Ethernet I / O card scanner

Abstract

Ethernet I / O Card (EIOC) scanner devices facilitate the configuration of process control systems to enable better integration of EIOC-enabled field devices (and associated field device variables) into the process control system. Specifically, an EIOC scanner can: (i) analyze decoder files for EIOC-enabled field devices to automatically identify field device variables that the EIOC-enabled field devices are configured to send or receive; and (ii) quickly and easily facilitate the configuration of process control systems to integrate EIOC-enabled field devices and any associated field device variables identified by the EIOC scanner into the process control system.

Description

Technical Field

[0001] This disclosure generally relates to Ethernet input / output (I / O) cards (EIOCs) in process control environments, and more specifically, to a scanner device that enables improvements to the configuration of a process control system based on decoder files for EIOC-enabled field devices. Background Technology

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

[0003] Field devices perform process or plant functions (such as opening or closing valves, switching equipment on and off, and measuring process parameters). Exemplary 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 sensed temperature, pressure, and flow rate).

[0004] A process controller (typically located within a factory environment) receives signals indicative of process measurements taken by field devices (or other information related to the field devices) and executes a controller application. This application runs, for example, different control modules that make process control decisions, generate control signals based on the received information, and communicate with intelligent field devices (e.g., and Coordinate the control modules or blocks implemented in Fieldbus field devices.

[0005] The execution of the control module causes the process controller to send control signals to field devices via a communication link or signal path, thereby controlling the operation of at least a portion of the process plant or system (e.g., to control at least a portion of one or more industrial processes running or executed within the plant or system). For example, a first set of controllers and field devices may control a first portion of the process controlled by the process plant or system, and a second set of controllers and field devices may control a second portion of the process.

[0006] (I / O) cards (sometimes called “I / O devices” or “I / O modules”) (which are also typically located within the plant environment as inputs / outputs) are usually communicatively positioned between the controller and one or more field devices to enable communication between them (e.g., by converting electrical signals to digital values ​​and vice versa). Typically, the I / O card acts as an intermediary node between the process controller and one or more field device inputs or outputs configured to use one or more communication protocols identical to those used by the I / O card. Specifically, field device inputs and outputs are typically configured for analog or discrete communication. To communicate with field devices, the controller typically requires an I / O card configured for the same type of inputs or outputs used by the field device. In other words, for a field device configured to receive analog control output signals (e.g., 4-20mA signals), the controller needs an analog output (AO) I / O card to send the appropriate analog control output signals; and for a field device configured to send measurement results or other information via analog signals, the controller typically needs an analog input (AI) card to receive the sent information. Similarly, for field devices configured to receive discrete control output signals, the controller requires a Discrete Output (DO) I / O card to send the appropriate discrete control output signals; for field devices configured to send information via discrete control input signals, the controller requires a Discrete Input (DI) I / O card. Additionally, some I / O cards are configured for resistance temperature detectors (RTDs) (which change the resistance of their leads with temperature) or thermocouples (TCs) (which generate a voltage proportional to temperature). Typically, each I / O card can connect to multiple field device inputs or outputs, where each communication link to a particular input or output is called an "I / O channel" (or more generally, a "channel"). For example, a 120-channel DO I / O card can communicatively connect to 120 different discrete field device inputs via 120 different DO I / O channels, enabling the controller to send discrete control output signals (via the DO I / O card) to the 120 different 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 typically located, set up, or installed in the field environment of a process control system or plant. A network consisting of one or more controllers, field devices that are communicatively connected to one or more controllers, and intermediate nodes that facilitate communication between the controllers and field devices can be called an “I / O network” or “I / O subsystem”.

[0008] Information from the I / O network can be obtained by one or more other hardware devices via a high-speed data channel or communication network (“process control network”). These hardware devices may be, for example, operator workstations, personal computers or computing devices, handheld devices, data history databases, report generators, centralized databases or other centralized management computing devices. These devices are typically located in control rooms or other locations away from the harsh field environment of the plant, such as in the back-end environment of a process plant.

[0009] Information transmitted through a process control network enables operators or maintenance personnel to perform desired functions related to the process via one or more hardware devices connected to the network. These hardware devices can run applications that allow operators to, for example, change the settings of process control routines, modify the operation of control modules within process controllers or intelligent field devices, view the current status of the process or the status of specific equipment within the process plant, view alarms generated by field devices and process controllers, simulate process operation for personnel training or software testing purposes, diagnose problems or hardware failures within the process plant, etc. The process control network or high-speed data channel used by hardware devices, controllers, and field devices can include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0010] As an example, the DeltaV sold by Emerson TM Control system and Ovation TM Distributed control systems (DCS) typically consist of multiple applications, which are stored and executed by different devices located at different locations within the process plant. Configuration applications (residing in one or more workstations or computing devices in the back-end environment of the process control system or plant) enable users to create or modify process control modules and download these modules to a dedicated distributed controller via high-speed data channels. These control modules are typically composed of communicatively interconnected function blocks, which are objects in an object-oriented programming protocol. These function blocks (i) perform functions within the control scheme based on their inputs and (ii) provide outputs to other function blocks within the control scheme. Configuration applications also allow configuration designers to create or modify operator interfaces, which are used by viewing applications to display data to operators and enable operators to change settings in process control routines, such as setpoints.

[0011] Each dedicated controller (and in some cases, one or more field devices) stores and executes a corresponding controller application that runs control modules assigned to and downloaded to it to perform the actual process control functions. A viewing application, which can run on one or more operator workstations (or one or more remote computing devices connected to the operator workstations and the data highway), receives data from the controller application via the data highway and displays that data to process control system designers, operators, or users using a user interface. It can provide any of several different views, such as operator view, engineer view, technician view, etc. A 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 a configuration database application can run on another computer attached to the data highway to store the current process control routine configuration and associated data. Alternatively, the configuration database can reside on 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 that are 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), which are located in many places in a typical plant.

[0013] Note that this background description provides context to aid in understanding and comprehension of the detailed description that follows. The portion of the inventor's work described in the background section (and aspects of this background description that do not constitute prior art at the time of filing) is neither expressly nor implied to be acknowledged as prior art that undermines this disclosure. Summary of the Invention

[0014] Refer to Figure 1- Figure 12 This disclosure describes various techniques, systems, and methods for facilitating the configuration of process control systems to enable better integration of EIOC-enabled field devices and associated field device variables into the process. Specifically, this disclosure describes an EIOC scanner that can: (i) analyze decoder files for EIOC-enabled field devices to automatically identify field device variables (sometimes referred to as "field device parameters") configured to be sent or received by the EIOC-enabled field devices; and (ii) quickly and easily facilitate the configuration of process control systems to integrate EIOC-enabled field devices and any desired field device variables associated with the EIOC-enabled field devices identified by the EIOC scanner into the process control system.

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

[0016] In one 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 controller output processing functionality or controller input processing functionality. When configured for the controller output processing functionality, the EIOC is configured to map DST values ​​from controller output messages to message locations in field device input messages for the corresponding field device variables (appropriate message locations may be determined from a decoder file). Performing this mapping may include: (1) receiving a controller output message from the process controller including a controller output value for a first DST, and (2) responding by assigning the controller output value to a first message location mapped to the first DST according to the dataset, such that for a field device input message sent to the field device, the controller output value is sent from the EIOC to the field device at the first message location.

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

[0018] In one embodiment, the EIOC can be configured to implement both the controller output processing function and the controller input processing function. The EIOC can be configured to send the controller input message and the field device input message, such that each of the controller input message and the field device input message is sent during a different predetermined time slot. Furthermore, the controller input / output message and the field device input / output message may each carry multiple parameter values.

[0019] In one embodiment, the dataset generated by the electronic device based on the decoder file may include any desired type of system label, including any one or more of DST, Physical Device Label (PDT), Logical Device Label (LDT), or node label (representing a specific EIOC).

[0020] In one embodiment, the electronic device may present a user interface for adding, editing, or viewing the DST and any other system tags (and any associated characteristics) included in the dataset generated from the decoder file. In one embodiment, the electronic device may download the decoder file from the field device associated with the decoder file. In some cases, the electronic device may download the decoder file from a server (e.g., associated with the manufacturer of the field device).

[0021] Note that this overview has been provided to introduce some of the concepts in the following detailed description. As explained in the detailed description, certain embodiments may include features and advantages not described in this overview, and some embodiments may omit one or more features or advantages described in this overview. Attached Figure Description

[0022] Each of the accompanying drawings described below depicts one or more aspects of the disclosed system or method according to an embodiment. Detailed description refers to the reference numerals included in the following drawings.

[0023] Figure 1A This is a block diagram of an Ethernet I / O card (“EIOC”) network, which includes EIOC field devices and EIOC scanners.

[0024] Figure 1B This is a block diagram of process control system 5. Figure 1A The EIOC network shown can be part of the process control system.

[0025] Figure 2 A control routine is described, which represents a control routine that can be... Figure 1A and Figure 1B The example shown is a control routine implemented by the controller.

[0026] Figure 3 It describes existing technology I / O networks, including traditional I / O cards, and... Figure 1A Unlike the EIOC shown, it requires fixed, dedicated, and manually configured wiring and grouping based on the signal type configured for each traditional I / O card.

[0027] Figure 4 It is used for Figure 1A The image shows a perspective view of the EIOC components of EIOC.

[0028] Figure 5 It is used for analysis of decoder files for field devices, via an EIOC scanner (in... Figure 1A (as shown in the image) to facilitate process control systems (in...) Figure 1B A flowchart of an exemplary method for configuring (shown in the figure).

[0029] Figure 6 An exemplary protocol stack is depicted. Figure 1A and 1B The controllers and field devices shown can communicate according to this protocol stack, which can be used to encapsulate process control messages that conform to process control standards or protocols (such as Modbus / TCP) within messages that conform to standard protocols selected from the Internet Protocol Suite.

[0030] Figure 7 Depicting commonly used according to Figure 6 The code shown illustrates the functional code for messages sent using the Modbus / TCP protocol.

[0031] Figure 8 This is an example protocol stack. Figure 1A and Figure 1BThe controllers and field devices shown can communicate according to this protocol stack, including the Common Industrial Protocol (CIP) stack encapsulated in a typical TCP / IP or UDP / IP stack.

[0032] Figure 9 This is an example protocol stack. Figure 1A and Figure 1B The controllers and field devices shown can communicate according to this protocol stack, including the IEC 61850 stack encapsulated in a typical TCP / IP or TCP / UDP stack.

[0033] Figure 10 It shows that it can be made by Figure 1A The EIOC scanner user interface shown in the image allows users to add, edit, or view data to be assigned from... Figure 1A The decoder file shown in the diagram identifies any of the multiple system tags of the field device variables.

[0034] Figure 11 It shows that it can be made by Figure 1A The user interface presented by the EIOC scanner shown in the figure allows users to add, edit, or view node labels (a type of system label) of EIOCs associated with variables imported from the decoder file.

[0035] Figure 12 It shows that it can be made by Figure 1A The EIOC scanner user interface shown in the image allows users to add, edit, or view physical device labels (a type of system label) associated with one or more variables imported from the decoder file. Detailed Implementation

[0036] As indicated, refer to Figure 1- Figure 12 This disclosure describes various techniques, systems, and methods for facilitating the configuration of process control systems to enable better integration of EIOC-enabled field devices and associated field device variables into the process control system. Specifically, Figure 1A and Figure 1B An EIOC scanner 75 (sometimes referred to as “scanner 75” or “device 75”) is described, which can: (i) analyze decoder files for EIOC-enabled field devices to automatically identify field device variables (sometimes referred to as “field device parameters”) that the EIOC-enabled field devices are configured to send or receive; and (ii) quickly and easily facilitate the configuration of process control systems to integrate EIOC-enabled field devices and any desired field device variables associated with the EIOC-enabled field devices identified by the EIOC scanner 75 into the process control system.

[0037] The following description is divided into the following sections. Section I Reference Figures 1A-4 Exemplary systems, devices, and networks associated with the disclosed technologies are described, including an exemplary process control system that can be configured using an EIOC scanner 75 to integrate EIOC-enabled field devices and associated field device variables into the process control system. (Part II Reference) Figure 5 This describes exemplary methods for facilitating the configuration of a process control system to integrate EIOC-enabled field devices and associated variables into the process control system. (Part III Reference) Figures 6-9 This describes an exemplary protocol stack associated with an EIOC-enabled field device and EIOC, which can be configured using the EIOC scanner 75. (Partial IV Reference) Figures 10-12 The description may be presented by the EIOC scanner 75, providing an exemplary user interface (UI) that allows the user to add, edit, or view information associated with parameters to be added to the process control system based on analysis of the decoder file. Sections V and VI describe other considerations and the terms and phrases used in this specification.

[0038] I, Exemplary EIOC scanner 75 and exemplary process control system 5

[0039] Figure 1A This is a block diagram of an Ethernet I / O card (“EIOC”) network 7 and a scanner 75. The EIOC network 7 includes an EIOC field device 131. Figure 1B This is a block diagram of process control system 5, and EIOC network 7 may be part of process control system 5. At a higher level, scanner 75 may: (i) analyze decoder file 199 for field device 131 to automatically identify field device variables that field device 131 is configured to send or receive; and (ii) quickly and easily facilitate the configuration of EIOC network 7 (and the broader process control system 5, if needed) to integrate field device 131 and any desired field device variables associated with field device 131 into EIOC network 7 or process control system 5.

[0040] Generally, the EIOC-compliant 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 protocol stack. An “EIOC stack” refers to any suitable communication protocol stack, including standard process control communication protocols encapsulated within packets 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 Common Industrial Protocol (CIP), EthernetIP, and ModbusTCP.

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

[0042] The term "Ethernet" refers to a family of computer networking technologies commonly used in Local Area Networks (LANs) and Wide Area Networks (WANs). At the physical layer, Ethernet can use coaxial cable, twisted-pair cable (e.g., any suitable CATX cable, such as CAT5 or CAT6), or fiber optic links as the shared medium. These physical links can be terminated using any suitable connector (e.g., an RJ45 connector). At the physical and data link layers, Ethernet communication typically conforms to the IEEE 802.3 standard. Generally, systems communicating according to Ethernet standards (e.g., the EIOC controllers and field devices disclosed herein) divide the data stream into shorter pieces called "frames." Typically, each frame contains source and destination addresses, as well as error check data, so that corrupted frames can be detected and discarded; most commonly, higher-layer protocols trigger retransmission of lost frames.

[0043] Regarding the phrases “EIOC” and “I / O” in the process control industry, the term “I / O” (as in “Ethernet I / O card”) can be used in a variety of related but distinct contexts. The term “I / O” generally refers to a logical link or communication channel that communicatively couples field devices to an I / O card or controller (e.g., “I / O channel”), but can be used when referring to several other concepts, such as devices that send signals to or receive signals from field devices via an I / O channel (e.g., “I / O device,” “I / O card,” or “I / O module”), connectors or terminals associated with an I / O device (e.g., “I / O connector”), signals transmitted on an I / O channel (e.g., “I / O signal”), variables or commands represented by signals (e.g., “I / O parameter”), or the values ​​of variables or commands carried by signals (e.g., “I / O parameter value”). When the term “I / O” is used herein without qualifiers, the context of the sentence should clearly define which of these concepts is being discussed.

[0044] Furthermore, it should be understood that "I / O channel" represents a specific type of "communication channel" or "channel". In other words, unless the context of the sentence specifies otherwise, the reference to the term "channel" or "communication channel" in this description without the qualifier "I / O" may refer to a communication link that may be an I / O channel in some embodiments, but may also refer to a communication link other than an I / O channel in other embodiments. Additionally, "EIOC channel" is a specific type of I / O channel; it is an I / O channel between the controller and field devices that relies on Ethernet networking technology. For example, an EIOC channel may be or include a physical link, such as a CatX cable (e.g., Cat5, Cat5e, Cat6), configured to facilitate communication between devices using a physical link that uses an Ethernet standard, and the controller and field devices may communicate using a TCP / IP standard.

[0045] Similarly, "EIOC" refers to a specific type of I / O device (e.g., a device configured to communicate according to process control standards and one or more Ethernet standards); "EIOC connector" refers to a specific type of I / O connector (e.g., a male CatX connector or female CatX port configured for Ethernet communication); "EIOC signal" refers to a specific type of I / O signal (e.g., I / O signals that transmit process variables via Ethernet-compliant messages at the physical, data link, network, or transport layers of the OSI model). Finally, "EIOC parameter" refers to a specific type of I / O parameter (e.g., I / O parameters transmitted to or from EIOC field devices via EIOC signals on an EIOC channel).

[0046] A. EIOC Network 7 and EIOC Scanner 75

[0047] Generally, EIOC network 7 is an I / O network for Ethernet field devices and I / O cards in a process control environment, and EIOC scanner 75 is configured to analyze decoder file 199 for field devices (e.g., field device 131) to identify one or more field device variables (sometimes "field device parameters") that field device 131 is configured to send or receive. Before describing the functionality provided by EIOC network 7 and EIOC scanner 75, the following paragraphs identify the various systems and links depicted in Figure 1.

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

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

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

[0051] Network 7's EIOC 126 is an I / O card configured to communicate with field devices according to one or more Ethernet or Internet protocol standards. EIOC 126 may include a first communication interface (not shown) for establishing EIOC communication (e.g., via link 142) and a second communication interface for communicating with a controller (e.g., communicating with controller 111 via link 141). Generally, the first communication interface is an Ethernet-based interface, and the second communication interface is a digital communication bus on the backplane shared by EIOC 126 and controller 111. EIOC 126 may have certain identical structures and is capable of performing the following... Figure 1B Any operation discussed in the field devices 15-22 and 40-46 shown in the figure.

[0052] Switch 128 in network 7 can be any suitable network switch or router configured to forward or route EIOC messages between devices connected to switch 128. For example... Figure 1A As shown, switch 128 can forward messages between field devices 133 / 135 and EIOC 125 via links 143 / 144 and 145, respectively. In some embodiments, a router may be used instead of switch 128, or a router may be used in addition to switch 128.

[0053] Each field device in network 7, 131-135, is an EIOC-compliant field device. In other words, each field device is configured to communicate with the EIOC (e.g., EIOC 126) using EIOC-formatted messages. If needed, each field device 131-135 may have the following... Figure 1B Any structure of the field devices 15-22 and 40-46 shown in the diagram that are discussed for their functions.

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

[0055] EIOC scanner 75 includes: a memory 101 storing scanner tool 113 and 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 may include input components 106 (e.g., touch sensor, keyboard, mouse, mechanical buttons, etc.) and a display 107 (e.g., LCD, LED, CRT, plasma, projection display, head-up display, etc.). The user interface 104 may include output components other than or replacing the display 107, such as speakers for audio output, motors for haptic output, and light sources (e.g., LEDs) for visual output.

[0056] Processor 102 can execute tool 113, which is a computer-readable instruction set that, when executed by processor 102, enables processor 102 to perform the functions attributed herein to scanner 75.

[0057] In operation, the EIOC scanner 75 receives the decoder file 199 from the decoder source 120 via link 121. The decoder source 120 may be a server (e.g., associated with the manufacturer of the field device 131). The decoder file 199 may be obtained from multiple decoder files based on model, MAC address, or some other identifier unique to the field device 131 or its model. In some embodiments, the scanner 75 obtains the decoder file 199 from the field device 131 via a wired or wireless connection.

[0058] Generally, decoder file 199 includes a list of field device variables that field device 131 is configured to write to or read from. Decoder file 199 also includes code for interpreting EIOC messages sent or received by field device 131. This code can specify the message location (e.g., bytes offset from the message header) where each field device variable should be written to or read. As described below, scanner 75 can analyze decoder file 199 to import field device variables as process variables into the process control system and enable EIOC 75 to write and read values ​​from EIOC messages exchanged with field device 131.

[0059] When scanner tool 113 is executed, EIOC scanner 75 analyzes decoder file 199 to identify one or more field device variables that field device 131 is configured to send or receive. Scanner 75 can also analyze decoder file 199 to identify message locations mapped to the identified field device variables for use by field device 131 in sending or receiving messages (e.g., to EIOC 126). After identifying the field device variables and their corresponding mapped message locations, scanner 75 can create records linking the message locations to a set of system tags (e.g., new system tags not currently used by process control system 5) designed to represent the identified field device variables.

[0060] The EIOC scanner 175 can then update the configuration system 72 to include this record, thereby formally (from the perspective of the process control system 5) assigning the system tag set to the appropriate message location (for messages sent between field device 131 and EIOC 126) so that the system tag set represents one or more field devices. Specifically, the configuration system may include a database storing mappings 132 that link system tags to I / O channels. For conventional I / O cards and field devices, an I / O channel may be a specific physical 4-20mA channel on the I / O card (e.g., each card may have 32 I / O channels). For EIOCs and EIOC field devices, I / O channels can be identified by the specific message location of EIOC messages that the EIOC is configured to send or receive.

[0061] The updated configuration database 72 can then be used to configure the process control system 5, thereby enabling the assigned system tags to be operational so that relevant field device variables associated with field device 131 can be referenced by the system within the process control system 5 via the assigned system tags. The process control system 5 is updated to use system tags such that (i) when controller 111 generates a controller output referencing a system tag for a specific variable, EIOC 126 encodes the field device input message for field device 131 such that EIOC 126 writes the controller output to a message location within the field device input message that is linked to or assigned to the system tag for the specific variable, and (ii) when field device 131 sends a field device output message to EIOC 126, including the field device output value at a given message location, 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 a controller input message sent to controller 11).

[0062] Compared to manual techniques used to integrate new field devices into a process control system, the scanner 75 offers a faster and more automated configuration technique for integrating new or updated field devices or field device variables into the process control system. In typical scenarios involving manual techniques, integrating field device variables associated with new field devices into the process control system might involve a user (i.e., a human) manually reading manuals or other documentation (e.g., issued by the manufacturer) to identify the field device variables that the new field device can send or receive. The user can then manually update the configuration database by adding system labels to the configuration database and manually assigning the new system labels to the I / O channels or message locations that the user believes are associated with the field device variables they want the new system labels to represent (e.g., ideas derived from the manufacturer's manual or guide).

[0063] It is worth noting that this manual technique is extremely time-consuming and prone to current and future errors. Needless to say, manually reading documentation and programming the configuration database accordingly is a time-consuming and laborious process. Regarding potential errors, users may misunderstand the documentation and assign new system tags to the wrong I / O channels or message locations, resulting in system tags being assigned to the wrong field device variables (leading to system tags carrying incorrect values). Similarly, if the manufacturer updates the firmware or software of the field devices, causing the field devices to now write or read field device variables in a different way (e.g., at different message locations), the corresponding system tags may "break" (e.g., the message location read or written from the message location by the process control system is no longer associated with the expected field device variable). Furthermore, after the field devices have been installed and the process control system has been configured accordingly, the field device manufacturer may make new field device variables available. In this case, the process control system may not be able to integrate the new field device variables without human knowledge of the update, manually consulting the documentation to determine how the new variables should be read or written, and then manually configuring the process control system accordingly. Needless to say, such updates are easily overlooked or ignored.

[0064] The EIOC scanner 75 automatically maps field device variables for EIOC field devices to message locations by using decoder files associated with the field devices (e.g., decoder file 199), enabling easy and rapid integration of field device variables into the process control system. This addresses the problems caused by error-prone, time-intensive, and labor-intensive manual configuration techniques.

[0065] B. Process Control System 5

[0066] Figure 1BThis is a block diagram of an exemplary process plant, process control system, or process control environment 5, including... Figure 1B EIOC network 7 is shown in the figure.

[0067] A process plant 5 controls a process, which can be said to have one or more "process outputs" (e.g., tank level, flow rate, material temperature, etc.) characterizing the state of the process, and one or more "process inputs" (e.g., various environmental conditions and actuator states, the operation of which may cause changes in the process outputs). Typically, at least some of the process outputs are measured and used as "control inputs" to one or more controllers controlling the process. One or more controllers can then send one or more "control outputs," "control signals," or "commands" (which can be considered process inputs or signals affecting process inputs). Typically, Figure 1B The process plant or control system 5 includes a field environment 122 (e.g., “process plant bottom layer 122”) and a back-end environment 125, which are each communicatively connected via a process control backbone or high-speed data channel 10, which may include one or more wired or wireless communication links and may be implemented using any desired or suitable communication protocol such as Ethernet.

[0068] At higher levels (and such as) Figure 1B As shown in the diagram, the field environment 122 includes physical components (e.g., process control equipment, networks, network elements, etc.) that are configured, installed, and interconnected to operate in order to control the process during operation. For example, the field environment includes I / O network 6 and I / O network 7 (i.e., EIOC network 7). Generally, components of each of these I / O networks are located, configured, or otherwise included in the field environment 122 of the process plant 5. Typically, in the field environment 122 of the process plant 5, raw materials are received and processed using physical components configured therein to produce one or more products.

[0069] In contrast, the back-end environment 125 of process plant 5 includes various components (such as computing devices, operator workstations, databases or archives, etc.) that are shielded or protected from the harsh conditions and 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 process plant 5 may be physically located in different physical locations, some of which may be local to process plant 5. Some of these physical locations may be remote.

[0070] 1. Field environment associated with System 5 122

[0071] As noted, the field environment 122 includes I / O networks 6 and 7, each of which can be coupled to the plant network 10. Each I / O network 6 and 7 includes one or more controllers, field devices communicatively connected to the one or more controllers, and intermediate nodes (e.g., I / O cards) that facilitate communication between the controllers and the field devices.

[0072] Each process controller in process plant 5 implements a control strategy defined by one or more control routines, which can be stored in the controller's memory. When the controller's processor executes one or more control routines, the controller sends control signals (i.e., "control outputs") to the field devices via wired or wireless process control communication links or networks to control the operation of the processes in plant 5. The controller can generate control signals based on (i) one or more received signals, which can be referred to as "control inputs" (e.g., one or more received signals representing measurements obtained by field devices), and (ii) the logic of one or more control routines, which can be defined by one or more software elements (e.g., function blocks). Typically, the controller manipulates process inputs (which can be referred to as "manipulated variables") to change specific process outputs (which can be referred to as "controlled variables" or simply "process variables") based on feedback (i.e., measurements of controlled variables) and the expected value of the process output (i.e., setpoint).

[0073] Typically, at least one field device performs a physical function (e.g., opening or closing a valve, raising or lowering the temperature, performing a measurement, sensing conditions, etc.) to control the operation of the process implemented in process plant 5. Some types of field devices communicate with the controller using I / O devices (e.g., "I / O cards"). Process controllers, field devices, and I / O cards can be wired or wireless, and the process plant environment or system 5 can include any number and combination of wired and wireless process controllers, field devices, and I / O devices.

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

[0075] In some configurations (not shown), controller 11 can communicate with wireless gateway 35 using one or more communication networks other than backbone network 10, for example by using one or more communication protocols that support one or more communication protocols (e.g., Wi-Fi or other wireless LAN protocols compliant with IEEE 802.11, mobile communication protocols (e.g., WiMAX, LTE or other ITU-R compatible protocols)). Profibus, Any number of other wired or wireless communication links (such as Fieldbus).

[0076] Controller 11 could be, for example, a DeltaV sold by Emerson Process Management. TM or Ovation TM A controller, operable to implement batch or continuous processes using at least some of field devices 15-22 and 40-46. In one embodiment, in addition to being communicatively connected to the process control data high-speed channel 10, the controller 11 also uses communication protocols such as standard 4-20mA devices, I / O cards 26, 28, or any smart communication protocol (e.g., ...). Fieldbus protocol protocol, Any desired hardware and software associated with protocols, etc., to communicatively connect to at least some of the field devices in field devices 15-22 and 40-46. Figure 1A In this configuration, controller 11, field devices 15-22, and I / O cards 26 and 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 or protocol (e.g., any wired or wireless protocol), including any standards or protocols developed in the future.

[0077] Figure 1B The process controller 11 includes a processor 30 that implements or supervises one or more process control routines 38 (e.g., process control routines stored in memory 32). A control routine is a set of instructions executable by a processor for performing one or more operations to provide or perform control over at least a portion of a process. Generally, a control routine can be understood as software configured to implement a specific control strategy. A control routine may include one or more functional blocks associated with various functions.

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

[0079] Controller 11 implements control strategies using what are commonly called function blocks, where each function block is an object or other part (e.g., a subroutine) of an overall control routine, and combines with other function blocks (via communication called links) to implement process control loops in process control system 5. Control-based function blocks typically perform one of the following: (i) input functions, such as input functions associated with transmitters, sensors, or other process parameter measuring devices (sometimes called "input blocks"); (ii) control functions, such as control functions associated with control routines that perform PID, fuzzy logic, etc. (sometimes called "control blocks"); or (iii) output functions that control the operation of certain devices (e.g., valves) to perform certain physical functions within process control system 5 (sometimes called "output blocks"). Of course, hybrid and other types of function blocks exist.

[0080] Function blocks can be stored in controller 11 and executed by controller 11, when these function blocks are used for standard 4-20mA devices and certain types of intelligent field devices (e.g. This is typically the case when it comes to equipment or related devices, or it can be stored in the field device itself and implemented by the field device itself. This is the case for Fieldbus devices. One or more control routines 38 can implement one or more control loops, which are executed by executing one or more function blocks.

[0081] Wired field devices 15-22 can be any type of device (e.g., sensors, valves, transmitters, positioners, etc.), while I / O cards 26 and 28 can be any type of process control I / O device conforming to any desired communication or controller protocol. Figure 1A In the middle, field equipment 15-18 is a standard 4-20mA device or The devices communicate with I / O card 26 via analog lines or a combination of analog and digital lines, while field devices 19-22 are intelligent devices (e.g., Fieldbus field devices, which use The Fieldbus communication protocol communicates with I / O card 28 via a digital bus. 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, additionally or alternatively use the process control data high-speed channel 10 or communicate with controller 11 using other suitable control system protocols (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.).

[0082] exist Figure 1B In the middle, wireless field devices 40-46 use, for example, The wireless protocol of the protocol communicates via the wireless process control communication network 70. Such wireless field devices 40-46 can communicate directly with one or more other devices or nodes of the wireless network 70, which are also configured for wireless communication (e.g., using a wireless protocol or another wireless protocol). To communicate with one or more other nodes not configured for wireless communication, wireless field devices 40-46 can use a wireless gateway 35 connected to the process control data high-speed channel 10 or another process control communication network. The wireless gateway 35 provides access to various wireless devices 40-58 of the wireless communication network 70. Specifically, the wireless gateway 35 provides communication coupling between the wireless devices 40-58, wired devices 11-28, or other nodes or devices of the process control plant 5. For example, the wireless gateway 35 can provide communication coupling by using the process control data high-speed channel 10 or by using one or more other communication networks of the process plant 5.

[0083] 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 valves or measuring process parameters. 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 act as producers and consumers of wireless communication packets.

[0084] In some configurations of process plant 5, the wireless network 70 includes non-wireless devices. For example, in Figure 1A middle, Figure 1A Field device 48 is a traditional 4-20mA device, while field device 50 is a wired device. Devices. For communication within network 70, field devices 48 and 50 are connected to the wireless communication network 70 via wireless adapters 52a and 52b. Wireless adapters 52a and 52b support wireless protocols (such as WirelessHART) and may also support one or more other communication protocols, such as... Fieldbus, PROFIBUS, DeviceNet, etc. Additionally, in some configurations, the wireless network 70 includes one or more network access points 55a, 55b, which can be separate physical devices communicating with the wireless gateway 35 via wired connections, or can be provided as part of a single unit with the wireless gateway 35. The wireless network 70 may also include one or more routers 58 to forward packets from one wireless device to another within the wireless communication network 70. Figure 1A In this process, wireless devices 40-46 and 52-58 communicate with each other and with wireless gateway 35 via wireless link 60 of wireless communication network 70 or via process control data high-speed channel 10.

[0085] 2. Factory 5's backend environment 125

[0086] As noted, the backend environment 125 includes various components (e.g., computing devices, operator workstations, databases or archives, etc.) which are typically shielded or protected from the harsh conditions and materials of the field environment 122. The terminal environment 125 may include any one or more of the following, each of which can be communicatively connected to the data high-speed channel 10: (i) one or more operator workstations 71; (ii) configuration application 72a and configuration database 72b; (iii) data history database application 73a and data history database 73b; (iv) one or more other wireless access points 74 that communicate with other devices using other wireless protocols; and (v) one or more gateways 76, 78 that provide access to systems outside the immediate process control system 5.

[0087] Operator workstation 71 can be used by operators to view and monitor the runtime operations of process plant 5 (e.g., operations implemented by devices in EIOC network 7), and to perform any diagnostics, corrections, maintenance, or other actions that may be required. At least some operator workstations 71 may be located in or near various protected areas within plant 5, and in some cases, at least some operator workstations 71 may be located remotely but still maintain a communication connection with plant 5. Operator workstation 71 can be a wired or wireless computing device. Users can use operator workstation 71 to view system tags created by scanner 75 based on analysis of decoder file 199, and to view any related control routines.

[0088] The data history library application 73a operates to collect some or all of the data provided across the data highway 10 (e.g., parameters sent or received by any field device or controller in the EIOC network 7) and historiize or store the data in the history library database 73b for long-term storage. Similar to the configuration application 72a and configuration database 72b, the data history library application 73a and history library database 73b are centralized and have a unified logical appearance within the process control system 5. Although multiple instances of the data history library application 73a can execute simultaneously within the process control system 5, the data history library 73b can be implemented across multiple physical data storage devices. The data history library 73 can collect and historiize any one or more process variables created by the scanner 75.

[0089] One or more other wireless access points 74 enable devices in the back-end environment 125 (and sometimes in the field environment 122, such as devices in the EIOC network 7) to communicate with other devices using wireless protocols, such as Wi-Fi or other IEEE 802.11 compliant wireless LAN protocols, mobile communication protocols (such as WiMAX (Microwave Access Global Interoperability), LTE (Long Term Evolution), or other ITU-R (International Telecommunication Union Radiocommunication Sector) compliant protocols), shortwave radio communications (such as Near Field Communication (NFC) and Bluetooth), or other wireless communication protocols. Typically, such wireless access points 74 allow handheld or other portable computing devices (e.g., user interface devices 75) to communicate through a corresponding wireless process control communication network, which is different from the wireless network 70 and supports different wireless protocols. For example, the wireless or portable user interface device 75 could be a mobile workstation or diagnostic test equipment used by operators in the process plant 5 (e.g., an example of one of the operator workstations 71). In some cases, 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 wireless protocols supported by access point 74.

[0090] Gateways 76 and 78 can interface with systems outside the real-time process control system 5 (e.g., enabling communication between external systems and one or more devices in the EIOC network 7). Typically, such systems are customers or suppliers of information generated or operated by the process control system 5. For example, the process control plant 5 may include gateway node 76 to communicatively connect the real-time process plant 5 to another process plant. Additionally or alternatively, the process control plant 5 may include gateway node 78 to communicatively connect the real-time process plant 5 to external public or private systems, such as laboratory systems (e.g., laboratory information management systems or LIMS), operator rounds databases, material handling systems, maintenance management systems, product inventory control systems, production scheduling systems, weather data systems, transportation and handling systems, packaging systems, the Internet, process control systems from other providers, or other external systems.

[0091] although Figure 1BOnly a single controller 11 is illustrated, along with a limited number of field devices 15-22 and 40-46, a wireless gateway 35, a wireless adapter 52, an access point 55, a router 58, and a wireless process control communication network 70 included in the exemplary process plant 5. This is merely an exemplary and not limiting embodiment. Any number of controllers 11 may be included in the process control plant or system 5, and any controller 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 the processes in plant 5.

[0092] Still refer to Figure 1B Configuration application 72a and configuration database 72b can be used to configure certain aspects of plant 5. Various instances of configuration application 72a can execute on one or more computing devices (not shown) to enable users to create or modify process control modules and download these modules to controller 11 or any process controller in EIOC network 7 via data high-speed channel 10, and to enable users to create or modify operator interfaces through which operators can view data and change data settings within process control routines (e.g., process control routines implemented via controllers in EIOC network 7). Configuration database 72b stores the created (e.g., configured) modules or operator interfaces. Typically, configuration application 72a and configuration database 72b are centralized and have a unified logical appearance within process control system 5, although multiple instances of configuration application 72a can execute simultaneously within process control system 5, and configuration database 72b can be implemented across multiple physical data storage devices. Therefore, configuration application 72a, configuration database 72b, and their user interfaces (not shown) constitute a configuration or development system 72 for controlling or displaying modules. Typically, but not necessarily, the user interface of configuration system 72 is different from that of operator workstation 71, because configuration and development engineers use the user interface of configuration system 72 regardless of whether plant 5 is operating in real time, while operator workstation 71 is used by operators during the real-time operation of process plant 5 (which may also be referred to here as the "runtime" operation of process plant 5).

[0093] During commissioning, 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 wish to implement at the process plant level or field environment 122. Some of this commissioning data can be provided to components in field environment 122 for commissioning of devices and their loops, and some of this data can be used in backend environment 125, for example, for designing, developing, and preparing control modules and / or operator interface modules that will operate with field environment 122 during live operation of process plant 5. In one example, an approved control module is downloaded to a process controller (e.g., in EIOC network 7) so that, when executed during live operation, the process controller will operate according to its resident control module to send and receive various signals to and from other components in its loop (in some cases, to or from other process controllers), thereby controlling at least a portion of the processes in process plant 5.

[0094] The configuration database 72b can store multiple logical identifiers (or tags) of components in the field environment 122, thereby enabling the controller 11 and other devices to reference components and signals associated with them through logical identifiers.

[0095] For example, for a given field device, configuration database 72b may store information that maps or binds logical identifiers to specific hardware addresses or I / O channels. Hardware addresses may identify a specific controller, a specific I / O card connected to that controller, and / or a specific address used to connect a specific I / O card to an I / O channel of the field device. For EIOCs and associated field devices, database 72b may store the address of each logical identifier (e.g., a tag or DST) for a specific message location used to identify a specific controller, a specific EIOC connected to that controller, and / or an EIOC message expected to carry the value of the logical identifier and sent or received by that specific EIOC.

[0096] In some cases, this mapping or binding may be stored in controller 11, user interface device 75, operator workstation 71, or any other desired device (e.g., any device that needs to resolve logical identifiers). Once a logical identifier has been bound to a hardware address or I / O channel, it is considered "assigned." In some cases, system 5 includes "unassigned" logical identifiers, which are identifiers referenced by software elements (e.g., control routines or function blocks) but not bound. That is, logical identifiers are considered "unassigned" when system 5 and configuration database 72b do not have a hardware address or I / O channel already bound to a tag. Therefore, when a control routine references an unassigned logical identifier, the value carried by a signal in plant 5 will not be read, and commands will not be sent to field devices in plant 5 via signals. Each tag in database 72b may generally be referred to as a "system tag." Exemplary types of tags that can be stored in configuration database 72b and used by factory 5 include physical device tags (PDT), device signal tags (DST), logical device tags (LDT), and I / O node or node tags (sometimes referred to as EIOC node or node tags).

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

[0098] Generally speaking, an LDT can be viewed as representing a set of related DSTs. For example, a single LDT can be provided for a set of 10 diagnostic parameters for a particular physical device, indicating that each of the 10 diagnostic parameters is a diagnostic parameter.

[0099] Finally, each EIOC node or node label represents a unique EIOC. Therefore, a given EIOC connected to six field devices can be associated with a specific node label (e.g., EIOC04), and a node label can be assigned to each of the six field devices connected to the EIOC. 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 a specific field device receiving or transmitting a specific signal), and (iv) an assigned EIOC node (identifying a specific EIOC linked to a specific field device).

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

[0101] 3. Exemplary control routine 200 can be found in process control system 5.

[0102] Figure 2 Control routine 200 is described, and its representation can be provided by... Figure 1A and Figure 1B The example shown is a control routine 38 implemented by the controller.

[0103] At a higher level, control routine 200 controls process 201 by attempting to drive a controlled variable (CV) (e.g., tank level) to a specific setpoint. Control routine 200 receives a setpoint (SP) or desired value 212 for CV (sometimes referred to simply as process variable or PV), measures the actual value 214 of CV, calculates the error or difference 216 between SP and the measured CV value, and then calculates a command or controller output (e.g., manipulated variable (MV) 226) for a CV response (e.g., tank inlet valve position) based on a proportional factor 218, an integral factor 220, a derivative factor 222, or some combination thereof. The controller can send the value 226 (e.g., actuator position) to the appropriate MV (e.g., actuator) via AO block 208 to drive CV 232 (e.g., temperature, level, or flow rate) to the SP value 212. As shown, CV 232 in process 201 may be influenced by one or more parameters outside the direct control of loop 200. These parameters can be referred to as disturbance variables (DV)236.

[0104] As shown in the figure, 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 by the controller implementing routine 200 or an I / O card coupled to that controller via an I / O channel (e.g., from a field device). For example, AI block 204 can be bound to a first Device Signal Tag (DST) identifying a specific AI I / O channel at a first I / O card, and the value provided by AI block 204 can therefore be driven by the value of a signal on that specific AI I / O channel (e.g., a 4-20 mA signal representing the measured flow rate provided by a flow transmitter field device). Similarly, AO block 208 can represent analog signals that will be sent by the controller implementing routine 200 via an I / O channel (e.g., to a field device) or to an I / O card coupled to that controller. For illustration, AO block 208 can be bound to a second DST that identifies a specific AO I / O channel at the second I / O card. Therefore, the value fed to AO block 208 can, based on the value received at AO block 208, cause the second I / O card to drive a signal on a specific AO I / O channel (e.g., this value could cause the second I / O card to drive a 4-20mA signal to the valve field device via the AO I / O channel to control the valve position).

[0105] As an example, routine 200 can be configured to control field device 131, and can be controlled by... Figure 1A The controller 111 shown in the figure implements this. In such an example, when the controller 111 writes the value for DST to the AO block 208, the controller 111 can send the DST value to the EIOC 126, and the EIOC 126 can send the value to the field device 131 via the EIOC message through the link 142 (e.g., where the value is encapsulated in a field device input message).

[0106] Similarly, field device 131 can send measurement results or other parameters to EIOC 126 via link 142 as part of an EIOC message (e.g., where the measurement results are encapsulated within a field device output message). EIOC 126 can then map the measurement results or parameters to a DST or another system tag. Routine 200 can receive the measurement results at AI block 204.

[0107] C. An exemplary conventional I / O network 300 that can be found in process control system 5

[0108] Figure 3The prior art I / O network 300, including conventional I / O card 156, is described. Unlike EIOC 126, conventional I / O card 156 requires fixed, dedicated, and manual configuration wiring and grouping based on the signal type configured for each I / O card 56.

[0109] EIOC Network 7 offers numerous advantages over traditional I / O networks such as Network 300. For example, EIOC Network 7 eliminates the need for cross-grouping, thus avoiding the time-consuming and labor-intensive configuration processes associated with traditional Network 300. Instead, EIOC Network 7 allows a single EIOC to connect to multiple field devices (e.g., AI, AO, DI, DO, RTD, TC, smart field devices, “dumb” field devices, etc.) with any suitable signal configuration. Furthermore, EIOC Network 7 avoids the inefficient deployment of I / O cards often associated with traditional I / O networks such as I / O Network 300. While traditional I / O networks typically have multiple I / O cards with unused I / O channels because they must be configured separately for specific signal types, each EIOC in EIOC Network 7 can be linked to any suitable field device and can send / receive any suitable parameter type.

[0110] Regarding I / O network 300, at the high level, manual or direct grouping is a labor-intensive process that involves wiring each field device I / O terminal or connector to a specific terminal block in the grouping cabinet; wiring each I / O card channel to a terminal block in a field terminal array or FTA (located in the grouping cabinet) dedicated to that I / O card; and coupling field device I / O connectors to I / O cards by cross-arranging terminal blocks and FTAs ​​in the grouping cabinet.

[0111] Typically, each conventional I / O card 156 is permanently configured for one signal type, and only for one signal type selected from a variety of signal types (e.g., AO, AI, DI, DO, resistance thermal 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.

[0112] 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 connected to field devices 152A-K via grouping cabinet 150, field junction boxes 154A-D, and multiple wired links 181A, 181B, and 183.

[0113] The I / O network 300 enables the process controller 158 to control a process or a portion thereof via one or more field devices 152. Unfortunately, the I / O network 300 is designed to be inflexible and difficult to modify once field wiring is in place, making project changes very expensive in terms of labor, time, and materials.

[0114] During the design phase of the I / O network 300, process diagrams and instrumentation diagrams (P&IDs) are designed to provide an early view of the control elements (e.g., field devices 152) and how they are intended to be used in the control strategy involving the network 300. An instrumentation list is then derived from these P&IDs; it is a detailed list of each element (e.g., field device) in the design, including device type, manufacturer, calibration range, etc., and the physical location of each element in process preparation. As part of the design phase, the designer defines the field signals associated with each field device 152 and assigns each assigned signal to the controller.

[0115] like Figure 3 As shown, each field device 152 has one or more I / O terminals 161-176 for sending 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 as "input" or "output". For example, field devices including terminals 161, 164, 166, 167, and 172 are configured to send analog input or "AI" signals (e.g., carrying process measurement results) via the terminals. Field devices including terminals 162, 163, and 168 are configured to receive analog input or "AO" signals (e.g., carrying control commands such as commands to open valves) via the terminals. Field devices including terminals 169 and 176 are configured to send digital input or "DI" signals via those terminals. Field devices including terminals 165, 170, 171, 173, 174, and 175 are configured to send discrete output or "DO" signals via those terminals.

[0116] like Figure 3 As shown, each signal associated with terminals 161-176 is assigned to controller 158. The signal count for each signal type assigned to terminals 161-176 allows designers to determine the number and type of each I / O card 156 necessary for controller 158 to communicate with the inputs and outputs of each field device 152.

[0117] The selection of I / O cards is important because each I / O card 156 (i) has 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. 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. The traditional I / O card 156 is limited to four I / O channels, but it will be noted that some dedicated traditional I / O cards have different limitations on the number of I / O channels (e.g., eight channels). As noted, each I / O card 156 is configured for a specific type of signal and can only be used for that type of signal. For 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 only supports a maximum of four channels, results in unused and wasted terminal blocks. For example, five field device terminals 161-176 are configured to send AI signals, even though one of the I / O cards 156 will have three unused channels or blocks, which requires two I / O cards 156.

[0118] To construct network 300, it must first be designed. Then, technicians begin the field wiring phase of development. I / O terminals 161-176 are wired to corresponding field junction boxes FJB154A-154D, which are then wired to terminal sets 192 in grouping cabinet 150. Note that each terminal in 161-176 connects to its corresponding terminal in the FJB and its corresponding terminal 192 in grouping cabinet 150. In other words, for each existing I / O terminal 161-176, a corresponding terminal 192 must be used. The terminal sets 192 are wired to field terminal assemblies (FTAs) 194A-194F, and each field terminal assembly is wired to its corresponding I / O card 156A-F.

[0119] The process of wiring terminal 192 to FTA 194 is called “cross-grouping”. Cross-grouping is usually necessary because the organization of the wires connected to terminal 192 is determined by the physical layout of the factory, while the organization of FTA 194 is determined by the signal type of the conventional I / O card 156 connected to the FTA. Specifically, field devices sharing close proximity typically share an FJB and are wired to the first available terminal 192, resulting in grouping of terminals 192 that roughly correspond to the FJB but have no other distinguishable organization. Conversely, FTA 194 is organized by signal type because each FTA 194 feeds into a specific I / O card 156. For example, FTA 194A corresponds to AI card 156A. Therefore, each terminal 194A needs to be connected to terminal 192, which is connected to the AI ​​channel (i.e., wired to the AI ​​field device terminal). Similarly, the FTA194C corresponds to the AO card 156C, therefore each terminal in the FTA194C should be wired to terminal 192, which is then wired to the AO channel (i.e., connected to the AO field device terminal). The terminals of the FTA194D are similarly used for interconnection between the DI card 156D and terminal 192, which are wired to the DI field device terminal.

[0120] It is worth noting that the channel limitations associated with the dedicated conventional I / O card 156 result in inefficient deployment of the I / O cards, as well as unused I / O channels, terminal blocks, and associated cabinet space in the grouping cabinet 150. Since each I / O card 156 only supports four channels, two I / O cards 156A and 156B must be installed and connected to the controller 158, and two corresponding FTAs ​​194A and 194B must be used. For example, due to signal counting requirements and the limitations of the dedicated I / O card 156, the FTA 194B includes three unused terminals, and the I / O card 156B has three unused I / O channels. The imperfect match between the signal requirements of the field device 152 and the limitations of the I / O card 156 leads to inefficient deployment of the I / O card 156. Although 16 signals are allocated to the controller 158, the controller 158 requires six dedicated I / O cards. If the signal counts were perfectly distributed by type, the controller 158 would only require four I / O cards. As mentioned earlier, since each EIOC can be linked to any suitable EIOC field device, EIOC network 7 is not affected by channel limitations.

[0121] D. Exemplary EIOC component 400 for EIOC 126

[0122] Figure 4 It is used for Figure 1A and Figure 1BThe diagram shows a perspective view of EIOC component 400 of EIOC 126 in EIOC network 7. Component 400 can be mounted to a backplane including a communication bus or channel. Controller 111 can also be mounted to the backplane and can be connected via a bus (e.g., Figure 1A The link 141 shown communicates with EIOC 126.

[0123] Component 400 includes an EIOC connector or terminal 407. (e.g., from a switch, router, or field device) The communication link to the EIOC 126 can be established by connecting a physical link (e.g., Figure 1A Link 142 (or any suitable CATx or Ethernet cable) shown is connected to one of terminals 407 to establish a connection. As shown, terminal 407 is configured according to the RJ45 standard and can facilitate interconnection with any other cable or link having an RJ45 connector. Any one or more of links 142-145 can be or include an Ethernet link with an RJ45 connector for termination at each end. Similarly, each of field devices 131-135 and switch 128 can facilitate connections to links 142-145 via RJ45 connectors.

[0124] II. Used to facilitate the configuration of process control systems to integrate EIOC field devices and associated field device variables. Exemplary method 500

[0125] Figure 5 This is a flowchart of an exemplary method 500 for facilitating the configuration of a process control system 5 via an EIOC scanner 75 and a decoder file 199 of a field device 131, to integrate field device variables configured to be sent or received by the field device 131 into the process control system 5. Method 500 may be wholly or partially derived from... Figure 1A The method 500 can be implemented using one or more systems shown, and can be stored as one or more instructions or routines in memory (e.g., EIOC scanner 75). In other words, it will also be understood that method 500 can be implemented for any suitable process control system, EIOC field device, decoder file, or EIOC scanner.

[0126] Method 500 begins at step 505, where scanner 75 analyzes decoder file 199 to identify message locations (for messages sent or received via link 142) that map to field device variables of field device 131. The location can be an offset relative to the header or any suitable delimiter in the message on link 142. For example, the first byte in the message could represent the value of a first command or a first variable; the second byte in the message could represent the value of a second command or a second variable; and so on.

[0127] In one embodiment, decoder file 199 may specify any suitable technique for decoding field device variable values ​​from or from messages sent to or from field device 131. For example, in one embodiment, time-division multiplexing may be used. In other words, the variable represented within a message or by a given message location may depend on which of the multiple active time slots (which can be determined from decoder file 199). Of course, in such an embodiment, EIOC 126 and field device 131 may be clock-synchronized to coordinate appropriate message transmission.

[0128] In step 510, scanner 75 generates a dataset that maps system labels representing process variables to message locations where field device 131 is configured to read or write field device variables. In other words, the dataset is generated to create process variables that represent the same type of command (e.g., desired valve position), measurement result (e.g., measured temperature), or parameter (e.g., diagnostic parameters representing the state of field device 131).

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

[0130] If needed, scanner 75 can present a user interface for manipulating the dataset that maps system labels to field device variables. See below for reference. Figures 10-12 The exemplary user interface is described in more detail. In short, the user can modify or specify various fields, such as fields indicating the following: the node (e.g., the tag for a specific EIOC) assigned to field device 131 (e.g., a tag unique to EIOC 126 in this case); the name of the system tag; and the parameters associated with the system tag (e.g., type, message location, inputs and outputs, etc.).

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

[0132] In step 520, the process control system 5 is configured according to the configuration system 72. This configuration process enables the new system tag associated with field device 131 to be addressed (i.e., readable or writable) by devices within the control system 5 (e.g., controller 111, EIOC 126, other field devices 131-135 and 15-22, and data history database 73, etc.). As a result, control routines (e.g., 38, 200) executed by the controllers in the process control system 5 can reference the system tag to achieve control of the process.

[0133] In some cases, method 500 can be implemented to configure the process control system based on an updated decoder file for field devices already functioning within the process control system. For example, the manufacturer or developer of an existing field device in the process control system may release a new or updated decoder file for that field device (e.g., taking into account new variables, updated variable characteristics, new functionality of the field device, new firmware, etc.). To obtain any benefits or updates associated with the updated decoder file, scanner 75 may analyze the updated decoder file and update configuration system 72 accordingly.

[0134] III. Example protocol stack for EIOC networks 600-9007

[0135] Figures 6-9 Exemplary protocol stacks 600-900 are depicted for protocols implemented by EIOC network 7 and EIOC 126. As shown in stacks 600-900, simply put, messages sent between EIOC 126 and EIOC field devices 131-135 conform to one or more EIOC protocol stacks (e.g., stacks 600, 800, or 909), in which messages conforming to typical process control standards or protocols are encapsulated in TCP / IP wrappers (e.g., ModbusTCP, CIP, EthernetIP).

[0136] Figure 6 An exemplary protocol stack 600 is depicted, which can be used to encapsulate process control messages conforming to process control standards or protocols (such as Modbus / TCP) within messages conforming to standard protocols selected from the Internet Protocol Suite.

[0137] Stack 600 includes layers 601-607 conforming to protocols from the Internet Protocol Suite: IEEE 802.3 Ethernet protocol for physical layer 601, IEEE 802.2 protocol for data link layer 603, Internet Protocol (IP) for IP layer 605, and Transmission Control Protocol (TCP) for TCP layer 607.

[0138] Stack 600 also includes a protocol 608 (e.g., Modbus / TCP protocol) for an intermediate layer 609 between TCP layer 607 and application layer 611. Generally, messages sent according to protocol 608 are Modbus messages sent over the network within a TCP / IP wrapper. In other words, protocol 608 encapsulates data units from application layer 611 (e.g., Modbus messages in this case) and adds metadata to create data units within layer 609, which can then be encapsulated and sent according to standard protocols from the Internet Protocol Suite (e.g., TCP, UDP).

[0139] Figure 7 Function codes 701 are described as typically used for messages sent according to protocol 608. These codes can be used by any field device in EIOC 126 or field devices 131-135 to read or write any desired process control variables or parameters (e.g., commands for actuators; measurements of temperature, flow, pressure, level, etc.; diagnostic parameters, etc.).

[0140] Figure 8 This is an exemplary protocol stack 800, which includes a Common Industry Protocol (CIP) stack 809 encapsulated within a typical TCP / IP or UDP / IP stack 807. Generally, any reference to TCP / IP or “TCP / IP stack” herein should also be understood as a reference to UDP / IP. EIOC 126 and field devices 131-135 can send and receive messages based on protocol stack 800.

[0141] Stack 809 represents the set of protocols used for process control communication in stack 800. These protocols can be encapsulated in messages configured according to a typical TCP / IP stack 807. Generally, stack 809 contains a comprehensive range of messages and services for automation applications. For example, there are two types of message connections: implicit and explicit. Explicit message connections are point-to-point relationships established to facilitate request-response transactions between two nodes. These connections use TCP / IP services to send messages according to Ethernet standards. Implicit message connections can periodically move application-specific I / O data. They can use multicast producer-consumer models and UDP / IP services to transmit data over Ethernet-compliant links.

[0142] Figure 9 This includes exemplary protocol stacks 900s that incorporate IEC 61850 stack 909. Process control communications formatted according to stack 909 can be encapsulated in messages conforming to typical TCP / IP or TCP / UDP stack 907. EIOC 126 and field devices 131-135 can send and receive messages according to protocol stack 900.

[0143] Generally speaking, IEC 61850 is an international standard that defines communication protocols for intelligent electronic equipment in substations. It is part of IEC Technical Committee 57, the Power System Reference Architecture. The abstract data model defined in IEC 61850 can be mapped to many protocols. Current mappings in this standard include MMS (Manufacturing Message Specification), GOOSE (Object-Oriented Generic Substation Events), SMV (Sampled Measured Values), etc. These protocols can run on TCP / IP networks or substation LANs using high-speed switched Ethernet.

[0144] In some embodiments, EIOC 126 and field devices 131-135 can be configured to communicate with the field devices via the HART-IP protocol, and can be configured to use HART-IP communication to implement method 500. In other words, EIOC scanner 75 can be configured to analyze decoder files for HART-IP field devices to facilitate the configuration of process control system 5 accordingly. In some embodiments, EIOC 126 is not compatible with HART-IP, and EIOC scanner 75 may not be configured to facilitate the integration of HART-IP field devices into process control system 5.

[0145] IV. Can be by Example UI 1000-1200 presented by EIOC Scanner 75

[0146] Figures 10-12 Exemplary UIs 1000-1200, which can be presented by EIOC scanner 75, are depicted to facilitate the configuration of process control system 5 based on decoder file 199. UIs 1000-1200 can be displayed by scanner 75 after analyzing decoder file 199, allowing the user to view or edit characteristics associated with system labels and field device variables being mapped to those system labels. As an example, the user can use UIs 1000-1200 to edit the names and characteristics associated with PDT, LDT, DST, and nodes (each representing a system label) that are being generated and mapped to field device variables associated with field device 131.

[0147] In some cases, users can use UI 1000-1200 to add I / O nodes (as mentioned earlier, each node represents a specific EIOC). For example, as... Figure 11 As shown in UI 1100, the user can then specify the name; type; the protocol that should be configured for the node / EIOC (e.g., CIP, IEC 61850, Modbus TCP, etc.); and so on.

[0148] Turning Figures 10-12Before going into details, it should be noted that the phrase "user interface" or "UI" refers to a component of a computer system through which a user interacts with the computer system. UI components can be hardware, software, or some combination thereof, and can include UI input components, UI output components, or some combination thereof. In some embodiments, Figure 1B Any one or more UI components 104 shown may include any one or more of the exemplary UI components listed below.

[0149] 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 (e.g., speakers), and (iii) motion generation components (e.g., motors that provide haptic feedback).

[0150] Exemplary UI input components include: (i) mechanical or electrical components for detecting physical or touch input, such as hardware actuators (e.g., “hard” buttons on a keyboard, mouse, tablet, or phone, etc.) or electrical sensors (e.g., resistive or capacitive touch sensors); (ii) audio sensors (e.g., microphones) for detecting audio input (e.g., voice commands); (iii) image sensors for detecting image or video input, such as those found in cameras (e.g., enabling facial recognition or gesture input without requiring the user to touch the device); and (iv) motion sensors (e.g., accelerometers, gyroscopes, etc.) for detecting motion of the computer system itself (e.g., enabling the user to provide input by rotating or otherwise moving the computer system).

[0151] The EIOC scanner 75 can provide a graphical user interface (GUI) via the display 107 of the UI 104. Generally, the GUI is generated via routines (e.g., scanner tool 113) and enables the user to interact with indicators and other graphical elements displayed on the electronic display screen. Generally, the graphical elements of the GUI can be output elements (i.e., conveying some information to the user), control elements (i.e., "interactive" with the user to cause the system to perform actions), or both (e.g., icons may include images representing a browser and can be interacted with to launch the browser). Exemplary GUI control elements include buttons (e.g., radio buttons, checkboxes, etc.), sliders, list boxes, spinner elements, drop-down lists, menus, menu bars, toolbars, interactive icons, text boxes, movable or minimized and maximized windows, etc.

[0152] Go to Figure 10The UI 1000 can be rendered by the scanner 75 to enable the user to add, edit or view any of the multiple system tags (e.g., DST, PDT, LDT, node tags) assigned to field device variables (e.g., each variable is associated with a specific message location within an EIOC message sent or received by the field device 131) identified from the decoder file 199.

[0153] like Figure 11 As shown, the scanner 75 can present a UI 1100 to enable users to add, edit, or view node labels for EIOCs associated with variables imported from the decoder file (e.g., node labels unique to EIOC 126).

[0154] like Figure 12 As shown, the UI 1200 can be rendered by the scanner 75 to allow users 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 a default Field Device ID or PDT, and the scanner 75 can populate the UI 1200 with the default PDT. In some cases, users may want to assign PDTs different from the default values ​​(e.g., if the default PDT has already been assigned to a device in the process control system 5, or if the default PDT does not conform to the naming criteria associated with the process control system 5). As shown, users can use the UI 1200 to specify a name, description, index, and various other attributes for each PDT.

[0155] V. Other precautions

[0156] When implemented in software, any applications, services, and engines described herein may be stored in any tangible, non-transitory computer-readable storage medium, such as on a disk, laser disk, solid-state storage device, molecular memory storage device, or other storage medium, in the RAM or ROM of a computer or processor, etc. Although the exemplary systems disclosed herein are disclosed as including software or firmware executing on hardware among other components, it should be noted that such systems are illustrative only and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied solely in hardware, solely in software, or in any combination of hardware and software. Therefore, although the exemplary systems described herein are depicted as being implemented in software executing on the processor of one or more computer devices, those skilled in the art will readily understand that the examples provided are not the only way to implement such systems.

[0157] Referring to method 500, the described functions can be wholly or partially derived from... Figure 1BThe process control system 5 shown is implemented by devices, circuits, or routines. Method 500 may 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 the corresponding method or at least temporarily configured (e.g., a set of instructions or routines representing logical functions stored in memory) to perform the logical functions of the corresponding method.

[0158] Although the invention has been described with reference to specific examples, these examples are merely exemplary and not limiting of the invention. It will be apparent to those skilled in the art that changes, additions, or deletions can be made to the embodiments disclosed herein without departing from the spirit and scope of the invention. Furthermore, while the foregoing text provides detailed descriptions of many different embodiments, it should be understood that the scope of the patent is defined by the words of the claims set forth at the beginning of the patent and their equivalents. The detailed descriptions will be construed as exemplary only and do not describe every possible embodiment, as describing every possible embodiment would be impractical, if not impossible.

[0159] Throughout this specification, multiple instances may implement a component, operation, or structure that is described as a single instance. Although a single operation of one or more methods is exemplified and described as a separate operation, in some embodiments, one or more of the single operations may be performed simultaneously.

[0160] As used herein, any reference to "an embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. The phrase "in an embodiment" appearing in various places in the specification does not necessarily refer to the same embodiment.

[0161] As used herein, the terms “comprising,” “containing,” “including,” “having,” “with,” or any other variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, article of manufacture, or apparatus that includes a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such process, method, article of manufacture, or apparatus. Furthermore, unless expressly stated to the contrary, “or” refers to inclusive “or” rather than exclusive “or.” For example, condition A or B is satisfied by any of the following conditions: A is true (or exists) and B is false (or does not exist); A is false (or does not exist) and B is true (or exists); and both A and B are true (or exist).

[0162] Furthermore, the phrase "wherein 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 "wherein the component is configured as X, Y, or Z" means that the component is configured for X, configured for Y, configured for Z, or configured for some combination of X, Y, and Z.

[0163] Additionally, the terms "a" or "an" are used to describe elements and components of the embodiments herein. This description, along with the appended claims, should be read as encompassing one or at least one. The singular also includes the plural, unless explicitly stated otherwise.

[0164] Furthermore, the patent claims at the beginning of this document are not intended to be interpreted in accordance with 35 U.SC §112(f) unless the conventional “apparatus plus function” language is explicitly used, such as the “apparatus” or “step” language explicitly used in the claims(s). At least some aspects of the systems and methods described herein are aimed at improving the functionality of computers and improving the functionality of conventional computers.

[0165] VI. Terms and phrases

[0166] The following terms and phrases are used throughout the instruction manual.

[0167] Communication Protocols. In this description, communication protocols, standards, and technologies may be collectively referred to as "communication protocols." Exemplary communication protocols, standards, or technologies that may be used by the described system include those facilitating communication via 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.

[0168] Exemplary near-field network protocols and standards include typical radio frequency identification (“RFID”) standards or protocols and near-field communication (“NFC”) protocols or standards. Exemplary PAN protocols and standards include 6LoWPAN, Bluetooth (i.e., a wireless standard that uses radio waves in the range of approximately 2.4 to 2.485 GHz to exchange data between two devices), IEEE 802.15.4-2006, ZigBee, Threading protocol, Ultra Wideband (“UWB”), Universal Serial Bus (“USB”), and Wireless USB, as well as ANT+. Exemplary LAN protocols and standards include the 802.11 protocol and other high-frequency protocols / systems for the range of approximately 1 GHz to 60 GHz (e.g., including 900 MHz, 2.4 GHz, 3.6 GHz, 5 GHz, or 60 GHz bands), and suitable standards (e.g., coaxial and fiber optic). Exemplary technologies for facilitating wireless WANs include technologies 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 can be considered a WAN.

[0169] Other communication protocols and standards that may be used 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 (such as IrDA or IrSimple), Transmission Control Protocol / Internet Protocol (“TCP / IP”) (e.g., any protocol used in each TCP / IP layer), Real-time Transport 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.

[0170] Communication link. Unless otherwise stated, a “communication link” or “link” is a path or medium connecting two or more nodes. A link can be a physical link or a logical link. A physical link is an interface or medium on which information is transmitted, and can be wired or wireless in nature. Exemplary 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 carry information by altering one or more characteristics of electromagnetic waves.

[0171] As noted, a wireless link can be a radio electromagnetic signal that carries information by altering one or more properties of an electromagnetic wave. The radio electromagnetic signal can be a microwave or a radio wave and can be referred to as a radio frequency (RF) signal. Unless otherwise stated, the described RF signal can oscillate at frequencies within any one or more frequency bands found in the spectrum from approximately 30 kHz to 3,000 GHz (e.g., an 802.11 signal in the 2.4 GHz band). Exemplary RF bands include the low frequency (“LF”) band of 30-300kHz, the intermediate frequency (“MF”) band of 300-3,000kHz, the high frequency (“HF”) band of 3-30MHz, the very high frequency (“VHF”) band of 30-300MHz, the ultra-high frequency (“UHF”) band of 300-3,000MHz, the ultra-high frequency (“SHF”) band of 3-30GHz, the extremely high frequency (“SHF”) band of 30-300GHz, and the very high frequency (“THF”) band of 300-3,000GHz.

[0172] A logical link between two or more nodes represents an abstraction of the underlying physical link or intermediate node connecting the two or more nodes. For example, two or more nodes can be logically coupled via a logical link. A logical link can be established through any combination of physical links and intermediate nodes (e.g., routers, switches, or other networking equipment).

[0173] A link is sometimes referred to as a "communication channel." In wireless communication systems, the term "communication channel" (or simply "channel") typically refers to a specific frequency or band. A carrier signal (or carrier wave) can be transmitted at a specific frequency or within a specific band of the channel. In some cases, multiple signals can be transmitted on a single band / channel. For example, signals can sometimes be transmitted simultaneously on a single band / channel via different sub-bands or sub-channels. As another example, signals can sometimes be transmitted via the same band by assigning appropriate transmitters and receivers time slots to use the band in question.

[0174] A computer. Generally speaking, a computer or computing device is a programmable machine with two main characteristics: that is, it responds to a set of instructions in a well-defined manner and can execute a pre-recorded list of instructions (e.g., a program or routine). A computer according to this disclosure is a device having a processor and memory. For the purposes of this disclosure, examples of computers include server hosts, personal computers (e.g., desktop computers, laptop computers, netbooks), mobile communication devices (e.g., mobile “smartphones”), and devices that provide functionality through internal components or connections to external computers, servers, or global communication networks (e.g., the Internet) to obtain guidance from or participate in processes subsequently sent to other system components.

[0175] Database. Generally speaking, a "database" is an organized collection of data that is typically stored and accessed electronically from a computer system. Typically, any suitable data storage device can be called a "database." This disclosure may describe one or more databases used to store information relating to aspects of this disclosure. For example, information stored in a database may relate to private subscribers, content providers, hosting providers, security providers, etc. A server (which may or may not be hosted on the same computer as the database) acts 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 any reference to "database" may refer to multiple databases, each of which may be linked to each other.

[0176] Display device. Generally, 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). Exemplary displays include LED screens, LCD screens, CRT screens, projectors, head-up displays, smartwatch displays, headphone displays (e.g., VR headsets), etc.

[0177] Memory and computer-readable media. Generally, as used herein, the phrase “memory” or “memory device” refers to a system or device that includes one or more computer-readable media (“CRM”). “CRM” refers to one or more media accessible to the relevant computing system for placing, storing, or retrieving information (e.g., data, computer-readable instructions, program modules, applications, routines, etc.). Note that “CRM” refers to media that are not inherently transient and does not involve non-physical, transient signals such as radio waves.

[0178] A CRM can be implemented using any technology, device, or group of devices included in or communicating with the relevant computing system. A CRM can include volatile or non-volatile media, as well as removable or non-removable media. A CRM can include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other media that can be used to store information and is accessible by the computing system. A CRM can be communicatively coupled to a system bus, thereby enabling communication between the CRM and other systems or components coupled to the system bus. In some implementations, the CRM can be coupled to the system bus via a memory interface (e.g., a memory controller). The memory interface is the circuitry that manages the data flow between the CRM and the system bus.

[0179] Message. When used in the context of a communication network, the term "message" refers to a communication unit represented by a set of data that is sent or received by a node (e.g., via a link). The set of data representing a message may include a payload (i.e., the content intended to be transmitted) and protocol overhead. Overhead may include routing information and metadata related to the protocol or payload (e.g., the protocol that identifies the message, the expected receiving node, the originating node, the size of the message or payload, data integrity information used to check the integrity of the message, etc.). In some cases, packets or sequences of packets can be considered messages.

[0180] Module. When used in the context of a software system, the term "module" typically refers to an application, routine, or set of executable instructions. See "Routine". In some cases, the term "module" refers to a component of a physical system (e.g., a car includes multiple modules such as the engine, transmission, brakes, etc.). The context in which the term is used will clearly indicate whether a "module" refers to a software component or a non-software component.

[0181] Network. As used herein, unless otherwise stated, the term "network" (e.g., when used in the context of a system or device that transmits information or data) refers to a network. Figure 1B The network or backbone 10 shown refers to a collection of nodes (e.g., devices or systems capable of sending, receiving or forwarding information) and links that are connected to enable communication between nodes.

[0182] Depending on the embodiments (and unless otherwise stated), each of the described networks may include a dedicated router, switch, or hub responsible for forwarding and bootstrapping traffic between nodes, and optionally, a dedicated device responsible for configuring and managing the network. Some or all of the nodes in the described networks may also be adapted to act as routers to bootstrap traffic sent between other network devices. The nodes of the described networks may be interconnected via wired or wireless means and may have different routing and transmission capabilities. If desired, each described network may include a network or subnet, such as a Personal Area Network (PAN), Local Area Network (LAN), or Wide Area Network (WAN).

[0183] Node. Generally, the term "node" refers to a connection point, redistribution point, or communication endpoint. A node can be any device or system (e.g., a computer system) capable of sending, receiving, or forwarding information. For example, a terminal device or system that initiates or ultimately receives a message is a node. Intermediate devices that receive and forward messages (e.g., between two terminal devices) are also often considered "nodes."

[0184] Processor. Various operations of the exemplary methods described herein can be at least partially controlled by one or more described or implicitly disclosed controllers or processors (e.g., Figure 1A The processor 102 shown in the figure executes the commands. Generally speaking, the terms "processor" and "microprocessor" are used interchangeably, each referring to a computer processor configured to fetch and execute instructions stored in memory.

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

[0186] The performance of certain operations can be distributed across one or more processors, not only residing within a single computer but also deployed across multiple computers. For example, when a single processor is described as performing a set of operations, it should be understood that in some embodiments, multiple processors can perform that set of operations according to any desired distribution across multiple processors. In some exemplary embodiments, one or more processors may reside in a single location (e.g., within a home environment, in an office environment, or as a server farm), while in other embodiments, the processors may be distributed across multiple locations.

[0187] Words such as “processing,” “computing,” “determining,” “presenting,” and “displaying” can refer to actions or processes that manipulate or transform information represented as one or more memories (e.g., volatile memory, non-volatile memory, or combinations thereof), registers, or a machine (e.g., a computer) that receives, stores, transmits, or displays information.

[0188] Routine. Unless otherwise stated, “routine,” “module,” or “application” described in this disclosure refers to a set of computer-readable instructions that can be stored on the CRM. For example, scanner tool 113 is a routine that can be stored on the CRM. Typically, the CRM stores computer-readable code (“code”) that represents or corresponds to the instructions, and this code is adapted to be executed by a processor to facilitate the functionality described as represented by or associated with a routine or application. Each routine or application may be implemented via a standalone executable, a suite or bundle of executables, one or more non-executable files used by an executable or program, or some combination thereof. In some cases, unless otherwise stated, one or more described routines may be hard-coded into one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other hardware or firmware elements.

[0189] In addition, unless otherwise stated, each routine or application may be embodied as: (i) a standalone software program, (ii) a module or submodule of a software program, (iii) a routine or subroutine of a software program, or (iv) a resource invoked or accessed by a software program by a “call”, thereby enabling the system to perform a task or function associated with that resource.

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

[0191] A server. Generally speaking, a server is a collection of programs or routines that manage network resources or services to provide functionality to other programs or devices called "clients". Servers are typically hosted by a host, which itself may be referred to as a "server". Exemplary servers include database servers, file servers, mail servers, print servers, web servers, game servers, and application servers. Servers can be dedicated (e.g., where the software and hardware are dedicated or nearly dedicated to server functions) or virtual (e.g., where the server is hosted by a virtual machine on a physical machine and / or where the server shares the hardware or software resources of a single machine with another operating system).

Claims

1. An electronic device for configuring an Ethernet I / O card in a process control environment, comprising: processor; A communication interface coupled to the processor; as well as A memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the processor to perform the following operations: (i) Analyze decoder files for field devices configured to be coupled to an Ethernet I / O card (EIOC) in a process control system via an Ethernet link, wherein the decoder files map one or more field device variables to one or more message locations; (ii) Generate a dataset including one or more Device Signal Tags (DSTs), each DST representing a process variable corresponding to a different field device variable among the one or more field device variables mapped to the one or more message locations; (iii) Uploading the dataset to the configuration database of the process control system via the communication interface to include the dataset, so that when the process control system is configured according to the configuration database, the one or more DSTs correspond to the one or more message locations, such that the EIOC is configured as follows: (a) Implementing controller output processing functions, wherein the EIOC is configured as follows: (1) Receive a controller output message from the process controller including a controller output value for a first DST, and (2) respond by assigning the controller output value to a first message location mapped to the first DST according to the dataset, such that the controller output value is sent from the EIOC to the field device at the first message location, thereby enabling the sending of a field device input message to the field device; or (b) Implementing controller input processing functions, wherein the EIOC is configured as follows: (1) Receive a field device output message from the field device, the field device output message including a controller input value at a second message location, the second message location being mapped to a second DST according to the dataset, and (2) respond by assigning the controller input value to the second DST such that the input value is sent from the EIOC to the process controller as a value of the second DST, thereby making the input value part of the controller input message.

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

3. The electronic device according to claim 1, wherein, The EIOC and the field device are configured to send the field device input message and the controller input message in a time-coordinated manner, such that each of the field device input message and the controller input message is sent during a different predetermined time slot.

4. The electronic device according to claim 1, wherein, Each of the controller output message and the controller input message is configured to carry multiple parameter values.

5. The electronic device according to claim 1, wherein, The dataset also includes one or more logical device tags (LDTs) mapped to a second or more message locations.

6. The electronic device according to claim 1, wherein, The dataset also includes one or more physical device tags mapped to a second or more message locations.

7. The electronic device according to claim 1, wherein, The instructions also cause the processor to perform the following operations: generate and display a user interface via the display of the electronic device for viewing or editing the dataset, which includes the one or more DSTs mapped to the one or more message locations.

8. The electronic device according to claim 7, wherein, The user interface includes fields for specifying node labels that are unique to the EIOC as associated with the dataset.

9. The electronic device according to claim 1, wherein, The instructions also cause the processor to perform the following operation: download the decoder file from a server associated with the field device before analyzing the decoder file.

10. The electronic device according to claim 1, wherein, The instructions also cause the processor to perform the following operation: download the decoder file from the field device before analyzing the decoder file.

11. A method for configuring an Ethernet I / O card in a process control environment, comprising: (i) The decoder file for field devices is analyzed by electronic devices configured to be coupled to an Ethernet I / O card (EIOC) in the process control system via an Ethernet link, the decoder file mapping one or more field device variables to one or more message locations; (ii) The electronic device generates a dataset including one or more device signal tags (DSTs), each DST representing a process variable corresponding to a different field device variable among the one or more field device variables mapped to the one or more message locations; (iii) Uploading the dataset to the configuration database of the process control system to include the dataset, so that when the process control system is configured according to the configuration database, the one or more DSTs correspond to the one or more message locations, such that the EIOC is configured as follows: (a) Implement the controller output processing function, wherein the EIOC is configured as follows: (1) Receive a controller output message from the process controller including a controller output value for a first DST, and (2) respond by assigning the controller output value to a first message location mapped from the dataset to the first DST, such that the controller output value is sent from the EIOC to the field device at the first message location, thereby enabling the sending of a field device input message to the field device; or (b) Implement the controller input processing function, wherein the EIOC is configured as follows: (1) (2) Receive an EIOC output message from the field device, the EIOC output message including a controller input value at a second message location, the second message location being mapped from the dataset to a second DST, and (2) respond by assigning the controller input value to the second DST such that the input value is sent from the EIOC to the process controller as a value of the second DST, thereby making the input value part of the controller input message.

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.

13. The method according to claim 11, wherein, The EIOC and the field device are configured to send the EIOC output message and the controller output message in a time-coordinated manner, such that each of the EIOC output message and the controller output message is sent during a different predetermined time slot.

14. The method according to claim 11, wherein, Each of the controller output message and the controller input message is configured to carry multiple parameter values.

15. The method according to claim 11, wherein, The dataset also includes one or more logical device tags (LDTs) mapped to a second or more message locations.

16. The method according to claim 11, wherein, The dataset also includes one or more physical device tags mapped to a second or more message locations.

17. The method according to claim 11, wherein, Also includes: A user interface is generated and displayed at the electronic device for viewing or editing the dataset, which includes the one or more DSTs mapped to the one or more message locations.

18. The method according to claim 17, wherein, The user interface includes fields for specifying node labels that are unique to the EIOC as associated with the dataset.

19. The method of claim 11, further comprising: The decoder file is downloaded from a server associated with the field device before it is analyzed.

20. The method according to claim 11, wherein, Also includes: The decoder file is downloaded from the field device before it is analyzed.

Images