Variable-Level Consistency Check of Communication in a Process Control Environment

Abstract

To provide a method enabling a receiving device to verify the consistency of a received value for each variable, and a process control device to transmit or receive a device variable value.SOLUTION: For facilitating verification of consistency, a variable of an arbitrary number in a message can be subjected to data consistency check within the message. For each received value to be subjected to data consistency check, a receiving device computes inherent data consistency check on the basis of the received value and a seed value (known by both a transmitting device and the receiving device), compares the data consistency check with received data consistency check, and verifies whether the received value has been altered while being communicated.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure generally relates to verifying communication integrity in a process control environment, and more specifically, to verifying the integrity of variable values (such as those used in safety systems) in such communications on a per-variable basis in order to improve the reliability and trustworthiness of the variable values of a device that receives the communication.

Background Art

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

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

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

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

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

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

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

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

[0010] Furthermore, in many processes, when problems occur that can pose significant risks within the plant, such as the leakage of harmful chemicals or explosions, a safety system (sometimes referred to as a "safety instrumented system" or "SIS") is provided to detect critical safety issues within the process plant and automatically perform actions such as closing valves, cutting off the power to devices, and switching the flow within the plant. What the safety system or SIS must do (functional requirements) and how well it must perform (safety integrity requirements) can be determined from hazard and operability studies (HAZOP), layer of protection analysis (LOPA), risk graphs, etc. Examples of techniques are described in IEC61511 and IEC61508. During the design, construction, installation, and operation of the safety system or SIS, safety personnel typically verify that these requirements are met. The functional requirements can be verified through design reviews such as failure mode, effects, and criticality analysis (FMECA) and various types of tests (e.g., factory acceptance tests, site acceptance tests, and periodic functional tests).

[0011] Generally, a safety system or SIS is designed to perform "specific control functions" to achieve fail-safe operation or maintain the safe operation of the process when unacceptable or dangerous conditions occur. Usually, the safety system is relatively independent from other control systems to ensure that the functions of the safety system are not impaired. The safety system typically consists of the same types of control elements (including sensors, logic solvers or controllers, actuators, and other control equipment) as the basic process control system (BPCS). However, in conventional implementations, the control elements of the safety system are dedicated only to the proper functioning of the safety system (e.g., not for the proper control of the process controlled by the control system).

[0012] Generally, a "Safety Instrumented Function" or "SIF" is a specific set of equipment within a safety system aimed at reducing risks associated with a particular hazard, and can be considered or referred to as a safety system control loop or "safety loop". The SIF aims to (1) automatically bring an industrial process to a safe state if a specified condition is violated, (2) enable the process to proceed in a safe manner if the specified conditions allow (permissive function), or (3) take measures to mitigate the effects of industrial hazards. The SIF is usually implemented as part of an overall risk reduction strategy aimed at eliminating the possibility of previously identified safety, health, and environmental (SH&E) events, which can range from minor equipment damage to events involving uncontrolled catastrophic releases of energy and / or materials.

[0013] Typically, each SIF or safety loop is assigned a specific level of protection defined by a "Safety Integrity Level" or "SIL" (1, 2, 3, or 4) using one of the methods defined in IEC61508 / 61511 as "risk graph", "risk matrix", or LOPA. The assignment of SIL is a practice in risk analysis where the risk associated with a particular hazard that is intended to be protected by the SIF is calculated without the beneficial risk reduction effect of the SIF. The unmitigated risk is then compared to an acceptable risk target. If the unmitigated risk is higher than the acceptable risk, the difference between the unmitigated risk and the acceptable risk needs to be addressed through the risk reduction of the SIF. This required amount of risk reduction correlates with the SIL target. In essence, each digit of the required risk reduction correlates with an increase in one of the required SIL numbers. In a typical example, SIL-1 represents a maximum risk reduction of 100 times, SIL-2 represents a maximum risk reduction of 1000 times, SIL-3 represents a maximum risk reduction of 10,000 times, and SIL-4 represents a maximum risk reduction of 100,000 times.

[0014] The IEC 61508 standard of the International Electrotechnical Commission (IEC) defines SIL using requirements that are classified into two major categories: hardware safety integrity and systematic safety integrity. A device or system typically needs to meet the requirements of both categories to achieve a specific SIL. The SIL requirements regarding hardware safety integrity are based on the probabilistic analysis of the device. To achieve a specific SIL, a device typically needs to meet the target of the maximum probability of a dangerous failure and the ratio of the minimum safe failures. Usually, the concept of "dangerous failure" is defined for the system in question and is usually defined in the form of requirement constraints whose integrity is verified throughout the system development. The actual targets required vary depending on the likelihood of demand, the complexity of the device, and the type of redundancy used.

[0015] Regarding communication, the IEC 61508 standard states that safe communication must not exceed 1% of the allowable probability of a dangerous failure per hour of the desired SIL. To be acceptable for use in SIL3 applications, the likelihood of a dangerous failure due to safe communication must be less than 10-9 per hour. That is, the function of verifying the integrity of specific information received via communication can have a significant impact on whether a safety system can rely on the information in a manner compliant with general safety standards. In other words, without the function of verifying information integrity, the expected error rate associated with communication may exceed the acceptable threshold, making the information unusable in a safety system.

[0016] As described above, a safety system typically includes, separately from a process control controller connected to safety field devices via individual buses or communication lines arranged within a process plant, one or more individual logic solvers or controllers (sometimes referred to as "safety controllers"). The safety controller uses safety field devices to detect process conditions related to critical events, such as the positions of some safety switches or shut-off valves, overflows or underflows during the process, the operation of important power generation or control devices, the operation of fault detection devices, etc., thereby detecting an "event" representing an abnormal state within the process plant. When an event is detected, the safety controller executes some action to limit the adverse effects of the event, such as sending commands to close one or more valves, deactivate or turn off one or more devices, cut off power from a section of the plant, etc.

[0017] It should be noted that this background description provides a context that facilitates understanding and recognition of the following detailed description. The research of the inventors named herein, to the extent described in this section of the background art, (as well as aspects of the background art description that may not be considered prior art at the time of filing in another way) is not admitted as prior art to this disclosure, either expressly or implicitly. SUMMARY OF THE INVENTION

[0018] The methods and systems described enable a process control device to send and receive device variable values in a way that allows a receiving device to verify the integrity of received values for each variable.

[0019] In one embodiment, a method for sending a message that includes a value for a device variable includes sending the message such that the integrity of the value can be verified for each variable. The method includes detecting a detected value for the device variable by a first process control device within a process control environment for controlling a process, performing a first data integrity check by the process control device by using the detected value and a seed as inputs to perform a data integrity calculation, encoding the message to include the detected value and the first data integrity check for the detected value, or sending the message, and may include any one or more of the foregoing. Sending the message may include sending a message that is receivable by a second process control device configured to (i) receive the message, (ii) calculate a second data integrity check for a candidate value within the message for the device variable, (iii) update, or not update, a process variable mapped to the device variable with the candidate value based on whether the first and second data integrity checks match in the second process control device, and (iv) implement a function as part of a control scheme for the process according to the process variable.

[0020] In one embodiment, the system is configured to send a message that includes values for process variables that can be authenticated at the parameter or variable level (e.g., for each variable). The system can include a first process control device configured to be communicatively coupled to one or more other process control devices within an input / output (I / O) network of a process control environment for controlling the process. The first process control device can 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 circuits communicatively coupled to the communication interface. The set of circuits is configured to detect a detected value for a device variable, calculate a first data integrity check by performing a data integrity calculation using the detected value and a seed as inputs, encode a message to include the detected value and the first data integrity check for the detected value, and 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 (i) receive the message, (ii) calculate a second data integrity check for a candidate value within the message for the device variable, (iii) update, or not update, a process variable mapped to the device variable with the candidate value based on whether the first and second data integrity checks match in the second process control device, or (iv) implement a function as part of a control scheme for the process according to the process variable.

[0021] In one embodiment, a method for verifying the integrity of device variable values included in a message from a process control device may be implemented. This method includes: (1) receiving, at a second process control device within a process control environment for controlling a process, a message transmitted by a first process control device; (2) decrypting the message to identify, within the message, (i) a candidate value for a device variable and (ii) a first data integrity check for the device variable; (3) calculating a second data integrity check by performing a second data integrity calculation using the candidate value and a seed as inputs; (4) comparing the second data integrity check with the first data integrity check to determine whether the second data integrity check matches the first data integrity check, thereby determining whether the candidate value matches a detected value used in the calculation of the first data integrity check; (5) discarding the candidate value so that a process variable mapped to the device variable maintains a previous value, in response to a determination that the second data integrity check does not match the first data integrity check; (6) updating the process variable with the candidate value at the second process control device, in response to a determination that the second data integrity check matches the first data integrity check; and (7) implementing a function as part of a control scheme for the process according to the process variable. The method may include any one or more of these steps.

[0022] In one 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 be communicatively coupled to a first process control device in a process control environment. The second process control device may include any one or more of (A) a communication interface configured to communicatively couple the second process control device to the first process control device, or (B) a set of circuits communicatively coupled to the communication interface. The set of circuits is configured to receive, via the communication interface, a message transmitted by the first process control device, decode the message to identify, within the message, (i) a candidate value for a device variable and (ii) a first data integrity check for the device variable, calculate a second data integrity check by performing a second data integrity calculation using the candidate value and a seed as inputs, compare the second data integrity check with the first data integrity check to determine whether the second data integrity check matches the first data integrity check, thereby determining whether the candidate value matches a detected value used in the calculation of the first data integrity check, discard the candidate value such that a process variable mapped to the device variable maintains a previous value in response to a determination that the second data integrity check does not match the first data integrity check, update the process variable with the candidate value in response to a determination that the second data integrity check matches the first data integrity check, and implement a function as part of a control scheme for the process according to the process variable.

Brief Description of the Drawings

[0023]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

[0024] The described method and system enable a receiving device to verify the integrity of received values for each variable, and enable a process control device to send and receive device variable values. To facilitate integrity verification, any desired number of variables within a message can perform a data integrity check within the message. 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 sending device and the receiving device). For each process variable value where there is a discrepancy between the integrity checks of the received data and the calculated data, the receiving device can consider the received value not to match the original sent value (and thus can discard the received value). On the other hand, when the integrity of the received data and the calculated data checks for a match of a particular device variable, the receiving device can verify the integrity of the received value (i.e., verify that it matches the original sent value). As a result, the receiving device can confidently act on the received value (e.g., update a local or system-wide process variable corresponding to the device variable, implement control based on the received value, etc.). In contrast, to the extent that conventional systems enable verification of data integrity, they typically verify on a packet-based or message-based basis. In such systems, if the data within a message is altered, the entire message cannot be verified. Thus, if a single device variable value (or any other data) is corrupted after transmission, the receiving device must discard the entire message (or proceed with values for which integrity cannot be verified).

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

[0026] In any case, various techniques, systems, and methods are considered below with reference to FIGS. 1 - 7.

[0027] I. Exemplary Process Control Environment FIG. 1 shows a process plant 10 that can be configured (if desired) such that each of the shown safety controller, process controller, and field devices transmits and receives messages containing variable values in a manner that enables the receiving device to verify the integrity of the received value for each variable. This improvement in verifying data integrity for each variable is particularly beneficial for safety systems (such as those shown in FIG. 1), as it allows communication that transports variable values, which would otherwise be error - prone in the implementation of safety systems, to be relied upon.

[0028] As used herein, a "process control device" is any device configured to be implemented in a process plant 10 and to transmit or receive messages that carry process variables according to one or more protocols implemented in the process plant 10 such that the messages are received, decoded, and acted upon by one or more devices within the process plant 10.

[0029] As shown, process plant 10 includes a process control system 12 integrated with a safety system 14 (shown in dashed lines), which generally monitors and overrides the control provided by process control system 12 to maximize the likely safe operation of process plant 10 and operates as a safety instrumented system (SIS).

[0030] A. Exemplary Components of an Exemplary Process Control System and an Exemplary Safety System At a high level, plant 10 includes a field environment (e.g., the components within nodes 18 and 20 shown in FIG. 1) that includes process control devices (e.g., field devices, controllers, and I / O devices) that are typically located, positioned, or installed in the area where the controlled process is measured and controlled, as well as a backend environment that can include components separated or removed from the field environment (e.g., office environment, remote environment, etc.), such as components 21 and 16 shown in FIG. 1.

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

[0032] Generally speaking, as used herein, unless otherwise specified, the term "network" refers to a collection of nodes (e.g., devices or systems capable of transmitting, receiving, or forwarding information) and links connected to enable long-distance communication between the nodes. Depending on the embodiment (unless otherwise specified), each of the described networks can include a dedicated router, switch, or hub responsible for directing traffic between the nodes, and optionally, a dedicated device responsible for network configuration and management. Some or all of the nodes within the described networks can also be adapted to function as routers to direct traffic transmitted between other network devices. The nodes of the described networks can be interconnected in a wired or wireless manner, and the network devices can have different routing and forwarding capabilities.

[0033] Generally speaking, each of nodes 18 and 20 of process plant 10 includes both a process control system device and a safety system device connected together via a bus structure that can be provided on a backplane to which different devices are attached. Node 18 is shown in FIG. 1 as including a process controller 24 (which can be a redundant pair of controllers), as well as one or more process control system input / output (I / O) devices 28, 30, and 32. Node 20 is shown as including a process controller 26 (which can be a redundant pair of controllers), as well as 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 shown as field devices 40 and 42 in FIG. 1. The process controllers 24 and 26, the I / O devices 28 - 36, and the controller field devices 40 and 42 generally constitute the process control system 12 of FIG. 1.

[0034] One or more of the field devices 40, 42, 60, and 62 can be an actuator for a device such as a valve and can respond to commands received from a controller to which it is coupled (e.g., configured to operate the valve to open and close it in response to a command from the controller). Similarly, one or more of the field devices 40, 42, 60, and 62 can be a transmitter configured to detect measurement values (e.g., flow rate, temperature, pressure, etc.) via a sensor and transmit the measurement values to the controller. One or more of the field devices can be a "smart" field device configured to transmit one or more "secondary" variable values other than the primary process variable that the field device is configured to drive or measure. For example, in a HART implementation, the primary variable can be transmitted or received by the field device via a 4 - 20 mA signal, and one or more secondary variables can be transmitted or received via a digital signal superimposed on the 4 - 20 mA signal.

[0035] Generally speaking, a "field device variable" is a variable within a field device configured to be detected (e.g., via sensor measurement or calculation) or set (e.g., in response to a message received from a controller). In a typical implementation, the associated process control system or safety system of which the field device variable is a part includes one or more process variables mapped to the field device variable (e.g., via the configuration system 80). More broadly, when a "device variable" is considered with respect to a particular device, this generally refers to a variable that is detected, calculated, set, updated, etc. by the particular device.

[0036] Node 18 includes one or more safety system logic solvers 50, 52, while node 20 includes safety system logic solvers 54 and 56. Each of the logic solvers 50 - 56 executes a safety logic module 58 stored in memory, provides control signals to, and / or receives signals from, safety system field devices 60 and 62, and is an I / O device having a processor 57 that is communicatively connected to do so.

[0037] Generally speaking, as used herein, the terms "memory" or "memory device" refer to a system or device that includes a computer-readable medium or media ("CRM"). "CRM" refers to media (s) accessible by a related computing system for placing, holding, or retrieving information (e.g., data, computer-readable instructions, program modules, applications, routines, etc.). It should be noted that "CRM" means a medium that is essentially non-transitory and does not refer to intangible transient signals such as radio waves. The CRM of the memory described can be implemented in any technology, device, or group of devices that are included within or communicate with the related computing system. The CRM of the memory described can include volatile or non-volatile media, and removable or non-removable media.

[0038] In any case, each of nodes 18 and 20 includes at least one message propagation device (MPD) 70 or 72 communicatively coupled to each other via a ring-type bus connection 74. The safety system logic solvers 50 - 56, the safety system field devices 60 and 62, the MPDs 70 and 72, and the bus 74 generally constitute the safety system 14 of FIG. 1.

[0039] In some embodiments, the safety system field devices 60 and 62 can be field devices that are specially designed for the implementation of a safety system rather than typical process control operations. On the other hand, in some embodiments, the safety system field devices 40 and 60 can be field devices that can be implemented in a typical process control system (e.g., system 12), and for example, can function simultaneously as field devices in both the process control system 12 and the safety system 14. However, in such embodiments, the field devices are likely to need to meet the high standards typically required for implementation in a safety system (e.g., with respect to the increased requirements for verifiable integrity of the data transmitted and received by the device). As a result, the per-variable data integrity verification techniques disclosed herein can be particularly useful in safety systems such as safety system 14.

[0040] Process controllers 24 and 26 can be, by way of example only, DeltaV (trademark) controllers sold by Emerson Process Management, and any other desired type of process controller can be programmed to provide process control functionality using module 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 (using what is generally referred to as control). In particular, each of controllers 24 and 26 implements, or monitors, one or more process control routines stored therein or otherwise associated therewith and communicates with field devices 40 and 42 and workstation 14 to control process 10 or a portion of process 10 in any desired manner. Field devices 40 and 42 can be of 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 protocol, including, by way of example only, HART or 4 - 20ma protocol (as shown for field device 40), Foundation Fieldbus protocol (as shown for field device 42), or any fieldbus protocol, or CAN, Profibus, AS interface protocol. Similarly, I / O devices 28 - 36 can be of any known type of process control I / O device using any suitable communication protocol.Generally speaking, a process controller implements a control routine (which is part of a larger control strategy for controlling the process), determines one or more controller output values (i.e., the commands sent by the controller), drives one or more process inputs (i.e., manipulated variables such as the position of a control valve that responds to the controller's commands), and based on one or more measured process inputs received at the controller as controller inputs (e.g., measured temperature, flow rate, pressure, etc.), sets the process output (i.e., a controlled variable such as temperature, flow rate, etc.) to a desired value (i.e., a setpoint), thereby implementing control of the process being controlled.

[0041] The safety logic solvers 50 - 56 of FIG. 1 can be any desired type of safety system control device including a processor 57 and a memory storing a safety logic module or routine 58 adapted to be executed on the processor 57 to provide control functions related to the safety system 14 using field devices 60 and 62. The logic implemented by the logic solver to implement safe control of a controlled process can be referred to as a "safety scheme" or "safety system scheme". The safety scheme is based on the evaluation of one or more process variable values (e.g., sensor measurement values, diagnostic metrics, etc.) and one or more detected unsafe states based on the logic of the safety scheme, and commands one or more of the field devices 40, 42, 60, or 62 to transition to a safe state (e.g., actuate a related valve to drive it to a safe state). The nature of the safe state generally depends on the specific nature of the process and field devices in question. For example, if there is a risk of a tank overflowing, the logic solver can drive the inlet valve to a safe state by closing the valve (thereby preventing more liquid from entering the tank). In contrast, the logic solver can drive the outlet valve to a safe state by opening the outlet valve (thereby draining the tank). In other words, in this particular example, the safe state of the inlet valve may be 0% open and the safe state of the outlet valve may be 100% open.

[0042] Of course, the safety field devices 60 and 62 can be any known or desired communication protocol compliant or used field devices such as those described above, or any desired type of field device. In particular, the field devices 60 and 62 can be safety-related field devices of the type conventionally controlled by a separate dedicated safety-related control system. In the process plant 10 shown in FIG. 1, the safety field device 60 is shown as using a dedicated or point-to-point communication protocol such as the HART or 4-20ma protocol, while the safety field device 62 is shown as using a bus communication protocol such as the Fieldbus protocol. However, as described above, in one embodiment, the 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.

[0043] A common backplane 76 (shown by the dotted lines through the controllers 24, 26, I / O devices 28-36, safety logic solvers 50-56, and MPDs 70 and 72) is used at each of the nodes 18 and 20 to connect the controllers 24 and 26 to the process control I / O cards 28, 30 and 32 or 34 and 36, and to the safety logic solvers 52 and 54 or 56 and 58, and to the MPD 70 or 72. The controllers 24 and 26 are also communicatively coupled to the bus 22 and operate as a bus arbiter of the bus 22 to enable each of the I / O devices 28-36, logic solvers 52-56 and MPDs 70 and 72 to communicate with any of the workstations 16 via the bus 22.

[0044] As will be appreciated, each of the workstations 16 includes a processor 77 and a memory 78 storing one or more configuration and / or display applications adapted to be executed on the processor 78.

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

[0046] The configuration database 80 includes, or is otherwise accessible to, a configuration database that stores data and other information that specifically identifies or addresses various devices or components, and their interconnections, that are planned or desired to be implemented in a process plant floor or field environment. As an example, the configuration database stores some logical identifiers of components in the field environment, enabling controllers and other devices to reference components and signals associated therewith via the logical identifiers. For example, for a given field device, the configuration database can store information that maps or binds a logical identifier to a specific hardware address or I / O channel. The hardware address can identify a specific controller, a specific I / O card connected to the specific controller, or a specific address for an I / O channel that connects the specific I / O card to the field device. In some cases, this mapping or binding can be stored in a controller, a user interface device, an operator workstation, or any other desired device (e.g., any device that needs to resolve a logical identifier).

[0047] After a logical identifier is coupled to a hardware address or I / O channel, the identifier is considered "assigned". In some cases, the system 10 includes "unassigned" logical identifiers, which are identifiers that are referenced by software elements (e.g., control routines or function blocks) but have no coupling. That is, a logical identifier is considered "unassigned" when the system 10 and the configuration database do not have a hardware address or I / O channel bound to the tag. Thus, when an unassigned logical identifier is referenced by a control routine, the value carried by a signal within the plant 10 will not be read, and a command will not be sent through a field device within the plant 10.

[0048] Examples of such logical identifiers include device tags (DTs), each representing a particular instrument, controller, valve, or other physical field device (e.g., field device 60A), and device signal tags (DSTs), each representing a particular signal corresponding to a particular parameter received or generated by a particular device and typically utilized by a field device (e.g., a command received by field device 60A from controller 52 or a measurement transmitted by field device 60A to controller 52). In some devices, the DST includes a combination of the device's DT and an identifier of a particular signal received or generated by that device, e.g., an identifier of a particular parameter referenced by a control module. In some devices, such as legacy devices or dumb devices, the DT represents both the physical device and the signal generated by the device. Generally speaking, the logical identifier of a device is used by process plant 10 in both the field environment and the backend environment to uniquely identify the device. The DT and DST may be referred to as "system tags" or "system identifiers". A variable represented by a "system tag" may be referred to as a "system variable".

[0049] 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 a logical identifier unique to smart field device 22. These logical identifiers may be different from the system tags utilized by plant 10 to identify the field devices and their associated signals and may be referred to as "source identifiers" or "source tags". Depending on the implementation, source tags may or may not be stored in the aforementioned configuration database.

[0050] Generally speaking, the "field device variables" contemplated herein are variables local to the field device described. As an example, a smart field device may have a local "source tag" that uniquely identifies a field device variable local to the smart field device. If desired, the smart field device may be configured to send the field device variable value to a corresponding controller, which may then map the received value to a system tag intended to map to the 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 system tags (and thus the represented variables may not be integrated into or considered by the associated process control or safety system). Some source tags may be ignored by the process control or safety system because the variables they represent may have little impact on the operating or safety objectives of the process control or safety system.

[0051] The display application 82 can be used to provide one or more displays, as needed, to a user such as a process control operator, a safety operator, etc., in either separate views or the same view, including information regarding the states of the process control system 12 and the safety system 14. For example, the display application 82 can be an alarm display application that receives an indication of an alarm and displays it to the operator. Such an alarm display receives alarms from both the process control system 12 and the safety system 14, and since the alarms from both the process control system 12 and the safety system 14 are sent to the operator workstation 14 that runs the alarm display application and are recognized as alarms from different devices, the alarms can be received and displayed in an integrated alarm display. Similarly, the operator can process safety alarms displayed in an alarm banner in the same way as process control alarms. For example, the operator or user can use the alarm display to confirm a safety alarm and turn off the safety alarm, which sends a message to the appropriate process controllers 24, 26 within the safety system 14 using communication via the bus 22 and the backplane 76 to perform corresponding actions regarding the safety alarm. In a similar manner, other display applications can display information or data from both the process control system 12 and the safety system 14 so that any data from one of the systems 12 and 14 can be integrated into a display or view that is traditionally provided for the process control system, since these systems use the same type and kind of parameters, security, and references.

[0052] In either case, applications 80 and 82 can send individual configurations and other signals to each of process controllers 24 and 26, and can also receive data from each of safety system logic solvers 50 - 56. These signals can include process-level messages associated with controlling the operating parameters of process field devices 40 and 42, and can include safety-level messages associated with controlling the operating parameters of safety-related field devices 60 and 62. Safety logic solvers 50 - 56 can be programmed to recognize both process-level messages and safety-level messages, but safety logic solvers 50 - 56 can distinguish between the two types of messages and cannot be programmed or affected by process-level configuration signals. In one example, programming messages sent to process control system devices can include certain fields or addresses that are recognized by safety system devices and that prevent those signals from being used to program the safety system devices.

[0053] If desired, safety logic solvers 50 - 56 can employ the same or different hardware or software designs compared to the hardware and software designs used for process control I / O cards 28 - 36. However, using alternative technologies for devices within process control system 12 and devices within safety system 14 can minimize or eliminate common cause hardware or software failures.

[0054] Furthermore, a safety system device including logic solvers 50-56 can employ any desired isolation and security techniques to reduce or eliminate the possibility that unauthorized changes are made to the safety-related functions implemented thereby. For example, the safety logic solvers 50-56 and the configuration application 80 may require a person with a specific privilege level or a person at a specific workstation to make changes to the safety modules within the logic solvers 50-56, and this privilege level or location is different from the privilege or access level or location required to make changes to the process control functions executed by the controllers 24 and 26 and the I / O devices 28-36. In this case, only a person designated within the safety software or located at a workstation permitted to make changes to the safety system 14 has the authority to change the safety-related functions, thereby minimizing the possibility of damage to the operation of the safety system 14. As will be understood, in order to implement such security, the processors within the safety logic solvers 50-56 evaluate received messages for appropriate format and security and act as a gatekeeper for changes applied to the safety level control module 58 executed within the safety logic solvers 50-56.

[0055] Furthermore, if desired, when a safety-related function is enabled within the logic solvers 50-56, the status of the safety function cannot be changed via the operator workstation 14 without appropriate access rights, thereby enabling the communication structure associated with the process control system 12 to be used to provide initialization of the safety system 14 and to provide a runtime report of the operation of the safety system 14, while still isolating the process control system 12 from the safety system 14 in the sense that changes to the process control system 12 cannot affect the operation of the safety system 14.

[0056] As will be appreciated, by using the backplane 76 at each of nodes 18 and 20, the safety logic solvers 50 and 52 and the safety logic solvers 54 and 56 can communicate locally with each other to coordinate the safety functions implemented by each of these devices, communicate data with each other, or perform other integration functions. On the other hand, the MPDs 70 and 72 operate such that portions of the safety system 14 located in very different locations of the plant 10 can still communicate with each other to provide coordinated safety operations at different nodes of the process plant 10. In particular, the MPDs 70 and 72 in combination with the bus 74 enable safety logic solvers associated with different nodes 18 and 20 of the process plant 10 to be communicatively cascaded together, enabling a cascade of safety-related functions within the process plant 10 according to the assigned priorities. Alternatively, two or more safety-related functions located in different locations within the process plant 10 can be interlocked or interconnected without the need to run dedicated lines to individual safety field devices within separate areas or nodes of the plant 10. In other words, the use of the MPDs 70 and 72 and the bus 74 allows configuration engineers to design and configure a safety system 14 that is naturally distributed throughout the process plant 10 but whose different components are communicatively interconnected such that heterogeneous safety-related hardware can communicate with each other as needed. This feature also provides scalability of the safety system 14 in that it allows additional safety logic solvers to be added to the safety system 14 as needed or when new process control nodes are added to the process plant 10.

[0057] B. Examples of Field Devices and Controllers FIG. 2 is a block diagram showing exemplary components of field device 60A and controller 52 (also shown in FIG. 1) communicatively coupled via link 199 when the I / O network 1 shown in FIG. 1, each of which may be configured to transmit and receive messages containing variable values in such a way that a receiving device can verify the integrity of received values on a variable-by-variable basis.

[0058] Unless otherwise specified, a "communication link" or "link" is a path or medium that connects two or more nodes. A link can be a physical link or a logical link. A physical link is an interface and / or medium over which information is transferred and may be essentially wired or wireless. Examples of physical links include (i) wired links such as cables with conductors for transmitting electrical energy or fiber optic connections for transmitting light, and (ii) wireless links such as radio electromagnetic signals that convey information via modifications imposed on one or more characteristics of electromagnetic waves. A logical link between two or more nodes represents the abstract concept of an underlying physical link or intermediate nodes connecting the two or more nodes. For example, two or more nodes can be logically connected 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).

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

[0060] Further, the controller 52 includes a set of circuits 152 and a communication interface 154 for (i) coupling the controller 52 to the field device 60A via a link 199 and (ii) coupling the controller 52 to the communication network 22. The set of circuits 152 includes a processor 163 and a memory 161, which includes logic or instructions 171 that, when executed by the processor 163, cause the controller 52 to perform one or more of the functions described herein (e.g., those described with reference to FIGS. 6 and 7). The memory 152 includes the same data integrity formula 132 and the same seed 123 used by the field device 60A, enabling the controller 52 to calculate a data integrity check on the values received from the field device 60A. The controller 52 includes a process variable 175 that corresponds to or maps to the device variable 125.

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

[0062] When transmitting the value of the device variable 125 to the controller 52 via a message, the field device 60A can include a calculated data integrity check to enable the controller 52 to verify the integrity of the received value. Generally speaking, the controller 52 (or any desired recipient) is configured to recalculate the data integrity check based on the known seed 123 (also known to the controller 52) and the value included in the received message. The formula 132 is configured such that changing any of the inputs results in a different data integrity check being performed. Thus, if the value of the variable 125 (or the sequence parameter or variable status parameter if used) is changed in any way during transmission, the data integrity check calculated by the controller 52 will be different from that received in the message, and thus it can be determined that one of the inputs (e.g., the value of the variable 125) is different from what was transmitted.

[0063] Generally, in response to verifying the integrity of the received value, the controller 52 updates the process variable 175 with the value of the device variable 125 received from the field device 60A. If the data integrity check calculated by the controller 52 does not match the received data integrity check, the controller 52 discards the received value instead of updating the process variable 175 with the received value. Depending on the embodiment, the process variable 175 can be a local variable or a system variable. Further, the controller 52 can include control logic 182 for implementing functions as part of a safety scheme (e.g., putting one or more field devices in a safe state in response to detecting a dangerous condition). Depending on the particular configuration, the control logic 182 can consider the value of the process variable 175 (and thus can depend on the device variable 125). Additional details regarding the per-variable data integrity check are described below with reference to the methods shown in FIGS. 6 and 7.

[0064] If desired, the field device 60A can calculate and transmit a data integrity check for any of a desired number of variable values and, if desired, can transmit multiple data integrity checks for a single variable value (e.g., when each is targeted to a different recipient). Further, any suitable process control device can be configured to transmit variable values in a message that enables per-variable verification of data integrity by implementing a data integrity formula such as formula 132 and a seed such as seed 123.

[0065] II. Exemplary Protocol FIG. 3 shows exemplary layers of an exemplary protocol stack 300 that can be used for a process control device to transmit and receive device variable values in a way that enables a receiving device to verify the integrity of received values for each variable, as described herein.

[0066] The protocol stack 300 includes five layers: a physical layer 303, a data link layer 305, a network layer 307, a transport layer 309, and an application layer 311. The protocols used by the described system may include additional or alternative layers to those described. Each layer 303 - 311 of the protocol 300 may have a set of rules that protocol data units (PDUs) or messages must follow in order for nodes on the network to properly understand the content of the message. The PDU of each layer may include a payload and metadata (e.g., included in headers, footers, preambles, etc.). Generally speaking, the payload is the content or data of the PDU, and the metadata is "data about data" (e.g., format, sequence, timing, destination and source addresses, communication handshake, etc.).

[0067] Generally speaking, each of the layers 303 - 311 may 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 comply with the HART protocol of the application layer 311, and standard HART commands, responses, and formats are used. In one embodiment, the described messages may comply with other protocols such as Open Platform Communications United Architecture ("OPC UA"), a machine-to-machine communication protocol for industrial automation. The ALPDU may be transmitted via any suitable NLDU.

[0068] III. Exemplary Message Payload Figures 4 and 5 show exemplary message payloads 400 and 500, each representing an example of the message payload 352 shown in FIG. 3, and each including one or more variable values having corresponding data integrity checks so that a receiving device can verify the integrity of the values included on a variable-by-variable basis. Any one or more of the process control devices shown in FIG. 1 may be configured to send or receive messages including payloads formatted in a manner similar to payloads 400 and 500.

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

[0070] Integrity portions 408 and 410 include data integrity checks corresponding to the values carried in the variable portions. Each of portions 408 and 410 may include a parameter indicating the variable portion to which the data integrity check corresponds. For example, integrity portion 408 includes a data integrity check 425 and a parameter 423 identifying the message portion to which data integrity check 421 corresponds. For example, referring to FIG. 2, data integrity check 425 may be a value calculated through data integrity formula 132 using values 411 and seed 123 as inputs. Sub-parameter 423 may include a value "402" (or any other suitable ID identifying portion 402 or value 411) indicating that check 421 of portion 408 corresponds to portion 402 (and thus value 411).

[0071] Similarly, the consistency portion 410 may include a data consistency check (not shown) and parameters indicating corresponding portions thereof. For example, the consistency portion 410 may correspond to the variable portion 406 or the variable portion 402 (e.g., when the value 411 is intended to be received by two different recipients, each of the portions 408 / 410 corresponds to a different recipient).

[0072] Moving on to FIG. 5, the portions 502 - 510 correspond to the portions 402 - 410 shown in FIG. 4. Similarly, the device variable value 514 corresponds to the value 411, the data consistency check 525 corresponds to the data consistency check 425, and the partial parameter 523 corresponds to the partial parameter 423.

[0073] However, the portions 502 - 510 include additional data that is not necessarily included in the portions 402 - 410 of the payload 400. For example, the variable portion 502 includes (i) a device variable code 511 that includes a value unique to the variable in question (e.g., uniquely identifying the variable 125 shown in FIG. 2), (ii) a device variable classification 512 that includes a value unique to the variable type (e.g., process variable, consistency variable, etc.), (iii) a device variable unit code 513 that includes a value unique to the unit corresponding to the variable in question (e.g., Fahrenheit, Celsius, Kelvin, etc.), and (iv) a device variable status 515 that includes a value indicating the status of the value 514 (e.g., good or reliable, bad or unreliable, unknown, etc.).

[0074] Furthermore, the consistency portion 508 may include data related to the data consistency check 525. For example, it may include (i) a device variable code 521 that contains values specific to the data consistency check in question, (ii) a device variable classification 522 that contains values specific to the variable type (e.g., indicating that the variable in question is a data consistency check), (iii) a portion 523 that identifies the message portion to which the data consistency check 525 corresponds, (iv) a sequence parameter 524 that is incremented each time the value 514 is updated, (v) a data consistency check 526, such as a CRC, of the configuration data included in the portion 502 (i.e., the relevant portion) and the portion 508, and (vi) a device variable status that indicates the status or reliability of the data consistency check 525. The data consistency check 526 of the configuration data can ensure that the check 525 is for the intended information. For example, consider the case where the configuration is changed from Deg C to Deg F, or the type of thermocouple is changed. Depending on the embodiment, this change may not be captured by the check 525 of the value 514. Thus, the check 526 can capture changes to, for example, the metadata associated with the variable value 411 / 514.

[0075] IV. Exemplary Method for Sending a Message Enabling Data Consistency Checks at the Variable Level FIG. 6 shows an exemplary method for transmitting a message containing variable values, which enables a receiving device to verify the integrity of received values for each variable. Method 600 may be implemented, in whole or in part, by any one or more suitable process control devices (e.g., controllers 24, 26, 50, 52, 54, or 56, or field devices 40, 42, 60, or 62) such as those shown in FIGS. 1 and 2, and may be implemented via a set of circuits (e.g., of field device 60A) that are permanently or semi-permanently configured to execute method 600. In one embodiment, method 600 may be embodied by a set of instructions or routines stored in memory and executable by a processor to implement the functionality of method 600. The following discussion may refer to the structures shown in FIGS. 1 and 2, but it should be understood that method 600 may be implemented by any suitable process control device configured to transmit messages including process variable values and data integrity checks for each variable, such as those described herein.

[0076] Method 600 begins at step 605, where a first process control device (e.g., field device 60A) detects a value for a device variable. The value can be detected by sensor measurements (e.g., flow rate, temperature, pressure, viscosity, level, light, sound, etc.) or by calculation. Examples of values detected by calculation include diagnostic parameters related to the health of the first process control device and the devices it operates (e.g., valves) or uses for measurement (e.g., sensors).

[0077] At step 610, the first process control device (e.g., field device 60A) calculates a data integrity check for each detected value for which improved data integrity is desired. The data integrity check can be any suitable error detection code for verifying the integrity of data, such as a cyclic redundancy check (CRC), checksum, or hash.

[0078] If desired, some of the detected values may not have corresponding data integrity checks. The data integrity check can be calculated via the data integrity formula 132 shown in FIG. 1B. Generally speaking, to calculate the data integrity check, the first process control device uses the detected value and the 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 one embodiment, the seed is unique enough to enable the detection of a mask.

[0079] For example, the seed can be a device tag used by the process control system 12 and / or the safety system 14 for the field device 60A, the device tag of the target controller 52, the serial number of the field device 60A, the serial number of the controller 52, the hardware address of the field device 60A (e.g., MAC address), 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 an exemplary embodiment, the seed is a combination of the device tag of the field device 60A and the serial number of the field device 60A.

[0080] In one embodiment, the first process control device includes a sequence parameter for each detected value that is updated each time the respective value is updated. If desired, this sequence parameter can be used as an input to the data integrity formula.

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

[0082] If desired, the first process control device may calculate multiple data integrity checks for each detected value. This can be useful if multiple other process control devices receive the detected value and rely on it (e.g., the detected value carried in a message may be corrupted by the time the message reaches one device via a first communication path, but may not be corrupted when received by another device via a second communication path). Further, this can be useful if a second consumer of the data requires a second seed (e.g., a high-level system that does not want to share the seed for security reasons).

[0083] In step 615, the first process control device (e.g., field device 60A) encodes a message with each detected value and each corresponding data integrity check (assuming one exists). The message can be encoded according to a format such as that of messages 400 and 500 in FIGS. 4 and 5. The message can be encoded to include each input used in the calculation of the data integrity calculation. Thus, in embodiments where a data integrity formula is calculated for a particular variable based on a variable value, a sequence number of the variable, a status of the variable, and a seed, the message can include the variable value, sequence number, and variable status for a given variable.

[0084] For example, the message can include a payload having multiple parts each corresponding to a different variable (see, e.g., parts 402 - 406 shown in FIG. 4). Then, for each value having a data integrity check, the message can include an additional part corresponding to the data integrity check (see, e.g., parts 408 and 410 shown in FIG. 4).

[0085] For illustration purposes, a message may include first, second, and third portions corresponding to first, second, and third variables, respectively. If data integrity checks are desired for the first and third variables but not, for example, for the second variable, the message may also include fourth and fifth portions that include a data integrity check (e.g., a fourth portion) for the first variable and a data integrity check (e.g., a fifth portion) for the third variable.

[0086] A message may include consistency portions and means for determining the variable value or message portion to which the data integrity check corresponds. For example, each consistency portion within the message may include a "portion number" parameter that indicates the position within the message of the portion that carries the corresponding variable value. For illustration purposes, if the consistency portion 408 corresponds to the variable value of portion 402, the parameter 422 may be set to "402". If the message includes multiple data integrity checks for a single detected value, the multiple consistency portions may include a "portion number" parameter that identifies the same variable value portion.

[0087] In some embodiments, up to eight portions may be anticipated for each message, and the "portion number" of the consistency portion may be set from 0 to 7 to indicate the variable portion to which it corresponds. If desired, the variable portions and consistency portions may be encoded with additional and / or alternative information such as that discussed with reference to FIG. 5.

[0088] In step 620, a first process control device (e.g., field device 60A) transmits a message such that the message 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, historian, etc.). Depending on the embodiment, the first process control device can transmit the message via a wired or wireless link. Generally speaking, the second process control device is a device configured to implement a function as part of a control scheme for a process controlled in a process control environment (e.g., plant 10). The control scheme can be a safety system scheme (e.g., implemented via safety system 14) that is responsible for maintaining the safe operation of the devices within the environment (e.g., responsible for driving one or more process control devices within the environment in response to the detection of an unstable or otherwise potentially dangerous state). In one embodiment, the control scheme is a process control scheme or strategy (e.g., implemented via process control system 12) for controlling the process to achieve a control objective (e.g., production of a desired product or chemical such as ethanol, power generation, etc.). The safety system scheme can be characterized as a "passive" system that intervenes only when a potentially dangerous state occurs, while the process control system is typically more active, continuously reacting to the state of the process and attempting to drive various aspects of the process to the desired state to achieve the desired objective.

[0089] The first and second process control devices may be configured to send and receive messages via a publish / subscribe model (e.g., where the first device periodically sends messages to the second device without prompting) or to send messages according to request / response messages (e.g., where the first device sends a message in response to a request from the second device). In one embodiment, the first and second process control devices may each be configured to implement either a request / response model or a publish / subscribe model, as needed.

[0090] The first and second process control devices may be configured to send and receive messages according to any suitable protocol that may be implemented in a process control environment, provided that such a protocol can support or can be modified to support the per-variable data integrity checks described herein. Examples of protocols that may be used with the first and second process control devices include HART, HART-IP, WirelessHART, Profibus, FOUNDATION™ Fieldbus, Ethernet / IP, ControlNet, DeviceNet, Modbus, OPC UA, and the like.

[0091] In some cases, method 600 is implemented at a rate proportional to the scan cycle (e.g., every scan cycle, every other scan cycle, etc.). Generally, a scan cycle occurs every all scan times (any desired time such as 1 millisecond, 100 milliseconds, 1 second, etc.). A scan cycle is generally a cycle in which the associated controller collects inputs, executes control algorithms, and updates outputs accordingly. Thus, if controller 52 is configured to perform a scan cycle during a given scan time, field device 60A can be configured to perform method 600 at a rate equal to or faster than the scan rate (e.g., the harmonic period relative to the scan time) (e.g., thereby providing the latest field device variable values to controller 52).

[0092] In some cases, method 600 is implemented each time a change is detected in an associated field device variable (e.g., a variable that field device 60A is configured to transmit a value for).

[0093] If desired, method 600 can be implemented by any suitable device for the purpose of sending a message containing variable values in a way that allows verification of data integrity for each variable. For example, in some cases, a controller (e.g., logic solvers 50 - 56 or process controllers 24 / 26), a workstation (remote or local to process control environment 10), a historian, a device within an asset management system (AMS), a network device, or any other desired device implemented in a process control environment can implement method 600 for sending a message that allows verification of data integrity for each variable, and as a result, any such process control device can, in one embodiment, implement the above-described functionality as being performed by field device 60A. Similarly, a second process control device (i.e., the recipient of the sent message) can be any of these devices.

[0094] Exemplary Method for Receiving Messages Enabling Data Consistency Checks at the Variable Level FIG. 7 shows an exemplary method 700 for receiving a message containing variable values in a manner that enables verification of the integrity of received values on a per-variable basis. Method 700 may be implemented, in whole or in part, by any one or more suitable process control devices (e.g., controllers 24, 26, 50, 52, 54, or 56, or field devices 40, 42, 60, or 62) such as those shown in FIGS. 1 and 2, and may be implemented via a set of circuits (e.g., controller 52) that are permanently or semi-permanently configured to execute method 700. In one embodiment, method 700 may be embodied by a set of instructions or routines stored in a memory and executable by a processor to implement the functionality of method 700. The following discussion describes method 700 with reference to the structures shown in FIGS. 1 and 2, but it should be understood that method 600 may be implemented by any suitable process control device configured to receive messages including process variable values and per-variable data consistency checks, such as those described herein.

[0095] Method 700 may be implemented to process a message transmitted by a first process control device that includes process variable values and per-variable data consistency checks. Specifically, method 700 may be implemented by a second process control device such as controller 52 shown in FIGS. 1 and 2.

[0096] 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). Optionally, the second process control device may receive the message from any suitable device (field device or otherwise) configured to transmit messages in a manner that enables per-variable verification of data consistency in a manner consistent with the techniques described. The message may be received via a wired or wireless link.

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

[0098] Further, optionally, the message may include multiple data integrity checks for a given candidate value (e.g., each data integrity check may be targeted at a different recipient of the message). In such cases, the second process control device needs to determine the data integrity check corresponding to a given candidate value. In some embodiments, the second process control device is preconfigured to assume that one of the data integrity checks is assigned to it (e.g., the data integrity check for the second process control device may always be at the same relative position or portion of the message). In some embodiments, the message includes each parameter of the data integrity check for identifying the receiving device to which it corresponds (e.g., the parameter for each data integrity check identifying the tag, serial number, unique identifier, IP address, etc. of the intended receiving device).

[0099] When decrypting the message, the second process control device (e.g., controller 52) can analyze the message to determine which part of the message is the variable part (i.e., the part carrying the device variable value) and which part is the integrity part (i.e., the part carrying the data integrity check of the device variable value). To this end, each part of the message may include a parameter or field indicating its type (e.g., a device variable code indicating that the part is a variable part, an integrity part, etc.). The second process control device then analyzes the integrity part to determine the corresponding variable part. This may involve analyzing the "part number" parameter of each integrity part, which indicates the part within the corresponding message.

[0100] In step 715, the second process control device (e.g., controller 52) calculates a second data integrity check for the candidate value. For example, referring to FIGS. 2 and 4, controller 52 can identify candidate value 411 within part 402 and corresponding data integrity check 421 within part 408. Then, using value 411 and a predetermined seed as inputs to equation 132, a second data integrity check can be calculated. The second integrity check can then be stored permanently or temporarily. Similarly, the second process control device can calculate a second data integrity check for each of the other data integrity checks included in the message.

[0101] In step 720, the second process control device (e.g., controller 52) selects the first and second data integrity checks for a given candidate value to be compared. For example, sticking with the previous example, controller 52 may select value 411 and data integrity check 421 corresponding to value 411.

[0102] In step 725, the second process control device (e.g., controller 52) compares the first and second data integrity checks. For example, in the case of value 411, controller 52 may compare the received data integrity check 421 with the data integrity check calculated by controller 52 using value 411 and the seed as inputs. If value 411 has not been changed after data integrity check 421, the first and second data integrity checks should match. If value 411 has been changed (or in embodiments where the sequence number is used to calculate the integrity check, if the sequence number has been changed), the first and second integrity checks do not match.

[0103] In step 730, the second process control device (e.g., controller 52) proceeds to step 740 if the first and second data integrity checks match (indicating that the candidate value has not changed since the first data integrity check was calculated, and thus indicating that the received candidate value is the detected value intended to be sent by field device 60A), and proceeds to step 735 otherwise (indicating that value 411 is somehow different from the original value sent by field device 60A).

[0104] In step 735, in response to a determination that there is a data integrity check mismatch, the second process control device (e.g., controller 52) discards a given candidate value corresponding to the first and second data integrity checks. That is, it continues without updating the corresponding process variable with value 411. The second process control device and the larger control or safety system can continue operation under the assumption that the value of the variable in question was the value it had before receiving the message. In some cases, the second process control device can generate an alarm (e.g., via a workstation) in response to detecting that there is a mismatch (or in response to receiving a certain number of mismatches during a particular period of time or after a particular number of messages have elapsed). In some cases, the second process control device may determine that the risk of proceeding in such a state is too high and can send a message to the first field device (e.g., field device 60A) to put it in a safe state (e.g., by opening or closing a valve).

[0105] In step 740, in response to a determination that there is a data integrity check match, the second process control device (e.g., controller 52) updates the process variable corresponding to the field device variable with the candidate value.

[0106] For example, before method 700 is implemented, valve CV001 may have a position that is 25% open. In the received message, the variable in question may be the valve position of CV001, and the candidate value of the message may be 50% open (indicating that the valve position has changed). In response to detecting a data integrity mismatch, controller 52 discards the candidate value and can continue operation under the assumption that, for example, the valve is still 25% open, the valve position is unknown, etc.

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

[0108] In step 745, a second process control device (e.g., the controller 52) determines whether the received message includes additional candidate values for which data integrity checks have not been analyzed in steps 725 and 730. If additional candidate values are present in the message, the controller proceeds to step 720; otherwise, it proceeds to step 750. For example, referring to FIG. 4, the controller 52 may determine that the variable portion 406 of the message 400 also has an integrity portion (e.g., portion 408). As a result, the controller 52 proceeds to step 720 and may analyze the integrity of the values included in the variable portion 406.

[0109] In step 750, the second process control device (e.g., the controller 52) ends the analysis of the received message and proceeds to the next task (e.g., processing a new message received during a future scan).

[0110] In some cases, the controller 52 (or any other device implementing the method 700) is configured to implement a scan cycle at the start of a predetermined scan period or time. In such cases, the method 600 is performed by the controller 52 for each scan cycle. Note that the method 600 can be implemented by any suitable device configured to receive messages and verify the integrity of the variable values included for each variable. For example, in some cases, a smart field device can implement the method 600.

[0111] Further, as discussed with reference to FIG. 6, the first and second process control devices can be configured to send and receive messages via a subscribe / publish model (e.g., where the first device periodically sends messages without prompting from the second device) or to send messages according to request / response messages (e.g., where the first device sends a message in response to a request from the second device). In one embodiment, the first and second process control devices can each be configured to implement either a request / response model or a publish / subscribe model as needed. Further, as described with reference to FIG. 6, the first and second process control devices can be configured to send and receive messages according to any suitable protocol that can be implemented in a process control environment, provided that such a protocol can or can be modified to correspond to the per-variable data integrity checks described herein.

[0112] VI. Additional Considerations In one embodiment, the residual error of a single message part (sometimes called a SLOT) can be calculated. Depending on the embodiment, the following assumptions may be used (but not necessarily). The limitation that the data path for communication uses shielded twisted pairs limits the worst-case bit error rate to 10-4. The 0x9eb2 16-bit CRC (CRC-16-DNP) polynomial has a Hamming distance of 6 for messages less than 135 bits (or 16 bytes). Even bit errors beyond the Hamming distance contribute very little to the result (odd errors are detected). The data word is 6 bytes - 48 bits (float + status + sequence number), the code word is 8 bytes - 64 bits (data word + 2-byte CRC), and the probability of a 6-bit error in a 64-bit code word is 7.45408-17 for a given BER. Under these assumptions, for the 0x9eb2 16-bit CRC polynomial, there may be 2051 6-bit errors for the data word size. Under such assumptions, the probability of an undetected 6-bit error is 2.83214-24. With a transfer rate of 40 Hz, the PFH can be equal to 4.07828-19.

[0113] In some embodiments, the implementation of the described system may include both a secure network connection and user-based or role-based authorization. For example, HART-IP supports the establishment of secure connections using TLS and DTLS. Role-based authorization may be desirable since the "user" may be a controller or a secure application. In some embodiments, the described system may be implemented without user / role-based authorization.

[0114] Various aspects, apparatuses, systems, components, devices, methods, and techniques for managing discrete process control elements (e.g., discrete devices, discrete communication channels, discrete signals, etc.) and smart commissioning of discrete elements within a control system 5 are described below.

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

[0116] Specifically referring to methods 600 and 700, the described functionality may be implemented, in whole or in part, by the devices, circuits, or routines of system 10 shown in FIGS. 1 and 2. Each of the described methods may be embodied by a set of circuits that are permanently or semi-permanently configured (e.g., an ASIC or FPGA) to perform the logical functions of each method, or at least temporarily configured (e.g., one or more processors, and a set of instructions or routines representing the logical functions and stored in memory) to perform the logical functions of each method.

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

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

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

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

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

[0122] In various embodiments, the hardware systems described herein may be implemented mechanically or electronically. For example, a hardware system may include dedicated circuits or logic that are permanently configured (e.g., as a dedicated processor such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC)). A hardware system may also include programmable logic or circuitry (e.g., that is included within a general purpose processor or other programmable processor) that is temporarily configured by software to perform a particular operation. It will be appreciated that the decision to implement a hardware system mechanically, either in a dedicated and permanently configured circuit, or in a temporarily configured circuit (e.g., configured by software), may be made considering cost and time.

Claims

1. A method for transmitting a message including the value for a device variable so that the integrity of the value can be verified for each variable, comprising: detecting a detected value for a device variable by a first process control device in a process control environment for controlling a process; performing a first data integrity check by performing a data integrity calculation using the detected value and a seed as inputs by the process control device; encoding a message to include the detected value and the first data integrity check for the detected value; transmitting the message such that it is receivable by a second process control device configured to: (i) receive the message; (ii) calculate a second data integrity check for a candidate value in the message for the device variable; (iii) in the second process control device, update, or not update, a process variable mapped to the device variable with the candidate value based on whether the first and second data integrity checks match; and (iv) implement a function as part of a control scheme for the process according to the process variable.

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

3. The method according to claim 1 or claim 2, 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 to a safe state.

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

6. The first process control device is a field device, and the device variable is a field device variable, the method according to any one of claims 1 to 5.

7. The first process control device is a controller, the method according to any one of claims 1 to 6.

8. The message is encoded to include a plurality of detected values each having a data integrity check, and the method detecting a second detected value for a second device variable; further comprising calculating a third data integrity check by performing the data integrity calculation using the second detected value and the seed as inputs; encoding the message further comprises encoding the message to include the second detected value and the second data integrity check for the second detected value; The second process control device (i) calculating a fourth data integrity check for a second candidate value in the message for the second device variable; (ii) in the second process control device, updating, or not updating, a second process variable mapped to the second device variable with the second candidate value based on whether the third and fourth data integrity checks match; (iii) further configured to perform a function as part of a control scheme for the process according to the second process variable, the method according to any one of claims 1 to 7.

9. Encoding the message includes encoding the message such that the message includes a plurality of message parts, the plurality of message parts including: a first message part including the first detection value, a second message part including the second detection value, a third message part including the first data integrity check and a parameter indicating to which of the plurality of message parts the first data integrity check corresponds, The method according to claim 8, wherein a fourth message part includes the third data integrity check and a parameter indicating to which of the plurality of message parts the third data integrity check corresponds.

10. Further including incrementing a sequence parameter to indicate an update to the device variable, the sequence parameter being configured to be updated each time the device variable is updated, Calculating the first data integrity check further includes using the sequence parameter as one of the inputs for the data integrity calculation, The method according to any one of claims 1 to 9, wherein encoding the message further includes encoding the message to include the sequence parameter.

11. Further including detecting a variable status for the device variable, Calculating the first data integrity check further includes using the variable status as one of the inputs for the data integrity calculation, The method according to claim 10, wherein encoding the message further includes encoding the message to include the variable status.

12. The first process control device is configured to calculate the third data integrity check for the detected value so that a third process control device that receives the message can verify the integrity of the detected value via a third data integrity check. The method includes: further including calculating the third data integrity check by performing the data integrity calculation using the detected value and a second seed as inputs by the first process control device; encoding the message further includes encoding the message so as to include the third data integrity check for the detected value; transmitting the message includes transmitting the message so that it can be received by the third process control device, and the third process control device is configured to (i) receive the message, (ii) calculate a fourth data integrity check for the candidate value in the message, and (iii) update or not update the process variable mapped to the device variable with the candidate value based on whether the third and fourth data integrity checks match in the third process control device. The method according to any one of claims 1 to 11. **Claim 13** The method according to any one of claims 1 to 12, 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, and the tag is an identifier by which the first process control device can be addressed by one or more other devices in the process control environment. **Claim 14** A system for transmitting a message including a value for a process variable that can be authenticated at the parameter level, the system comprising: A first process control device configured to be communicatively coupled to one or more other process control devices within 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 field device to the one or more controllers; (B) a set of circuits communicatively coupled to the communication interface and configured to: detect a detected value for a device variable; use the detected value and a seed as inputs to perform a data integrity calculation to compute a first data integrity check; encode a message to include the detected value and the first data integrity check for the detected value; transmit the message via the communication interface to a second process control device to: (i) receive the message; (ii) compute a second data integrity check for a candidate value within the message for the device variable; (iii) update, or not update, a process variable mapped to the device variable with the candidate value in the second process control device based on whether the first and second data integrity checks match; and (iv) implement a function as part of a control scheme for the process according to the process variable. **Claim 15** The system of claim 14, wherein the second process control device is a controller. **Claim 16** The system of claim 14 or claim 15, wherein the first process control device is a field device and the device variable is a field device variable. **Claim 17** The message is encoded to include a plurality of detected values each having a data integrity check, and the set of circuits is detecting a second detected value for a second device variable, further configured to perform: calculating a third data integrity check by performing the data integrity calculation using the second detected value and the seed as inputs, Encoding the message further includes encoding the message to include the second detected value and the second data integrity check for the second detected value, The second process control device is (i) calculating a fourth data integrity check for a second candidate value in the message for the second device variable, (ii) in the second process control device, updating, or not updating, a second process variable mapped to the second device variable with the second candidate value based on whether the third and fourth data integrity checks match, (iii) implementing a function as part of a control scheme for the process according to the second process variable. The system according to any one of claims 14 to 16.

18. The set of circuits is further configured to encode the message such that the message includes a plurality of message parts, the plurality of message parts being a first message part including the first detected value, a second message part including the second detected value, a third message part including the first data integrity check and a parameter indicating to which of the plurality of message parts the first data integrity check corresponds, The system according to claim 17, wherein the fourth message part includes the third data integrity check and a parameter indicating which of the plurality of message parts the third data integrity check corresponds to.

19. The set of circuits further includes incrementing a sequence parameter to indicate an update to the device variable, the sequence parameter being configured to be updated each time the device variable is updated. Calculating the first data integrity check 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 parameter, the system according to any one of claims 14 to 18.

20. The set of circuits is further configured to detect a variable status for the device variable. Calculating the first data integrity check further includes using the variable status as one of the inputs for the data integrity calculation. Encoding the message further includes encoding the message to include the variable status, the system according to claim 19.

21. The set of circuits is configured to calculate a plurality of data integrity checks for the detected values for different recipients of the message such that a third process control device that receives the message receives a third data integrity check. The set of circuits is configured to calculate a third data integrity check by performing the data integrity calculation using the detected value and a second seed as inputs. Encoding the message further includes encoding the message such that the third data integrity check on the detected value is included. Transmitting the message includes transmitting the message such that it is receivable by the third process control device, which is configured to: (i) receive the message; (ii) calculate a fourth data integrity check on the candidate value within the message; and (iii) update, or not update, the process variable mapped to the device variable with the candidate value in the third process control device based on whether the third and fourth data integrity checks match. The system according to any one of claims 14 to 20.

22. 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, and the tag is an identifier by which the first process control device can be addressed by one or more other devices within the process control environment. The system according to any one of claims 14 to 21.

23. A method for verifying the integrity of a device variable value included in a message from a process control device, comprising: Receiving, in a second process control device within a process control environment for controlling a process, a message transmitted by a first process control device; Decoding the message to identify, within the message: (i) a candidate value for the device variable; and (ii) a first data integrity check for the device variable; Calculating a second data integrity check by performing a second data integrity calculation using the candidate value and the seed as inputs; Comparing the second data integrity check with the first data integrity check to determine whether the second data integrity check matches the first data integrity check, thereby determining whether the candidate value matches the detected value used in the calculation of the first data integrity check, Discarding the candidate value so that the process variable mapped to the device variable maintains its previous value, in response to a determination that the second data integrity check does not match the first data integrity check, In the second process control device, updating the process variable with the candidate value, in response to a determination that the second data integrity check matches the first data integrity check, Implementing a function as part of a control scheme for the process according to the process variable, a method.

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

25. 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 to a safe state, the method according to claim 24.

26. The device variable is a first device variable, and decrypting the message decrypts the message and within the message, A first message part including the candidate value for the first device variable, A second message part including a candidate value for a second device variable, A third message part including (i) the first data integrity check and (ii) a parameter indicating which of the plurality of message parts the first data integrity check corresponds to, (i) a third data integrity check on the candidate value for the second device variable, and (ii) a fourth message part including a parameter indicating to which of the plurality of message parts the third data integrity check corresponds, The method according to any one of claims 23 to 25, comprising identifying.

27. Decoding the message further comprising identifying a sequence parameter configured to be updated each time the device variable is updated, calculating the second data integrity check further includes using the sequence parameter as one of the inputs for the data integrity calculation, The method according to any one of claims 23 to 26.

28. The method according to any one of claims 23 to 27, wherein the seed is a value including a serial number of the first process control device.

29. A system for verifying the integrity of device variable values included in a message from a process control device, including a second process control device configured to be communicably coupled to a first process control device in a process control environment, the second process control device comprising: (A) a communication interface configured to communicably couple the second process control device to the first process control device; (B) a set of circuits communicably coupled to the communication interface and receiving, via the communication interface, a message transmitted by the first process control device; decoding the message to identify, within the message, (i) a candidate value for a device variable, and (ii) a first data integrity check for the device variable; Using the candidate value and the seed as inputs to perform a second data integrity calculation to compute a second data integrity check; Comparing the second data integrity check with the first data integrity check to determine whether the second data integrity check matches the first data integrity check, thereby determining whether the candidate value matches the detected value used in the calculation of the first data integrity check; In response to a determination that the second data integrity check does not match the first data integrity check, discarding the candidate value so that the process variable mapped to the device variable maintains its previous value; In response to a determination that the second data integrity check matches the first data integrity check, updating the process variable with the candidate value; Implementing a function as part of a control scheme for the process according to the process variable, a system including a set of circuits configured to perform the above.

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 for a process control system configured to control the process, and the control scheme is a process control scheme for the process control system.

32. The device variable is a first device variable, and decrypting the message decrypts the message to obtain, within the message, a first message portion including the candidate value for the first device variable, and a second message portion including a candidate value for a second device variable; A third message part including (i) the first data integrity check and (ii) a parameter indicating to which of the plurality of message parts the first data integrity check corresponds, A fourth message part including (i) a third data integrity check for the candidate value with respect to the second device variable and (ii) a parameter indicating to which of the plurality of message parts the third data integrity check corresponds, identifying the system according to any one of claims 29 to 31.

33. The set of circuits, Is further configured to identify a sequence parameter configured to be updated each time the device variable is updated, Calculating the second data integrity check further includes using the sequence parameter as one of the inputs for the data integrity calculation, the system according to any one of claims 29 to 32.

34. The system according to any one of claims 29 to 33, wherein the seed is a value including the serial number of the first process control device.

Images