Smart Functions for Discrete Field Devices and Signals

Abstract

To provide smart functionality to discrete elements of a processing plant.SOLUTION: A signal characterization component includes: a first communication interface configured to be connected to a first channel coupling the signal characterization component to a processing controller; a second communication interface configured to be connected to a second channel coupling the signal characterization component to a processing control device, in which the processing control device is coupled to a plurality of discrete I / O channels for one or more field devices; and one or more circuits that are communicatively coupled to the first communication interface and the second communication interface and that (i) transmit, through the second channel, a discrete output (DO) message encoded with one or more commands received through the first channel and (ii) transmit, through the first channel, one or more sets of information decoded from a discrete input (DI) message received through the second channel.SELECTED DRAWING: Figure 1A

Description

[Technical field]

[0001] The present invention relates generally to process plants and process control systems, and more particularly to providing smart functionality to discrete elements of a process plant. [Background technology]

[0002] Distributed process control systems, e.g., distributed or scalable process control systems, used in power generation, chemical processing, petroleum processing, and other processes, include one or more process controllers communicatively coupled to each other, to at least one or more host or operator workstations through a process control network, and to one or more field devices through an analog bus, a digital bus, or a combined analog / digital bus.

[0003] Field devices, such as valves, valve positioners, switches, and transmitters (eg, temperature sensors, pressure sensors, flow rate sensors), perform functions within such processes or plants, such as opening and closing valves, switching devices on and off, measuring process parameters, etc.

[0004] A process controller is typically located within a plant environment and receives signals indicative of process measurements performed by field devices and / or other information related to the field devices, executes controller applications (e.g., operates different control modules to determine process control), generates control signals based on the received information, and coordinates with control modules or blocks executing in the field devices, e.g., HART®, WirelessHART®, FOUNDATION® Fieldbus field devices.

[0005] As a result of the control modules being executed, the process controller controls the operation of at least a portion of the process plant or system (e.g., controls at least a portion of one or more industrial processes operating / performed within the plant or system) by sending control signals over a communication link or signal path. For example, the controller and field devices control at least a portion of the processes controlled by the process plant or system.

[0006] Input / output (I / O) cards (also called "I / O devices" or "I / O modules") typically located within a plant environment are typically communicatively positioned between a controller and one or more field devices, for example by converting electrical signals to digital values ​​and digital values ​​to electrical signals. Typically, the inputs or outputs of a field device are communicatively coupled to a process controller through one or more I / O cards configured for the same communication protocol or for a protocol as used by the field device's inputs / outputs. In particular, field device inputs / outputs are typically configured for analog or discrete communication. In general, a controller typically requires an I / O card configured for the same type of input or output utilized by the field device to communicate with the field device. That is, for a field device configured to receive an analog control signal (e.g., a 4-20 mA signal), the process controller typically requires an analog output (AO) I / O card to transmit the appropriate control signal, and for a field device configured to transmit measurements or other information via analog signals, the process controller typically requires an analog input (AI) card to receive the communicated information. Similarly, a process controller requires a discrete output (DO) I / O card to send the appropriate control signal for field devices configured to receive discrete control signals, and typically requires a discrete input (DI) card for field devices configured to send information via discrete signals. Typically, each I / O card may be connected to multiple field device inputs or outputs, where each communication link for a particular input or output is referred to as a "channel." For example, a 120-channel DO I / O card may be communicatively coupled to 120 individual discrete field device inputs, allowing a controller (through the DO I / O card) to send discrete control output signals to the 120 individual discrete field device inputs.

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

[0008] Information from the field devices and controllers is typically transmitted over a data highway or communications network (a "process control network") to one or more other hardware devices, such as operator workstations, PCs or computer devices, handheld devices, data historians, report generators, centralized databases, or other centralized management computer devices that are located in a control room or other location away from the harsh field environment of the plant (e.g., in the back-end environment of a process plant).

[0009] Information communicated through the process management network enables an operator or maintenance personnel to perform desired process functions through one or more hardware devices connected to the network. Such hardware devices execute applications that enable an operator to, for example, change the settings of process control routine(s), adjust control modules in a process controller or smart field device, observe the current state of the process or the status of particular equipment in the process plant, monitor alarms generated by field devices or process controllers, simulate process operations for training personnel or testing process control software, diagnose problems or hardware failures in the process plant, etc. The process control network or data highway utilized by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, and combined wired / wireless communication paths.

[0010] As an example, the DeltaV® control system sold by Emerson Process Management includes multiple applications stored and executed in different equipment (located at different locations within a process plant). A configuration application located on one or more workstations or computing devices in the back-end environment of the process control system or plant allows a user to create or modify process control modules and download such process control modules over a data highway to a dedicated distributed controller. Typically, such control modules are composed of communicatively interconnected function blocks (i.e., objects in an object-oriented programming protocol that perform functions within a control scheme based on inputs and provide outputs to other function blocks in the control scheme). Additionally, the configuration application allows a configuration designer to configure or modify an operator interface (used by a viewing application to display data to an operator and to allow the operator to make configuration (e.g., set points) changes within a process control routine).

[0011] Each dedicated controller, or in some examples one or more field devices, stores and executes a respective controller application (which runs the control modules assigned and downloaded to perform the actual process control functions). A viewing application executing on one or more operator workstations (or one or more remote computing devices communicatively connected to the operator workstations and the data highway) receives data from the controller applications over the data highway and displays such data to a process control system designer, operator, or user using a user interface, which may provide any of several different views, such as an operator's view, a technician's view, or an expert's view. A data historian application is typically stored in and executed by a data historian device that retrieves and stores some or all of the data provided over the data highway, while a configuration database application executes on a computer similarly connected to the data highway and stores the current process control routine settings and associated data. Alternatively, the configuration database may be located in the same workstation as the configuration application. Summary of the Invention [Problem to be solved by the invention]

[0012] Typically, a treatment plant (or part of a plant) may be brought online after a multi-phase process including a design phase, an installation phase, and a commissioning phase. During the design phase, designers develop a general control tactic and identify the treatment elements (i.e., identify the equipment and treatment controllers required to implement the control strategy). During the installation phase, the treatment elements are installed. During the commissioning phase, the treatment elements are tested to the point where the system or plant can operate as intended. Unfortunately, some aspects of the plant are difficult to fully design prior to the installation and commissioning phases. Such phases may be somewhat iterative in nature and may be performed at least partially in parallel.

[0013] For example, designing an I / O network or subsystem is a complex, multi-step process. For decades, dedicated I / O architectures have been used, with each controller having one or more dedicated, multi-channel I / O cards physically connected to the controller through a backplane. Unfortunately, designing such dedicated I / O architectures is a difficult task. First, an instrumentation diagram (P&ID) is designed to provide an initial view of the control elements and how they should be used within the control strategy. Then, an instrument list is derived from the P&ID, which is a detailed list of each element (e.g., field devices) under design, including the device type, manufacturer, calibration range, and physical location of each element within the processing equipment. However, the field wiring design is typically not complete until the I / O subsystem is defined, which typically cannot be defined until the field signal usage is defined in the control strategy and the signals and control strategies can be assigned to the appropriate controllers. Only when the number of signals for each controller is known can the actual I / O subsystem for each controller be identified and the field wiring design completed.

[0014] Unfortunately, project changes and redesigns often disrupt and complicate field wiring installation. Typically, after the field wiring design is completed, the physical communication links are installed and the I / O network is created. "Wired marshalling" is a traditional industry accepted practice for establishing physical communication links (e.g., 2 or 3 wired links). Such wired marshalling is a difficult task, in which a field engineer wires a field box to a terminal block in a field junction box (FJB), and then wires the FJB terminal block to a first set of terminal blocks in a marshalling cabinet in an I / O room (sometimes called a "control room"). The field engineer then wires the first set of terminal blocks in the marshalling cabinet to a second set of terminal blocks in the marshalling cabinet, which are then wired to the appropriate I / O cards in the "system cabinet". Such I / O cards are typically communicatively connected (e.g., through a backplate) to a controller assigned to control or monitor the field device in question.

[0015] Marshalling cabinets represent a communications interconnection point and can be a source of problems during the design and commissioning phases. As wires are typically brought into the marshalling cabinet from the field (through multiple core cables), the wiring within the cabinet typically must be cross-marshaled to ensure that each connected field device is connected to the appropriate I / O card and channel. In particular, field devices are typically connected to a first set of terminal blocks located within the marshalling cabinet, and I / O cards are typically connected to a second set of terminal blocks located within the marshalling cabinet. To ensure proper operation, i.e., when a controller sends a command to a field device, each terminal in the first set of terminal blocks must be wired (i.e., cross-marshaled) to the appropriate terminal in the second set of terminal blocks to ensure that the intended field device receives the command.

[0016] Cross-marshalling can cause problems. In particular, "mapping errors" can occur at several points. As a first example, a field device output can be wired to the wrong terminal on the marshalling cabinet and therefore to the wrong I / O card channel, resulting in the information sent by the field device being assigned to the wrong system variable (e.g., if the field device is incorrectly wired to the same type of I / O card as the correct I / O card). As a second example, the same problem can occur even if the field device is correctly wired to the marshalling cabinet, but the wiring between the marshalling cabinet and the I / O card is incorrect. As a third example, the same problem can occur due to cross-marshalling, even if the field device and the I / O card are correctly wired to their respective marshalling cabinets. Furthermore, errors can occur if an engineer assigns an I / O channel to the wrong system variable, even if all the wiring is correct. It can be extremely difficult to identify the cause of the error and determine whether such an error is due to a wiring error or a software configuration error. In short, like the maze of wiring behind billions of televisions around the world, it's becoming increasingly difficult to keep track of where wires come from and where they're going, and the opportunity for human error is growing.

[0017] To further compound the problem, field cabling activities often need to begin long before the I / O subsystem(s) design is complete, resulting in a period of uncertainty during the design phase and assumptions being made based on possible changes in available information (due to changes in project scope or changes in control logic resulting in hardware changes). Such late changes are expensive, especially when field devices must be redistributed to new controllers. Such changes are expensive not only because of the rewiring of communication links to the new I / O cards, but also because of the additional cabinet space required to accommodate the additional equipment.

[0018] In short, adding a processing controller or other element of the I / O network to make a late design change is costly because such a change affects the design drawings, the field wiring, and sometimes the system cabinet footprint. Every project has late changes. Such changes can be caused by changes in the control strategy, late changes in skid equipment requirements, underestimation of the required control CPU power, adding field devices, changing device types (e.g., replacing limit switches with analog transmitters), etc.

[0019] Such late project changes, a common challenge with I / O requirements, can have a domino effect throughout the project implementation: reworking diagrams, splitting control systems, moving wires, and building new cabinets. Even a simple task such as replacing an installed field device can become complicated. For example, if an installed field device connected to a DO I / O card is replaced with a new field device configured to receive control commands through analog signals, the field engineer must find an AO I / O card with an empty channel or install a new AO I / O card. The field engineer must then remove the wiring between the field device and the marshalling cabinet, the wiring between the terminals in the marshalling cabinet, and the wiring between the marshalling cabinet and the I / O card. Finally, the field engineer must wire the new field device to the marshalling cabinet, wire the new I / O card to the marshalling cabinet if necessary, and verify that the cross-marshalling in the marshalling cabinet correctly connects the appropriate terminals in the marshalling cabinet.

[0020] In short, late changes add time, cost, and risk to a project, a problem exacerbated by the inflexibility of traditional, dedicated I / O architectures and the cross-marshalling required to verify that a field device is communicatively coupled to the appropriate I / O card and I / O card channel.

[0021] With respect to the commissioning phase, commissioning of a process plant or system includes the process of bringing various components of the plant or system to a point where the system or plant operates as intended. After the process elements are installed, at least some of the process elements are subject to commissioning. For example, field devices, sample points, and / or other elements are subject to commissioning. The commissioning process is usually a complex process involving multiple activities. For example, the commissioning process may include, among others, verifying or confirming the identification of the installed process controllers (e.g., field devices) and their predetermined connections, determining and providing a tag that uniquely identifies the process controller within the process control system or plant, setting or configuring initial values ​​for device parameters, limits, etc., verifying the correctness of the installation, operation, and behavior of the devices under various conditions, for example by manipulating signals provided to the devices and performing other tests, and other commissioning activities. Validation of devices during commissioning is important for safety and compliance with regulatory and quality requirements.

[0022] Other commissioning activities are performed in device-related process control loops. Generally, a "process control loop" includes one or more field devices and a controller configured to communicate with each other to implement a control scheme. For example, a control loop may include a field device (e.g., a control valve for an inlet pipe to a tank) that can be actuated to change a manipulated variable (e.g., cold water flows through a pipe when the valve is open), one or more field devices that measure one or more controlled variables that are affected by the change in the manipulated variable (e.g., temperature of the water in the tank), and a controller that controls the actuated field devices to reach a desired value of the manipulated variable.

[0023] In any case, commissioning activities in a control loop may include, for example, verifying that various signals sent through an interconnection (e.g., an interconnection found in a marshalling cabinet) are behaving as expected at both ends of the interconnection, generating an as-built I / O list that shows that devices running within the plant are actually physically connected, and recording other “as-built” data, to name a few.

[0024] Typically, commissioning of a treatment plant requires physical equipment, connections, wiring, etc. to be installed, configured, and interconnected in the treatment plant's field environment. In the plant's back-end environment, data identifying and / or corresponding to the various equipment, their configurations, and interconnections is consolidated, verified or commissioned, and stored. Thus, after the physical hardware is installed and configured, identification information, logic instructions, other instructions, and / or data are downloaded or otherwise provided to the various devices located in the field environment to enable the various devices to communicate with the other devices.

[0025] Of course, in addition to the commissioning activities that are performed in the back-end environment, there are also commissioning activities to individually and collectively verify the correctness of the connections and operation of the physical and logical devices in the field environment. For example, field devices are physically installed and individually verified, e.g., powered on, powered off, etc. Then, the ports of the field devices are physically connected to a commissioning tool, whereby simulated signals are sent to the field devices and the behavior of the field devices in response to the various simulated signals is tested. Similarly, field devices with communication ports to be commissioned may finally be physically connected to terminal blocks in a marshalling cabinet and the actual communication between the terminal blocks and the field devices may be tested. Commissioning may reveal errors in the system design or in the field wiring. Such errors may result in costly late project changes as mentioned above.

[0026] Typically, commissioning of field devices and / or other components in a field environment requires knowledge of the component identities, and in some cases, component interconnections, so that test signals and responses can be communicated between the field devices and other loop components and the resulting behavior can be verified. In currently known commissioning techniques, such identity and overall connectivity knowledge or data is typically provided to the components in the field environment by a back-end environment. For example, the back-end environment downloads field device tags used by a control module to smart field devices that are controlled by the control module during actual plant operation. [Means for solving the problem]

[0027] Disclosed herein are techniques, systems, equipment, components, devices, and methods for adding smart functionality to "dumb" discrete field devices and discrete signals. The techniques, systems, equipment, components, devices, and methods may be applied to industrial process control systems, environments, and / or plants (which are synonymous herein with "industrial control," "process control," or "process" systems, environments, and / or plants). Typically, such systems and plants individually provide control of one or more processes (also referred to herein as "industrial processes") that are operated to manufacture, refine, or transform physical ingredients to create or manufacture products.

[0028] The above techniques, systems, equipment, components, devices, and methods allow a set of discrete I / O channels for one or more field devices to be grouped, organized, and connected to a field module device (sometimes more generally referred to as a "field module," "process control device," or "process control entity"), which may then be connected through an I / O channel to electronic marshalling equipment in a marshalling cabinet. The field module acts as an intermediate device, decoding messages received over the I / O channel and identifying commands for a DO channel, which are then forwarded to the appropriate DO channel. Advantageously, a controller can reference multiple DO signals over a single I / O channel connected to the electronic marshalling equipment. The field module also receives variable values ​​carried by signals on the DI channel, encodes the values ​​into messages that are sent to the marshalling equipment and the controller, making the variable values ​​on the DI channel available to the controller.

[0029] A field module may store a profile that includes information related to the commissioning and configuration of the field module and any connected field devices, such as tags unique to the field devices and / or signal tags unique to the DI and DO channels. The information in the profile can be auto-sensed by the electronic marshalling equipment (and in particular by signal characterization components connected to the marshalling equipment) so that any tag in the profile can be assigned / connected to an I / O channel where a corresponding DI or DO signal is present. With such auto-sensing and connection techniques for auto-sensing the field module tags and automatically updating the tag connections, the I / O network can be easily and quickly reconfigured and wired.

[0030] One or more controllers may be configured to automatically configure a DIO control element or function block corresponding to a field module, which may then be utilized by a control routine to write to a DO signal connected to the field module and / or read values ​​carried by a DI signal connected to the field module. During such an automatic configuration procedure, the input of the DIO control element is connected to a signal tag representing the DO signal connected to the field module, allowing other routines or blocks to write to the DO signal by writing to the DIO control element input. Similarly, the output of the DIO control element is connected to a signal tag representing the DI signal, allowing other routines or blocks to receive and read the output of the DIO control element to read values ​​carried by the DI signal.

[0031] Also described herein is a portable device that is utilized to update the profile of a field module. In general, the portable device may establish one or more short-range communication channels with the field module and use the communication channels to download new information to the profile of the field module. Exemplary short-range communication channels include an RFID channel, an NFC channel, a Bluetooth channel, and a WiFi Direct channel. The portable device allows a person in a field environment to quickly and easily update a field module while near the field (e.g., after updating field wiring to add, replace, or remove a channel from a field device) without returning to a workstation in a back-end plant environment. Thus, the person can use the portable device to visually view the field module and verify or re-verify whether the information in the updated profile accurately reflects changes in the field wiring, field device connections, or control scheme.

[0032] The above summary is provided for the purpose of introducing some of the concepts that are described in more detail below. As described in the detailed description, some embodiments may include features and advantages not described in the above summary and some embodiments may omit one or more of the features and / or advantages described in the above summary. [Brief description of the drawings]

[0033] [Figure 1A] FIG. 1A is a block diagram of an example processing plant including an I / O network configured with one or more discrete I / O networks described herein and commissioned using one or more smart commissioning techniques described herein. [Figure 1B] FIG. 1B illustrates an example of a control routine implemented in the controller shown in FIG. 1A. [Diagram 2]FIG. 2 is a block diagram illustrating a conventional I / O network having a dedicated I / O architecture, including fixed dedicated I / O cards and direct marshalling. [Diagram 3] FIG. 3 is a block diagram illustrating one of the I / O networks shown in FIG. 1A that can be easily designed, wired, redesigned, and commissioned using the techniques described herein. [Figure 4A] FIG. 4A illustrates an unconfigured DIO control element created from a template that is used to create an example DIO control element (eg, the DIO element shown in FIG. 3). [Figure 4B] FIG. 4B illustrates a control routine that includes a discrete control (DC) function block that is linked to one or more other blocks (e.g., the DIO element shown in FIG. 4A), receives discrete input signal(s) from the linked block(s), and provides discrete output signals to the linked block(s) based on logic performed by the DC function block. [Diagram 5] FIG. 5 shows a profile view of an example electronic marshalling block or device that supports the electronic marshalling components shown in FIG. [Figure 6] FIG. 6 is a flow chart of an example method for smart commissioning a field module (eg, the field module shown in FIG. 3). [Figure 7] FIG. 7 is a flow chart of an exemplary method for automatically configuring a field module and a control element associated with one or more discrete inputs or outputs for a field device (eg, a control element as shown in FIG. 3). [Figure 8A] FIG. 8A is a block diagram of an exemplary mobile device used to update a profile of a field module (eg, a field module such as that shown in FIG. 3). [Figure 8B] FIG. 8B is a flow chart of an exemplary method for updating a profile using a mobile device such as that shown in FIG. 8A. [Figure 9A] FIG. 9A illustrates an exemplary data or communication signal carried by a channel connecting the field modules and DIO CHARMs shown in FIG. 3 and encoded, decoded, transmitted, or received according to a first protocol. [Figure 9B] FIG. 9B illustrates an exemplary data or communication signal carried by a channel connecting the field modules and DIO CHARMs shown in FIG. 3 and encoded, decoded, transmitted, or received according to a second protocol that offers many advantages over the first protocol shown in FIG. 9A. [Figure 10A] FIG. 10A is a flow chart of an exemplary method performed by the DIO CHARM and / or field module shown in FIG. 3 to encode a message conforming to the protocol shown in FIG. 9B. [Figure 10B] FIG. 10B is a flow chart of an exemplary method performed by the DIO CHARM and / or field module shown in FIG. 3 to decode a message conforming to the protocol shown in FIG. 10A. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] As described above, a process plant, process control system, or process control environment that operates to control one or more industrial processes online in real time may be commissioned using one or more of the novel smart commissioning techniques, systems, equipment, components, apparatus, and / or methods described herein. The process plant, when commissioned and operated online, includes one or more wired or wireless process control devices, components, or elements that perform physical functions in cooperation with the process control system to manage one or more steps occurring within the process plant. The process plant and / or process control system may include, for example, one or more wired and / or wireless communication networks. In addition, the process plant or control system may include centralized databases, for example, continuous type, batch type, asset management type, historian type, and other types of databases.

[0035] This specification is divided into the following sections: (I) an exemplary plant environment in which the improved I / O network for discrete processing elements is used; (II) a conventional I / O network using dedicated I / O architectures including fixed, dedicated I / O cards, and direct marshalling; (III) an improved I / O network for discrete processing elements; (IV) smart commissioning techniques for discrete processing elements; (V) an improved discrete I / O communication protocol; and (VI) other considerations.

[0036] I. Exemplary Plant Environment 5 1A is a block diagram of an exemplary process plant, process control system, or process control environment 5 that includes an input / output (I / O) network 7 configured in accordance with one or more of the discrete I / O signal management techniques described herein. In the process control industry, the term "I / O" may be used in a number of related but distinct contexts. The term generally refers to a logical link or communication channel that communicatively couples a field device to an I / O card or controller (e.g., an "I / O channel"), but also refers to numerous other concepts, such as a device that sends signals to or receives signals from an I / O channel (e.g., an "I / O device" or "I / O card"), a connector or terminal associated with an I / O device (e.g., an "I / O connector"), a signal transmitted on an I / O channel (e.g., an "I / O signal"), a variable or command represented by the signal (e.g., an "I / O parameter"), a value of a variable or command conveyed ... In some embodiments, the term "I / O" may be used to refer to a communication link, such as an I / O parameter value, a communication link, or a combination of both. When the term "I / O" is used herein without qualifiers, it should be clear from the context which of these concepts is being discussed. Furthermore, it should be understood that "I / O channel" refers to a particular type of "communications channel" or "channel." That is, unless otherwise indicated by context, when the term "channel" or "communications channel" is used without the qualifier "I / O," in some embodiments the communication link may be an I / O channel and in some embodiments the communication link may be other than an I / O channel.

[0037] The process plant 5 manages a process and has one or more "process outputs" (e.g., tank levels, flow rates, material temperatures, etc.) that characterize the state of the process and one or more "process inputs" (e.g., various environmental conditions and actuator states that can be manipulated to cause changes in the process outputs). The process plant or control system 5 of FIG. 1A includes a site environment 122 (e.g., the "process plant floor 122") and a back-end environment 125, which are communicatively interconnected by a process control backbone or data highway 10 (which may include one or more wired and / or wireless communication links and be implemented using any desired or suitable communication protocol, such as the Ethernet protocol).

[0038] At a high level (as shown in FIG. 1A ), the site environment 122 includes physical components (e.g., process control devices, networks, network elements, etc.) that are arranged, installed, and interconnected to perform processing at run time. For example, the site environment includes I / O network 6 and I / O network 7. Each such I / O network component is generally arranged, installed, or otherwise included in the site environment 122 of the processing plant 5. Generally, in the site environment 122 of the processing plant 5, raw materials are received and processed using the physical components arranged on-site to produce one or more products.

[0039] In contrast, the back-end environment 125 of the processing plant 5 includes various components, e.g., computer equipment, operator workstations, databases, data banks, etc., that are shielded and / or protected from the harsh conditions and materials of the site environment 122. In some configurations, the various computer equipment, databases, and other components and equipment included in the back-end environment 125 of the processing plant 5 may be located in different physical locations, i.e., some may be located at the processing plant 5 and some may be located at remote locations.

[0040] (A. Plant 5 Site Environment 122) As described above, field environment 122 includes I / O networks 6 and 7, each coupled to 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) to facilitate communication between the controllers and the field devices.

[0041] Each process controller of the process plant 5 implements a control strategy defined by one or more control routines, which may be stored in the controller's memory. When the controller's processor executes the one or more control routines, the controller sends control signals (i.e., "control outputs") to the field devices over a wired or wireless process control communication link or network to other field devices to control the process of the plant 5. The controller may generate the control signals based on (i) one or more received signals (which may be referred to as "control inputs") (e.g., one or more received signals indicative of measurements obtained by the field devices) and (ii) the logic of the one or more control routines (logic defined by one or more software elements (e.g., function blocks)). In general, the controller manipulates process inputs (which may be referred to as "manipulated variables") to change a particular process output (which may be referred to as a "controlled variable" or simply a "process variable") based on feedback (i.e., measurements of the controlled variables) and desired values ​​(i.e., setpoints) for the process outputs.

[0042] To control the processes performed in the process plant 5, at least one field device performs a physical function (e.g., opening and closing a valve, raising and lowering a temperature, taking measurements, sensing a condition, etc.). One type of field device communicates with a controller using an I / O device (e.g., an "I / O card"). The process controllers, field devices, and I / O cards may be wired or wireless, and the process plant environment or system 5 may include any number and combination of wired and wireless process controllers, field devices, and I / O devices.

[0043] 1A shows a processing controller 11 communicatively connected to wired field devices 15-22 through input / output (I / O) cards 26 and 28, and to field devices 40-46 through a wireless gateway 35 and data highway 10. In some configurations (not shown), the controller 11 may be communicatively connected to one or more communications networks other than the backbone 10, e.g., to a wireless gateway 35 using any number of other wired or wireless communications links supporting one or more communications protocols, e.g., WIFi or other IEEE 802.11 compliant wireless local area network protocols, mobile communications protocols (such as WiMAX, LTE, other ITU-R compliant protocols), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Fieldbus, etc.

[0044] The controller 11, which may be, for example, a DeltaV® controller sold by Emerson Process Managenet, may be operated to perform batch or continuous processing with at least some of the field devices 15-22 and 40-46. In one embodiment, the controller 11 is communicatively connected to the process control data highway 10, as well as to at least some of the field devices 15-22 and 40-46 using, for example, standard 4-20 mA devices, I / O cards 26, 28, and / or any smart communication protocol (e.g., FOUNDATION® Fieldbus protocol, HART® protocol, WirelessHART® protocol, etc.). In FIG. 1A, the controller 11, field devices 15-22, and I / O cards 26, 28 are wired devices, and the field devices 40-46 are wireless field devices. Of course, the wired shielded devices 15-22 and the wireless field devices 40-46 could also be compatible with any other desired standard(s), such as any wired or wireless protocol (including any standard or protocol developed in the future).

[0045] The process controller 11 of FIG. 1A includes a processor 30 that implements or oversees one or more process control routines 38 (e.g., routines stored in memory 32). The processor 30 is configured to communicate with the field devices 15-22 and 40-46, and other nodes communicatively connected to the controller 11. Any of the control routines or modules described herein may have portions implemented or executed in different controllers or other devices, if desired. Similarly, the control routines or modules 38 described herein implemented within the process control system may have any form including software, firmware, hardware, etc. The control routines may be implemented in any desired software format using object-oriented programming, ladder logic, sequential function charts, function block diagrams, or any other software programming language or design paradigm. The control routines 38 may be stored in any desired type of memory 32, e.g., random access memory (RAM), or read-only memory (ROM). Similarly, the control routines 38 may be hard-coded, for example, in one or more EPROMs, EEPROMs, application specific integrated circuits (ASICs), or any other hardware or firmware elements. Thus, the controller 11 may be configured to implement a control strategy or routine in any desired manner.

[0046] The controller 11 implements its control strategies using what are generally referred to as function blocks. Each function block is an object or other portion (e.g., a subroutine) of an overall control routine and works with other function blocks (through communication means called links) to implement a process control loop within the process control system 5. A control-based function block typically performs one of the following: (i) an input function (also referred to as an "input block") associated with an input, e.g., a transmitter, sensor, or other process parameter measuring device; (ii) a control function (also referred to as a "control block") associated with a control routine that performs a control function, PID, fuzzy logic, etc.; and (iii) an output function (also referred to as an "output block") that controls the operation of a device, such as a valve, to perform some physical function within the process control system 5. Of course, hybrid and other types of function blocks exist as well.

[0047] The function blocks may be stored and executed within the controller 11, as is the case for those used with or associated with certain types of smart field devices, such as standard 4-20 mA devices and HART® devices, or may be stored and executed on the field device itself, as is the case for FOUNDATION® Fieldbus devices. One or more control routines 38 may implement one or more control loops that are performed by operating one or more of the function blocks.

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

[0049] In FIG. 1A, the wireless field devices 40-46 communicate over a wireless process control communications network 70 using a wireless protocol such as the WirelessHART® protocol. Such wireless field devices 40-46 may communicate directly with one or more other devices or nodes of the wireless network 70 (also configured to communicate wirelessly, e.g., using the wireless protocol or another wireless protocol). The wireless field devices 40-46 may utilize a wireless gateway 35 connected to the process control data highway 10 or other process control communications network to communicate with one or more other nodes not configured to communicate wirelessly. The wireless gateway 35 provides access to the various wireless devices 40-58 of the wireless communications network 70. In particular, the wireless gateway 35 provides a communicative link between the wireless devices 40-58 and the wired devices 11-28 and / or other nodes or devices of the process control plant 5. For example, the wireless gateway 35 may provide a communicative link using the process control data highway 10 and / or using one or more other communications networks of the process plant 5.

[0050] The wireless field devices 40-46 of the wireless network 70, like the wired field devices 15-22, perform physical control functions within a process plant, such as opening and closing valves, measuring process parameters, etc. However, the wireless field devices 40-46 are configured to communicate using the wireless protocol of the network 70. Thus, the wireless field devices 40-46, the wireless gateway 35, and the other wireless nodes 52-58 of the wireless network 70 are producers and consumers of wireless communication packets.

[0051] In some configurations of the process plant 5, the wireless network 70 includes non-wireless devices. For example, in FIG. 1A, the field device 48 of FIG. 1A is a legacy 4-20 mA device and the field device 50 is a wired HART® device. To communicate within the network 70, the field devices 48 and 50 are connected to the wireless communication network 70 through wireless adapters 52a, 52b. The wireless adapters 52a, 52b support wireless protocols such as WirelessHART® and one or more other communication protocols such as Foundation® Fieldbus, PROFIBUS, DeviceNet, etc. Additionally, in some configurations, the wireless network 70 includes one or more network access points 55a, 55b, which may be separate physical devices in wired communication with the wireless gateway 35 or may be provided to the wireless gateway 35 as an integrated device. The wireless network 70 may include one or more routers 58 to forward packets from one wireless device to another within the wireless communication network 70. In FIG. 1A, wireless devices 40 - 46 and 52 - 58 communicate with each other and with wireless gateway 35 over wireless links 60 and / or process control data highway 10 of wireless communications network 70 .

[0052] (Plant 5 backend environment 125) As described above, the back-end environment 125 includes various components, such as computer equipment, operator workstations, databases, data banks, etc., that are shielded and / or protected from the harsh conditions and materials of the site environment 122. The back-end environment 125 may include any one or more of the following, each of which may be communicatively connected to the data highway 10: (i) one or more operator workstations 71, (ii) a configuration application 72a and a configuration database 72b, (iii) a data historian application 73a and a data historian database 73b, (iv) one or more wireless access points 74 that communicate with other devices using other wireless protocols, and (v) one or more gateways 76, 78 to systems external to the process control system 5.

[0053] (1. Operator Workstation 71) The operator workstations 71 may be used by an operator to monitor run-time operation of the process plant 5 and may be used to perform diagnostic, corrective, maintenance, and / or other necessary operations. At least some of the operator workstations 71 may be located in various protected locations within or near the plant 5, and in some circumstances, at least some of the operator workstations 71 may be located in remote locations that are still communicatively connected to the plant 5. The operator workstations 71 may be wired or wireless computing devices.

[0054] (2. Data Historians and Databases 73b) The data historian 73a is used to collect some or all of the data provided across the data highway 10 and obtain a history of that data and / or store it for long term storage in a historian database 73b. The data historian 73a and historian database 73b, like the installed applications 72a and 72b, may be centralized and have a single logical appearance within the process control system 5, although multiple data historian applications 73a may run simultaneously within the process control system 5 and the data historian 73b may run across multiple physical data storage devices.

[0055] (3. Wireless Access Point 74) One or more other wireless access points 74 enable devices in the back-end environment 125 (which may be the field environment 122) to communicate with other devices using wireless protocols such as WiFi or other IEEE 802.11 compliant wireless local area network protocols, mobile communication protocols such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution), or other ITU-R compliant protocols, short wavelength wireless communications such as Near Field Communication (NFC) and Bluetooth, or other wireless communication protocols. Typically, such wireless access points 74 enable handheld or other portable computing devices (e.g., user interface devices 75) to communicate over a respective wireless process control communications network that supports a different wireless protocol than wireless network 70, rather than wireless network 70. For example, wireless or portable user interface devices 75 may be mobile workstations or diagnostic test equipment used by operators within the process plant 5 (e.g., in the case of one operator workstation 71). In some scenarios, in addition to the mobile computing devices, one or more processing and control devices (eg, controller 11, field devices 15-22, or wireless devices 35, 40-58) also communicate using a wireless protocol supported by access point 74.

[0056] (4. Gateways 76 and 78) Gateways 76 and 78 may interface with systems external to process control system 5. Typically, such systems are consumers or suppliers of information generated or manipulated by process control system 5. For example, process control plant 5 may include gateway node 76 to communicatively connect the process plant 5 to another process plant. Additionally or alternatively, process control plant 5 may include gateway node 78 to communicatively connect the process plant 5 to an external public or private system, such as a laboratory system (e.g., a Laboratory Information Management System (LIMS)), an operator round database, a material handling system, a maintenance management system, a product inventory management system, a manufacturing planning system, a weather data system, a goods shipping system, a packaging system, the Internet, another provider's process control system, or other external systems.

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

[0058] (Settings application 72a and database 72b) The remaining configuration applications 72a and configuration databases 72b of FIG. 1A may be utilized to configure certain aspects of the plant 5. The configuration applications 72a, which may run on one or more computing devices (not shown) in various cases, allow users to create or modify process control modules and download such modules to the controllers 11 over the data highway 10, as well as to create or modify operator interfaces through which an operator may view data within a process control routine and change data settings. The configuration database 72b stores the modules and / or operator interfaces that have been created (e.g., configured). Generally, the configuration applications 72a and configuration databases 72b may be centralized and have a single logical appearance in the process control system 5, although multiple configuration applications 72a may run simultaneously within the process control system 5 and the configuration databases 72b may run across multiple physical data storage devices. Thus, the configuration applications 72a, databases 72b, and their user interfaces (not shown) comprise a configuration or development system 72 for control and / or display modules. Typically (though not necessarily), the configuration system 72 is utilized by a configuration / development engineer regardless of whether the plant 5 is operating in real time (used herein synonymously with “run time” of the treatment plant 5), but the configuration system 72 is distinct from the operator workstation 71 because the operator workstation 71 is utilized during real-time operation of the treatment plant 5.

[0059] With respect to commissioning, the configuration application 72b may store data and other information to specifically identify and / or address various equipment or components and interconnections planned or desired to be performed on the process plant floor or field environment 122. Some of such commissioning data may be provided to the components of the field environment 122 for use in commissioning the equipment and loops therein, and some of such data may be utilized in the back-end environment 125, for example, for designing, developing, and preparing control modules and / or operator interface modules that will operate with the field environment 122 during actual operation of the process plant 5. As an example, an approved control module may be downloaded to a process controller such that, when executed during actual operation, the process controller will be able to control at least a portion of the process within the process plant 5 by sending and receiving various signals to and from other components in the loop (and, in some cases, to and from other process controllers) in accordance with the resident control module.

[0060] The installation database 72b may store multiple logical identifiers for components in the field environment 122, such that the controller 11 and other devices may use the logical identifiers to reference the components and signals associated with the components. For example, for a particular field device, the configuration database 72b may store information mapping or associating logical identifiers with specific hardware addresses or I / O channels. A hardware address may identify a particular controller, a particular I / O card connected to a particular controller, and / or a particular address for an I / O channel connecting a particular I / O card to a field device. In some examples, such mapping or connection may be stored in the controller 11, the user interface device 75, the operator workstation 71, or any other desired device (e.g., any device that needs to know the logical identifiers). Once a logical identifier is associated with a hardware address or I / O channel, the identifier is considered "assigned." In some examples, the system 5 may include "unassigned" logical identifiers that are referenced by software elements (e.g., control routines and / or function blocks) but do not have a binding (connection). That is, if the system 5 and configuration database 72b do not have a hardware address or I / O channel bound to the tag, the logical identifier is considered "unassigned." Thus, when an unassigned logical identifier is referenced by a control routine, no value carried by the signal in plant 5 is read, and no command is sent through the signal to the field device in plant 5.

[0061] Examples of such logical identifiers include device tags (DTs) (each of which indicates a particular instrument, controller, valve, or other physical field device) and device signal tags (DSTs) (each of which indicates a particular signal received or generated by a particular piece of equipment and corresponding to a particular parameter typically utilized by a field device). In some equipment, the device signal tag consists of a combination of the device's device tag and an identifier of the particular signal the device receives or generates. In some equipment (typically legacy or dumb equipment), the device tag represents both the physical equipment and the signal the equipment generates. Generally, the logical identifier of an equipment is used by the process plant 5 in both the field environment 122 and the back-end environment 125 to uniquely identify the equipment. DTs and DSTs may be referred to as "system tags" or "system identifiers."

[0062] In some examples, the smart field devices 19-22 may also store a logical identifier that is unique to the smart field device 22. Such a logical identifier may be different from the system tag used by the plant 5 to identify the field devices 19-22 and may be referred to as a "source identifier" or "source tag." The source tag may or may not be stored in the configuration database 72b, depending on the implementation.

[0063] C. Exemplary Control Routine 101 Figure 1B shows a control routine 101, which is an example of one of the control routines implemented by the controller 11 shown in Figure 1A. The control routine 101 includes four blocks: an analog input (AI) block 102, an AI block 104, a control block 106, and an AO block 108.

[0064] The routine 101 is designed and created using any suitable configuration and design system executing on any suitable computing device (e.g., a fixed workstation or desktop, laptop, tablet, etc.). The designer creates the routine 101 by dragging and dropping each block from a library onto a canvas area (not shown) displayed by the application 72a. The designer then instantiates and configures each block and creates links between the blocks to define the control routine 101.

[0065] Although the control routine 101 provides an analog output based on a set of analog inputs, it will be understood that the control routines implemented by the controller 11 or other controllers of the plant 5 can provide any suitable number of analog or digital outputs based on any suitable number of analog or digital inputs. Inputs to the control function blocks and control routines used in the plant 5 may be parameter values ​​received from field devices (e.g., through analog input blocks or discrete input blocks) or parameter values ​​received from other control function blocks or other control routines. Similarly, outputs provided by the control function blocks and control routines implemented by the controllers in the plant 5 may be parameter values ​​or commands provided as inputs to other control routines or blocks (e.g., discrete or analog output blocks that provide parameters or commands to field devices, control function blocks such as PID blocks or discrete control blocks, etc.). Although the control routine 101 has a PID function block 106, it will be understood that the control routines implemented in the plant 5 can utilize other types of control function blocks. For example, FIG. 4B illustrates exemplary discrete control (DC) function blocks used in the control routines implemented by the controllers.

[0066] In any event, a designer may use the configuration application 72a shown in FIG. 1A to design the routine 101 and other control routines implemented by the controller described herein. In particular, the designer may design the routine by adding visual representations of blocks that the designer wishes to include in the routine to a "canvas area," influencing the visual representations (e.g., clicking on the visual representations to activate drop-down menus that allow such configuration), and establishing connections between the inputs and outputs of the blocks to define the flow of information between the blocks to facilitate logical design of the broader control routine. For example, with particular reference to the control routine 101, the designer may drag a generic PID block template (not shown) onto the canvas area to instantiate the PID function block 106 shown in FIG. 1B. At a high level, a PID block contains logic that drives a process variable (PV) or controlled variable (CV) (e.g., the temperature level of a tank fluid) to a desired level or set point (SP) by manipulating a manipulated variable (MV) (e.g., the position of a control valve in a hot water intake line). A typical PID block template is configured to (i) calculate the error 114 between the set point 112 and the measured process variable 114, and (ii) apply a proportional term 118, an integral term 120, and / or a derivative term 122 to the error 116 to obtain an output value 126. Typically, the output value 126 indicates the additional change to the MV required to move the PV 114 closer to the set point. As an example, the PID block may open a valve gradually over time to avoid overshooting the SP 112, and then rely on feedback of the measured PV 114 to further incrementally increase the command to open the valve (or decrease it as the PV 114 approaches the SP 112). When the error 114 is zero, the output 126 is zero, indicating that no further change is required to achieve the desired SP 112.

[0067] Upon instantiating the function block 106, the designer may set the parameters 118-122 to affect the operation of the function block 106. For example, the designer may modify one or more of the terms 118-122 to modify the block 106 to reach SP more quickly (increasing the risk of overshooting SP 112 and causing oscillations) or may modify one or more of the terms to cause the control variable to reach SP 112 at a more moderate rate (reducing the likelihood of overshooting and / or causing oscillations).

[0068] The input blocks 102 and 104 may be instantiated by dragging and dropping template AI blocks onto the canvas area and connecting each to a tag. For example, a designer may connect the AI ​​block 104 to a system tag (e.g., TI-093) unique to a field device for a PV (e.g., temperature) measurement that is desired as the measurement PV 114 for the PID block 106. The user then creates a link between the AI ​​block 104 and the PV 114 of the function block 106, feeding the AI ​​block 104 to the PV 114. A system tag may be connected to the AI ​​block 102 as well. In some examples, the designer may use tags to indicate variables that can be changed by the user (e.g., adjusting a set point). In some examples, instead of using the AI ​​block 102 as an input for the SP 112, the designer may utilize the output of a second function block to implement cascade control.

[0069] Finally, an output block 108 may be instantiated by dragging and dropping a template AO block onto the canvas area and connecting it to a tag (e.g., a tag unique to the control valve). The designer may then link the output 126 to the PID block 106 so that it feeds into the AO block 108.

[0070] The control system 5 may have numerous other block templates configured to use specific routines or logic set to derive outputs, as well as other control routines developed by linking one or more input blocks, control blocks, and / or output blocks created from the templates.

[0071] II. Exemplary Conventional I / O Network 200 and Direct Marshalling 2 is a block diagram illustrating a conventional I / O network 200 having a dedicated I / O architecture that includes fixed, dedicated I / O cards and direct marshalling. At a high level, direct marshalling involves wiring each field device I / O to a specific terminal block in a marshalling cabinet, wiring each I / O card channel to a terminal block in a field terminal array dedicated to that I / O card in the marshalling cabinet, and linking the field device I / O to the I / O cards by cross-marshalling the terminal blocks and FTAs ​​in the marshalling cabinet.

[0072] The I / O network 200 includes a processing controller 158A, a redundant backup controller 158B (collectively "controllers 158") and I / O cards 156A-F (communicatively connected to a set of field devices 152A-K through a marshalling cabinet 150), a set of field junction boxes (FJBs) 154A-D, and several wired links 181A, 181B, and 183.

[0073] The I / O network 200 enables the process controller 158 to control a process or parts of a process through one or more field devices 152. Unfortunately, the design of the I / O network 200 is inflexible and difficult to change after the field wiring is completed, thus making project changes expensive in terms of labor, time, and materials.

[0074] During the design phase of the I / O network 200, a P&ID is designed to provide an initial view of the control elements and how they will be used in the control strategy for the network 200. An instrument list is then derived from the P&ID, which is a detailed list of each element of the design (e.g., field devices), including device type, manufacturer, calibration range, etc., as well as each element's physical location within the process equipment. As part of the configuration phase, the designer defines the field signals associated with each field device 152 and assigns each defined signal to a controller.

[0075] As shown in FIG. 2, each of the field devices 152 has one or more I / O terminals for sending and receiving signals, with each terminal 161-176 having a particular signal type (e.g., AO, AI, DI, or DO). For clarity, from the perspective of the control system, the terminals are labeled as "inputs" or "outputs." For example, terminals 161, 164, 166, 167, and 172 are each configured to transmit analog inputs (i.e., "AI" signals) through the terminals. Terminals 162, 163, and 168 are each configured to transmit analog inputs (i.e., "AO" signals) through the terminals (e.g., signals conveying control commands, such as a command to open a valve). Terminals 169 and 176 are each configured to transmit digital inputs (i.e., "DI" signals) through such terminals. Terminals 165, 170, 171, 173, 174, and 175 are each configured to transmit digital outputs (i.e., "DO" signals) through such terminals.

[0076] 2, each of the signals associated with terminals 161-176 is assigned to controller 158. The number of signals of each signal type specified for terminals 161-176 allows a designer to determine the number and type of each I / O card 156 required for controller 158 to communicate with each input and output of field device 152.

[0077] The selection of I / O cards is important because each I / O card (i) has a limited number of I / O channels and (ii) is configured for and can only be used with a particular type of signal. The term "I / O channel" refers to a logical link that connects an I / O card or controller to a field device. Each I / O channel may include multiple physical links and terminal points for connecting such physical links. I / O card 156 is limited to four I / O channels, while some dedicated I / O cards have a different limited number of I / O channels (e.g., eight channels). Each I / O card 156 is configured for and can only be used with a particular type of signal. As an example, AI I / O card 156A can only transmit AI signals and cannot transmit DI signals or receive DO or AO signals. Such requirements, as well as the requirement that each I / O card 156 support only up to four channels, result in unused and wasted terminal blocks. For example, five of field device terminals 161-176 are configured to transmit AI signals.

[0078] After the design phase is complete, engineers can begin the field wiring development phase. The I / O terminals 161-176 are wired to corresponding field junction boxes FJBs 154A-D, which are then wired to a set of terminals 192 in the marshalling cabinet 150. Each of the terminals 161-176 is connected to a corresponding terminal on the FJB and to a corresponding terminal 192 in the marshalling cabinet 150. That is, for each I / O terminal 161-176 that is present, a corresponding terminal 192 must be used. The set of terminals 192 are wired to a field terminal assembly (FTA), and each of the FTAs ​​is wired to a corresponding I / O card 156A-F.

[0079] The process of wiring the terminals 192 to the FTAs ​​194 is called "cross-marshalling." Cross-marshalling is typically necessary because while the organization of the wires connected to the terminals 192 is determined by the physical layout of the plant, the organization of the FTAs ​​194 is determined by the signal types of the I / O cards 156 that are connected to the FTAs. In particular, field devices that share close proximity often share an FJB that is wired to the first available terminal 192, resulting in a grouping of terminals 192 that roughly corresponds to an FJB, but has no other identifiable way of organization. In contrast, the FTAs ​​194 are organized by signal type, since each feeds a specific I / O card 156. For example, FTA 194A corresponds to AI card 156A. Thus, each terminal 194A must be connected to a terminal 192 that is connected to an AI channel (i.e., wired to an AI field device terminal). Similarly, since FTA 194C corresponds to AO card 156C, the terminals of FTA 194C should each be wired to a terminal 192 that is wired to an AO channel (i.e., connected to an AO field device terminal). Similarly, terminal 194D should serve as an interconnect between DI card 156D and a terminal 192 that is wired to a DI field device terminal.

[0080] The channel limitations associated with the dedicated I / O cards result in inefficient placement of the I / O cards, as well as unused I / O channels, terminal blocks, and associated cabinet space within the marshalling cabinet 150. Since each of the I / O cards 156 only supports four channels, two AI cards 156A and 156B must be installed and connected to the controller 158, and two corresponding FTAs ​​194A and 194B must be utilized. Due to the signal count requirements and the limitations of the dedicated I / O cards 156, for example, the FTA 194B has three unused terminals and the I / O card 156B has three unused I / O channels. The incomplete match between the signal requirements for the field devices 152 and the limitations of the I / O cards 156 results in inefficient placement of the I / O cards 156. The controller 158 requires six dedicated I / O cards, despite the fact that the controller 158 has 16 signals assigned to it. If the signal counts were perfectly distributed by type, the controller 158 would only require four I / O cards.

[0081] Furthermore, the I / O network 200 requires an I / O channel for each of the DI and DO terminals 161-176, even if a single field device can transmit or receive multiple inputs and / or outputs. For example, the field device 152I has two DI terminals and one DO I / O terminal, and the field device 152K has one DI terminal and three DO terminals. As a result, if the controller 158 requires multiple parameters obtained by or associated with the field device 152I (e.g., to implement an associated control strategy), an I / O channel must be wired to each parameter indicated by a DI signal, resulting in multiple wired I / O channels and the additional complexity of field wiring. This is problematic because in most plants, the majority of the inputs and outputs of the field devices must be configured for discrete signals.

[0082] In general, the problem of a high ratio of I / O channels to field devices is less of an issue for smart field devices configured to transmit or receive analog signals because of the HART® protocol. The HART® protocol allows bidirectional field communication between smart field devices and controllers by using loop current amplitudes on the I / O channels to transmit or receive analog signals (carrying a "primary variable" value) and superimposing a digital carrier signal on the current loop signal (carrying one or more "secondary variable" values). Thus, smart field devices and / or controllers can transmit and receive not only the primary variable values ​​associated with the AI ​​or AO signals, but also secondary variable values ​​using the superimposed digital carrier signal. As an example, a smart field device configured for analog signals can transmit field device tags, DSTs associated with each primary and secondary variable, status information about the field device, device alarms, etc., using the superimposed carrier signal. The ability of smart field devices to transmit tags as secondary variables is particularly useful when commissioning field devices and setting up I / O networks.

[0083] In contrast, the DI and DO cards 156D-F and field devices 152I and 152K do not have a similar ability to send or receive secondary variable values: they are "dumb devices" that, like most devices configured for discrete signals, can do nothing other than send or receive a single variable value indicated by the signal level on the DI or DO channel.

[0084] Generally, as used herein, as noted above, smart field devices are typically analog devices configured to receive or transmit primary variable values ​​over AI or AO channels, whereas "dumb" or "legacy" field devices typically do not have on-board processor(s) and / or on-board memory, and typically do not have the capability to transmit secondary variable values.

[0085] (I / O network 7 and electronic marshalling for plant 5) FIG. 3 is a block diagram illustrating an I / O network 7 (also shown in FIG. 1A) that provides smart functionality to discrete elements and that can be easily designed, wired, redesigned, and commissioned using the techniques described herein. The I / O network 7 has a set of Signal Characterization Modules (i.e., "CHARMs") that facilitate field wiring, consolidate and organize signals, reduce cabinet footprint, and minimize inefficient I / O card placement. Generally, at a high level, a CHARM is configured to (i) identify and characterize analog or discrete input signals from a field device, identify the information carried by the signal, and forward the identified information in an acceptable format (e.g., over a digital communication bus) to an I / O card or controller, or (ii) identify and characterize signals from an I / O card or controller (e.g., by identifying voltage or current levels on a digital communication bus), identify the information carried by the signal, and forward the identified information to the appropriate field device (e.g., through an analog or discrete output signal sent to the field device). In some examples, the CHARMs described in this disclosure are synonymous with "electronic marshalling components" or "signal characterization components."

[0086] Additionally, network 7 includes an input and output (DIO) subnetwork 299 that includes CHARM 293M, a field module 291 coupled to CHARM 293M through bidirectional communication channel 282, and one or more field devices coupled to field module 291 through I / O subchannels carrying DI or DO signals. DIO subnetwork 299 allows plant 5 to "tag" dumb field devices that rely on discrete I / O signals for communication and to implement "smart" functions not normally available to dumb field devices. CHARM 293M, unlike a typical DI or DO CHARM, is capable of bidirectional communication and can also be coupled to multiple discrete input or discrete output channels coupled to one or more field devices.

[0087] The I / O network 7 includes field devices 252A-K, an FJB 254-D including terminals 255A-D, a field module 291, a marshalling cabinet 150 including a CHARM I / O or CI / O card 256A and a backup CHARM I / O card 256B, a set of CHARMs 293, and processing controllers 258A-B.

[0088] Field devices 252A-K are similar to field devices 152A-K shown in FIG. 2 and field devices 15-22 shown in FIG. 1A. During the design phase of developing I / O network 7, the designer develops an instrument list and defines the field signals associated with each of field devices 252A-K. Like field devices 152A-K, field devices 252A-K each have one or more I / O terminals or connectors 261-276 for sending or receiving signals, and connectors 261-276 each have a specific signal type (e.g., AO, AI, DI, or DO). Near the end of the design phase, the designer develops the signal numbers for each type of signal that are specific to terminals 261-276. Using the signal numbers, the designer can determine the number and type of each CHARM 293 that controller 258 needs to communicate with each of the inputs and outputs of field device 252.

[0089] After the design phase is complete, engineers can begin the field wiring phase of development: I / O terminals 261-276 are wired to corresponding FJBs 254A-254C, which are then communicatively connected to CHARMs 293A-L.

[0090] (CHARM293 and CI / O card 256 in AI / O network 7) Each CHARM 293 is a pluggable / removable electronic component that can be inserted into the marshalling equipment through a socket connected to a terminal block of the marshalling cabinet 250. Each CHARM 293 may have (i) a first communication interface communicatively connected to a first link (e.g., a backplane bus supporting digital communications) to an I / O card 256 and establishing communication with the I / O card 256, and (ii) a second communication interface communicatively connected to a second link to a field device (e.g., through a terminal block and a two, three, or four wire connection between the terminal block and the field device terminal). The CHARMs 293 may obtain power through one or more of the backplane and / or the first communication interface.

[0091] A CHARM is configured to receive a particular type of signal through a first communication interface and transmit the information carried by that signal through a second interface, or vice versa. A CHARM configured to communicate with a field device through an analog signal may have an analog-to-digital converter (A / D) to allow signal conversion between a digital signal on the first link and an analog signal on the second link. For example, a CHARM configured to receive an analog input signal may receive an analog 4-20 mA signal, determine a parameter value based on the current amplitude of the signal, and transmit the parameter value to a controller or I / O card through a digital communication bus. As a second example, a CHARM configured to transmit an analog or discrete output signal may receive commands or parameter values ​​for a target field device through a communication bus and transmit the analog or discrete signal to the target field device through the appropriate I / O channel.

[0092] The socket into which the CHARM is inserted has a terminal block that can be wired to the appropriate field device inputs / outputs to communicatively connect the field device to the I / O card 256. The CHARM 293 can effectively replace the terminals 192, FTAs ​​194, and I / O cards 156A-F shown in FIG. 2. Unlike the I / O card 156 of FIG. 2, the I / O card 256 can be connected to the backbone 10 as well as any process controller connected to the backbone 10. That is, the I / O card 526 need not be assigned to a single controller. One might think that the marshalling cabinet 250 could be a single I / O card that can be connected to any desired process controller of the plant (e.g., through the link 284 and / or the backbone 10 shown in FIG. 1), thereby connecting the controller to all field device inputs and outputs connected to the cabinet 250. In some examples, the I / O card 256 supports 96 field device signal connections or I / O channels.

[0093] Advantageously, CHARM 293 allows a technician to wire a field device 252 to any terminal block without having to worry about cross-wiring. A technician simply wires the field device to a terminal block and inserts a CHARM configured for the appropriate signal type to establish communication between the field device and the I / O card. For example, field device 252A is configured to transmit AI signals. Thus, a technician may insert AI CHARM 293A into the terminal block wired to field device 252A so that I / O card 256 (and ultimately controller 258) can receive the AI ​​signals transmitted by field device 252A.

[0094] As noted above, the I / O cards 256 may be communicatively connected to each CHARM 293 through the backplane bus. Additionally, the I / O cards 256 may be communicatively connected to the controller through a communication link 284, which may be wired (e.g., an Ethernet link) or wireless. In some examples, the link 284 may be direct, while in other examples, the link 284 may have one or more other links, nodes, and / or networks. For example, the I / O cards 256 may be connected to the controller 258 through the backbone 10 shown in FIG. 1A. Such an implementation allows any C-IO card, such as the I / O card 256, to communicate with any appropriately configured controller, and therefore each such controller to communicate with any field device connected to the C-IO. Such a many-to-many mapping between I / O cards and controllers offers numerous improvements (e.g., flexibility with redesign and rewiring) over conventional controller and I / O card implementations, where each I / O card is assigned to a specific controller and field devices connected to an I / O card can only be controlled through such assigned controller.

[0095] 2, the I / O cards 256 are not part of a single assembly with the controller. Although the I / O cards 156 generally must be located where the corresponding controller 158 is located, the I / O cards 256 may be located remotely relative to the controller 258 (e.g., in a marshalling cabinet 250 in a field environment). Of course, in some instances, the I / O cards 256 may share a location with the controller 258, may share an assembly with the controller 258, or may be connected to the same backplane and communication bus as the controller 258. In operation, the I / O cards 256 receive signals from one or more CHARMs 293 over the backbone bus and forward the information carried by the signals to the controller 258. Additionally, the I / O cards 256 may receive signals from the controller 258 carrying messages containing commands and forward the commands over the backplane bus to the appropriate CHARM (e.g., based on the particular field device or CHARM identified in the message as being associated with the command).

[0096] (CHARM293 of BI / O Network 7) CHARM 293M is special within I / O network 7. Unlike CHARMs 29A-L, CHARM 293M is configured to communicate bidirectionally through an I / O channel that couples one or more field devices to CHARM 293M. In particular, CHARM 293M communicates bidirectionally through a communication channel 282, which is shown as including two physical links 28A (connecting field module 191 to one of terminals 255D of FJB 254D) and 282B (connecting terminal 255D to CHARM 293M).

[0097] The CHARM 293M is coupled to a field device I / O connector through a field module 291 and may support as many field device signals as the field module 291 supports. In a typical example, the field module 291 supports up to eight field device signals (which may be any desired combination of discrete inputs and discrete outputs). In some examples, the shield module 291 and the CHARM 293M may support four signals, sixteen signals, or any other desired number of field device signals.

[0098] In operation, CHARM 293M receives one or more commands for discrete outputs (DOs) through a link to I / O card 256 and / or controller 258 and encodes the commands into a message (sometimes referred to as a "DO message") that is transmitted via a signal sent to field module 291. For example, referring to FIG. 3, CHARM 293M encodes into a message a first command for DO 273, a second command for DO 274, and a third command for DO 275. Each command may be binary and is therefore represented by a single bit. The encoded message is transmitted via a signal on channel 282 and is received and decoded by field module 291. Field module 291 then transmits the command to the appropriate DO.

[0099] Additionally, CHARM 293M may receive messages (sometimes referred to as "DI" messages) that include information transmitted by one or more field device discrete inputs (DIs) (e.g., DIs 276) connected to field module 291. CHARM 293M may decode the DI messages and identify variable values ​​or other information from each of the one or more field device DIs connected to field module 291, and then forward the received variable values ​​to I / O card 256 and / or controller 258. In addition to forwarding the variable values, CHARM 293M may also send tags associated with each variable value so that controller 258 knows which process variables have which values.

[0100] As mentioned above, the CHARM 293M is capable of bidirectional communication with the field module 291M. The devices may rely on clock synchronization to send alternating DI and DO messages. Additionally, the communication signals on the channel 282 may be superimposed on the DC power that the CHARM 293M provides to the field device 291. The CHARM 293M may obtain this power from a power bus that connects the CHARM 293M to the I / O card 256. The CHARM 293M may have coupling circuitry to provide the communication signals to the power on the channel 282 and / or decoupling circuitry to separate the communication signals from the power on the channel 282. The communication between the field module 291 and the CHARM 293M is described in more detail below with reference to FIGS. 9A, 9B, 10A, and 10B.

[0101] (Field module 291 of CI / O network 7) The field module 291 is an electronic process control device, apparatus, or component configured to act as a communication interface between (i) multiple discrete communication channels connected to field device inputs and / or outputs and (ii) a single discrete communication channel connecting the field module 291 to a CHARM, an I / O card, and / or a controller. The field module 291 may have a housing (not shown) and may be located in any suitable location within the process plant 5 (e.g., near a group of discrete input and / or output connectors for one or more field devices). Additionally, the field module 291 may store a profile including a tag unique to the field module 291 and may upload the tag and other profile information to the CHARM, an I / O card, and / or a controller to facilitate commissioning, configuration, and operation of the connected field devices, signals, and field module 291. In some examples, the field module 291 provides power to the field device or element receiving the DO signal.

[0102] Advantageously, the field module 291 enables "smart commissioning" of discrete input and output signals and field devices in the plant 5. During smart testing, tags for discrete signals are "auto-sensed" through the field module 291 and connected (e.g., through the configuration database 92b) to the physical channels carrying the signals, so that controllers and other devices can reference the DI values ​​and / or send commands to the field devices through DO signals by referencing the tags. Previously, smart commissioning and auto-sensing was not possible with respect to discrete devices and signals. Typical discrete devices are "dumb" in the sense that they cannot store information or transmit anything through discrete signals other than a single binary variable value. Thus, unlike smart field devices (e.g., HART devices) that are configured to transmit messages through analog signals, such dumb discrete devices have no way to store tags or transmit tags to other devices, and therefore do not have the ability to perform smart commissioning. Unfortunately, a significant amount of the equipment in many plants consists of discrete devices such as limit switches and solenoids.

[0103] Moreover, the field module 291 allows the discrete devices to communicate through simple DI and DO signals. No modification of the field devices is required, and from the field device's point of view, the connection of the field wiring in the field devices is no different from a normal system. In other words, the field module 291 enables smart commissioning while avoiding expensive and complex retrofitting of the discrete devices. Such retrofitting efforts can be challenging due to certain discrete devices (especially solenoids) having (i) high inductance and, as a result, tendency to interfere with communication signals, and (ii) high power requirements that cannot be met by traditional communication protocols (HART and other analog communication protocols).

[0104] The field module 291 may include a processor 291A, an I / O interface 291B, a power source 291C, a memory 291D that stores one or more routines 291E and profiles 291F, and / or one or more communication interfaces 291G-I. The processor 291 executes one or more routines that enable the field module 291 to provide the functionality conferred upon the field module 291 by this specification. In some examples, the field module 291 may additionally or instead include an ASIC (not shown) that provides some of the functionality of the field module 291 described herein.

[0105] The power source 291C provides power to one or more DOs (e.g., DO 273) connected to the field module 291. In some examples, the field module 291 does not include or utilize a power source. For example, the field module 291 receives power through a channel 282 available for both power and data transmission (e.g., data signals are superimposed on 24V DC power). The field module 291 may have a coupling circuit to provide communication signals to the power of the channel 282 and / or a decoupling circuit to separate communication signals from the power of the channel 282. The field module 192 may distribute the received power to connected DOs that require power. However, in some implementations, the power received from the channel 282 may be insufficient to power all of the DOs connected to it, especially DOs that require high power (e.g., solenoids). In such examples, the power source 291C provides power to such DOs. In some examples, the power source 291C shares a housing with other components of the field module 291. In other examples, the power source 291C is external to the housing.

[0106] The communication interface 291G of the field module 291 has connectors (e.g., terminals) for connection to the I / O connectors 273-276 of the field device 252k. The field device 252k is wired to the field module 291 in a manner similar to that which would be wired to an FJB or conventional marshalling cabinet (e.g., the field device I / O terminals or terminal blocks may each be wired to the field module 291 through two, three, or four wire connections), although in some examples are connected through other means. In some examples, the field module 291 is connected to I / O connectors for multiple field devices (e.g., field devices 252I and 252k).

[0107] The communication interface 291H has connectors (e.g., terminal blocks or ports) for connecting the communication channel 282 to the FJB, CHARM, I / O card, and / or controller. The single communication channel 282 is generally a serial data transmission channel established through conventional field wiring (e.g., two, three, or four wire connections, twisted pair cable, fiber optic cable, etc.) and may have one or more physical links (e.g., a link connecting the field module 291 to the FJB 254D and a link connecting the FJB 254D to the marshalling cabinet 250). The links 282 may be configured using wiring and connections corresponding to any suitable standard, e.g., RS-485, RS-422, RS-232, CAT5, CAT6, etc. In some examples, the channel 282 includes one or more wireless links.

[0108] The communication interface I comprises a wireless interface for wirelessly communicating with other devices. In particular, the interface I supports any suitable standards and protocols for short-range communication (e.g. NFC, RFID, Bluetooth, etc.).

[0109] Profile 291F includes one or more system tags unique to field module 291 and a set of field device channels (e.g., field device 252k, and in this case, channels to connectors 273-276) connected to communication interface 291G. In particular, it may include a single system or device tag and a DST for each field device channel connected to field module 291. For example, each channel to connectors 273-276 may have a unique DST listed in profile 291F. It may also include a mapping of each DST to a particular connector of interface 291G corresponding to the DST (e.g., indicating terminal block 1 corresponding to a first DST, terminal block 2 corresponding to a second DST, etc.), and may identify a signal type for each DST. For example, as shown in FIG. 3, profile 291F indicates that the signal type for the DSTs corresponding to connectors 273-275 is "DO" and the signal type for the DST corresponding to connector 276 is "DI."

[0110] The profile 291F of the field module 291 may be updated or replaced through the communication interface 291I. In particular, the portable device may update the profile wirelessly through a direct, short-range, or wireless link between the portable device and the field module 291. Updating the profile 291F is useful when a field device channel is added to, disconnected from, or replaced from the field module 291, or when a new tag is assigned to the field module 291 (e.g., during a project redesign). In particular, rather than being required to go to a workstation in the back-end environment 125 to update the profile 291F, the wireless update feature allows a technician or engineer to quickly and easily update the field module 291 while near the field module 291 in the field environment 122 (e.g., after updating the field wiring for adding, replacing, or removing a channel to a field device), and to visually view the field module 291 to verify or double-check whether the updated profile accurately reflects the physical changes to the field module 291. Below, an example field device and an example technique for updating a field module profile are described in more detail with reference to FIG. 8A.

[0111] As already mentioned above, the field module 291 serves as a communications interface between (i) multiple discrete communication channels connected to the field device inputs and / or outputs, and (ii) a single discrete communication channel connecting the field module 291 to the CHARM, I / O cards, and / or controllers. Although Figure 3 shows multiple DO channels and a single DI channel connected to interface 291G, it will be understood that the field module 291 can be connected to multiple inputs and / or multiple outputs.

[0112] In operation, the field module 291 receives, through the interface 291H and the I / O channel 282, discrete signals (also referred to as "signals H1") carrying DO messages from the CHARM 293M, the I / O card 256, and the controller 258. The field module 291 analyzes and decodes the messages, identifies one or more commands contained in the messages, and analyzes a tag-to message map (e.g., indicating the bit position in the DO message that corresponds to a particular DST) that maps system tags (e.g., DSTs) to DO messages so that for each command, the DST for the target DO can be determined. The tag-to message map is typically stored in the profile 291F and uploaded to other devices involved in sending or receiving the DO message, such as the controller 258. However, in some examples, the tag-to message map may be included in the metadata for the DO message. In any case, for example, the field module 291 may determine from the profile 291F that a first set of bits in the DO message maps to the DST "CV-123" and assign the command or value indicated by the first set of bits (e.g., "1") to the DST "CV-123". The field module 291 then forwards the command to the appropriate field device channel based on a tag-to-DO map (e.g., a map stored in the profile 291F) that maps each DST to a particular channel or connector of the field module 291. For example, the field module 291 may analyze the profile 291F and determine that the tag-to-DO map indicates that the DST "CV-123" maps to the third terminal block of the field module 291. The field module 291 may then transmit the appropriate command or value (e.g., in this case, 1) over the third terminal block.

[0113] In further operations, the field module 291 forwards through the I / O channel 282 a DI message carrying one or more variable values ​​or other sets of information received through one or more field device channels. For example, if the interface G receives multiple DI signals conveying multiple sets of information, the field module 291 generates a DI message (including a payload carrying each of the multiple sets of information). If desired, the field module 291 may generate a metadata portion including a tag-to message that maps, for example, a delimiter and / or a system tag (e.g., DST) to the DI message so that each set of information can be mapped to a specific DST. In some examples, one or more DI signals received by the field module 291 are binary values ​​and therefore may be represented by a single bit in the DI message, and in some examples, the DI signals received by the field module 291 are not binary and therefore may be more than one bit in the DI message sent by the field module 291. 9B for each variable value or set of information, the field module 291 may encode the DI message with a first set of bits indicating the value and a second set of bits indicating the bit inversion of the value. In any case, the field module 291 transmits the encoded message through the interface 291H and the channel 282 so that the CHARM, the I / O card, and / or the controller can receive the messages and information transmitted by the field device.

[0114] The information transmitted by a field device through a DI signal may indicate many things. For example, an ON-OFF valve may include a first binary number DI set to have a value of 1 (e.g., a value of 5V for a 1-5V voltage signal) when the valve is open, and a second binary number DI set to have a value of 1 indicating that the valve is closed (generally, the matching of the two DIs may indicate that the valve is in the process of being positioned or that an error exists). Furthermore, such a valve may have an actuator, as well as a first binary number DO that drives the actuator to open the valve when a value of 1 is present, and a second binary number DO that drives the actuator to close the valve when a value of 1 is present.

[0115] (D. Controller 258 and DIO element 259F) 1A , and implements a control strategy defined by one or more control routines 259D stored in memory 259A. Controller 258 is communicatively connected to other devices in I / O network 7 through links 284, as well as various other devices in plant 5 through backbone 10 (shown in FIG. 1A ). Links 284 may include any suitable wired (e.g., Ethernet) or wireless channels. Links 284 couple controller 258 to I / O cards 256 and field devices 252 and field modules 291.

[0116] During operation, the processor 259B of the controller 258 executes a control routine 259D which the controller 258 uses to send control signals over link 284 to one of the field devices 252a to control process operations within the plant 5 through control of the field devices 252. The controller 258 may generate the control signals based on one or more signals received over link 184 (e.g., carrying information sent by the field device 252K, the field module 291, the CHARM 293M, and / or the I / O card 256) and logic defined by the control routine 259D.

[0117] Each control routine 259D may be developed by linking and configuring various control elements or function blocks (FBs) 259E. Generally, each FB 259E represents an input function, a control function, and / or an output function. Examples of such types of blocks and functions are described with reference to FIG. 1B.

[0118] The controller 258 includes DIO elements (sometimes referred to as "DIO control elements," "DIOO function blocks," or "DIO blocks") 259F that may be used with the FBs 259E to define one or more control routines 259D. The elements 259F are objects or routines that may be thought of as software representations of the field modules 291 and / or CHARMs 293M. That is, the DIO elements 259F may be included in a control routine and may be referenced to reference field device signals of the channels 273-276 managed by the field modules 291 and CHARMs 293M. Exemplary elements similar to DIO elements are described below with reference to FIG. 4B.

[0119] During commissioning of the field devices 252K, field modules 291, CHARMs 293M, and the signals and channels associated with each such device, the controller 258 may auto-sense one or more tags for such devices and signals and store (e.g., in memory 259A and / or in configuration database 72b shown in FIG. 1A) the tags and their bindings. Such bindings map each tag to a particular I / O channel or subchannel, or to a hardware address linked to an I / O channel or subchannel. Such bindings allow the plant devices to read and send information (e.g., measurements, indicators, commands) by reading and writing to tags unique to the signals that carry the variable values ​​and commands. Any desired device of the plant 5, such as the controller 258, the controller 11, the workstation 71, the historian 73, and one or more field devices 252, may utilize the tags for read and write functions.

[0120] The hardware address in the binding may identify a particular terminal block address and / or a particular address for the CHARM 293 to which the channel and device are connected. For example, the hardware address may take the form of "controller.card.CHARM". For example, the field module 291 may have an address of the form "Controller 258->I / Ocard 256->CHARM 293M". In such an example, each CHARM may have an associated terminal block address or I / O channel address. Generally, each I / O channel extending from the marshalling cabinet to a field device or field module corresponds to a terminal block (i.e., channel 1=terminal block 1, channel 2=terminal block 2, etc.). The hardware address may take the form of "controller.card.channel" and / or "controller.card.channel.subchannel", if desired. As used herein, a "subchannel" of an I / O channel refers to a channel between a field module and an attached field device I / O connector, and may also be referred to simply as a "channel" or an "I / O channel". The channels for I / O connectors 273 - 276 are each subchannels of I / O channel 282 .

[0121] In any case, the controller 258, together with the I / O card 256 and the CHARM 293M, auto-senses the tags stored in the profile 291F of the field module 291 so that the auto-sensed tags can be connected to the appropriate hardware addresses and the field device 252K, the field module 291, the CHARM 293M, and the channels / signals between such devices can be commissioned as soon as the communication links between the devices are established and functioning. Such auto-sensing frees the technician from having to manually identify hardware addresses and manually create bindings to the appropriate tags, processes that are prone to human error and that pose difficulties when changes to field wiring are required.

[0122] The field module 291 may be disconnected from the terminal block connected to the CHARM 293M and coupled to a new terminal block in the marshalling cabinet 250, or coupled to a new terminal block in a different marshalling cabinet using a different I / O card and a different controller. For example, when the CHARM 293M is inserted into a socket that couples the CHARM 293M to a new terminal block, the CHARM 293M auto-senses the tag for the field device 291 and the binding for the tag is updated. For example, the I / O card 256 or a new I / O card may communicate with the CHRAM 293M, identify the I / O channel for the new terminal block or CHARM 293M, and update the binding with the new hardware address. In another example, a second DIO CHARM may be inserted into the new socket and the tag for the field module 291 auto-sensed and the binding updated to reflect the new hardware address.

[0123] The ability of DIO CHARMs (e.g., CHARM293M) and CHARM I / O cards to auto-sensing field module tags and automatically updating bindings for the tags allows for easy and quick reconfiguration and rewiring of I / O networks. In contrast, manual commissioning is error prone and requires significant time and effort from the technician (not only must the technician spend time rewiring, but must also manually keep records that may not be updated). For example, during manual commissioning, a device may be wired to the wrong I / O card and / or to a terminal block connected to the wrong controller, preventing the appropriate controller from communicating with the device and executing control routines associated with the device. In another example, a technician may update the binding for a device with an incorrect hardware address, resulting in other devices being unable to reference the device through its unique tag. The DIO CHARMs and field modules described herein eliminate the occurrence of such a process by allowing for auto-sensing of field module tags and automatic updating of bindings. The auto-sensing technique is described in more detail below with reference to FIG. 6.

[0124] The controller 258 has an auto-configuration routine 259G that allows the controller 258 to automatically instantiate and configure DIO control elements or function blocks for all connected field modules. Such DIO elements are objects or routines that may be thought of as software representations of field modules or DIO CHARMs. That is, input and output channels between one or more field devices and a field module may be accessed (e.g., by a control routine) through corresponding DIO elements (e.g., DIO element 259F). In any case, the auto-configuration routine 259G automatically configures the DIO elements. For example, execution of the routine 259G may cause the controller 258 to download a profile 291F from the field module 291 and connect appropriate tags (e.g., system tags and / or signal tags) to the inputs and outputs of the DIO element 259F. Thus, auto-configured DIO element 259F may have three control element or function block inputs connected to the system tag for field module 291, three control element or function block inputs connected to the signal tags for DOs 273-275 (e.g., indicating fields that other blocks can write to thereby control the corresponding DO signals), and one control element or function block output connected to the signal tag for DI 276 (e.g., allowing other blocks to read to thereby access the value of the corresponding DI signal). An exemplary technique for auto-configuring DIO elements with routine 259G is described in the following section with reference to FIG. 7.

[0125] (E.DIO Control Element Template 450) 4A illustrates an unconfigured DIO control element 450 created from a template (not shown) used to create one or more instances of a DIO control element (e.g., DIO element 259F shown in FIG. 3). A user may instantiate and configure DIO control element 450 using any suitable configuration and design system (e.g., configuration application 72a running on any suitable computing device). DIO control element 450 may be configured and linked to other input, function, and / or output blocks to create a routine in a manner similar to that described with reference to routine 101 shown in FIG. 1B.

[0126] Generally, element 450 is a software representation of a field module (e.g., field module 291). Element 450 may be connected to a particular field module by entering the system tag of the field module in field 452. For example, DIO element 259F is connected to a tag unique to field module 291.

[0127] As shown, element 450 has eight discrete inputs or outputs 454 and a hybrid discrete input / output (DIO) 456. Each I / O 454 corresponds to a particular terminal or terminal block of field module 291. A user can connect the corresponding discrete input or output 454 to a signal associated with the signal tag by entering a signal tag in one of fields 461. For example, DIO element 259F has an input connected to a signal tag (e.g., FM-9872-CMD-OPEN) that is unique for the signal being sent from field module 291 to DO 273. Each field module may have a profile that indicates which terminals or terminal blocks of the field module are mapped to specific signal tags.

[0128] Finally, the hybrid DIO 456 corresponds to a particular channel (e.g., channel 282 shown in FIG. 3) between the connected field module and the CHARM, I / O card, and / or controller. The DIO 456 can be connected to the CHARM, I / O card, and controller associated with the field module by filling in the signal tag in field 463. For example, DIO element 259F includes a hybrid DIO 456 connected to a signal tag indicating channel 282. In some examples, since each field module has a single hybrid DIO 456, element 450 may auto-configure field 463 and / or auto-connect the appropriate channel when a system tag is connected to element 450. Furthermore, in some examples, the signal tag for the hybrid DIO 456 may be the same as the system tag for element 450. It will be appreciated that, depending on the circumstances, element 450 may have any suitable number of discrete inputs, any suitable number of discrete outputs, and any suitable number of discrete hybrids. Additionally, if desired, element 450 may not include any discrete inputs, discrete outputs, or discrete hybrid inputs / outputs.

[0129] FIG. 4B illustrates a control routine 401 that includes a discrete control (DC) function block 406, which may be linked to one or more of the other blocks shown in FIG. 4A (e.g., DIO element 450) to receive discrete input signals and provide discrete output signals.

[0130] In particular, the control routine 401 has (i) a set of input blocks 402-404 (including DI 402, DI 403, and DIO element 404) that provide discrete input signals to a set of discrete inputs 412-416 of the DC block 406, and (ii) a set of output blocks 432-436 (including DO 432, DO 434, and DIO element 436) that receive discrete output signals from the discrete outputs 422-426 of the DC block 406. Although FIG. 4B shows DC block 406 with three discrete inputs 412-416 and three discrete outputs 422-426, DC block 406 may have any desired number of discrete inputs (each linkable to any desired block capable of providing a discrete signal (e.g., a standard DI block or DIO element, such as DIO element 450 shown in FIG. 4A)) and any desired number of discrete outputs (each linkable to any desired block capable of receiving a discrete signal (e.g., a standard DO block or DIO element, such as DIO element 450)).

[0131] The input blocks 402-404 and the output blocks 432-436 may be connected to or associated with any suitable device or signal tags associated with a process control entity (e.g., a field device or field module) configured to transmit or receive the appropriate type of signal. For example, the input blocks 402-404 may each be connected to or associated with one or more of (i) a device tag for a process control entity capable of transmitting a discrete input signal, or (ii) a signal tag for a particular discrete input signal transmitted by the field device. For example, the block 402 or the block 403 may be connected to a device tag for the field device 152K shown in FIG. 2, or a signal tag for the DI 176 of the field device 152K. Additionally, the DIO element 404, which is similar to the DIO element 450 shown in FIG. 4A, may be connected to or associated with any suitable device or signal tag associated with a field module (e.g., a tag associated with the field module 291 or the DI 276 of the field module 291 shown in FIG. 3).

[0132] After connecting input blocks 402-404 to processing control entities and tags associated with particular signals, the associated processing control entities each send a signal carrying a discrete parameter value to an I / O card or controller. The controller associates the discrete parameter value with the sending processing control entity and the signal or device tag that is "connected" to the signal. Then, when control routine 401 is executed, the input blocks 402-404 to which the signal or device tag is "connected" provide the discrete parameter value to the associated block(s).

[0133] As a further example, output blocks 432-436 may each be connected to or associated with one or more of: (i) a device tag for a process control entity capable of receiving a discrete output signal; or (ii) a signal tag for a particular discrete output signal to be transmitted to a field device. For example, block 432 or block 434 may be connected to a device tag for field device 252E shown in FIG. 2, or may be connected to a signal tag for DO 265 of field device 252E. Additionally, DIO element 436, similar to DIO element 450 shown in FIG. 4A, may be connected to or associated with any suitable device tag or signal tag associated with a field module (e.g., a tag for field module 291 shown in FIG. 3, or a tag for DO 273 of field module 291).

[0134] After output blocks 432-436 connect to tags associated with process control entities, output blocks 432-436 receive discrete parameter values ​​from outputs 422-426 of DC block 406 during execution of routine 401. A signal conveying the discrete parameter value is then sent by the controller executing routine 401 to the corresponding process control entity (e.g., a field device or field module) connected to output block 432-436 (e.g., through an I / O card such as I / O cards 256A and 256B shown in FIG. 3, or I / O cards 26 and 28 shown in FIG. 1A).

[0135] Control routine 401 (including any logic or passing of information associated with blocks 402-406 and 432-436) may be executed by any suitable processor or controller (e.g., controller 11 shown in FIG. 1A or controller 258 shown in FIG. 3). Control routine 401 may be created in a manner similar to that described with reference to routine 101 shown in FIG. 1B (e.g., through application 72a shown in FIG. 1A) or may be similar to routine 101.

[0136] In terms of functionality, DC block 406 performs logical operations using parameter values ​​it receives through a set of discrete inputs 412-416 to generate or calculate parameter values ​​or commands that it transmits to other blocks (e.g., in the illustrated example, blocks 432-436) through a set of discrete outputs. The logical operations that DC block 406 performs may represent any desired logic or routines that a designer desires to have implemented by DC block 406.

[0137] (F.CHARM293M and Marshalling Block 140) Figure 5 shows a profile view of an exemplary electronic marshalling block or device 140 supporting the electronic marshalling component 293M shown in Figure 3, with particular reference to the CHARM 293M. In Figure 5, the electronic marshalling block or device 140 includes a CHARM carrier 142 supporting one or more CHARM I / O cards (DIOC) 256 (also shown in Figure 3), to which a processing controller 258 may be connected (e.g., through a wired or wireless connector 284 shown in Figure 3). In addition, the electronic marshalling block or device 140 includes one or more CHARM baseplates 148 communicatively connected to the CHARM carrier 142 (and thus the CHARM I / O cards 256) and supporting multiple individually configurable channels.

[0138] Each channel corresponds to a dedicated CHARM terminal block 410 into which the CHARM 293M (or any other CHARM) is securely housed and electronically connected, so that electronic marshaling is performed in the field module 291 (shown in FIG. 3), the field device I / O connected to the field module 291 (e.g., connectors 273-276 of field device 252k shown in FIG. 3), and the I / O card with the controller 258.

[0139] (IV. Smart Commissioning Technology) 6-8, described below are exemplary techniques and systems that may be used to facilitate smart commissioning and configuration of discrete elements in a process plant, such as plant 5. In particular, and with reference to FIGURE 3, the techniques and systems described below may be utilized for smart commissioning of discrete field devices, such as field device 252K, discrete I / O subchannels, such as I / O connectors 273-276 of field device 252K, field module devices, such as field module 291, and DIO CHARMs, such as DIO CHARM 293M.

[0140] The following description refers to (A) FIG. 6 illustrating a method for smart commissioning of a field module, (B) FIG. 7 illustrating a method for automatically configuring a control element or function block associated with a field module, and (C) FIG. 8A illustrating an exemplary portable device configured to update the profile of a field module.

[0141] (A. How to Smart Commission the Field Module) 6 is a flow chart of an example method 601 for smart commissioning of a field module. Generally, devices in an I / O network 7 of a plant 5 perform the method 601 for commissioning a field module, such as a field module 291, and discrete field devices and signals associated with the field module. The method 601 allows software configuration tasks to be separated from hardware configuration tasks during commissioning, thereby addressing issues of project implementation and late changes. Although the method 601 is described in the context of the field module 291, DIO CHARM 293M, and controller 258 shown in FIG. 3, it will be understood that similar field modules, DIO CHARMs, and controllers may perform the functions described herein.

[0142] Method 601 begins at step 605 where the CHARM 293M is activated. The CHARM 293M may be activated by communicatively connecting the CHARM 293M to both the field module 291 and the controller 258. Typically, such connection is accomplished by inserting the CHARM 293M into a socket in the base plate 148 of the instrument 140 as shown in FIG. 5. Inserting the CHARM couples (e.g., by electrical contacts) a first communication interface of the CHARM 293M to an I / O connector (e.g., a terminal block) of the instrument 140 (to which the channel 282 and field module 291 are linked).

[0143] The insertion also connects (e.g., by electrical contact) the second communication interface of the CHARM 293M to a communication link to the I / O card 256. Such a link may be a power bus that provides power to the CHARM 293M, as well as a communication channel that allows the CHARM 293M to communicate with the I / O card 256 and the controller 258. In some examples, the first or second communication interface of the CHARM 293M may be wirelessly connected to a communication link linking the field module 291, the I / O card 256, or the controller 258. In such examples, inserting the CHARM 293M into a socket in the base plate 148 of the device 140 triggers the CHARM 293M or the device 140 to establish one or more wireless connections.

[0144] In any event, in step 610, the CHARM 293M autosenses a tag for the field module 291. Referring to the set of system tags used in the system 5, a tag is typically a logical identifier that uniquely identifies a field module 291. For example, the tag stored in the profile 291F and autosensed by the CHARM 293M would be described as the character set "FM-291", although the tag may be any other suitable character combination (and thus a unique tag). The autosense may also be referred to as a "device tag" or more generally a "system tag" (a term that encompasses device tags and signal tags).

[0145] In any event, auto-sensing typically occurs after both the CHARM 293M and the field module 291 have been installed and powered up. To facilitate auto-sensing, either or both of the CHARM 293M and the field module 291 may be configured to periodically transmit a beacon over the channel 282. When the CHARM 293M receives a beacon from the field module 291 (e.g., shortly after the field module 291 has been installed, coupled to the CHARM 293M, and powered up), the CHARM 293M responds by requesting a tag (e.g., a system tag or a device tag unique to the field module 291) or profile for the field module 291. The field module 291 responds to the request by sending to the CHARM 293M (i) the tags stored in the profile 291F, (ii) a portion of the profile 291F, or (iii) the entire profile 291F. Similarly, the field module 291 may transmit any of this information in response to receiving a beacon from the CHARM 293M (shortly after the CHARM 293M is inserted and powered up).

[0146] In step 615, after the CHARM 293M receives the tag "FM-291" and / or profile 291F, the tag is connected (bound) to a hardware address specific to the CHARM 293M and / or channel 282, thereby allowing the controller 258 and other devices to communicate with devices in the I / O sub-network 299 (e.g., field module 291) by referencing the tag "FM-291". The binding may be stored in the configuration database 72b shown in FIG. 1A. Bindings and hardware addresses are described in further detail with reference to FIG. 3.

[0147] In some examples, the CHARM 293M auto-senses additional tags. In particular, the CHARM 293M may auto-sense signal tags or DSTs indicative of signals of I / O sub-channels connected to the field module 291 (e.g., the three DO and DI signals of the sub-channels between the I / O connectors 273-276 and the field module 291) in addition to sensing a device tag (DT) specific to the field module 291 (e.g., "FM-291"). In general, each auto-sensed DST corresponds to (i) a particular parameter (indicated by a DI signal) measured, detected, or reported by the field device, or (ii) a particular command that can be provided to the field device by driving a DO signal to a logic "1".

[0148] 1A, the DST may include the DT of the field module 291. For example, the CHARM 293M may autosense DST "FM-291-CV-101" that corresponds to DI 276 and indicates a status indicator for the control valve (e.g., indicating whether the valve is open or closed) and / or DST "FM-291-CO-374" that corresponds to DO 273 and indicates a signal that can be driven to a logic "1" to drive the control valve to an open state.

[0149] B. A method for automatically configuring a control element or function block associated with a field module 7 is a flow chart of an example method 701 for automatically configuring control elements associated with one or more discrete inputs or outputs for field modules and field devices. Typically, devices in an I / O network 7 of a plant 5 perform the method 701 to generate a software representation of a particular field module (having discrete inputs and outputs corresponding to the discrete inputs and outputs of the field module). Using the method 701, an engineer or designer is relieved from having to manually configure control elements for every field module present in a process plant, which may number in the hundreds or even thousands. The method 701 is described with reference to the field module 291, DIO CHARM 293M, and controller 258 shown in FIG. 3, although it will be understood that similar field modules, DIO CHARMs, and controllers may perform the functions described herein.

[0150] Method 701 begins at step 705, when controller 258 first detects DIO network 299 or when controller 258 detects a change to DIO network 299. Controller 258 may detect DIO network 299 when CHARM 293M is inserted into instrument 140 and / or when a field module is connected to CHARM 293M.

[0151] In step 710, controller 258 requests a profile associated with DIO network 299. In particular, controller 258 causes I / O card 256 and CHARM 293M to retrieve profile 291F and transmit profile 291F to controller 258.

[0152] As indicated by the dashed outlines of blocks 705 and 710, in some examples, the controller 258 does not perform steps 705 and 710. Instead, the CHARM 293M and / or the I / O card 256 may detect changes to the sub-network 299 and send the profile 291F to the controller 258 without receiving a request from the controller 258. The CHARM 293M may detect changes to the sub-network 299 by periodically checking whether the profile 291F of the field module 291 matches a recently uploaded profile and / or by receiving a notification issued by the field module 291 after the profile 291F is updated. The CHARM 293M may auto-sense tag changes in the profile 291F according to the method 601 described with reference to FIG. 6.

[0153] In any case, in step 711 , the controller 258 receives the profile 291 F for the field module 291 from the I / O card 256 and the CHARM 293 .

[0154] In step 715, controller 258 analyzes profile 291F and identifies a tag indicating field module 291 (e.g., “FM-291”) and the signals of the I / O subchannel between (i) field module 291 and (ii) field device I / O connectors 273-276 connected to field module 291.

[0155] In step 720, controller 258 instantiates DIO control element 259F and connects element 259F to device tag "FM-291." Additionally, controller 258 connects the signal tag for DI 276 (identified from profile 291) to the output of the DI control element and connects the signal tags for DOs 273-275 to the three inputs of the DIO control element. If desired, controller 258 may connect the signal tag for channel 282 to a hybrid input / output of element 259F. After connecting the tags to element 259F, element 259F may be inserted into a control routine and linked to other blocks (e.g., input blocks, output blocks, or control blocks) to write to any of DOs 273-275 and / or read DI 276.

[0156] Field module 291 may generate information other than that conveyed by discrete signals 273-276. For example, field module 291 may generate a health index value indicative of the health of field module 291, one or more communication status indicators indicative of the status of any I / O subchannels or channels 282, one or more error parameters indicative of a malfunction in field module 291, etc. If desired, each such other parameter or indicator may be coupled to an output of element 259F.

[0157] After configuring the DIO element, controller 258 may periodically send a request to field module 291 to determine whether profile 291F has changed since element 259F was last configured. If controller 258 receives notification that profile 291F has changed (step 705), controller 258 may perform steps 710-720 again.

[0158] C. An Exemplary Mobile Device Configured to Update a Field Module's Profile 8A is a block diagram of an example mobile device 801 that may be used to update a profile of a field module, such as field module 291. Although device 801 is described with reference to field module 291 shown in FIG. 3, device 801 may similarly interact with any suitable field module in accordance with the operations described herein.

[0159] The device 801 allows a person in the field environment 122 to quickly and easily update the field module 291 (e.g., after updating the field wiring for adding, replacing, or removing a channel to a field device) while in the vicinity of the field module without returning to a workstation in the back-end environment 125 of the plant. Thus, the device 801 allows a person to visually view the field module 291 and verify or double-check whether the updated profile accurately reflects the physical changes to the field module 291. The portable device 801 may be specially configured for operation in a process control environment. For example, the portable device 801 is intrinsically safe. That is, the portable device 801 may be configured to operate safely in hazardous areas by including only components that do not have / emit enough energy to ignite (e.g., all components are configured to maintain a voltage of less than 24 VDC and a current of less than 100 mA). As another example, the portable device 801 may be configured to provide an operator / maintenance display that allows a user of the device 801 to monitor equipment and variables of the plant 5 or to operate variables or equipment of the plant 5 and control the plant 5.

[0160] The portable device 801 is a portable electronic device such as a laptop, tablet, mobile phone, PDA, or industrial communicator configured to update the profile 291F of the field module 291. The device 801 has a processor 802 (which may be any suitable microprocessor or general purpose processor) communicatively connected to a memory 804, a communication interface 806, and a user interface (UI) 808. The device 801 may have a housing and a power source (not shown), such as a battery.

[0161] The memory 804 may be any suitable memory and / or storage component including non-fixed computer readable media (CRM), and may include volatile and / or non-volatile media, and removable and / or non-removable media. The memory 804 stores one or more routines 812 that are executed by the processor 802 to enable the device 801 to perform functions attributed to the device 801. The memory 804 also stores profiles 814 for the field modules 291.

[0162] The communication interface 806 may be any suitable interface that enables the device 801 to transmit information or data to and / or receive information or data from other systems. In particular, the interface 806 includes circuitry for establishing a direct wireless connection with the field module 291 (e.g., through NFC). For example, the interface 806 may include an NFC tag, an NFC reader / writer, a non-NFC RFID tag, and / or an RFID interface 806. If desired, the interface 806 has circuitry for wirelessly connecting to one of the access points 55a or 55b and / or circuitry for establishing a wireless connection to the field module 291 (through USB, Ethernet, etc.).

[0163] The UI 808 may have any suitable user input or output components. As shown, the UI 808 has a display, which may be an LCD display, a smartwatch display, a headset display (e.g., VR goggles), any other suitable display, or some combination thereof. The UI 808 also has a touchscreen 818, which may be a resistive or capacitive touchscreen integrated into the display 816 or one or more "soft key" surfaces. If desired, the UI 808 may have buttons and other mechanical actuators available for input, as well as any suitable audio or visual output components.

[0164] During operation, a user of the device 801 configures the profile 814 (e.g., through the UI 808) to have the information they wish to include in the profile 291F of the field module 291. Such configuration may include providing device tags for the module 291 and / or signal tags for one or more I / O subchannels from the field module 291 to the field device connectors. In some examples, the device 801 may simply download the profile 814 in a pre-configured state from a server in the backend 125 (e.g., a server coupled to a database 72b that stores the pre-configured profile 814).

[0165] In any case, after profile 814 is configured and ready to be downloaded to field module 291, device 801 detects field module 291 or field module 291 detects device 801, a communication channel is established, and all or part of profile 814 is downloaded to field module 291 to replace profile 291F.

[0166] As a first exemplary configuration, the device 801 has an RFID or NFC reader / writer that detects a passive RFID or NFC tag (also simply referred to as an RF tag) of the field module 291. For example, the device 801 may generate a magnetic field that powers the NFC or RFID tag of the field module 291 when a technician places the device 801 near (e.g., within 4 inches) the tag of the field module 291. The NFC or RFID tag may then transmit a signal carrying information that allows the device 801 to bootstrap a link to the field module 291 through a second set of protocols or standards (e.g., Bluetooth or WiFi Direct). In some examples, the field module 291 may instead extend the range of its connectivity capabilities to 15 feet by using active or powered RFID tags.

[0167] In some examples, the RFID or NFC tag of the field module 291 stores and transmits the system tag of the field module 291. In such examples, the device 801 may update the system tag of the field module 291 by using a reader / writer to write a new system tag to the NFC or RFID tag. Such an operation is useful if the profile 291F is not already configured to have a system tag or if a project change requires that the field module 291 be assigned a different tag. Additionally, the field module 291 may have an NFC or RFID tag for each potential I / O subchannel to a field device. The device 801 can write to each of them, allowing updating of the signal tag stored in the profile 291F for each I / O subchannel.

[0168] In a second example configuration, the field module 291 may have an RFID or NFC reader / writer and the device 801 may have an NFC tag and a passive or active RFID tag. In such an example, the reader / writer of the field module 291 detects a signal transmitted by the RFID or NFC tag of the device 801 (e.g., after being powered by a magnetic field provided by the reader / writer of the field module 291). The field module 291 may rely on such information to bootstrap the second link in a similar manner as described in the first example.

[0169] In some examples, device 801 may store desired system or signal tags in an RFID or NFC tag so that they are transmitted when the RFID or NFC tag is powered. Field module 291 receives the system tags and updates profile 291F accordingly.

[0170] In a third exemplary configuration, the field module 291 and the device 801 may each have an NFC reader / writer capable of mutual discovery and also capable of establishing an NFC peer-to-peer (p2p) connection. The device 801 may send all or part of the profile 814 to the field module 291 through such an NFC p2p connection to replace the profile 291F.

[0171] If desired, the device 801 may establish an indirect connection to the field module 291 (e.g., through an access point 55a, 55b, or 74, the backbone 10, and the I / O network 7) and download all or a portion of the profile 814 to the field module 291 through such indirect connection. In some examples, the configuration application 72a or a server may act as an intermediate element between the mobile device 801 and the field module 291.

[0172] FIG. 8B is a flow chart of an example method 851 of updating a profile (eg, profile 291F) in a field module (eg, field module 291 shown in FIG. 3) using the mobile device 801 shown in FIG. 8A.

[0173] The method 851 begins at step 852, where the portable device 801 detects the field module 291. The portable device 801 detects the field module 291 automatically and wirelessly without input from a user. Any suitable short-range, medium-range, or long-range wireless standard or protocol may be used for detection. For example, as described above, NFC, RFID, or Bluetooth protocols may be used by the device 801 and the field module 291 to facilitate detection. Detection may be accomplished using one or more of the following radio frequency bands: 13.56 MHz, 900 MHz, 2.4 GHz, 5 GHz, or 60 GHz. In some implementations, user input may facilitate detection. For example, the user may select a tag, identifier, or image displayed by the device 801 and uniquely associated with the field module 291. Such user action causes the device 801 to attempt to wirelessly detect the field module 291.

[0174] In step 854, the device 801 establishes a wireless channel between the device 801 and the field module 291. Any suitable short-range, medium-range, or long-range wireless standard or protocol may be used for the communication channel. Furthermore, the wireless channel may correspond to one or more of the following radio frequency bands: 13.56 MHz, 900 MHz, 2.4 GHz, 3. GHz, 5 GHz, or 60 GHz. In some implementations, the wireless channel corresponds to a different protocol(s) than the protocol(s) used to detect the field module 291. For example, the field module 291 may be detected through RFID communication that is utilized to bootstrap a WiFi, Bluetooth, or some other wireless communication channel. In some implementations, the wireless channel corresponds to the same protocol(s) used for detection (e.g., NFC may be used for detection and subsequent communication). In some examples, a user input at the device 801 may facilitate the establishment of the communication channel. For example, the device 801 may first detect the field module 291 and then the user may select the field module 291 through the UI 808 to indicate an intent to establish communication with the field module 291. For example, the device 801 may detect multiple field modules and the user may select a particular field module with which to establish communication.

[0175] In step 856, the device 801 updates the profile of the field module 291 over the established wireless channel. For example, the device 801 may send a request for the profile to the field module 291. The module 291 may then respond to the request by sending the profile to the device 801.

[0176] After receiving the profile, the device 801 may update the information stored in the profile. For example, it may change the device tag for the module 291 or may change one or more signal tags for signals transmitted by or received by the module 291. After updating the profile, the device 801 may send the profile back to the module 291 (e.g., along with a command to overwrite the old profile or to activate the new or updated profile). User input at the UI 808 may enable or facilitate the device 801 to upload the profile to the module 291 (by using a button or other UI element to initiate the upload). The ability of the module 291 to update the profile allows plant personnel to quickly and easily reconfigure the module 291 (e.g., if the module 291 needs to be connected to additional or different field devices or field device signals).

[0177] V. Improved Discrete I / O Communication Protocol for Processing Plants Figures 9A and 9B show exemplary data or communication signals 910 and 920 conveyed by channel 282 shown in Figure 3 and encoded, decoded, transmitted, or received by a system described herein (including CHARM 293M and field module 291 shown in Figure 3) according to protocol 912 and protocol 922, respectively. Figures 10A and 10B show exemplary methods 1001 for encoding a message according to protocol 922, and method 1051 for decoding a message according to protocol 922, respectively.

[0178] (A. Protocols 912 and 922) 9B, signal 920 corresponds to a novel bit-wise discrete I / O communications protocol 922 (more generally referred to herein as the "DIO protocol") that offers a number of advantages over protocol 912 that signal 910 corresponds to. In particular, protocol 922 provides improved error detection and a more stable DC level of channel 282 over protocol 912.

[0179] As shown, signals 910 and 920 each carry a payload portion of a message transmitted by CHARM 293M over channel 282 to field module 291. The payloads carried by signals 910 and 920 carry the same information content (e.g., the same variable values), but the payload carried by signal 910 is encoded and decoded by protocol 912 and the payload carried by signal 920 is encoded and decoded by protocol 922. Signals 910 and 920 may be encoded by DIO CHARM 293M, I / O card 256, or some combination thereof.

[0180] FIG. 9A illustrates a portion of signal 910 corresponding to the payload portion of a message carried by signal 910, and eight examples of signal 910 occurring at times t1-t8. The payload conveys information indicating eight bits corresponding to eight discrete output values ​​for DO_1-DO_8: “0101 1111”. Eight DO values ​​914 are first generated by controller 258 and sent to I / O card 256 which transfers the values ​​(e.g., over the backplane) to CHARM 293M. CHARM 293M then encodes the DO values ​​into a message and sends the message over channel 282. As illustrated, protocol 912 is a non-return-to-zero protocol that relies on amplitude modulation where a bit value of “1” is represented by a voltage of +5V and a bit value of “0” is represented by a voltage of +1V. In some examples, protocol 910 may rely on different amplitudes to represent values ​​(e.g., 0V and 5V, −5V and 5V, etc.). FIG. 9A shows a communication signal 910 superimposed on 24V DC power (obtained from the backplane of the device 140 shown in FIG. 5 to which the CHARM293M is connected), and in some cases, channel 282 carries the signal 910 but does not provide power.

[0181] 9B, protocol 922 offers a number of advantages over protocol 912. Protocol 922 requires a set of data to be encoded by transmitting (i) a first subset of bits indicative of a first discrete input or output variable value, and (ii) a second subset of bits indicative of the bit-inverse of the first variable value. Similarly, each variable value transmitted according to protocol 922 is represented by a first subset of one or more bits indicative of the value and a second subset of one or more bits indicative of the bit-inverse of the value.

[0182] For example, in operation, CHARM 293M encodes a message with the value of DO_1 by setting a first bit to "0" (as shown at t1) and setting a second bit to the inverse of the value of DO_1, i.e., "1" (as shown at t2). The first set of bits indicates the value of DO_1. CHARM 293M performs a similar operation for each of the other values ​​924. Field module 293M receives signal 920 and decodes the message by identifying each set of bits for each of the values ​​924 (e.g., the first two bits correspond to DO_1, the second two bits correspond to DO_2, etc.) and determining that a second bit or subset of the bits indicates the inverse of the first bit or the first subset of bits.

[0183] Advantageously, protocol 922 provides high reliability to signal 920 such that single bit errors and multiple bit errors can be detected at the coding level. For example, field module 291 or CHARM 293M detects an error when the bits of the second subset carried by signal 920 do not show a bit inversion of the bits of the first subset. Furthermore, protocol 922 requires fewer changes in the DC level of channel 282. Referring to FIG. 9A, protocol 912 can keep the DC level artificially high or low for a period of time. In contrast, in the inversion process required by protocol 922, a more stable DC level is maintained for a period of time. Furthermore, if the protocol uses positive and negative voltages (e.g., +5V and −5V) for amplitude modulation, the DC level will be maintained, on average, close to the designed power level (e.g., 24V).

[0184] The payload carried by each of signals 910 and 920 may be preceded and / or followed by (i) payload information, such as payload length, variable identifier (e.g., DST for each of DO_1 through DO_8), variable mapping (e.g., indicating the bit position within the payload for each variable), variable length (e.g., in some examples, a particular variable may not be binary and thus represent more than one bit), and (ii) routing information, such as one or more tags, hardware addresses, or network addresses indicating the destination of the message (e.g., field module 291), the destination of the variable value carried in the payload (e.g., connector I / O 273 of field device 252k), the source of the message (e.g., CHARM 293M), and the like. and / or controller 258), and / or any intermediate nodes used to send the message to a destination (e.g., I / O card 256 and / or CHARM 293M); (iii) error detection and correction information, e.g., checksum, parity bits, and / or cyclic redundancy check (CRC); (iv) protocol information identifying the protocol type used to create the message; and / or (v) megabytes of data (e.g., headers and / or trailers) carrying preambles, start codes, and / or end codes that enable sending and receiving devices to identify the start of a new message, map bit positions to appropriate variables, and / or identify the end of a message.

[0185] 9A and 9B show signals 910 and 920 carrying only binary variable values, in some examples, protocols 910 and 920 can also encode and decode non-binary values. For example, hexadecimal notation may be used, where, for example, a first set of 16 bits indicates a first value and a second set of 16 bits indicates a second value. In another example, binary-coded decimal (BCD) may be used, where each variable value may be characterized by one or more bytes or half-bytes, each of which may indicate a decimal digit. If BCD is used, the message metadata or field module profile may map and store each byte or half-byte to a particular variable and a particular digit of that variable. For example, a two-digit BCD value for a tank level may be represented by a first set of 8 bits for the first level value and a second set of 8 bits for the second level value.

[0186] In some embodiments, system 5, particularly CHARM 293M and field module 291, may rely on different encoding and decoding protocols for signals transmitted and received over channel 282, for example, Manchester encoding. However, Manchester encoding has drawbacks. For example, Manchester encoding halves the data rate relative to the bandwidth of the data signal. Manchester encoded signals require transitions for every bit (i.e., two Manchester logic states are used to convey one standard logic state). Furthermore, Manchester encoding is self-clocking, and therefore clock recovery from the signal is required when the signal is decoded. Protocol 922 does not require a clock to be embedded within signal 920, so clock recovery from the signal is not required during decoding.

[0187] In some examples, plant 5 may implement additional or alternative techniques. For example, in some examples, plant 5 may implement a protocol that uses the same general coding technique as protocol 912 or 922 but relies on return-to-zero (RTZ) coding (where the signal drops to zero between pulses) and / or a protocol that relies on transitions between voltage levels rather than constant voltage levels to indicate values. Additionally, if desired, plant 5 may implement a protocol that uses the same general coding technique as protocol 912 or 922 but modulates the frequency or phase of a signal rather than the amplitude of the signal to indicate a value.

[0188] (B. Encoding a message using protocol 522) Figure 10A is a flow chart of an example method 1001 of encoding a message according to protocol 922, which may be implemented by the CHARM 293M and / or field module 291 shown in Figure 3. Method 1001 provides improved error detection and stable DC levels over a channel that provides power and discrete communications.

[0189] At a high level, the method 1001 includes four steps: a DI signal receiving step 1005 / 1007 , a message encoding step 1009 , a message mapping step 1011 , and a message sending step 1013 .

[0190] In steps 1005 and 1007, discrete signals DI_1 and DI_2 carrying variable values ​​V1 and V2, respectively, are received. For example, referring to Figure 3, field module 291 may receive DI_1 over a sub-channel to field device connector 276 and DI_2 over a sub-channel (not shown) to a second field device connector.

[0191] After receiving the discrete signal, the field module 291 decodes the signal (e.g., based on the voltage of the subchannel) and encodes a message in step 1009. The encoded message may also be referred to as a "DI message" because it generally carries a variable value corresponding to a DI signal of the process plant (e.g., from the I / O connector 276 of the field device 252K shown in FIG. 3). However, the message may be encoded with information that does not correspond to a DI signal from the field device (e.g., an index value generated by the field module 291 or a value corresponding to a DO signal) through the protocol 922. In any case, step 1009 includes sub-step 1015, in which a payload for the DI message is generated, and sub-step 1017, in which metadata for the DI message is generated.

[0192] In sub-step 1015, a set of bits is generated for each of values ​​V1 (sub-step 1021) and V2 (sub-step 1031). In particular, for V1, a first subset of bits indicative of V1 is generated (sub-step 1023), and a second subset of bits indicative of the bit inversion of VI is generated (sub-step 1025). For V2, a first subset of bits indicative of V2 is generated (sub-step 1033), and a second subset of bits indicative of the bit inversion of V2 is generated (sub-step 1035). The field module 291 may verify that all of the second subsets indicate bit inversion of the value indicated by the first subset of bits. If not, the field module 291 may send an error signal to the CHARM 293M to inform the CHARM 293M that an encoding error has occurred. In any case, if no error is detected, each set of bits is encoded into a bit position in the payload of the message.

[0193] With respect to sub-step 1017, example metadata was described above with reference to Figures 9A and 9B. The metadata may indicate the beginning and / or end of the DI message (e.g., through a particular start or end code unique to the protocol 922). In some instances, very little or no metadata is generated for the DI message.

[0194] In step 1011, a tag-to-message map may be generated. The control system 5 may have a unique tag for each of DI_1 and DI_2, each indicating a variable (e.g., a control valve state). The tag-to-message map identifies a bit position within the DI message for each tag that corresponds to a DI. Step 1011 may occur before any other step of the method 1001 and may be stored in the profile 291F shown in FIG. 3 (which may then be uploaded to the CHARM 293M, the I / O card 256, the controller 258, and / or other devices in the plant 5). In some examples, the map is included in the metadata generated in step 1017.

[0195] In step 1013, field module 291 transmits a discrete signal H1 conveying a DI message (which may be received and decoded by CHARM 293M) through I / O channel 282. The "H1" label for the transmitted discrete signal has no significance other than to indicate that signal H1 is different from discrete signals DI_1 and DI_2. Field module 291 transmits signal H1 through interface 291H and channel 282 to CHARM 293M, and receives signals DI_1 and DI_2 through two channels wired separately to interface 291G.

[0196] 10A depicts substeps for the field module 291 to encode a DI message to convey a variable value, the substeps of step 1009 may similarly be used by any suitable device (e.g., the CHARM 293M) to encode a message to convey any desired information. Generally, the CHARM 293M does not encode variable values ​​received through a field device subchannel, but rather encodes commands received through the I / O card 256 and controller 258 into messages. The CHARM 293M sends a "DO message" over channel 282 that is received and decoded by the field module 291, which then transmits the command to the appropriate field device over the I / O subchannel.

[0197] (C. Decrypting a message using Protocol 922) Figure 1B is a flow chart of an example method 1051 of decoding a message according to protocol 922 that may be implemented by the CHARM 293M and / or field module 291 shown in Figure 3. The method 1051 provides improved error detection and stable DC levels over a channel that provides power and discrete communications.

[0198] At a high level, the method 1051 includes four steps: a message receiving step 1055 , a message decoding step 1057 , a discrete output (DO) signal encoding step 1059 , and a command sending step 1061 .

[0199] In step 1055, the field module 291 receives the message carried by the discrete signal H1. As noted above, the "H1" label has no significance other than to distinguish the received signal from other discrete signals (e.g., the DO signal referenced in steps 1059 and 1061).

[0200] In step 1057, the field module 291 decodes the received message according to protocol 922. The received message may also be referred to as a "DO message" because the received message generally carries a command or control output value received by the field device through a DO signal (e.g., through one of the I / O connectors 273-275 of the field device 252K shown in FIG. 3). However, the decoding step 1057 may be used to decode a message conveying any suitable information (e.g., a value corresponding to a DI signal, a command for the field module 291, etc.) so long as the message is encoded through protocol 922. In any case, step 1057 includes substeps 1061 and 1071 that identify bits indicative of a particular command or other information.

[0201] In particular, in sub-step 1065, field module 291 identifies a first subset of bits in the first set that indicate command C1. In subset 1067, field module 291 identifies a second subset of bits in the first set that indicate a bit inversion of command C1. If the second subset does not indicate a bit inversion of the first subset, command C1 is "discarded" and a default command (e.g., a pre-existing command or a pre-defined "safe" command) is used instead. In sub-steps 1075 and 1077, field module 291 performs similar operations to identify, in the second set of bits, a first subset of bits that indicate command C2 and a second subset of bits that indicate a bit inversion of command C2.

[0202] In substeps 1063 and 1073, the field module 291 identifies target field device subchannels or I / O connectors X1 and X2 for commands C1 and C2, respectively. The field module 291 identifies such target subchannels based on analysis of a tag-to-message map (e.g., indicating which tags correspond to which bit positions in a message) and / or a tag-to-hardware map (e.g., indicating which tags correspond to which hardware addresses). Such maps may be stored in the profile 291F or may be included in the metadata portion of the DO message.

[0203] After the DO message is decoded, the field module 291 transmits commands C1 (substep 1091) and C2 (substep 1093) to the appropriate field device I / O channels X1 and X2, respectively, by decoding signals DO_1 (carried by channel X1) and DO_2 (carried by channel X2), respectively. Generally, the process of encoding commands C1 and C2 only involves driving the voltage of the appropriate signals to one of two levels (e.g., 5V or 1V).

[0204] 10B depicts substeps for the field module 291 to decode a DO message carrying a command value, the substeps of 1057 may similarly be used by any suitable device (e.g., the CHARM 293M) to decode a message encoded according to the protocol 922. For example, the CHARM 293M may perform step 1057 to decode a DI message received from the field module 291 and identify a set of DI values. The CHARM 293M may then forward such DI values ​​(and associated tags, if desired) to the I / O card 256 and / or the controller 258 so that the controller 258 can implement a control routine that applies the DI values ​​(e.g., indicative of a measured process variable, e.g., flow rate, tank level, valve position, pressure level, temperature, etc.).

[0205] (VI. Other Considerations) Various aspects, apparatus, systems, components, devices, methods, and techniques for managing discrete processing control elements (e.g., discrete devices, discrete communication channels, discrete signals, etc.) and performing smart commissioning of the discrete elements within a control system 5 are described below.

[0206] As noted above, the smart commissioning techniques described herein significantly reduce the time, manpower, and costs involved in commissioning a treatment plant 5. Because a treatment plant may contain hundreds, thousands, or even tens of thousands of discrete elements, each of which must be commissioned before operation of the treatment plant begins, the manpower and time savings (and therefore financial savings) derived from smart commissioning are enormous. Furthermore, because at least a portion of the smart commissioning techniques are performed automatically, there is less opportunity for user error and, therefore, is more accurate than conventional commissioning techniques.

[0207] Although the smart commissioning techniques described herein are described with respect to a process control system 5, any one or more of the smart commissioning techniques described herein are equally applicable to a process control safety information system of a process control plant, such as the DeltaV SIS® offered by Emerson Process Management. For example, a stand-alone process control system or an integrated control and safety system (ICSS) may be commissioned using any one or more of the smart commissioning techniques described herein.

[0208] Additionally, when implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-fixed computer readable memory, such as in a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium, RAM or ROM of a computer or processor. Although the exemplary systems described herein are specifically described as including software and / or firmware executed in hardware, such systems should be considered exemplary only and not limiting. For example, any or all of such hardware, software, and firmware may be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, even if the exemplary systems described herein are described herein as being implemented in software executed in the processors of one or more computing devices, one of ordinary skill in the art will readily appreciate that the examples provided are not the only ways to implement such systems.

[0209] With reference to methods 601, 701, 851, 1001, and 1051, the functions described may be implemented, in part or in whole, by the devices, circuits, and / or routines of system 5 shown in Figure 1A. Each of the described methods may be embodied by a set of circuitry (e.g., an ASIC or FPGA) permanently or semi-permanently configured to perform the logical functions of the respective method, or a set of circuitry (one or more processors and instructions or routines representing the logical functions stored in memory) at least temporarily configured to perform the logical functions of the respective method.

[0210] Although the present invention has been described with reference to specific examples, they are illustrative only and are in no way intended to limit the present invention, and it will be apparent to one skilled in the art that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention. Furthermore, although the foregoing text details many different embodiments, it should be understood that the scope of this patent is defined by the language of the claims set forth at the end of this patent, and their equivalents. The detailed description is for illustrative purposes only, and does not describe every possible embodiment (it would be impractical, if not impossible, to describe every possible embodiment). Numerous alternative embodiments may be made using current technology, or technology developed after the filing date of this patent, within the scope of the claims and their equivalents.

[0211] Throughout this specification, a component, operation, or structure that is described as a single instance may be performed by multiple instances. Although individual operations of one or more methods are illustrated and described as separate operations, in a particular embodiment, one or more of the individual operations may be performed simultaneously.

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

[0213] As used herein, the terms "having", "having", "including", "including", "having", "having" or any other variations thereof are intended to be non-exclusive inclusive. For example, a process, method, article, or device that includes various elements is not necessarily limited to only those elements, but includes other elements not expressly listed or that are inherent in such process, method, article, or device. Furthermore, unless expressly stated otherwise, the term "or" is intended to be an inclusive "or" and not an exclusive "or". For example, the condition A or B is satisfied by any one of the following: A is true (or exists) and B is false (or does not exist), A is false (does not exist) and B is true (or exists), and both A and B are true (or exist).

[0214] Additionally, "a" or "an" are used to describe elements and components of the embodiments described herein. In general, when a system or technique is described as including "a" part or "a" step, the system or technique should be interpreted as including one or at least one part or step. In other words, for example, a system described as one blue instrument may include multiple blue instruments in some embodiments (unless it is clear that the system includes only one blue instrument).

[0215] Throughout this specification, some of the following terms and phrases are used.

[0216] Commissioning Commissioning is divided into at least two categories: traditional commissioning and smart commissioning. Traditional commissioning techniques require that names and identifiers of the various components located in the field environment 122 shown in FIG. 1 and their associations and interrelationships with other components be defined in the back-end environment 125 before commissioning can begin in any significant way in the field environment 122. That is, traditional commissioning techniques require that the various field components are first configured and defined in the back-end environment 125, and that such commissioning data must be downloaded or communicated to the field environment 122 through existing communication paths in the process control system 5 before it is available in the field environment 122 for commissioning of the components of the field environment 122. For example, with traditional commissioning techniques, the commissioning data (including settings and definitions) is typically transmitted over the data highway 10 from the back-end environment 125 to the controllers 120 and I / O devices 108, and in some cases, to the field devices 102 of the field environment 122, such that the commissioning data is available in the field environment 122 for performing one or more commissioning actions in the field environment 122.

[0217] In contrast, smart commissioning does not require that configuration and definition be fully completed in the back-end environment 125 before commencing commissioning activities in the field environment 122. Instead, the smart commissioning techniques described herein allow physical design, installation, engineering, and commissioning to be initiated and performed in the field environment 122 of the treatment plant 5 independent of the functional / logical design and engineering evolution performed in the back-end environment 125 of the treatment plant. For example, various commissioning activities may be performed in the field environment 122 of the treatment plant 5 before the field environment 122 is communicatively connected to the back-end environment 125 of the treatment plant 5, e.g., while the field environment 122 and the back-end environment 125 are communicatively disconnected and / or while a loop (or a portion thereof) installed in the field environment 122 is communicatively disconnected from the back-end environment 125.

[0218] For example, at least a portion of the commissioning activities may be performed before the process control system or plant 5 knows the assignment of field devices to particular I / O cards and / or I / O channels. Additionally or alternatively, various commissioning activities may be performed on various components of the process control loop while the various components are disconnected from other components of the process control loop and / or while the various components have not yet been assigned to other components of the loop. Thus, smart commissioning allows at least a portion of the commissioning process to be performed locally, automatically, distributed, and / or in parallel, such that equipment, components, and other parts of the process plant 5 are partially or fully commissioned before being fully incorporated or integrated into the plant or system 5, thereby significantly reducing the time, manpower, and costs required to commission a process plant as compared to traditional commissioning techniques.

[0219] Communications Interface Some of the described devices and / or systems include a "communications interface" (sometimes called a "network interface"). For example, device 806 includes communications interface 806. A communications interface, such as interface 806, enables a system to send information to and receive information from other systems and may include circuitry for wired and / or wireless communication.

[0220] 8, the communication interface 806 enables the device 801 to connect to the field module 291 and / or other computer systems or servers over any suitable network, such as a personal area network (PAN), a local area network (LAN), or a wide area network. In particular, the communication interface 806 has circuitry for wirelessly connecting the device 801 to the field module 291 according to protocols and standards for NFC (operating in the 13.56 MHz band), RFID (operating in the 125-134 kHz, 13.56 MHz, and / or 856 MHz-960 MHz frequency bands), Bluetooth (operating in the 2.4-2.485 GHz), WiFi Direct (operating in the 2.4 GHz or 5 GHz bands), and / or any other communication protocol or standard that enables wireless communication.

[0221] (Communications Link) A "communications link" or "link" is a path or medium that connects two or more nodes. A link may be a physical link or a logical link. A physical link is an interface and / or medium(s) for transferring information and may be wired or wireless. Examples of physical links may include cables having conductors for the transmission of electrical energy, fiber optic connections for the transmission of light, and / or wireless electromagnetic signals that carry information through changes to one or more properties of an electromagnetic wave(s).

[0222] A logical link between two nodes refers to an abstraction of the underlying physical links and / or intermediate nodes that connect two or more nodes. For example, two or more nodes may be logically coupled through a logical link. A logical link may be established through any combination of physical links and intermediate nodes (e.g., routers, switches, or other networking equipment).

[0223] A link may also be referred to as a "communications channel." In wireless communication systems, the term "communications channel" (or simply "channel") generally refers to a particular frequency or band of frequencies. A carrier signal (or carrier wave) may be transmitted at a particular frequency or within a particular frequency of the channel. In some instances, multiple signals may be transmitted over a single band / channel. For example, signals may be transmitted simultaneously over a single band / channel over different sub-bands or sub-channels. As another example, signals may be transmitted using the same band by allocating time slots in which each transmitter and receiver uses the band in question.

[0224] Memory and Computer Readable Media Generally, as used herein, the term "memory" or "memory device" refers to a system or device that includes a computer readable medium (CRM). "CRM" refers to a medium or media accessible by an associated computer system for arranging, storing, and / or retrieving information (e.g., data, computer readable instructions, program modules, applications, routines, etc.). "CRM" refers to a fixed medium, and not to intangible, transient signals such as radio waves.

[0225] A CRM may be implemented in any technology, device, or group of devices included in or in communication with an associated computer system. A CRM may include volatile and / or non-volatile media, and removable and / or non-removable media. A CRM may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk memory, magnetic cassette, magnetic tape, magnetic disk memory or other magnetic memory device, or any other medium that stores information and is accessible by a computer system. A CRM may 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, a CRM may be coupled to the system bus through a memory interface (e.g., a memory controller). A memory interface is a circuit that manages the flow of data between the CRM and the system bus.

[0226] Network Unless otherwise specified, the term "network" as used herein when used in the context of a system(s) or device(s) that communicate information or data means a collection of nodes (e.g., devices or systems that can send, receive, and / or forward information) and links connected to enable telecommunications between the nodes.

[0227] A network includes dedicated routers responsible for directing traffic between nodes, and optionally dedicated devices responsible for configuring and managing the network. Some or all of the nodes may be adapted to function as routers to direct traffic sent between other network devices. The network devices may be interconnected in wired or wireless modes. The network devices may have different routing and forwarding capabilities. For example, a dedicated router may be capable of high-capacity communication, while some nodes may be capable of sending and receiving relatively little traffic in the same period of time. In addition, the connections between the nodes of the network may have different throughput capabilities and different attenuation characteristics. Fiber optic cables may provide orders of magnitude more bandwidth than wireless links, for example, due to differences in the physical limitations inherent in the medium. A network may include a network or sub-network, for example, a local area network (LAN) or a wide area network (WAN).

[0228] (Node) In general, the term "node" refers to a connection point, a redistribution point, or a communication end point. A node may be any device or system (e.g., a computer system) that can send, receive, and / or forward information. For example, an end device or end system that initiates a message and / or ultimately receives a message is a node. Intermediate devices that receive and forward messages (between two end devices) are also generally considered to be "nodes."

[0229] Processor Various operations of the exemplary methods described herein may be performed, at least in part, by one or more processors. In general, the terms "processor" and "microprocessor" are used synonymously, each referring to a computer processor configured to retrieve and execute instructions stored in a memory. The processor(s) may execute such instructions to perform various operations or functions defined by the instructions. The processor(s) may be temporarily configured (e.g., by instructions or software) to perform the relevant operations or functions, depending on the particular embodiment, or may be permanently configured (e.g., a processor for an application specific integrated circuit (ASIC)). The processor may be part of a chipset (e.g., which may include a memory controller and / or an I / O controller). A chipset is a collection of electronic components in an integrated circuit configured to provide I / O and memory management functions, as well as a number of general-purpose and / or special-purpose registers, timers, etc. In general, one or more of the processors described herein may be communicatively coupled to other components (e.g., memory devices and I / O devices) through a system bus.

[0230] Execution of a particular operation may be located not only within a single machine, but also distributed among one or more processors located among several machines. In some exemplary embodiments, the processor(s) may be located in a single location (e.g., in a home environment, in an office environment, or as a server farm), while in other embodiments the processor may be distributed among several locations.

[0231] The terms "processing," "computing," "calculating," "determining," "presenting," "displaying," and the like refer to mechanical (e.g., computer) actions or processes that manipulate or transform data represented as physical (e.g., electronic, magnetic, or optical) quantities in one or more memories (e.g., volatile memory, nonvolatile memory, or a combination thereof), registers, or other machine components to receive, store, transmit, or display information.

Claims

1. A signal characterization component connected to a marshalling device, comprising: a first communication interface configured to be connected to a first channel coupling the signal characterization component to a processing controller; a processing control device as a field module; a second communication interface configured to be connected to a second channel coupling the signal characterization component to the processing controller, the processing controller being coupled to a plurality of discrete I / O channels for one or more field devices; one or more circuits communicatively coupled to the first communication interface and the second communication interface; The one or more circuits include: (i) transmitting a discrete output (DO) message over the second channel, the DO message being encoded with one or more commands received over the first channel; (ii) configured to transmit over the first channel one or more sets of information decoded from a discrete input (DI) message received over the second channel; Signal characterization components.

2. 2. The signal characterization component of claim 1, wherein the second channel is configured to provide power to the processing and control device, the processing and control device deriving power from a power source external to the signal characterization component.

3. 3. The signal characterization component of claim 1 or 2, wherein the one or more circuits are further configured to provide sufficient power to the second channel to enable the second channel to supply power to the processing control device.

4. 4. The signal characterization component of claim 3, wherein the first channel is a power communication bus, and the power provided to the second channel is sourced from the first channel.

5. 5. The signal characterization component of claim 4, wherein the power communication bus is connected to an I / O card that is communicatively coupled to the process controller.

6. 6. A signal characterization component according to claim 1, wherein the one or more commands include at least a first command and a second command; With respect to the first command, the DO message is encoded with a first set of bits including a first subset of bits indicative of the first command and a second subset of bits indicative of a bit inverse of the first command; With respect to the second command, the DO message is encoded with a second set of bits including a third subset of bits indicative of the second command and a fourth subset of bits indicative of a bit inverse of the second command.

7. 7. A signal characterisation component as claimed in any preceding claim, further comprising: The one or more circuits include: autosensing a device tag for the process control device; A signal characterization component further configured to transmit the device tag over the first channel such that the device tag can be coupled to the processing control device.

8. A signal characterisation component according to any preceding claim, further comprising: The one or more circuits include: autosensing a signal tag for each of the plurality of discrete I / O channels connected to the process control device; A signal characterization component further configured to transmit the signal tag over the first channel such that the signal tag can be associated with a hardware address for the discrete I / O channel.

9. A signal characterisation component according to any preceding claim, further comprising: a housing for the one or more circuits; The housing is a signal characterization component that (i) has a shape for insertion into a socket of an electronic marshalling equipment, and (ii) upon insertion enables a communicative connection between the first communication interface and the first channel, and a communicative connection between the second communication interface and the second channel.

10. 1. A method for a signal characterization component coupled to marshalling equipment to enable a process controller to control a field device configured to receive a discrete output (DO) signal through an input / output (I / O) channel, the method comprising: (A) receiving, at a signal characterization component, one or more commands transmitted by a process controller over a first channel; (B) encoding a DO message with the one or more commands; (C) transmitting the DO message by the signal characterization component over a second channel to a processing control device as a field module, The processing control device, (i) receiving the DO message via the second channel; (ii) decoding the DO message to identify the one or more commands; (iii) configuring to transmit the one or more commands over a plurality of discrete I / O channels to one or more field devices; The method according to claim 1,

11. 11. The method of claim 10, further comprising providing sufficient power to the second channel to enable power to be provided to the process control device through the second channel.

12. 12. The method of claim 11, wherein the first channel is a power communication bus; The method, wherein the power provided to the second channel is derived from the first channel by the signal characterization component.

13. 13. The method of claim 12, wherein the power communication bus is connected to an I / O card communicatively coupled to the process controller.

14. 14. The method of claim 13, wherein the one or more commands include at least a first command and a second command; encoding the DO message with the one or more commands, for the first command, encoding the DO message with a first set of bits including a first subset of bits indicative of the first command and a second subset of bits indicative of a bit inverse of the first command; for the second command, encoding the DO message with a second set of bits including a third subset of bits indicative of the second command and a fourth subset of bits indicative of a bit inverse of the second command; The method according to claim 1,

15. 15. The method according to any one of claims 10 to 14, autosensing a device tag for the process control device; transmitting the device tag over the first channel so that the device tag can be coupled to the processing control device; The method further comprises:

16. 16. The method according to any one of claims 10 to 15, autosensing a signal tag for each of the plurality of discrete I / O channels connected to the process control device; transmitting said signal tag over said first channel such that said signal tag can be connected to a hardware address for said discrete I / O channel; The method further comprises:

17. 17. A method as claimed in any one of claims 10 to 16, further comprising the step of inserting the signal characterisation component into a socket of an electronic marshalling equipment such that the signal characterisation component is physically interfaced with the first and second channels to enable communication by the signal characterisation component over the first and second channels prior to receiving the one or more commands transmitted by the processing controller.

18. 18. A method as claimed in any one of claims 10 to 17, further comprising the step of inserting the signal characterisation component into a socket of an electronic marshalling equipment such that the signal characterisation component wirelessly interfaces with the first and second channels, thereby enabling communication by the signal characterisation component over the first and second channels, prior to receiving the one or more commands transmitted by the processing controller.

Images