Method and system for recording quality control, production or regulatory data in a process control system

Abstract

In order to provide a trusted, secure, and immutable record of transactions within a process plant, a technique for utilizing a distributed ledger in a process control system is described. A distributed ledger can be maintained by a node that receives transactions broadcast from a field device, a controller, an operator workstation, or other device running within a process plant. Transactions can include process plant data, such as process parameter data, product parameter data, configuration data, user interaction data, maintenance data, debugging data, plant network data, and product tracking data. Distributed ledgers can also be used to execute smart contracts to allow machines such as field devices to trade on their own without human intervention. In this way, recorded process parameter values ​​and product parameter values ​​can be obtained to verify the quality of the product. In addition, regulatory data can be recorded in response to triggering events so that regulatory agencies can review the data.

Description

Technical Field

[0001] The present disclosure relates generally to process plants and process control systems and, more particularly, to using a distributed ledger to record data and events in a process control system. Background Art

[0002] Distributed process control systems such as those used in chemical, petroleum, or other process plants typically include one or more process controllers communicatively coupled to one or more field devices via an analog, digital, or combined analog / digital bus or via a wireless communication link or network. Field devices, which may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow sensors), are located within a plant environment and typically perform physical or process control functions, such as opening or closing valves, measuring process parameters (e.g., pressure, temperature, etc.) to control one or more processes performed in a process plant or system. Intelligent field devices, such as field devices that conform to well-known fieldbus protocols, may also perform control calculations, alarm functions, and other control functions typically implemented within a controller. A process controller, also typically located within a plant environment, receives signals indicating process measurements obtained by the field devices and / or other information related to the field devices, and executes a controller application that runs, for example, different control modules that make process control decisions based on the information received, generate control signals, and communicate with field devices (e.g., and Fieldbus controllers are a type of control system that coordinates control modules or blocks executed in a process control system (such as field devices). The control modules within the controller send control signals to the field devices via communication lines or links, thereby controlling the operation of at least a portion of the process plant or system. As used herein, field devices and controllers are generally referred to as "process control devices."

[0003] Information from field devices and controllers is typically available through data highways to one or more other hardware devices, such as operator workstations, personal computers or computing devices, data historians, report generators, centralized databases or other centralized management computing devices, which are typically placed in a control room or other location away from the harsh plant environment. Each of these hardware devices is typically centralized across the entire process plant or a portion of the process plant. These hardware devices run applications that, for example, enable operators to perform functions related to controlling the process and / or operating the process plant, such as changing the settings of process control routines, modifying the operation of control modules within controllers or field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for training personnel or testing process control software, retaining and updating configuration databases, etc. The data highways utilized by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0004] As an example, the DeltaV sold by EMERSON PROCESS MANAGEMENT TM The control system includes multiple applications stored in and executed by different devices located at different locations within the process plant. Configuration applications residing in one or more workstations or computing devices enable users to create or change process control modules and download these process control modules to dedicated distributed controllers via data highways. Typically, these control modules consist of communicatively interconnected function blocks, which are objects in an object-oriented programming protocol that perform functions within the control scheme based on their inputs and provide outputs to other function blocks within the control scheme. The configuration application can also allow the designer to create or change an operator interface, which is used by the viewing application to display data to the operator and enable the operator to change settings within the process control routine, such as set points. Each dedicated controller and, in some cases, one or more field devices store and execute their own controller application, which runs the control modules assigned and downloaded to it to implement the actual process control functions. A viewing application, which may be executed on one or more operator workstations (or one or more remote computing devices communicatively coupled to the operator workstations and the data highway), receives data from the controller application via the data highway and displays the data to a process control system designer, operator, or user using a user interface, and may provide any of a number of different views, such as an operator view, an engineer view, a technician view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided via the data highway, while a configuration database application may be run in another computer connected to the data highway to store current process control routine configurations and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.

[0005] Generally speaking, the process control system of a process plant includes field devices, controllers, workstations, and other devices interconnected by a set of hierarchical networks and buses. The process control system can be connected to various business and external networks, for example, to reduce manufacturing and operating costs, improve productivity and efficiency, provide timely access to process control and / or process plant information, etc. On the other hand, the interconnection of the process plant and / or process control system with the enterprise and / or external networks and systems increases the risk of network intrusion and / or malicious network attacks that may be caused by expected vulnerabilities in business systems and applications (such as those used in the enterprise and / or external networks). Network intrusion and malicious network attacks on process plants, networks, and / or control systems may adversely affect the confidentiality, integrity, and / or availability of information assets, and generally speaking, these vulnerabilities are similar to those of general computing networks. However, unlike general computer networks, network intrusions on process plants, networks, and / or control systems may also lead to not only damage, destruction, and / or loss of plant equipment, products, and other tangible assets, but also loss of life. For example, network intrusions may cause processes to become uncontrolled, resulting in explosions, fires, floods, exposure to hazardous substances, etc. Therefore, ensuring communications related to process control plants and systems is critical. Summary of the invention

[0006] Disclosed are techniques, systems, devices, components, equipment, and methods for utilizing distributed ledgers or blockchains in process control systems. The techniques, systems, devices, components, equipment, and methods may be applied to industrial process control systems, environments, and / or plants, interchangeably referred to herein as "industrial control," "process control," or "process" systems, environments, and / or plants. Typically, such systems and plants provide control of one or more processes in a distributed manner that operate to manufacture, refine, transform, generate, or produce a physical material or product.

[0007] For example, in a process control system, a distributed ledger may be maintained by a node referred to herein as an "edge gateway". The node receives transactions broadcast to the distributed ledger network from field devices, controllers, operator workstations, or other devices running within a process plant. In some cases, transactions include process parameter values ​​of process parameters corresponding to process plant entities. Process plant entities may include equipment used for a part of a process in a process plant that contains, transforms, generates, or transfers physical materials, such as valves, tanks, mixers, pumps, heat exchangers, etc. Transactions may also include product parameter values, such as properties of physical materials or products produced by a process plant, including the temperature of the product, the volume of the product, the mass of the product, the density of the product, the pressure of the product, etc.

[0008] The recorded process parameter values ​​and product parameter values ​​can then be obtained to verify the quality of the product. For example, a first process plant can manufacture, refine, transform, generate, or produce a product and then ship it to a second process plant. The second process plant can determine that the product meets certain quality standards by obtaining the recorded process parameter values ​​and product parameter values ​​from the distributed ledger. In addition, regulatory data can be recorded in the distributed ledger. For example, in response to a triggering event such as an alarm, error, leak, maintenance event, process major event, corrective action, etc., a process control element such as a field device or controller can generate a transaction including data from the triggering event, such as the time when the event occurred, the duration of the event, the process parameter values ​​of the process plant entities involved in the event, the product parameter values ​​of the products involved in the event, etc. The regulatory data is then recorded in the distributed ledger so that the regulatory agency can view the data.

[0009] Further, distributed ledgers can be used to execute smart contracts, which will be described in more detail below. A process control system can deploy smart contracts to a distributed ledger to exchange value, such as upon receipt of a product in good condition. Smart contracts can also be deployed to a distributed ledger to allow machines such as field devices to conduct transactions on their own without human intervention. For example, according to the terms of a smart contract, a computing device in a first process plant can automatically provide a predetermined number of tokens to a computing device in a second process plant after receiving an indication from one or more field devices in the first process plant that a product has been delivered from the second process plant and that the product meets certain quality standards. Smart contracts can also be used in a large number of other applications in process plants, which will be described in more detail below.

[0010] By utilizing distributed ledgers and, in some cases, smart contracts in process plants, each process plant or a network of process plants can provide a trusted, secure, and immutable record of transactions in the process plant. The secure, immutable, and trustless nature of distributed ledgers is particularly important in process control systems, where cyber intrusions may not only result in damage, destruction, and / or loss of plant equipment, products, and other tangible assets, but also in the loss of life. In addition, distributed ledgers allow process plants to track product lineage from raw materials to finished products, and further track products after they are manufactured. Moreover, when competing entities utilize or transfer common resources, distributed ledgers can be used to determine the amount of resources utilized by one of the entities and fairly compensate competing entities for the use of resources. For example, an oil refinery may produce oil that is supplied to several entities or process plants via an oil pipeline. Each process plant is responsible for compensating the refinery for the amount of oil received by the process plant from the oil pipeline. Distributed ledgers can be used to record the amount of oil received from each process plant from a device that measures the amount of oil when the oil is supplied. Since it is difficult to change the recorded data in the distributed ledger, competing entities do not have to believe that the data is reliable. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a block diagram of an example process plant or process control system illustrating, among other things, the interconnections between various example components of the process control system, the process control system itself, and other example systems and / or networks;

[0012] Figure 2 is a block diagram of an example security architecture for a process plant or process control system;

[0013] Figure 3 is an exemplary distributed ledger system for recording transactions and executing smart contracts in process control systems;

[0014] Figure 4 An exemplary validating network node and an exemplary transaction flow on a distributed ledger network in a process control system are shown;

[0015] Figure 5 Exemplary components of a network node on a distributed ledger network in a process control system are shown;

[0016] Fig. 6A An example distributed ledger including a blockchain with blocks of transactions in a process control system is shown.

[0017] Figure 6B Another example distributed ledger is shown that includes multiple side blockchains or sidechains maintained by different process plants and a main blockchain maintained by the multiple process plants that incorporates transaction data from the sidechains;

[0018] Fig. 7A Yet another example distributed ledger is shown, comprising multiple local blockchains each maintained by a different process plant;

[0019] Figure 7B showing a global blockchain of a process plant maintained by multiple process plants and merging blocks from local blockchains;

[0020] Figure 7C A super blockchain maintained by several process plants is shown that merges blocks from each global blockchain of each process plant.

[0021] Figure 8 An exemplary smart contract state in a distributed ledger network for performing a secure write operation to write a process parameter to a safety instrumented system (SIS) device in a process plant is shown;

[0022] Fig. 9 An exemplary transaction is shown representing an evidence transaction generated by an evidence oracle being a field device reporting the amount of oil received from an oil pipeline.

[0023] Fig.10 An exemplary transaction representing an evidence transaction resulting from an evidence oracle as a computing device reporting a software or firmware update is shown.

[0024] Fig.11 Exemplary transactions are shown representing evidence transactions resulting from evidence oracle being a process plant entity reporting process parameter or product parameter data.

[0025] Fig.12 A flow chart representing an exemplary method for recording data in a process control system using a distributed ledger is shown;

[0026] Fig.13 A flow chart representing an exemplary method for securely metering untrusted data in a process control system using a distributed ledger is shown;

[0027] Fig.14 A flow chart representing an exemplary method for recording quality control, production, or regulatory data in a process control system using a distributed ledger is shown;

[0028] Fig.15 A flow chart representing an exemplary method for recording the state of software or firmware in a process control system and connected instruments using a distributed ledger is shown;

[0029] Fig.16 A flow chart representing an exemplary method for creating a smart contract in a process control system using a distributed ledger is shown; and

[0030] Fig.17A flow chart representing an exemplary method for interacting with smart contracts in a process control system using a distributed ledger is shown. DETAILED DESCRIPTION

[0031] A distributed ledger is a storage mechanism for data, events, transactions, etc. maintained by several participants. Specifically, a distributed ledger is a method for reaching a distributed consensus on the validity or invalidity of information recorded in a distributed ledger. That is, a distributed ledger provides decentralized trust to participants and observers. In contrast to relying on a central authority, a distributed ledger is a decentralized database in which transaction records of changes to the ledger are maintained and verified by each node of a peer-to-peer network. One type of distributed ledger, the blockchain, consists of groupings of transactions organized together into "blocks" and ordered in sequence (hence the name "blockchain"). Although the distributed ledger discussed in this article is referenced in the context of a blockchain, this is only one example of a distributed ledger. A distributed ledger may also include a tangle, a block lattice, or other directed acyclic graph (DAG). In any case, over time, nodes can join and leave the blockchain network, and blocks can be obtained from peer nodes that propagated when the node left. Nodes can maintain the addresses of other nodes and exchange addresses of known nodes with each other to facilitate the propagation of new information in the network in a decentralized, peer-to-peer manner.

[0032] The nodes that share the ledger form what is referred to herein as a distributed ledger network. The nodes in the distributed ledger network validate changes to the blockchain (e.g., when new transactions and / or blocks are created) according to a set of consensus rules. The consensus rules depend on the information being tracked by the blockchain and can include rules about the chain itself. For example, the consensus rules can include proof of identity by the initiator of the change so that only approved entities can initiate changes to the chain. The consensus rules can require that blocks and transactions adhere to format requirements and provide certain meta-information about the changes (e.g., blocks must be below a size limit, transactions must contain multiple fields, etc.). The consensus rules can include mechanisms for determining the order in which new blocks are added to the chain (e.g., through a proof-of-work system, proof-of-stake, etc.).

[0033] Additions to the blockchain that satisfy the consensus rules are propagated from the node that has validated the addition to other nodes known to the validating node. If all nodes that receive the change to the blockchain validate the new block, the distributed ledger reflects the new change stored on all nodes, and a distributed consensus is said to have been reached on the new block and the information contained therein. Any changes that do not comply with the consensus rules are ignored by the validating nodes that received the change, and the change is not propagated to other nodes. Therefore, unlike traditional systems that use a central authority, a single party cannot unilaterally change the distributed ledger unless the single party can make the change in a way that complies with the consensus rules. The inability to modify past transactions leads to blockchains being often described as trusted, secure, and immutable.

[0034] The validation activities of nodes applying consensus rules on a blockchain network can take various forms. In one implementation, a blockchain can be viewed as a shared spreadsheet that tracks data such as asset ownership. In another implementation, validating nodes execute code contained in a "smart contract," and distributed consensus is represented by the network nodes agreeing on the output of the executed code.

[0035] A smart contract is a computer protocol that is able to automatically execute and / or implement an agreement between different parties. In particular, a smart contract can be a computer code located at a specific address on a blockchain. In some cases, a smart contract can automatically run in response to a participant in the blockchain sending funds (e.g., cryptocurrencies such as Bitcoin, Ethereum, or other digital / virtual currencies) to an address where the smart contract is stored. In addition, a smart contract can maintain a balance of the amount of funds stored in its address. In some cases, when this balance reaches zero, the smart contract may no longer be usable.

[0036] A smart contract may include one or more trigger conditions that, when satisfied, correspond to one or more actions. For some smart contracts, the action(s) performed may be determined based on one or more decision conditions. In some cases, a data stream may be routed to a smart contract so that the smart contract may detect that a trigger condition has occurred and / or analyze a decision condition.

[0037] Blockchains can be deployed in a public, decentralized, and permissionless manner, meaning that any party can view the distributed ledger, submit new information to be added to the ledger, or join the network as a validating node. Other blockchains are private (e.g., permissioned ledgers), which keep chain data private between a set of entities that have the right to participate in the blockchain network. Other blockchain implementations can be permissioned and permissionless, so verification of participants may be required, but only information that participants in the network wish to make public will be made public.

[0038] In some embodiments, the distributed ledger includes multiple blockchains such as a main blockchain and several side chains that operate independently of the main blockchain. The side chain then interacts with the main blockchain to provide some transaction data from the side chain to the main blockchain. In this way, the side chain can be private, while the main blockchain is public, or can be used by more entities than the side chain. Non-sensitive information from the side chain can be shared on the main blockchain. Also in some embodiments, the distributed ledger includes multiple layers or separate blockchains executed in parallel maintained by the same verification node. Some transaction data from the blockchain of the first layer can be provided to the blockchain of the second layer, and vice versa.

[0039] In one example, a distributed ledger in a process control system may be maintained by a verification node referred to herein as an "edge gateway," which transmits data to remote systems such as other process plants using one or more public and / or private networks (e.g., private enterprise networks, the Internet, cellular routers, backhaul Internet, or other types of backhaul connections). The edge gateway receives transactions broadcast to the distributed ledger network by, for example, process control devices (e.g., field devices or controllers running in a process plant). Other computing devices in the process plant (e.g., operator workstations, server devices, or other user interface devices) may also broadcast transactions to the distributed ledger network. The edge gateway then verifies the broadcasted transactions.

[0040] In another example, an edge gateway executes code contained in a “smart contract” while field devices act as “evidence oracles” that provide evidence to the blockchain related to quality control, regulatory compliance, delivery or receipt of products, and quantities delivered / received, etc.

[0041] Figure 1 is a block diagram of an example process plant 10 that can utilize any one or more of the novel distributed ledger technologies described herein. The process plant 10 (also interchangeably referred to herein as a process control system 10 or process control environment 10) includes one or more process controllers that receive signals indicating process measurements obtained by field devices, process the information to implement control routines, and generate control signals that are sent to other field devices via a wired or wireless process control communication link or network to control the operation of a process in the plant 10. Typically, at least one field device performs a physical function (e.g., opens or closes a valve, raises or lowers a temperature, takes a measurement, senses a condition, etc.) to control the operation of a process. Certain types of field devices communicate with the controller by using I / O devices. Process controllers, field devices, and I / O devices can be wired or wireless, and any number of wired and wireless process controllers, field devices, and I / O devices and combinations thereof can be included in the process plant environment or system 10.

[0042] For example, Figure 1 A process controller 11 is shown that is communicatively connected to wired field devices 15-22 via input / output (I / O) cards 26 and 28, and to wireless field devices 40-46 via a wireless gateway 35 and a process control data highway or backbone 105. The process control data highway 105 may include one or more wired and / or wireless communication links and may be implemented using any desired or suitable or communication protocol (e.g., an Ethernet protocol). In some configurations (not shown), the controller 11 may be communicatively connected to the wireless gateway 35 using one or more communication networks other than the backbone 105, such as by using a wireless communication network that supports one or more communication protocols (e.g., Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, mobile communication protocols (e.g., WiMAX, LTE or other ITU-R compliant protocols), Profibus, fieldbus, etc.)

[0043] The controller 11 may be, for example, a DeltaV TM A controller that can operate using at least some of the field devices 15-22 and 40-46 to implement a batch process or a continuous process. In one embodiment, in addition to being communicatively connected to the process control data highway 105, the controller 11 also uses communication with, for example, standard 4-20mA devices, I / O cards 26, 28 and / or any smart communication protocol (e.g. Fieldbus protocol, protocol, Any desired hardware and software associated with the field devices 15-22 and 40-46 may be communicatively connected to at least some of the field devices 15-22 and 40-46. Figure 1 In the embodiment, the controller 11, the field devices 15-22 and the I / O cards 26, 28 are wired devices, and the field devices 40-46 are wireless field devices. Of course, the wired field devices 15-22 and the wireless field devices 40-46 can conform to any other desired (multiple) standards or protocols, such as any wired or wireless protocols, including any standards or protocols developed in the future.

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

[0045] The controller 11 implements the control strategy using what are commonly referred to as function blocks, where each function block is an object or other portion (e.g., a subroutine) of an overall control routine and operates in conjunction with other function blocks (through communications called links) to implement process control loops in the process control system 10. Control-based function blocks typically perform one of an input function (e.g., associated with a transmitter, sensor, or other process parameter measurement device), a control function (e.g., associated with a control routine that performs PID, fuzzy logic, etc. control), or an output function (controlling the operation of a device (e.g., a valve) to perform a physical function within the process control system 10). Of course, hybrid and other types of function blocks exist. Function blocks can be stored in and executed by the controller 11, which is typically when these function blocks are used with or associated with standard 4-20mA devices and certain types of smart field devices (e.g., device), or can be stored in and implemented by the field device itself, which can be Fieldbus device case. The controller 11 may include one or more control routines 38 that may implement one or more control loops that are executed by executing one or more function blocks.

[0046] The wired field devices 15-22 may be any type of device, such as sensors, valves, transmitters, positioners, etc., and the I / O cards 26 and 28 may be any type of I / O device that conforms to any desired communication or controller protocol. Figure 1In the embodiment, the field devices 15-18 are standard 4-20 mA devices or devices that communicate with the I / O card 26 via analog lines or combined analog and digital lines. devices, while the field devices 19-22 are intelligent devices, such as Fieldbus field devices, which use The Fieldbus communication protocol communicates with the I / O card 28 via a digital bus. However, in some embodiments, at least some of the wired field devices 15, 16, and 18-21 and / or at least some of the I / O cards 26, 28 additionally or alternatively use the process control data highway 105 and / or by using other suitable control system protocols (e.g., Profibus, DeviceNet, Fieldbus, ControlNet, Modbus, HART, etc.) communicate with the controller 11.

[0047] exist Figure 1 In the example, the wireless field devices 40-46 use The wireless field devices 40-46 may communicate directly with one or more other devices or nodes of the wireless network 70 that are also configured to perform wireless communication (e.g., using the wireless protocol or another wireless protocol). In order to communicate with one or more other nodes that are not configured to perform wireless communication, the wireless field devices 40-46 may utilize a wireless gateway 35 connected to a process control data highway 105 or another process control communication network. The wireless gateway 35 provides access to various wireless devices 40-58 of the wireless communication network 70. In particular, the wireless gateway 35 provides communication coupling between the wireless devices 40-58, the wired devices 15-28, and / or other nodes or devices of the process control plant 10. For example, the wireless gateway 35 may provide communication coupling by using the process control data highway 105 and / or by using one or more other communication networks of the process plant 10.

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

[0049] In certain configurations of the process plant 10, the wireless network 70 includes non-wireless devices. Figure 1 middle, Figure 1 Field device 48 is a conventional 4-20mA device, while field device 50 is a wired To communicate within the network 70, the field devices 48 and 50 are connected to the wireless communication network 70 via wireless adapters 52A, 52B. The wireless adapters 52A, 52B support a wireless protocol, such as WirelessHART, and may also support one or more other communication protocols, such as Fieldbus, PROFIBUS, DeviceNet, etc. In addition, in some configurations, the wireless network 70 includes one or more network access points 55A, 55B, which may be separate physical devices that communicate with the wireless gateway 35 by wire, or may be provided as an integral device with the wireless gateway 35. The wireless network 70 may also include one or more routers 58 to forward packets from one wireless device to another wireless device within the wireless communication network 70. Figure 1 , the wireless devices 40 - 46 and 52 - 58 communicate with each other and with the wireless gateway 35 through the wireless links 60 of the wireless communication network 70 and / or via the process control data highway 105 .

[0050] exist Figure 1 , the process control system 10 includes one or more operator workstations or user interface devices 8 that are communicatively connected to the data highway 105. Via the operator workstations 8, an operator can view and monitor the runtime operation of the process plant 10, as well as take any diagnostic, corrective, maintenance, and / or other actions that may be required. At least some of the operator workstations 8 may be located in various protected areas within or near the plant 10, and in some cases, at least some of the operator workstations 8 may be remotely located, but still communicatively connected to the plant 10. The operator workstations 8 may be wired or wireless computing devices.

[0051] The example process control system 10 may further include a configuration application (not shown) and a configuration database (not shown), each of which is also communicatively connected to the data highway 105. As described above, various instances of the configuration application (not shown) may be executed on one or more user interface devices 8 to enable a user to create or change process control modules and download these modules to the controller 11 via the data highway 105, as well as to enable a user to create or change an operator interface via which an operator can view data and change data settings in a process control routine. The configuration database (not shown) stores created (e.g., configured) modules and / or operator interfaces.

[0052] In some configurations, the process control system 10 includes one or more other wireless access points 7a that communicate with other devices using other wireless protocols (e.g., Wi-Fi or other wireless local area network protocols compliant with IEEE 802.11, mobile communication protocols (e.g., WiMAX (Worldwide Interoperability for Microwave Access)), LTE (Long Term Evolution) or other protocols compliant with ITU-R (International Telecommunication Union Radiocommunication Sector), shortwave radio communications (e.g., near field communications (NFC) and Bluetooth) or other wireless communication protocols). Typically, such wireless access points 7a allow handheld devices or other portable computing devices to communicate on a corresponding wireless process control communication network that is different from the wireless network 70 and supports a different wireless protocol than the wireless network 70. For example, the wireless or portable user interface device 8 can be a mobile workstation or diagnostic test equipment used by an operator in the process plant 10. In some cases, in addition to the portable computing device, one or more process control devices (e.g., the controller 11, the field devices 15-22, or the wireless devices 35, 40-58) also communicate using the wireless protocol supported by the access point 7a.

[0053] In some configurations, the process control system 10 includes one or more gateways 7b, 7c (also referred to herein as "edge gateways" and described in more detail below) to systems external to the current process control system 10. Typically, such systems are clients or suppliers of information generated or operated by the process control system 10. For example, the process control plant 10 may include a gateway node 7b to communicatively connect the current process plant 10 to another process plant. Additionally or alternatively, the process control plant 10 may include a gateway node 7c to communicatively connect the current process plant 10 to an external public or private system, such as a laboratory system (e.g., a laboratory information management system or LIMS), an operator inspection database, a material handling system, a maintenance management system, a product inventory control system, a production scheduling system, a weather data system, a transportation and handling system, a packaging system, the Internet, a process control system of another supplier, or other external system.

[0054] Note that although Figure 1 Only a single controller 11 is shown with a limited number of field devices 15-22 and 40-46, wireless gateway 35, wireless adapter 52, access point 55, router 58, and wireless process control communication network 70 included in the example process plant 10, which is merely an exemplary and non-limiting embodiment. Any number of controllers 11 may be included in the process control plant or system 10, and any of the controllers 11 may communicate with any number of wired or wireless devices and networks 15-22, 40-46, 35, 52, 55, 58, and 70 to control the process in the plant 10.

[0055] In addition, it should be noted that Figure 1 The process equipment or control system 10 may include a field environment (e.g., a "process plant floor") and a backend environment (e.g., a server 12) that are communicatively connected via a data highway 105. Figure 1 As shown, the field environment includes physical components (e.g., process control devices, networks, network elements, etc.) that are arranged, installed, and interconnected therein to operate at runtime to control the process. For example, the controller 11, I / O cards 26, 28, field devices 15-22 and other devices, and network components 40-46, 35, 52, 55, 58, and 70 are located, arranged, or otherwise included in the field environment of the process plant 10. Generally speaking, in the field environment of the process plant 10, raw materials are received and processed using the physical components arranged therein to produce one or more products.

[0056] The backend environment of the process plant 10 includes various components, such as server computing devices 12, operator workstations 8, databases or data repositories, etc., which are shielded and / or protected from the harsh conditions and materials of the field environment. Figure 1 , the backend environment includes, for example, operator workstations 8, server computing devices 12, and / or functionality that supports runtime operations of the process plant 10. In some configurations, the various computing devices, databases, and other components and equipment included in the backend environment of the process plant 10 may be physically located in different physical locations, some of which may be local to the process plant 10 and some of which may be remote.

[0057] Figure 2 A block diagram of an example security architecture 200 for a process plant 10 is included. Figure 2 As shown, one or more devices 202 are communicatively connected to one or more wireless gateways 205A, 205B, which may be, for example, Figure 1 204B is an example of a wireless gateway 35. The communication connection between the gateway 205A, 205B and the device 202 is represented by reference numerals 204A, 204B.

[0058] The device set 202 is shown as including a limited number of wireless field devices. However, it should be understood that the concepts and features described herein with respect to the devices 202 can be readily applied to any number of field devices of the process plant 10, as well as any type of field devices. For example, the field devices 202 can include one or more wired field devices 15-22 that are communicatively connected to the wireless gateways 205A, 205B via one or more wired communication networks of the process plant 10, and / or the field devices 202 can include wired field devices 48, 50 coupled to wireless adapters 52A, 52B.

[0059] Furthermore, it should be understood that the device set 202 is not limited to field devices, but may additionally or alternatively include any device or component within the process plant 10 that generates data as a result of the process plant 10 controlling an online process. For example, the device set 202 may include diagnostic devices or components that generate diagnostic data, network routing devices or components that transmit information between various components of the process plant 10, and so on. In fact, Figure 1 Any of the components shown in (e.g., components 7a-7c, 8, 11, 12, 15-22, 26, 28, 35, 40-46, 52, 55, 58, 60, and 70) and other components not shown may be devices that generate data for transmission to the remote system 210. Therefore, the device set 202 may be interchangeably referred to herein as "data source 202" or "data source device 202."

[0060] Figure 2 Further illustrated is a remote application or service set 208 that can be used for the process plant 10 and / or utilized by the process plant 10. The remote application or service set 208 can be executed or hosted on one or more remote systems 210. When real-time data is generated by the process plant 10 and the application or service 208 receives the real-time data, at least some of the applications or services 208 perform real-time operations on the real-time data. Other applications or services 208 can operate or perform on the data generated by the process plant in the case where the timing requirements are not strict. Examples of applications / services 208 that can be executed or hosted at the remote system 210 and are consumers of data generated by the process plant 10 include applications that monitor and / or sense conditions and / or events that occur at the process plant 10, and applications or services that monitor at least a portion of the online process itself when the online process is executed on the process plant 10. Other examples of applications / services 208 include descriptive and / or prescriptive analytics that can operate on data generated by the process plant 10, and in some cases, can operate on knowledge collected or discovered from analyzing data generated by the process plant and data generated by other process plants or received from other process plants. Other examples of applications / services 208 include one or more routines that implement specified functions and / or changes, e.g., as a result of another service or application, to be implemented back into the process plant 10. Other examples of applications and services 208 operate on knowledge gleaned from analyzing historical data generated by the process plant and / or other process plants or from comparing data of a process plant entity to data of the same or similar type of process plant entity.

[0061] The one or more remote systems 210 may be implemented in any desired manner, such as through a remote repository of a networked server, one or more cloud computing systems, one or more networks, etc. For ease of discussion, the singular form is used herein to refer to the one or more remote systems 210, i.e., "remote system 210", but it should be understood that the term may refer to one system, more than one system, or any number of systems. In some cases, a computing device 250 that analyzes process plant data may be included within the remote system 210.

[0062] In general, the security architecture 200 provides end-to-end security, from the on-site environment of the process plant 10 in which the device 202 is installed and operated to the remote system 210 that provides the application and / or service 208 that uses and operates the data generated by the process plant 10. Thus, the data generated by the device 202 and other components of the process plant 10 can be securely transmitted to the remote system 210 for use by the remote application / service 208, while protecting the plant 10 from cyber attacks, intrusions, and / or other malicious events. In particular, the security architecture 200 includes a field gateway 212, and an edge gateway 218 disposed between the process plant 10 (e.g., between the wireless gateways 205A, 205B of the process plant 10) and the remote system 210.

[0063] Data sent from the process plant 10 and transmitted from the input port 220 to the output port 222 can be further protected by encryption. In an example, the field gateway 212 encrypts the data and passes the encrypted data to the input port 220. The encrypted and transmitted data traffic can be UDP (User Datagram Protocol) data traffic in one example, and can be JSON data traffic or some other common communication format in another example.

[0064] The field gateway 212 is communicatively connected to the process control plant 10. Figure 2 As shown, the field gateway 212 is communicatively connected to the wireless gateway 205A, 205B, which is arranged in the field environment of the process plant 10 and is communicatively connected to one or more devices or data sources 202. As previously described, the device or data source 202 and the wireless gateway 205A, 205B can communicate using the WirelessHART industrial protocol or other suitable wireless protocols, which are constructed to provide secure communication via one or more security mechanisms. For example, the WirelessHART industrial protocol provides 128-bit AES encryption, and the communication paths 204A, 204B can be protected accordingly.

[0065] In addition, the communication connection 225 between the wireless gateway 205A, 205B and the field gateway 212 is protected using the same or different security mechanism as used by the communication connection 204A, 204B, respectively. In the example, the communication connection 225 is protected by a TLS (Transport Layer Security) wrapper. For example, the wireless gateway 205A, 205B generates a data packet in a HART-IP format, which is protected by a TLS wrapper for transmission to the field gateway 212.

[0066] Thus, as described above, in one embodiment, data or packets generated by the device 202 may be protected using a first security mechanism for transmission 204A, 204B to the wireless gateway 205A, 205B, and then protected using a second security mechanism for transmission 225 from the wireless gateway 205A, 205B to the field gateway 212, and then protected using a third security mechanism for transmission to the edge gateway 218. Additionally or alternatively, and as Figure 2 As shown, the edge gateway 218 can be protected by a firewall 228.

[0067] One or more public and / or private networks, such as a private enterprise network, the Internet, a cellular router, backhaul Internet, or other type of backhaul connection, may be used to communicate data transmitted from the edge gateway 218 to the remote system 210. Importantly, the data transmitted from the edge gateway 218 to the remote system 210 is secured by using a fourth security mechanism or by using one of the security mechanisms previously discussed above. Figure 2 The data traffic transmitted from the edge gateway 218 to the remote system 210 is shown protected via a SAS (Shared Access Signature) token, which can be managed by a token service 230 provided at the remote system 210. The edge gateway 218 authenticates to the token service 230 and requests a SAS token, which is valid only for a limited period of time, such as two minutes, five minutes, thirty minutes, no more than one hour, etc. The edge gateway 218 receives and uses the SAS token to protect and authenticate an AMQP (Advanced Message Queuing Protocol) connection to the remote system 210, via which content data is transmitted from the edge gateway 218 to the remote system 210.

[0068] At remote system 210, security is provided via domain authentication service 232. Thus, only user interface devices 235 authenticated and authorized via domain authentication service 232 can access at least some of the data "available" at remote system 210, including data generated by device 202, etc.

[0069] Thus, as described above, the security architecture 200 provides end-to-end security for data generated by a device or data source 202 while operating in the process plant 10 to control a process, such as from the data originating from the data source 202 through its transmission to a remote system 210 to be operated on by one or more remote applications or services 208. Importantly, the security architecture 200 provides this end-to-end security while preventing malicious attacks from being incurred in the process plant 10.

[0070] Note that although Figure 2 The wireless gateways 205A, 205B are shown as communicatively connecting the devices or data sources 202 to the field gateway 212, but in some arrangements, one or more of the wireless gateways 205A, 205B are omitted, and the source data is transmitted directly from the data source 202 to the field gateway 212. For example, the data source 202 can transmit the source data directly to the field gateway 212 via the big data network of the process plant 10. Generally speaking, the big data network of the process plant 10 is not the backbone plant network 105, nor is the big data network an industrial protocol network for transmitting control signals between devices using industrial communication protocols (e.g., Profibus, DeviceNet, FoundationFieldbus, ControlNet, Modbus, HART, etc.). Instead, the big data network of the process plant 10 can be an overlay network implemented for the process plant 10 that can stream data between nodes, such as for data processing and analysis purposes. The nodes of the big data network may include, for example, the data source 202, the wireless gateways 205A, 205B, and the field gateway 212, and Figure 1 Any one or more of the components 7a-7c, 8, 11, 12, 15-22, 26, 28, 35, 40-46, 52, 55, 58, 60 and 70 shown and other components. Thus, for example, for many nodes of the process plant data network, a designated interface for process plant operations that typically utilize an industrial communication protocol and another designated interface for data processing / analysis operations that may utilize a streaming protocol are included.

[0071] Relative to Figure 2 It is further noted that in some embodiments, a wired gateway (not shown) may be used in place of one of the wireless gateways 205A, 205B. Furthermore, the field gateway 212 and the edge gateway 218 may be physically located at the same location, e.g. Figure 2 As shown in block 235 in FIG. 1 , or components 212 and 218 may be physically located at multiple locations. For example, one or more of the field gateway 212 or edge gateway 218 may be located at the process plant 10. Additionally or alternatively, one or more of the field gateway 212 or edge gateway 218 may be located remotely from the process plant 10.

[0072] If desired, the process plant 10 can be served by more than one field gateway 212, and any number of field gateways 210 can be served by a single edge gateway 218. In some embodiments, a remote system 210 can be served by more than one edge gateway 218, if desired.

[0073] Although the above examples involve a computing device 250 for analyzing process plant data as a component of a remote system 210, the computing device 250 may receive process plant data by communicating with any suitable communication component in a secure manner. For example, the computing device 250 may be communicatively connected to a wireless gateway 205A, 205B, a field gateway 212, or an edge gateway 218. The communication path from the device 202 to the computing device 250 may be protected via encryption techniques, firewalls, data diodes, or any other suitable security mechanism.

[0074] Once the process plant data is received at the computing device 250, the computing device analyzes the process plant data to identify conditions in the corresponding process plant entities. An indication of the condition is then sent to the user interface device 235, for example, via a domain authentication service. In this way, an operator can view conditions occurring at various process plant entities within the process plant. The operator can then take appropriate measures to resolve problems caused by these conditions.

[0075] Distributed Ledger Architecture in Process Control Systems

[0076] Despite Figure 2 The process plant 10 is shown as including a single edge gateway 218, but the process plant 10 may include several edge gateways, each of which acts as a validating node in the distributed ledger network. Figure 3 An exemplary distributed ledger system 300 for recording process plant data is shown. The process plant data may include process parameter data, product parameter data, configuration data, user interaction data, maintenance data, commissioning data, plant network data, product tracking data, event data related to events in the process plant 10, such as alarms, leaks, faults, errors, etc., or any other suitable data generated in or related to one or more process plants.

[0077] The system 300 includes a distributed ledger 312 and a plurality of nodes 302, 304, 306, 308, and 310, which may be edge gateways in the process plant 10, such as the edge gateway 218, may be field devices, or may be any suitable computing devices operating in the process plant 10 or other process plants. Each node maintains a copy of the distributed ledger 312. When a change is made to the distributed ledger 312, each node receives the change via the network 314 and updates its respective copy of the distributed ledger 312. The nodes 302-310 in the distributed ledger system 300 may use a consensus mechanism to decide whether it is appropriate to make a received change to the distributed ledger 312.

[0078] Thus, each node in the system has its own copy of the distributed ledger 312 that is identical to every other copy of the distributed ledger 312 stored by other nodes. Due to the decentralized nature of the distributed ledger, the distributed ledger system 300 can be more robust than a central authority database system. Thus, there is no single point of failure on the distributed ledger system 300 as there is in a centralized system.

[0079] Figure 4 An exemplary validating network node and an exemplary transaction flow 400 for settling a transaction on a distributed ledger network are shown. Figure 4 It includes two time frames 420 and 422 represented by the left and right sides of the dashed line respectively, node A402 and node B404 (which can be two edge gateways in the process plant 10, can be two edge gateways in two different process plants, can be two field devices in the same or different process plants, etc.), transaction sets 408A-408D, transaction block sets 409A-409D, a distributed ledger 410 and a blockchain 418.

[0080] The block propagation flow 400 may begin with node A 402 receiving transaction 406 at time 420. When node A 402 confirms that transaction 406 is valid, node A 402 may add the transaction to a newly generated block 408. As part of adding transaction 406 to block 408, node A 402 may solve a cryptographic puzzle and include the solution in the newly generated block 408 as proof of the work done to generate block 408. Alternatively, a proof-of-stake algorithm may be used to generate block 408, where node A 402 "reserve" a certain number of digital tokens used on the network, but the network itself determines the node that will create the new block. In other embodiments, transaction 406 may be added to a transaction pool until there are a sufficient number of transactions in the pool to form a block. Node A 402 may transmit the newly created block 408 to the network at time 412. Before or after propagating block 408, node A 402 may add block 408 to its copy of blockchain 418.

[0081] While proof of work and proof of stake are described herein as consensus algorithms for selecting nodes to create new blocks, these are just some example consensus algorithms and are not intended to be limiting. Other consensus algorithms may be utilized, such as delegated proof of stake, where nodes select a subset of nodes (called delegates) to perform validation, and the delegates take turns creating new blocks. Consensus algorithms may also include proof of authority, proof of weight, Byzantine fault tolerance, tangle consensus algorithms, block lattice consensus algorithms, and the like.

[0082] In any case, transactions 409A-409D may include updates to state database 416. State database 416 may contain current values ​​of variables created by smart contracts deployed on blockchain 418. Validated blocks such as block 408 may include transactions that affect state variables in state database 416. At time 422, node B 404 may receive the newly created block 408 via the network at 412. Node B 404 may verify that transaction block 408 is valid by checking the solution to the cryptographic puzzle provided in block 408. If the solution is accurate, node B 404 may add block 408 to its blockchain 418 and make any updates to state database 416, such as those rejected by the transaction in block 408. Node B 404 may then send block 408 to the rest of the network at time 314.

[0083] Figure 5 Exemplary components of verifying a network node 500 on a distributed ledger network for recording process plant data are shown. Node 500 may include at least one processor 502, memory 504, communication module 506, application set 508, external port 510, blockchain manager 514, smart contract 516, and operating system 518. In some embodiments, node 500 may generate a new transaction block by using blockchain manager 514, or may broadcast transactions to other network nodes. Similarly, node 500 may use blockchain manager 514 in conjunction with smart contract 516 stored in memory 504 to perform the functions disclosed herein. Memory 504 may further include chain data 524, which includes, for example, a state database of a blockchain for storing the state of a smart contract deployed thereon.

[0084] In other embodiments, the smart contract 516 operates independently of the blockchain manager 514 or other applications. In some embodiments, the node 500 does not have a blockchain manager 514 or smart contract 516 stored at the node. In some embodiments, the node 500 may have more or fewer components than described. The components of the node 500 are described in more detail below.

[0085] Node 500, as part of decentralized ledger system 300 or another decentralized or centralized network, can be used as part of a system for interacting with and / or manipulating transactions associated with data or events occurring in one or more process plants.

[0086] Fig. 6A An exemplary distributed ledger 600 is shown, which includes a blockchain with blocks 602-608 of transactions in a process control system. In some embodiments, the blockchain 600 includes several blocks 602-608 connected together to form a chain of blocks 602-608 of transactions. In order to cryptographically link blocks and transactions together, each block in the blockchain 600 organizes its transactions into a Merkle Tree. In the Merkle Tree, each transaction is hashed according to a cryptographic hash algorithm (e.g., SHA-256), and the resulting output hash value is then combined with the hash value of another transaction. The combined result is then hashed according to the cryptographic hash algorithm. This output is then combined with the hash values ​​of the other two transactions, and this process is repeated until all transactions in the block are combined and hashed to generate a Merkle root, which is used in the header of the block 602-608. If any single transaction in the block is tampered with, a different Merkle root will be generated because the Merkle root is the combination of the hashes of all transactions in the block.

[0087] That is, transactions can be hashed using a cryptographic hashing algorithm such as the algorithm discussed above, and the hash value of each transaction can be stored in a tree. As the tree is built, the hash values ​​of each adjacent node at the same level can be hashed together to create new nodes that exist at higher levels in the tree. Therefore, the node at the top of the tree, or the Merkle root, depends on the hash value of each transaction stored below it in the tree. Each transaction can include a data set. The data set can include identification data for the transaction, as well as transaction data that identifies the nature of the transaction and the transaction needs (e.g., input and output addresses, transaction values, document hash values, timestamps, transaction fee values, etc.).

[0088] To verify that a block is valid, a node can compare the Merkle root of a block with the Merkle root of the same block contained in other nodes' copies of the blockchain. Therefore, if the Merkle root is the same in every node's copy of the block, the Merkle root can be used as evidence of the transactions included in the block, and also as evidence that the block's contents have not been tampered with.

[0089] In one embodiment, a document stored "on" a blockchain is one that has been hashed according to a cryptographic hash algorithm (e.g., SHA-256), and the resulting output hash value has been included in a transaction in a block that has been accepted by network nodes as satisfying the consensus rules of the blockchain. In this way, the document can later be verified or validated by comparing the hash value of the document to the hash value stored on the blockchain. For example, if a collection of documents results in a SHA-256 hash value recorded on the blockchain on a certain date, then the blockchain provides cryptographic evidence that the document existed on that date.

[0090] One way to store a document on a blockchain is to broadcast a transaction including a hash of the document to the network, and if the transaction satisfies all of the consensus rules of the network, the transaction will be included in the block. In some embodiments, the blockchain is a permissioned ledger, meaning that only authorized network participants can broadcast transactions. In other embodiments, only some authorized network participants can conduct certain transactions. For example, when a field device determines a property of a product (e.g., the temperature of a product, the volume of a product, the mass of a product, the density of a product, the pressure of a product, etc.), product parameter data indicating the properties of a product generated in the process plant 10 can be uploaded to the blockchain 600 by the field device. Only a cryptographic hash of the data can be included in the blockchain 600, so that the blockchain can be used to verify the data even if the data is obtained by an off-chain party.

[0091] The verification network node can verify that the signed transaction or signed message is signed by a private key corresponding to the published public key owned by the field device that collects the measurement results. In at least one embodiment, a valid identity certificate can be used as a consensus rule by the blockchain network. In this way, any transaction that attempts to add new product parameter data without an encrypted identity certificate that matches the identity authorized to add new product parameter data will be rejected by the network because it does not meet the consensus rules. A public key / private key pair can be assigned to each field device in the process plant 10, which is identified in the blockchain network as corresponding to the field device. In addition, each field device can be authorized to collect certain types of measurement results. For example, a first field device may be authorized to collect temperature measurements of a product, while a second field device may be authorized to collect volume measurements indicating the volume of the manufactured product. If the verification network node receives a transaction regarding product parameter data that is not from an authorized field device, or a transaction including a type of measurement result that the field device is not authorized to collect, the verification network node will reject the transaction.

[0092] Figure 6B Shown includes Fig. 6A Another exemplary distributed ledger 650 with an architecture different from that described in Fig. 6A Similar to the distributed ledger 600 in Figure 6B The distributed ledger 650 in the process control system includes a blockchain 660 with blocks 662-668 of transactions in the process control system. The blockchain 660 can be referred to as the main blockchain in the distributed ledger 650. In addition to the main blockchain 660, the distributed ledger 650 also includes multiple side blockchains 670, 680 or side chains maintained by different process plants with blocks 672-676, 682-686 of transactions. For example, the side chain 670 can be maintained by two process plants: plant A and plant B to record transactions related to events that occur within or between the two process plants. These transactions can include: when plant A delivers a product to plant B, plant B sends a payment to plant A in the form of a token value. The side chain 680 can also be maintained by two process plants: plant C and plant D to record transactions related to events that occur within or between plant C and plant D. These transactions can include plant D recording the amount of oil received from plant C during a specific time period.

[0093] In some embodiments, the main blockchain 660 is maintained by several process plants including plant AD and several other process plants. Also in some embodiments, side chains 670, 680 interact with the main blockchain 660 to provide at least some transactions in their respective blocks 672-676, 682-686 to the main blockchain 660. In this way, the side chains 670, 680 can include data from transactions related to the process plants that maintain them. The main blockchain 660 can include data from transactions related to each process plant. In addition, the side chains 670, 680 can include private or sensitive data that is not meant to be shared outside the process plant that maintains a particular side chain. Non-private or sensitive data from the side chain 670 can be provided to the main blockchain 660, while private or sensitive data is not provided to the main blockchain 660. For example, the side chain 670 can execute a smart contract between factory A and factory B, which transfers the token value from factory A to factory B when factory A receives products that meet certain quality standards from factory B. Factories A and B may not want to disclose all terms of the smart contract to the public or a large number of process plants by deploying the smart contract on the main blockchain 660, or may not want every measurement result of a product attribute to be provided to the public or a large number of process plants. In addition, as more transactions are added to the main blockchain 660, the memory storage requirements of the main blockchain 660 increase. Therefore, it can reduce the memory requirements of the nodes in the validating distributed ledger network to store some transactions outside the main blockchain 660. In any case, when the smart contract determines that factory A has received products that meet the necessary quality standards from factory B, the transaction that transfers the token value from factory A to factory B can be provided to the main blockchain 660.

[0094] In some embodiments, the main blockchain 660 is a public blockchain, which means that any party can view the distributed ledger, submit new information to be added to the ledger, or join the network as a verification node. Sidechains 670, 680 are private or permissioned blockchains that keep chain data private among a set of entities authorized to participate in the side blockchain network (for example, sidechain 670 can be private between factory A and factory B). In other embodiments, the main blockchain 660 is also a permissioned blockchain, but the main blockchain has a larger number of entities authorized to participate in the blockchain network than the sidechains 670, 680. For example, the main blockchain 660 can be private between a large number of process plants including factory AD and several other process plants, while the sidechain 670 is private between factory A and factory B.

[0095] In addition to or in lieu of sidechains, the distributed ledger 650 may include other forms of transactions that occur off-chain and are not part of the main blockchain 660. For example, two parties such as factory A and factory B may open a payment channel where an initial transaction exchanging a threshold amount of tokens between factory A and factory B is provided to the main blockchain 660. Factory A and factory B may then transact with each other without recording anything on the main blockchain 660, as long as they send portions of the threshold amount back and forth to each other and no transaction results in one of the process plants having more than the threshold amount. When the two process plants have completed their transactions with each other, they may close the payment channel and provide a final amount of tokens for each process plant in the main blockchain 660. For example, factory A and factory B may open a payment channel when factory A sends two tokens to factory B. Factory B may then send one token back to factory A so that each process plant has one token, factory B may send 0.5 tokens back to factory A, and so on, as long as neither process plant has more than two tokens. In other embodiments, the distributed ledger 650 may include multiple blockchain layers, including separate blockchains that operate independently of each other. For example, the first blockchain layer can record transactions related to the supply chain, while the second blockchain layer can record transactions related to the exchange of certificates. The first blockchain layer can be public, while the second blockchain layer can be private, or vice versa.

[0096] In addition to protecting privacy via sidechains or off-chain transactions, in some embodiments, transactions can be made on a public blockchain, such as Fig. 6A Privacy is preserved on the illustrated blockchain 600. For example, transactions in the blockchain 600 may be obfuscated using various cryptographic techniques to obfuscate the identities of the parties to the transaction and the amounts transacted.

[0097] Figures 7A-7C Shown includes Fig. 6A Another exemplary distributed ledger 700 with an architecture different from that described in . Figures 7A-7C The distributed ledger 700 in includes multiple local blockchains 710, 720, each of which is maintained by a different party or process plant. Each local blockchain 710, 720 includes blocks 712-716, 722-726 of transactions in the process control system. For example, multiple process plants can share resources, such as oil from an oil pipeline, electricity from a power generation system, products transported by rail, car, sea or air, products through liquid, gas, steam, fuel or material pipelines, or water from a water distribution system. Field devices in plant A can collect measurements about shared resources, such as the amount of oil obtained from a pipeline, and broadcast the measurement data in transactions to the local blockchain of plant A. Similarly, field devices in plant B can collect measurements about shared resources and broadcast the measurement data in transactions to the local blockchain of plant B.

[0098] like Figure 7B As shown, transactions from each local blockchain 710, 720 are provided to a global blockchain 730 for the respective parties or process plants, wherein the global blockchain 730 is maintained by multiple process plants and / or via a cloud service having multiple cloud computing systems. For example, blocks from the local blockchain 710 for plant A are provided to the global blockchain 730 for plant A, blocks from the local blockchain 720 for plant B are provided to the global blockchain for plant B, and so on. After a threshold time period or period, the blocks of transactions are provided from the local blockchain to the corresponding global blockchain. In this way, the validation nodes within the specific process plant maintaining each local blockchain can delete or prune blocks from the local blockchain that have been provided to the global blockchain except for the most recent blocks to reduce storage requirements.

[0099] like Figure 7BAs shown, during period E (reference numeral 740), block N (reference numeral 742), block N+1 (reference numeral 746), and block N+2 (reference numeral 748) are added to the local blockchain 710 for factory A. After the threshold time period of period E expires, the verification node maintaining the local blockchain 710 for factory A provides blocks N-N+2 (reference numerals 742-746) to the global blockchain 730 for factory A. Then, the verification node maintaining the local blockchain 710 for factory A deletes or prunes block N (reference numeral 742) and block N+1 (reference numeral 744) from the local blockchain 710 to reduce storage requirements. The local blockchain 710 at this time only includes the most recent block, block N+2 (reference numeral 746). Then during period E+1 (reference numeral 750), block N+3 (reference numeral 752) and block N+4 (reference numeral 754) are added to the local blockchain 710. After the threshold time period of epoch E+1 expires, the validating node maintaining the local blockchain 710 for plant A provides blocks N+3-N+4 (reference numerals 752-754) to the global blockchain 730 for plant A. The validating node maintaining the local blockchain 710 for plant A deletes or prunes blocks N+2-N+3 (reference numerals 746, 752) from the local blockchain 710. The local blockchain 710 at this point includes only the most recent block, block N+4 (reference numeral 754).

[0100] like Figure 7C As shown, the verification node maintaining the global blockchains (such as the global blockchain 730 for factory A and the global blockchain 770 for factory B) combines the global blockchains 730, 770 to create a super blockchain 760 with state blocks 762, 764. Each state block 762, 764 includes each block from the global blockchains 730, 770 within a specific time period. For example, state block K (reference numeral 762) includes corresponding blocks N, N+1, and N+2 from each global blockchain 730, 770. State block K+1 (reference numeral 764) includes corresponding blocks N+3, N+4, and N+5 from each global blockchain 730, 770.

[0101] To cryptographically link blocks and transactions together, each state block 762, 764 in the super blockchain 760 organizes its transactions into a Merkle tree. If any single transaction in the state block is tampered with, a different Merkle root will be generated because the Merkle root is a combination of the hash values ​​of all transactions in the block. The Merkle root of each state block 762, 764 is included in the header of the state block 762, 764.

[0102] Figures 7A-7CThe distributed ledger architecture 700 with local blockchains, global blockchains, and super blockchains described in allows competing entities to verify the accuracy of measurement data. For example, if plant A reports to plant B that plant A obtained 30,000 gallons of oil from an oil pipeline shared between the two entities, plant B can obtain measurement data from the super blockchain to verify the accuracy of this measurement. The measurement data can also be cryptographically verified within the super blockchain 760 by calculating the expected Merkle root for the header of the state block that includes the measurement data, and comparing the actual Merkle root in the header of the state block to the expected Merkle root. This allows competing entities to analyze the super blockchain 760 to verify that the state blocks 762, 764 in the super blockchain 760 have not been tampered with.

[0103] Smart Contracts in Process Control Systems

[0104] As described above, a process control system can deploy a smart contract to a distributed ledger to exchange value, for example, upon receiving a product in good condition. Smart contracts can also be deployed to a distributed ledger to allow machines, such as field devices, to conduct transactions on their own without human intervention.

[0105] Figure 8 An exemplary smart contract state 806 in a distributed ledger network within a process control system is shown. Figure 8 Includes blockchain 802, transaction block 804, and secure write request smart contract state 806. Smart contracts can be deployed by any participant in a distributed ledger network or blockchain network (e.g., plant operator, configuration engineer, process system designer, etc.) to establish contract state 806, for example, for secure write requests. Deployed smart contracts can expose methods and data to other participants in the blockchain network. Some data in the smart contract state can be private data that can only be changed by calling the method of the smart contract, or only by authorized blockchain participants. One way to change the state of the smart contract is to broadcast the transaction to the distributed ledger network. If the broadcasted transaction meets the consensus rules, the network validator can include the transaction in the block. Including a transaction that sends data to a smart contract in the blockchain can cause the verification node to update the state database of the smart contract, thereby allowing network participants to access a rich state mechanism to manage secure write requests and ultimately write parameter data to the safety instrument system (SIS) device.

[0106] The secure write request smart contract state 806 may include multiple pieces of data identifying an operator submitting a secure write request, a computing device used by the operator to submit the secure write request, and / or a SIS device that is the target of the secure write request. In some embodiments, the operator may be identified by a cryptographic public key assigned to the operator's electronic wallet. If the operator's electronic wallet is operated on the operator's computing device, the operator's computing device may be identified by the same cryptographic public key as the operator. In other embodiments, the operator's computing device may be identified by other cryptographic public keys known to belong to the operator's computing devices by other network participants.

[0107] In some embodiments, the contract owner can select a unique ID for the SIS device so that subsequent transactions and data sent to the smart contract can identify the SIS device by the ID number. For example, each SIS device can have a different unique identifier in the smart contract. The contract owner can also specify the identifier of the operator and / or computing device that is authorized to perform secure write operations. Subsequent data sent to the smart contract can include a message signed by a private key corresponding to the public key that identifies the operator and / or computing device in the smart contract, thereby providing cryptographic proof that the transaction was initiated by an authorized operator and / or authorized computing device. Private and public keys can be managed separately by only the operator / computing device to minimize the attack surface of any attacker who may attempt to forge transactions (for example, the operator / computing device generates a public / private key pair offline and only provides the public key to other network participants). The private key of the operator and / or computing device can be generated based on a securely stored seed value (for example, on a physical piece of paper or multiple copies of a piece of paper) so that the private key can be recovered in the event of data loss.

[0108] In order to write parameter data to the SIS device, the secure write request smart contract state 806 can obtain evidence of the secure write request. The evidence for the secure write request can include the name of the parameter to be changed in the SIS device and / or the path information of the parameter. The evidence can also include the new parameter value, and in some embodiments, the evidence can include a cyclic redundancy check (CRC) value or other error checking value and the new parameter value to ensure that the parameter information is intact and not corrupted. In some embodiments, in response to receiving the parameter information, the smart contract can provide a confirmation dialog box to the operator's computing device, which includes the name of the SIS device, the name and / or path of the parameter to be changed in the SIS device, the new parameter value, and a confirmation button for the operator to confirm the secure write request. In this case, the evidence can include an indication of whether the operator selected the confirmation button.

[0109] The operator and / or the operator's computing device may broadcast a transaction including the evidence to the blockchain 802. The evidence may be cryptographically signed to provide cryptographic proof of identity that the evidence is from an operator and / or the operator's computing device that is authorized to perform the secure write request. Thus, the smart contract may compare the provided identity to a list of operators and / or computing devices that are authorized to perform the secure write request. In some embodiments, the smart contract may compare the provided identity to a list of operators and / or computing devices that are authorized to perform the secure write request on a particular SIS device that is the target of the secure write request.

[0110] Another aspect of the secure write request smart contract state 806 is the smart contract data. Smart contract data can be considered as private and public data in an object created according to an object-oriented programming paradigm, because the smart contract data can be updated directly from outside the object, or the smart contract data can be updated only in a limited manner, such as by calling a method of the smart contract. The smart contract data can include the name and / or path of the parameter to be changed in the SIS device, as well as the new parameter value. In some embodiments, the smart contract data can include an indication of whether the parameter information has been received in full. For example, a transaction including the parameter to be changed and the parameter information can also include a CRC value or other error check value. The smart contract can generate an expected CRC value based on the parameter to be changed and the parameter information, and compare the expected CRC value with the received CRC value. If the expected CRC value matches the received CRC value, the smart contract can determine that the parameter information has been received in full. Also in some embodiments, the smart contract data can include an indication of whether the secure write request has been confirmed. For example, if the smart contract receives a transaction indicating that the operator has selected a confirmation button through an operator and / or the operator's computing device, the smart contract can determine that the secure write request has been confirmed.

[0111] For example, Figure 8 As shown, the smart contract data may include a parameter to lock / unlock the SIS device, a parameter value "1" or "locked" indicating that the parameter to lock the SIS device is set, an acknowledgement value "1", "yes", or "true" indicating that the secure write request has been acknowledged, and a received data integrity value "1", "yes", or "true" indicating that the parameter information is not corrupted. Therefore, the smart contract may determine that a new parameter value should be provided to the SIS device. The smart contract may then provide the parameter information to the SIS device or a controller communicatively coupled to the SIS device to perform a secure data write.

[0112] In some embodiments, when the operator and / or computing device that sends the secure write request is authorized to perform secure data writes to the target SIS device, the parameter information is not damaged, and the secure write request is confirmed, the secure write request smart contract can provide parameter information to the target SIS device or a controller that is communicatively coupled to the target SIS device. In other embodiments, the secure write request smart contract does not determine whether the parameter information is received in full. Alternatively, in response to receiving the secure write request, the secure write request smart contract provides a first instance of parameter information including a parameter name and / or parameter path, a new parameter value, and a CRC value to the target SIS device or controller. In response to receiving confirmation of the secure write request, the secure write request smart contract also provides a second instance of the parameter information to the target SIS device or controller. The controller or target SIS device then determines whether the parameter information in the two instances is the same and whether the parameter information has been completely received. When the parameter information in the two instances is the same and the parameter information has been completely received, the controller or target SIS device writes the new parameter value of the parameter to the target SIS device.

[0113] Although Figure 8 A smart contract state 806 for a secure write request is shown, which is only an example smart contract for ease of illustration. Participants in the distributed ledger network (e.g., plant operators, configuration engineers, process control system designers, etc.) can deploy any suitable smart contract related to process control.

[0114] In another example, a smart contract can be deployed that obtains device information of a device that experiences a fault within the process plant 10, and in response to receiving a request to share device information, provides the device information to the device supplier. Specifically, when a device within the process plant 10 experiences a fault, such as a process plant entity, the device can send a transaction to the address of a smart contract stored on a distributed ledger. The transaction can be cryptographically signed to provide encrypted proof of identity that the transaction is from the device. In other embodiments, the process plant entity can send an indication of the fault to a controller, field device, or other process control device, which acts as an evidence oracle and generates a transaction. In any case, the transaction can include device information of the device, such as identification information of the device, brand, model, and year of the device, maintenance history of the device, type of fault, damaged parts within the device, etc.

[0115] In some embodiments, the smart contract transmits the device information to a computing device of a maintenance personnel in the process plant 10 for the maintenance personnel to review the device information. After reviewing the device information, the maintenance personnel may determine that the equipment supplier needs to review the device information to further investigate the failure and / or provide a replacement device or replacement part. Therefore, the computing device of the maintenance personnel may generate a transaction requesting the smart contract to provide the device information to the equipment supplier. The transaction may be cryptographically signed to provide cryptographic proof of identity that the transaction is from the maintenance personnel. In response to determining that the request to provide the device information to the equipment supplier is from an authorized maintenance personnel, the smart contract may provide the device information to the computing device of the equipment supplier.

[0116] Another example smart contract is a smart contract that obtains a token value from a first process plant, determines that a product that meets certain quality standards is transferred from a second process plant to the first process plant, and provides the token value to the second process plant. In some embodiments, the smart contract can receive an indication that a product has been received at the first process plant from an evidence oracle such as a field device in the first process plant. The field device can also provide parameter data related to the product, which the smart contract compares with a set of quality indicators to determine whether the product meets the quality standards. If the product meets the quality standards, the smart contract provides the token value to the second process plant. Otherwise, the smart contract can return the token value to the first process plant.

[0117] Types of transactions recorded in distributed ledgers in process control systems

[0118] The process control system distributed ledger may include many different types of transactions related to process control. These transactions may include: 1) transactions related to the delivery or receipt of products at the process plant 10 and the quantity delivered / received; 2) transactions related to software or firmware updates at devices within the process plant 10 (e.g., operator workstations, server devices, controllers, I / O devices, network devices, field devices, etc.); 3) transactions related to quality control, production or regulatory reporting in the process plant 10; 4) transactions for recording process plant data; 5) transactions for recording the production and sales custody chain through product tracking data.

[0119] In some scenarios, for example, transactions are provided to a smart contract to change the smart contract state. In other scenarios, transactions are not provided to a smart contract but are simply recorded in a distributed ledger as a secure, immutable and trustless record of information related to one or more process plants.

[0120] Transactions related to the delivery or receipt of products and quantities delivered / received

[0121] Fig. 9An exemplary transaction 906 is shown representing a proof transaction reporting the amount of oil received from the oil pipeline at the process plant 10. Fig. 9 The example transaction 906 in reports the amount of oil from the oil pipeline, but this is only an example for ease of illustration. Other materials or products from other sources may also be reported, such as electricity from a power generation system, products transported by rail, car, sea or air, products through liquid, gas, steam, fuel or material pipelines, or water from a water distribution system. In any case, transaction 906 can be generated by a field device that acts as an oracle of evidence. When the field device detects oil flowing through the valve, the field device broadcasts transaction 906 to blockchain 902 for inclusion in a block such as block 904.

[0122] Transaction 906 may include a transaction ID and an initiator such as field device 456 in plant A (identified by cryptographic proof of identity). Transaction 906 may also include identification information related to the product, the provider of the product (e.g., an oil producer), and information related to the quantity of the product received. For example, the field device may be a flow rate sensor that determines the volume of oil obtained at plant A over a specific time period (e.g., an hour, a day, etc.) and includes the volume in the transaction. In other embodiments, the field device may include multiple flow rates for various time periods in a series of transactions, and the flow rate as a function of time may be used to determine the amount of oil received at plant A. In addition, transaction 906 may include an encrypted hash value of information about the event, product identifier, and product provider identifier. In another embodiment, the information about the event, product identifier, and product provider identifier is not stored as an encrypted hash value, but is directly accessible in block 904 by an observer or other network participant.

[0123] Although in this example, a field device of the process plant 10 that receives the product generates a transaction, a field device of the process plant 10 that provides the product or another entity may generate a transaction. The transaction may be generated in addition to or in lieu of a transaction performed by a field device of the process plant 10 that receives the product. Transactions related to software or firmware updates at devices within a process plant

[0124] To prevent the introduction of unauthorized software or firmware into the process plant 10, software and firmware updates to devices in the process plant 10 may be digitally recorded in a distributed ledger, such as the distributed ledger described above. The distributed ledger may maintain a record of each software and firmware update to devices in the process plant 10, including the time and date of the update, the identity of the user performing the update (via cryptographic identification), the change to the previous version of the software, and / or the new version of the software. The server device 12 or other computing device within the process plant 10 may continuously or periodically (e.g., once per second, once per minute, once per hour, once per day, etc.) obtain the current version of the software and firmware running in the devices in the process plant 10. The server device 12 may also obtain transactions from the distributed ledger and compare the current software or firmware in the device with the latest version of the software or firmware recorded in the distributed ledger. In some embodiments, the distributed ledger stores a cryptographic hash value of the new version of the software or firmware, and compares the current software or firmware executed in the device with the cryptographic hash value to verify that the software or firmware has not been tampered with.

[0125] If the current software or firmware in the device does not match the latest version of the software or firmware recorded in the distributed ledger, the server device 12 can prevent the device from executing the current software or firmware. In some embodiments, the server device 12 can restore the software or firmware in the device to a previous version, for example, by downloading the previous version to the device. In this way, unauthorized users cannot tamper with the software or firmware executed in the process plant 10.

[0126] Fig.10 An exemplary transaction 1006 is shown representing a transaction for evidence reporting a software or firmware update in a device within a process plant 10. The transaction 1006 may be generated by a device receiving the update, such as an operator workstation, another user interface device 8, a server device 12, a controller 11, an I / O device 26, 28, a network device, a field device 15-22, 40-46, etc. The network devices in the process plant 10 may include, for example, a wireless gateway 35, a router 58, a wireless access point 7a, 55, an edge gateway, a wireless adapter 52, etc.

[0127] Transaction 1006 may include a transaction ID and the initiator of modifying the software or firmware, such as John Doe (identified by cryptographic proof of identity). Transaction 1006 may also include identification information (operator workstation 1234) of the device used to execute the software or firmware (identified by cryptographic proof of identity), including a version number and a description of the time and date of the update ("Updated to version 10.3.1.4 at 6:02 am on January 15, 2019"). In addition, transaction 1006 may include a cryptographic hash value of the software instructions for the new version of the software. In another embodiment, the new version of the software is not stored as a cryptographic hash value, but is directly accessible in block 1004 by an observer or other network participant. In some embodiments, the consensus rules indicate that only authorized users can record software or firmware updates on the distributed ledger. Therefore, when broadcasting transaction 1006 to the distributed ledger, if the initiator is an authorized user, the verification node verifies transaction 1006. If the initiator is not an authorized user, transaction 1006 is not included in the distributed ledger, and the update to the software will not match the latest version of the software recorded in the distributed ledger.

[0128] In an exemplary scenario, at 6:03 a.m. on January 15, 2019, a server device 12 in a process plant 10 obtains the state of the software executed in the operator workstation 1234 and compares the software with the cryptographic hash value of the software instructions for the new version of the software in the distributed ledger, for example, by performing cryptographic hashing on the software instructions executed in the operator workstation 1234. If the cryptographic hash values ​​are the same, the server device 12 determines that the software has not been tampered with. On the other hand, if the cryptographic hash values ​​are different, the server device determines that the software has been tampered with and prevents the operator workstation 1234 from executing the software in its current state. The server device 12 then downloads the previous state of the software to the operator workstation 1234, and the operator workstation 1234 resumes executing the software in its previous state.

[0129] Transactions related to quality control, production or regulatory reporting in process plants

[0130] Process plants have reporting and recordkeeping requirements to comply with regulatory agencies such as the Environmental Protection Agency (EPA). For example, the EPA has enacted leak detection and repair (LDAR) regulations to minimize emissions of volatile organic compounds and hazardous air pollutants from leaking equipment, such as valves, pumps, and connectors in process plants. In order to comply with regulations and provide secure, immutable, and trustless records, regulatory data can be recorded in a distributed ledger. For example, in response to a triggering event such as an alarm, error, leak, maintenance event, process milestone, corrective action, etc., a process control element such as a field device, controller, or process plant entity can generate a transaction including data from the triggering event, such as the time the event occurred, the duration of the event, the process parameter value of the process plant entity involved in the event, the product parameter value of the product involved in the event, etc. The regulatory data is then recorded in a distributed ledger so that the regulatory agency can review the data.

[0131] In some embodiments, when a triggering event occurs, one of the process control elements detects the triggering event. The process control element then notifies the other process control elements of the triggering event and assigns a unique identifier to the triggering event. In this manner, each process control element can collect measurements related to the triggering event and broadcast transactions to a distributed ledger, where each transaction includes the same unique identifier for the triggering event.

[0132] In some embodiments, the regulatory data is recorded in a public blockchain so that anyone can view the regulatory data from the process plant 10. In other embodiments, the regulatory data is recorded in a private or permissioned blockchain accessible to the process plant 10 and the regulatory body. In other embodiments, the regulatory data is recorded in a private or permissioned blockchain accessible to multiple process plants in a process plant network and the regulatory body.

[0133] Fig.11 An exemplary transaction 1106 representing an evidence transaction for reporting process parameter or product parameter data is shown. The transaction 1106 may be generated by a process plant entity, which may be a device within the process plant 10 that is used to contain, transform, produce, or transfer a portion of a process of a physical material, such as a valve, tank, mixer, pump, heater, etc.

[0134] Transaction 1106 may include a transaction ID and the initiator (heater Y-001) of collecting product or process parameter measurements (identified by cryptographic proof of identity). Transaction 1106 may also include identification information related to the product, product parameter data (e.g., the temperature of the product has been maintained at 100°C for 2 hours), and process parameter data (e.g., the temperature in heater Y-001 is 120°C). When transaction 1106 is generated in response to a triggering event, transaction 1106 may also include identification information for the triggering event and event data from the triggering event, such as the time of the triggering event, the duration of the triggering event, and / or a description of the triggering event. In some scenarios, multiple process plant entities generate transactions in response to the same triggering event and communicate with each other to assign a unique identifier to the triggering event. In this way, parties such as regulators reviewing distributed ledgers can view each transaction associated with the same triggering event.

[0135] In addition, transaction 1106 may include encrypted hash values ​​of product and / or process parameter data and data related to the triggering event. In another embodiment, product parameter data, process parameter data, and other data related to the triggering event are not stored as encrypted hash values, but can be directly accessed by an observer or other network participant in block 1104.

[0136] As described above, triggering events may include alarms, errors, leaks, maintenance events, corrective actions, and the like. In an example scenario, the triggering event may be a leak in the process plant 10 caused by the opening of a safety valve. When the pressure in the process control system exceeds a threshold pressure amount, the safety valve may open, or the safety valve may open in proportion to the pressure detected at the valve. When the safety valve opens, the safety valve or one or more other field devices may detect the time of opening, the duration of opening, the size of opening, the pressure in the safety valve when the safety valve opens, the flow rate of the fluid leaking from the safety valve, and / or the properties of the fluid, such as the temperature of the fluid, the type of the fluid, and the like. In some embodiments, the amount of fluid leaking from the safety valve may also be determined based on the flow rate of the safety valve, the size of opening, and the duration of opening. The safety valve and / or one or more other field devices may then generate a transaction, similar to transaction 1106, including the same unique identifier for the triggering event of the leak caused by the opening of the safety valve, and / or the same description for the triggering event. Each transaction may also include process parameter data, such as the time of opening, the size of opening, the pressure in the safety valve, the flow rate of the fluid leaking from the safety valve, and the like. The transaction may also include product parameter data, such as properties of the fluid. The device generating the transaction then broadcasts the transaction to the distributed ledger network for a validating node (e.g., an edge gateway) to confirm that the transaction is valid and include it in the distributed ledger.

[0137] A regulator reviewing an event can request and obtain event data from the distributed ledger included in the transaction with the triggering event identifier. The regulator’s computing device (e.g., Figure 2 The computing device 235 shown) can present the event data on the user interface. In other embodiments, the distributed ledger includes an encrypted hash value of the event data, which is provided to the computing device 235 of the regulatory body in response to a request for authentication event data. The event data is obtained from other data sources (e.g., a database that is communicatively connected to the server device 12 in the process plant 10). The computing device 235 of the regulatory body then calculates the encrypted hash value of the obtained event data and compares the encrypted hash value of the obtained event data with the encrypted hash value of the event data from the distributed ledger. If the encrypted hash values ​​are the same, the computing device 235 of the regulatory body determines that the event data from the database has not been tampered with. Otherwise, the computing device 235 of the regulatory body determines that the event data from the database is unreliable.

[0138] Transactions that record process plant data

[0139] In addition to recording process parameter data and product parameter data in transactions related to triggering events, process and product parameter data can also be included in transactions unrelated to triggering events, for example, to maintain accurate records of the operation of the process plant 10. Other types of process plant data can also be included in transactions, such as configuration data, user interaction data, maintenance data, commissioning data, plant network data, product tracking data, or any other suitable data generated in or related to one or more process plants. User interaction data can include operations performed by an operator or configuration engineer at, for example, an operator workstation. The operator can adjust set points, respond to alarms, etc. through user controls at the operator workstation, which can be included in the transaction as user interaction data. In this way, when a competing entity questions the quality of a product manufactured in the process plant 10, the process plant 10 can obtain process plant data from a distributed ledger related to the product. Then, the process plant 10 can review the records of each process plant entity involved in manufacturing the product, the parameter values ​​of the process plant entity when manufacturing the product, the parameter values ​​of the product at various stages in the manufacturing process, the triggering events that occurred during the manufacture of the product, etc. Thus, the process plant 10 can determine whether a product was properly manufactured to meet certain quality standards, or whether an anomaly occurred during production that caused the product to not meet quality standards.

[0140] Process plant data can also be used to perform root cause analysis on products. For example, a product may have a predicted shelf life, such as gasoline, whose half-life may be less than one month. In some embodiments, the computing device can predict the shelf life of the product based on the characteristics of the product, including process parameter data and product parameter data recorded in the distributed ledger when the product is manufactured. The computing device can also predict the shelf life of the product based on historical data of similar products with similar components and / or process parameter data and product parameter data during manufacturing. Specifically, the computing device can predict the shelf life of the product based on the average shelf life of the same type of products (e.g., gasoline).

[0141] The computing device may then increase or decrease the predicted shelf life from the average shelf life based on the quality of the components in the product. For example, the components may be classified as above average, average, or below average. Indications of the components may be stored in a database along with associated grades or quality scores. Components having a quality score below a first threshold score or ranking below a first threshold ranking may be classified as below average. Components having a quality score above a first threshold score and below a second threshold score or ranking above a first threshold ranking and below a second threshold ranking may be classified as average. Components having a quality score above a second threshold score or ranking above a second threshold ranking may be classified as above average.

[0142] The computing device may also increase or decrease the predicted shelf life based on properties of the product, such as temperature of the product, volume of the product, mass of the product, density of the product, pressure of the product, viscosity of the product, chemical composition of the product, etc. For example, the computing device may assign a quality score to each property and adjust the predicted shelf life based on each quality score.

[0143] In some embodiments, the computing device may generate a machine learning model to predict the shelf life of a product based on the actual shelf life of previous products, components in previous products, and attributes of previous products.

[0144] In addition, when the actual shelf life of a product is different from the predicted shelf life, the computing device can obtain process plant data related to the product from the distributed ledger to identify the reason. For example, the actual shelf life may be lower than the expected shelf life due to poor quality components in the product. In another example, the actual shelf life may be lower than the expected shelf life because a heater in the process plant 10 heats the product to an undesirable temperature.

[0145] Record chain of custody transactions through product tracking data

[0146] In order to provide an accurate record of the chain of custody of a product in a supply chain, a transaction may be generated, wherein the transaction includes identification information of the source or supplier of the product and the entity that handles the product (e.g., a manufacturer, a distributor, a distribution facility, a retailer, and a customer that purchases the product). Specifically, a transaction may include product tracking data having identification information of the product, identification information of the supplier / manufacturer of the product, identification information of the manufacturer / supplier of each component of the product, identification information of the entity that receives and handles the product in the supply chain, identification information of the retailer that sells the product, and / or identification information of the customer that purchases the product. When a product is delivered from one entity (e.g., a process plant) to another entity (e.g., a warehouse), the delivering entity may generate a transaction that includes identification information of the delivering entity, identification information of the receiving entity, and an indication that the product is being transferred to the receiving entity.

[0147] Thus, a user such as a customer can retrieve each transaction involving a particular product from the distributed ledger using the product's identification information via a user interface device. The user interface device can then display, through a user interface, an indication of the supplier or source of the product and the entity that handles the product (e.g., a manufacturer, distributor, distribution facility, retailer, and customer who purchased the product). The user interface device can also display, through a user interface, an indication of the components of the product. The user can then retrieve each transaction involving a particular component of the product from the distributed ledger using the identification information of the component. The user interface device can then display, through a user interface, an indication of the supplier or source of the component and the entity that handles the component (e.g., a manufacturer, distributor, distribution facility, etc.).

[0148] In some embodiments, product packaging may include a product identifier, such as a barcode or radio frequency identification (RFID) tag, which, when scanned, provides data from the distributed ledger for the product. For example, a user may scan the barcode or RFID tag with a mobile device and then be presented with an indication of the supplier or source of the product and the entity that handled the product on the mobile device.

[0149] Fig.12 A flow chart representing an exemplary method 1200 for recording data in a process control system using a distributed ledger is shown. The method 1200 may be performed by a field device 15-22, 40-46 within a process plant 10, a controller 11 within a process plant 10, or another computing device within the process plant 10 (e.g., an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, a network device 35, etc.).

[0150] At box 1202, data related to a process control element is obtained from a field device. The process control element may be a field device, a controller, or a process plant entity, such as a valve, a tank, a mixer, a pump, a heat exchanger, etc. The data may include process plant data, such as process parameter data for parameters of the process control element (e.g., tank fill level, pump speed, temperature in a heat exchanger), and product parameter data for products entering, leaving, in, and / or controlled by the process control element (e.g., temperature of the fluid in the tank, fluid flow rate leaving the valve). Then, at box 1204, a transaction is generated, which includes process plant data related to the process control element. The entity generating the transaction (e.g., a field device) signs the transaction with a cryptographic signature unique to the entity (box 1206), and expands the transaction with identity data of the entity (e.g., a public encryption key owned by the entity) (box 1208). For example, the transaction may be signed by a private encryption key corresponding to a public encryption key owned by the entity.

[0151] At block 1210, the transaction is transmitted to participants in the distributed ledger network. For example, a field device may broadcast the transaction to the distributed ledger network. A verification node, such as an edge gateway, may then confirm that the transaction is valid, add the transaction to a block of transactions, solve the cryptographic puzzle, and include the solution in a newly generated block as proof of the work done to generate the block. The verification node may then provide the newly generated block to each other verification node in the distributed ledger network to include the newly generated block in their respective copies of the distributed ledger.

[0152] In some embodiments, the validating nodes confirm transactions according to a consensus rule set and add transactions to a block when the transaction satisfies each consensus rule. For example, the consensus rules may include proof of identity provided by the initiator of the transaction so that only approved entities can initiate transactions to the distributed ledger. The consensus rules may require blocks and transactions to adhere to format requirements and provide certain meta information about the transaction (e.g., blocks must be smaller than a size limit, transactions must contain multiple fields, etc.). Any transaction that does not meet the consensus rules is ignored by the validating node that receives the transaction, and the transaction is not propagated to other nodes.

[0153] The validation node includes a transceiver to communicate with a field device, controller, or other computing device in the process plant 10 that broadcasts a transaction with distributed ledger data (e.g., process plant data). In addition, the validation node may include a memory for storing a copy of the distributed ledger, the memory including a state database for storing the state of smart contracts deployed on the distributed ledger. In addition, the validation node may include an application, such as a process data validator, that applies a consensus rule set to the distributed ledger data and, if the distributed ledger data satisfies the consensus rules, appends the distributed ledger data to the validation node's copy of the distributed ledger.

[0154] Fig.13 A flow chart representing an exemplary method 1300 for securely metering untrusted data in a process control system using a distributed ledger is shown. The method 1300 may be performed by a field device 15-22, 40-46 within a process plant 10, a controller 11 within a process plant 10, or another computing device within the process plant 10 (e.g., an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, a network device 35, etc.). The method 1300 may also be performed by a verification node such as an edge gateway or a combination of a field device and a verification node.

[0155] At box 1302, data related to a process control element is obtained from a field device. The process control element may be a field device, a controller, or a process plant entity, such as a valve, a tank, a mixer, a pump, a heat exchanger, etc. The data may include process plant data, such as process parameter data for parameters of the process control element (e.g., tank fill level, pump speed, temperature in a heat exchanger), and product parameter data for products entering, leaving, in, and / or controlled by the process control element (e.g., temperature of the fluid in the tank, fluid flow rate leaving the valve). Then, at box 1304, a transaction is generated, which includes process plant data related to the process control element. The entity generating the transaction (e.g., a field device) signs the transaction using a cryptographic signature unique to the entity, and expands the transaction using the entity's identity data (e.g., a public encryption key owned by the entity). For example, a transaction may be signed by a private encryption key corresponding to a public encryption key owned by the entity.

[0156] At box 1306, the transaction is transmitted to the participants in the distributed ledger network. There may be multiple local distributed ledgers, each of which is maintained by a different party or process plant. For example, the local distributed ledger network of plant A may be composed of an edge gateway within plant A. The edge gateway can record transactions, which include process plant data related to events and equipment within plant A. Then, the transaction is added to the local distributed ledger network for a threshold time period or period. After the threshold time period expires (box 1308), the verification node maintaining the local distributed ledger provides the transaction or block of transactions generated during the threshold time period to the global distributed ledger network (box 1310). The global distributed ledger network may include verification nodes across multiple process plants, such as a cloud service with multiple cloud computing systems. The verification node can maintain a global distributed ledger (e.g., a global blockchain) for each process plant. Then, the verification node in the local distributed ledger network can delete or prune the blocks that have been provided to the global distributed ledger except for the most recent block from the local distributed ledger. Validation nodes of the local distributed ledger can continue to generate blocks, broadcast the blocks to the global distributed ledger network after each epoch expires, and delete the local copy of the block after the block has been added to the global blockchain.

[0157] Also in some embodiments, each global blockchain for each entity or process plant is combined to create a super blockchain with state blocks. Each state block includes each block from the global blockchain corresponding to a specific time period or period.

[0158] Fig.14 A flow chart representing an exemplary method 1400 for recording quality control, production, or regulatory data in a process control system using a distributed ledger is shown. The method 1400 may be performed by a field device 15-22, 40-46 within a process plant 10, a controller 11 within a process plant 10, or another computing device within the process plant 10 (e.g., an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, a network device 35, etc.).

[0159] At block 1402, a triggering event related to quality control is detected by a process control element. The triggering event may be an alarm, an error, a leak, a maintenance event, a process milestone, a corrective action, etc. In some embodiments, an indication of the triggering event is provided to a field device, a controller, or other computing device within the process plant 10. In other embodiments, a field device, a controller, or other computing device detects the triggering event.

[0160] In any case, at box 1404, event data of the triggering event is obtained. The event data may include a unique identifier of the triggering event, a time of the triggering event, a duration of the triggering event, a description of the triggering event, identification information of the process control elements involved in the triggering event, identification information of the products manufactured by the process control elements during the triggering event, etc. Then, at box 1406, a transaction is generated, which includes the event data of the triggering event and / or the encrypted hash value of the event data. The transaction may also include identification information of the transaction initiator, product parameter data of the product when the triggering event occurs, process parameter data of the process control element during the triggering event, or any other suitable information. In some embodiments, multiple field devices, controllers or other computing devices within the process plant 10 can generate transactions related to the triggering event. For example, a first field device can generate a transaction including the temperature in the heater at the time of the triggering event, and a second field device can generate a transaction including the speed of the pump at the time of the triggering event.

[0161] At block 1408, the transaction is transmitted to the participants in the distributed ledger network. For example, a field device may broadcast the transaction to the distributed ledger network. A verification node, such as an edge gateway, may then confirm that the transaction is valid, add the transaction to a block of transactions, solve the cryptographic puzzle, and include the solution in a newly generated block as proof of the work done to generate the block. The verification node may then provide the newly generated block to each other verification node in the distributed ledger network to include the newly generated block in their respective copies of the distributed ledger.

[0162] As described above, the transaction may include a cryptographic hash of the event data of the triggering event, and / or a combination of the event data of the triggering event and other process plant data related to the triggering event. In addition to generating the transaction, the field device may also provide the event data or other process plant data related to the triggering event to the server device 12 for storage, for example, in a database (block 1410).

[0163] Then, to authenticate the event data, the event data stored in the database is compared with the encrypted hash value included in the distributed ledger (box 1412). If there is a match, the event data has not been tampered with. For example, a regulatory agency reviewing the event can request and obtain an encrypted hash value of the event data from the distributed ledger, which is included in a transaction with a triggering event identifier. The event data is obtained from other data sources (e.g., a database of a server device 12 in the process plant 10 that is communicatively coupled). The computing device of the regulatory agency then calculates the encrypted hash value of the obtained event data and compares the encrypted hash value of the obtained event data with the encrypted hash value of the event data from the distributed ledger. If the encrypted hash values ​​are the same, the computing device of the regulatory agency determines that the event data from the database has not been tampered with. Otherwise, the computing device of the regulatory agency determines that the event data from the database is unreliable. In other embodiments, a computing device within the process plant 10 obtains an encrypted hash value of the event data stored in the database and the event data from the distributed ledger, and compares the event data with the encrypted hash value to authenticate the event data.

[0164] Fig.15 A flow chart representing an exemplary method 1500 for recording the state of software or firmware in a process control system and connected instruments using a distributed ledger is shown. The method 1500 may be performed by a field device 15-22, 40-46 within a process plant 10, a controller 11 within a process plant 10, or another computing device within the process plant 10 (e.g., an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, a network device 35, etc.).

[0165] At box 1502, the current state of the software or firmware executed on the device of the process plant 10 is obtained. For example, a device within the process plant 10 that receives the software or firmware update can obtain a new version of the software or firmware. The device can be an operator workstation, another user interface device 8, a server device 12, a controller 11, an I / O device 26, 28, a network device 35, a field device 15-22, 40-46, etc. Then at box 1504, the device can generate a transaction, which includes an indication of the current state of the software or firmware. For example, the indication can be a cryptographic hash value of the software instructions for the new version of the software. The transaction can also include the initiator of the modification of the software or firmware identified by the cryptographic identity proof, the identification information of the device executing the software or firmware, the description of the update, the time and date of the update, etc.

[0166] At block 1506, the transaction is transmitted to participants in the distributed ledger network. For example, a computing device may broadcast the transaction to the distributed ledger network. A validating node, such as an edge gateway, may then confirm that the transaction is valid, add the transaction to a block of transactions, solve the cryptographic puzzle, and include the solution in a newly generated block as proof of the work done to generate the block. The validating node may then provide the newly generated block to each other validating node in the distributed ledger network to include the newly generated block in their respective copies of the distributed ledger.

[0167] In some embodiments, the validation nodes confirm transactions according to a consensus rule set, and when a transaction satisfies each consensus rule, the transaction is added to the block. In addition, in some embodiments, the consensus rules indicate that only authorized users can record software or firmware updates on the distributed ledger. Therefore, when broadcasting a transaction to the distributed ledger, if the initiator is an authorized user, the validation node confirms that the transaction is valid. If the initiator is not an authorized user, the transaction is not included in the distributed ledger, and the update to the software will not match the latest version of the software recorded in the distributed ledger.

[0168] In any case, in block 1508, the state of the software or firmware executed on the device in the process plant 10 is obtained. For example, the server device 12 or other computing device within the process plant 10 may continuously or periodically (e.g., once per second, once per minute, once per hour, once per day, etc.) obtain the current version of the software and firmware running in the device in the process plant 10. The state of the software or firmware obtained at the server device 12 is then compared with the cryptographic hash value of the software or firmware stored in the distributed ledger to verify that the software or firmware has not been tampered with (block 1510). If the state of the software or firmware matches the cryptographic hash value of the software or firmware stored in the distributed ledger, the software or firmware continues to execute on the device (block 1514). Otherwise, the server device 12 determines that the software has been tampered with and prevents the device from executing the software in its current state (block 1512). In some embodiments, the server device 12 then downloads the previous state of the software to the device, and the device resumes executing the software in its previous state.

[0169] Fig.16 A flow chart representing an exemplary method 1600 for creating a smart contract in a process control system using a distributed ledger is shown. The method 1600 may be performed by a field device 15-22, 40-46 within a process plant 10, a controller 11 within a process plant 10, or another computing device within the process plant 10 (e.g., an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, a network device 35, etc.).

[0170] At block 1602, a smart contract is generated related to one or more process plants. For example, when plant A receives a product from plant B that meets certain quality standards, the smart contract may transfer a token value from plant A to plant B. Another example smart contract in a process control system may include a secure write request smart contract that allows plant personnel to write parameter data to SIS devices in the process plant 10. Yet another example smart contract in a process control system may include a device information smart contract that obtains device information from a device that has experienced a fault and provides the device information to a device supplier in response to receiving a request to share the device information.

[0171] At block 1604, the smart contract is deployed to an address stored on a distributed ledger. The deployed smart contract may expose methods and data to other participants in the distributed ledger network. Some data in the smart contract state may be private data that can only be changed by calling methods of the smart contract, or only by authorized blockchain participants. One way to change the state of a smart contract is to broadcast a transaction to the distributed ledger network. If the broadcasted transaction satisfies the consensus rules, the network validator may include the transaction in the distributed ledger.

[0172] In some embodiments, a validating node such as an edge gateway executes code contained in a smart contract, and field devices act as evidence oracles and provide evidence transactions that change the state of the smart contract.

[0173] Fig.17 A flow chart representing an exemplary method 1700 for interacting with smart contracts in a process control system using a distributed ledger is shown. The method 1700 may be performed by a field device 15-22, 40-46 within a process plant 10, a controller 11 within a process plant 10, or another computing device within the process plant 10 (e.g., an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, a network device 35, etc.).

[0174] At block 1702, event data is obtained from an event occurring within the process plant 10. The event may be a product delivered by or received at the process plant 10, completion of a product manufactured at the process plant 10, a change in a product attribute, a change in a process parameter value, a triggering event (e.g., an alarm, an error, a leak, a maintenance event, a corrective action, a user interaction (e.g., a write request to a SIS device, a request to provide device information to a device supplier, or a request to transfer a token value when a particular product is received)), or any other suitable event occurring in the process plant 10. The event data may include process parameter data, product parameter data, configuration data, user interaction data, maintenance data, commissioning data, plant network data, product tracking data, or any other suitable data related to the event, such as a date and time of the event, a duration of the event, a description of the event, etc.

[0175] Then at block 1704, a transaction is generated that includes the event data and identification information of the entity that generated the transaction, such as a cryptographic public key assigned to the entity. The transaction may be cryptographically signed to provide cryptographic proof of the identity of the entity that generated the transaction. At block 1706, the transaction is transmitted to an address on a distributed ledger where the smart contract is deployed. In this way, a verification node such as an edge gateway changes the smart contract state based on the event data included in the transaction.

[0176] For example, when factory A receives a product that meets certain quality standards from factory B, the smart contract can transfer the token value from factory A to factory B. The field device in factory A can generate a transaction that includes event data related to product quality, such as identification information of factory A, identification information of the product, an indication of receiving the product from factory B, and product parameter data describing the attributes of the product (e.g., the temperature of the product, the volume of the product, the density of the product, the viscosity of the product, or the chemical composition of the product). The field device can provide the transaction to the address of the smart contract, and the verification node can change the smart contract state to include the product parameter data. In some embodiments, the smart contract compares the product attributes included in the product parameter data with the minimum threshold requirement set of the product to meet the appropriate quality standards. If the product meets the quality standards, the smart contract can transfer the token value to factory B. In some embodiments, the field device in factory B can generate a transaction that includes event data related to product quality, such as process parameter data, which describes the parameter values ​​of the process factory entities in factory B involved in manufacturing the product, where the parameter values ​​are collected when the product is manufactured.

[0177] Embodiments of the technology described in this disclosure may include any number of the following aspects, alone or in combination:

[0178] 1. A validation network node in a process plant on a distributed ledger network, comprising: a transceiver configured to communicate with one or more field devices that each perform a physical function to control an industrial process in the process plant, and to exchange distributed ledger data with a peer network node, the distributed ledger data including transactions with process plant data; a storage medium configured to store a copy of the distributed ledger; and a process data validator configured to apply a consensus rule set to the distributed ledger data received from the peer network node, the process data validator being further configured to: append the distributed ledger data received from the peer network node to the copy of the distributed ledger if the distributed ledger data satisfies the consensus rule.

[0179] 2. A verification network node according to aspect 1, wherein the distributed ledger data received from the peer node includes proof of identity of an entity generating a transaction with the process plant data.

[0180] 3. A verification network node according to any of the preceding aspects, wherein, in order to append distributed ledger data received from a peer node, the transaction validator is configured to: solve a cryptographic puzzle based on a transaction block; and add the solution to the cryptographic puzzle to the transaction block; append the transaction block to a copy of the distributed ledger; and transmit the transaction block to at least one of the peer network nodes in the distributed ledger network.

[0181] 4. A verification network node according to any of the preceding aspects, wherein the consensus rule set includes at least one of: formatting requirements for transactions or transaction blocks; a mechanism for determining which of the peer network nodes will add the next transaction or transaction block to the distributed ledger; or a cryptographic hash algorithm for hashing process plant data included in each transaction.

[0182] 5. A verification network node according to any of the preceding aspects, wherein the process data verifier is further configured to execute code in a smart contract and update a state database for the smart contract.

[0183] 6. The verification network node according to any one of the preceding aspects, wherein the process data validator is further configured to: ignore the distributed ledger data received from the peer network node if the distributed ledger data does not satisfy the consensus rule.

[0184] 7. The verification network node according to any of the preceding aspects, wherein the verification network node and the peer network node are devices within the same process plant.

[0185] 8. The verification network node according to any of the preceding aspects, wherein the verification network node and the peer network nodes are devices within a plurality of process plants.

[0186] 9. A method for recording data in a process control system using a distributed ledger maintained by multiple participants, the method comprising: obtaining process plant data related to process control elements within the process plant by a computing device; generating a transaction including the process plant data, wherein the transaction is stored in the distributed ledger; transmitting the transaction to at least one other participant of the distributed ledger network of the participant maintaining the distributed ledger.

[0187] 10. The method of aspect 9, wherein generating the transaction comprises: generating a cryptographic signature based on the transaction; and augmenting the transaction with the cryptographic signature.

[0188] 11. A method according to any one of Aspect 9 or Aspect 10, wherein the data is obtained from a field device within the process plant, and generating the transaction further includes: obtaining identity data of the field device; and augmenting the transaction with the identity data.

[0189] 12. The method according to any one of aspects 9-11 also includes: adding the transaction to the transaction block; and solving the cryptographic puzzle based on the transaction block; adding the solution to the cryptographic puzzle to the transaction block; and transmitting the transaction block to at least one other participant in the distributed ledger network.

[0190] 13. The method of any of aspects 9-12, wherein the data is product tracking data and generating the transaction comprises generating a transaction indicating that the product has been transferred from the process plant to another entity.

[0191] 14. A method according to any one of aspects 9-13, wherein the data is product parameter data, including at least one of the following: the temperature of the product, the volume of the product, or the chemical composition of the product, and wherein the product parameter data is stored in a distributed ledger to verify the authenticity of the product parameter data when the product is provided to another entity.

[0192] 15. A method according to any of aspects 9-14, wherein the distributed ledger network includes multiple layers and further includes: in a first instance, generating a transaction to be stored in a first layer of the distributed ledger; and in a second instance, generating a transaction to be stored in a second layer of the distributed ledger.

[0193] 16. A method according to any one of aspects 9-15, wherein the first layer of the distributed ledger is public and the second layer of the distributed ledger is private.

[0194] 17. A method according to any one of aspects 9-16, wherein the distributed ledger is at least one of the following: a blockchain, a tangle, a block lattice, or other directed acyclic graph.

[0195] 18. The method of any of aspects 9-17, wherein the process plant data comprises at least one of: product parameter data, configuration data, product tracking data, or process parameter data.

[0196] 19. The method of any of aspects 9-18, wherein generating a transaction comprises generating a transaction comprising a cryptographic hash value corresponding to the process plant data.

[0197] 20. A system for recording data in a process control system using a distributed ledger maintained by multiple participants, comprising: one or more devices set in a process plant, each of which performs a physical function to control an industrial process; and a computing device executed in the process plant, the computing device comprising: one or more processors; a communication unit; and a non-transitory computer-readable medium, which is coupled to the one or more processors and the communication unit and stores instructions thereon, which when executed by the one or more processors causes the computing device to perform the following operations: obtain process plant data related to one or more devices within the process plant; generate a transaction including the process plant data; and transmit the transaction to at least one other participant of the distributed ledger network of the participant maintaining the distributed ledger so as to verify the transaction and record the transaction in the distributed ledger.

[0198] 21. The system of aspect 20, wherein, to generate the transaction, the instructions cause the computing device to: generate a cryptographic signature based on the transaction; and augment the transaction with the cryptographic signature.

[0199] 22. A system according to any one of Aspect 20 or Aspect 21, wherein the data is obtained from a field device within a process plant, and, in order to generate a transaction, the instructions cause the computing device to perform the following operations: obtain identity data of the field device; and expand the transaction using the identity data.

[0200] 23. A system according to any one of aspects 20-22, wherein the instructions further cause the computing device to perform the following operations: add the transaction to a transaction block; and solve a cryptographic puzzle based on the transaction block; add the solution to the cryptographic puzzle to the transaction block; and transmit the transaction block to at least one other participant in the distributed ledger network.

[0201] 24. A system according to any of aspects 20-23, wherein the distributed ledger network includes multiple layers, and the instructions further cause the computing device to perform the following operations: in a first instance, generate transactions to be stored in a first layer of the distributed ledger; and in a second instance, generate transactions to be stored in a second layer of the distributed ledger.

[0202] 25. The system of any of aspects 20-24, wherein the first layer of the distributed ledger is a public blockchain and the second layer of the distributed ledger is a private blockchain.

[0203] 26. The system of any one of aspects 20-25, wherein the distributed ledger is at least one of: a blockchain, a tangle, a block lattice, or other directed acyclic graph.

[0204] 27. The system of any of aspects 20-26, wherein the process plant data comprises at least one of: product parameter data, configuration data, product tracking data, or process parameter data.

[0205] 28. The system of any of aspects 20-26, wherein generating the transaction comprises generating a transaction comprising a cryptographic hash value corresponding to the process plant data.

[0206] 29. A non-transitory computer-readable memory coupled to one or more processors and storing instructions thereon, which, when executed by the one or more processors, cause the one or more processors to perform the following operations: receive transactions including process plant data generated by one or more field devices, each of which performs a physical function to control an industrial process in the process plant; store a copy of a distributed ledger; apply a consensus rule set to the received transactions; if the received transactions satisfy the consensus rules, append one of the received transactions to the copy of the distributed ledger; and transmit the appended transaction to at least one peer network node that stores a copy of the distributed ledger.

[0207] 30. The computer-readable memory of clause 29, wherein the received transaction includes proof of identity of an entity generating the transaction.

[0208] 31. A computer-readable memory according to any one of Aspect 29 or Aspect 30, wherein, to append one of the received transactions, the instructions cause one or more processors to perform the following operations: solving a cryptographic puzzle based on a transaction block including the received transaction; adding the solution to the cryptographic puzzle to the transaction block; appending the transaction block to a copy of the distributed ledger; and transmitting the transaction block to a peer network node.

[0209] 32. A computer-readable memory according to any of Aspects 29-31, wherein the consensus rule set includes at least one of: formatting requirements for transactions or transaction blocks; a mechanism for determining which of the peer network nodes will add the next transaction or transaction block to the distributed ledger; or a cryptographic hash algorithm for hashing process plant data included in each transaction.

[0210] 33. The computer-readable memory of any one of aspects 29-32, wherein the instructions further cause the one or more processors to perform the following operations: if the distributed ledger data does not satisfy the consensus rules, ignoring the distributed ledger data received from the peer network node.

[0211] 34. The computer readable memory of any of clauses 29-33, wherein the peer network nodes are devices within the same process plant.

[0212] 35. The computer readable memory of any of aspects 29-34, wherein the peer network nodes are devices within a plurality of process plants.

[0213] 36. A method for securely measuring untrusted data in a process control system using a distributed ledger maintained by multiple participants, the method comprising: collecting measurement results of parameters within a process plant by field devices that perform physical functions to control an industrial process in the process; obtaining the measurement results of the parameters by a computing device; generating a transaction including the measurement results; and transmitting the transaction to at least one other participant in a local distributed ledger network of the participant maintaining the local distributed ledger; after a threshold time period, transmitting multiple transactions generated during the threshold time period to at least one participant in a global distributed ledger network of the participant maintaining a global distributed ledger.

[0214] 37. The method of aspect 36 further comprises: adding the transaction to a local block of transactions; solving a cryptographic puzzle based on the local block of transactions; adding the solution to the cryptographic puzzle to the local block of transactions; and transmitting the local block of transactions to at least one other participant in the local distributed ledger network.

[0215] 38. The method according to any one of aspects 36 or 37 further includes: after a threshold time period, transmitting the local block of one or more transactions generated during the threshold time period to at least one participant in the global distributed ledger network.

[0216] 39. The method of any of aspects 36-38, further comprising, after a threshold time period, reducing from the local distributed ledger network at least some of the plurality of transactions generated during the threshold time period.

[0217] 40. The method of any of aspects 36-39, wherein the global distributed ledger is a permissioned blockchain viewable by a plurality of entities operating a plurality of process plants.

[0218] 41. The method of any of aspects 36-40, wherein the parameter relates to a shared resource between a plurality of entities operating a plurality of process plants.

[0219] 42. A method according to any of aspects 36-41, wherein the global distributed ledger comprises a plurality of global distributed ledgers corresponding to a plurality of entities, each global distributed ledger comprising transactions stored in a local distributed ledger for the same corresponding entity as the global distributed ledger.

[0220] 43. The method of any one of aspects 36-42, further comprising: for transactions generated during a threshold time period, adding transactions from each of a plurality of global distributed ledgers to a status block for the transaction; solving a cryptographic puzzle based on the status block for the transaction; adding the solution to the cryptographic puzzle to the status block for the transaction; and transmitting the status block for the transaction to at least one other participant in the hyperblockchain network of participants maintaining the hyperblockchain.

[0221] 44. A method according to any of aspects 36-43, wherein the local distributed ledger is a private blockchain viewable by an entity operating the process plant.

[0222] 45. A method according to any of clauses 36-44, wherein generating a transaction including the measurement result comprises generating a transaction including a cryptographic hash value corresponding to the measurement result.

[0223] 46. ​​The method of any of aspects 36-45, wherein the shared resource between the plurality of entities operating the plurality of process plants is fluid in a fluid pipeline, and the measurement of the parameter is an amount of fluid obtained from the fluid pipeline by one of the plurality of entities.

[0224] 47. A system for securely metering untrusted data in a process control system using a distributed ledger maintained by multiple participants, comprising: one or more field devices, arranged in a process plant, each field device performing a physical function to control an industrial process, the one or more field devices being configured to collect measurement results of parameters within the process plant and provide the measurement results of the parameters to one or more edge gateway devices; and one or more edge gateway devices executed in the process plant, each edge gateway device comprising: one or more processors; a communication unit; and a non-transitory computer-readable medium, which is coupled to the one or more processors and the communication unit and stores instructions thereon, which when executed by the one or more processors, causes the edge gateway device to perform the following operations: obtain at least one of the measurement results of the parameter; generate a transaction including the measurement results; and transmit the transaction to at least one other edge gateway in a local distributed ledger network of edge gateways maintaining a local distributed ledger; and after a threshold time period, transmit multiple transactions generated during the threshold time period to at least one participant in a global distributed ledger network of participants maintaining a global distributed ledger.

[0225] 48. The system of aspect 47, wherein the instructions further cause the edge gateway to: add the transaction to a local block of transactions; solve a cryptographic puzzle based on the local block of transactions; add the solution to the cryptographic puzzle to the local block of transactions; and transmit the local block of transactions to at least one other edge gateway in the local distributed ledger network.

[0226] 49. A system according to any one of Aspects 47 or 48, wherein the instructions further cause the edge gateway to perform the following operations: after a threshold time period, transmit the local block of one or more transactions generated during the threshold time period to at least one participant in the global distributed ledger network.

[0227] 50. The system of any of aspects 47-49, wherein the instructions further cause the edge gateway to: after a threshold time period, reduce from the local distributed ledger network at least some of the plurality of transactions generated during the threshold time period.

[0228] 51. The system of any of aspects 47-50, wherein the global distributed ledger is a permissioned blockchain viewable by multiple entities operating multiple process plants.

[0229] 52. The system of any of aspects 47-51, wherein the parameter relates to a shared resource between a plurality of entities operating a plurality of process plants.

[0230] 53. The system of any of aspects 47-52, wherein the global distributed ledger comprises a plurality of global distributed ledgers corresponding to a plurality of entities, each global distributed ledger comprising transactions stored in a local distributed ledger for the same corresponding entity as the global distributed ledger.

[0231] 54. The system of any one of aspects 47-53 further comprises: a computing device located in a global distributed ledger network that maintains a global distributed ledger, comprising: one or more processors; a communication unit; and a non-transitory computer-readable medium coupled to the one or more processors and the communication unit and storing instructions thereon, which, when executed by the one or more processors, causes the computing device to perform the following operations: for transactions generated during a threshold time period, add transactions from each of a plurality of global distributed ledgers to a status block for the transaction; solve a cryptographic puzzle based on the status block for the transaction; add the solution to the cryptographic puzzle to the status block for the transaction; and transmit the status block for the transaction to at least one other participant in the hyperblockchain network of participants that maintains the hyperblockchain.

[0232] 55. The system of any of aspects 47-54, wherein the local distributed ledger is a private blockchain viewable by an entity operating the process plant.

[0233] 56. The system of any of aspects 47-55, wherein the transaction comprises a cryptographic hash value corresponding to the measurement result.

[0234] 57. A system according to any of aspects 47-56, wherein the shared resource between the plurality of entities operating the plurality of process plants is fluid in a fluid pipeline, and the measurement result of the parameter is the amount of fluid obtained from the fluid pipeline by one of the plurality of entities.

[0235] 58. A validation network node in a process plant on a local distributed ledger network, comprising: a transceiver configured to (i) communicate with one or more field devices, each of which performs a physical function to control an industrial process in the process plant and collects measurements of parameters within the process plant, and (ii) exchange local distributed ledger data with a peer network node, the local distributed ledger data including transactions having measurements of the parameters; a storage medium configured to store a copy of the local distributed ledger; and a process data validator configured to apply a consensus rule set to the distributed ledger data received from the peer network node, the process data validator further configured to: if the distributed ledger data satisfies the consensus rules, append the distributed ledger data received from the peer network node to the copy of the distributed ledger, wherein, after a threshold time period, the transceiver is configured to transmit a plurality of transactions generated during the threshold time period to at least one participant in the global distributed ledger network of participants maintaining the global distributed ledger.

[0236] 59. The validation network node of aspect 58, wherein after a threshold time period, the validation network node is configured to remove from the copy of the local distributed ledger at least some of the plurality of transactions generated during the threshold time period.

[0237] 60. A validation network node according to any one of Aspect 58 or Aspect 59, wherein the global distributed ledger is a permissioned blockchain viewable by multiple entities operating multiple process plants.

[0238] 61. The validation network node according to any of aspects 58-60, wherein at least one of the parameters is related to a shared resource between a plurality of entities operating a plurality of process plants.

[0239] 62. A validation network node according to any of aspects 58-61, wherein the global distributed ledger comprises a plurality of global distributed ledgers corresponding to a plurality of entities, each global distributed ledger comprising transactions stored in a local distributed ledger for the same corresponding entity as the global distributed ledger.

[0240] 63. A validation network node according to any of aspects 58-62, wherein the local distributed ledger is a private blockchain viewable by an entity operating the process plant.

[0241] 64. A verification network node according to any of aspects 58-63, wherein the transaction comprises a cryptographic hash value corresponding to the measurement of the parameter.

[0242] 65. A method for recording quality control, production or regulatory data in a process control system using a distributed ledger maintained by multiple participants, the method comprising: detecting a trigger event related to quality control within a process plant via one or more field devices that each perform a physical function to control an industrial process; obtaining event data from the trigger event, including at least one of: the time of the trigger event, the duration of the trigger event, product parameter data related to the trigger event, or process parameter data related to the trigger event; generating a transaction including the event data, wherein the transaction is stored in the distributed ledger; and transmitting the transaction to at least one other participant of the distributed ledger network of the participant maintaining the distributed ledger.

[0243] 66. The method of aspect 65, wherein the triggering event is at least one of: an alarm, an error, a leak, a maintenance event, a process milestone, or a corrective action.

[0244] 67. The method according to any one of Aspect 65 or Aspect 66 also includes: receiving a request for event data from a specific trigger event; obtaining the event data from a distributed ledger; and presenting the event data from the specific trigger event on a user interface.

[0245] 68. A method according to any of aspects 65-67, wherein generating a transaction including event data comprises: generating a transaction including a cryptographic hash value corresponding to at least some of the event data.

[0246] 69. The method of any one of Aspects 65-68 further includes: storing the event data in a database; and in response to a request for authenticated event data, providing a cryptographic hash value corresponding to at least some of the event data from the distributed ledger and the event data from the database to verify the authenticity of the event data.

[0247] 70. A method according to any one of Aspects 65-69, wherein the triggering event is an opening in a safety valve, and the event data from the triggering event includes at least one of the following: the time of opening the safety valve, the duration of opening the safety valve, the pressure value when the safety valve is opened, or the amount of fluid discharged when the safety valve is opened.

[0248] 71. A method according to any of aspects 65-70, wherein the distributed ledger is a private blockchain accessible to the process plant and regulatory agencies.

[0249] 72. A method according to any of aspects 65-71, wherein the distributed ledger is a public blockchain.

[0250] 73. The method of any one of aspects 65-72, wherein the transaction further comprises a unique identifier for triggering the event.

[0251] 74. The method according to any one of Aspects 65-73 further includes: transmitting an indication of the detected triggering event including a unique identifier of the triggering event to one or more other process control elements in the process plant for the other process control elements to generate a transaction including additional event data related to the triggering event.

[0252] 75. A system for recording quality control, production or regulatory data in a process control system using a distributed ledger maintained by multiple participants, comprising: one or more devices set in a process plant, each of which performs a physical function to control an industrial process; and a computing device executed in the process plant, the computing device comprising: one or more processors; a communication unit; and a non-transitory computer-readable medium, which is coupled to the one or more processors and the communication unit and stores instructions thereon, which when executed by the one or more processors causes the computing device to perform the following operations: detect a trigger event related to quality control within the process plant via one or more devices; obtain event data from the trigger event, including at least one of the following: the time of the trigger event, the duration of the trigger event, product parameter data related to the trigger event, or process parameter data related to the trigger event; generate a transaction including the event data, wherein the transaction is stored in the distributed ledger; and transmit the transaction to at least one other participant of the distributed ledger network of the participant maintaining the distributed ledger so as to verify the transaction and record the transaction in the distributed ledger.

[0253] 76. The system of aspect 75, wherein the triggering event is at least one of: an alarm, an error, a leak, a maintenance event, a process milestone, or a corrective action.

[0254] 77. A system according to any one of Aspect 75 or Aspect 76, wherein the instructions further cause the computing device to perform the following operations: receive a request for event data from a specific trigger event; obtain the event data from a distributed ledger; and present the event data from the specific trigger event on a user interface.

[0255] 78. The system of any of aspects 75-77, wherein the transaction comprises a cryptographic hash value corresponding to at least some of the event data.

[0256] 79. A system according to any of aspects 75-78, wherein the instructions further cause the computing device to perform the following operations: store the event data in a database; and in response to a request for authenticated event data, provide a cryptographic hash value corresponding to at least some of the event data from the distributed ledger and the event data from the database to verify the authenticity of the event data.

[0257] 80. A system according to any of Aspects 75-79, wherein the triggering event is an opening in a safety valve, and event data from the triggering event includes at least one of the following: the time when the safety valve is opened, the duration of the safety valve being opened, the pressure value when the safety valve is opened, or the amount of fluid discharged when the safety valve is opened.

[0258] 81. The system of any of aspects 75-80, wherein the distributed ledger is a private blockchain accessible to the process plant and a regulatory agency.

[0259] 82. The system of any of aspects 75-81, wherein the distributed ledger is a public blockchain.

[0260] 83. The system of any of aspects 75-82, wherein the transaction further comprises a unique identifier for triggering the event.

[0261] 84. A system according to any of aspects 75-83, wherein the instructions further cause the computing device to perform the following operations: transmit an indication of the detected triggering event including a unique identifier of the triggering event to one or more devices in the process plant for the one or more devices to generate a transaction including additional event data related to the triggering event.

[0262] 85. A verification network node in a process plant on a distributed ledger network, comprising: a transceiver configured to communicate with one or more field devices that each perform a physical function to control an industrial process in the process plant, and to exchange distributed ledger data with a peer network node, the distributed ledger data including transactions having event data from a triggering event; a storage medium configured to store a copy of the distributed ledger; and a process data validator configured to apply a consensus rule set to the distributed ledger data received from the peer network node, the process data validator being further configured to: if the distributed ledger data satisfies the consensus rules, append the distributed ledger data received from the peer network node to the copy of the distributed ledger.

[0263] 86. A validation network node according to aspect 85, wherein the event data comprises at least one of: a time of a triggering event, a duration of a triggering event, product parameter data related to the triggering event, or process parameter data related to the triggering event.

[0264] 87. A verification network node according to any one of aspects 85 or 86, wherein the triggering event is at least one of: an alarm, an error, a leak, a maintenance event or a corrective action.

[0265] 88. A verification network node according to any of aspects 85-87, wherein the distributed ledger data received from the peer node includes: an identity certificate of one of the one or more field devices that generated the transaction with the event data.

[0266] 89. A validation network node according to any one of aspects 85-88, wherein, in order to append distributed ledger data received from a peer node, the transaction validator is configured to: solve a cryptographic puzzle based on a transaction block; and add the solution to the cryptographic puzzle to the transaction block; append the transaction block to a copy of the distributed ledger; and transmit the transaction block to at least one of the peer network nodes in the distributed ledger network.

[0267] 90. A validation network node according to any of Aspects 85-89, wherein the consensus rule set includes at least one of: formatting requirements for transactions or transaction blocks; a mechanism for determining which of the peer network nodes will add the next transaction or transaction block to the distributed ledger; or a cryptographic hash algorithm for hashing process control data included in each transaction.

[0268] 91. A validation network node according to any of aspects 85-90, wherein the distributed ledger is a private blockchain accessible to the process plant and regulatory agencies.

[0269] 92. A validation network node according to any of aspects 85-91, wherein the distributed ledger is a public blockchain.

[0270] 93. A verification network node according to any one of aspects 85-92, wherein the transaction further comprises a unique identifier of the triggering event.

[0271] 94. A method for recording the state of software or firmware in a process control system and connected instruments using a distributed ledger maintained by multiple participants, the method comprising: obtaining, by a computing device, the current state of software or firmware executed in a process plant having one or more field devices, the one or more field devices each performing a physical function to control an industrial process, the software or firmware being executed in a network or process control device within the process plant; generating a transaction including the current state of the software or firmware executed in the process plant, wherein the transaction is stored in a distributed ledger; and transmitting the transaction to at least one other participant in the distributed ledger network of the participant maintaining the distributed ledger.

[0272] 95. A method according to aspect 94, wherein the current state of the software or firmware executed within the process plant is obtained from a computing device of a user who updated the current state, and generating a transaction also includes: obtaining identity data of the user; at one or more processors, augmenting the transaction with the identity data of the user; at one or more processors, generating a cryptographic signature based on the transaction; and at one or more processors, augmenting the transaction with the cryptographic signature.

[0273] 96. A method according to any one of Aspect 94 or Aspect 95, wherein generating a transaction including a current state of software or firmware executed within the process plant includes: generating a transaction including a cryptographic hash value corresponding to the current state of the software or firmware executed within the process plant.

[0274] 97. The method according to any one of Aspects 94-96 further includes: obtaining the state of the software or firmware executed in the process plant from a network or process control device that executes the software or firmware; and comparing the state of the software or firmware executed in the process plant with the encrypted hash value in the distributed ledger to verify that the software or firmware has not been tampered with.

[0275] 98. The method of any one of Aspects 94-97 further includes: in response to determining, based on the cryptographic hash value, that the state of the software or firmware executed within the process plant does not match the current state of the software or firmware stored in the distributed ledger, preventing the execution of the software or firmware within the process plant.

[0276] 99. The method of any of aspects 94-98, further comprising: restoring the software or firmware to a previous state.

[0277] 100. The method of any one of Aspects 94-99 further includes causing a network or process control device to execute software or firmware in response to determining, based on a cryptographic hash value, that a state of software or firmware executed within a process plant matches a current state of software or firmware stored in a distributed ledger.

[0278] 101. The method of any one of aspects 94-100, further comprising: adding the transaction to a transaction block; and solving a cryptographic puzzle based on the transaction block; adding the solution to the cryptographic puzzle to the transaction block; and transmitting the transaction block to at least one other participant in the distributed ledger network.

[0279] 102. The method of any one of Aspects 94-101 further includes: comparing the identity data in the transaction with multiple identity data sets corresponding to users authorized to update the state of software or firmware executed in the process plant; and adding the transaction to the transaction block when the identity data is included in multiple identity data sets.

[0280] 103. The method of any of aspects 94-102, wherein the distributed ledger is a permissioned blockchain.

[0281] 104. A system for recording the state of software or firmware in a process control system and connected instruments using a distributed ledger maintained by multiple participants, comprising: one or more devices set in a process plant, the one or more devices each performing a physical function to control an industrial process; a computing device executing in the process plant, the computing device comprising: one or more processors; a communication unit; and a non-transitory computer-readable medium, which is coupled to the one or more processors and the communication unit and stores instructions thereon, which when executed by the one or more processors causes the computing device to perform the following operations: obtain the current state of software or firmware executing in the process plant, the software or firmware being executed in one or more devices set in the process plant or at least one of the network devices within the process plant; generate a transaction including the current state of the software or firmware executing in the process plant, wherein the transaction is stored in the distributed ledger; and transmit the transaction to at least one other participant in the distributed ledger network of the participant maintaining the distributed ledger so as to verify the transaction and record the transaction in the distributed ledger.

[0282] 105. A system according to aspect 104, wherein the current state of software or firmware executed within the process plant is obtained from a computing device of a user who updated the current state, and in order to generate a transaction, the instructions cause the computing device to perform the following operations: obtain the user's identity data; use the user's identity data to expand the transaction; generate a cryptographic signature based on the transaction; and use the cryptographic signature to expand the transaction.

[0283] 106. A system according to any one of aspects 104 or 105, wherein the transaction is generated using a cryptographic hash value corresponding to a current state of software or firmware executing within the process plant.

[0284] 107. The system according to any one of Aspects 104-106 further includes: a server device, the server device including: one or more processors; a communication unit; and a non-temporary computer-readable medium, which is coupled to the one or more processors and the communication unit and stores instructions thereon, and the instructions, when executed by the one or more processors, cause the server device to perform the following operations: obtain the state of the software or firmware executed in the process plant from a network or process control device that executes the software or firmware; and compare the state of the software or firmware executed in the process plant with the encrypted hash value in the distributed ledger to verify that the software or firmware has not been tampered with.

[0285] 108. A system according to any of aspects 104-107, wherein the instructions further cause the server device to perform the following operations: in response to determining that the state of the software or firmware executed in the process plant does not match the current state of the software or firmware stored in the distributed ledger based on the cryptographic hash value, preventing the execution of the software or firmware in the process plant.

[0286] 109. The system of any one of aspects 104-108, wherein the instructions further cause the server device to: restore the software or firmware to a previous state.

[0287] 110. A system according to any of aspects 104-109, wherein the instructions further cause the server device to perform the following operations: in response to determining that the state of software or firmware executed within the process plant matches the current state of the software or firmware stored in the distributed ledger based on the cryptographic hash value, causing the network or process control device to execute the software or firmware.

[0288] 111. A system according to any of aspects 104-110, wherein the instructions further cause the computing device to perform the following operations: add the transaction to a transaction block; and solve a cryptographic puzzle based on the transaction block; add the solution to the cryptographic puzzle to the transaction block; and transmit the transaction block to at least one other participant in the distributed ledger network.

[0289] 112. A system according to any of aspects 104-111, wherein the instructions further cause the computing device to perform the following operations: compare the identity data in the transaction with multiple identity data sets corresponding to users authorized to update the state of software or firmware executed within the process plant; and add the transaction to a transaction block when the identity data is included in multiple identity data sets.

[0290] 113. The system of any of aspects 104-112, wherein the distributed ledger is a permissioned blockchain.

[0291] 114. A verification network node in a process plant on a distributed ledger network, comprising: a transceiver configured to communicate with one or more field devices that each perform a physical function to control an industrial process in the process plant, and to exchange distributed ledger data with a peer network node, the distributed ledger data including transactions having data indicating a current state of software or firmware executing within the process plant; a storage medium configured to store a copy of the distributed ledger; and a process data validator configured to apply a consensus rule set to the distributed ledger data received from the peer network node, the process data validator being further configured to: append the distributed ledger data received from the peer network node to the copy of the distributed ledger if the distributed ledger data satisfies the consensus rules.

[0292] 115. A validation network node according to aspect 114, wherein, to append distributed ledger data received from a peer node, the transaction validator is configured to: solve a cryptographic puzzle based on a transaction block; and add the solution to the cryptographic puzzle to the transaction block; append the transaction block to a copy of the distributed ledger; and transmit the transaction block to at least one of the peer network nodes in the distributed ledger network.

[0293] 116. A verification network node according to any one of Aspect 114 or Aspect 115, wherein the consensus rule set includes at least one of the following: formatting requirements for transactions or transaction blocks; a mechanism for determining which of the peer network nodes will add the next transaction or transaction block to the distributed ledger; or a cryptographic hash algorithm for hashing software or firmware state data included in each transaction.

[0294] 117. A verification network node according to any of aspects 114-116, wherein the distributed ledger data received from the peer node includes an identification of a user of a device generating a transaction having data indicating a current state of software or firmware executed in the process plant.

[0295] 118. A method for creating a smart contract in a process control system using a distributed ledger maintained by multiple participants, the method comprising: generating, by one or more processors, a smart contract associated with a process plant having one or more field devices, each of which performs a physical function to control an industrial process; and deploying, by the one or more processors, the smart contract to an address stored on a distributed ledger maintained by multiple participants of a distributed ledger network.

[0296] 119. A method according to aspect 118, wherein the smart contract receives or provides token value based on events occurring within the process plant.

[0297] 120. A method according to any one of Aspect 118 or Aspect 119, wherein generating a smart contract related to a process plant includes: generating a smart contract that obtains a token value from a first process plant, determines that a product is transferred from a second process plant to the first process plant, and provides the token value to the second process plant.

[0298] 121. A method according to any of aspects 118-120, wherein the smart contract determines that the product is transferred from the second process plant to the first process plant by receiving a transaction from an evidentiary oracle indicating that the product was received at the first process plant.

[0299] 122. A method according to any one of Aspects 118-121, wherein generating a smart contract related to a process plant further includes: generating a smart contract that determines that a product meets or exceeds one or more quality indicators, and in response to determining that the product meets or exceeds one or more quality indicators, providing a token value to a second process plant.

[0300] 123. A method according to any one of Aspects 118-122, wherein the smart contract determines that the product meets or exceeds one or more quality indicators by receiving one or more transactions from an evidence oracle, each of which includes a product parameter value or a process parameter value, and comparing the product parameter value or the process parameter value with a product parameter threshold value or a process parameter threshold value included in one or more quality indicators.

[0301] 124. A method according to any one of aspects 118-123, wherein generating a smart contract related to a process plant includes: generating a smart contract that obtains equipment information of equipment experiencing a failure in the process plant and provides the equipment information to an equipment supplier in response to receiving a request to share the equipment information.

[0302] 125. A method according to any of aspects 118-124, wherein the smart contract obtains the device information by receiving a transaction including the device information from an evidential oracle.

[0303] 126. A method according to any of aspects 118-125, wherein the smart contract receives the request by receiving a transaction including the request together with identity data of the user issuing the request, and the smart contract compares the identity data in the transaction with multiple identity data sets corresponding to users authorized to request shared device information of the distributed ledger network, and when the identity data is included in the multiple identity data sets, provides the device information to the device provider.

[0304] 127. A method according to any one of Aspects 118-126, wherein generating a smart contract related to a process plant includes: generating a smart contract that receives a parameter associated with a safety instrumented system (SIS) device and writes the parameter to the SIS device in response to determining that an operator providing the parameter is an authorized operator.

[0305] 128. A method according to any of Aspects 118-127, wherein the smart contract receives a parameter associated with a SIS device by receiving a transaction that includes the parameter together with identity data of an operator providing the transaction, and wherein determining that the operator providing the parameter is an authorized operator includes: comparing the identity data in the transaction with multiple identity data sets corresponding to operators authorized to adjust parameters associated with the SIS device.

[0306] 129. The method of any of aspects 118-128, wherein the parameter associated with the SIS device is a request to lock the SIS device.

[0307] 130. A method for interacting with a smart contract in a process control system using a distributed ledger maintained by multiple participants, the method comprising: obtaining event data from events occurring within a process plant having one or more field devices, each of which performs a physical function to control an industrial process; generating, by a computing device, a transaction including the event data in response to the smart contract being deployed to an address stored on the distributed ledger; and transmitting the transaction to the smart contract stored on the distributed ledger maintained by multiple participants in the distributed ledger network.

[0308] 131. The method according to aspect 130 also includes: obtaining identity data of a computing device; using the identity data of the computing device to expand the transaction at one or more processors; generating a cryptographic signature based on the transaction at one or more processors; and expanding the transaction using the cryptographic signature at one or more processors.

[0309] 132. The method according to any one of Aspect 130 or Aspect 131 also includes: adding the transaction to a transaction block; solving a cryptographic puzzle based on the transaction block; adding the solution to the cryptographic puzzle to the transaction block; and transmitting the transaction block to at least one other participant in the distributed ledger network.

[0310] 133. A method according to any one of Aspects 130-132, wherein the smart contract obtains a token value from a first process plant, determines that a product is transferred from a second process plant to the first process plant, and provides the token value to the second process plant, and wherein obtaining event data from an event occurring within the process plant includes: obtaining an indication that the product is received at the first process plant; and generating a transaction including identification information of the first process plant, identification information of the product, and an indication that the product is received at the first process plant from the second process plant.

[0311] 134. A method according to any one of aspects 130-133, wherein obtaining an indication of receipt of a product at a first process plant further comprises: obtaining one or more product parameter values ​​of the product or one or more process parameter values ​​of process plant entities involved in manufacturing the product; and generating a transaction including one or more product parameter values ​​or one or more process parameter values.

[0312] 135. A method according to any one of aspects 130-134, wherein the smart contract obtains equipment information of equipment experiencing a failure within a process plant and provides the equipment information to an equipment supplier in response to receiving a request to share the equipment information, and wherein obtaining event data from events occurring within the process plant includes: obtaining equipment information of the equipment; and generating a transaction including identification information of the equipment and the equipment information.

[0313] 136. A method according to any of Aspects 130-135, wherein a smart contract receives parameters associated with a safety instrumented system (SIS) device and writes the parameters to the SIS device in response to determining that an operator providing the parameters is an authorized operator, and wherein obtaining event data from an event occurring within the process plant includes: obtaining a request to change a parameter associated with the SIS device; and generating a transaction including identification information of the SIS device, the changed parameter, and a new parameter value of the changed parameter.

[0314] 137. A computing device for creating a smart contract in a process control system using a distributed ledger maintained by multiple participants, comprising: one or more processors; a communication unit; and a non-transitory computer-readable medium coupled to the one or more processors and the communication unit and storing instructions thereon, which, when executed by the one or more processors, causes the computing device to perform the following operations: generate a smart contract associated with a process plant having one or more field devices, each of which performs a physical function to control an industrial process; and deploy the smart contract to an address stored on a distributed ledger maintained by multiple participants in a distributed ledger network.

[0315] 138. A computing device according to aspect 137, wherein the smart contract receives or provides token value based on events occurring within the process plant.

[0316] 139. A computing device according to any one of Aspect 137 or Aspect 138, wherein the smart contract obtains a token value from a first process plant, determines that a product is transferred from a second process plant to the first process plant, and provides the token value to the second process plant.

[0317] 140. A computing device according to any of aspects 137-139, wherein the smart contract determines that the product is transferred from the second process plant to the first process plant by receiving a transaction from an evidentiary oracle indicating that the product was received at the first process plant.

[0318] 141. A computing device according to any of Aspects 137-140, wherein the smart contract determines that the product meets or exceeds one or more quality indicators, and provides the token value to the second process plant in response to determining that the product meets or exceeds the one or more quality indicators.

[0319] 142. A computing device according to any one of Aspects 137-141, wherein the smart contract determines whether a product meets or exceeds one or more quality indicators by receiving one or more transactions from an evidential oracle, each including a product parameter value or a process parameter value, and comparing the product parameter value or the process parameter value with a product parameter threshold value or a process parameter threshold value included in one or more quality indicators.

[0320] 143. A computing device according to any of aspects 137-142, wherein the smart contract obtains equipment information of equipment experiencing a failure within the process plant and provides the equipment information to the equipment supplier in response to receiving a request to share the equipment information.

[0321] 144. A computing device according to any of aspects 137-143, wherein the smart contract obtains the device information by receiving a transaction including the device information from an evidential oracle.

[0322] 145. A computing device according to any of Aspects 137 to 144, wherein the smart contract receives a request for shared device information by receiving a transaction that includes the request together with identity data of the user making the request, and the smart contract compares the identity data in the transaction with multiple identity data sets corresponding to users authorized to request shared device information on the distributed ledger network, and when the identity data is included in the multiple identity data sets, provides the device information to the device provider.

[0323] 146. A computing device according to any of Aspects 137-145, wherein the smart contract receives a parameter associated with a safety instrumented system (SIS) device and writes the parameter to the SIS device in response to determining that an operator providing the parameter is an authorized operator.

[0324] 147. A computing device according to any of Aspects 137-146, wherein the smart contract receives a parameter associated with a SIS device by receiving a transaction that includes the parameter together with identity data of an operator providing the transaction, and wherein determining that the operator providing the parameter is an authorized operator includes: comparing the identity data in the transaction with multiple identity data sets corresponding to operators authorized to adjust the parameters associated with the SIS device.

[0325] 148. The computing device of any of aspects 137-147, wherein the parameter associated with the SIS device is a request to lock the SIS device.

[0326] 149. A system for interacting with smart contracts in a process control system using a distributed ledger maintained by multiple participants, comprising: one or more devices disposed in a process plant, each device performing a physical function to control an industrial process; and a body device executed in the process plant, comprising: one or more processors; a communication unit; and a non-transitory computer-readable medium coupled to the one or more processors and the communication unit and storing instructions thereon, which, when executed by the one or more processors, cause the computing device to perform the following operations: obtain event data from events occurring within the process plant via one or more devices; generate a transaction including the event data in response to the smart contract being deployed to an address stored on the distributed ledger; and transmit the transaction to the smart contract stored on the distributed ledger maintained by multiple participants in the distributed ledger network.

[0327] 150. The system of aspect 149, wherein the instructions further cause the computing device to: obtain identity data of the computing device; augment the transaction using the identity data of the computing device; generate a cryptographic signature based on the transaction; and augment the transaction using the cryptographic signature.

[0328] 151. A system according to any one of Aspect 149 or Aspect 150, wherein the instructions further cause the computing device to perform the following operations: add the transaction to a transaction block; and solve a cryptographic puzzle based on the transaction block; add the solution to the cryptographic puzzle to the transaction block; and transmit the transaction block to at least one other participant in the distributed ledger network.

[0329] 152. A system according to any of Aspects 149-151, wherein a smart contract obtains a token value from a first process plant, determines that a product is transferred from a second process plant to the first process plant, and provides the token value to the second process plant, and wherein, in order to obtain event data from an event occurring within the process plant, instructions cause the computing device to perform the following operations: obtain an indication that the product is received at the first process plant; and generate a transaction including identification information of the first process plant, identification information of the product, and an indication that the product is received at the first process plant from the second process plant.

[0330] 153. A system according to any of aspects 149-152, wherein, in order to obtain an indication that a product is received at a first process plant, the instructions cause the computing device to perform the following operations: obtain one or more product parameter values ​​of the product or one or more process parameter values ​​of process plant entities involved in manufacturing the product; and generate a transaction including one or more product parameter values ​​or one or more process parameter values.

[0331] 154. A system according to any of Aspects 149-153, wherein the smart contract obtains equipment information of equipment experiencing a failure within a process plant and provides the equipment information to a supplier of the equipment in response to receiving a request to share the equipment information, and wherein, in order to obtain event data from events occurring within the process plant, the instructions cause the computing device to perform the following operations: obtain equipment information of the equipment; and generate a transaction including identification information of the equipment and the equipment information.

[0332] 155. A system according to any of Aspects 149-154, wherein a smart contract receives parameters associated with a safety instrumented system (SIS) device and writes the parameters to the SIS device in response to determining that an operator providing the parameters is an authorized operator, and wherein, in order to obtain event data from events occurring within a process plant, instructions cause a computing device to perform the following operations: obtain a request to change a parameter associated with the SIS device; and generate a transaction including identification information of the SIS device, the changed parameter, and a new parameter value of the changed parameter.

[0333] When implemented in software, any application, service, and engine described herein may be stored in any tangible, non-transitory computer-readable memory, such as on a disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage medium, in the RAM or ROM of a computer or processor, and the like. Although the example system disclosed herein is disclosed as including software and / or firmware and other components executed on hardware, it should be noted that such a system is merely illustrative and should not be considered restrictive. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied in hardware only, software only, or in any combination of hardware and software. Therefore, although the example system described herein is described as being implemented in software executed on a processor of one or more computer devices, it will be readily understood by those of ordinary skill in the art that the examples provided are not the only way to implement such a system.

[0334] Therefore, although the present invention has been described with reference to specific examples, these specific examples are only intended to be used for illustration rather than limitation of the present invention, and it will be obvious to those skilled in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention.

Claims

1. A method for recording quality control, production or regulatory data in a process control system using a distributed ledger maintained by a plurality of participants, the method comprising: detecting a triggering event related to quality control within a process plant via one or more field devices each performing a physical function to control an industrial process; Obtaining event data from the triggering event, including at least one of: a time of the triggering event, a duration of the triggering event, product parameter data related to the triggering event, or process parameter data related to the triggering event; generating a transaction including the event data, wherein the transaction is stored in the distributed ledger, and the transaction also includes a unique identifier of the triggering event; transmitting the transaction to at least one other participant in a distributed ledger network of participants maintaining the distributed ledger; as well as An indication of the detected triggering event including a unique identifier of the triggering event is communicated to one or more other process control elements in the process plant for the other process control elements to generate a transaction including additional event data related to the triggering event.

2. The method according to claim 1, wherein: The triggering event is at least one of: an alarm, an error, a leak, a maintenance event, a process milestone, or a corrective action.

3. The method according to claim 1, further comprising: receiving a request for event data from a particular triggering event; Obtaining the event data from the distributed ledger; as well as The event data from the particular triggering event is presented on a user interface.

4. The method according to claim 1, wherein: Generating a transaction including the event data includes generating a transaction including a cryptographic hash value corresponding to at least some of the event data.

5. The method according to claim 4, further comprising: storing the event data in a database; as well as In response to the request to authenticate the event data, providing the cryptographic hash value corresponding to at least some of the event data from the distributed ledger and the event data from the database to verify the authenticity of the event data.

6. The method according to claim 1, wherein: The triggering event is an opening in a safety valve, and the event data from the triggering event includes at least one of: The time to open the safety valve, the duration of opening of the safety valve, The pressure value at which the safety valve is opened, or The amount of fluid discharged when the safety valve is opened.

7. The method according to claim 1, wherein: The distributed ledger is a private blockchain that can be accessed by the process plant and regulatory agencies.

8. The method according to claim 1, wherein: The distributed ledger is a public blockchain.

9. A system for recording quality control, production or regulatory data in a process control system using a distributed ledger maintained by multiple participants, comprising: One or more devices disposed in a process plant, the one or more devices each performing a physical function to control an industrial process; as well as A computing device executed in the process plant, the computing device comprising: one or more processors; a communication unit; and a non-transitory computer-readable medium coupled to the one or more processors and the communication unit and storing thereon instructions that, when executed by the one or more processors, cause the computing device to: detecting, via the one or more devices, a triggering event related to quality control within the process plant; Obtaining event data from the triggering event, including at least one of: a time of the triggering event, a duration of the triggering event, product parameter data related to the triggering event, or process parameter data related to the triggering event; generating a transaction including the event data, wherein the transaction is stored in the distributed ledger, and the transaction also includes a unique identifier of the triggering event; transmitting the transaction to at least one other participant of a distributed ledger network of participants maintaining the distributed ledger for verification of the transaction and recording the transaction in the distributed ledger; and An indication of the detected triggering event including the unique identifier of the triggering event is communicated to the one or more devices in the process plant for the one or more devices to generate a transaction including additional event data related to the triggering event.

10. The system according to claim 9, wherein: The triggering event is at least one of: an alarm, an error, a leak, a maintenance event, a process milestone, or a corrective action.

11. The system according to claim 9, wherein: The instructions further cause the computing device to: receiving a request for event data from a particular triggering event; Obtaining the event data from the distributed ledger; as well as The event data from the particular triggering event is presented on a user interface.

12. The system according to claim 9, wherein: The transaction includes a cryptographic hash value corresponding to at least some of the event data.

13. The system according to claim 12, wherein: The instructions further cause the computing device to: storing the event data in a database; and In response to the request to authenticate the event data, providing a cryptographic hash value corresponding to at least some of the event data from the distributed ledger and the event data from the database to verify the authenticity of the event data.

14. The system according to claim 9, wherein: The triggering event is an opening in a safety valve, and the event data from the triggering event includes at least one of: The time to open the safety valve, the duration of opening of the safety valve, The pressure value at which the safety valve is opened, or The amount of fluid discharged when the safety valve is opened.

15. The system according to claim 9, wherein: The distributed ledger is a private blockchain that can be accessed by the process plant and regulatory agencies.

16. The system of claim 9, wherein: The distributed ledger is a public blockchain.

Images