An electronic device and method for configuring an Ethernet I / O card in a process control environment

Abstract

To provide an Ethernet I / O Card (EIOC) scanner device which enables improved integration of EIOC-enabled field devices (and associated field device variables) into a process control system, while easily configuring the process control system.SOLUTION: An Ethernet I / O card (EIOC) scanner device can perform the following operations: (i) A decoder file of an EIOC-enabled field device is analyzed to automatically identify a field device variable which is configured to be sent or received by the EIOC-enabled field device; and (ii) the EIOC-enabled field devices and associated field device variables identified by the EIOC scanners are integrated into the process control system, while quickly and easily configuring the process control system.SELECTED DRAWING: Figure 1A

Description

Technical Field

[0001] The present disclosure generally relates to Ethernet input / output (I / O) cards (EIOCs) in a process control environment, and more specifically to a scanner device that enables an improved configuration of a process control system based on a decoder file for an EIOC-compatible field device.

Background Art

[0002] Distributed process control systems, such as distributed or scalable process control systems used in power generation, chemical, petroleum, or other processes, are communicatively coupled to at least one host or operator workstation via a process control network and to one or more instruments or field devices via an analog, digital, or combined analog / digital bus, typically including one or more process controllers communicatively coupled to each other.

[0003] Field devices perform functions within a process or plant, such as opening and closing valves, switching devices on / off, and measuring process parameters. Examples of field devices include valves, valve positioners, switches, and transmitters (e.g., devices including sensors for measuring temperature, pressure, or flow rate, and transmitters for transmitting the sensed temperature, pressure, and flow rate).

[0004] The process controller is typically located within the plant environment, receives signals indicative of process measurements (or other information regarding the field device) performed by the field device, and, for example, makes process control decisions, generates control signals based on the received information, and executes a controller application that runs different control modules that cooperate with control modules or blocks implemented in smart field devices (e.g., HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices).

[0005] By executing the control modules, the process controller transmits control signals to the field device through a communication link or signal path, thereby controlling the operation of at least a portion of the process plant or system (e.g., controlling at least a portion of one or more industrial processes operating or executing within the plant or system). For example, a first set of controllers (s) and field devices can control a first portion of a process that is being controlled by the process plant or system, and a second set of controllers (s) and field devices can control a second portion of the process.

[0006] An input / output (I / O) card (which may also be referred to as an “I / O device” or “I / O module”) is also typically located within a plant environment but is typically disposed between a controller and one or more field devices to enable communication therebetween (e.g., by converting electrical signals to digital values and vice versa). Usually, the I / O card functions as an intermediate node between the process controller and the input or output of one or more field devices configured for the same communication protocol used by the I / O card. Specifically, the inputs and outputs of field devices are typically configured for analog or discrete communication. To communicate with the field device, the controller typically requires an I / O card configured for the same type of input or output used by the field device. That is, for a field device configured to receive an analog control output signal (e.g., a 4 - 20 mA signal), the controller requires an analog output (AO) I / O card to transmit an appropriate analog control output signal, and for a field device configured to transmit a measured value or other information via an analog signal, the controller typically requires an analog input (AI) card to receive the transmitted information. Similarly, for a field device configured to receive a discrete control output signal, the controller requires a discrete output (DO) I / O card to transmit an appropriate discrete control output signal, and for a field device configured to transmit information via a discrete control input signal, the controller requires a discrete input (DI) I / O card. Additionally, some I / O cards are configured for resistance temperature detectors (RTDs) (which vary the resistance of a wire with temperature) or thermocouples (TCs) (which generate a voltage proportional to temperature). Generally, each I / O card can be connected to multiple field device inputs or outputs, and each communication link to a particular input or output is referred to as an “I / O channel” (or more generally, a “channel”).For example, a 120-channel DO I / O card can be communicatively connected to 120 individual discrete field device inputs via 120 individual DO I / O channels, enabling a controller to send discrete control output signals (via the DO I / O card) to the 120 individual discrete field device inputs.

[0007] As used herein, field devices, controllers, and I / O devices are generally referred to as "process control devices" and are generally located, disposed, or installed within the field environment of a process control system or plant. A network formed by one or more controllers, field devices communicatively connected to the one or more controllers, and intermediate nodes that facilitate communication between the controllers and the field devices may be referred to as an "I / O network" or "I / O subsystem".

[0008] Information from the I / O network(s) can be made available to one or more other hardware devices such as an operator workstation, a personal computer or computing device, a handheld device, a data historian, a report generator, a central centralized database, or typically a control room or other location remote from the harsher field environment of the plant, e.g., other central centralized management computing devices located within the backend environment of the process plant, via a data highway or communication network ("process control network").

[0009] Through the information communicated via the process control network, an operator or maintenance personnel can execute desired functions regarding the process via one or more hardware devices connected to the network. These hardware devices can, for example, enable an operator to change the settings of process control routine(s), modify the operation of control modules within a process controller or smart field device, view the current state of the process within the process plant or the status of a specific device, view alarms generated by the field device and the process controller, simulate the operation of the process for the purpose of personnel training or testing of process control software, diagnose problems or hardware failures within the process plant, etc. The process control network or data highway utilized by the hardware devices, controllers, and field devices can include a wired communication path, a wireless communication path, or a combination of a wired communication path and a wireless communication path.

[0010] As an example, the DeltaVTM control system and the OvationTM distributed control system (DCS) sold by Emerson each include multiple applications that are stored and executed in different devices located in various locations within a process plant. Configuration applications that reside in one or more workstations or computing devices within the back-end environment of the process control system or plant enable a user to create or modify process control modules and download these process control modules to dedicated distributed controllers via a data highway. Typically, these control modules are composed of functionally interconnected function blocks, and these function blocks are objects within an object-oriented programming protocol that (i) perform functions within a control scheme based on inputs to the function block and (ii) provide outputs to other function blocks within the control scheme. Also, the configuration application may enable a configuration designer to create or modify an operator interface used by a visualization application to display data to an operator and to enable the operator to change settings such as setpoints within process control routines.

[0011] Each dedicated controller (or, in some cases, one or more field devices) stores and executes a respective controller application that executes the control modules assigned and downloaded to it to implement the actual process control function. The visualization application can be executed on one or more operator workstations (or one or more remote computing devices communicatively connected to the operator workstation and the data highway), receives data from the controller application via the data highway, and uses the user interface to display this data to the process control system designer, operator, or user, providing any one of several different views, such as the operator's view, the engineer's view, the technician's view, etc. The data history application is typically stored in and executed by a data history device that collects and stores some or all of the data provided across the data highway, while the configuration database application can be executed on a still more remote computer attached to the data highway to store the current process control routine configuration and the data associated therewith. Alternatively, the configuration database may be located within the same workstation as the configuration application.

[0012] In addition to process controllers, I / O cards, and field devices, a typical process control system includes many other support devices necessary for or related to the process operation. These additional devices include, for example, power supply equipment, power generation and distribution equipment, and rotating equipment such as turbines located in many places within a typical plant.

[0013] It should be noted that this background description provides a context to facilitate understanding and recognition of the following detailed description. The research of the inventors whose current names are mentioned within the scope described in this background art section, (as well as aspects of the background art description that may not be considered prior art at the time of filing in another way), are not admitted as prior art to this disclosure, either explicitly or implicitly.

Summary of the Invention

Problems to be Solved by the Invention

[0014] This disclosure, with reference to FIGS. 1 - 12, describes various technologies, systems, and methods for facilitating the configuration of a process control system to enable improved integration of EIOC - compliant field devices and related field device variables into the process control system.

Means for Solving the Problems

[0015] Specifically, this disclosure describes an EIOC scanner that can perform the following: (i) analyze the decoder file of an EIOC - compliant field device to automatically identify field device variables (sometimes referred to as "field device parameters") that the EIOC - compliant field device is configured to transmit or receive; and (ii) quickly and easily facilitate the configuration of the process control system to integrate the EIOC - compliant field device and any desired field device variables associated with the EIOC - compliant field device identified by the EIOC scanner into the process control system.

[0016] In an embodiment, an electronic device (sometimes referred to as an "EIOC scanner") for configuring an Ethernet I / O card in a process control environment can include a memory that stores machine-readable instructions that cause a process, a communication interface, and a processor to implement one or more operations. The one or more operations can include any one or more of the following: (i) analyzing a decoder file for a field device configured to be coupled to an Ethernet I / O card (EIOC) via an Ethernet link in a process control system and mapping one or more field device variables to one or more message locations; (ii) generating a data set that includes one or more device signal tags (DSTs) each representing a process variable corresponding to a different one of the one or more field device variables mapped to the one or more message locations; and (iii) uploading the data set to a configuration database of the process control system via the communication interface such that the one or more DSTs correspond to the one or more message locations when the process control system is configured according to the configuration database.

[0017] In an embodiment, the dataset is uploaded to the configuration database such that when the process control system is configured according to the configuration database, the EIOC is configured to implement a controller output processing function or a controller input processing function. When configured for the controller output processing function, the EIOC is configured to map the DST value from the controller output message to the message position within the field device input message of the corresponding field device variable (the appropriate message position can be determined from the decoder file). Performing this mapping includes (1) receiving from the process controller a controller output message including the controller output value of the first DST, and (2) in response to the first DST, assigning the controller output value to the mapped first message position according to the dataset such that the controller output value is transmitted from the EIOC to the field device at the first message position of the field device input message to be transmitted to the field device.

[0018] Similarly, when configured for the controller input processing function, the EIOC is configured to map the field device variable value from the field device output message (received from the field device) to the message position of the controller input message (to be transmitted to the process controller) for the corresponding DST (the appropriate message position can be determined from the decoder file). Performing this mapping can include: (1) receiving from the field device a field device output message including a controller input value (also "field device output value") at the second message position mapped to the second DST according to the dataset; and (2) in response, assigning the controller input value to the second DST such that the input value is transmitted from the EIOC to the process controller as part of the controller input message as the value for the value of the second DST.

[0019] In an embodiment, the EIOC can be configured to implement both a controller output processing function and a controller input processing function. The EIOC can be configured to transmit controller input messages and field device input messages such that each is transmitted during a different predetermined time slot. Further, the controller input / output messages and the field device input / output messages can each carry a plurality of parameter values.

[0020] In an embodiment, a data set generated by an electronic device based on a decoder file can include any desired type of system tag that includes one or more of DST, physical device tag (PDT), logical device tag (LDT), or node tag (representing a particular EIOC).

[0021] In an embodiment, the electronic device can present a user interface for adding, editing, or displaying the DST and any other system tags (and any related properties) included in the data set generated from the decoder file. In an embodiment, the electronic device can download the decoder file from a field device associated with the decoder file. In some cases, the electronic device can download the decoder file from a server (e.g., associated with the manufacturer of the field device).

[0022] Note that this summary is provided to introduce a selection of concepts that are further described below in the detailed description of the invention. As described in the detailed description of the invention, a particular embodiment can include features and effects not described in this summary, and a particular embodiment can omit one or more features or effects described in this summary.

[0023] Each of the figures described below shows one or more aspects of the disclosed system(s) and / or method(s) according to the embodiments. The detailed description of the invention refers to the reference numerals included in the following figures.

Brief Description of the Drawings

[0024]

Figure 1A

[0025]

Figure 1B

[0026]

Figure 2

[0027]

Figure 3

[0028]

Figure 4

[0029]

Figure 5

[0030]

Figure 6

[0031]

Figure 7

[0032]

Figure 8

[0033]

Figure 9

[0034]

Figure 10

[0035]

Figure 11

[0036]

Figure 12

[0037] As described above, the present disclosure, with reference to FIGS. 1 - 12, describes various techniques, systems, and methods for facilitating the configuration of a process control system to enable improved integration of EIOC - compliant field devices and associated field device variables into a process control system. In particular, FIGS. 1A and 1B show an EIOC scanner 75 (sometimes referred to as "scanner 75" or "device 75") that can: (i) analyze the decoder file of an EIOC - compliant field device to automatically identify the field device variables (sometimes referred to as "field device parameters") that the EIOC - compliant field device is configured to transmit or receive; and (ii) quickly and easily facilitate the configuration of the process control system to integrate the EIOC - compliant field device and any desired field device variables associated with the EIOC - compliant field device identified by the EIOC scanner 75 into the process control system.

[0038] The following description is divided into the following sections. Section I describes exemplary systems, devices, and networks related to the disclosed technology, including an exemplary process control system that can be configured to integrate, using the EIOC Scanner 75, a process control system EIOC-compatible field device and associated field device variables with reference to FIGS. 1A-4. Section II describes an exemplary method for facilitating the configuration of a process control system for integrating an EIOC-compatible field device and associated variables into a process control system with reference to FIG. 5. Section III describes an EIOC-compatible field device and an exemplary protocol stack associated with EIOC that can be configured using the EIOC Scanner 75 with reference to FIGS. 6-9. Section IV describes an exemplary user interface (UI) that can be presented by the EIOC Scanner 75 to enable a user to add, edit, or view information related to parameters added to a process control system based on the analysis of a decoder file with reference to FIGS. 10-12. Sections V and VI describe additional considerations and terms and phrases used in the specification.

[0039] I. Exemplary EIOC Scanner 75 and Exemplary Process Control System 5 FIG. 1A is a block diagram of an Ethernet I / O card (“EIOC”) network 7 that includes an EIOC field device 131 and a scanner 75. FIG. 1B is a block diagram of a process control system 5 of which the EIOC network 7 can be a part. Generally speaking, the scanner 75 can do the following: (i) analyze the decoder file 199 of the field device 131 to automatically identify the field device variables that the field device 131 is configured to transmit or receive; and (ii) facilitate the rapid and easy configuration of the EIOC network 7 (and, optionally, a wider process control system 5) to integrate the field device 131 and any desired field device variables associated with the field device 131 into the EIOC network 7 or the process control system 5.

[0040] Generally speaking, the EIOC-compatible controllers and field devices disclosed herein communicate using EIOC messages. An “EIOC message” is a network message (e.g., a packet or frame) formatted according to the EIOC stack of a protocol. An “EIOC stack” refers to any suitable stack of communication protocols that includes a standard process control communication protocol encapsulated within a packet that can be transmitted according to standard Internet protocol suite standards (e.g., Ethernet, TCP / IP, UDP / IP, etc.). Exemplary EIOC protocols or stacks include the Common Industrial Protocol (CIP), Ethernet / IP, and Modbus TCP.

[0041] As an example, a typical "EIOC message" can be a process control message configured according to the Modbus TCP standard, Ethernet / IP standard, or IEC standard in the application, presentation, and session layers of the OSI model. The process control message can be encapsulated within a User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) packet in the transport layer of the OSI model, which can in turn be encapsulated within an IP packet in the network layer of the OSI model. Finally, the IP packet of the EIOC message can be encapsulated according to the Ethernet standard in the data link and physical layers of the OSI model.

[0042] The term "Ethernet" refers to a family of computer network technologies commonly used in Local Area Networks (LANs) and Wide Area Networks (WANs). At the physical layer, Ethernet can use coaxial cables, twisted pairs (e.g., any suitable CATX cable such as CAT5 or CAT6), or fiber optic links as shared media. These physical links can be terminated using any suitable connector such as an RJ45 connector. At the physical and data link layers, Ethernet communication generally complies with the IEEE802.3 standard. Generally speaking, a system that communicates according to the Ethernet standard (e.g., the EIOC controller and field devices disclosed herein) divides a stream of data into shorter fragments called "frames". Usually, each frame contains a source address, a destination address, and error-checking data so that a damaged frame can be detected and discarded. In most cases, the upper layer protocol triggers the retransmission of lost frames.

[0043] In the process control industry, with respect to the phrases "EIOC" and "I / O", the term "I / O" (such as in "Ethernet I / O card") may be used in a number of related but different contexts. The term "I / O" generally refers to the logical link or communication channel (e.g., "I / O channel") that communicatively couples a field device to an I / O card or controller, but can also be used to refer to devices (e.g., "I / O device" or "I / O card") that transmit signals to or receive signals from a field device via the I / O channel, and connectors or terminals associated with the I / O device (e.g., "I / O connector"), signals transmitted on the I / O channel (e.g., "I / O signal"), variables or commands represented by the signals (e.g., "I / O parameter"), or values of variables or commands carried by the signals (e.g., "I / O parameter value"). As long as the term "I / O" is referenced without a modifier in this specification, the context of the sentence should clarify which of these concepts is being discussed.

[0044] Furthermore, it should be understood that an "I / O channel" represents a specific type of "communication channel" or "channel". That is, unless the context otherwise indicates, referring to the term "channel" or the term "communication channel" in this description without the modifier "I / O" may, in some embodiments, refer to a communication link that can be an I / O channel, but in some embodiments, may also refer to a communication link other than an I / O channel. Further, an "EIOC channel" is a specific type of I / O channel. It is an I / O channel between a controller and a field device that depends on Ethernet network technology. For example, an EIOC channel can be or include a physical link such as a CatX cable (e.g., Cat5, Cat5e, Cat6) configured to facilitate communication between devices that communicate via a physical link utilizing the Ethernet standard, and the controller and the field device can communicate using the TCP / IP standard.

[0045] Similarly, an "EIOC" is a specific type of I / O device (e.g., a device configured to communicate in accordance with process control standards and one or more Ethernet standards). An "EIOC connector" refers to a specific type of I / O connector (e.g., a male CatX connector or a female CatX port configured for Ethernet communication). An "EIOC signal" is a specific type of I / O signal (e.g., an I / O signal in which a process variable is communicated via a message compliant with the Ethernet standard in the physical, data link, network, or transport layer of the OSI model). And finally, an "EIOC parameter" refers to a specific type of I / O parameter (e.g., an I / O parameter transmitted between an EIOC field device via an EIOC signal on an EIOC channel).

[0046] A. EIOC Network 7 and EIOC Scanner 75 Generally speaking, the EIOC network 7 is an I / O network for Ethernet field devices and I / O cards within a process control environment, and the EIOC scanner 75 is a device configured to analyze a decoder file 199 for a field device (e.g., field device 131) to identify one or more field device variables (sometimes "field device parameters") configured for the field device 131 to transmit or receive. The following paragraphs identify the various systems and links shown in FIG. 1A before describing the functions provided by the EIOC network 7 and the EIOC scanner 75.

[0047] The EIOC network 7 is configured to facilitate Ethernet communication between the controllers, field devices, and intermediate network devices included in the EIOC network 7. The EIOC network 7 can be coupled to the process control backbone or network 10 and can include any one or more of the following: (i) a process controller 111 coupled to a configuration system 72 via the network 10; (ii) an EIOC 126 coupled to the controller 111 via a link 141 that can be any suitable communication link (e.g., a backplane on the mounts of the controller 111 and the EIOC 126, including a bus for digital communication); (iii) a switch 128 coupled to the EIOC 126 via a link 145; (iv) a field device 131 coupled to the EIOC 126 via a link 142; and (v) field devices 133 and 135 coupled to the switch 128 via links 143 and 144, respectively. The links 142 - 145 can be any suitable Ethernet link.

[0048] As an example, DeltaV sold by Emerson Process Management TM or Ovation TMThe controller 111, which can be a controller, can be any process controller suitable for a process control environment and can have any one or more of the features or functions further described below with respect to the controller 11. The controller 111 can include a first communication interface (e.g., an EIOC communication interface; not shown) for connecting to the EIOC link 141 and the EIOC 126, and a second communication interface (not shown) for connecting to any desired node of the network 10 and the network 10 (e.g., the configuration system 10).

[0049] Generally speaking, a "communication interface" (sometimes called a "network interface") is a device or component that enables the system (e.g., the controller 111) of which it is a part to send and receive information or data with other systems or components (e.g., the field device EIOC 126 and the configuration system 72). Optionally, the communication interface of the controller 111 can include (i) a connection to a wired link that conveys electrical or optical signals to another device (e.g., via a coaxial cable or an optical fiber cable), a circuit for communicating with other devices, or (ii) a circuit that enables wireless communication (e.g., short - range or long - range communication) via electromagnetic signals such as radio frequency (RF) signals. The described communication interfaces and systems can conform to any one or more suitable communication protocols, standards, or technologies, such as those described herein.

[0050] The EIOC126 of network 7 is an I / O card configured to communicate with field devices according to one or more Ethernet or Internet Protocol standards. The EIOC126 can include a first communication interface (not shown) for establishing EIOC communication (e.g., via link 142), as well as a second communication interface for communicating with a controller (e.g., controller 111 via link 141). Generally speaking, the first communication interface is an Ethernet-based interface, and the second communication interface is a digital communication bus on the backplane shared by the EIOC126 and the controller 111. The EIOC126 has several of the same structure and can perform any of the operations described below with respect to the field devices 15-22 and 40-46 shown in Figure 1B.

[0051] The switch 128 of network 7 can be any suitable network switch or router configured to transfer or route EIOC messages between devices connected to the switch 128. As shown in Figure 1A, the switch 128 can transfer messages between the field devices 133 / 135 and the EIOC125 via links 143 / 144 and 145, respectively. In some embodiments, a router can be used instead of or in addition to the switch 128.

[0052] Each of the field devices 131-135 of network 7 is an EIOC-compatible field device. That is, each is configured to communicate with an EIOC (such as EIOC126) using EIOC-formatted messages. Each field device 131-135 can have any of the functional structures described below with respect to the field devices 15-22 and 40-46 shown in Figure 1B, as needed.

[0053] The EIOC scanner 75, which can be any suitable computing device, can be coupled to the EIOC network 7 via the link 123. Further, the EIOC scanner 75 can be coupled to the decoder source 120 and the configuration system 72 via the links 121 and 122, each of which can be any suitable electronic system or computer system. The configuration system 72 can be coupled to the EIOC network 7 via the process control network or backbone 10. Each of the links 121 - 123 can be any suitable wired or wireless communication link. The configuration system 72 is described in more detail with respect to Figure 1B.

[0054] The EIOC scanner 75 includes a memory 101 that stores the scanner tool 113 and the decoder file 199, a processor 102, a communication interface 103 coupled to the processor 102, and a user interface 104 coupled to the processor 102. The user interface 104 can include an input component 106 (e.g., a touch sensor, keyboard, mouse, mechanical button, etc.) and a display 107 (e.g., an LCD, LED, CRT, plasma, projection display, head-up display, etc.). The user interface 104 can include output components such as a speaker for audio output, a motor for tactile output, a light source (e.g., an LED) for visual output, in addition to or instead of the display 107.

[0055] The processor 102 can execute the tool 113, which, when executed by the processor 102, is a set of computer-readable instructions that cause the processor 102 to implement the functions attributed to the scanner 75 herein.

[0056] During operation, the EIOC scanner 75 receives the decoder file 199 from the decoder source 120 via the link 121. The decoder source 120 can be a server (e.g., associated with the manufacturer of the field device 131). The decoder file 199 can be retrieved from a plurality of decoder files based on a model number, a MAC address, or some other identifier unique to the field device 131 or the model of the field device 131. In some embodiments, the scanner 75 retrieves the decoder file 199 from the field device 131 via a wired or wireless connection.

[0057] Generally speaking, the decoder file 199 includes a list of field device variables configured for the field device 131 to write or read. The decoder file 199 further includes code for interpreting EIOC messages transmitted or received by the field device 131. This code can specify the message positions (e.g., bytes at a specific offset from the header of the message) where writing or reading of each field device variable is required. As will be described below, the scanner 75 analyzes the decoder file 199 to import the field device variables as process variables into the process control system and enables the EIOC 75 to read and write values to the EIOC messages exchanged with the field device 131.

[0058] When executing the scanner tool 113, the EIOC scanner 75 analyzes the decoder file 199 to identify one or more field device variables configured for the field device 131 to transmit or receive. The scanner 75 can also analyze the decoder file 199 to identify the message positions mapped to the identified field device variables for messages configured for the field device 131 to transmit or receive (e.g., to the EIOC 126). Having identified the field device variables and the corresponding mapped message positions, the scanner 75 can create a record that links the message positions to a set of system tags (e.g., new system tags not currently used by the process control system 5) intended to represent the identified field device variables.

[0059] Next, the EIOC scanner 75 can update the configuration system 72 to include the record, thereby formally assigning the set of system tags to the appropriate message positions (from the perspective of the process control system 5) for messages transmitted between the field device 131 and the EIOC 126 such that the set of system tags represents one or more field devices. Specifically, the configuration system can include a database that stores a map 132 that links system tags to I / O channels. In the case of conventional I / O cards and field devices, the I / O channel can be a specific physical 4 - 20 mA channel on the I / O card (e.g., each card can have 32 I / O channels). In the case of EIOCs and EIOC field devices, the I / O channel can be identifiable by a specific message position for an EIOC message configured for the EIOC to transmit or receive.

[0060] Next, the updated configuration database 72 can be used to configure the process control system 5 such that the associated field device variables associated with the field device 131 are made accessible to the systems within the process control system 5 via the assigned system tags by operating the assigned system tags. The process control system 5 is updated to utilize the system tags such that (i) when the controller 111 generates a controller output that references the system tag of a particular variable, the EIOC 126 encodes the field device input message of the field device 131 such that the EIOC 126 writes the controller output to the message location within the field device input message that is linked or assigned to the system tag of the particular variable; and (ii) when the field device 131 transmits a field device output message that includes a field device output value at a given message location to the EIOC 126, the EIOC 126 automatically decodes the field device output message and updates the system tag linked to the given message location by writing the field device output value to the system tag (e.g., by writing the value to the controller input message transmitted to the controller 11).

[0061] Scanner 75 provides a faster and more automated configuration technique for integrating new or updated field devices or field device variables into a process control system, as compared to manual techniques for integrating new field devices into a process control system. In a typical scenario that includes manual techniques, integrating field device variables associated with a new field device into a process control system can involve a user (i.e., a human) reading a manual or other document (e.g., issued by a manufacturer) to identify the field device variables that the new field device can transmit or receive. Next, the user can manually update the configuration database by adding system tags to the configuration database and manually assigning the new system tags to an I / O channel or message location that the user believes is associated with the field device variable that the new system tag is intended to represent (e.g., a belief derived from a manufacturer's manual or guide).

[0062] In particular, this manual technique is time-consuming and prone to current and future errors. The tedious and time-consuming process of manually reading the document and programming the configuration database accordingly is self-evident. Regarding potential errors, the user may misunderstand the document and assign new system tags to the wrong I / O channel or the wrong message position, and as a result, the system tags may be assigned to the wrong field device variables (thus resulting in system tags carrying incorrect values). Similarly, when the manufacturer updates the firmware or software of the field device so that the field device writes or reads field device variables in a different way (e.g., at different message positions), the corresponding system tags may become "broken" (e.g., the way the process control system reads from or writes to the message position is not associated with the desired field device variable). Furthermore, after the field device is installed and the process control system is configured accordingly, the manufacturer of the field device makes new field device variables available. In such a scenario, the process control system may not have a way to integrate the new field device variables such that a human recognizes the update in some way, manually checks the document to determine how the new variables are to be read or written, and manually configures the process control system accordingly. Needless to say, such updates can easily be overlooked or ignored.

[0063] EIOC Scanner 75 addresses these issues with error-prone and time-consuming manual configuration techniques by automatically mapping the field device variables of the EIOC field device to message positions using a decoder file (e.g., decoder file 199) associated with the field device so that the field device variables can be easily and quickly integrated into the process control system.

[0064] B. Process Control System 5 Figure 1B is a block diagram of an exemplary process plant, process control system, or process control environment 5 that includes the EIOC network 7 shown in Figure 1B.

[0065] The process plant 5 controls a process that can be said to have one or more "process outputs" (e.g., tank level, flow rate, material temperature, etc.) that characterize the state of the process and one or more "process inputs" (e.g., various environmental conditions and the state of actuators, actions that can change the process output). As a general matter, at least a portion of the process output is measured and used as a "control input" to one or more controllers that control the process. Next, the one or more controllers can send one or more "control outputs", "control signals", or "commands" (which can be considered process inputs or signals that affect process inputs). The process plant or control system 5 of Figure 1B includes a field environment 122 (e.g., "process plant floor 122") and a back-end environment 125, each of which is communicatively connected by a process control backbone or data highway 10, which can include one or more wired or wireless communication links and can be implemented using any desired or suitable communication protocol such as the Ethernet protocol.

[0066] Generally speaking (and as shown in FIG. 1B), the field environment 122 includes physical components (such as process control devices, networks, network elements, etc.) arranged, installed, and interconnected to operate to control a process during runtime. For example, the field environment includes I / O networks 6 and 7 (i.e., the EIOC network 7). Generally, the components of each of these I / O networks are positioned, arranged, or otherwise included within the field environment 122 of the process plant 5. Generally speaking, in the field environment 122 of the process plant 5, raw materials are received and processed using the physical components arranged therein to produce one or more products.

[0067] In contrast, the back-end environment 125 of the process plant 5 includes various components such as computing devices, operator workstations, databases, or data banks that are shielded or protected from harsh conditions and the materials of the field environment 122. In some configurations, the various computing devices, databases, and other components and equipment included in the back-end environment 125 of the process plant 5 can be physically located in different physical locations, some of which may be local to the process plant 5 and some of which may be remote.

[0068] 1. The field environment 122 associated with the system 5 As described above, the field environment 122 includes I / O networks 6 and 7, each of which can be coupled to the plant network 10. Each of the I / O networks 6 and 7 includes one or more controllers, field devices communicatively connected to the one or more controllers, and intermediate nodes that facilitate communication between the controller and the field devices (such as I / O cards).

[0069] Each process controller of the process plant 5 implements a control strategy defined by one or more control routines, which can be stored in the memory of the controller. When the processor of the controller executes one or more of the control routines, the controller transmits a control signal (i.e., a "control output") to other field devices in the plant 5 to control the operation of the process via a wired or wireless process control communication link or network. The controller can generate a control signal based on (i) one or more received signals that can be called "control inputs" (e.g., one or more received signals representing measurement values obtained by a field device), and (ii) the logic of one or more control routines that can be defined by one or more software elements (e.g., function blocks). Typically, the controller manipulates a process input (which can be called a "manipulated variable") to change a particular process output (which can be called a "controlled variable" or simply a "process variable") based on feedback (i.e., a measured value of the controlled variable) and a desired value of the process output (i.e., a setpoint).

[0070] Generally, at least one field device performs a physical function (e.g., opening or closing a valve, increasing or decreasing temperature, measurement, state detection, etc.) and controls the operation of the process implemented in the process plant 5. Some types of field devices communicate with the controller using an I / O device (e.g., an "I / O card"). The process controller, field devices, and I / O cards can be wired or wireless, and any number and combination of wired and wireless process controllers, field devices, and I / O devices may be included within the process plant environment or system 5.

[0071] For example, FIG. 1B shows a process controller 11 that implements a control strategy defined by one or more control routines, which can be stored in the memory of the controller. The controller 11 is communicatively connected to the wired field devices 15-22 via input / output (I / O) cards 26 and 28, and is communicatively connected to the wireless field devices 40-46 via a wireless gateway 35 and a data highway 10.

[0072] In one configuration (not shown), the controller 11 is communicatively connected to the wireless gateway 35 by using one or more communication networks other than the backbone 10, such as using any number of other wired or wireless communication links that support one or more communication protocols, for example, Wi-Fi or other wireless local area network protocols compliant with IEEE 802.11, mobile communication protocols (such as WiMAX, LTE, or other ITU-R compatibility protocols), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Fieldbus, etc.

[0073] The controller 11 is, by way of example, DeltaV sold by Emerson Process Management TM or Ovation TMIt can be a controller and can operate to perform a batch process or a continuous process using at least some of field devices 15 - 22 and 40 - 46. In an embodiment, in addition to being communicably connected to process control data highway 10, controller 11 is also communicably connected to at least some of field devices 15 - 22 and 40 - 46 using any desired hardware and software associated with, for example, a standard 4 - 20 mA device, I / O cards 26, 28, or any smart communication protocol such as FOUNDATION™ Fieldbus protocol, HART™ protocol, WirelessHART™ protocol. In FIG. 1A, controller 11, field devices 15 - 22 and I / O cards 26, 28 are wired devices, and field devices 40 - 46 are wireless field devices. Of course, wired field devices 15 - 22 and wireless field devices 40 - 46 can conform to any other desired standard(s) or protocol, for example, any wired or wireless protocol including any standard or protocol to be developed in the future.

[0074] The process controller 11 of FIG. 1B includes a processor 30 that implements or supervises one or more process control routines 38 (e.g., stored in memory 32). A "control routine" is a set of instructions executable by a processor to perform one or more operations for providing or performing at least partial control of a process. Generally speaking, a control routine can be understood as software configured to implement a particular control strategy. A control routine can include one or more functional blocks related to various functions.

[0075] The processor 30 is configured to communicate with the field devices 15 - 22 and 40 - 46, and with other nodes communicatively coupled to the controller 11. Note that any control routine or module described herein may, if so desired, be implemented or executed in part by a different controller or other device. Similarly, the control routines or modules 38 described herein implemented within the process control system 5 may take any form including software, firmware, hardware, etc. The control routines may be implemented in any desired software format such as object - oriented programming, ladder logic, sequential function charts, function block diagrams, or those using any other software programming language or design paradigm. The control routine 38 can be stored in any desired type of memory 32 such as random access memory (RAM) or read - only memory (ROM). Similarly, the control routine 38 may be hard - coded, for example, in one or more EPROMs, EEPROMs, application - specific integrated circuits (ASICs), or any other hardware or firmware element. Thus, the controller 11 can be configured to implement control strategies or control routines in any desired manner.

[0076] Controller 11 implements control strategies using what are generally referred to as functional blocks. Each functional block is an object or other part (e.g., a subroutine) of the overall control routine and operates with other functional blocks (via a communication called a link) to implement a process control loop within process control system 5. Control-based functional blocks typically perform one of the following: (i) an input function (sometimes called an "input block") such as one associated with a transmitter, sensor, or other process parameter measurement device; (ii) a control function (sometimes called a "control block") such as one associated with a control routine that performs PID, fuzzy logic, etc.; or (iii) an output function (sometimes called an "output block") that controls the operation of some device, such as a valve, to perform some physical function within process control system 5. Of course, there are hybrid and other types of functional blocks.

[0077] The functional blocks may be stored and thereby executed within controller 11, which is typically the case when these functional blocks are used or associated with several types of smart field devices such as standard 4 - 20 mA devices and HART® devices, or the functional blocks may be stored and thereby implemented within the field device itself, which can be the case for FOUNDATION® Fieldbus devices. One or more of the control routines 38 can implement one or more control loops by executing one or more of the functional blocks.

[0078] The wired field devices 15 - 22 can be any type of device such as sensors, valves, transmitters, positioners, etc., while the I / O cards 26 and 28 can be any type of process control I / O device that conforms to any desired communication or controller protocol. In FIG. 1A, the field devices 15 - 18 are standard 4 - 20 mA devices or HART (registered trademark) devices that communicate with the I / O card 26 via an analog line or an analog-digital combined line, while the field devices 19 - 22 are smart devices such as FOUNDATION (registered trademark) Fieldbus field devices that communicate with the I / O card 28 via a digital bus using the FOUNDATION (registered trademark) Fieldbus communication protocol. However, in some embodiments, at least some of the wired field devices 15, 16, and 18 - 21 or at least some of the I / O cards 26, 28 can, in addition to or instead of, use the process control data highway 10 or communicate with the controller 11 by using other suitable control system protocols (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.).

[0079] In FIG. 1B, wireless field devices 40-46 communicate via a wireless process control communication network 70 using a wireless protocol such as the WirelessHART® protocol. Such wireless field devices 40-46 can communicate directly with one or more other devices or nodes of the wireless network 70 that are also configured to communicate wirelessly (e.g., using the wireless protocol or another wireless protocol). To communicate with one or more other nodes that are not configured to communicate wirelessly, the wireless field devices 40-46 may utilize a wireless gateway 35 connected to the process control data highway 10 or another process control communication network. The wireless gateway 35 provides access to the various wireless devices 40-58 of the wireless communication network 70. In particular, the wireless gateway 35 provides a communicable coupling between the wireless devices 40-58, the wired devices 11-28, or other nodes or devices of the process control plant 5. For example, the wireless gateway 35 provides a communicable coupling by using the process control data highway 10 or by using one or more other communication networks of the process plant 5.

[0080] Similar to the wired field devices 15-22, the wireless field devices 40-46 of the wireless network 70 perform physical control functions within the process plant 5, such as opening or closing a valve or obtaining a measurement of a process parameter. However, the wireless field devices 40-46 are configured to communicate using the wireless protocol of the network 70. Thus, the wireless field devices 40-46, the wireless gateway 35, and the other wireless nodes 52-58 of the wireless network 70 are producers and consumers of wireless communication packets.

[0081] In some configurations of the process plant 5, the wireless network 70 includes non-wireless devices. For example, in FIG. 1A, the field device 48 of FIG. 1A is a conventional 4-20 mA device, and the field device 50 is a wired HART® device. To communicate within the network 70, the field devices 48 and 50 are connected to the wireless communication network 70 via wireless adapters 52a, 52b. The wireless adapters 52a, 52b support a wireless protocol such as WirelessHART and can also support one or more other communication protocols such as Foundation® Fieldbus, PROFIBUS, DeviceNet. In addition, in some configurations, the wireless network 70 can be an independent physical device that communicates with the wireless gateway 35 over a wired connection or can be provided within the wireless gateway 35 as an integrated device, and includes one or more network access points 55a, 55b. The wireless network 70 can also include one or more routers 58 for forwarding packets from one wireless device in the wireless communication network 70 to another wireless device. In FIG. 1A, the wireless devices 40-46 and 52-58 communicate with each other and with the wireless gateway 35 via the wireless link 60 of the wireless communication network 70 or via the process control data highway 10.

[0082] 2. Back-end environment 125 of the plant 5 As described above, the back-end environment 125 typically includes various components such as computing devices, operator workstations, databases or data banks that are shielded or protected from the harsh conditions and materials of the field environment 122. The back-end environment 125 can include any one or more of (i) one or more operator workstations 71, (ii) configuration applications 72a and configuration databases 72b, (iii) data history applications 73a and history databases 73b, (iv) one or more other wireless access points 74 that communicate with other devices using other wireless protocols, (v) one or more gateways 76, 78 to systems external to the real-time process control system 5, each of which can be communicatively connected to the data highway 10.

[0083] The operator workstations 71 are utilized by an operator to view and monitor the runtime operation of the process plant 5 (e.g., as implemented by devices in the EIOC network 7) and to take any diagnostic, corrective, maintenance, or other actions that may be required. At least some of the operator workstations 71 may be located within various protected areas within or near the plant 5, and in some situations, at least some of the operator workstations 71 may be located remotely but still communicatively connected to the plant 5. The operator workstations 71 can be wired or wireless computing devices. The user can utilize the operator workstations 71 to view the system tags created by the scanner 75 based on the analysis of the decoder file 199, as well as to view the associated control routines.

[0084] The data history application 73a collects some or all of the data provided across the data highway 10 (e.g., parameters transmitted or received by either a field device or a controller in the EIOC network 7), and operates to either historize the data for long-term storage or store it in the history database 73b. Similar to the configuration application 72a and the configuration database 72b, the data history application 73a and the history database 73b can be centralized and have a single logical appearance to the process control system 5, even though multiple instances of the data history application 73a can be executed simultaneously within the process control system 5, and the data history 73b can be implemented across multiple physical data storage devices. The data history 73 can collect and historize any one or more process variables created via the scanner 75.

[0085] One or more other wireless access points 74 enable devices within the backend environment 125 (and, optionally, devices within the field environment 122, such as those within the EIOC network 7) to communicate with other devices using a wireless protocol such as Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, a mobile communication protocol such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution), or other ITU-R (International Telecommunication Union Radiocommunication Sector) compatibility protocols, a short-range wireless communication such as Near Field Communication (NFC) and Bluetooth, or other wireless communication protocols. Typically, such wireless access points 74 enable communication by a handheld or other portable computing device (e.g., user interface device 75) via respective wireless process control communication networks that support a wireless protocol different from, and independent of, the wireless network 70. For example, the wireless or portable user interface device 75 may be a mobile workstation or diagnostic test equipment utilized by an operator within the process plant 5 (e.g., one instance of the operator workstations 71). In some scenarios, in addition to portable computing devices, one or more process control devices (e.g., controller 11, field devices 15 - 22, or wireless devices 35, 40 - 58) also communicate using the wireless protocols supported by the access point 74.

[0086] Gateways 76 and 78 can interface with systems external to the real-time process control system 5 (e.g., enabling communication between an external system and one or more devices within the EIOC network 7). Typically, such systems are customers or suppliers of information generated or manipulated by the process control system 5. For example, the process control plant 5 can include a gateway node 76 for communicatively connecting the real-time process plant 5 to another process plant. Additionally or alternatively, the process control plant 5 can include a gateway node 78 for communicatively connecting the real-time process plant 5 to external public or private systems such as a laboratory system (e.g., a laboratory information management system or LIMS), an operator round inventory management system, a product inventory management system, a production scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, a process control system of another provider, or other external systems.

[0087] FIG. 1B merely illustrates a single wireless controller 11, a wireless gateway 35, a wireless adapter 52, an access point 55, a router 58, and a process control communication network 70 included within an exemplary process plant 5 with a finite number of field devices 15 - 22 and 40 - 46, but this is merely an exemplary and non-limiting embodiment. Any number of controllers 11 may be included within the process control plant or system 5, and any of the controllers 11 may communicate with any number of wired or wireless devices and networks 15 - 22, 40 - 46, 35, 52, 55, 58, and 70 to control processes within the plant 5.

[0088] Staying at FIG. 1B, the configuration application 72a and the configuration database 72b can be used to configure a particular aspect of the plant 5. Various instances of the configuration application 72a enable a user to create or modify process control modules and download these modules to the controller 11 or any process controller in the EIOC network 7 via the data highway 10, and also enable the user to create or modify an operator interface through which an operator can view data and change data settings within a process control routine (e.g., one implemented via a controller in the EIOC network 7). The configuration application 72a may be executed on one or more computing devices (not shown). The configuration database 72b stores the created (e.g., configured) modules or operator interfaces. Generally, the configuration application 72a and the configuration database 72b can be centralized and have a single logical appearance to the process control system 5, even though multiple instances of the configuration application 72a can be executed simultaneously within the process control system 5, and the configuration database 72b can be implemented across multiple data storage devices. Thus, the configuration application 72a, the configuration database 72b, and the user interface (not shown) thereto constitute a configuration or development system 72 for control or display modules. Typically, the user interface for the configuration system 72 is utilized by configuration engineers and development engineers regardless of whether the plant 5 is operating in real time. Thus, the user interface for the configuration system 72 is different from, but not necessarily distinct from, the operator workstation 71, while the operator workstation 71 is utilized by an operator during the real-time operation of the process plant 5 (herein also interchangeably referred to as the "runtime" operation of the process plant 5).

[0089] During commissioning, the configuration database 72b can be configured to store data and other information that specifically identifies or addresses various devices or components and their interconnections that plant personnel desire to be implemented in the process plant floor or field environment 122. Some of this commissioning data may be provided to components within the field environment 122 for use in commissioning the devices and loops therein, and some of this data may be utilized in the backend environment 125 for, e.g., preparing design, development, and control modules and / or operator interface modules that operate in conjunction with the field environment 122 during operation of the process plant 5. In one example, an approved control module is downloaded to a process controller (e.g., in the EIOC network 7), such that when executed during live operation, the process controller operates in accordance with its resident control module to send and receive various signals to / from other components within its loop (and, in some cases, to / from other process controllers), thereby controlling at least a portion of the process within the process plant 5.

[0090] The configuration database 72b can store some logical identifiers (or tags) of components within the field environment 122, enabling the controller 11 and other devices to reference components and signals associated with the components by the logical identifiers.

[0091] For example, for a given field device, the configuration database 72b can store information that maps or associates a logical identifier to a specific hardware address or I / O channel. The hardware address can identify a specific controller, a specific I / O card connected to the specific controller, and / or a specific address for an I / O channel that connects the specific I / O card to the field device. In the case of an EIOC and the associated field device, the database 72b can store the address of each logical identifier (e.g., tag or DST) that identifies a specific controller, a specific EIOC connected to the specific controller, and / or a specific message location of an EIOC message transmitted or received by the specific EIOC for which the value of the logical identifier is expected to be held.

[0092] In some cases, this mapping or binding can be stored in the controller 11, the user interface device 75, the operator workstation 71, or any other desired device (e.g., any device that needs to resolve logical identifiers). After the logical identifier is associated with a hardware address or I / O channel, the identifier is considered to be "assigned". In some cases, the system 5 includes "unassigned" logical identifiers, which are identifiers that software elements (e.g., control routines or function blocks) reference but do not have an association. That is, a logical identifier is considered "unassigned" when the system 5 and the configuration database 72b do not have a hardware address or I / O channel associated with the tag. Thus, when an unassigned logical identifier is referenced by a control routine, the value carried by the signal within the plant 5 will not be read, and commands will not be sent through the field devices within the plant 5. Each tag within the database 72b can be collectively referred to as a "system tag". Exemplary types of tags stored in the configuration database 72b and that can be used by the plant 5 include physical device tags (PDT), device signal tags (DST), logical device tags (LDT), and I / O nodes or node tags (also sometimes called EIOC nodes or node tags).

[0093] PDT represents a specific device, controller, valve, or other physical field device. DST represents a specific signal that is received or generated by a specific device and is typically used by a field device. In some devices, DST includes a combination of the device's PDT and an identifier for the specific signal received or generated by that device, e.g., an identifier for a specific parameter referenced by a control module. In some devices (e.g., legacy or dumb devices), PDT represents both the physical device and the signal generated by the device. Generally speaking, the logical identifier of a device is used by the process plant 5 in both the field environment 122 and the back-end environment 125 to uniquely identify the device.

[0094] Generally speaking, LDT can be considered to represent a group of related DSTs. For example, a set of 10 diagnostic parameters for a specific physical device can each be given a single LDT indicating that each of the 10 diagnostic parameters is a diagnostic parameter.

[0095] Finally, each EIOC node or node tag represents a unique EIOC. Thus, a given EIOC connected to six field devices can be associated with a specific node tag (e.g., EIOC04), and each of the six field devices connected to the EIOC can be assigned a node tag. As a result, a single process variable can have (i) an assigned DST (identifying a specific signal), (ii) an assigned LDT (identifying the logical group to which the DST or parameter belongs), (iii) an assigned DT or PDT (identifying the specific field device that receives or transmits the specific signal), and (iv) an assigned EIOC node (identifying the specific EIOC linked to the specific field device).

[0096] In some cases, the smart field devices 19 - 22 may also store a "source tag" or "source identifier" unique to the smart field devices 19 - 22 (similarly, the smart field devices of the EIOC network 7). These sources may be different from the system tags stored in the configuration database 72b and used by the plant 5 to identify field devices. Depending on the implementation, the source tags may or may not be stored in the configuration database 72b.

[0097] 3. Exemplary control routine 200 that can be seen in the process control system 5 FIG. 2 shows a control routine 200 representing an example of a control routine 38 that can be implemented by the controllers shown in FIGS. 1A and 1B.

[0098] Broadly speaking, the control routine 200 attempts to control the process 201 by driving a control variable (CV) (e.g., water tank level) to a specific setpoint. The control routine 200 receives a setpoint (SP) or desired value 212 for the CV (the CV may also simply be called a process variable or PV), measures the actual value 214 of the CV, calculates the error or difference 216 between the SP and the measured CV value, and then calculates a command or controller output (e.g., manipulated variable (MV) 226) for which the CV responds (e.g., the inlet valve position to the tank), based on, for example, the sum 224 of a proportional coefficient 218, an integral coefficient 220, a derivative coefficient 222, or some combination thereof. The controller can send the value 226 (e.g., actuator position) via the AO block 208 to an appropriate MV (e.g., actuator) to drive the CV232 (e.g., temperature, level, or flow variable) to the SP value 212. As shown, the CV232 within the process 201 may be affected by one or more parameters outside the direct control of the loop 200. These parameters may be referred to as disturbance variables (DV) 236.

[0099] As shown, control routine 200 includes four blocks, analog input (AI) block 202, AI block 204, control block 206, and AO block 208. Depending on the implementation, AI blocks 202 and 204 can represent analog signals received via an I / O channel (e.g., from a field device) by a controller implementing routine 200 or an I / O card coupled to the controller. For example, AI block 204 can be restricted to a first device signal tag (DST) that identifies a particular AI I / O channel in a first I / O card, and the value provided by AI block 204 can be driven by the value of a signal on a particular AI I / O channel (e.g., a 4 - 20 ma signal provided by a flow transmitter field device representing a measured flow rate). Similarly, AO block 208 can represent analog signals transmitted via an I / O channel (e.g., to a field device) by a controller implementing routine 200 or an I / O card coupled to the controller. By way of illustration, AO block 208 can be restricted to a second DST that identifies a particular AO I / O channel in a second I / O card. Thus, the value supplied to AO block 208 can cause the second I / O card to drive a signal on a particular AO I / O channel based on the value received in AO block 208 (e.g., the value can cause the second I / O card to drive a 4 - 20 ma signal via the AO I / O channel to a valve field device to control the position of the valve).

[0100] As an example, routine 200 can be configured to control field device 131 and can be implemented by controller 111 shown in FIG. 1A. In such an example, when controller 111 writes the value of DST to AO block 208, controller 111 can send the DST value to EIOC 126 and cause EIOC 126 to send the value to field device 131 via link 142 via an EIOC message (e.g., the value is encapsulated within a field device input message).

[0101] Similarly, field device 131 can send a measured value or other parameter as part of an EIOC message to EIOC 126 via link 142 (e.g., the measured value is encapsulated within a field device output message). Next, EIOC 126 can map the measured value or parameter to DST or another system tag. Routine 200 can receive the measured value at AI block 204.

[0102] C. Exemplary conventional I / O network 300 that can be seen in process control system 5 FIG. 3 shows a prior art I / O network 300 that includes conventional I / O cards 156 that, unlike EIOC 126, require fixed, dedicated, and manually configured wiring and marshaling based on the signal types that each I / O card 156 is configured for.

[0103] The EIOC network 7 offers several advantages compared to conventional I / O networks such as network 300. For example, the EIOC network 7 does not require cross - marshalling, thus avoiding the configuration process that involves time and effort associated with the conventional network 300. Instead, the EIOC network 7 enables a single EIOC to be connected to multiple field devices of any suitable signal configuration (e.g., AI, AO, DI, DO, RTD, TC, smart field devices, "dam" field devices, etc.). Further, the EIOC network 7 avoids the inefficient deployment of I / O cards often associated with conventional I / O networks such as network 300. Due to the fact that conventional I / O cards need to be configured for specific signal types respectively, conventional I / O networks often have multiple I / O cards with unused I / O channels, but each EIOC of the EIOC network 7 can be linked to any suitable field device and can transmit / receive any suitable parameter type.

[0104] Regarding the I / O network 300, broadly speaking, manual or direct marshalling is a labor - intensive process that involves wiring the I / O terminals or connectors of each field device to specific terminal blocks within a marshalling cabinet, wiring each I / O card channel to the terminal blocks of a field terminal array or FTA (located in the marshalling cabinet) dedicated to that I / O card, and coupling the I / O connectors of the field devices to the I / O cards by cross - marshalling the terminal blocks within the marshalling cabinet and the FTA.

[0105] Typically, each conventional I / O card 156 is permanently configured for a single signal type selected from a plurality of signal types (e.g., AO, AI, DI, DO, resistance temperature detector (RTD), or thermocouple (TC)). For example, I / O card 156 is permanently configured for the AI signal type and cannot be configured or reconfigured to communicate according to the AO, DI, DO, RTD, or TC signal types.

[0106] I / O network 300 includes process controller 158A, redundant backup controller 158B (collectively referred to as "controller 158"), and conventional I / O cards 156A - F, which are communicatively connected to a set of field devices 152A - K via marshalling cabinet 150, a set of field junction boxes (FJB) 154A - D, and several wired links 181A, 181B, and 183.

[0107] I / O network 300 enables process controller 158 to control a process or part of a process via one or more field devices 152. Unfortunately, the design of I / O network 300 lacks flexibility, is difficult to change after field wiring is complete, and makes project changes expensive in terms of labor, time, and materials.

[0108] During the design phase of I / O network 300, a process and instrumentation diagram (P&ID) is designed to provide an initial view of the control elements (e.g., field devices 152) and how they are intended to be used in a control strategy that includes network 300. Next, an equipment list is derived from these P&IDs, which is a detailed list of each element (e.g., field device) in the design, including device type, manufacturer, calibration range, etc., as well as the physical location of each element within the process equipment. As part of the design phase, the designer defines the field signals associated with each field device 152 and assigns each assigned signal to a controller.

[0109] As shown in FIG. 3, each of the field devices 152 has one or more I / O terminals 161-176 for transmitting or receiving signals, and each of the terminals 161-176 has a specified signal type (e.g., AO, AI, DI, or DO). For clarity, from the perspective of the control system, the terminals are labeled "input" or "output". For example, the field devices including terminals 161, 164, 166, 167, and 172 are each configured to transmit an analog input or "AI" signal (e.g., carrying a process measurement value) via the terminals. The field devices including terminals 162, 163, and 168 are each configured to receive an analog input or "AO" signal (e.g., carrying a control command such as a command to open a valve) via the terminals. The field devices including terminals 169 and 176 are each configured to transmit a digital input or "DI" signal via these terminals. The field devices including terminals 165, 170, 171, 173, 174, and 175 are each configured to transmit an individual output or "DO" signal via these terminals.

[0110] As shown in FIG. 3, each of the signals associated with terminals 161-176 is assigned to the controller 158. The signal count of each type of signal specified for terminals 161-176 enables the designer to determine the number and type of each I / O card 156 necessary for the controller 158 to communicate with each of the inputs and outputs of the field device 152.

[0111] Each I / O card 156 has (i) a limited number of I / O channels and (ii) is configured for a specific type of signal and can only be used for that type of signal, so it is important to select the I / O card. Note that the term "I / O channel" generally refers to the logical link that connects the I / O card or controller to the field device. Conventional I / O cards 156 are limited to four I / O channels, but note that some dedicated conventional I / O cards have different limitations (e.g., eight channels) with respect to the I / O channels. As mentioned above, each I / O card 156 is configured for a specific type of signal and can only be used for that type of signal. As an example, the AI I / O card 156A can only transmit AI signals. It cannot transmit DI signals or receive DO or AO signals. This requirement, along with the requirement that each I / O card 156 supports only a maximum of four channels, results in unused and wasted terminal blocks. For example, five of the field device terminals 161-176 are configured to transmit AI signals, which requires two I / O cards 156 despite the fact that one of the I / O cards 156 has three unused channels or blocks.

[0112] To build the network 300, it is first necessary to design the network. Next, the engineer starts the field wiring phase of the development. The I / O terminals 161-176 are wired to the corresponding field junction boxes FJB154A-154D, which are then wired to a set of terminals 192 in the marshalling cabinet 150. Note that each of the terminals 161-176 is connected to the corresponding terminal in the FJB and the corresponding terminal 192 in the marshalling cabinet 150. That is, for all existing I / O terminals 161-176, the corresponding terminal 192 must be used. The set of terminals 192 is wired to the field terminal assemblies (FTAs) 194A-194F, and each FTA is wired to the corresponding I / O card 156A-F.

[0113] The process of wiring terminal 192 to FTA 194 is called "cross-mashing". While the wiring of the wires connected to terminal 192 is determined by the physical layout of the plant, the wiring of FTA 194 is determined by the signal type of the conventional I / O card 156 connected to the FTA. Therefore, cross-mashing is usually necessary. Specifically, field devices sharing proximity often share an FJB and are wired to the first available terminal 192, resulting in a grouping of terminal 192s that roughly correspond to the FJB but have no other distinguishable wiring method. In contrast, FTA 194 is wired by signal type because each supplies a specific I / O card 156. For example, FTA 194A corresponds to AI card 156A. Therefore, each of the terminals 194A needs to be connected to a terminal 192 that is connected to an AI channel (i.e., wired to an AI field device terminal). Similarly, since FTA 194C corresponds to AO card 156C, each terminal of FTA 194C should be wired to a terminal 192 that is wired to an AO channel (i.e., connected to an AO field device terminal). Similarly, the terminals of FTA 194D need to function as an interconnection between DI card 156D and the terminals 192 that are wired to DI field device terminals.

[0114] It should be noted that the channel limitations associated with dedicated conventional I / O cards 156 result in an inefficient deployment of the I / O cards and the associated cabinet space within the unused I / O channels, terminal blocks, and marshalling cabinet 150. Since each I / O card 156 supports only four channels, it is necessary to install two AI cards 156A and 156B and connect them to the controller 158, and it is necessary to utilize two corresponding FTAs 194A and 194B. For example, FTA 194B includes three unused terminals, and I / O card 156B has three unused I / O channels due to signal count requirements and the limitations of dedicated I / O card 156. This imperfect match between the signal requirements of field device 152 and the limitations of I / O card 156 results in an inefficient deployment of I / O card 156. Despite the fact that 16 signals are assigned to controller 158, controller 158 requires six dedicated I / O cards. If the signal counts were perfectly distributed for each type, controller 158 would require only four I / O cards. As described above, since EIOC network 7 can link each EIOC to any suitable EIOC field device, these problems regarding channel limitations do not occur.

[0115] D. Exemplary EIOC Assembly 400 of EIOC 126 FIG. 4 is a perspective view of an EIOC assembly 400 for EIOC 126 of the EIOC network 7 shown in FIGS. 1A and 1B. The assembly 400 can be attached to a backplane including a communication bus or channel. The controller 111 can also be attached to the backplane and communicate with the EIOC 126 via a bus (e.g., link 141 shown in FIG. 1A).

[0116] Assembly 400 includes an EIOC connector or terminal 407. A communication link to EIOC 126 (e.g., from a switch, router, or field device) can be configured by connecting a physical link (e.g., link 142 shown in FIG. 1A or any suitable CATx or Ethernet cable) to any of terminals 407. As shown, terminals 407 are configured according to the RJ45 standard and can facilitate interconnection with other cables or links having RJ45 connectors. Any one or more of links 142 - 145 can be or include an Ethernet link with RJ45 connectors for terminating at both ends. Similarly, each of field devices 131 - 135 and switch 128 can facilitate connection to links 142 - 145 via RJ45 connectors.

[0117] II. Exemplary method 500 for facilitating configuration of a process control system to integrate EIOC field devices and associated field device variables FIG. 5 is a flowchart of an exemplary method 500 for facilitating configuration of process control system 5 via decoder file 199 for field device 131 and EIOC scanner 75 (shown in FIG. 1A) that integrates field device variables configured to be transmitted or received by field device 131 to process control system 5. Method 500 can be implemented, in whole or in part, by the system(s) shown in FIG. 1A and can be stored in memory as one or more instructions or routines (e.g., of EIOC scanner 75). That being said, it will also be understood that method 500 can be implemented with respect to any suitable process control system, EIOC field device, decoder file, or EIOC scanner.

[0118] Method 500 begins at step 505 when scanner 75 analyzes decoder file 199 to identify message positions (for messages transmitted or received via link 142) mapped to field device variables of field device 131. The positions can be offset with respect to a header or any suitable delimiter character within the message on link 142. For example, the first byte within a message can represent the variable value of a first command or a first variable. The second byte within the message can represent the variable value of a second command or a second variable, and so on.

[0119] In an embodiment, decoder file 199 can specify any suitable technique for decoding field device variable values from messages transmitted between field device 131. For example, in an embodiment, a form of time division multiplexing can be utilized. That is, the variables represented within a message or by a given message position can depend on the number of active time slots (which can be determined from decoder file 199). Of course, in such an embodiment, EIOC 126 and field device 131 can be clock synchronized to coordinate appropriate messaging.

[0120] At step 510, scanner 75 generates a data set mapping system tag representing a process variable to the message position of a field device variable configured for field device 131 to read or write. Said another way, the data set is generated to create a process variable representing the same type of command (e.g., a desired valve position), measurement (e.g., a measured temperature), or parameter (e.g., a diagnostic parameter representing the status of field device 131).

[0121] The set of field device variables identified in decoder file 199 can include various types of variables including: a default field device ID (which can be mapped to a PDT within a data set); one or more field device signal variables representing a specific command or parameter received by field device 131, or a measurement or other parameter transmitted by field device 131 (which can be mapped to a DST within a data set); or one or more group variables that specify a logical group of field device signal variables (which can be mapped to an LDT within a data set).

[0122] Optionally, scanner 75 can present a user interface for manipulating data set mapping system tags to field device variables. Exemplary user interfaces are described in more detail below with reference to FIGS. 10-12. Briefly, the user can change or specify various fields such as a field (e.g., in this case, a tag unique to EIOC 126) indicating the node to which field device 131 is assigned (e.g., a tag of a specific EIOC); the name of the system tag; parameters associated with the system tag (type, message location, input vs. output, etc.).

[0123] In step 515, scanner 75 uploads the data set to configuration system 72. Configuration system 72 stores the data set in configuration database 72b, thereby formally assigning the system tags of the process variables to the appropriate communication channels (e.g., the EIOC message location associated with field device 131).

[0124] In step 520, process control system 5 is configured according to configuration system 72. This configuration process makes new system tags associated with field device 131 addressable (i.e., readable or writable) by devices within control system 5 (e.g., controller 111, EIOC 126, other field devices 131 - 135 and 15 - 22; data historian 73, etc.). As a result, control routines (e.g., 38, 200) implemented by the controller of process control system 5 can implement process control by referring to the system tags.

[0125] In some cases, method 500 can be implemented to configure the process control system based on an updated decoder file of a field device already functioning within the process control system. For example, a manufacturer or developer of an existing field device within the process control system can publish a new or updated decoder file for the field device (e.g., new variables, updated variable characteristics, new functions of the field device, new firmware, etc.). To obtain the advantages or updates associated with the updated decoder file, scanner 75 can analyze the updated decoder file and update configuration system 72 accordingly.

[0126] III. Exemplary protocol stacks 600 - 900 for EIOC network 7 Figures 6 - 9 show exemplary protocol stacks 600 - 900 for protocols that can be implemented by EIOC network 7 and EIOC 126. Briefly, as shown by stacks 600 - 900, messages transmitted between EIOC 126 and EIOC field devices 131 - 135 conform to one or more EIOC protocol stacks (e.g., stack 600, 800, or 909), and messages conforming to typical process control standards or protocols are wrapped in a TCP / IP wrapper (e.g., Modbus TCP, CIP, Ethernet / IP).

[0127] Figure 6 shows an exemplary protocol stack 600 that can be used to encapsulate a process control message conforming to a process control standard or a protocol such as Modbus / TCP within a message conforming to a standard protocol selected from the Internet protocol suite.

[0128] Stack 600 includes layers 601 - 607 that conform to protocols from the following Internet protocol suite: the IEEE802.3 Ethernet protocol for the physical layer 601, the IEEE802.2 protocol for the data link layer 603, the Internet protocol (IP) for the IP layer 605, and the Transmission Control Protocol (TCP) for the TCP layer 607.

[0129] Stack 600 also includes a protocol 608 (e.g., the Modbus / TCP protocol) for the intermediate layer 609 between the TCP layer 607 and the application layer 611. Generally speaking, a message transmitted according to protocol 608 is a Modbus message that is transmitted within a TCP / IP wrapper and transmitted over the network. That is, protocol 608 encapsulates a data unit (e.g., in this case, a Modbus message) from the application layer 611, adds metadata, and creates a data unit within layer 609 that can be encapsulated and transmitted according to a standard protocol from the Internet protocol suite (e.g., TCP, UDP).

[0130] Figure 7 shows function codes 701 commonly used in messages transmitted according to protocol 608. These codes can be utilized by either the EIOC126 or any of the field devices 131 - 135 to read or write any desired process control variable or parameter (e.g., an actuator command; measurements such as temperature, flow, pressure, level; diagnostic parameters, etc.).

[0131] Figure 8 is an exemplary protocol stack 800 that includes a Common Industrial Protocol (CIP) stack 809 encapsulated within a typical TCP / IP or UDP / IP stack 807. Generally speaking, any reference herein to TCP / IP or a "TCP / IP stack" is understood to refer to UDP / IP as well. The EIOC 126 and field devices 131 - 135 can send and receive messages according to protocol stack 800.

[0132] Stack 809 represents a set of protocols within stack 800 for process control communication that can be encapsulated within a message configured according to a typical TCP / IP stack 807. Generally speaking, stack 809 encompasses a comprehensive suite of messages and services for automation applications. For example, there are two types of message connections: implicit and explicit. An explicit message connection is a point - to - point relationship established to facilitate a request / response transaction between two nodes. These connections use TCP / IP services to send messages according to the Ethernet standard. Implicit message connections can periodically move I / O data for a particular application. They can transfer data via a link compliant with the Ethernet standard using a multicast producer - consumer model and UDP / IP services.

[0133] Figure 9 is an exemplary protocol stack 900 that includes an IEC 61850 stack 900. Process control communication formatted according to stack 909 can be encapsulated within a message compliant with a typical TCP / IP or TCP / UDP stack 907. The EIOC 126 and field devices 131 - 135 can send and receive messages according to protocol stack 900.

[0134] Generally speaking, IEC 61850 is an international standard that defines the communication protocol for intelligent electronic devices in substations. It is part of the reference architecture of Technical Committee 57 of the International Electrotechnical Commission (IEC) for power systems. The abstract data model defined in IEC 61850 can be mapped to several protocols. The current mappings of the standard are for MMS (Manufacturing Message Specification), GOOSE (Generic Object Oriented Substation Event), SMV (Sampled Measured Values), etc. These protocols can be run on a TCP / IP network or a substation LAN using fast switched Ethernet.

[0135] In some embodiments, EIOC126 and field devices 131 - 135 can be configured to communicate with field devices via the HART-IP protocol and can be configured to implement method 500 of utilizing HART-IP communication. That is, the EIOC scanner 75 can analyze the decoder file of the HART-IP field device and can be configured to facilitate the configuration of the process control system 5 accordingly. In some embodiments, EIOC126 may not be HART-IP compatible and the EIOC scanner 75 may not be configured to facilitate the integration of the HART-IP field device into the process control system 5.

[0136] IV. Exemplary UIs 1000 - 1200 that can be presented by the EIOC scanner 75 Figures 10 to 12 show exemplary UIs 1000 to 1200 that can be presented by the EIOC scanner 75 to facilitate the configuration of the process control system 5 based on the decoder file 199. The UIs 1000 to 1200 can be displayed by the scanner 75 after analyzing the decoder file 199, and the user can display or edit properties related to the system tags and the field device variables mapped to the system tags. As an example, the user can use the UIs 1000 to 1200 to edit the names and properties associated with the PDT, LDT, DST, and nodes (each representing a system tag) that are generated and mapped to the field device variables associated with the field device 131.

[0137] In some cases, the user can use the UIs 1000 to 1200 to add I / O nodes (as described above, each node represents a specific EIOC). For example, as shown by the UI 1100 in FIG. 11, the user can then specify the name; type; protocol (e.g., CIP, IEC 61850, Modbus TCP, etc.) by which the node / EIOC is to be configured.

[0138] Before moving on to the details of FIGS. 10 to 12, it should be noted that the phrase "user interface" or "UI" refers to a component of a computer system for a user to interact with the computer system. The UI component can be hardware, software, or some combination thereof, and can include a UI input component, a UI output component, or some combination thereof. In some embodiments, any one or more of the UI components 104 shown in FIG. 1B can include any one or more of the exemplary UI components listed below.

[0139] Exemplary UI output components include (i) visual output components such as lights (e.g., LEDs) and electronic displays (e.g., LCDs, LEDs, CRTs, plasmas, projection displays, head-up displays, etc.), (ii) audio output components such as speakers, and (iii) movement generation components such as motors that provide tactile feedback.

[0140] Exemplary UI input components include (i) mechanical or electrical components for detecting physical or touch inputs such as hardware actuators (e.g., those used in keyboards, mice, tablets or the "hard" buttons found on phones) or electrical sensors (e.g., resistive or capacitive touch sensors), (ii) audio sensors (e.g., microphones) for detecting audio inputs such as voice commands, (iii) image sensors for detecting image or video inputs such as those found in cameras (e.g., enabling face recognition input or gesture input without the user having to touch the device), and (iv) movement sensors (e.g., accelerometers, gyroscopes, etc.) for detecting the movement of the computer system itself (e.g., enabling the user to provide input by rotating or otherwise moving the computer system).

[0141] The EIOC scanner 75 can provide a graphical user interface (GUI) via the display 107 of the UI104. Generally speaking, the GUI is generated via routines (such as the scanner tool 113) and enables the user to interact with indicators and other graphic elements displayed on the electronic display. Generally speaking, the graphic elements of the GUI can be GUI output elements (i.e., those that convey some information to the user), GUI control elements (i.e., those that are "interactive" for the user to cause the execution of actions by the system), or both (e.g., an icon can include an image representing a browser and can be interacted with to launch the browser). Exemplary GUI control elements include buttons (such as radio buttons, check boxes, etc.) that can be moved or minimized and maximized, sliders, list boxes, spinner elements, drop-down lists, menus, menu bars, toolbars, interactive icons, text boxes, windows, and the like.

[0142] Referring to FIG. 10, the UI1000 can be presented by the scanner 75 to enable the user to add, edit, or view any of several system tags (such as DST, PDT, LDT, node tags) that are assigned to field device variables identified from a decoder file 199 (e.g., each associated with a specific message position within an EIOC message transmitted or received by the field device 131).

[0143] As shown in FIG. 11, the scanner 75 can present the UI1100 to enable the user to add, edit, or view the EIOC node tags (such as the node tag specific to EIOC126) associated with variables imported from the decoder file.

[0144] As shown in FIG. 12, the UI 1200 can be presented by the scanner 75 to enable a user to add, edit, or view PDTs associated with one or more variables imported from the decoder file 199. In some cases, the decoder file 199 includes default field device IDs or PDTs, and the scanner 75 can import the default PDTs into the UI 1200. In some cases, the user may want to assign a PDT different from the default value (for example, when the default PDT is already assigned to a device in the process control system 5, or when the default PDT does not comply with the naming criteria associated with the process control system 5). As shown, the user can use the UI 1200 to specify the name, description, index, and various other attributes of each PDT.

[0145] V. Additional Considerations When implemented in software, any of the applications, services, and engines described herein can be stored in any tangible non-transitory computer-readable memory, such as a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium in the RAM or ROM of a computer or processor. The exemplary systems disclosed herein are disclosed as including software or firmware executed on hardware among other components, but it should be noted that such systems are merely exemplary and should not be considered limiting. For example, any or all of these hardware, software, and firmware components can be embodied solely in hardware, solely in software, or in any combination of hardware and software. Accordingly, while the exemplary systems described herein are described as being implemented in software executed by a processor of one or more computer devices, those skilled in the art will readily recognize that the examples provided are not the only way to implement such systems.

[0146] Referring to method 500, the described functionality can be implemented, in whole or in part, by the devices, circuits, or routines of process control system 5 shown in FIG. 1B. Method 500 can be embodied by a set of circuits that are permanently or semi-permanently configured (e.g., ASIC or FPGA) to perform the logical functions of each method, or at least temporarily configured (e.g., one or more processors and a set of instructions or routines stored in memory that represent the logical functions) to perform the logical functions of each method.

[0147] Although the present invention has been described with reference to specific examples, these are merely illustrative and are not intended to be limiting of the present invention. It will be apparent to those skilled in the art that changes, specific additions, or deletions can be made to the disclosed embodiments without departing from the spirit and scope of the present invention. Further, while the above description sets forth details of many different embodiments, it should be understood that the scope of this patent is defined by the words of the claims set forth at the end of this patent and their equivalents. The detailed description should be construed as merely illustrative, and it is not possible, even if not unrealistic, to describe all possible embodiments, so not all possible embodiments are described.

[0148] Throughout this specification, multiple instances can implement components, operations, or structures described as a single instance. Although the individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed simultaneously in a particular embodiment.

[0149] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification are not necessarily all referring to the same embodiment.

[0150] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0151] Furthermore, the phrase "the system includes at least one of X, Y, or Z" means that the system includes X, Y, Z, or some combination thereof. Similarly, the phrase "the component is configured for X, Y, or Z" means that the component is configured for X, for Y, for Z, or for some combination of X, Y, and Z.

[0152] In addition, the use of "a" or "an" is employed to describe the elements and components of the embodiments of this specification. This description, and the claims that follow, should be read to include one or at least one. The singular form also includes the plural form unless it is clear that it does not include the plural form.

[0153] Furthermore, the claims at the end of this document are not intended to be construed under 35 U.S.C. § 112, paragraph (f), unless a traditional means-plus-function recitation is expressly recited in a claim, such as where the phrase "means for" or "step for" is expressly recited in the claim(s). At least some aspects of the systems and methods described herein are directed to improvements in computer capabilities and improvements in the capabilities of conventional computers.

[0154] VI. Terms and Phrases Throughout this specification, some of the following terms and phrases are used.

[0155] Communication protocol. In this description, communication protocols, standards, and technologies may generally be referred to as "communication protocols". Exemplary communication protocols, standards, or technologies that can be utilized by the systems described include those that facilitate communication over nanoscale networks, near-field networks, personal area networks ("PANs"), local area networks ("LANs"), backbone networks, metropolitan area networks ("MANs"), wide area networks ("WANs"), Internet area networks ("IANs"), or the Internet.

[0156] Examples of protocols and specifications for short-range field networks include typical radio frequency identification (“RFID”) specifications or protocols, and near field communication (“NFC”) protocols or specifications. Examples of PAN protocols and specifications include 6LoWPAN, Bluetooth (i.e., a wireless standard for exchanging data between two devices using radio waves in the range of approximately 2.4 to 2.485 GHz), IEEE802.15.4-2006, ZigBee, Thread protocol, ultra-wideband (“UWB”), universal serial bus (“USB”), wireless USB, and ANT+. Examples of LAN protocols and specifications include the 802.11 protocol and other high-frequency protocols / systems for wireless communication in bands in the range of approximately 1 GHz to 60 GHz (including, for example, the 900 MHz, 2.4 GHz, 3.6 GHz, 5 GHz, or 60 GHz bands), as well as specifications for suitable cables such as coaxial cables and optical fiber cables. Examples of technologies used to facilitate wireless WANs include the technologies used for LANs, as well as 2G (e.g., GPRS and EDGE), 3G (e.g., UMTS and CDMA2000), 4G (e.g., LTE and WiMAX), and 5G (e.g., IMT-2020) technologies. Note that the Internet may be considered a WAN.

[0157] Other communication protocols and standards that may be utilized include BitTorrent, Bluetooth Bootstrap Protocol (BOOTP), Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Ethernet, File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), infrared communication standards (e.g., IrDA or IrSimple), Transmission Control Protocol / Internet Protocol (TCP / IP) (e.g., any of the protocols used at each of the TCP / IP layers), Real-Time Transfer Protocol (RTP), Real-Time Streaming Protocol (RTSP), Simple Mail Transfer Protocol (SMTP), Simple Network Management Protocol (SNMP), Simple Network Time Protocol (SNTP), Secure Shell Protocol (SSH), and any other communication protocol or standard, or any combination thereof.

[0158] Communication link. Unless otherwise specified, a "communication link" or "link" is a path or medium that connects two or more nodes. A link can be a physical link or a logical link. A physical link is an interface or medium (s) over which information is transferred and can be either wired or wireless in nature. Examples of physical links include (i) wired links such as cables with conductors for transmitting electrical energy or fiber optic connections for transmitting light, and (ii) wireless links such as radio electromagnetic signals that convey information through modifications applied to one or more characteristics of the electromagnetic wave.

[0159] As described above, a wireless link can be a wireless electromagnetic signal that conveys information via a modification applied to one or more characteristics of an electromagnetic wave(s). The wireless electromagnetic signal can be a microwave or a radio wave and can be referred to as a radio frequency or “RF” signal. Unless otherwise specified, the RF signals described can oscillate at frequencies within any one or more bands found in a spectrum of approximately 30 kHz to 3,000 GHz (e.g., an 802.11 signal in the 2.4 GHz band). Examples of RF bands include a low frequency (“LF”) band of 30 to 300 kHz, a medium frequency (“MF”) band of 300 to 3,000 kHz, a high frequency (“HF”) band of 3 to 30 MHz, a very high frequency (“VHF”) band of 30 to 300 MHz, an ultra-high frequency (“UHF”) band of 300 to 3,000 MHz, a super high frequency (“SHF”) band of 3 to 30 GHz, a millimeter wave frequency (“SHF”) band of 30 to 300 GHz, and a tremendously high frequency (“THF”) band of 300 to 3,000 GHz.

[0160] A logical link between two or more nodes represents an abstract concept of an underlying physical link or intermediate nodes that connect two or more nodes. For example, two or more nodes can be logically coupled via a logical link. A logical link can be established via any combination of physical links and intermediate nodes (e.g., routers, switches, or other network devices).

[0161] A link is sometimes referred to as a "communication channel". In a wireless communication system, the term "communication channel" (or simply "channel") generally refers to a specific frequency or frequency band. A carrier signal (or carrier wave) can be transmitted at a specific frequency or within a specific frequency band of a channel. In some cases, multiple signals may be transmitted on a single band / channel. For example, signals may sometimes be transmitted simultaneously on a single band / channel via different sub-bands or sub-channels. As another example, signals may sometimes be transmitted via the same band by allocating time slots, with each transmitter and receiver using the said band.

[0162] Computer. Generally speaking, a computer or computing device is a programmable machine having two main characteristics. That is, it can respond to a set of instructions in a well-defined manner and execute a pre-recorded list of instructions (e.g., a program or routine). The computer according to the present disclosure is a device equipped with a processor and a memory. For the purposes of the present disclosure, examples of computers include server hosts, personal computers (e.g., desktop computers, laptop computers, netbooks), mobile communication devices (such as mobile "smart" phones), and devices that provide functions through connections to internal components or external computers, servers, or global communication networks (such as the Internet) and receive instructions from or participate in processes distributed to other system components.

[0163] Database. Generally speaking, a "database" is an organized collection of data, generally stored and accessed electronically from a computer system. Generally, any suitable data store may be referred to as a "database". The present disclosure can describe one or more databases for storing information related to aspects of the present disclosure. The information stored in the database can be related to, for example, private subscribers, content providers, hosts, security providers, etc. A server (which may or may not be hosted on the same computer as the database) can function as an intermediary between the database and the client by providing data from the database to the client or enabling the client to write data to the database. Those skilled in the art will understand that references to a "database" can refer to multiple databases, and each of them can be linked to each other.

[0164] Display device. Generally speaking, the term "display device" or "display" refers to an electronic visual display device that provides visual output in the form of images, text, or video. In some embodiments, the described display device (e.g., X, Y, Z) can be any display, screen, monitor, or projector suitable for displaying visual output (e.g., image or video output). Examples of displays include LED screens, LCD screens, CRT screens, projectors, head-up displays, smartwatch displays, headset displays (such as VR goggles), etc.

[0165] Memory and Computer-Readable Media. Generally speaking, the phrases "memory" or "memory device" as used herein refer to a system or device that includes a computer-readable medium or media ("CRM"). "CRM" refers to one or more media that are accessible by a related computing system for placing, holding, or retrieving information (e.g., data, computer-readable instructions, program modules, applications, routines, etc.). It should be noted that "CRM" means media that are essentially non-transitory and does not refer to intangible transient signals such as radio waves.

[0166] CRM can be implemented in any technology, device, or group of devices that are included within or communicate with the related computing system. CRM can include volatile or non-volatile media, and removable or non-removable media. CRM can include, but is not limited to, RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other media that can be used to store information and can be accessed by a computing system. CRM is communicatively coupled to the system bus and enables communication between CRM and other systems or components coupled to the system bus. In some implementations, CRM can be coupled to the system bus via a memory interface (e.g., a memory controller). The memory interface is a circuit that manages the flow of data between CRM and the system bus.

[0167] Message. When used in the context of a communication network, the term "message" refers to a unit of communication represented by a set of data sent or received by a node (e.g., via a link). The set of data representing a message can include a payload (i.e., the content intended to be delivered) and protocol overhead. The overhead can include routing information and metadata related to the protocol or payload (e.g., identification of the message's protocol, the destination recipient node, the originating node, the size of the message or payload, data integrity information messages for checking the integrity, etc.). In some cases, a packet or a sequence of packets may be considered a message.

[0168] Module. When used in the context of a software system, the term "module" generally refers to a set of applications, routines, or executable instructions. See also "routine". In some cases, the term "module" refers to a component of a physical system (e.g., an automobile includes several modules such as an engine, a transmission, brakes, etc.). The context of use of this term clarifies whether "module" refers to a software component or a non-software component.

[0169] Network. As used herein, unless otherwise specified, when used in the context of a system(s) or device(s) for communicating information or data, the term "network" (e.g., the network or backbone 10 shown in FIG. 1B) refers to a collection of nodes (e.g., devices or systems capable of sending, receiving, or relaying information) and links connected to enable long-distance communication between the nodes.

[0170] Unless otherwise specified, each of the described networks may include a dedicated router, switch, or hub that is responsible for forwarding traffic between nodes, and optionally, a dedicated device responsible for network configuration and management. Some or all of the nodes within the described networks may also be adapted to function as routers to direct traffic transmitted between other network devices. The nodes of the described networks may be interconnected in a wired or wireless fashion, and the network devices may have different routing and forwarding capabilities. If desired, each of the described networks may include a network or subnetwork such as a personal area network (PAN), local area network (LAN), or wide area network (WAN).

[0171] Node. Generally speaking, the term "node" means a connection point, redistribution point, or communication endpoint. A node can be any device or system (e.g., a computer system) that can transmit, receive, or forward information. For example, an end device or system that originates or ultimately receives a message is a node. An intermediate device that receives and forwards a message (e.g., between two end devices) is also generally considered a "node".

[0172] Processor. The various operations of the exemplary methods described herein can be performed, at least in part, by one or more of the described or implicitly disclosed controllers or processors (e.g., the processor 102 shown in FIG. 1A). Generally speaking, the terms "processor" and "microprocessor" are used interchangeably and each refers to a computer processor configured to fetch and execute instructions stored in memory.

[0173] By executing these instructions, the disclosed processor(s) can perform various operations or functions defined by the instructions. The disclosed processor(s) may be temporarily configured (e.g., by instructions or software) or permanently configured to perform related operations or functions (e.g., a processor for an application-specific integrated circuit or ASIC) depending on a particular embodiment. Each disclosed processor may be a component of a chipset that can also include, for example, a memory controller or an I / O controller. A chipset is a collection of electronic components within an integrated circuit typically configured to provide I / O and memory management functions, as well as multiple general-purpose or dedicated registers, timers, etc. Generally speaking, one or more of the described processors can be communicatively coupled to other components (such as memory devices and I / O devices) via a system bus.

[0174] Reliable performance of operations can exist not only within a single machine but also be distributed among one or more processors deployed across several machines. For example, when a single processor is described as performing a set of operations, it is understood that in some embodiments, multiple processors can perform the set of operations according to any desired distribution across the multiple processors. In some embodiments, one or more processors can be present in a single location (e.g., within a home environment, within a workplace environment, or as a server farm), while in other embodiments, the processors may be distributed across a number of locations.

[0175] Words such as "processing", "computing", "calculating", "determining", "presenting", "displaying", etc. can mean the operation or process of a machine (e.g., a computer) that manipulates or transforms data represented as a physical (e.g., electrical, magnetic, or optical) quantity within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0176] Routine. Unless otherwise specified, the "routines", "modules", or "applications" described in this disclosure refer to a set of computer-readable instructions that can be stored in a CRM. For example, the scanner tool 113 is a routine that can be stored in a CRM. Generally, a CRM stores computer-readable code (the "code") that represents or corresponds to instructions, and the code is adapted to be executed by a processor to facilitate the functions described as being represented by or associated with a routine or application. Each routine or application can be implemented via a stand-alone executable file, a suite or bundle of executable files, one or more non-executable files utilized by an executable file or program, or some combination thereof. In some cases, unless otherwise specified, one or more of the routines described can be hard-coded in one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other hardware or firmware elements.

[0177] Furthermore, unless otherwise specified, each routine or application can be embodied as a (i) stand-alone software program, (ii) module or sub-module of a software program, (iii) routine or sub-routine of a software program, or (iv) resource that is called or accessed by a software program via a "call", thereby causing the system to perform a task or function associated with the resource.

[0178] Each routine described can be represented by code implemented in any desired language such as source code (e.g., interpretable for execution or compilable to lower-level code), object code, bytecode, machine code, microcode, etc. The code can be written in any suitable programming language or scripting language (e.g., C, C++, Java®, Actionscript, Objective-C, Javascript®, CSS, Python, XML, Swift, Ruby, Elixir, Rust, Scala, etc.).

[0179] Server. Generally speaking, a server is a set of programs or routines that manages network resources or services and provides functions to other programs or devices called "clients". A server is typically hosted by a host computer, and this host computer itself may be called a "server". Examples of servers include database servers, file servers, mail servers, print servers, web servers, game servers, and application servers. A server can be dedicated (e.g., software and hardware are used exclusively or almost exclusively for server functions) or virtual (e.g., when the server is hosted by a virtual machine on a physical machine and / or the server shares the hardware or software resources of a single machine with another operating system).

Claims

Claim 1 An electronic device for configuring an Ethernet I / O card in a process control environment, comprising: a processor; a communication interface coupled to the processor; a memory for storing instructions coupled to the processor, wherein when the instructions are executed by the processor, the processor is caused to: (i) analyze a decoder file for a field device configured to be coupled via an Ethernet link to an Ethernet I / O card (EIOCC) within a process control system, and map one or more field device variables to one or more message positions; (ii) generate a data set including one or more device signal tags (DSTs) each representing a process variable corresponding to a different one of the one or more field device variables mapped to the one or more message positions; (iii) when the process control system is configured according to a configuration database, upload the data set via the communication interface to the configuration database of the process control system such that the one or more DSTs correspond to the one or more message positions, whereby: (a) the EIOCC implements a controller output processing function configured such that (1) the EIOCC receives from a process controller a controller output message including a controller output value of a first DST, and (2) in response to the first DST, the controller output value is assigned to the mapped first message position according to the data set, such that the controller output value is transmitted from the EIOCC to the field device at the first message position of a field device input message transmitted to the field device, or (b) The EIOCC is configured to implement a controller input processing function that responds by: (1) receiving, from the field device, a field device output message including a controller input value at a second message position mapped to a second DST according to the data set; and (2) assigning the controller input value to the second DST such that the controller input value is transmitted from the EIOCC to the process controller as a value of the second DST as part of a controller input message. An electronic device.

2. The electronic device according to claim 1, wherein the EIOCC is configured to implement both the controller output processing function and the controller input processing function.

3. The electronic device according to claim 1 or claim 2, wherein the EIOCC and the field device are configured to transmit the field device input message and the controller input message in a time-adjusted manner such that each is transmitted during a different predetermined time slot.

4. The electronic device according to any one of claims 1 to 3, wherein each of the controller output message and the controller input message is configured to carry a plurality of parameter values.

5. The electronic device according to any one of claims 1 to 4, wherein the data set further includes one or more logical device tags (LDTs) mapped to a second one or more message positions.

6. The electronic device according to any one of claims 1 to 5, wherein the data set further includes one or more physical device tags mapped to a second one or more message positions.

7. The electronic device according to any one of claims 1 to 6, wherein the instructions further cause the processor to generate and display, via a display of the electronic device, a user interface for viewing or editing the data set including the one or more DSTs mapped to the one or more message positions.

8. The electronic device according to claim 7, wherein the user interface includes a field for specifying a node tag specific to the EIOCC associated with the data set.

9. The electronic device according to any one of claims 1 to 8, wherein the command further causes the processor to download the decoder file from a server associated with the field device before analyzing the decoder file.

10. The electronic device according to any one of claims 1 to 8, wherein the command further causes the processor to download the decoder file from the field device before analyzing the decoder file.

11. A method of configuring an Ethernet I / O card in a process control environment, comprising: (i) analyzing, by an electronic device, a decoder file of a field device configured to be coupled to an Ethernet I / O card (EIOCC) via an Ethernet link within a process control system, and mapping one or more field device variables to one or more message positions; (ii) generating, by the electronic device, a data set including one or more device signal tags (DSTs) each representing a process variable corresponding to a different one of the one or more field device variables mapped to the one or more message positions; (iii) uploading the data set to the configuration database of the process control system such that the one or more DSTs correspond to the one or more message positions, thereby: (a) the EIOCC implements a controller output processing function configured such that the EIOCC (1) receives a controller output message including a controller output value of a first DST from a process controller and (2) responds to the first DST by assigning the controller output value to the mapped first message position, whereby the controller output value is transmitted from the EIOCC to the field device at the first message position of an EIOCC input message transmitted to the field device, or Uploading, comprising: (b) the EIOC is configured to respond by: (1) receiving, from the field device, an EIOC output message including a controller input value at a second message position mapped to a second DST by the dataset; and (2) assigning the controller input value to the second DST such that the controller input value is transmitted from the EIOC to the process controller as a value of the second DST as part of a controller input message, implementing a controller input processing function. **Claim 12** The method according to claim 11, wherein the EIOC is configured to implement both the controller output processing function and the controller input processing function. **Claim 13** The method according to claim 11 or claim 12, wherein the EIOC and the field device are configured to transmit the EIOC output message and the controller output message in a time-adjusted manner such that each is transmitted during a different predetermined time slot. **Claim 14** The method according to any one of claims 11 to 13, wherein each of the controller output message and the controller input message is configured to carry a plurality of parameter values. **Claim 15** The method according to any one of claims 11 to 14, wherein the dataset further includes one or more logical device tags (LDTs) mapped to second one or more message positions. **Claim 16** The method according to any one of claims 11 to 15, wherein the dataset further includes one or more physical device tags mapped to second one or more message positions. **Claim 17** The method according to any one of claims 11 to 16, further comprising generating and displaying, in the electronic device, a user interface for viewing or editing the dataset including the one or more DSTs mapped to the one or more message positions. **Claim 18** The method according to claim 17, wherein the user interface includes a field for specifying a node tag specific to the EIOC associated with the dataset. **Claim 19** The method according to any one of claims 11 to 18, further comprising downloading the decoder file from a server associated with the field device before analyzing the decoder file. **Claim 20** The method according to any one of claims 11 to 18, further comprising downloading the decoder file from the field device before analyzing the decoder file.

Images