Not applicable.
Not applicable.
Not applicable.
This patent relates generally to process control systems and, more particularly, to a remote processing and protocol conversion interface module.
Process control systems, like those used in chemical, petroleum or other processes, typically include at least one centralized process controller communicatively coupled to at least one host or operator workstation and to one or more field devices via analog and/or digital buses or other communication lines or channels. The field devices, which may be, for example, valves, valve positioners, switches, transmitters (e.g., temperature, pressure and flow rate sensors), etc. perform functions within the process such as opening 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 via an input/output (I/O) device, uses this information to implement a control routine and then generates control signals which are sent over the buses or other communication channels via the input/output device to the field devices to control the operation of the process. Information from the field devices and the controller is typically made available to one or more applications executed by the operator workstation to enable an operator to perform any desired function with respect to the process, such as viewing the current state of the process, modifying the operation of the process, configuring the process, documenting the process, etc.
Over the last decade or so, smart field devices including a microprocessor and a memory have become prevalent in the process control industry. In addition to performing a primary function within the process, smart field devices may store data pertaining to the device, communicate with the controller and/or other devices in a digital or combined digital and analog format, and perform secondary tasks such as self-calibration, identification, diagnostics, etc.
In the past, standard communication protocols were developed to enable controllers and field devices from different manufacturers to exchange data using standard formats. In many cases, however, the variations in the communication protocols made them suitable for use in some environments while others were more suitable elsewhere, even within the same plant or facility. For example, a 4-20 milliampere (“mA”) protocol has good noise immunity but requires dedicated wiring. A high speed Ethernet (HSE) protocol may be fast but often requires expensive rewiring. Other protocols, such as controller area network (“CAN”), HART®, H1, Foundation™ Fieldbus (“Fieldbus”), Actuator Sensor Interface (“AS-Interface” or “ASI”) and others have features and drawbacks including maximum length of cable run, multi-drop/single drop, intrinsically safe (for explosive environments), noise immunity, backward compatibility, supplemental power, etc. Sometimes the features often dictate the use of one protocol and its associated wiring even though it is not suitable for use in an entire plant or facility. Accommodations must be made to deal with the drawbacks. For example, to compensate for short distance wiring runs, plants may use an arrangement where a single field process control module is coupled to a single control board using one protocol. Then, the control board communicates to a central controller via a second protocol more suited to that connection. For example, a 3051S Super Module may be coupled to a Fieldbus feature board by a CAN network, and the Fieldbus feature board communicates to a central controller, or other upstream data manager, using an H1 protocol network. Such architectures solve problems associated with incompatible wiring and protocol, but it is still relatively expensive, and may be relatively difficult to maintain.
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present invention.
While this invention is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail preferred embodiments of the invention with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and is not intended to limit the broad aspect of the invention to the embodiments illustrated.
Referring to
Each of the Fieldbus boards 104a-n is programmed to send and receive data with a respective field device 102a-n. The data sent may include instructions for setting an actuator, requests for current state or requests for status such as the health of the field device. Data received from the field device 102 may include acknowledgements of setting requests, responses to other requests, or alarms, for example. The Fieldbus board 104 may, in some embodiments, use a higher speed network 116, such as HSE, to communicate with a process controller 114.
In most cases, a single network and protocol cannot be used between a field device 102 and a process controller 114 due to speed and flexibility on one hand and ruggedness, addressability and data integrity on the other. The Fieldbus boards 104a-n provide local instruction and monitoring services, data conversion and protocol translation between the separate data networks. However, each Fieldbus board carries an overhead in power supply electronics, protocol converters, memory and processor.
A simplified and representative block diagram of a remote processing and protocol conversion interface module for use in a process control system is illustrated in
The controller 320 comprises a communication interface 322 to couple the field device ports 302a-b to a plurality of transducer blocks 324. The transducer blocks 324, in turn are coupled to analog blocks 326. Together, one of transducer blocks 324 and a respective one of the analog blocks 326 make up one of the plurality of process function modules 328.
The communication interface 322 manages the routing of data between the field device ports 302a-b and the appropriate one of the transducer blocks 324. The transducer blocks 324 are defined by the HSE standard as having custom functions. For example, transducer blocks 324 are required for instrumentation and are specific to the measurement being taken. Examples of instrumentation are pressure and temperature. In an exemplary embodiment, the field device 102a may supply a pulse-coded reading that corresponds to temperature, the reading formatted for transmission over a CAN protocol network 308. The port 302a can receive and process the CAN signal where the interface module 322 is operable to convert and route the signal to a transducer block 324 assigned to that particular field device 102a. The transducer block 324 converts the data into a measurement using an method adapted to that type of field device 102a. The measurement, now converted to a raw temperature, is passed to the corresponding analog block 326. That analog block operates to convert the raw temperature reading to a generic format, defined by the applicable standard, usable for process control, for example, degrees Celsius. When all the conversion and processing is complete, the data is passed to the port 316 where it is passed through a protocol stack for transmission to the process controller 114.
In general, a field device 102a-n may supply a raw digital signal, requiring conversion to a reading. Another of many possible functions performed in the transducer blocks 324 is scaling and formatting of readings not requiring data conversion. The analog blocks 326 are standard modules and may be configured as inputs or outputs. The analog blocks 326 take any measurement and convert it to an appropriate generic format for use in a control strategy. The analog blocks 326 may also implement a control strategy or perform other process functions. The analog blocks 326 are coupled to the port 316 where protocol conversion, formatting, and low-level communication stack functions are implemented.
In operation, the controller 320 is programmed to receive data communicated on the first network 308 from each of the plurality of field devices 102a-b via the first port 302a. The controller 320 implements a plurality of transducer blocks 324 and analog blocks 326, in combination forming process function modules 328. Each of the process function modules 328 is assigned to one of the field devices 102a-n and is adapted to perform process control functions, for example data translation, limit checking, alarm management, scheduled health queries, etc. The plurality of transaction blocks 324 and analog blocks 326 process the data according to programming specific to the type and function of its respective field device. In one embodiment at least one of the plurality of process function modules 328, that is a transducer/analog block pair, is programmed to process CAN commands received at the first port 302a. The process function modules 328 create processed data for use in the second network 318 and transmit the processed data to the second network 318 via the second network port 316 using a second protocol, for example, HSE.
The controller 320 can be programmed to supply diagnostic data not only regarding the plurality of field devices 102a-n, but also to report diagnostic data about the interface module 200 itself. These diagnostic reports can be made to an upstream process controller 114 or process monitor (not depicted). The controller 320 can be further programmed to implement electronic mail services. The controller 320 can send operational data, including alarm messages about either the interface module 200 or one of the plurality of field modules 102a-n via an email message sent via the port 316. Recipients for such an email message could be on-call maintenance personnel, engineers, or other plant managers as well as computers or controllers (not depicted) adapted to process email notifications.
The first network 308, for communication with the field devices 102a-n may be a CAN network, a HART network, a MODbus network, a 4-20 ma network among others, wherein the corresponding one of the process function modules 328 is adapted to decode that protocol. The second network can be an HSE network; or other network supporting Internet Protocol (IP) packets.
The interface module 200 may be programmed remotely by a message from the process controller 114 or another network device. Such programming messages may be received via an Internet Protocol message or other supported protocol.
The components for building the interface module are known and available. Integrated circuits supporting major protocols are available from commercial suppliers. Similarly, the controller is or may include one or more microprocessors from commercial semiconductor companies and be programmed in a language suitable to the application. For example, highly time critical control applications may be programmed in assembler, whereas less critical monitoring functions may be programmed in ‘C’. Where power operation is desired, custom or semi-custom integrated circuit may be used. The translation of functions between software and logic is known to those of ordinary skill in the art.
The ability to connect multiple field devices to single interface module 200 and implement multiple process function modules 328 for each specific field device brings a new level of sophistication to distributed process control. Enhanced messaging, repurposing and remote reprogramability are combined in an interface module capable of supporting a variety of field devices and network protocols.
Various embodiments of methods and apparatus for managing field devices by a remote processing and protocol conversion interface module have been discussed and described. It is expected that these embodiments or others in accordance with the present invention will have application to many kinds of process control situations where an operator user may wish to manage multiple field devices but lower cost and increase maintainability. Using the principles and concepts disclosed herein advantageously allows or provides for improved process control as well as improved accessibility for programming and alarm notification.