Variable level integrity checking of communications in a process control environment

Abstract

The described methods and systems enable process control devices to transmit and receive device variable values in a manner that enables the receiving device to verify the integrity of the received values on a variable-by-variable basis. To facilitate verification of integrity, any desired number of variables in a message can have a data integrity check result in the message. For each received value that has a data integrity check result, the receiving device can compute its own data integrity check result based on the received value and a seed (known to both the transmitting and receiving devices) and can then compare it to the received data integrity check result to verify that the received value has not changed during communication.

Description

Technical Field

[0001] This disclosure generally relates to verifying the integrity of communications in a process control environment, and more specifically, to verifying the integrity of variable values ​​(e.g., those used in safety systems) in such communications on a variable-by-variable basis to improve the reliability and trustworthiness of variable values ​​for receiving devices. Background Technology

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

[0003] Field devices perform functions within a process or plant, such as opening or closing valves, connecting or disconnecting equipment, and measuring process parameters. Example field devices include valves, valve positioners, switches, and transmitters (e.g., devices including sensors for measuring temperature, pressure, or flow rate; and transmitters for transmitting sensed temperature, pressure, and flow rate).

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

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

[0006] Input / output (I / O) cards (sometimes also called "I / O devices" or "I / O modules") are typically located within the plant environment and are usually communicatively positioned between the controller and one or more field devices to enable communication between them (e.g., by converting electrical signals to digital values ​​and vice versa). Typically, I / O cards serve as intermediate nodes between process controllers and one or more field device inputs or outputs configured to use one or more communication protocols identical to those used by the I / O card. Specifically, field device inputs and outputs are typically configured for analog or discrete communication. To communicate with field devices, the controller typically requires an I / O card configured for the same type of inputs or outputs used by the field device. That is, for field devices configured to receive analog control output signals (e.g., 4-20mA signals), the controller needs an analog output (AO) I / O card to transmit the appropriate analog control output signals; and for field devices configured to transmit measured values ​​or other information via analog signals, the controller typically needs an analog input (AI) card to receive the transmitted information. Similarly, for field devices configured to receive discrete control output signals, the controller requires a Discrete Output (DO) I / O card to transmit the appropriate discrete control output signals; and for field devices configured to transmit information via discrete control input signals, the controller requires a Discrete Input (DI) I / O card. Additionally, some I / O cards are configured for resistance temperature detectors (RTDs) (which change the resistance of wires with temperature) or thermocouples (TCs) (which generate a voltage proportional to temperature). Typically, each I / O card can connect to multiple field device inputs or outputs, where each communication link to a particular input or output is called an "I / O channel" (or more generally, a "channel"). For example, a 120-channel DO I / O card can communicate with 120 different discrete field device inputs through 120 different DO I / O channels, enabling the controller (via the DO I / O card) to transmit discrete control output signals to 120 different discrete field device inputs.

[0007] As used herein, field devices, controllers, and I / O devices are generally referred to as “process control devices” and are typically located, set up, or installed in the field environment of a process control system or plant. A network consisting of one or more controllers, field devices communicatively connected to one or more controllers, and intermediate nodes that facilitate communication between the controllers and field devices may be referred to as an “I / O network” or “I / O subsystem”.

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

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

[0010] In addition, in many processes, safety systems (sometimes called “safety instrumented systems” or “SIS”) are provided to detect critical safety-related issues within the process plant and, in the event of problems that could lead to serious harm to the plant, such as leaks of toxic chemicals, explosions, etc., to automatically shut off valves, remove power from equipment, switch flow within the plant, etc. What a safety system or SIS should do (functional requirements) and how well it must perform (safety integrity requirements) can be determined based on hazard and operability studies (HAZOP), layer of protection analysis (LOPA), risk maps, etc. Example techniques are mentioned in IEC 61511 and IEC 61508. During the design, construction, installation, and operation of a safety system or SIS, safety personnel typically verify that these requirements are met. Functional requirements can be verified through design reviews, such as failure mode, effects, and criticality analysis (FMECA), and various types of testing (e.g., example plant acceptance testing, field acceptance testing, and routine functional testing).

[0011] Generally, a safety system, or SIS, is designed to perform "specific control functions" to prevent failures or maintain the safe operation of a process in the event of unacceptable or hazardous conditions. Typically, a safety system operates relatively independently of other control systems to ensure its functionality is not compromised. Safety systems usually consist of control elements (including sensors, logic solvers or controllers, actuators, and other control devices) of the same type as a basic process control system (BPCS). However, in conventional implementations, the control elements in a safety system are dedicated solely to the normal operation of the safety system (e.g., rather than to the proper control of the process controlled by the control system).

[0012] Typically, a "Safety Instrumented Function" (SIF) is a specific set of devices in a safety system designed to reduce the risk associated with a particular hazard, and can be considered or referred to as a safety system control loop or "safety loop." An SIF aims to (1) automatically place an industrial process in a safe state in the event of a breach of specified conditions; (2) allow the process to proceed safely if specific conditions permit (permitted functions); and (3) take steps to mitigate the consequences of an industrial hazard. SIFs are typically implemented as part of an overall risk reduction strategy designed to eliminate the likelihood of previously identified safety, health, and environmental (SH&E) events, ranging from minor equipment damage to events involving uncontrolled catastrophic energy and / or material releases.

[0013] Typically, a specific level of protection is assigned to each Safety Integrity Level (SIF) or Safety Loop using one of the methods defined in IEC 61508 / 61511 as a “risk map,” “risk matrix,” or LOPA, defined by a “Safety Integrity Level” or “SIL” (1, 2, 3, or 4). SIL assignment is an exercise in risk analysis where the risk associated with a specific hazard (aimed at being protected by the SIF) is calculated without the beneficial risk reduction effect of the SIF. This unreduced risk is then compared to a tolerable risk target. If the unreduced risk is higher than the tolerable risk, the difference between the unreduced and tolerable risks must be addressed by reducing the risk through the SIF. The required amount of risk reduction is related to the SIL target. Essentially, each order of magnitude of the required risk reduction is associated with an increase in one of the required SIL numbers. In a typical example, SIL-1 represents a risk reduction of up to 100 times; SIL-2 represents a risk reduction of up to 1000 times; SIL-3 represents a risk reduction of up to 10,000 times; and SIL-4 represents a risk reduction of up to 100,000 times.

[0014] The International Electrotechnical Commission (IEC) standard IEC 61508 defines Safety Integrity Levels (SILs) using requirements grouped into two main categories: Hardware Safety Integrity and System Safety Integrity. Equipment or systems should generally meet the requirements of both categories to achieve a given SIL. Hardware Safety Integrity SIL requirements are based on a probabilistic analysis of the equipment. To achieve a given SIL, equipment typically aims to meet the objectives of the maximum probability of a hazardous failure and the minimum safe failure fraction. Typically, the concept of a “hazardous failure” is defined for the system in question, usually in the form of requirement constraints whose integrity is verified throughout the system development process. The actual objectives required vary depending on the likelihood of the requirements, the complexity of one or more devices, and the type of redundancy used.

[0015] Regarding communication, the IEC 61508 standard indicates that, in order to achieve the required Safety Integrity Level (SIL), safety communication should not exceed 1% of the permissible probability of a hazardous failure per hour. For use in SIL 3 applications to be acceptable, the probability of a hazardous failure caused by safety communication must be less than 10⁻⁹ times per hour. In short, the ability to verify the integrity of a given message received via communication can significantly impact whether a safety system can rely on that message in a manner consistent with typical safety standards. In other words, if the integrity of a message cannot be verified, the expected error rate associated with the communication may exceed an acceptable threshold, rendering the information unusable by the safety system.

[0016] As mentioned above, in addition to the process control controller, safety systems typically have one or more separate logic solvers or controllers (sometimes called "safety controllers") connected to safety field devices via separate buses or communication lines located within the process plant. Safety controllers use these field devices to detect process conditions related to critical events, such as the position of certain safety switches or shut-off valves, overflows or underflows in the process, the operation of critical power generation or control equipment, and the operation of fault detection equipment, thereby detecting "events" representing abnormal conditions within the process plant. When an event is detected, the safety controller takes measures to limit its adverse effects, such as issuing commands to close one or more valves, deactivate or shut down one or more devices, disconnect power to various parts of the plant, and so on.

[0017] Note that this background description provides context to facilitate understanding and comprehension of the specific implementations described below. The work of the currently named inventors, within the scope described in this background section (and in respect of the background description which may not conform to the prior art at the time of submission), is neither explicitly nor implied to be acknowledged as prior art to this disclosure. Summary of the Invention

[0018] The described methods and systems enable process control devices to transmit and receive device variable values ​​in a manner that allows receiving devices to verify the integrity of received values ​​on a variable-by-variable basis.

[0019] In an embodiment, a method for transmitting a message including values ​​of device variables includes: transmitting the message such that the integrity of the values ​​can be verified on a variable-by-variable basis. The method may include any one or more of the following: detecting a detected value of a device variable by a first process control device in a process control environment for controlling a process; calculating a first data integrity check result by the process control device using the detected value and a seed as input to perform a data integrity calculation; encoding the message to include the detected value and the first data integrity check result for the detected value; or transmitting the message. Transmitting the message may include transmitting the message so that it can be received by a second process control device configured to: (i) receive the message; (ii) calculate a second data integrity check result for candidate values ​​of the device variables in the message; (iii) at the second process control device, updating or not updating a process variable mapped to a device variable using the candidate values ​​based on whether the first and second data integrity check results match; and (iv) performing a function as part of a control scheme for the process based on the process variable.

[0020] In one embodiment, a system is configured to transmit messages including values ​​of process variables that can be authenticated at the parameter or variable level (e.g., on a variable-by-variable basis). The system may include a first process control device configured to communicatively couple to one or more other process control devices in an input / output (I / O) network of a process control environment for controlling the process. The first process control device may include any one or more of: (A) a communication interface configured to couple field devices to one or more controllers; or (B) a set of circuitry communicatively coupled to the communication interface. The set of circuitry may be configured to: detect a detected value of a device variable; perform a data integrity calculation using the detected value and a seed as input to calculate a first data integrity check result; encode a message to include the detected value and the first data integrity check result for the detected value; or transmit the message to a second process control device via the communication interface. The second process control device can be configured to perform any one or more of the following: (i) receiving a message; (ii) calculating a second data integrity check result for candidate values ​​of device variables in the message; (iii) at the second process control device, updating or not updating the process variables mapped to the device variables based on whether the first and second data integrity check results match; or (iv) performing a function as part of the process control scheme based on the process variables.

[0021] In an embodiment, a method for verifying the integrity of device variable values ​​included in a message from a process control device may be performed. The method may include any one or more of the following: (1) receiving a message transmitted by a first process control device at a second process control device in a process control environment for controlling a process; (2) decoding the message to identify in the message: (i) candidate values ​​of the device variable, and (ii) a first data integrity check result of the device variable; (3) calculating a second data integrity check result by performing a second data integrity calculation using the candidate value and a seed as input; (4) comparing the second data integrity check result with the first data integrity check result to determine whether the second data integrity check result matches the first data integrity check result, thereby determining whether the candidate value matches the detection value used to calculate the first data integrity check result; (5) responding to the determination that the second data integrity check result does not match the first data integrity check result by discarding the candidate value, such that the process variable mapped to the device variable retains its previous value; (6) responding to the determination that the second data integrity check result matches the first data integrity check result by updating the process variable at the second process control device using the candidate value; or (7) performing a function as part of a control scheme for the process based on the process variable.

[0022] In an embodiment, a system for verifying the integrity of device variable values ​​included in messages from a process control device may be implemented. The system may include a second process control device configured to communicatively couple to a first process control device within a process control environment. The second process control device may include any one or more of the following: (A) a communication interface configured to communicatively couple the second process control device to the first process control device; or (B) a set of circuitry communicatively coupled to the communication interface. The circuitry can be configured to: receive messages transmitted by a first process control device via a communication interface; and decode the messages to identify in the messages: (i) candidate values ​​of device variables, and (ii) a first data integrity check result of the device variables; calculate a second data integrity check result by performing a second data integrity calculation using the candidate values ​​and a seed as input; compare the second data integrity check result with the first data integrity check result to determine whether the second data integrity check result matches the first data integrity check result, thereby determining whether the candidate values ​​match the detection values ​​used to calculate the first data integrity check result; respond to determining that the second data integrity check result does not match the first data integrity check result by discarding candidate values, such that the process variables mapped to the device variables retain their previous values; respond to determining that the second data integrity check result matches the first data integrity check result by updating the process variables using the candidate values; or perform a function as part of a process control scheme based on the process variables. Attached Figure Description

[0023] Figure 1 It is a block diagram of an example process control plant in which the described techniques can be performed.

[0024] Figure 2 This is a block diagram of example field devices and example controllers that can communicate according to the described technology.

[0025] Figure 3 An example layer of an example protocol stack is shown, which the process control device described herein can utilize to transmit and receive device variable values ​​in a manner that enables the receiving device to verify the integrity of received values ​​on a variable-by-variable basis.

[0026] Figure 4 An example message payload is shown, which may include one or more variable values ​​or candidate values ​​with corresponding data integrity checks, so that the receiving device can verify the integrity of the included values ​​on a variable-by-variable basis.

[0027] Figure 5An additional example message payload is shown, which may include one or more variable values ​​or candidate values ​​with corresponding data integrity checks, enabling the receiving device to verify the integrity of the included values ​​on a variable-by-variable basis.

[0028] Figure 6 An example method is shown for transmitting messages including variable values ​​in a manner that enables the receiving device to verify the integrity of received values ​​on a variable-by-variable basis.

[0029] Figure 7 An example method 700 is shown for receiving messages including variable values ​​in a manner that enables verification of the integrity of received values ​​on a variable-by-variable basis. Detailed Implementation

[0030] The described methods and systems enable process control devices to transmit and receive device variable values ​​in a manner that allows the receiving device to verify the integrity of the received values ​​on a variable-by-variable basis. For ease of integrity verification, any desired number of variables in the message can have data integrity checks. For each received value with a data integrity check, the receiving device can calculate its own data integrity check based on the received value and a seed (known to both the transmitting and receiving devices). For each process variable value where there is a mismatch between the received and calculated data integrity checks, the receiving device can assume that the received value does not match the originally transmitted value (and therefore can discard the received value). On the other hand, if the received and calculated data integrity checks for a particular device variable match, the receiving device can verify the integrity of the received value (i.e., verify that it matches the original transmitted value). As a result, the receiving device can confidently take actions on the received value (e.g., by updating local or system-wide process variables corresponding to the device variable, performing control based on the received value, etc.). In contrast, conventional systems, in terms of their ability to verify data integrity, typically perform verification based on data packets or messages. In such systems, any change to any data in a message renders the entire message unverifiable. Therefore, if a single device variable value (or any other data) is corrupted after transmission, the receiving device must discard the entire message (or continue processing with a value whose integrity cannot be verified).

[0031] As used herein, the term "message" refers to a unit of communication represented by a dataset transmitted or received through a node (e.g., via a link). The dataset representing a message may include a payload (i.e., the content intended to be transmitted) and protocol overhead. Overhead may include routing information and metadata related to the protocol or payload (e.g., the protocol identifying the message, the expected receiving node, the originating node, the size of the message or payload, data integrity information used to check message integrity, etc.). In some cases, data packets or sequences of data packets may be considered messages.

[0032] In any case, the following reference Figure 1-7 Various technologies, systems, and methods were discussed. I, Example process control environment

[0033] Figure 1 Process plant 10 is illustrated, in which each of the safety controller, process controller, and field devices shown can be configured (if desired) to transmit and receive messages including variable values ​​in a manner that enables the receiving device to verify the integrity of received values ​​on a variable-by-variable basis. This improvement in verifying data integrity on a variable-by-variable basis can be particularly beneficial to safety systems (such as the system shown in Figure 1), enabling them to rely on communication carrying variable values ​​that might otherwise be too error-prone for safety system execution.

[0034] As used herein, a “process control device” is any device configured to perform in process plant 10 and configured to transmit or receive messages carrying process variables according to one or more protocols performed in process plant 10, such that the messages can be received, decoded, and processed by one or more devices in process plant 10.

[0035] As shown in the figure, the process plant or environment 10 includes a process control system 12 integrated with a safety system 14 (indicated by dashed lines). This safety system typically operates as a safety instrumented system (SIS) to monitor and override the controls provided by the process control system 12 to maximize the likelihood of safe operation of the process plant 10. A. Example components of example process control systems and example safety systems

[0036] At a higher level, plant 10 may include a field environment and a back-end environment, the field environment including process control devices (e.g., field devices, controllers, and I / O devices) typically located, set up, or installed in areas where the controlled process is measured and controlled. Figure 1 The components in nodes 18 and 20 shown can be included in the backend environment, which may include components isolated from or removed from the field environment (e.g., in an office environment, a remote environment, etc.). Figure 1 Components 21 and 16 are shown.

[0037] More specifically, the process plant 10 includes one or more host workstations, computers, or user interfaces 16 (which can be any type of personal computer, workstation, etc.) accessible to plant personnel (e.g., process control operators, maintenance personnel, configuration engineers, etc.). Figure 1 In the example shown, three user interfaces 16 are shown connected to two separate process control / safety control nodes 18 and 20 and a configuration database 21 via a common communication line or bus 22. The communication network 22 can be implemented using any desired bus-based or non-bus-based hardware, any desired hardwired or wireless communication structure, and any desired or suitable communication protocol (e.g., Ethernet).

[0038] Generally, as used herein and unless otherwise stated, the term "network" refers to a collection of nodes (e.g., devices or systems capable of sending, receiving, or forwarding information) and links connected to enable remote communication between the nodes. Depending on the embodiment (and unless otherwise stated), each of the described networks may include a dedicated router, switch, or hub responsible for forwarding and bootstrapping traffic between nodes, and optionally dedicated devices responsible for configuring and managing the network. Some or all of the nodes in the described network may also be adapted to function as routers to bootstrap traffic transmitted between other network devices. The nodes of the described network may be interconnected via wired or wireless means and may have different routing and transmission capabilities.

[0039] Generally, each of nodes 18 and 20 in process plant 10 includes both process control system equipment and safety system equipment connected together via a bus structure, which can be provided on a backplane to which different devices are attached. Node 18 in Figure 1 The diagram shows a process controller 24 (which can be a pair of redundant controllers) and one or more process control system input / output (I / O) devices 28, 30, and 32, while node 20 is shown as a process controller 26 (which can be a pair of redundant controllers) and one or more process control system I / O devices 34 and 36. Each of the process control system I / O devices 28, 30, 32, 34, and 36 is communicatively connected to a set of process control-related field devices. Figure 1 The diagram shows field devices 40 and 42. The process controllers 24 and 26, I / O devices 28-36, and controller field devices 40 and 42 roughly constitute the system. Figure 1 12. Process control system.

[0040] One or more of field devices 40, 42, 60, and 62 may be actuators for devices such as valves and may respond to commands received from a controller coupled thereto (e.g., configured to actuate a valve to open or close it in response to a command from the controller). Similarly, one or more of field devices 40, 42, 60, and 62 may be transmitters configured to detect measured values ​​(e.g., flow rate, temperature, pressure, etc.) via sensors and transmit the measured values ​​to the controller. One or more field devices may be “smart” field devices configured to transmit one or more “minor” variable values, rather than field devices configured to drive or measure a primary process variable. For example, in a HART implementation, the field device may transmit or receive a primary variable via a 4-20mA signal and may transmit or receive one or more minor variables via a digital signal superimposed on the 4-20mA signal.

[0041] Generally speaking, a "field device variable" is a variable within a field device that is configured to detect (e.g., measured via sensors or calculated) or set (e.g., in response to a message received from a controller). In a typical implementation, a field device variable is a process variable that is part of a related process control system or safety system, including one or more (e.g., via configuration system 80) mapped to the field device variable. More broadly, when discussing "device variables" with reference to a particular device, this typically refers to variables that are detected, calculated, set, updated, etc., by that particular device.

[0042] Node 18 includes one or more security system logic resolvers 50, 52, while node 20 includes security system logic resolvers 54 and 56. Each of the logic resolvers 50-56 is an I / O device with a processor 57 that executes a security logic module 58 stored in memory and is communicatively connected to provide control signals to and / or receive signals from security system field devices 60 and 62.

[0043] Generally, as used herein, the phrase "memory" or "memory device" refers to a system or device that includes one or more computer-readable media ("CRM"). "CRM" refers to one or more media accessible to the relevant computing system for placing, storing, or retrieving information (e.g., data, computer-readable instructions, program modules, application programs, routines, etc.). Note that "CRM" refers to a medium that is inherently non-transient, and not to a non-physical transient signal such as radio waves. The CRM of the described memory can be implemented in any technology, device, or group of devices that includes or communicates with the relevant computing system. The CRM of the described memory can include volatile or non-volatile media, as well as removable or non-removable media.

[0044] In any case, each of nodes 18 and 20 includes at least one message propagation device (MPD) 70 or 72, which are communicatively coupled to each other via a ring bus connection 74. The security system logic solvers 50-56, security system field devices 60 and 62, MPDs 70 and 72, and bus 74 roughly constitute the following: Figure 1 Security system 14.

[0045] In some embodiments, safety system field devices 60 and 62 may be field devices designed specifically for safety system performance rather than typical process control operations. On the other hand, in some embodiments, safety system field devices 40 and 60 may be field devices capable of performing in a typical process control system (e.g., system 12), and may, for example, be used as field devices in both process control system 12 and safety system 14 simultaneously. However, in such embodiments, the field devices may need to meet higher standards typically required for performance in safety systems (e.g., higher requirements for the verifiable integrity of data transmitted and received by the devices). Therefore, the variable-wise data integrity verification techniques disclosed herein may be particularly useful in safety systems such as safety system 14.

[0046] Process controllers 24 and 26, for example only, could be DeltaV sold by Emerson Process Management. TMControllers, or any other desired type of process controller, are programmed to provide process control functionality (using what are commonly called control modules) using I / O devices 28, 30, and 32 (for controller 24), I / O devices 34 and 36 (for controller 26), and field devices 40 and 42. Specifically, each of controllers 24 and 26 executes or monitors one or more process control routines stored therein or otherwise associated with it, and communicates with field devices 40 and 42 and workstation 14 to control process 10 or a portion thereof in any desired manner. Field devices 40 and 42 can be any desired type of field device, such as sensors, valves, transmitters, positioners, etc., and can conform to any desired open, proprietary, or other communication or programming protocols, including, for example, HART or 4-20mA protocols (as shown in field device 40), any fieldbus protocol, such as the Foundation Fieldbus protocol (as shown in field device 42), or CAN, Profibus, AS-Interface protocols, etc., to name just a few. Similarly, I / O devices 28-36 can be any known type of process control I / O device using any suitable one or more communication protocols. Generally, a process controller determines one or more controller output values ​​(i.e., commands transmitted by the controller) by executing control routines (part of a larger control strategy for controlling the process) to drive one or more process inputs (i.e., manipulated variables responding to controller commands, such as control valve positions) to drive process outputs (i.e., controlled variables, such as temperature, flow rate, etc.) to desired values ​​(i.e., setpoints) based on one or more measured process inputs (e.g., measured temperature, flow rate, pressure, etc.) received at the controller as controller inputs, thereby achieving control of the controlled process.

[0047] Figure 1The safety logic solvers 50-56 can be any desired type of safety system control device, including a processor 57 and a memory storing safety logic modules or routines 58 adapted to execute on the processor 57 to provide control functions associated with the safety system 14 using field devices 60 and 62. The logic executed by the logic solver for performing safety control of the controlled process can be referred to as a “safety scheme” or “safety system scheme.” A safety scheme may involve commanding one or more of field devices 40, 42, 60, or 62 to transition to a safe state (e.g., by actuating an associated valve to drive it to a safe state) based on one or more unsafe conditions and the logic of the safety scheme. The unsafe conditions are detected based on an assessment of one or more process variable values ​​(e.g., sensor measurements, diagnostic indices, etc.). The nature of the safe state typically depends on the specific nature of the process in question and the field devices. For example, if a tank is at risk of overflow, the logic solver can drive the inlet valve to a safe state by closing the valve (thus preventing further liquid from entering the tank). In contrast, the logic solver can drive the outlet valve to a safe state by opening the outlet valve (thus emptying the tank). That is, in this particular example, the safe state of the inlet valve can be 0% open and the safe state of the outlet valve can be 100% open.

[0048] Of course, safety field devices 60 and 62 can be any desired type of field device that conforms to or uses any known or required communication protocol, such as those mentioned above. In particular, field devices 60 and 62 can be the type of safety-related field device typically controlled by a separate, dedicated safety-related control system. Figure 1 In the process plant 10 shown, safety field device 60 is shown using a dedicated or point-to-point communication protocol, such as HART or 4-20mA, while safety field device 62 is shown using a bus communication protocol, such as a fieldbus protocol. However, as noted, in the embodiments, safety field devices 60 and 62 can be typical field devices that can be deployed and used in both the process control system 12 and the safety system 14.

[0049] A common backplane 76 (represented by dashed lines passing through controllers 24, 26, I / O devices 28-36, safety logic resolvers 50-56, and MPDs 70 and 72) is used on each node 18 and 20 to connect controllers 24 and 26 to process control I / O cards 28, 30 and 32 or 34 and 36, to safety logic resolvers 52, 54 or 56 and 58, and to MPDs 70 or 72. Controllers 24 and 26 are also communicatively coupled to bus 22 and operate as bus arbitrators of bus 22, enabling each of the I / O devices 28-36, logic resolvers 52-56, and MPDs 70 and 72 to communicate with any workstation 16 via bus 22.

[0050] As will be understood, each workstation 16 includes a processor 77 and a memory 78, which stores one or more configuration and / or viewing applications suitable for execution on the processor 78.

[0051] Configure application 80 and view application 82 in Figure 1 The configuration application 80 is shown in an exploded diagram as being stored in one of workstations 14. However, if needed, these applications can be stored and executed on different workstations within workstation 14 or on other computers associated with process plant 10. Generally, configuration application 80 provides configuration information to configuration engineers, enabling them to configure some or all components of process plant 10 and store that configuration in configuration database 21. As part of the configuration activities performed by configuration application 80, configuration engineers can create control routines or control modules for process controllers 24 and 26, create safety logic modules for any and all safety logic solvers 50-56, and download these different control and safety modules to the appropriate process controllers and safety logic solvers in process controllers 24 and 26 and safety logic solvers 50-56 via bus 22 and controllers 24 and 26. Similarly, configuration application 80 can be used to create other programs and logic and download them to any of I / O devices 28-36, field devices 40, 42, 60, and 62, etc.

[0052] Configuration application 80 includes, or may otherwise access, a configuration database that stores data and other information that specifically identifies or addresses various devices or components and their interconnections, which are planned or desired to be executed in a process plant shop or in a field environment. As an example, the configuration database may store multiple logical identifiers for components in the field environment, enabling controllers and other devices to reference components and signals associated with them through these logical identifiers. For instance, for a given field device, the configuration database may store information mapping or binding logical identifiers to specific hardware addresses or I / O channels. Hardware addresses may identify a specific controller, a specific I / O card connected to a specific controller, or a specific address used to connect a specific I / O card to an I / O channel of the field device. In some cases, this mapping or binding may be stored at a controller, user interface device, operator workstation, or any other desired device (e.g., any device that needs to resolve logical identifiers).

[0053] After a logical identifier is bound to a hardware address or I / O channel, that identifier is considered "assigned." In some cases, System 10 includes "unassigned" logical identifiers, which are identifiers referenced by software elements (e.g., control routines or function blocks) but not bound. That is, logical identifiers are considered "unassigned" when System 10 and the configuration database are not bound to a tag's hardware address or I / O channel. Therefore, when an unassigned logical identifier is referenced by a control routine, the value carried by a signal in Plant 10 will not be read, and commands will not be transmitted to field devices in Plant 10 via signals.

[0054] Example logical identifiers include device labels (DTs), each label representing a specific instrument, controller, valve, or other physical field device (e.g., field device 60A); and device signal labels (DSTs), each signal label representing a specific signal received or generated by a specific device and typically corresponding to a specific parameter used by the field device (e.g., a command received by field device 60A from controller 52 or a measurement result transmitted by field device 60A to controller 52). For some devices, the DST includes a combination of the device's DT and an identifier for the specific signal received or generated by that device (e.g., an identifier for a specific parameter referenced by a control module). For some devices, typically conventional or dumb devices, the DT represents both the physical device and the signal generated by the device. Generally, process plant 10 uses logical identifiers for devices to uniquely identify devices in both field and back-end environments. DTs and DSTs may be referred to as "system labels" or "system identifiers." Variables represented by "system labels" may be referred to as "system variables."

[0055] In some cases, one or more smart field devices (e.g., one or more of field devices 40, 42, 60, or 62) may also store logical identifiers unique to smart field device 22. These logical identifiers may be different from the system tags used by factory 10 to identify field devices and their associated signals, and may be referred to as "source identifiers" or "source tags." Source tags may or may not be stored in the configuration database mentioned above, depending on the implementation.

[0056] Generally, the "field device variables" discussed in this paper refer to variables local to the described field device. For example, a smart field device may have a local "source tag" that uniquely identifies the local field device variable. If needed, a smart field device can be configured to transmit the field device variable value to the appropriate controller, which can then map the received value to a system tag intended for mapping to a source tag of interest. In some cases, the control system 10 may be configured such that one or more source tags of the field device are not mapped to a system tag (and therefore the represented variable may not be integrated into and considered by the relevant process control system or safety system). Some source tags may be ignored by the process control system or safety system because the variable it represents may not be meaningful to the operational or safety objectives of the process control system or safety system.

[0057] Viewing application 82 can be used to provide one or more displays to users, such as process control operators, safety operators, etc., including, if needed, information about the status of process control system 12 and safety system 14 in separate views or within the same view. For example, viewing application 82 can be an alarm display application that receives alarm indications and displays them to the operator. This alarm display can receive alarms from both process control system 12 and safety system 14 and display them in an integrated alarm display, since alarms from both systems 12 and 14 will be sent to the operator workstation 14 executing the alarm display application and will be identifiable as alarms from different devices. Similarly, operators can handle safety alarms displayed in the alarm bar in the same way as process control alarms. For example, operators or users can use the alarm display to acknowledge safety alarms, deactivate safety alarms, etc., which will use communication via bus 22 and backplane 76 to send messages to the appropriate process controllers 24, 26 within safety system 14 to take appropriate action in response to the safety alarm. In a similar manner, other viewing applications can display information or data from process control system 12 and safety system 14, because these systems use the same type and kind of parameters, safety and references, making it possible for any data from one of systems 12 and 14 to be integrated into displays or views traditionally provided for process control systems.

[0058] In any case, applications 80 and 82 can send individual configuration and other signals to each process controller 24 and 26 and each safety system logic resolver 50-56, and can receive data from them. These signals may include process-level messages related to the operating parameters of the control process field devices 40 and 42, and may include safety-level messages related to the operating parameters of the control safety-related field devices 60 and 62. Although safety logic resolvers 50-56 can be programmed to recognize process-level and safety-level messages, they are able to distinguish between these two types of messages and cannot be programmed or influenced by process-level configuration signals. In one example, programming messages sent to the process control system devices may include certain fields or addresses that are recognized by the safety system devices and prevent those signals from being used to program the safety system devices.

[0059] If necessary, the safety logic solvers 50-56 can employ the same or different hardware or software designs compared to those used for the process control I / O cards 28-36. However, using alternating techniques for the devices within the process control system 12 and the devices within the safety system 14 can minimize or eliminate hardware or software failures of common causes.

[0060] Furthermore, the security system devices, including logic solvers 50-56, can employ any necessary isolation and security techniques to reduce or eliminate the possibility of unauthorized changes to the security-related functions thereby implemented. For example, the security logic solvers 50-56 and configuration application 80 may require personnel with specific privilege levels or located at specific workstations to modify security modules within the logic solvers 50-56, where this privilege level or location differs from the privilege or access level or location required to modify process control functions performed by controllers 24 and 26 and I / O devices 28-36. In this case, only those personnel specified in the security software or located at workstations authorized to modify the security system 14 are authorized to change security-related functions, minimizing the possibility of compromising the operation of the security system 14. It will be understood that, to achieve this security, the processor within the security logic solvers 50-56 evaluates the correct form and security of incoming messages and acts as a gatekeeper when changes are made to the security-level control module 58 executed within the security logic solvers 50-56.

[0061] Furthermore, if necessary, once safety-related functions are enabled within logic solvers 50-56, the state of safety functions cannot be changed via operator workstation 14 without proper access permissions. This allows the communication structure associated with process control system 12 to be used to provide initialization for safety system 14 and to provide runtime reports on the operation of safety system 14. However, process control system 12 remains isolated from safety system 14 in the sense that changes to process control system 12 do not affect the operation of safety system 14.

[0062] As will be understood, the use of backplane 76 in each of nodes 18 and 20 enables safety logic resolvers 50 and 52, as well as safety logic resolvers 54 and 56, to communicate locally with each other to coordinate safety functions performed by each of these devices, transfer data to each other, or perform other integrated functions. On the other hand, MPDs 70 and 72 operate such that the components of safety system 14 located at different locations in plant 10 still communicate with each other to provide coordinated safety operation at different nodes in process plant 10. Specifically, MPDs 70 and 72, in conjunction with bus 74, enable safety logic resolvers associated with different nodes 18 and 20 of process plant 10 to communicatively cascade together to allow cascading of safety-related functions within process plant 10 according to specified priorities. Alternatively, two or more safety-related functions at different locations within process plant 10 can be interlocked or interconnected without having to run dedicated lines to individual safety field devices within separate areas or nodes of plant 10. That is, the use of MPDs 70 and 72 and bus 74 enables configuration engineers to design and configure safety system 14, which is essentially distributed throughout the process plant 10, but with its different components interconnected so that different safety-related hardware can communicate with each other as needed. This feature also provides scalability to safety system 14, as it allows additional safety logic solvers to be added to safety system 14 when needed or when new process control nodes are added to process plant 10. B. Example Field Devices and Controllers

[0063] Figure 2 This shows the field device 60A and the controller 52 (also shown). Figure 1 A block diagram of an example component (shown in the diagram), via Figure 1 The I / O network 1 shown in the figure has links 199 that are communicatively coupled, each of which can be configured to transmit and receive messages including variable values ​​in a manner that enables the receiving device to verify the integrity of the received values ​​on a variable-by-variable basis.

[0064] Unless otherwise stated, a “communication link” or “link” is a path or medium connecting two or more nodes. A link can be a physical link or a logical link. A physical link is an interface or medium(s) for transmitting information and can be wired or wireless in nature. Examples of physical links include (i) wired links, such as cables with conductors for transmitting electrical energy or fiber optic connections for transmitting light, and (ii) wireless links, such as radio electromagnetic signals that carry information by altering one or more properties of electromagnetic waves. A logical link between two or more nodes represents an abstraction of the underlying physical link or intermediate node connecting the two or more nodes. For example, two or more nodes can be logically coupled via a logical link. A logical link can be established via any combination of physical links and intermediate nodes (e.g., routers, switches, or other network devices).

[0065] As shown in the figure, field device 60A includes a set of circuitry 102, a communication interface 104 for coupling field device 60A to controller 52 via link 199, actuator 106 (e.g., for actuating a valve), and / or sensors (e.g., for detecting or measuring process variable values, such as pressure, flow rate, tank level, temperature, etc.). The set of circuitry 102 includes a processor 113 coupled to memory 111. Memory 111 may include logic or instructions 121 that, when executed by processor 113, cause the field device to perform one or more functions described herein (e.g., refer to...). Figure 6 and 7 (Those described). Specifically, logic 121 may include data integrity formula 132 for calculating data integrity verification results and actuator / sensor logic 134. Memory 111 may also include seed 123 and device variable 125 (which may be any suitable variable detected by field device 60A via sensor 108 or via calculation by processor 113).

[0066] Furthermore, controller 52 includes a set of circuitry 152 and a communication interface 154 for (i) coupling controller 52 to field device 60A via link 199, and (ii) coupling controller 52 to communication network 22. The set of circuitry 152 includes a processor 163 and a memory 161, the memory 161 including logic or instructions 171 that, when executed by processor 163, cause controller 52 to perform one or more functions described herein (e.g., using references). Figure 6 and 7(Those described). Memory 152 includes the same data integrity formula 132 and the same seed 123 used by field device 60A, enabling controller 52 to calculate the data integrity verification result of the value received from field device 60A. Controller 52 includes process variables 175 corresponding to or mapped to device variable 125.

[0067] In operation, field device 60A executes logic 134 to perform control functions regarding actuator 106 (e.g., actuating a valve in response to a command from controller 52) and / or sensor 108 (e.g., detecting a process variable value via sensor 108 and transmitting that value to controller 52). Furthermore, field device 60A can execute data integrity formula 132 to generate a data integrity check result for device variable 125 by inputting the value of variable 125 and seed 123 into formula 132. Seed 123 can be any relatively unique information known to field device 160 and the intended recipient of the message (e.g., controller 52). In some cases, the data integrity check result can be calculated using additional inputs, such as sequence parameters updated each time variable 125 is updated, variable state parameters indicating the state of variable 125, etc.

[0068] When the value of device variable 125 is transmitted to controller 52 via a message, field device 60A may include a calculated data integrity check result so that controller 52 can verify the integrity of the received value. Generally, controller 52 (or any desired receiver) is configured to recalculate the data integrity check result based on a known seed 123 (also known to controller 52) and the value included in the received message. Formula 132 is constructed such that any change to any input will result in a different data integrity check result. Therefore, if the value of variable 125 (or sequence parameter or variable state parameter, if used) changes in some way during transmission, the data integrity check result calculated by controller 52 will differ from that received in the message, and it will thus know that one of the inputs (e.g., the value of variable 125) is different from the transmitted value.

[0069] Typically, controller 52 updates process variable 175 with the value of device variable 125 received from field device 60A in response to verifying the integrity of the received value. If the data integrity check result calculated by controller 52 does not match the received data integrity check result, controller 52 discards the received value instead of updating process variable 175 with the received value. Depending on the embodiment, process variable 175 may be a local variable or a system variable. Furthermore, controller 52 may include control logic 182 for performing functions as part of a safety scheme (e.g., putting one or more field devices into a safe state in response to detecting an unsafe condition). Depending on the specific configuration, control logic 182 may take into account the value of process variable 175 (and therefore may depend on device variable 125). Additional details regarding variable-wise data integrity verification are described below with reference to the method shown in Figures 6 and 7.

[0070] If needed, field device 60A can calculate and transmit data integrity check results for any desired number of variable values, and if desired, can transmit multiple data integrity check results for a single variable value (e.g., where each is intended for a different recipient). Furthermore, any suitable process control device can be configured to transmit variable values ​​in messages that implement per-variable verification of data integrity by executing data integrity formulas such as Equation 132 and seeds such as Seed 123. II. Example Protocol

[0071] Figure 3 An example layer of an example protocol stack 300 is shown, which can be utilized by the process control device described herein so that the receiving device can transmit and receive device variable values ​​in a manner that verifies the integrity of the received values ​​on a variable-by-variable basis.

[0072] Protocol stack 300 comprises five layers: Physical layer 303; Data link layer 305; Network layer 307; Transport layer 309; and Application layer 311. The protocols used by the described system may include additional or alternative layers to those described. Each layer 303-311 of protocol 300 may have a set of rules that Protocol Data Units (PDUs) or messages must conform to so that nodes on the network can correctly understand the content of the message. Each PDU at each layer may have a payload and metadata (e.g., contained in headers, trailers, preambles, etc.). Generally, the payload is the content or data of the PDU, and the metadata is "data about the data" (e.g., about format, ordering, timing, destination and source addresses, communication handshake, etc.).

[0073] Generally, each of layers 303-311 can be any suitable protocol found in the Internet Protocol suite (e.g., TCP, UDP, IP, etc.) or any suitable protocol or standard found in typical process control communication protocols, such as HART, HART-IP, WirelessHART, Ethernet / IP, Fieldbus, ControlNet, etc. In one embodiment, the messages described herein conform to the HART protocol at application layer 311, using standard HART commands, responses, and formats. In one embodiment, the described messages may conform to other protocols, such as the Open Platform Communications Federation Architecture (“OPCUA”), a machine-to-machine communication protocol for industrial automation. ALPDUs can be transmitted via any suitable NLDU. III. Example message payload

[0074] Figure 4 and 5 Example message payloads 400 and 500 are shown, each representing... Figure 3 The example message payload 352 shown includes one or more variable values ​​with corresponding data integrity verification results, enabling the receiving device to verify the integrity of the included values ​​on a variable-by-variable basis. Figure 1 Any one or more process control devices shown can be configured to transmit or receive messages including payloads formatted in a manner similar to payloads 400 and 500.

[0075] Payload 400 includes message portions 402-410. Generally, variable portions 402-406 are "variable portions," each specific to a particular variable and configured to carry the value of that particular variable. For example, variable portion 402 includes device variable value 411 (e.g., Figure 2 (The value of device variable 125 shown). If needed, section 402 may include other data related to the variable.

[0076] Integrity sections 408 and 410 include data integrity verification results corresponding to the values ​​carried in the variable sections. Each of sections 408 and 410 may include a parameter indicating the variable section corresponding to the data integrity verification result. For example, integrity section 408 includes a data integrity verification result 425 and a parameter 423 identifying the message section corresponding to the data integrity verification result 421. For example, refer to... Figure 2The data integrity check result 425 can be a value calculated via data integrity formula 132 using value 411 and seed 123 as input. Partial parameter 423 may include the value "402" (or any other suitable ID identifying part 402 or value 411) indicating that the check result 421 in part 408 corresponds to part 402 (and therefore to value 411).

[0077] Similarly, integrity section 410 may include a data integrity verification result (not shown) and a parameter indicating the section it corresponds to. For example, integrity section 410 may correspond to variable section 406 or variable section 402 (e.g., each of sections 408 / 410 corresponds to a different recipient when value 411 is intended to be received by two different recipients).

[0078] Go to Figure 5 Part of 502-510 corresponds to Figure 4 Parts 402-410 are shown in the diagram. Similarly, device variable value 514 corresponds to value 411; data integrity check result 525 corresponds to data integrity check result 425; and partial parameter 523 corresponds to partial parameter 423.

[0079] However, portions 502-510 include additional data that is not necessarily included in portions 402-410 of payload 400. For example, variable portion 502 includes (i) device variable code 511, which includes values ​​unique to the variable in question (e.g., uniquely identifying...). Figure 2 (i) Variables 125 shown in the figure; (ii) Equipment variable classification 512, including values ​​unique to the variable type (e.g., process variable; integrity variable, etc.); (iii) Equipment variable unit code 513, including values ​​unique to the unit corresponding to the variable in question (e.g., Fahrenheit, Celsius, absolute temperature, etc.); (iv) Equipment variable status 515, including values ​​of the status of the indication value 514 (e.g., good or reliable, bad or unreliable; unknown, etc.).

[0080] Furthermore, the integrity section 508 may include data related to the data integrity check result 525. For example, it may include: (i) a device variable code 521, including a value unique to the data integrity check in question; (ii) a device variable classification 522, including a value unique to the variable type (e.g., indicating that the variable in question is a data integrity check result); (iii) a section 523 identifying the message section corresponding to the data integrity check 525; (iv) a sequence parameter 524, incremented each time the value 514 is updated; (v) a data integrity check result 526, such as a CRC, included in sections 502 (i.e., the relevant section) and 508, of the data integrity check result 526 of the configuration data; and (vi) a device variable status indicating the status or reliability of the data integrity check result 525. The data integrity check result 526 of the configuration data can ensure that the check result 525 is for the intended information. For example, consider changing the configuration from Deg C to Deg F or changing the thermocouple type. According to an embodiment, this change may not be captured by the check result 525 of value 514. Therefore, for example, the verification result 526 can capture changes to the metadata associated with the variable values ​​411 / 514. IV. Example method for transmitting messages that implement data integrity verification at the variable level

[0081] Figure 6 An example method is shown for transmitting a message including variable values ​​in a manner that enables the receiving device to verify the integrity of the received values ​​on a variable-by-variable basis. Method 600 can be performed wholly or partially by any one or more suitable process control devices, such as... Figure 1 and 2 Those shown (e.g., controllers 24, 26, 50, 52, 54, or 56; or field devices 40, 42, 60, or 62) can be executed via a set of circuitry (e.g., field device 60A) permanently or semi-permanently configured to perform method 600. In one embodiment, method 600 can be embodied by an instruction set or routine set stored in memory and executable by a processor to perform the functions of method 600. Note that although the following discussion may refer to... Figure 1 The structure is the same as shown in Figure 2, but it is understood that method 600 can be implemented by any suitable process control device configured to transmit messages including process variable values ​​and results of variable-wise data integrity checks, such as those described herein.

[0082] Method 600 begins at step 605, in which a first process control device (e.g., field device 60A) detects the value of a device variable. This value can be detected via sensor measurement (e.g., flow rate, temperature, pressure, viscosity, level, light, sound, etc.) or via calculation. An example of a value detected via calculation is a diagnostic parameter related to the health status of the first process control device, or a diagnostic parameter related to the device it actuates (e.g., a valve) or the device used for measurement (e.g., a sensor).

[0083] In step 610, the first process control device (e.g., field device 60A) calculates a data integrity check result for each detection value for which data integrity is to be improved. The data integrity check result can be any suitable error detection code used to verify data integrity, such as a cyclic redundancy check (CRC), checksum, or hash.

[0084] If needed, some test values ​​may not have corresponding data integrity verification results. Data integrity verification results can be obtained through... Figure 2 The data integrity formula 132 shown is used for calculation. Generally, to calculate the data integrity verification result, the first process control device uses a detection value and a seed as inputs to formula 132. The seed can be any suitable seed known to the first process control device and the intended receiving device (e.g., controller 52). In this embodiment, the seed is unique enough to detect spoofing.

[0085] For example, the seed can be some combination of the following: a device tag for the field device 60A used by the process control system 12 and / or safety system 14; a device tag for the intended controller 52; the serial number of the field device 60A; the serial number of the controller 52; the hardware address (e.g., MAC address) of the field device 60A; the hardware address of the controller 52; the site ID of the process control environment 10; a randomly generated unique value; or some combination thereof. In the example embodiment, the seed is a combination of the device tag and the serial number of the field device 60A.

[0086] In one embodiment, the first process control device includes a sequence parameter for each detected value, which is updated each time the corresponding value is updated. This sequence parameter can be used as input to a data integrity formula, if desired.

[0087] In one embodiment, the first process control device generates a variable state for each detected value, indicating the relative reliability of the value (e.g., good, bad, unknown, etc.). This variable state can be used as input to a data integrity formula if desired.

[0088] If desired, the first process control device can calculate multiple data integrity checks for each detection value. This can be useful when multiple other process control devices receive and rely on the detection values ​​(e.g., because the detection value carried in the message might be corrupted when it arrives at one device via the first communication path, but likely not when received at another device via the second communication path). Furthermore, this can be useful if it is desired to provide a second seed for a second consumer of the data (e.g., a higher-level system with which it does not wish to share the seed for security reasons).

[0089] In step 615, the first process control device (e.g., field device 60A) encodes the message using each detection value and each corresponding data integrity check result (assuming one exists). The message can be configured according to, for example... Figure 4 and 5 The messages can be encoded using the formats of Messages 400 and 500. Messages can be encoded to include each input used for calculating data integrity. Therefore, in an embodiment where a data integrity formula is calculated for a given variable based on the variable value, the variable's sequence number, the variable's state, and a seed, the message may include the variable value, sequence number, and variable state of the given variable.

[0090] For example, the message may include a payload with multiple parts, each corresponding to a different variable (see, for example, see...). Figure 4 (See sections 402-406 shown). For each value with a data integrity check result, the message may then include an additional portion corresponding to the data integrity check result (e.g., see...). Figure 4 Parts 408 and 410 are shown in the diagram.

[0091] For illustration, the message may include first, second, and third parts corresponding to the first, second, and third variables, respectively. If it is desired to perform data integrity checks on the first and third variables, but not on the second variable (for example), the message may also include fourth and fifth parts, including the data integrity check results for the first variable (for example, in the fourth part) and the data integrity check results for the third variable (for example, in the fifth part).

[0092] The message may include modules for determining the variable values ​​or message portions corresponding to integrity sections and data integrity verification results. For example, each integrity section in the message may include a "section number" parameter, which indicates the position of the section carrying the corresponding variable value within the message. For illustration, if integrity section 408 corresponds to the variable value in section 402, then parameter 422 may be set to "402". If the message includes multiple data integrity verification results for a single detection value, the multiple integrity sections may include a "section number" parameter identifying sections with the same variable value.

[0093] In some embodiments, each message may be expected to have up to eight parts, and the "part number" in the integrity part may be set to 0-7 to indicate its corresponding variable part. If desired, the variable parts and the integrity parts may be encoded with additional and / or alternative information, such as references. Figure 5 Discussed.

[0094] In step 620, a first process control device (e.g., field device 60A) transmits a message that can be received by a second process control device (e.g., one of controllers 50-56 or 24 / 26, one of field devices 40 / 42 / 60 / 62, workstation 16, historical database, etc.). Depending on the embodiment, the first process control device may transmit the message via a wired or wireless link. Generally, the second process control device is a device configured to perform functions as part of a control scheme for a controlled process in a process control environment (e.g., plant 10). The control scheme may be a safety system scheme (e.g., executed via safety system 14) responsible for maintaining the safe operation of equipment in the environment (e.g., responsible for driving one or more process control devices in the environment in response to the detection of unstable or other potentially hazardous conditions). In embodiments, the control scheme is a process control scheme or strategy (e.g., executed via process control system 12) for controlling a process to achieve a control objective (e.g., producing a desired product or chemical (such as ethanol), generating electricity, etc.). While safety systems can be characterized as “passive” systems that intervene only when a potential unsafe condition occurs, process control systems are typically more proactive, constantly responding to process conditions and attempting to drive all aspects of the process to a desired state to achieve the desired objectives.

[0095] The first and second process control devices can be configured to transmit and receive messages via a publish / subscribe model (e.g., where the first device transmits messages periodically without prompting from the second device) or to transmit messages based on request / response messages (e.g., where the first device transmits a message in response to a request from the second device). In embodiments, each of the first and second process control devices can be configured to perform either a request / response model or a publish / subscribe model as needed.

[0096] The first and second process control devices can be configured to transmit and receive messages according to any suitable protocol that can be executed in a process control environment, assuming that such protocols can be adapted, or modified, to accommodate the variable-wise data integrity checks described herein. Example protocols that may be used by the first and second process control devices include HART, HART-IP, WirelessHART, Profibus, and FOUNDATION. TM Fieldbus, Ethernet / IP, ControlNet, DeviceNet, Modbus, OPC UA, etc.

[0097] In some cases, method 600 is executed at a rate proportional to the scan cycle (e.g., per scan cycle, every other scan cycle, etc.). Generally, a scan cycle occurs during each scan time (which can be any desired time, such as 1 millisecond, 100 milliseconds, 1 second, etc.). Typically, a scan cycle is the period during which the relevant controller collects input, runs the control algorithm, and updates the output accordingly. Therefore, in an instance where controller 52 is configured to execute a scan cycle during a given scan time, field device 60A can be configured to execute method 600 at a rate equal to the scan rate or at a faster rate (e.g., at a harmonic period relative to the scan time) (e.g., thereby providing controller 52 with the latest field device variable values).

[0098] In some cases, method 600 is executed whenever a change is detected in a relevant field device variable (e.g., a variable for which field device 60A is configured to transmit values).

[0099] If needed, method 600 can be implemented by any suitable device to transmit messages including variable(s) values ​​in a manner capable of verifying data integrity on a variable-by-variable basis. For example, in some instances, a controller (e.g., logic solvers 50-56 or process controllers 24 / 26), a workstation (remote or local to process control environment 10), a historical database, a device in an asset management system (AMS), a network device, or any other desired device that can be implemented in the process control environment can perform method 600 to transmit messages capable of verifying data integrity on a variable-by-variable basis; consequently, in embodiments, any such process control device can perform the functions described above performed by field device 60A. Similarly, a second process control device (i.e., the recipient of the transmitted message) can be any of these devices. V. Example method for receiving messages that implement data integrity verification at the variable level

[0100] Figure 7 An example method 700 is shown for receiving a message including variable values ​​in a manner capable of verifying the integrity of the received values ​​on a variable-by-variable basis. Method 700 can be performed wholly or partially by any one or more suitable process control devices, such as... Figure 1 and 2 Those shown (e.g., controllers 24, 26, 50, 52, 54, or 56; or field devices 40, 42, 60, or 62) can be executed via a set of circuitry (e.g., controller 52) permanently or semi-permanently configured to perform method 700. In embodiments, method 700 can be embodied by a set of instructions or routines stored in memory and executable by a processor to perform the functions of method 700. Note that although the following discussion may refer to... Figure 1 and 2 The structure shown describes method 700, but it is understood that method 700 can be implemented by any suitable process control device configured to receive messages including process variable values ​​and results of variable-wise data integrity checks, such as those described herein.

[0101] Method 700 can be executed to process a message transmitted by a first process control device, the message including process variable values ​​and variable-wise data integrity check results. Specifically, method 700 can be executed by a second process control device, for example... Figure 1 and 2 The controller 52 shown is shown.

[0102] The method begins at step 705, where a second process control device (e.g., controller 52) receives a message from a first process control device (e.g., field device 60A). In some instances, the second process control device may receive the message from any suitable device (field device or others) configured to transmit the message in a manner consistent with the described techniques, capable of verifying data integrity on a variable-by-variable basis. The message may be received via a wired or wireless link.

[0103] In step 710, the second process control device (e.g., controller 52) decodes the received message to identify (i) multiple candidate values ​​for a device variable and (ii) multiple data integrity check results for each candidate value. In some instances, the message may include variable values ​​for which no data integrity check result exists. That is, if desired, the message may include some combination of field device values ​​with data integrity check results and field device values ​​without data integrity check results.

[0104] Furthermore, in some cases, a message may include multiple data integrity check results for a given candidate value (e.g., where each data integrity check is intended for a different recipient of the message). In such instances, the second process control device must determine which data integrity check result corresponds to the given candidate value. In some embodiments, the second process control device is pre-configured to assume that one of the data integrity check results is assigned to it (e.g., the data integrity check result of the second process control device may always be in the same relative position or section of the message). In some embodiments, the message includes parameters for each data integrity check result to identify its corresponding receiving device (e.g., parameters for each data integrity check result identifying the intended receiving device, such as a tag, serial number, unique identifier, IP address, etc.).

[0105] When decoding the message, the second process control device (e.g., controller 52) can analyze the message to determine which parts of the message are variable parts (i.e., the parts carrying device variable values) and which parts are integrity parts (i.e., the parts carrying data integrity verification results for the device variable values). For this purpose, each part of the message may include a parameter or field indicating its type (e.g., a device variable code, indicating whether a part is a variable part, an integrity part, etc.). The second process control device then analyzes the integrity parts to determine the variable parts corresponding to them. This may involve analyzing a "part number" parameter in each integrity part, which indicates the part in the message corresponding to the integrity part.

[0106] In step 715, the second process control device (e.g., controller 52) calculates a second data integrity check result for the candidate value. For example, refer to Figure 2 and 4 The controller 52 can identify the candidate value 411 in section 402 and the corresponding data integrity check result 421 in section 408. It can then use the value 411 and a predetermined seed as input to formula 132 to calculate a second data integrity check result. The second integrity check result can then be stored permanently or temporarily. Similarly, the second process control device can calculate a second data integrity check result for each of the other data integrity check results included in the message.

[0107] In step 720, the second process control device (e.g., controller 52) selects first and second data integrity verification results to be compared for a given candidate value. For example, continuing the previous example, controller 52 can select value 411 and the data integrity verification result 421 corresponding to value 411.

[0108] In step 725, the second process control device (e.g., controller 52) compares the first and second data integrity check results. For example, for value 411, controller 52 may compare the received data integrity check result 421 with the data integrity check result calculated by controller 52 using value 411 and a seed as input. If value 411 has not changed since data integrity check result 421, the first and second data integrity check results should match. If value 411 has changed (or if the sequence number has changed in an embodiment where the integrity check result is calculated using a sequence number), the first and second integrity check results will not match.

[0109] In step 730, if the first and second data integrity check results match (indicating that the candidate value has not changed since the calculation of the first data integrity check result, and therefore indicating that the received candidate value is the detection value that the field device 60A intends to send), the second process control device (e.g., controller 52) proceeds to step 740; if they do not match (indicating that value 411 is somewhat different from the original value transmitted by the field device 60A), then proceeds to step 735.

[0110] In step 735, in response to determining that a data integrity check result mismatch exists, the second process control device (e.g., controller 52) discards the given candidate value corresponding to the first and second data integrity check results. That is, it continues without updating the corresponding process variable using value 411. The second process control device and the larger control or safety system can continue operating, assuming that the value of the variable in question is whatever value it had before receiving the message. In some instances, the second process control device may generate an alarm (e.g., via a workstation) in response to detecting a mismatch (or in response to receiving a certain number of mismatches during a specific time period or during a certain number of messages). In some cases, the second process control device may determine that continuing operation in this situation is too risky and may send a message to the first field device (e.g., field device 60A) to put it into a safe state (e.g., by opening or closing a valve).

[0111] In step 740, in response to determining that a data integrity check result match exists, the second process control device (e.g., controller 52) updates the process variable corresponding to the field device variable using the candidate value.

[0112] For example, before executing method 700, valve CV001 may be in a 25% opening position. In the received message, the variable under discussion could be the valve position of CV001, and the candidate value in the message could be 50% opening (indicating a change in valve position). In response to detecting a data integrity mismatch, controller 52 can discard the candidate value and continue operation, for example, under the assumption that the valve is still 25% open, the valve position is unknown, etc.

[0113] However, in response to verifying the integrity of the received value, controller 52 may update the system variable representing the valve position to 50%. Therefore, controller 52, control system 12, and / or safety system 14 may operate based on this updated control valve position (e.g., execute control routines). In some embodiments, the updated process variable is a system variable accessible by components of control system 12 and / or safety system 14. In some embodiments, the updated process variable is a local variable at controller 52.

[0114] In step 745, the second process control device (e.g., controller 52) determines whether the received message includes additional candidate values ​​that have not yet been analyzed in steps 725 and 730 regarding their data integrity verification results. If additional candidate values ​​exist in the message, the controller proceeds to step 720; otherwise, it proceeds to step 750. For example, refer to... Figure 4The controller 52 can determine that the variable portion 406 of message 400 also has an integrity portion (e.g., portion 408). As a result, the controller 52 can proceed to step 720 to analyze the integrity of the values ​​included in the variable portion 406.

[0115] In step 750, the second process control device (e.g., controller 52) completes the analysis of the received message and proceeds to the next task (e.g., processing new messages received during future scans).

[0116] In some instances, controller 52 (or any other device performing method 700) is configured to perform a scan cycle at the beginning of a predetermined scan period or time. In this case, method 600 is performed by controller 52 in each scan cycle. Note that method 600 can be performed by any suitable device configured to receive messages and verify the integrity of included variable values ​​on a variable-by-variable basis. For example, in some instances, a smart field device can perform method 600.

[0117] In addition, as referenced Figure 6 The first and second process control devices discussed can be configured to send and receive messages via a publish / subscribe model (e.g., where the first device periodically sends messages without prompting from the second device) or to send messages based on request / response messages (e.g., where the first device sends messages in response to a request from the second device). In embodiments, each of the first and second process control devices can be configured to perform either a request / response model or a publish / subscribe model as needed. Furthermore, as referenced... Figure 6 As indicated, the first and second process control devices can be configured to transmit and receive messages according to any suitable protocol that can be executed in the process control environment, assuming that such protocols can be adapted or modified to accommodate the variable-wise data integrity verification described herein. VI. Other precautions

[0118] In one embodiment, the residual error of a single message segment (sometimes called a SLOT) can be calculated. Depending on the embodiment, the following assumptions may be used (but are not mandatory): the limitation of shielded twisted-pair cabling used for the data path for communication limits the worst-case bit error rate to 10⁻⁴; the 0x9eb² 16-bit CRC (CRC-16-DNP) polynomial has a Hamming distance of 6 for messages less than 135 bits (or 16 bytes); even errors exceeding the Hamming distance have negligible impact on the result (detection of sporadic errors); data words are 6 bytes–48 bits (floating point + status + sequence number); codewords are 8 bytes–64 bits (data word + 2-byte CRC); for a given BER, the probability of a 6-bit error in a 64-bit codeword is 7.45408. -17 Under these assumptions, for a 0x9eb2 16-bit CRC polynomial, the data word size could have 2051 possible 6-bit errors. Under these assumptions, the probability of not detecting a 6-bit error is 2.83214. -24 Assuming a transmission rate of 40Hz, PFH could be equal to 4.07828. -19 .

[0119] In some embodiments, implementations of the described system may include secure network connectivity and user-based or role-based authorization. For example, HART-IP supports establishing secure connections using TLS and DTLS. Role-based authorization may be required because a “user” could be a controller or a security application. In some embodiments, the described system can operate without user / role-based authorization.

[0120] The following describes the various aspects, devices, systems, components, equipment, methods, and techniques used for managing discrete process control elements (e.g., discrete devices, discrete communication channels, discrete signals, etc.) and for the discrete elements in the intelligent commissioning control process 5.

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

[0122] Referring specifically to methods 600 and 700, the functions described can be wholly or partially derived from... Figure 1 The methods described herein may be performed by devices, circuits, or routines of system 10 as shown in Figure 2. Each of the described methods may be embodied by a set of circuits that are permanently or semi-permanently configured (e.g., ASIC or FPGA) to perform the logical function of the corresponding method or at least temporarily configured (e.g., one or more processors and instruction sets or routine sets, representing the logical function, stored in memory) to perform the logical function of the corresponding method.

[0123] Throughout this specification, multiple instances may perform components, operations, or structures described as a single instance. Although the various operations of one or more methods are illustrated and described as separate operations, in some embodiments one or more of the various operations may be performed simultaneously.

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

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

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

[0127] Furthermore, the terms "a" or "an" are used to describe elements and components in the embodiments described herein. This description, as well as the following claims, should be understood to include one or at least one. The singular also includes the plural, unless it is obvious otherwise.

[0128] In various embodiments, the hardware system described herein can be implemented mechanically or electronically. For example, the hardware system may include permanently configured dedicated circuitry or logic (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)) to perform certain operations. The hardware system may also include programmable logic or circuitry temporarily configured by software to perform certain operations (e.g., contained within a general-purpose processor or other programmable processor). It should be understood that the decision to implement the hardware system mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., via software configuration) may be driven by cost and time considerations.

Claims

1. A method for transmitting a message including values ​​of device variables, enabling the integrity of the values ​​to be verified on a variable-by-variable basis, the method comprising: The first process control device detects the value of the device variable in the process control environment used to control the process; The first process control device performs a data integrity calculation by using the detection value and the seed as input to calculate the first data integrity verification result. The seed is any relatively unique information known to the first process control device and the second process control device. The message is encoded to include the detection value and the first data integrity verification result for the detection value; as well as The message is transmitted such that it can be received by the second process control device, which is configured to: (i) receive the message; (ii) decode the message to identify in the message: a candidate value of the device variable; the first data integrity check result of the device variable; (iii) perform a second data integrity calculation by using the candidate value and the seed as input to calculate a second data integrity check result; (iv) at the second process control device, update or not update the process variable mapped to the device variable using the candidate value based on whether the first data integrity check result and the second data integrity check result match. And (v) to perform functions as part of the control scheme of the process based on the process variables.

2. The method according to claim 1, wherein, The second process control equipment is a field device.

3. The method according to claim 1, wherein, The second process control device is a controller.

4. The method according to claim 3, wherein, The controller is a logic solver for a safety system, and the control scheme is a safety system scheme for determining when to drive one or more field devices coupled to the logic solver into a safe state.

5. The method according to claim 3, wherein, The controller is a process controller configured to control the process of the process control system, and the control scheme is a process control scheme for the process control system.

6. The method according to claim 1, wherein, The first process control device is a field device, and the device variable is a field device variable.

7. The method according to claim 1, wherein, The first process control device is a controller.

8. The method according to claim 1, wherein, The message is encoded to include multiple detection values, each with a data integrity verification result. The method further includes: The second detected value of the second device variable; The third data integrity verification result is calculated by performing the data integrity calculation using the second detection value and the seed as input. Encoding the message further includes: encoding the message to include the second detection value and the third data integrity verification result for the second detection value; and The second process control device is further configured as follows: (i) Decode the message to identify in the message: a second candidate value of the second device variable; the third data integrity verification result of the second device variable; (ii) The fourth data integrity verification result is calculated by performing a fourth data integrity calculation using the second candidate value and the seed as input; (iii) At the second process control device, based on whether the third data integrity check result and the fourth data integrity check result match, the second process variable mapped to the second device variable is updated or not updated using the second candidate value; and (iv) Perform the function as part of the control scheme of the process according to the second process variable.

9. The method according to claim 8, wherein, Encoding the message includes encoding the message such that the message comprises a plurality of message portions, the plurality of message portions comprising: The first message section includes the detected value; The second message section includes the second detection value; The third message portion includes the first data integrity verification result and a parameter indicating which of the plurality of message portions the first data integrity verification result corresponds to; The fourth message portion includes the third data integrity verification result and a parameter indicating which of the plurality of message portions the third data integrity verification result corresponds to.

10. The method according to claim 1, further comprising: An incrementing sequence parameter is used to indicate an update to the device variable, wherein the sequence parameter is configured to be updated each time the device variable is updated; The calculation of the first data integrity verification result further includes: using the sequence parameter as one of the inputs for the data integrity calculation; Encoding the message further includes encoding the message to include the sequence parameters.

11. The method of claim 10, further comprising: Detect the variable status of the device variables; The calculation of the first data integrity verification result further includes: using the variable state as one of the inputs for the data integrity calculation; Encoding the message further includes encoding the message to include the variable state.

12. The method according to claim 1, wherein, The first process control device is configured to calculate a third data integrity verification result for the detected value, such that a third process control device receiving the message can verify the integrity of the detected value via the third data integrity verification result, wherein the method further includes: The first process control device performs the data integrity calculation by using the detection value and the second seed as input to calculate the third data integrity verification result; Encoding the message further includes: encoding the message to include the third data integrity verification result for the detected value; and The transmission of the message includes: transmitting the message so that it can be received by the third process control device, wherein the third process control device is configured to: (i) receive the message; (ii) perform a fourth data integrity calculation by using the candidate value and the second seed as input to calculate a fourth data integrity verification result; and (iii) at the third process control device, update or not update the process variable mapped to the device variable using the candidate value based on whether the third data integrity verification result and the fourth data integrity verification result match.

13. The method according to claim 1, wherein, The seed is a value formed by combining the serial number of the first process control device and the tag of the first process control device, wherein the tag is an identifier that enables one or more other devices in the process control environment to address the first process control device.

14. A system for transmitting a message including values ​​of process variables, the values ​​of which can be authenticated at the parameter level, the system comprising: A first process control device is configured to be communicatively coupled to one or more other process control devices in an input / output (I / O) network of a process control environment for controlling a process, the first process control device comprising: (A) A communication interface configured to couple the first process control device to the one or more other process control devices; and (B) A set of circuits communicatively coupled to the communication interface and configured as follows: The detected value of the variable detected by the detection equipment; A first data integrity verification result is calculated by performing a data integrity calculation using the detected value and the seed as input, wherein the seed is any relatively unique information known to the first process control device and the second process control device; The message is encoded to include the detection value and the first data integrity verification result for the detection value; and The message is transmitted to the second process control device via the communication interface. The second process control device is configured to: (i) receive the message; (ii) decode the message to identify in the message: a candidate value of the device variable; the first data integrity check result of the device variable; (iii) perform a second data integrity calculation by using the candidate value and the seed as input to calculate a second data integrity check result; (iv) at the second process control device, update or not update the process variable mapped to the device variable using the candidate value based on whether the first data integrity check result and the second data integrity check result match; and (v) perform a function as part of the control scheme of the process according to the process variable.

15. The system according to claim 14, wherein, The second process control device is a controller.

16. The system according to claim 14, wherein, The first process control device is a field device, and the device variable is a field device variable.

17. The system according to claim 14, wherein, The message is encoded to include multiple detection values, each with a data integrity verification result, wherein the set of circuits is further configured as follows: The second detected value of the second device variable; The third data integrity verification result is calculated by performing the data integrity calculation using the second detection value and the seed as input. Encoding the message further includes: encoding the message to include the second detection value and the third data integrity verification result for the second detection value; and The second process control device is further configured as follows: (i) Decode the message to identify in the message: a second candidate value of the second device variable; the third data integrity verification result of the second device variable; (ii) The fourth data integrity verification result is calculated by performing a fourth data integrity calculation using the second candidate value and the seed as input; (iii) At the second process control device, based on whether the third data integrity check result and the fourth data integrity check result match, the second candidate value is used to update or not update the second process variable mapped to the second device variable; and (iv) Perform the function as part of the control scheme of the process according to the second process variable.

18. The system according to claim 17, wherein, The circuitry is further configured to encode the message such that the message includes multiple message portions, the multiple message portions including: The first message section includes the detected value; The second message section includes the second detection value; The third message portion includes the first data integrity verification result and a parameter indicating which of the plurality of message portions the first data integrity verification result corresponds to; The fourth message section includes the third data integrity verification result and a parameter indicating which of the multiple message sections the third data integrity verification result corresponds to.

19. The system according to claim 14, wherein, The set of circuits is further configured as follows: An incrementing sequence parameter is used to indicate an update to the device variable, wherein the sequence parameter is configured to be updated each time the device variable is updated; The calculation of the first data integrity verification result further includes: using the sequence parameter as one of the inputs for the data integrity calculation; Encoding the message further includes encoding the message to include the sequence parameters.

20. The system according to claim 19, wherein, The set of circuits is further configured as follows: Detect the variable status of the device variables; The calculation of the first data integrity verification result further includes: using the variable state as one of the inputs for the data integrity calculation; Encoding the message further includes encoding the message to include the variable state.

21. The system according to claim 14, wherein, The set of circuits is further configured to calculate multiple data integrity verification results for different recipients of the message, such that the third process control device receiving the message receives a third data integrity verification result, wherein the set of circuits is configured to: The third data integrity verification result is calculated by performing the data integrity calculation using the detected value and the second seed as input. Encoding the message further includes: encoding the message to include the third data integrity verification result for the detection value; and The transmission of the message includes: transmitting the message so that it can be received by the third process control device, wherein the third process control device is configured to: (i) receive the message; (ii) perform a fourth data integrity calculation by using the candidate value and the second seed as input to calculate a fourth data integrity verification result; and (iii) at the third process control device, update or not update the process variable mapped to the device variable using the candidate value based on whether the third data integrity verification result and the fourth data integrity verification result match.

22. The system according to claim 14, wherein, The seed is a value formed by combining the serial number of the first process control device and the tag of the first process control device, wherein the tag is an identifier that enables one or more other devices in the process control environment to address the first process control device.

23. A method for verifying the integrity of device variable values ​​included in messages from process control devices, the method comprising: At the second process control device, messages transmitted by the first process control device are received in a process control environment used to control the process. The message is decoded to identify in the message: (i) candidate values ​​of device variables, and (ii) the first data integrity check result of the device variables; The second data integrity verification result is calculated by performing a second data integrity calculation using the candidate value and the seed as input, wherein the seed is any relatively unique information known to the first process control device and the second process control device; The second data integrity verification result is compared with the first data integrity verification result to determine whether the second data integrity verification result matches the first data integrity verification result, thereby determining whether the candidate value matches the detection value used to calculate the first data integrity verification result; By discarding the candidate values, a response is made to determine that the second data integrity check result does not match the first data integrity check result, so that the process variable mapped to the device variable retains its previous value. The process variable is updated at the second process control device using the candidate value to respond to determining that the second data integrity check result matches the first data integrity check result; as well as The process variables are used to perform functions that are part of the control scheme for the process.

24. The method according to claim 23, wherein, The second process control device is a controller.

25. The method according to claim 24, wherein, The controller is a logic solver for a safety system, and the control scheme is a safety system scheme for determining when to drive one or more field devices coupled to the logic solver into a safe state.

26. The method according to claim 23, wherein, The device variable is a first device variable and wherein decoding the message includes decoding the message to identify within the message: The first message portion includes the candidate values ​​of the first device variable; The second message section includes candidate values ​​for the second device variable; The third message portion includes (i) the result of the first data integrity check and (ii) a parameter indicating which of a plurality of message portions the first data integrity check result corresponds to; and The fourth message portion includes (i) a third data integrity check result for the candidate value of the second device variable; and (ii) a parameter indicating which of a plurality of message portions the third data integrity check result corresponds to.

27. The method according to claim 23, wherein, Decoding the message also includes: Identify the sequence parameters that are configured to be updated each time the device variable is updated; and The calculation of the second data integrity verification result also includes using the sequence parameter as one of the inputs for the data integrity calculation.

28. The method according to claim 23, wherein, The seed is a value that includes the serial number of the first process control device.

29. A system for verifying the integrity of device variable values ​​included in messages from process control devices, the system comprising: A second process control device is configured to communicatively couple to a first process control device in a process control environment, the second process control device comprising: (A) A communication interface configured to communicatively couple the second process control device to the first process control device; and (B) A set of circuits communicatively coupled to the communication interface and configured as follows: Receive messages transmitted by the first process control device via the communication interface; The message is decoded to identify in the message: (i) candidate values ​​of device variables, and (ii) the first data integrity check result of the device variables; The second data integrity verification result is calculated by performing a second data integrity calculation using the candidate value and the seed as input, wherein the seed is any relatively unique information known to the first process control device and the second process control device; The second data integrity verification result is compared with the first data integrity verification result to determine whether the second data integrity verification result matches the first data integrity verification result, thereby determining whether the candidate value matches the detection value used to calculate the first data integrity verification result; By discarding the candidate values, a response is made to determine that the second data integrity check result does not match the first data integrity check result, so that the process variable mapped to the device variable retains its previous value. By updating the process variable using the candidate values, a response is made to determine whether the second data integrity check result matches the first data integrity check result; and The process variables are used to perform functions that are part of the control scheme for the process.

30. The system according to claim 29, wherein, The second process control device is a controller.

31. The system according to claim 30, wherein, The controller is a process controller configured to control the process of the process control system, and the control scheme is a process control scheme for the process control system.

32. The system according to claim 29, wherein, The device variable is a first device variable and wherein decoding the message includes decoding the message to identify within the message: The first message portion includes the candidate values ​​of the first device variable; The second message section includes candidate values ​​for the second device variable; The third message portion includes (i) the result of the first data integrity check and (ii) a parameter indicating which of a plurality of message portions the first data integrity check result corresponds to; and The fourth message portion includes (i) a third data integrity check result for the candidate value of the second device variable; and (ii) a parameter indicating which of the plurality of message portions the third data integrity check result corresponds to.

33. The system according to claim 29, wherein, The set of circuits is further configured as follows: Identify the sequence parameters that are configured to be updated each time the device variable is updated; and The calculation of the second data integrity verification result also includes using the sequence parameter as one of the inputs for the data integrity calculation.

34. The system according to claim 29, wherein, The seed is a value that includes the serial number of the first process control device.

Images