Industrial process control using IP communications with publisher subscriber pattern

A method of controlling an industrial process run in a plant includes sending field data from the process to a data acquisition module. The data acquisition module converts the field data into Internet protocol (IP) field data. The IP field data is provided to an IP broker having a memory that stores the IP field data arranged in a tree of topics. The IP broker has a stored publisher/subscriber pattern including a plurality of clients including a first client subscribed by a published message to the IP broker that includes at least a selected topic from the tree of topics. Upon receipt of an update of the IP field data including the selected topic, the IP broker publishes the updated IP field data according to the publisher/subscriber pattern over a permanently open IP connection that is received by at least the first client.

FIELD

Disclosed embodiments relate to process data transmission for visualization and for controlling an industrial process.

BACKGROUND

Process control systems for industrial processes, whether distributed control system (DCS) or supervisory control and data acquisition (SCADA) systems, generally include one or more process controllers communicatively coupled to at least one host (e.g., an operator workstation) and to one or more process control devices (e.g., field devices) configured to communicate via analog, digital or combined analog/digital communication signals and/or protocols. Such process control systems are commonly used in chemical, pharmaceutical, pulp and paper manufacturing and petroleum processes. The field devices can comprise device controllers, valves, valve actuators or positioners, switches, transmitters (e.g., temperature, pressure, flow rate, or chemical composition sensors), performing functions within the process control system such as opening and/or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, uses this information to implement a control routine, and generates control signals over buses and/or other communication lines to the field devices to control the operation of the process control system.

Some industrial processes such as petroleum refining include storage tanks. Tank gauging is needed for the assessment of tank contents, tank inventory control and tank farm management. Radar and servo tank sensors (or gauges) help in accurate level gauging for refineries, tank terminals and petrochemical industries. Tank inventory systems utilize tank gauging data and provide connectivity for various field protocols that enable integration of existing field equipment. A set of standardized host interface areas are available to link software packages to control systems and business domain packages for advanced resource planning and asset management.

There are known tank inventory systems sufficiently flexible to handle tank farms ranging from a single tank up to more than 250 tanks, covering multiple locations and a variety of different gauges and interfaces. One such conventional tank inventory system comprises a pair of embedded software “host” applications running in a Communication Interface Unit (CIU) that is essentially basically an embedded personal computer (PC) and a dedicated WINDOWS graphical user interface (GUI) application that provides GUIs in standard formats for representing process data with both text and graphics running at a PC at an operator station or distributed control system (DCS).

This conventional tank inventory system requires high development costs and significant maintainability efforts because designing and implementing a GUI to suit all customers takes considerable effort. An experienced programmer is needed to perform this task. All logic for performing calculations, rounding, input validation, (button) event handling, localization, etc. also needs good programming skills. Moreover, such conventional tank inventory systems generally provide only a limited provision for customization/extension for customers should they have any specific need(s).

SUMMARY

Disclosed embodiments recognize known process control systems (e.g., tank inventory systems) depend on serial Modbus remote terminal unit (RTU) communications throughout. The data from the field devices generally gets polled in sequential order. This serial communications with sequential data ordering results in a somewhat sluggish deliver of field data to the operators in the control room. Moreover, serial lines are limited to maximum lengths and the data is limited to what is published in the Modbus map.

By using publish subscribe features of a modern Internet Protocol (IP) connectivity protocol (such as machine-to-machine (M2M) based on Internet of Things (IIoT technologies) because of the broader bandwidth of IP connections as compared to serial RTU lines the field data gets delivered to the operator or other client significantly faster. Other advantages include the IP communications simplifying configuration changes as they are published by the applications back to the IP broker, as well as other updates of data and/or commands including kill, manual overwrite and resurrects.

Disclosed control systems are better in providing site device management (SDM) data to service clients located somewhere in the local area network (LAN), wide area network (WAN) or in the cloud. Using conventional serial lines the service tools can only operate on the machine which is connected by the serial lines. With using IP connections such as based on IIoT technologies used in disclosed embodiments, service tools or diagnostic services can subscribe to data from anywhere in the LAN, WAN or cloud and analyze the state of the processing equipment and other devices while in process. Raw field data can be transported to the service tools easily. Diagnostics will also receive a new dimension such as analyzing the data, predicting maintenance and informing service engineers about it.

Disclosed embodiments include process data transmission, calculation and optional visualization architectures and associated methods for controlling industrial processes that utilize IP communications based on a publisher subscriber pattern of a publisher/subscriber model to deliver (push) process data to clients such as operators at operator stations. Stored messages are organized at an IP broker around a tree of topics, and clients subscribe to messages stored at the IP broker that are delivered to client(s) that subscribe to a particular topic or to groups of topics. The data pushed to the clients is generally used by the client to fill GUI components in their display for representing process data with both text and graphics generally running at a personal computer (PC) at an operator station or a distributed control system (DCS), or by web applications visualized by Internet browsers on a PC or any mobile device or mobile apps running on smart phones or tablets.

As known in communications, the IP suite is the computer networking model and set of communications protocols used on the Internet and similar computer networks commonly known as TCP/IP based on its most important protocols, the Transmission Control Protocol (TCP) and the Internet Protocol (IP) being the first networking protocols defined during its development. The IP communications can comprise, but is not limited to machine (M2M)/Internet of Things known as Message Queuing Telemetry Transport (MQTT), Advanced Messaging Queuing Protocol (AMQP), and OPC Unified Architecture (OPC UA). The process data from the device layer is converted from a serial protocol (e.g., Modbus) to IP communications which pushes the data directly to the application (GUI) layer by using a publish subscriber pattern. For example, in collaboration with a MQTT broker, live data from field devices in a plant can be pushed the application layer instead of the application layer pulling the data on request or at selected time intervals.

The application layer can apply a visualization algorithm to the calculated data configured to fill GUI's generally modeled in WINDOWS forms (WINDOWS GUIs). Instead, the calculated data can be processed by client' web applications for visualizing the content by Internet browsers on a PC or any mobile device or mobile application running on smart phones or tablets. A control activity regarding the processing equipment can be performed for controlling the equipment in the plant running the industrial process using the visualization provided by the WINDOWS GUIs or client' web applications.

DETAILED DESCRIPTION

Disclosed embodiments are described with reference to the attached figures, wherein like reference numerals are used throughout the figures to designate similar or equivalent elements. The figures are not drawn to scale and they are provided merely to illustrate certain disclosed aspects. Several disclosed aspects are described below with reference to example applications for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the disclosed embodiments.

One having ordinary skill in the relevant art, however, will readily recognize that the subject matter disclosed herein can be practiced without one or more of the specific details or with other methods. In other instances, well-known structures or operations are not shown in detail to avoid obscuring certain aspects. This Disclosure is not limited by the illustrated ordering of acts or events, as some acts may occur in different orders and/or concurrently with other acts or events. Furthermore, not all illustrated acts or events are required to implement a methodology in accordance with the embodiments disclosed herein.

Also, the terms “coupled to” or “couples with” (and the like) as used herein without further qualification are intended to describe either an indirect or direct electrical connection. Thus, if a first device “couples” to a second device, that connection can be through a direct electrical connection where there are only parasitics in the pathway, or through an indirect electrical connection via intervening items including other devices and connections. For indirect coupling, the intervening item generally does not modify the information of a signal but may adjust its current level, voltage level, and/or power level.

FIG. 1is a flow chart that shows steps in a method100of controlling an industrial process using IP communications based on a publisher subscriber pattern, according to an example embodiment. Step101comprises sending measured field data from an industrial process run in a plant (see industrial plant105inFIGS. 2 and 3described below) including processing equipment having associated field devices110in a device layer including sensors110a,110b, and actuator(s)110c(collectively field devices110) for sensing field data and processing equipment112a,112bcoupled to a field layer130comprising a data acquisition block135including a data acquisition module135aand an IP broker135bby a bus125.

The data acquisition module135acan comprise a device for scanning or polling the field data, with this module generally called a scanner. The scanner makes sure the field data gets acquired regularly. A side task of the scanner is to raise events when the field devices110are not responding for some reason. However, the field data can flow to the data acquisition module135ain other ways. In another embodiment, instead of scanning the measured field data to scanned data, the field devices110can be “smart” field devices programmed to deliver the field data regularly (at regular or predetermined intervals) to the data acquisition module135a. The data acquisition module135aconverts the measured field data into IP field data.

IP communications provides end-to-end data communication specifying how data is packetized, addressed, transmitted, routed and received. As known in the art, this functionality is organized into four abstraction layers which are used to sort all related protocols according to the scope of networking involved. From lowest to highest, the layers are the link layer, containing communication methods for data that remains within a single network segment (link); the internet layer, connecting independent networks, thus providing internetworking; the transport layer handling host-to-host communication; and the application layer, which provides process-to-process data exchange for applications.

The IP data output by data acquisition module135acan comprise MQTT data, AQMP data or OPC UA data. MQTT is an ISO standard (ISO/IEC PRF 20922) publish-subscribe-based “lightweight” messaging protocol for use on top of the TCP/IP protocol. AQMP stands for Advanced Message Queuing Protocol which is a wire-level protocol that is a description of the format of the data that is sent across the network as a stream of octets. OPC UA is an industrial machine-to-machine (M2M) communication protocol for interoperability developed by the Open Process Control (OPC) Foundation.

MQTT is low overhead, with only a 2-byte header for many messages. The MQTT design suits devices that are suspended (inactive) most of the time, with only occasional network activity. MQTT also has support for reliable delivery built into the protocol, so that simple sensors can simply flag an outgoing message as requiring confirmed delivery and let the IP broker take care of delivery reattempts. Using a standard messaging protocol for all communication also significantly reduces the surface area for possible security vulnerabilities.

Step102comprises providing the IP field data to an IP broker (see IP broker135binFIG. 2) having at least one memory135b1(e.g., Random Access Memory) that stores the IP field data arranged in a tree of topics. A topic is generally a simple string that can have more hierarchy levels, which may be separated by a slash. Clients can subscribe to an exact topic or use a wildcard. The IP broker has a stored publisher/subscriber pattern in memory135b1comprising a plurality of clients including at least a first client, such as a client at an operator station or DCS (see DCS180and operator station185inFIG. 2) and/or in an application layer (see application layer150inFIG. 2). Each client is subscribed by a published message to the IP broker that includes at least a selected topic from the tree of topics. Publish/subscribe is event-driven and enables messages to be pushed to clients.

The IP broker is the central communication point in charge of dispatching all messages between the senders (field devices110) and the rightful receivers (clients). Each client that publishes a message to the broker includes a topic into the message. The topic includes the routing information for the IP broker to use. Each client that wants to receive messages subscribes to a certain topic and the IP broker delivers all messages with the matching topic to the client. Therefore the respective clients don't have to “know” each other, as they only communicate over the topic. This architecture enables highly scalable solutions without dependencies between the data producers and the data consumers.

In step103upon receipt of an update of the field data (new field data) including the selected topic, the IP broker publishes the updated IP field data according to the publisher/subscriber pattern stored in memory135b1over a permanently open IP connection to at least the first client. For example, there is an IP connection138shown inFIG. 2between the IP broker135band clients such as in the application layer150and the cloud computing system190.

FIG. 2is a depiction of an automatic control system200associated with an industrial plant105configured to run an industrial process (e.g., refining) that utilizes IP communications over an IP connection138based on a publisher subscriber pattern having an IP broker135bin a data acquisition block135, according to an example embodiment. The field layer130includes a data acquisition block135which functions as an input/output (IO) module that includes a data acquisition module135a, where the data acquisition module135acan comprise a smart Communication Interface Unit (CIU) which can provide an intelligent IO interface that knows about the processing equipment (e.g., instruments, tanks) and the complete site setup at the industrial plant105. Such a CIU can take care of fetching the field data from the field devices110, performing data calculations, and presenting a complete record as shown inFIG. 2to layers such as the cross software platform layer140, application layer150, and cloud computing system190. The field layer130, cross software platform layer140, application layer150and cloud computing system190collectively can be considered a data processing and visualization system170for the control system200.

The field devices110in industrial plant105shown as sensors110a,110bprovide measured field data and actuators110care coupled to processing equipment112a,112b(such as storage tanks in a refining or distillation system) configured together to run an industrial process. The field devices110are coupled by a bus125to the field layer130. The bus125can be a serial bus, such as a MODBUS RTU, used in serial communication which makes use of a compact, binary representation of the data for protocol communication.

In the arrangement shown inFIG. 2, process data from the plant105acquired by data acquisition block135is stored in a cache memory135a1in the data acquisition module135a. Typically the hosts are connected peer-to-peer to the data acquisition module135a, with the host inFIG. 2being the IP broker135bwhich hosts the calculated data provided by the data acquisition module135a. The IP broker135bscans this cache memory135a1on regular basis to collect new field data. This means two asynchronous communication routines working with the same cache memory135a1, meaning the data acquisition module135asuch as a scanner is polling the field data from the field devices110and is storing it in the cache memory135a1while the IP broker135bis polling the same cache memory135a1for updates. As the data acquisition module135aand IP broker135bboth rely on the same cache memory135a1, some latency can be expected.

In a tank gauging system one typically finds scanned values, commissioning, configuration, diagnostics and calculated values in this system200are arranged as topics in a memory135b1of the IP broker135b. By creating a well-defined object, an instance can be used for the payload of the topics. To avoid latency an intelligent controller (e.g., an intelligent CIU) for the data acquisition module135acan process the acquired field data and use it to prepare a verbose payload containing all the parameters the applications need. This object can be a JavaScript Object Notation (JSON), binary JSON (BSON) or generally any serialized object type modeling the payload.

The object of the payload can hold the process parameter value, the status, the validity, timestamp, units of measurement, and boundaries such as minimum and maximum allowed values, the required update rate, the category, etc. The data acquisition module135apopulates the value fields of the prepared serialized object modeling the payload and publishes it to the IP broker135b. All clients in the application layer150, the calculation block162/DLLs163, and cloud computing system190subscribed to the IP broker135bconnected by the IP connection138will automatically receive call-backs and further process the data without latency, and optionally the DCS180its and operator station185can also be clients of the IP broker135bwhen the bus139is an TCP/IP bus. The calculation block162/DLLs163can generally be any solution such as a service, WINDOWS or other OS Application, or Web service.

All topics with their payload will be stored in the memory135b1of the IP broker135b, such as scanned values, commissioning, configuration, diagnostics and calculated values such as when the data acquisition module135acomprises a ‘smart’ CIU. Configuration changes will be published from the application layer150(optionally the DCS180its and operator station185, and cloud computing system190in the IP broker135b(or broker(s)). This simplifies the configuration of the data acquisition block135. By subscribing to changes the data acquisition block135can update its scan list by received call-backs published by the commissioning/configuration module152shown inFIG. 3.

The data acquisition module135asuch as a CIU can be Ethernet enabled. The data acquisition block135is shown coupled by a bus139to the DCS180and its operator station185that are both shown outside of the application layer150as they can process raw field data received from the field layer130. DCS180can also have an IP input to acquire data from the IP broker135b, or a Modbus input to acquire data directly from the input of the data acquisition block135(e.g., CIU or similar device) by a serial or an Ethernet link.

The data processing and visualization system170also includes a cross software platform layer140. The cross software platform layer140and application layer150are generally implemented by one or more processors shown as processor160that is generally part of computing device such as a personal computer (PC)/server. The processor160can comprise a microprocessor, digital signal processor (DSP), or microcontroller unit (MCU). The cross software platform layer140is coupled by the IP connection138to receive data from the IP broker135b. The processor160has an associated memory160athat stores algorithms shown collectively as166including a calculation algorithm66afor implementing the calculation block162that performs calculations on the field data and an optional visualization algorithm166b. The visualization algorithm166bpopulates with calculated data from the calculation algorithm166afor filling WINDOWS GUIs, or the calculated data is visualized without the need for the visualization algorithm166bby web applications visualized by Internet browsers on a PC or any mobile device or mobile applications running on smart phones or tablets for a display.

The visualization algorithm166ballows a user (e.g. at the application layer150or at the operator station185) to select a mapping that maps some or all the data available from the cross software platform layer140to fill WINDOWS GUIs. For example, the data acquisition provided by the cross software platform layer140generally has a plurality of different data entities available, such as for tank applications Tank1/Level, Tank1/Temperature, Tank1/Volume. The user can change the mapping table at any time when he or she wants to move the data to other WINDOWS GUIs or other web applications

The application layer150can host any application which is able to subscribe to the IP broker135band visualize the payload of the topics. The application layer150can generally comprise any application capable of de-serializing and visualizing the payload. Between the cross software platform layer140and applications layer150is a publish subscribe relationship. All applications can subscribe on data which get pushed from the IP broker135bto the applications. On the other hand placing the subscriptions but also the storage/update of configuration data will flow from applications back to the IP broker135b. The IP broker135b, application layer150and calculation block162are connected to one another by the IP connection138.

The bus139for legacy systems enables DCS180and its operator station185to connect to the field layer130by Modbus, or by an OPC connection. The provided peer-to-peer connections can comprise RS232, or RS485 connections. For future DCS systems, bus139can comprise M2M protocols over TCP/IP or OPC-UA (over TCP/IP). The operator station185for DCs180may also be moved to the application layer150which has advantages including bandwidth, essentially no latency, longer distance, and remote capabilities. The cloud computing system190shown allows data to be stored in the cloud and for some host services to be remotely performed there.

The calculation library163is shown implemented as a plurality of separate modules (e.g., DLLs), which for tank applications can provide American Petroleum Institute (API)-conforming calculations. In the case of tank inventory applications, calculation library163can implement other calculation methods, such as ASTM or GPA. The data acquisition provided by the cross software platform layer140can include a plurality of data entities available that by a mapping table customizing a visualization algorithm166bfrom a user can map respective data entities to selected WINDOWS GUIs. The user can change the mapping table at any time when he/she wants to move the data.

FIG. 3is a depiction of an automatic control system300that utilizes IP communications based on a publisher subscriber pattern associated with an industrial plant105configured to run an industrial process, having an IP broker145bhaving memory145b1in the cross software platform layer140′, according to an example embodiment. In this embodiment the data acquisition module135a′ in the field layer130′ is not an intelligent (smart) module and thus does not perform calculations on the field data it receives. The data acquisition module135a′ generates raw scanned field data fetched by the cross software platform layer140′ that includes a data acquisition module145a. A bus132(e.g., Modbus) connects the data acquisition module135a′ to the data acquisition module145a. In this embodiment the data acquisition module145aconverts the serial field data received from the data acquisition module135a′ into IP field data that is provided to the IP broker145b. The field layer130, cross software platform layer140′, application layer150and cloud computing system190collectively can be considered a data processing and visualization system170′ for the control system200

In control system300the calculations are performed in the cross software platform layer140′ or by the application layer150. Typically a GUI is used to display (visualize) the values fetched by the data acquisition module135a′ and display the information to the end user. In control system300the visualization algorithm166bprocesses the data received from bus132and prepares it for showing to the user as described as GUI layer functions in the paragraph below.

Even when the field data comes as a prepared record with calculated data (such as by a ‘smart’ data acquisition module135ainFIG. 2), it generally needs to be processed by a GUI application in the application layer to display (visualize) it. The Modbus output conventional CIUs as the data acquisition module135aor135a′ provide include a number of bytes. The GUI application generally needs to perform a number of functions, for example extracting the information, taking care of the rounding and format in a number of decimals and showing the right units of dimension. On request values need to be converted to another dimension and shown with another number of decimals. Colors can be provided having special meanings, and the status generally needs to be determined and shown.

Although not shown, disclosed embodiments include automatic control systems including a data processing and visualization system using IP communications based on a publisher subscriber pattern associated with an industrial plant configured to run an industrial process, having an IP broker in the CIU and another IP broker in the cross platform layer. This arrangement enables use of a data acquisition module with either basic CIU(s) or smart CIU(s) to be accommodated.

While various disclosed embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Numerous changes to the subject matter disclosed herein can be made in accordance with this Disclosure without departing from the spirit or scope of this Disclosure. In addition, while a particular feature may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.

As will be appreciated by one skilled in the art, the subject matter disclosed herein may be embodied as a system, method or computer program product. Accordingly, this Disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, this Disclosure may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.