Patent Application
20080081579
Referring now to
As is known, each of the controllers 12, which may be by way of example, the DeltaV controller sold by Fisher-Rosemount Systems, Inc., stores and executes a controller application that implements a control strategy using any number of different, independently executed, control modules or blocks. Each of the control modules can be made up of what are commonly referred to as function blocks wherein each function block is a part or a subroutine of an overall control routine and operates in conjunction with other function blocks (via communications called links) to implement process control loops within the process plant 10. As is well known, function blocks, which may but need not be objects in an object oriented programming protocol, typically perform one of an input function, such as that associated with a transmitter, a sensor or other process parameter measurement device, a control function, such as that associated with a control routine that performs proportional-integral-derivative (PID), fuzzy logic, etc. control, or an output function that controls the operation of some device, such as a valve, to perform some physical function within the process plant 10. Of course hybrid and other types of complex function blocks exist such as model predictive controllers (MPCs), optimizers, etc. While the Fieldbus protocol and the DeltaV system protocol use control modules and function blocks designed and implemented in an object oriented programming protocol, the control modules could be designed using any desired control programming scheme including, for example, sequential function chart, ladder logic, etc. and are not limited to being designed and implemented using the function block or any other particular programming technique.
In the plant 10 illustrated in
Still further, in a known manner, one or more of the workstations 20 and 22 may include user interface applications to enable a user, such as an operator, a configuration engineer, a maintenance person, etc. to interface with the process control network within the plant 10. In particular, the workstation 22 may include one or more user interface applications which may be executed on a processor within the workstation 22 to communicate with the database 28, the control modules or other routines within the controllers 12 or I/O devices, with the field devices 14 and 16 and the modules within these field devices, etc. to obtain information from the plant, such as information related to the ongoing state of the process control system. The user interface applications may process and/or display this collected information on a display device associated with one or more of the workstations 20 and 22. The collected, processed and/or displayed information may be, for example, process state information, alarms and alerts generated within plant, maintenance data, etc. Likewise, one or more applications may be stored in an executed in the workstations 22 and 20 to perform configuration activities such as creating or configuring the modules to be executed within the plant, to perform control operator activities, such as changing set-points or other control variables, within the plant, etc. Of course the number and type of routines is not limited by the description provided herein and other numbers and types of process control related routines may be stored in an implemented within the workstations 20 and 22 if desired. The workstations 20, 22 may also be connected via, for example, the internet 30, extranet, bus, Ethernet, etc., to a corporate WAN 32 as well as to a computer system 34 that enables remote monitoring of or communication with the plant 10 from remote locations.
As shown in
The first layer 40 runs the process and has a tight real-time requirement of high predictability and reliability. As indicated above, the network protocols may be industry standards such as HART, Foundation Fieldbus, DeviceNet, etc. The first layer 40 generally utilizes reliable short range data transmissions, and communications at the first layer 40 may involve small data package sizes, such as less than 100 bytes. Wireless technologies at the first layer 40 may include, but are not limited to, ZigBee, WiFi, Bluetooth, Ultra Wideband (UWB), etc., or any other short-range wireless technology. In particular, wireless technologies at the first layer 40 may include any commercial off-the-shelf wireless products to transmit process control data. A network protocol may be implemented on top of the wireless technology at the first layer 40, or a new process control standard may be developed for wireless communication at the first layer 40. In one example, mesh technologies, such as a self-healing wireless mesh technology, may be implemented at the first layer 40.
The second layer 42 supports user interaction, including configuration, control and monitoring. The timing requirement of the second layer 42 may be less than that of the first layer 40, but still has good reliability. The network protocol for the second layer 42 may be proprietary, or an industry standard such as Ethernet. The second layer 42 generally utilizes longer transmission ranges and bigger data package sizes. As a result, the second layer 42 may have less strict requirements as compared to the first layer 40 and commercial off-the-shelf wireless products to transmit process control data, such as satellite, Wi-Max, and other wireless technologies, may be used at this level to support long-range wireless transmission. Microwave and radio may also be used for shorter distances.
The third layer 44 may be considered a gateway of the process control system to other systems, such as corporate systems which may include, but are not limited to, accounting, inventory, management decision systems, etc. At the third layer 44, conventional networks may be deployed, such as an office network, intranet, etc. Communications at the third layer 44 may be of less concern to process control communications, and various conventional wireless technologies may be utilized.
Regardless of the communication technology utilized within the process control system, each of the devices 14, 16 may include one or more actuators, sensors, or other I/O devices. Each of the I/O devices may correspond to an input/output data point, where an input/output data point within the process control system is a source of process control data. Critical process control data may be collected utilizing point-to-point wireline communications. On the other hand, wireless communications, such as a wireless mesh network, may be deployed within the process control system to collect non-critical process control data. However, in a further example, a wireless mesh network may also be used to collect critical process control data, and, as a result, may be used throughout the process control system. Process control systems having an existing wireline, point-to-point communications may have wireline I/O devices gradually replaced with wireless I/O devices, or otherwise have the wireline communications network replaced with a wireless communications network, with minimal change to the existing process control system, such as utilizing the same network protocols used by the wireline, point-to-point process control system.
Referring to
The deployment of a mesh network anywhere within a process control system results in multiple wireless process control system nodes that transmit mesh network data, such as process control data, within the mesh network. For example, with a wireless mesh network between the controllers 12 and the workstations 20, 22, each of the controllers 12 may correspond to a wireless process control system node. With a wireless mesh network between the field devices 14, 16 and the controllers 12, each of the field devices 14, 16, or each of the associated I/O devices, may correspond to a wireless process control system node. While each of the process control nodes may communicate with the physical network, one or a few process control nodes within a mesh network may be dedicated as a communications gateway node. The gateway node within a wireless mesh network may act as a control node for the mesh network and facilitate communication between different networks, such as between the controllers 12 and the workstations 20, 22 or between the field devices 14, 16 and the controllers 12. For example, as shown in the wireless mesh network of
When implementing a wireless communication network for a process control system, a basic commercial wireless network, such as a commercial off-the-shelf mesh wireless network may be utilized, on top of which process control data communication middleware may be established. The middleware provides an application programming interface (API) to the process control system. The process control system transmits process control data to the middleware with transmission constraint requirements, but with little knowledge or awareness of the underlying wireless network. In other words, the underlying mesh wireless network is transparent to the process control system.
Referring to
During execution, the middleware carries out the commands from the process control system and maintains the parameters. In one example, the middleware automatically adjusts itself by taking into account a response time, bandwidth, number of packets, number of unacknowledged packets, delay times, cost and choosing between transmission media based on time of day, etc. One particular function of the middleware is maintenance of the network connections, because communications within a wireless network may be intermittent. Depending on configuration, the connection may be permanent between two nodes or ad hoc whenever a connection is available. In the case of redundant connections, the middleware may switch between primary and standby connections, where such switches are transparent to the process control applications. The middleware may add variable retries and timeout times for each connection to account for propagation delays, or allow multiple outstanding messages for more efficient bandwidth use.
During an active data transmission, the middleware may perform various tasks, including, but not limited to, round-trip delay timing, send message processing, receive message processing, retry of timeouts, message packing and unpacking, and other optimizations. With the round-trip delay timing task, the initial round-trip delay is based on the time between the synchronous request and the synchronous response when establishing a connection. The round-trip delay may be updated over time by timing the delay between sending a message and the receipt of the acknowledgment. The round-trip delay value is added to the message header to communicate the initial value to the passive end of the connection and to keep both ends of the connection in agreement of the current value.
With the send message processing task, remote connections should have the ability to support multiple outstanding send messages. A window parameter may define limits on how many messages are to be outstanding at any particular time, change the message sending function to send ail messages on the pending message queue up to the window limit, request an ackowledgment only on the last message sent, and add a timer to trigger sending messages that have queued while waiting for an acknowledgment on previous message.
For the received message processing task, when acknowledging a message the time send value may be copied from the received message into the acknowledgment message. This may be used to calculate round-trip times and provides a mechanism for validating that the acknowledgment is associated with the acknowledged message. If an out-of-order message is received, acknowledgment for messages that have been accepted up to this point may be returned. This prevents messages that have already been received but not yet acknowledged from being needlessly retransmitted. When an acknowledgment is received, the time sent value is checked against the time sent value in the message being acknowledged. If the times match, the round-trip time may be averaged into the round-trip time value.
For a retry and timeout task, in order to support multiple outstanding messages, each message must have a timeout value. As messages are acknowledged, they are removed from the acknowledgment time queue leaving messages to be timed out at the proper time. An acknowledgment may acknowledge multiple messages. All messages within the window that precede the sequence number being acknowledged are also acknowledged and are taken off the retransmit queue. Acknowledgments for messages with sequence numbers that are not in the window may be ignored. Management of the retransmit queue handles timing out multiple sets of messages sent at different times with each message given the same fixed amount of time to remain in the retransmit queue before being considered timed out. The retry value may be based on the configured timeout or on the round-trip delay. The timeout value for a link may be based on the number of retries for the link, where the retry count may be configurable depending on the link.
With the message packing and unpacking task, in order to better utilize a given bandwidth on a remote connection, as much information as possible may be packed into each packet, which may be particularly valuable if it is common for several small messages to be queued waiting for a message to be acknowledged or for the window to open up. In order to accomplish this, if two or more messages can fit into a single message buffer, a large message may be allocated and all available messages that will fit are copied into large buffer. As messages are received that contain more than one message as a result of being packed, new receive messages are allocated and data is copied from the packed message into individual message buffers to be processed. All messages contained in a single message may be acknowledged by a single acknowledgment of the last sequence number on the packed messages.
The middleware layer may farther enable many additional kinds of optimizations. If several applications request the same data, multiple requests for the same data may be sent over the wireless link. For remote network connections using delayed transmission media, such as satellite or modems, runtime data may be collected on the remote side of the network over the communication link and distributed to the other side, which reduces the amount of message traffic sent over the network. The remote applications may then retrieve the runtime data from the local middleware instead of requests and over the communications link.
While the above disclosure describes the implementation and deployment of a wireless mesh network within a process control system, wireless mesh networks may also be deployed in whole or in part outside of a process control system. For example, mesh networks may be deployed in areas that are inhospitable or inaccessible by traditional wireline networks. Further, mesh networks may be deployed to collect non-critical process control data or auxiliary data which may be cost prohibitive to collect using traditional wireline networks, or which may be otherwise inaccessible by the process control system. Auxiliary data may include data that is unrelated to process control but which may nonetheless be useful to a user accessing the auxiliary data from within the process control system, including, but not limited to, control room light switches, stock prices, weather forecasts, etc. However, because a process control system can only communicate with I/O devices that it understands, mesh network data generated from wireless I/O devices within a mesh network, whether it be critical process control data, non-critical process control data, auxiliary data, etc., should be provided to a process control system assist the mesh network data is native to the process control system. This may further apply to mesh networks that are deployed within a process control system as part of the control system itself In other words, an appropriate interface merges mesh network data from a mesh network to a process control system. In particular, the mesh network data should be provided to the process control system 10 so that the mesh network data shows up in the process control system as if it is native process control data. Although mesh networks and corresponding mesh components have been, and are further, disclosed, it should be understood that different wireless technologies and different wireless networks may be utilized in place of wireless mesh networks, and that communications between a process control system and other wireless networks may be facilitated by the methods and apparatus described herein.
Referring to
As seen in
Each node may correspond to one or more I/O devices which generate information and which may receive information, such as instructions from the process control system 104. Each node may correspond to one or more input/output data points where each input/output data point is a source of information from the wireless mesh network 102. For example, each I/O device within the mesh network may correspond to an input/output data point within the mesh network. A central control node, such as a central control computer, may be provided within the mesh network 102 to control the mesh network nodes. The central control node may act as a communication gateway node for the mesh network to communicate mesh network data from the input/output data points to the mesh server 100, and each node within the mesh network 102 may function as a repeater to transmit data from other nodes to the central control node. It is noted, however, that the central control node need not necessarily correspond to an I/O device to collect or provide mesh network data itself.
The process control system 104, which may be the process control system 10 disclosed above or any other process control system implementation, may support object linking and embedding (OLE) for process control (OPC), or another process control interface. OPC provides a common process control interface for entities, such as field devices 14, 16, within the process control system 104. The process control system 104 may be communicatively coupled to the mesh server 100 via a communications link, such as an OPC communications link. In particular, the process control system 104 may include an OPC server (not shown) which communicates with the mesh server 100. As shown in
Data point placeholders are defined within the process control system 104, with a data point placeholder configured within the process control system 104 for each input/output data point within the mesh network 102. In particular, a user may configure each data point placeholder in the process control system 104 for each input/output data point in the mesh network 102 that the user wants to merge into the process control system 104. The data point placeholders are treated within the process control system as if they are input/output data points native to the process control system 104, as opposed to input/output data points in the mesh network 102. A data point placeholder provides a unique identification for an input/output data point within the mesh network 102, and reserves a spot within the process control system for mesh network data from the corresponding input/output data point. In other words, a data point placeholder provides a way for mesh network data from an input/output data point in the mesh network 102 to be referenced within the process control system, without establishing a new input/output data point in the process control system and without requiring the process control system to know of the existence of the mesh network, much less the input/output data point.
The unique identification of a data point placeholder distinguishes the different input/output data points. For example, the unique identification may specify the name of a component within the wireless mesh network 102, such as the switch for a fan XYZ (e.g., “on_XYZ”), where an input/output data point corresponds to an I/O device that generates the on/off data for the fan (e.g., a switch) and mesh network data from the input/output data point is the on/off data from the switch. As discussed further below, this mesh network data is provided to the mesh server 100, which in turn provides the data to the corresponding data point placeholder (e.g., “on_XYZ”) in the process control system 104. The data point placeholders may then be treated within the process control system 104 as if they are process control system input/output data points, even though the process control system 104 does not necessarily know the source of the data. As a result, the mesh network data may be treated as process control data native to the process control system. 104. Further, the process control system may use the data point placeholders to provide process control data, such as instructions or requests, to the input/output data points in the wireless mesh network 102 via the mesh server 100, as will be described further below. It is noted, however, that data values from the mesh network 102 may not be as real-time to the process control system 104 as compared to process control data from the process control system 104. However, the mesh network data that may still be used includes, but is not limited to, configuration data, displayed data, alarm/event data, the diagnostics data, etc., and the mesh network data may be used via a tool or toolset in the control system. Further, the mesh network data may be employed to improve process control in the process control system 104.
The mesh server 100 includes a configuration 106, a mesh service 108, and a mesh interface 110. A mesh driver 112 may be published by the mesh network 102, and provided to the mesh server 100. The mesh driver 112 may be assumed to exist within the mesh network 102, and different mesh networks 102 may support different drivers. The mesh server 100 accesses the mesh network 102 through the mesh driver 112, and accesses the process control system 104 through the process control interface, for example through OPC. The mesh server 100 thus provides the software to interface between the mesh network 102 and the process control system 104. The mesh server 100 may facilitate the use of the process control system 104 as a process control system for the underlying mesh network 102, as will be described further.
The configuration 106 is stored within a file in a memory or database of the mesh server 100, and may be provided as an XML data file. The configuration 106 includes a list of data point maps between the process control system data point placeholders and the mesh network input/output data points. In particular, each data point map identifies which data point placeholders correspond with which input/output data points. The data point map also defines where data attributes defined in OPC come from, including, but not limited to, attributes such as timestamp, quality, etc.
Different data point maps may be provided for different groups of input/output data points or for different groups of data point placeholders. For example, the data point maps may be defined according to the mesh network 102 to which an input/output data point may belong, or according to the process control system to which a data point placeholder may belong. Alternatively, entities within the mesh network 102, and corresponding input/output data points, may be grouped according logical groupings, such as location, update frequency or function. For a mesh network 102 deployed in a process control system, entities may include groups of devices and/or equipment such as loops, sub-units, units, areas or other process control entities. In short, different data point maps may be provided for each entity within the mesh network 102, such as a data point map for each loop, sub-unit, a unit, area or any other logical grouping.
Further, the configuration 106 includes an update period which dictates how often mesh network data needs to be retrieved from the mesh network 102, updated to the mesh server 100 and provided to the process control system 104. Different update periods may be provided for different data point maps. For example, mesh network data from some input/output data points may need to be updated to the process control system 104 more frequently than mesh network data from other input/output data points. Connection information may also be provided with the configuration 106 to provide the information necessary to connect with the process control system OPC server.
The mesh service 108 communicates with the process control system 104 via a communications link. As mentioned above, the communications link may be an OPC communications link, although the OPC communications link may be replaced with a proprietary link in which the mesh service 108 invokes a proprietary or private process control system application programming interface (API) to read/write data directly to/from the process control system 104, in which case the configuration 106 may indicate how to handle attributes of tile data, such as timestamp, quality, etc. The mesh service 108 makes function calls to the mesh interface 110, where the function calls may be requests to read data from, or write data to, the mesh network 102. If the mesh service 108 is executed on a Windows workstation, the mesh service 108 may be run as a Windows service.
The mesh interface 110 serves as a interface to access the mesh network 102. The mesh interface is responsible for marshalling calls between the mesh service 108 and the mesh network 102. The mesh interface 110 receives requests from the mesh service 108 and makes a request to the mesh driver 112 The mesh interface 110 further translates the request into a request understood by the mesh driver API.
In one example, the mesh interface 110 provides a set of uniformed APIs for the mesh service 108, and calls into the mesh driver 110 to access data from the mesh network 102. A different API may be provided and invoked by the mesh interface 110 for each mesh network 102 (or each mesh driver 112) that interfaces with the mesh server 100. In another example, the mesh interface 110 may be provided as a unified wireless interface which serves as a common interface to access the mesh network, and the common interface may serve as a data source for any third party clients. The API for the common interface may be defined to best fit the process control system requirements. For example, the mesh interface 110 may use OPC as a common interface. In yet another example, the mesh service 108 and the mesh interface 110 may be provided as a unified interface.
In operation, the mesh service 108 reads the configuration 106 and connects with the process control system by the communications link. Using the data point map from the configuration 106, the mesh service 108 may create data point placeholders within the process control system 104 for any unmapped input/output data points within the mesh network 102. The mesh service 108 further accesses the mesh network 102 via the mesh driver 112 of the mesh interface 110. In order to communicate with the mesh network 102, the mesh service 108 makes function calls to the mesh interface 110. The mesh interface 110 receives a request from the mesh service 108 makes a request to the mesh driver 112. In particular, the mesh interface 110 translates the mesh service request into a request understood by the mesh driver API. In other words, the mesh interface 110 marshals calls between the mesh service 108 and the mesh network 102.
For each input/output data point in the mesh network 102, and for each data point map, the mesh service 108 reads mesh network data from the mesh network 102, for example via the central control node. As such, the mesh server 100 may receive the mesh network data for some or all of the entities within the mesh network 102, including some or all of the input/output data points within the mesh network 102. In addition, because each data point map may correspond to different mesh network, reading mesh network data for each data point map may result in reading mesh network data for a plurality of wireless mesh networks. However, it should be understood that mesh network data generated by input/output data points may be read individually, for example in response to a request from the process control system 104 for mesh network data from a data point placeholder, and hence from a particular input/output data point in the mesh network.
Using the data point map, each item of mesh network data is mapped between the input/output data point which provided the mesh network data and the data point placeholder in the process control system 104 that corresponds to the input/output data point. The mapped mesh network data is then written to the data point placeholder of the process control system 104 which corresponds to the input/output data point. In one example, the data may be read from the mesh network 102 and written immediately to the OPC server of the process control system 104 through OPC to minimize any delay in providing the mesh network data in real-time.
After writing data to the process control system 104, the mesh service 108 may sleep for a configurable length of time, after which the mesh service 108 may repeat the read/write operation between the mesh network 102 and process control system 104. As indicated above, the read write operation may be dictated by the update periods defined in the configuration 106.
When the mesh network data is written to a data point placeholder in the process control system 104, the process control system treats the data point placeholder as an input/output data point within the process control system 104 and the mesh network data is provided within the process control system 104 as process control data native to the process control system 104. As a result, the mesh network 102, and the input/output data points therein, are transparent to the process control system 104. A user is able to manage the mesh network data within the process control system environment using any process control system tool or toolset, including, but not limited to, diagnostics routines, process control operations, maintenance routines, business functions, analysis routines, and the like.
In addition to providing mesh network data to a process control system 104, the mesh server 100 may be used to provide process control information, such as commands requests etc., to input/output data points within the mesh network 102. In particular, an indication may be provided in the configuration 106 to write data front the process control system 104 to the mesh network 102, and the mesh service 108 may read the process control data through the process control interface and write the data to the mesh driver 112. For example, the mesh service 108 may receive process control data from the process control system via the process control interface, such as OPC. The process control data may include a command to turn on fan XYZ. Using the data point placeholder (e.g., “on_XYZ”) of the process control system 104 corresponding to the input/output data point of the switch of fan XYZ, the process control system 104 may issue the command using the data point placeholder as an input/output data point, and the command is read by the mesh server 100. Using the data point maps from the configuration 106, the mesh service 108 maps the process control data between the data point placeholder of the process control system and the corresponding input/output data point of the mesh network 102. For example, the mesh service 108 may map the “on” command between the data point placeholder “on_XYZ” and the wireless node corresponding to the I/O device of the switch for fan XYZ. Communication with the mesh network 102 may be established, as described above, and the mapped process control data may be written to the mesh network 102 via the mesh driver 112.
If the OPC link between the mesh service 108 and the process control system 104 is replaced with a proprietary link and the process control system interface utilizes a private process control system API, as mentioned above, the mesh service 108 may invoke the private process control system API to read a mesh network data directly from the mesh network 102 to the process control system 104, and particularly to write the mesh network data directly from the mesh network 102 to the data point placeholder of the process control system 104. Likewise, read/write operations may be performed directly from the process control system 104 to the mesh network 102.
Still further, using the mesh server 100, the process control system 104 may be used as a pure control system for the underlying mesh network 102, which may be particularly useful if the mesh network 102 is being used as all or part of the process control system 104 (e.g. gradual replacement of wireline I/O devices within the process control system). Generally, a process control system includes various I/O devices for entities within the process control system, such as sensors, actuators, etc. for components, controllers, equipment, field devices, etc. Each I/O device may correspond to an input/output data point within the process control system software. However, using the mesh server 100, the process control system software may be deployed without any input/output data points. Instead, data point placeholders are used in place of the input/output data points.
As a result, a wireless mesh network deployed in all or in part of the process control system 104 may be used to collect process control data, and provide the process control data to the process control system 104 via the mesh server 100. The process control system 104 may use data point placeholders for the input/output data points within the wireless mesh network 102, and, as described above, the process control system software may utilize only data point placeholders in place of input/output data points. The process control system 104, including the application and algorithms therein, use the data point placeholders as input/output data points native to the process control system 104 in order to facilitate operations of the physical part of the process control system 104, such as the controllers 12, the field devices 14, 16, etc., including controlling, communicating or otherwise interacting with an entity in the process control system 104.
Although the forgoing text sets Forth a detailed description of numerous different embodiments of the invention, it should be understood that the scope of the invention is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possibly embodiment of the invention because describing, every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims defining the invention.
Thus, many modifications and variations may be made in the techniques and structures described and illustrated herein without departing from the spirit and scope of the present invention. Accordingly, it should be understood that the methods and apparatus described herein are illustrative only and are not limiting upon the scope of the invention.
