Transparent support of remote I/O in a process control system

[0002] The invention relates generally to process control systems and, more specifically, to a system and method for automatically configuring a remote input/output (I/O) communication link in a process control system.

[0003] Modern process control systems are typically microprocessor-based distributed control systems (DCSs). A traditional DCS configuration includes one or more user interface devices, such as workstations, connected by a databus (e.g., Ethernet) to one or more controllers. The controllers are generally physically close to a controlled process and are in communication with numerous electronic monitoring devices and field devices such as electronic sensors, transmitters, current-to-pressure transducers, valve positioners, etc. that are located throughout the process.

[0004] In a traditional DCS, control tasks are distributed by providing a control algorithm within each of the controllers. The controllers independently execute the control algorithms to control the field devices coupled to the controllers. This decentralization of control tasks provides greater overall system flexibility. For example, if a user desires to add a new process or part of a process to the DCS, the user can add an additional controller (having an appropriate control algorithm) connected to appropriate sensors, actuators, etc. Alternatively, if the user desires to modify an existing process, new control parameters or control algorithms may, for example, be downloaded from a user interface to an appropriate controller via the databus.

[0005] To provide for improved modularity and inter-manufacturer compatibility, process controls manufacturers have more recently moved toward even further decentralization of control within a process. These more recent approaches are based on “smart” field devices that communicate using an open protocol such as the HART®, PROFIBUS®, WORLDFLIP®, Device-Net®, CAN, and FIELDBUS® protocols. These smart field devices are essentially microprocessor-based devices such as sensors, actuators, etc. that, in some cases, such as with Fieldbus devices, also perform control loop functions traditionally executed by a DCS controller. Because some smart field devices provide control capability and communicate using an open protocol, field devices from a variety of manufacturers can communicate with one another on a common digital databus and can interoperate to execute a control loop without the intervention of a traditional DCS controller.

[0006] In conventional process control systems, field devices may be connected directly to a controller or, alternatively, may be connected to one or more I/O devices that are communicatively coupled to the controller via a databus. Generally speaking, these I/O devices process analog and/or digital information provided by the field devices and send the processed information as digital messages containing control signals, device information, etc. to the controller over the controller databus. Additionally, the controller can send digital messages containing configuration information, commands, etc. over the controller databus to the I/O devices. The digital messages sent by the controller to the I/O devices may be used to change the manner in which the I/O devices process signals received from the field devices and/or may be used to send signals to the field devices. Traditional I/O devices send and receive analog and digital signals, such as 4-20 mA, 0-10 VDC, dry contact closures, etc., to and from standard field devices. More recently, however, linking or bridge I/O devices have become available that enable a network of smart field devices, such as the Fieldbus devices discussed above, to communicate with the controller using digital messages via the controller databus.

[0007] In practice, I/O devices are typically located physically close to the field devices to which they are connected and may reside on a common mounting rail that facilitates their connection to a power source and to the controller databus. Thus, in applications where some of the field devices are physically remote from the locus of the process control system, it becomes desirable to locate some of the I/O devices so that these I/O devices are close to the remotely situated field devices. However, simply extending the controller databus to connect with remotely situated or remote I/O devices presents significant difficulties because the controller databus is typically not suitable for reliable communications over the required distance to the remote I/O devices.

[0008] A variety of well-known communication media (e.g., wireless, fiber optic, coaxial cable, etc.) and communication protocols (e.g., High Speed Ethernet) are available for long distance communications and, generally speaking, can provide a reliable remote communication link between remote I/O devices and a controller. While these known techniques for accomplishing remote communications may allow controllers to communicate with remote I/O devices (and the field devices associated with the remote I/O devices), they do not allow a seamless integration of the remote I/O devices within a process control system. For example, because the controller databus and the communication link to the remote I/O devices typically use different media and/or different communication protocols, the controller may communicate with the remote I/O devices via a remote I/O interface device that requires intensive manual integration by the user.

[0009] The integration of the remote I/O interface may involve a device-by-device configuration requiring the user to manually define and instantiate complex communication links for routing information between the controller and the remote I/O devices via the remote I/O communication link. As a result, the system user must be proficient with the particular communication configuration attributes associated with the local I/O devices and must additionally be proficient with the particular communication configuration attributes of the remote I/O interface device, which may be remarkably different from the communication configuration attributes of the local I/O devices. This intensive manual integration of remote I/O devices is undesirable because the “look and feel” of the system is inconsistent when the user attempts to incorporate remote I/O devices into a control loop of a local controller. For example, a graphical interface may allow a user to associate icons representing devices to establish connections (e.g., using a mouse or any other conventional computer-based pointing device) in a control loop between local I/O devices, but may require the user to define control loop connections to remote I/O devices using a completely different method, such as, for example, entering a series of textual commands via a keyboard connected to the user interface.

[0010] The system and method described herein enables the seamless integration of remotely situated I/O devices within a process control system. Generally speaking, the system and method automatically configures a remote I/O interface device at each end of a remote I/O communication link so that all communication activities (e.g., configuration, runtime reporting, user requests for information via the user interface, etc.) with the remote I/O devices over the remote I/O communication link appear to be transparent from the perspective of a user at a user interface and a controller that is communicating over the remote I/O communication link.

[0011] More specifically, the system and method automatically establishes communication objects in the pair of remote I/O interface devices situated at respective ends of the remote I/O communication link. In particular, a local communication object is established in the remote I/O interface which is connected to the controller and a remote communication object is established in the remote I/O interface which is connected to the remote I/O devices. The communication objects provide communication links that enable the routing of communications between the controller and the remote I/O devices via the remote I/O communication link.

[0012] One particularly interesting aspect of the system and method described herein is that the user can interact at the system level through a graphic interface running on the user interface, for example, to configure control loops, monitor process parameters, etc. associated with a combination of local and remote I/O devices, which may be communicating using one or more communication technologies (i.e., media and/or protocols), without having to understand, or even be aware of, the underlying communication technologies. In other words, the system and method described herein insulates the user from the implementation details of the underlying remote I/O communication technologies by automatically generating and instantiating appropriate communication objects (e.g., the local and remote communication objects) within the remote I/O interface devices in response to the user requesting a control loop connection to a remote I/O device. In one embodiment, the system and method automatically recognizes that the user has requested communications (e.g., via a control loop connection) with a remote I/O device that requires communications via the remote I/O communication link, creates communication objects to enable and carry out these remote communications, and loads these communication objects in the appropriate I/O devices during configuration to provide the communications specified by the user. As a result, the user only needs to understand how to use the graphical interface, for example, to interact with the control system and the user's interaction with the system has a consistent look and feel regardless of whether or not the user has specified a connection to a remote or to a local I/O device and regardless of the underlying communication technologies being used to accomplish the remote I/O communications.

[0013] In accordance with one aspect of the invention, a method of configuring a communication link for use in a distributed process control system having a controller, a first remote I/O interface communicatively coupled to the controller and a remote I/O communication link, a second remote I/O interface communicatively coupled to the remote I/O communication link, and an I/O device communicatively coupled to the second remote I/O interface, specifies a connection between the controller and the I/O device. The method may recognize that the remote connection requires communications over the remote I/O communication link and automatically generate a first communication object that automatically routes communications between the controller and the remote I/O communication link and may also automatically generate a second communication object that automatically routes communications between the remote I/O communication link and the I/O device.

[0014] The method may further automatically generate the first communication object so that the first communication object receives communications having a first signal protocol and converts the communications to be sent using a second signal protocol and may generate the second communication object so that the second communication object receives communications having the second signal protocol and converts the communications to be sent using the first signal protocol.

[0015] FIG. 1 is a schematic block diagram illustrating a process control system having a controller that is communicatively coupled to remote I/O devices via a remote communication link;

[0016] FIG. 2 is an exemplary block diagram illustrating communication objects that enable automatic communications between the controller and the remote I/O devices of FIG. 1;

[0017] FIG. 3 is an exemplary flow diagram depicting one method of generating and instantiating the communication objects of FIG. 2;

[0018] FIG. 4 is an exemplary flow diagram depicting one method by which information is sent from the remote I/O devices to the controller using the communication objects of FIG. 2;

[0019] FIG. 5 is an exemplary flow diagram depicting one method by which information is sent from the controller to the remote I/O devices using the communication objects of FIG. 2;

[0020] FIG. 6 is a schematic block diagram illustrating a graphical interface that may be used to configure control loops within the process control system of FIG. 1;

[0021] FIG. 7 is a schematic block diagram illustrating autosense routines that may be used in the remote I/O interfaces to enable the automatic detection of and communication with the remote I/O devices of FIG. 1; and

[0022] FIG. 8 is an exemplary flow diagram depicting one method of establishing the autosense routines of FIG. 7.

[0023] While a system and method for automatically configuring a remote I/O communication link and carrying out communications with remotely situated input/output (I/O) devices over the remote I/O communication link is described in detail in conjunction with a particular process control system, it should be understood that the system and method described herein can be advantageously used within a variety of process control systems having a remote I/O communication link that uses any of a variety of communications media such as wireless/spread spectrum, fiber optic, etc. and communication protocols such as Fieldbus, AS-Interface, Profibus, DeviceNet, etc.

[0024] FIG. 1 is a schematic block diagram illustrating a process control system 10 having a controller 12 that is communicatively coupled to remote I/O devices 14 and 16 via a remote I/O communication link 18. The control system 10 includes a user interface 20, which may be a workstation, that is connected in a communication network to the controller 12 via a system level databus 22. The system level databus 22 may be a standard Ethernet databus or any other databus suitable for the transmission of data. The controller 12 may be a DCS controller and may communicate with the user interface 20 using a proprietary communication protocol, or in any other suitable manner, via the system level databus 22. For example, the controller 12 may send alarm and status information to the user interface 20 and may additionally receive user commands/requests from the user interface 20 via the system level databus 22. The controller 12 may further include control algorithms for use in controlling field devices that are connected to the controller 12 in any conventional or any other desired manner.

[0025] By way of example, the controller 12 is in communication with I/O devices 24 and 26 via a controller databus 28 which typically uses a proprietary signal protocol. The I/O device 24 may function as a communication bridge or a linking device to smart field devices 30 and 32 that are communicatively coupled to one another and to the I/O device 24 via a non-proprietary protocol databus 34. The smart field devices 30 and 32 may be, for example, Fieldbus devices and, accordingly, the non-proprietary protocol databus 34 may use the Fieldbus signal protocol. As is well-known, the smart field devices 30 and 32 may be configured to execute one or more process control loops either in conjunction with or independently from the controller 12. However, other types of devices and protocols could be used without departing from the scope of the invention. In contrast, the I/O device 26 may be a standard I/O device, such as an analog input (AI) card, analog output (AO) card, etc., that communicates via wires 36 and 38 to respective conventional field devices 40 and 42.

[0026] The controller 12 is also in communication with a remote I/O host interface 44 that allows the controller 12 to communicate transparently with the remote I/O devices 14 and 16 via the remote communication link 18. More specifically, the remote I/O interface 44 communicates with the controller 12 over the controller databus 28 using the appropriate proprietary signal protocol and sends/receives information over the remote communication link 18 to/from a remote communication interface 46 using a conventional remote communications signal protocol (e.g., High Speed Ethernet), which is typically different than the proprietary signal protocol of the controller databus 28. Similarly, the remote communication interface 46 sends and receives signals over the remote I/O communication link 18 using the conventional remote communications signal protocol and routes these signals to and from the remote I/O devices 14 and 16 through a remote databus 48 that may use a proprietary signal protocol. In fact, this proprietary signal protocol may be the same protocol as the signal protocol that is used on the controller databus 28.

[0027] In particular, the remote I/O host interface 44 communicates with the controller 12 over the controller databus 28 using the proprietary signal protocol that is used on the controller databus 28 and processes (i.e., converts) these communications using communication objects (which are discussed in more detail below) to send the processed communications over the remote I/O communication link 18 using the conventional remote signal communications protocol. Likewise, the remote I/O communication interface 46 converts communications, using communication objects, on the remote I/O communication link 18 to send the communications over the remote databus 48 using the same proprietary signal protocol that is used on the controller databus 28. Thus, the remote I/O communication interfaces 44 and 46 (together with the communication objects) perform a signal protocol conversion/de-conversion at respective ends of the remote I/O communication link 18 so that the signal protocol used on the remote I/O communication link 18 is transparent to the controller 12 that may be, for example, communicating over the link 18 with one of the remote I/O devices 14 and 16. In fact, the controller 12 can communicate with one or more of the I/O devices 14 and 16 as if the I/O devices 14 and 16 are communicating directly on the controller databus 28. Additionally, the remote communication interface 46 and the remote I/O devices 14 and 16 may be mounted in a remote I/O carrier 50 that facilitates the mechanical mounting of the remote communication interface 46 and the remote I/O devices 14 and 16 and which facilitates the electrical connections of the I/O devices 14 and 16 to the remote communication interface 46 and to the field devices 52-58.

[0028] FIG. 2 is an exemplary block diagram illustrating a local communication object 70 and a remote communication object 72 that enable transparent communications between the controller 12 and the remote I/O devices 14 and 16 of FIG. 1. Generally speaking, the communication objects 70 and 72 cooperate to provide the communication links needed to transmit information between the remote I/O devices 14 and 16 and the controller 12 via the remote I/O communication link 18. More specifically, the local communication object 70 allows information to be transmitted between the controller databus 28 and the remote I/O communication link 18 and the remote communication object 72 allows the remote I/O communication interface 46 to transmit information between the remote communication link 18 and the remote databus 48. For example, the controller 12 may be configured to periodically publish control information to the remote I/O host interface 44 via the controller databus 28 and the remote I/O host interface 44 uses the local communication object 70 to route this control information over the remote I/O communication link 18 to the remote I/O communication interface 46. The remote I/O communication interface 46 may then use the remote communication object 72 to periodically publish the control information to an appropriate one of the I/O devices 14 and 16 via the remote databus 48. Similarly, the controller 12 may be configured to subscribe to control information that is provided by one of the remote I/O devices 14 and 16 and, in that case, the remote I/O communication interface 46 is configured to periodically retrieve the control information needed by the controller 12 from one of the remote I/O devices 14 and 16 via the remote databus 48. The remote I/O communication interface 46 may then use the remote communication object 72 to send the control information over the remote communication link 18 to the remote I/O host interface 44. Upon receiving the control information from the remote I/O communication link 18, the remote I/O interface 44 uses the local communication object 70 to periodically publish the control information to the controller 12 via the controller databus 28.

[0029] As is generally known, communication objects, such as the communication objects 70 and 72, receive information in the form of digital messages and route these digital messages to destinations based on addresses or paths specified within the messages. For example, the local communication object 70 may receive a message which includes an address which fully specifies a routing or communication path over the remote I/O communication link 18, through the remote I/O communication interface 46, and to the I/O device 14. Thus, when the remote I/O host interface 44 receives and processes this message using the local communication object 70, the remote I/O host interface 44 will recognize that a portion of the address specified within the message indicates that the message is to be transmitted to the remote I/O communication interface 46 and then transmit the message over the remote I/O communication link 18 to the remote I/O communication interface 46. The remote I/O communication interface 46 receives the message and uses the remote communication object 72 to determine that another portion of the specified address indicates that the message is to be published to the I/O device 14. The remote I/O communication interface 46 then publishes the message on the remote databus 48 to be received by the remote I/O device 14.

[0030] The controller 12 may also include a remote I/O configuration routine 74 that automatically creates the communication objects 70 and 72 in response to the user specifying (via the user interface) a control loop connection, for example, to one or more of the remote I/O devices 14 and 16. Because the remote I/O configuration routine 74 automatically creates the communication objects 70 and 72, the user does not have to understand the particular communication attributes associated with the remote I/O communication link 18. Instead, the user only needs to specify the control loop connection to one of the remote I/O devices 14 and 16 and the remote I/O configuration routine 74 automatically recognizes that the connection specified by the user requires communications over the remote I/O communication link 18 and automatically sets up the appropriate communication objects 70 and 72 in the respective remote I/O interfaces 44 and 46. Although the automatic generation of the communication objects 70 and 72 has been discussed above within the context of the user specifying a control loop connection to one of the remote I/O devices 14 and 16, the communication objects 70 and 72 may be similarly generated during runtime, for example, in response to the user making a request for information provided by one of the remote I/O devices 14 and 16 via the user interface 20.

[0031] In particular, the controller 12 may execute a control loop 76 having an analog input (AI) block 78, a proportional-integral-derivative (PID) block 80, and an analog output (AO) block 82 which may be, for example, Fieldbus type function blocks. As shown, the AI block 78 provides an output 84 to the PID block 80, the PID block 80 provides an output 86 to the AO block 82, and the AO block 82 provides a feedback signal 88 to the PID block 80. If, for example, the AI block 78 is to receive its input from the I/O device 14, then the configuration routine 74 recognizes that the input needed from the I/O device 14 requires the controller 12 to communicate over the remote I/O communication link 18. As a result of recognizing that the input to the AI block 78 requires communications over the remote I/O communication link 18, the remote I/O configuration routine 74 automatically creates appropriate links by setting up the communication objects 70 and 72 to enable the information from the I/O device 14 to be routed through the remote I/O communication link 18 and the remote I/O interfaces 44 and 46 to the controller 12 on a periodic basis.

[0032] The controller 12 may also include function block update routines 90, a processor 92, and a memory 94. Generally speaking, the function block update routines 90 provide decoupling between the control process (which may be executed by the processor 92) associated with the control loop 76 and the communications over the controller databus 28. The function block update routines 90 may maintain a table or a list 96 that includes control information needed by or provided by the function blocks 78, 80 and 82. In this manner, the control loop 76 may be executed asynchronously with respect to the communications between the controller 12 and the remote I/O host interface 44. For example, while the remote I/O host interface 44 is publishing the information needed by the AI block 78 to the controller 12 via the controller databus 28, the function block update routines 90 may be retrieving the information needed by the block 78 from the list 96. Likewise, the function block update routines 90 may store information associated with the control loop 76 in the list 96 and this stored information may be published by the controller 12 on the databus 28. Thus, the function block update routines 90 and the control process 76 can independently access the list 96, thereby allowing the control process 76 and the communications on the controller databus 28 to operate asynchronously (i.e., decoupled) from one another so that execution of the control loop 76 is not interrupted or delayed by the communications on the controller databus 28.

[0033] FIG. 3 is an exemplary flow diagram depicting one method 100 of configuring the communication objects 70 and 72 of FIG. 2. In general, the method 100 of FIG. 3 enables the controller 12 to insulate the user from the communication technology associated with the remote I/O link 18. The method 100 automatically recognizes, during configuration, for example, when a control signal needed by the controller 12 requires communications over the remote I/O communication link 18 and automatically creates communication objects in both the remote I/O host interface 44 and the remote I/O communication interface 46 that enable these communications to occur in a transparent manner. Thus, the user, who may be, for example, configuring a control loop by interacting with a graphical interface program running on the user interface 20 does not have to understand or even be aware of the particular communication links and objects that are needed to accomplish the communications over the remote I/O communication link 18. Rather, the user may simply specify that information from the remote I/O devices 14 and 16 be exchanged with the controller 12 and the remote I/O configuration routine 74 sets up the appropriate communication objects 70 and 72 without requiring any further input from the user. In this manner, the user's interaction with the system 10 during configuration has a consistent look and feel because the user requests, at a high level (e.g., from the graphical interface), that the controller 12 exchange information with the remote I/O devices 14 and 16 and the remote I/O configuration routine 74 establishes (without any further input from the user) the local and remote communication objects 70 and 72 which enable the controller 12 to communicate with the remote I/O devices 14 and 16 to exchange the information as specified by the user or as needed to perform a control loop.

[0034] In particular, as shown in FIG. 3, block 102 downloads a control strategy to the controller 12 which may include one or more control loops, such as the control loop 76 shown in FIG. 2. Block 104 recognizes that an I/O signal for a function block is performed via the remote I/O communication link 18. For example, the AI block 78 (FIG. 2) may receive its input from one of the remote I/O devices 14 and 16. Recognizing that an I/O signal requires communications over the remote I/O communication link 18 may be accomplished, for example, by determining that an identifier such as a tag or address associated with an I/O device indicates that the device is a remote I/O device. Block 106 instructs the remote I/O host interface 44 to set up the appropriate local communication object 70 for the I/O signal (e.g., the input to the AI block 78) within the remote I/O host interface 44 and block 108 then uses the local communication object 70 to communicate over the remote I/O communication link 18 to set up the appropriate remote communication object 72 within the remote I/O communication interface 46.

[0035] FIG. 4 is an exemplary flow diagram depicting one method 120 by which information is sent from the remote I/O devices 14 and 16 to the controller 12 using the communication objects 70 and 72 of FIG. 2. In general, the method 120 uses the local communication object 70 and the remote communication object 72 to provide seamless or transparent communications between the controller 12 and the remote I/O devices 14 and 16. More specifically, the method 120 allows the remote I/O host interface 44 to use the local communication object 70 to route information published to the interface 44 via the controller databus 28 over the remote I/O communication link 18 and to publish information sent to the interface 44 over the remote I/O communication link 18 to the controller 12 via the controller databus 28. Likewise, the method 120 allows the remote I/O communication interface 46 to use the remote communication object 72 to route information sent to the interface 46 via the remote communication link 18 to one or more of the remote I/O devices 14 and 16 and to send information provided by the I/O devices 14 and 16 over the remote communication link 18 to the remote I/O communication interface 44.

[0036] In particular, as shown in FIG. 4, block 122 uses the local communication object 70 to cause the remote I/O host interface 44 to send updated parameters (e.g., signal information, function block information, device information, etc.) to the controller 12 via the controller databus 28. For example, the remote I/O host interface 44 may be configured to periodically send updated function block information, such as the input needed by the AI block 78, to the controller 12. Block 124 uses the local communication object 70 to cause the remote I/O host interface 44 to automatically communicate with the remote I/O communication interface 46 over the remote I/O communication link 18 to retrieve the information or parameters needed by the controller 12. These communications of the remote I/O host interface 44 are received by the remote I/O communication interface 46 and are routed within the remote I/O communication interface 46 using the remote communication object 72 to retrieve the information that is needed by the controller 12. Block 126 notifies the controller 12 of the presence of updated/changed parameters, which may include, for example, an updated input signal for the AI block 78 and block 128 causes the controller 12 to request that the remote I/O host interface 44 publish the updated/changed parameters on the controller databus 28. The controller 12 then receives and stores the published parameter data in the list 96 within the memory 94. Block 130 then uses the parameter data stored in the list 96 to execute the control process 76.

[0037] FIG. 5 is an exemplary flow diagram depicting one method 150 by which information is sent from the controller 12 to the I/O devices 14 and 16 using the communication objects 70 and 72 of FIG. 2. Generally speaking, the controller 12 may publish information to the remote I/O host interface 44 via the controller databus 28 and this information may be automatically routed over the remote I/O communication link 18 to one or more of the I/O devices 14 and 16. Also, generally, the controller 12 may be configured to periodically publish information and/or may be configured to publish information in response to requests for information from the user. More specifically, the remote I/O host interface 44 may use the local communication object 70 to automatically route information to the remote I/O communication interface 46 via the remote I/O communication link 18, and the remote I/O communication interface 46 may use the remote communication object 72 to automatically route the information to one or more of the I/O devices 14 and 16 via the remote databus 48.

[0038] In particular, as shown in FIG. 5, block 152 causes the controller 12 to send signals and/or commands over the controller databus 28 that are received by the local communication object 70. Block 154 then uses the local communication object 70 to automatically send the signals and/or commands over the remote I/O communication link 18 to the remote I/O communication interface 46 and block 156 uses the remote communication object 72 to route the signals and/or commands to an appropriate one of the I/O devices 14 and 16.

[0039] FIG. 6 is a schematic block diagram illustrating a graphical interface 160 that may be used to configure control loops within the process control system 10 of FIG. 1. Generally speaking, the graphical interface 160 typically runs within the user interface 20 and sends and receives information related to the configuration of the system 10 over the system level databus 22 to and from the controller 12 and/or other controllers and devices such as a configuration database (not shown) which may be connected to the system level databus 22. The graphical interface 160 provides an intuitive visual environment that allows the user to interactively specify control loops (i.e., specify relationships or connections between function blocks) within the process control system 10 and, at the request of the user, to download the appropriate configuration information to the controller 12 to instantiate the user specified control loops within the controller 12. For example, the controller 12 may use the downloaded configuration information to instantiate the process control loop 76 and may further use the configuration information together with the remote I/O configuration routine 74 to establish the communication objects 70 and 72 within the remote I/O interfaces 44 and 46 which, as described above, enable the control loop 76 to receive the control information needed by the AI block 78 from the remote I/O device 14 via the remote I/O communication link 18.

[0040] More specifically, the graphical user interface 160 includes a control loop graphic 162 representing the control loop currently being specified, which is shown by way of example FIG. 6 to be the control loop 76. The graphical user interface 160 also includes a system hierarchy graphic 164 representing the system topology or hardware relationships between the various devices making up the control system 10. In particular, the various levels shown in the system hierarchy graphic 164 may correspond to the various devices shown in FIG. 1. For example, a controller level 166 may correspond to the controller 12, an I/O level 168 may correspond to the group of I/O devices (e.g., I/O devices 24 and 26) that are connected to the controller databus 28, and a host interface level 170, which falls within the I/O level 168, may correspond to the remote I/O host interface 44. The host interface level 170 may further include a communication link level 172 that corresponds to the remote I/O communication link 18 and an I/O file level 174, which includes an I/O device level 176 corresponding to the remote I/O devices 14 and 16. Typically, the textual designators or “tags” used to label and identify each of the levels within the hierarchy graphic 164 are set to a system default which can be modified by the user via the user interface. For example, while the tag for the host interface level 170 may be set to a default “HOST INTERFACE,” as shown in FIG. 6, the user could change the tag via the user interface 20 to read “REMOTE I/O INTERFACE 1,” if desired.

[0041] The graphical user interface 160 allows the user to specify relationships or connections between the function blocks 78, 80 and 82 of the control loop 76 and the I/O devices 14, 16, 24 and 26. More specifically, the user can establish a connection by using a pointing device, such as a computer mouse, to browse the levels 166-176 of the hierarchy graphic 164 to form a relationship between one or more of the function blocks 78, 80 and 82 and an appropriate I/O device (e.g., a channel within an I/O card that is associated with a particular signal and field device). In particular, the user may associate the AI block 78 into the tag “I/O card 1” (within the I/O device level 176) to form a connection 178 between the I/O device 14 (which corresponds to the tag “I/O card 1”) and the input of the AI block 78. Likewise, the user may associate the AO block 82 into the tag “I/O card 2” (which corresponds to the I/O device 16) to form a connection 180 between the output of the AO block 82 and the I/O device 16.

[0042] While or after the user specifies the connections 178 and 180 between the control loop 76 and the remote I/O devices 14 and 16 (which are represented by the respective tags “I/O device 1” and “I/O device 2”) using the above-described procedure, the user interface 20 automatically creates the appropriate configuration information for downloading to the controller 12. This configuration information contains linking information that may be used by the remote I/O configuration routine 74 to create the communication objects 70 and 72 within the respective remote I/O devices 44 and 46, thereby enabling the above-described transparent communications between the controller 12 and the remote I/O devices 14 and 16.

[0043] While the connections 178 and 180 from the function blocks 78 and 82 to the remote I/O devices 14 and 16 require communications over the remote I/O communication link 18, the user may, generally speaking, specify function block connections to any combination of remote I/O devices that communicate via the remote I/O communication link 18 and local I/O devices (e.g., I/O devices 24 and 26) that communicate with the controller 12 via the controller databus 28. Additionally, the user may interact with the same graphical interface 160 in conjunction with the above-described technique to form connections between I/O devices and function blocks regardless of whether the connections are made to a remote I/O device or to a local I/O device. As a result, the user experiences a consistent look and feel at the user interface 20 regardless of which I/O devices are being connected to the control loop 76 and regardless of the technology and configuration attributes of the underlying the communications that are used to accomplish the connections.

[0044] A more detailed discussion of process control configuration routines which enable a user to graphically create process control routines and elements to auto-sense devices within a process control system and to provide control of devices within a process control system may be found in U.S. Pat. No. 5,838,563 to Dove et al. (“System for Configuring a Process Control Environment”), U.S. Pat. No. 5,828,851 to Nixon et al. (“Process Control System Using Standard Protocol Control of Standard Devices and Nonstandard Devices”), and U.S. patent application Ser. No. 08/631,458 to Dove (“System for Assisting Configuring a Process Control Environment”) filed Apr. 12, 1996, all of which are assigned to the assignee of the present invention, and all of which are expressly incorporated herein by reference.

[0045] FIG. 7 is a schematic block diagram illustrating autosense routines 190 and 192 that may be used in the remote I/O interfaces 44 and 46 to enable the automatic detection of and communication with the remote I/O devices 14 and 16 of FIG. 1. Generally speaking, the autosense routines 190 and 192 enable the controller 12 to automatically identify the presence of the remote I/O devices 14 and 16 on the remote databus 48. More specifically, the remote autosense routine 192 scans the remote databus 48 and collects device information from I/O devices connected to the databus 48, which in this case, for example, are the remote I/O devices 14 and 16. However, any other number or types of I/O devices could be connected to the databus 48. The remote autosense routine 192 uses the remote communication object 72 to automatically send the device information collected via the databus 48 over the remote I/O communication link 18 to the remote I/O host interface 44. The local communication object 70 receives the collected device information and automatically routes it to the autosense routine 190 within the remote I/O host interface 44. The local autosense routine 190 then updates a live list 194 which maintains a list of active I/O devices connected to the remote databus 48, which in this case may be the remote I/O devices 14 and 16. The local autosense routine 190 may also receive an autosense command from the controller 12 and send a command to initiate the remote autosense routine 192. The autosense routines 190 and 192 may be the same type of autosense routines now implemented by a controller for local I/O devices and as such are not described in more detail herein. A more detailed discussion of such autosense routines may be found in U.S. patent application Ser. No. 08/631,519 to Nixon et al. (“Process Control System Including a Method and Apparatus for Automatically Sensing the Connection of Devices To a Network”) filed Apr. 12, 1996, which is assigned to the assignee of the present invention and which is expressly incorporated herein by reference.

[0046] After the remote I/O devices 14 and 16 have been detected using the above-described autosense routines 190 and 192, the controller 12 may then access the live list 194 to retrieve the collected device information, which may subsequently be stored by the controller 12 in the list 96. The controller 12 may pass the collected device information associated with the remote I/O devices 14 and 16 to the user interface 20, which may, for example, update the hierarchy graphic 164 to include the tags “I/O device 1” and “I/O device 2” within the hierarchy representing the I/O devices 14 and 16. Additionally, the device information related to the I/O devices 14 and 16 may be used to form the connections 178 and 180 and to generate the communication objects 70 and 72 that instantiate the connections 178 and 180. FIG. 8 is an exemplary flow diagram depicting one method 200 of establishing the autosense routines 190 and 192 of FIG. 7. Block 202 sets up the local autosense routine 190 within the host interface block 44 and block 204 uses the local communication object 70 to recognize that the local autosense routine 190 requires communications over the remote I/O communication link 18. Block 206 sets up the remote autosense routine 192 in the remote I/O communication interface 46 and then block 208 uses the remote autosense routine 192 to poll the remote databus 48 for I/O devices and collects device information (e.g., device type, manufacturer, addresses, tags, serial numbers, functional roles, etc.) from all I/O devices present on the bus 48. Block 210 then uses to the remote communication object 72 to send the collected device information over the remote I/O communication link 18 to the remote I/O host interface 44, which then uses the local communication object 70 to automatically route the device information to the local autosense routine 190. Block 212 uses the local autosense routine to send the device information to the user interface 20 via the controller databus 28 and the controller 12, as described above.

[0047] Accordingly, The system and method described herein enables the seamless integration of remotely situated I/O devices within a distributed process control system. The system and method automatically configures a remote I/O interface device at each end of a remote I/O communication link so that all communication activities with the remote I/O devices over the remote I/O communication link appear to be transparent from the perspective of and a user at a user interface and a controller that is communicating over the remote I/O communication. The system may also allow the user to interact at the system level through a graphic interface running on the user interface, for example, to configure control loops, monitor process parameters, etc. associated with a combination of local and remote I/O devices without having to understand, or even be aware of, the underlying communication technologies used by the remote I/O devices. In other words, the system and method described herein insulates the user from the implementation details of the underlying remote I/O communication technologies by automatically generating and instantiating appropriate communication objects within the remote I/O interface devices in response to the user requesting a control loop connection to a remote I/O device. As a result, the user's interaction with the system has a consistent look and feel regardless of whether or not the user has specified a connection to a remote or a local I/O device and regardless of the underlying communication technologies being used to accomplish the remote I/O communications.

[0048] Generally, the above-described system and method may be efficiently implemented using one or more general purpose processors to execute a number of software code segments or modules that are retrieved from a computer readable memory. However, other combinations of hardware and software using, for example, algorithm specific integrated circuits (i.e., ASICs) or other types of hardware may be used to accomplish the same functions without departing from the scope of the invention. If implemented in software, the functional blocks and routines discussed herein may be stored in any computer readable memory such as on a magnetic, optical, or other storage medium, in a RAM or ROM of a computer, controller, field device, etc. Likewise, this software may be delivered to a user or a device via any known or desired delivery method including, for example, over a communication channel such as a telephone line, the Internet, etc.

[0049] While the invention has been described with reference to specific examples, which are intended to be illustrative only and not to be limiting of the invention, it will be apparent to those of ordinary skill in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.