Patent Application
20080080395
Although the following describes example apparatus and systems including, among other components, software and/or firmware executed on hardware, it should be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components could be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Accordingly, while the following describes example apparatus and systems, persons of ordinary skill in the art will readily appreciate that the examples provided are not the only way to implement such apparatus and systems.
As used herein the phrase “input/output device” (i.e., “I/O device”) includes any hardware and/or software used to communicatively couple one or more field devices to a process controller. In some implementations, the I/O device may be a separate card (i.e., an I/O card) that is coupled to the controller via a bus. In other implementations, some or all of the functionality of the I/O device may be integral with the controller. Thus, the phrases “I/O device” and “I/O card” may be used interchangeably throughout the description provided herein.
Typically I/O devices or cards are programmed or configured so that a process controller may communicate with field devices via a single specified communications protocol. These known I/O cards enable communication with a plurality of field devices that use the specified protocol. If it is desired to enable the controller to communicate with a variety of field devices that use different communication protocols, a separate I/O card is typically required for each of the different communication protocols used. However, this can significantly increase the costs associated with installation, configuration, operation and maintenance of a system in which a variety of communication protocols are used to communicate with a plurality of different field devices.
In some such systems, for example, utilization of the I/O device(s) and/or the I/O cards may be relatively low such that each of a number of I/O cards may be needed to communicate with relatively few field devices that use a particular communications protocol. In other words, while each I/O card may have the capability to communicate with a much larger number of field devices, a much smaller number of field devices is actually in communication with each I/O card because a separate I/O card is used for each type of communications protocol used by the field devices. Further, adding and/or replacing one or more field devices with one or more field devices that use a communications protocol that is different than any of those supported by the I/O cards in an I/O device requires the installation and configuration of yet another I/O card to support that further communications protocol.
Unlike known systems and methods, the example systems and methods described herein may be used to communicatively couple a controller to one or more field devices using a variety of protocols via a single I/O device or card. More specifically, as described herein, an example process control system that may be used to control a plurality of field devices includes an I/O device or card that has a master or communications protocol component. The communications protocol component includes a plurality of reconfigurable components, each of which corresponds to an I/O port. Each reconfigurable component is configurable to use one of a plurality of communication protocols depending on the specification of the associated field device with which the controller communicates via that I/O port. Thus, in this manner, different communication protocols may be used simultaneously to communicate with different field devices via the same I/O card or device. When it is desirable to change the field device(s) coupled to an I/O port, the reconfigurable component associated with the I/O port may be, if needed, reconfigured to use a different communications protocol to communicate with the new field device(s). Thus, the communications protocol is selectable within the I/O device or card on a per connection (e.g., I/O port) basis. As a result, the I/O device or card provides flexibility to the process control system in that many field devices that communicate via a plurality of different communication protocols may be coupled to the process control system via a single I/O device or card.
The reconfigurable components of the communications protocol component may be configured using a configuration application that is associated with the process control system. The configuration application may be created using one (i.e., a single) tool, such as an application configured to be executed via a workstation. In addition, the configuration application may provide beneficial attributes, including that it is incorporated within an object-oriented database and is self-documenting. The configuration application may also provide information related to the sensing of the field devices by an I/O device or card, may be configured to assign and/or clear address assignments of the field devices, and may be configured to use a device definition to describe an input, an output, or a parameter associated with a particular field device. Still further, the configuration application may be configured to generate signal tags with labels related to the device definition, may be configured to generate device alerts on a per field device basis for any one of a plurality of communication protocols used to communicate with the field devices, and may support pass-through communications from a workstation-based device configuration application. Additionally, a handheld configuration tool may be used to assign addresses to the field devices.
Now turning to
The operator station 14 includes a memory 26 for storing a process control configuration system 52, which is alternatively referred to as a process control configuration routine, application or tool 52 as is described in greater detail below in connection with
The operator station 14 may also include a process control configuration database 18 to store the process control configuration information used by the configuration tool 52. The database 18 may be stored in the memory 26 or in any other desired memory communicatively coupled to the process control system 10.
The controller 12 may be coupled to a plurality of smart field devices 22 via a plurality of communication links or channels 28, which may be implemented as digital data buses, and the I/O card or device 30, which may be referred to as a flexible I/O device, card or interface card. As described in greater detail in connection with
In addition to coupling various I/O devices 30, which are configurable to use different combinations of communication protocols, to the controller 12, the example I/O device 30 and any additional I/O device(s) may also communicate via the communication channels 28 using any variety and/or combination of the communication protocols named herein, and/or any other known or later developed communication protocols.
Thus, the flexible I/O device 30 enables the mixing and matching of field devices, which may be made by different manufacturers and/or which employ different communication protocols, on the ports, connections or communication channels of the I/O device 30. Such flexibility may enable an optimum implementation (e.g., selection of a combination of field devices based on the performance/cost characteristics of the devices rather than having to select devices that all use a single communications protocol) and the ability to readily replace one or more of the field devices 22 with field devices that communicate via different communication protocol(s) without incurring additional cost or needing to install different or additional I/O devices. For example, the flexible I/O device 30 could be configured to simultaneously that support Honeywell DE protocol on several channels or ports and the HART® protocol on other channels or ports. Similarly, the I/O device 30 could be configured to simultaneously support the Foxboro FoxCom® protocol on several channels or ports and the HART® protocol on other channels or ports. Furthermore, the example process system 10 allows for the use of analog communications (e.g., Analog 4-20 mA) with the field devices 22 if desired, as well as combination analog and digital communications if supported by the protocol that is implemented on one of the channels 28.
Furthermore, as mentioned above and described in greater detail below, in addition to supporting multiple communication protocols on different ones of the communication channels 28 or associated ports 48, the flexible I/O device 30 enables each of the communication channels 28 or ports 48 to be independently reconfigured. Thus, a communications channel 28 that is configured to use one communications protocol may later be programmed to use a second different communications protocol. Thus, when one of the field devices 22 fails, needs to be removed for maintenance, or is otherwise replaced, the failed field device may be decoupled or removed from the process control system 10, and a replacement field device may be coupled to the process control system 10 via the same communications channel 28, i.e., into the same port of the I/O device 30. In the case where the replacement field device 22 uses a communications protocol that is different than that used by the replaced, failed field device, the communications channel 28 via which the replacement field device communicates with the I/O device 30 can be reconfigured to use the communications protocol used by the replacement field device. For example, a system operator, configuration engineer or other user may use the configuration tool 52 to reconfigure the communications channel 28 to communicate with the replacement field device. The reconfiguration of any one of the communication channels 28 does not affect the operation of any other one of the communication channels 28.
In addition to the smart field devices 22, one or more non-smart field devices 32 and 34 may also be communicatively coupled to the controller 12. The non-smart field devices 32 and 34 may be, for example, conventional 4-20 mA or 0-10 VDC devices that communicate with the controller 12 via respective hardwired links 36 and 38.
The controller 12 may be, for example, a DeltaV™ controller sold by Fisher-Rosemount Systems, Inc. and Emerson Process Management™. However, any other controller may be used instead. Further, while only one controller is shown in
Furthermore, as discussed in greater detail below, in operation, the handheld configuration tool 50 may be used to assign addresses to the field devices 22. Typically, field devices 22 are provided by the manufacturer with a default address assigned thereto. Consequently two field devices (e.g., field devices 22a and 22b of
As described above, addresses may be assigned or reassigned to the field devices 22 at the time a field device 22 is added to the process control system 10, or at any other time desired. Assigning addresses to the field devices 22 may be performed offline, for example, with the handheld configuration tool 50, or automatically by the process control system 10 via, for example, the configuration tool 52 and the controller 12. The configuration tool 52 may also provide the capability to clear the address of any one of the field devices 22. The handheld configuration tool 50 may not be needed to assign/clear addresses because the process control system 10 and, specifically, the configuration tool 52, may clear and/or assign addresses to the field devices 22. However, as described above, the handheld configuration tool 50 also facilitates field operations such as, for example, routine maintenance, troubleshooting or repair.
The address of a field device is incorporated into a signal tag, which may be generated by the configuration tool 52 for use with valid inputs and outputs. Thus, the signal tag for a field device may include an address such as, for example, “T101.” In addition, the signal tag may include a label. The label is a descriptive term or phrase by which the operator or configuration engineer, maintenance personal, or other user can readily identify the type of device, a specific device, or a type of measurement or reading made by a device associated with the signal. Thus, a label may read, for example, “Boiler Feedwater Temperature.” Furthermore, the signal tags may also include definitions associated with the field devices 22. These device definitions provide additional information about a field device. For example, the device definitions may describe at least an input, an output and a parameter associated with each of the particular field devices 22. Such device definitions can be imported into the configurations database 18 in a bulk format, or the user can create device definitions from product descriptions as each of the field device 22 is added to the system 10 or at any other time. Cues, prompts, etc. to facilitate the creation or generation of the device definitions, i.e., defining the inputs, outputs, and parameters, may be provided to the user via the operator station 14 based on the communications profile of the field devices 22, which includes the communication protocol(s) needed to communicate with the field devices 22. Additionally, the configuration tool 52 may use the device definitions to describe the inputs, outputs, and parameters of the field devices 22. The use of such device definitions eliminates user configuration errors. Also, the example process control system 10 may provide a hierarchical view of the network devices based, at least in part, upon the signal tags, i.e., the defined inputs and outputs, the labels and the device definitions. The hierarchical view may be generated automatically.
The example systems and methods described herein also offer other benefits. For example, a user may be alerted to various states or operating conditions of a particular field device on a per device basis, regardless of the communications protocol used to communicate with the device. For example if a certain parameter measured by a field device reaches an unsafe level, the operator may be alerted of the state of the field device and/or of what specific actions to take. In addition, the operator may be alerted to the absence of a field device. For example, during configuration, which is described in greater detail below, an operator may expect a response from a particular field device after sending the field device a specific message. When the expected response is not received by the operator, the operator may be alerted that the field device has failed, is not configured correctly so the field device does not understand the communication, or is otherwise absent or not available.
Further, the system 10 supports pass-through communications from a workstation-based device configuration application. One such example application is the Asset Management Solutions (AMS®) series of software programs provided by Fisher-Rosemount Systems, Inc. and Emerson Process Management™, which provides support to personnel at a manufacturing plant implementing the example process control system 10 in various areas including device configuration, calibration and diagnosis of equipment problems. This allows for device configuration and management such as, for example, changes in the field devices 22, to be handled regardless of the implementation of the host process control system.
The example process control system 10 may also support other digital communication networks in place of analog networks (i.e., for example, those using the 4-20 mA analog signal). Such networks may be digital, bi-directional, multidrop, serial-bus, communications networks used to link isolated field devices, such as controllers, transducers, actuators and sensors, These networks may include, for example, Profibus PA. These other networks may be supported on a per channel basis to allow for easier migration of field devices to these high speed, all digital communication protocols. The methodology may also be extended to remote terminal units (RTUs) or stand alone controllers such as Fisher Remote Operations Controllers (ROCs), which are general-purpose RTUs designed for a variety of measurement and control applications, or similar devices.
Now turning to
The example I/O device 30 includes a controller interface 40, via which the I/O device 30 communicates with the controller 12, a processor 42 and a memory 44, which operate similarly to the processor 16 and the memory 26 illustrated in and described in connection with
While four reconfigurable communication ports or modules (i.e., 46a-n) and four corresponding communication channels or links (i.e., 28a-n) are shown, more or fewer reconfigurable communication ports or modules and communication channels or links may be used instead. Additionally, multiple I/O devices or cards similar or identical to the I/O device 30 may be coupled to the controller 12 and/or multiple field devices may be coupled to each or any combination of the communication channels 28a-n.
As described in greater detail below, when one of the field devices 22 is coupled to the I/O device 30 via one of the communication channels 28a-n, communication ports 48a-n and modules 46a-n, the configuration tool 52 may be used to configure or reconfigure the one of the modules 46a-n to which the field device 22 is coupled to use the communications protocol used by that field device 22, thereby enabling the controller 12 to communicate with the field device 22.
The configuration tool 52 may provide a single or integrated software tool that enables configuration of the communications protocol component 24, including the configurable communications modules 46a-n contained therein. Further, the configuration tool 52 may be an intuitive application running on one or more workstations, such as the operator station 14 (described above). More specifically, the configuration tool 52 may, for example, be implemented as a software program for use on a personal computer similar to the aforementioned AMS® software. The configuration of the process control system 10 (
As mentioned above, the configuration of the network 20 may be displayed as an easily understood hierarchy, and the configuration application 52 is self-documenting. Because the configuration of the network 20 is self-documenting, information related to the process control system 10 is readily available to the user and does not need to be translated when used by different views or divisions (i.e., maintenance, operations, etc.). For example, in some known systems, an operator configuring a communications channel for a particular field device may analyze the field device and consult secondary materials such as a workbook to determine what communications protocol to use to communicate with the field device as well as to access a variety of other information such as, for example, maintenance records for the device etc.
The example process control system 10 is self-documenting and, thus, each of the field devices 22 is adapted to provide information about itself via the communication channels or links 28. As a result, the field devices 22 may be accessed directly or auto-sensed when an auto-sense mechanism is integrated with the configuration application or tool 52 (as described below with
As shown in
The configuration application 52 also includes a series of generators 60, 62 and 64. In particular, a definition generator 60 generates device definitions using product descriptions, which may be information imported by the importer 58. A tag generator 62 generates signal tags with labels that relate to the device definitions. Finally, an alert generator 64 generates alerts for one or more of the field devices 22 based upon the operational states of the relevant field devices 22. The device alerts may be generated on a per field device basis.
The configuration tool 52 also includes several other components including, without limitation, a redundancy manager 66 that may be used to support redundant I/O devices 30 and a passthrough communications manager 68, which enables the operator or field engineer to manage various aspects of the process control system 10 including device configuration and management, regardless of the implementation of the host process control system 10.
As shown in
When, after sending a communication over the selected communications channel 28 with the selected communications protocol, the configuration tool 52 or operator does not receive a response (block 74), the configuration tool 52 or operator determines if a response was expected for that communications channel 28 (block 80). If a response was expected, i.e., the configuration tool 52 or the operator had pre-knowledge or information that a field device is (or should be) coupled to that communications channel 28 and, thus, expected to receive a response from that field device, the configuration tool 52 or operator can confirm that no field device is coupled to that communications channel 28 or that the field device 22 coupled thereto, if any, does not use the chosen communications protocol. Consequently, the configuration tool 52 or operator can begin the process again to either attempt configuration of a different communications channel 28 or attempt configuration of the same communications channel 28 again but with a different communications protocol (block 78).
If the configuration tool 52 or operator expected to receive a response over the communications channel 28 upon sending a message over the communications channel 28 using the communications protocol (block 80), then the configuration tool 52 or the operator expected a field device 22 to be coupled to that communications channel 28 that uses the selected communications protocol. This situation may lead to the generation of an alert (discussed above) to indicate that the results are not as expected. Also, this situation may indicate that there is no field device coupled to that communications channel 28 or, alternatively, if there is a field device 22 coupled thereto, that the field device 22 uses a communications protocol to communicate different than the communications protocol that was used to communicate over that communications channel 28 at block 74.
In addition, the configuration tool 52 or the operator may attempt configuration of the same communications channel 28 with the same protocol again (block 82) any number of times, for instance, until a desirable result (e.g., a field device response) is received. Alternatively, the configuration tool 52 or the operator can select another communications protocol (block 84) to use to communicate over the communications channel 28 to determine if a field device coupled to that communications channel 28 uses another communications protocol to communicate. Upon trying the same communications channel 28 with another communications protocol (block 84), the process begins again (block 70).
If a response has been received (block 94), then the configuration tool 52 determines that the field device coupled to the communications channel (a) uses the communications protocol (x), and the configuration tool 52 configures the communications channel (a) for that communications protocol (x) (block 96). Upon configuration of the communications channel (a), the configuration tool 52 determines if there are more communication channels to configure (block 98). If there are no more communication channels to configure, the process 86 ends and/or returns to a calling process or routine (block 102).
On the other hand, if there are more communication channels to configure, then the configuration tool 52 proceeds to configure another communications channel, for example, communications channel a+1 (block 100) by choosing a communications protocol for that communications channel (a+1) (block 90) and sending a communication via the communications channel (a+1) using the communications protocol (x) (block 92). As stated above, the configuration tool 52 then determines if a response has been received (block 94).
If, after sending a communication over the communications channel (a), a response is not received at block 94, the configuration tool 52 determines if the most recent attempt at obtaining a response over the communications channel (a) using the communications protocol (x) is greater than or equal to or less than a pre-set number (n) of attempts (block 104). If the most recent attempt is less than the pre-set number (n) of attempts, then the attempt counter will increment by 1 (block 106), and the configuration tool 52 will again attempt to obtain a response by sending a communication via the communications channel (a) using the communications protocol (x) (block 92). However, if the attempt at communicating via the communications channel (a) using the communications protocol (x) is greater than or equal to the pre-set number (n) of allotted attempts (block 104), the configuration tool 52 will abort attempts at communicating via the communications channel (a) using the communications protocol (x). Typically, the attempt counter will not surpass the pre-set number (n). However, in the event of a system override or other disruption that may cause the configuration tool 52 to attempt communication n+1 or more times, the configuration tool 52 has the ability to abort attempting to configure the same communications channel using the same communications protocol when there has been no response.
After attempting communication to the communications channel (a) using the communications protocol (x) at least n times, the configuration tool 52 determines if there are more communication protocols to try (block 108) because the field device coupled to the communications channel (a) may use a communications protocol other than the communications protocol (x). If there are more communications protocols to try, the configuration tool 52 selects another communications protocol, for example communications protocol x+1 (block 110) and again sends a communication via the communications channel (a) using the different communications protocol (x+1). The configuration tool 52 may repeat this process for any number of communication protocols. If, after attempting communication via the communications channel (a) using the communications protocol (x) at least n times and determining that there are no more communication protocols to try (block 108), the configuration tool 52 determines if there are more communication channels to configure (block 98). If there are no more communication channels to configure, as stated above, the process 86 ends or returns to a calling process or routine (block 102). If there are more communication channels to configure, then the configuration tool 52 proceeds to configure another communications channel, for example, communications channel a+1 (block 100) by choosing a communications protocol for that communications channel (a+1) (block 90), sending a communication via the communications channel (a+1) using the communications protocol (x) (block 92) and proceeding through the process 86.
The methods described in
The processor 212 of
The system memory 224 may include any desired type of volatile and/or non-volatile memory such as, for example, static random access memory (“SRAM”), dynamic random access memory (“DRAM”), flash memory, read-only memory (“ROM”), etc. The mass storage memory 225 may include any desired type of mass storage device including hard disk drives, optical drives, tape storage devices, etc.
The I/O controller 222 performs functions that enable the processor 212 to communicate with peripheral input/output (“I/O”) devices 226 and 228 and a network interface 230 via an I/O bus 232. The I/O devices 226 and 228 may be any desired type of I/O device such as, for example, a keyboard, a video display or monitor, a mouse, etc. The network interface 230 may be, for example, an Ethernet device, an asynchronous transfer mode (“ATM”) device, an 802.11 device, a DSL modem, a cable modem, a cellular modem, etc. that enables the processor system 210 to communicate with another processor system.
While the memory controller 220 and the I/O controller 222 are depicted in
Although certain example methods, apparatus and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.
