Maintaining quality control, regulatory, and parameter measurement data using distributed ledgers in process control systems

Abstract

To provide techniques for utilizing distributed ledgers in process control systems in order to provide a trusted, secure and immutable record of transactions within a process plant.SOLUTION: The distributed ledgers are maintained by nodes which receive transactions broadcasted from field devices, controllers, operator workstations, or other devices operating within a process plant 10. The transactions include process plant data, such as process parameter data, product parameter data, configuration data, user interaction data, maintenance data, and commissioning data. The distributed ledgers are also utilized to execute smart contracts to allow machines such as field devices to transact by themselves without human intervention, so that recorded process parameter values and product parameter values are retrieved to verify the quality of products.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates generally to process plants and process control systems, and more particularly to the use of distributed ledgers in process control systems for recording data and events. [Background technology]

[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 bus, a digital bus, or an analog / digital combination bus, or via a wireless communication link or network. The field devices, which may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure, level, and flow sensors), are positioned within the process environment and generally perform physical or process control functions, such as opening and closing valves, measuring process parameters such as pressure, temperature, etc., to control one or more processes running within the process plant or system. Smart field devices, such as field devices conforming to the well-known Fieldbus protocol, may also perform control calculations, alarm functions, and other control functions typically implemented in a controller. Process controllers are also typically located within the plant environment and execute controller applications that execute different control modules that receive signals indicative of process measurements made by and / or other information related to the field devices, e.g., make process control decisions, generate control signals based on the received information, and interface with control modules or blocks implemented in field devices such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules within the controllers send control signals over communication lines or links to the field devices, 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 usually made available over a data highway 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 computing devices, which are typically located in a control room or other location away from the more austere plant environment. Each of these hardware devices is typically centralized throughout the process plant or throughout a portion of the process plant. These hardware devices execute applications that may enable operators to perform functions related to the control of the process and / or the operation of the process plant, such as, for example, changing settings of process control routines, modifying the operation of control modules in 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 purposes of training personnel or testing process control software, maintaining 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™ control system sold by Emerson Process Management includes multiple applications stored in and executed by different devices located at various locations within a process plant. Configuration applications residing in one or more workstations or computing devices enable users to create or modify process control modules and download them to dedicated distributed controllers via a data highway. Typically, these control modules are composed of communicatively interconnected function blocks, which are objects in an object-oriented programming protocol that perform functions within a control scheme based on inputs and provide outputs to other function blocks within the control scheme. The configuration application may also enable a configuration designer to create or modify operator interfaces that a viewing application uses to display data to an operator and to allow the operator to change settings, such as setpoints, within a process control routine. Each dedicated controller, and in some cases, one or more field devices, stores and executes its own controller application, which executes its assigned and downloaded control modules to implement the actual process control functions. A visibility application may run on one or more operator workstations (or one or more remote computing devices communicatively connected to the operator workstations and the data highway), and the visibility application may receive data from the controller application via the data highway and display this data to a process control system designer, operator, or user using a user interface to provide any of several different views, such as an operator's view, an engineer's view, a technician's view, etc.While the data historian application is typically stored on and executed by a data historian device that collects and stores some or all of the data provided over the data highway, a configuration database application may be run on an even further remote computer attached to the data highway to store the current process control routine configuration and its associated data. Alternatively, the configuration database may be located on the same workstation as the configuration application. Summary of the Invention [Problem to be solved by the invention]

[0005] Generally speaking, a process control system for a process plant includes field devices, controllers, workstations, and other devices interconnected by a set of hierarchical networks and buses. The process control system may then be connected to various business and external networks to, for example, reduce manufacturing and operational costs, increase productivity and efficiency, and provide timely access to process control and / or process plant information. Meanwhile, the interconnection of the process plant and / or process control system to corporate and / or external networks and / or systems increases the risk of cyber intrusions and / or malicious cyber attacks that may arise from anticipated vulnerabilities in commercial systems and applications, such as those used in corporate and / or external networks. Cyber ​​intrusions and malicious cyber attacks on process plants, networks, and / or control systems can adversely affect the confidentiality, integrity, and / or availability of information assets, which are generally similar to vulnerabilities of general-purpose computing networks. However, unlike general-purpose computer networks, cyber intrusions on process plants, networks, and / or control systems can result in damage, destruction, and / or loss of plant equipment, products, and other physical assets, as well as loss of human life. For example, cyber intrusions can cause processes to become uncontrollable, thereby causing explosions, fires, floods, exposure to hazardous materials, etc. Therefore, it is extremely important to protect communications associated with process control plants and systems.

[0006] Techniques, systems, apparatus, components, devices, and methods are disclosed for utilizing distributed ledgers or blockchains in process control systems. Such techniques, systems, apparatus, components, devices, and methods may be applied to industrial process control systems, environments, and / or plants, which are also referred to interchangeably 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 that operate to manufacture, refine, transform, create, or produce physical substances or products in a distributed manner. [Means for solving the problem]

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

[0008] The recorded process parameter values ​​and product parameter values ​​may then be retrieved to verify the quality of the product. For example, a first process plant may manufacture, refine, convert, create, or produce a product, and then ship it to a second process plant. The second process plant may determine that the product meets certain quality standards by retrieving the recorded process parameter values ​​and product parameter values ​​from the distributed ledger. In addition, regulatory data may be recorded on the distributed ledger. For example, in response to a trigger event, such as an alarm, error, leak, repair event, process milestone, or corrective action, process control elements, such as field devices and controllers, may generate transactions that include data from the trigger event, such as the time the event occurred, the duration of the event, and process parameter values ​​for the process plant entities involved in the event. The regulatory data is then recorded on the distributed ledger so that regulators can review the data.

[0009] Furthermore, distributed ledgers may be used to execute smart contracts, which are described in more detail below. A process control system may deploy smart contracts on a distributed ledger to exchange value, for example, upon receiving a product in good condition. Smart contracts may also be deployed on a distributed ledger to enable machines, such as field devices, to operate on their own without human intervention. For example, according to the terms of the smart contract, a computing device in a first process plant may automatically provide a predetermined amount of tokens to a computing device in a second process plant upon 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 may also be utilized in process plants in numerous other applications, which are described in more detail below.

[0010] In some scenarios utilizing distributed ledgers, by utilizing smart contracts within a process plant, each process plant, or network of process plants, can provide a reliable, secure, and immutable record of transactions within the process plant. The secure, immutable, and trustless nature of distributed ledgers is particularly important within process control systems, where cyber intrusions can lead to damage, destruction, and / or loss of plant equipment, products, and other physical assets, as well as loss of human life. Additionally, distributed ledgers enable process plants to track product lineage from raw materials to finished products and further track products after the raw materials are processed. Furthermore, when competing entities utilize or transfer a common resource, distributed ledgers can be used to determine the amount of the resource utilized by one of the entities and to fairly compensate the competing entities for the use of the resource. For example, an oil refinery may produce oil that is delivered via an oil pipeline to several entities or process plants. Each process plant is responsible for compensating the oil refinery for the amount of oil the process plant receives from the oil pipeline. Using a distributed ledger, each process plant can record the amount of oil it receives from a device that measures the amount of oil as it is dispensed. Because it is difficult to change the recorded data in a distributed ledger, competing entities do not need to be certain that this data is trustworthy. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a block diagram of an example process plant or process control system showing, among other things, interconnections between various example components of the process control system, the process control system itself, and other systems and / or networks. [Figure 2] FIG. 1 is a block diagram of an example security architecture for a process plant or process control system. [Figure 3]1 is an exemplary distributed ledger system for recording transactions and executing smart contracts in a process control system. [Figure 4] 1 illustrates an example validating network node and an example transaction flow on a distributed ledger network within a process control system. [Figure 5] 1 illustrates example components of a network node on a distributed ledger network in a process control system. [Figure 6A] 1 illustrates an example of a distributed ledger comprising a blockchain having blocks of transactions within a process control system. [Figure 6B] Figure 1 shows another example of a distributed ledger that includes multiple side blockchains or side chains maintained by different process plants, and a main blockchain maintained by several process plants that incorporates transaction data from the side chains. [Figure 7A] 1 shows yet another distributed ledger example that includes multiple local blockchains, each maintained by a different process plant. [Figure 7B] 1 shows a global blockchain for process plants maintained by several process plants and incorporating blocks from local blockchains. [Figure 7C] 1 shows a super-blockchain maintained by several process plants, with each process plant incorporating blocks from each of the global blockchains. [Figure 8] 1 illustrates an example smart contract state in a distributed ledger network for performing a secure write operation in a process plant to write process parameters to a secure instrumentation system (SIS) device. [Figure 9] 1 shows an example transaction representing an evidence transaction generated by an evidence oracle, a field device that reports the amount of oil received from an oil pipeline. [Figure 10]1 shows an example transaction representing an evidence transaction generated by an evidence oracle, which is a computing device that reports software or firmware updates. [Figure 11] 1 illustrates an example transaction representing an evidence transaction generated by an evidence oracle, which is a process plant entity that reports process parameter or product parameter data. [Figure 12] FIG. 1 shows a flow diagram illustrating an example method for recording data in a process control system using a distributed ledger. [Figure 13] FIG. 1 shows a flow diagram illustrating an exemplary method for secure metering of untrusted data in a process control system using a distributed ledger. [Figure 14] FIG. 1 shows a flow diagram illustrating an example method for recording quality control, production, or regulatory data in a process control system using a distributed ledger. [Figure 15] 1 shows a flow diagram depicting an example method for recording software or firmware state in a process control system and connected instrumentation using a distributed ledger. [Figure 16] FIG. 1 shows a flow diagram illustrating an example method for creating smart contracts in a process control system using a distributed ledger. [Figure 17] FIG. 1 shows a flow diagram depicting an example method for interacting with smart contracts in a process control system using a distributed ledger. DETAILED DESCRIPTION OF THE INVENTION

[0012] A distributed ledger is a storage mechanism for data, events, transactions, etc. maintained by several participants. More specifically, a distributed ledger is a method for achieving distributed consensus regarding the validity or invalidity of information recorded in the distributed ledger. In other words, 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 transactional records of changes to the ledger are maintained and verified by each node in a peer-to-peer network. One type of distributed ledger, a blockchain, consists of a group of transactions organized into "blocks" and ordered (hence the term "blockchain"). While the distributed ledger described here is referred to in relation to a blockchain, this is merely one example of a distributed ledger. A distributed ledger may also include a tangle, a block lattice, or other directed acyclic graph (DAG). In either case, nodes may join and leave the blockchain network over time, obtaining blocks from peer nodes that were propagated during their absence. Nodes may maintain the addresses of other nodes and exchange addresses of known nodes with each other to facilitate the propagation of new information through the network in a decentralized, peer-to-peer manner.

[0013] Nodes that share the ledger form what is referred to herein as a distributed ledger network. Nodes in a distributed ledger network validate changes to the blockchain (e.g., when new transactions and / or blocks are created, etc.) according to a set of consensus rules. The consensus rules depend on the information tracked by the blockchain and may include rules regarding the chain itself. For example, consensus rules may include requiring that change originators provide identity proofs to ensure only authorized entities can make changes to the chain. Consensus rules may require blocks and transactions to adhere to formatting requirements and provide specific meta-information about changes (e.g., blocks must be under a size limit, transactions must contain a number of fields, etc.). Consensus rules may include mechanisms that determine the order in which new blocks are added to the chain (e.g., proof-of-work systems, proof-of-stake, etc.).

[0014] Additions to the blockchain that satisfy the consensus rules are propagated from nodes that verify the addition to other nodes known to the validating node. When all of the nodes receiving the changes to the blockchain verify the new block, the distributed ledger reflects the new changes stored on all nodes, and a distributed consensus is said to have been reached regarding the new block and the information it contains. Any changes that do not satisfy the consensus rules are ignored by validating nodes that receive the changes, and the changes are not propagated to other nodes. Thus, unlike traditional systems using a central authority, no single party can unilaterally change the distributed ledger unless the single party can make the change in a way that satisfies the consensus rules. Because past transactions cannot be amended, blockchains are commonly described as trusted, secure, and immutable.

[0015] The validating activity of nodes that enforce consensus rules on a blockchain network can take a variety of forms. In one implementation, the blockchain can be viewed as a shared spreadsheet that tracks data such as asset ownership. In another implementation, validating nodes execute code contained in "smart contracts," and distributed consensus is represented as network nodes agreeing on the output of the executed code.

[0016] A smart contract is a computer protocol that allows for the automated execution and / or enforcement of agreements between different parties. In particular, a smart contract can be computer code located at a specific address on a blockchain. In some cases, a smart contract can be automatically activated when a blockchain participant sends funds (cryptocurrency, such as Bitcoin, Ether, or other digital / cryptocurrency) to the address where the smart contract is stored. Additionally, a smart contract can maintain a balance of the remaining funds stored at that address. In some scenarios, if this balance reaches zero, the smart contract can cease to function.

[0017] 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) to be performed may be determined based on one or more decision conditions. In some cases, a smart contract may route a data stream to the smart contract so that it can detect when a trigger condition has occurred and / or analyze a decision condition.

[0018] Blockchains may 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 participate in the network as a validating node. Other blockchains are private (e.g., permissioned ledgers) that keep chain data private among a group of entities authorized to participate in the blockchain network. Other blockchain implementations may be both permissioned and permissionless, which may require participants to be verified, but only publish information that participants in the network wish to make public.

[0019] In some implementations, a distributed ledger includes multiple blockchains, such as a main blockchain and several side chains that operate independently of the main blockchain. The side chains then interact with the main blockchain to provide some of the transaction data from the side chains to the main blockchain. In this way, the side chains can be private while the main blockchain is public or available to a larger number of entities than the side chains. Non-confidential information from the side chains can be shared on the main blockchain. Also, in some implementations, a distributed ledger includes multiple layers or separate blockchains running in parallel, maintained by the same validator nodes. Some of the transaction data from the blockchain for the first layer can be provided to the blockchain for the second layer, or vice versa.

[0020] In one example, a distributed ledger within a process control system may be maintained by verifying nodes referred to as "edge gateways," which transmit data to remote systems, such as other process plants, using one or more public and / or private networks, such as a private enterprise network, the Internet, cellular routers, backhaul Internet, or other types of backhaul connections. The edge gateways receive transactions broadcast to the distributed ledger network by process control devices, such as field devices or controllers operating within the process plant. Other computing devices, such as operator workstations, server devices, or other user interface devices within the process plant, may also broadcast transactions to the distributed ledger network. The edge gateways then verify the broadcasted transactions.

[0021] In another example, edge gateways execute code contained in "smart contracts," and field devices act as "evidence oracles" that provide evidence to the blockchain related to quality control, regulatory compliance, product delivery or receipt, and delivery / received quantities.

[0022] 1 is a block diagram of an example process plant 10 that may utilize any one or more of the novel distributed ledger technologies described herein. The process plant 10 (also referred to herein as a process control system 10 or process control environment 10) includes one or more process controllers that receive signals representing process measurements made by field devices, process this information to implement control routines, and transmit this information via wired or wireless process control communication links or networks to other field devices to control the operation of a process within the plant 10. Typically, at least one field device performs a physical function (e.g., opening or closing a valve, raising or lowering a temperature, measuring, sensing a condition, etc.) to control the operation of a process. Some types of field devices communicate with a controller using I / O devices. The process controllers, field devices, and I / O devices may be wired or wireless, and any number and combination of wired and wireless process controllers, field devices, and I / O devices may be included within the process plant environment or system 10.

[0023] 1 shows a process controller 11 that is communicatively coupled 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 communication protocol, such as, for example, an Ethernet protocol. In some configurations (not shown), the controller 11 may be communicatively coupled to the wireless gateway 35 using one or more communications networks other than the backbone 105, such as by using any number of other wired or wireless communications links supporting one or more communications protocols, e.g., Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, mobile communications protocols (e.g., WiMAX, LTE, or other ITU-R compatible protocols), Bluetooth®, HART®, WirelessHART®, Profibus, FOUNDATION® Fieldbus, etc.

[0024] The controller 11 may be, by way of example, a DeltaV™ controller sold by Emerson Process Management and may operate to implement a batch or continuous process using at least some of the field devices 15-22 and 40-46. In an embodiment, in addition to being communicatively connected to the process control data highway 105, the controller 11 is also communicatively connected to at least some of the field devices 15-22 and 40-46 using any desired hardware and software, for example, associated with standard 4-20 mA devices, I / O cards 26, 28, and / or any smart communication protocol such as the FOUNDATION® Fieldbus protocol, the HART® protocol, the WirelessHART® protocol, etc. In FIG. 1 , 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 wireless field devices 40-46 may conform to any other desired standard(s) or protocol, such as any wired or wireless protocol, including any standard or protocol developed in the future.

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

[0026] The controller 11 implements its control strategies using what are generally 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 cooperation with other function blocks (through communications called links) to implement a process control loop within the process control system 10. A control-based function block typically performs one of the following functions: an input function associated with a transmitter, sensor, or other process parameter measurement device; a control function associated with a control routine that performs PID, fuzzy logic, etc.; or an output function that controls the operation of some device, such as a valve, to implement some physical function within the process control system 10. Of course, hybrid and other types of function blocks exist. The function blocks may be stored within and executed by the controller 11, which is typically the case when these function blocks are used for or associated with certain types of smart field devices, such as standard 4-20 mA devices and HART® devices, or the function blocks may be stored within and implemented by the field device itself, which may be the case for FOUNDATION® Fieldbus devices. The controller 11 may include one or more control routines 38 that may implement one or more control loops performed by executing one or more of the function blocks.

[0027] Wired field devices 15-22 may be any type of device, such as sensors, valves, transmitters, positioners, etc., while I / O cards 26 and 28 may be any type of I / O device conforming to any desired communication or controller protocol. In Figure 1, field devices 15-18 are standard 4-20 mA or HART® devices that communicate to I / O card 26 via analog lines or combined analog and digital lines, while field devices 19-22 are smart devices, such as FOUNDATION® Fieldbus field devices, that communicate to I / O card 28 via a digital bus using the FOUNDATION® Fieldbus communication protocol. 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 may additionally or alternatively communicate with the controller 11 using the process control data highway 105 and / or by using other suitable control system protocols (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.).

[0028] In FIG. 1 , the wireless field devices 40-46 communicate over the wireless process control communication network 70 using a wireless protocol such as the WirelessHART® protocol. Such wireless field devices 40-46 may communicate directly with one or more other devices or nodes of the wireless network 70 that are also configured to communicate wirelessly (e.g., using the wireless protocol or another wireless protocol). To communicate with one or more other nodes not configured to communicate wirelessly, the wireless field devices 40-46 may utilize a wireless gateway 35 connected to the process control data highway 105 or to another process control communication network. The wireless gateway 35 provides access to the various wireless devices 40-58 of the wireless communication network 70. In particular, the wireless gateway 35 provides a communicative link 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 a communicative link by using the process control data highway 105 and / or by using one or more other communication networks of the process plant 10.

[0029] Like the wired field devices 15-22, the wireless field devices 40-16 of the wireless network 70 perform physical control functions within the process plant 10, such as opening and closing valves, taking measurements of process parameters, etc. However, the wireless field devices 40-46 are configured to communicate using the wireless protocol of the network 70. In this manner, 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.

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

[0031] 1 , the process control system 10 includes one or more operator workstations or user interface devices 8 communicatively connected to a data highway 105. Through the operator workstations 8, an operator may view and monitor the real-time operation of the process plant 10 as well as take any diagnostic, corrective, maintenance, and / or other actions that may be necessary. At least some of the operator workstations 8 may be located within various protected areas within or near the plant 10, and in some situations, 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.

[0032] The example process control system 10 may further include a configuration application (not shown) and a configuration database (not shown), each of which are also communicatively connected to the data highway 105. As described above, various instances of the configuration application (not shown) may run on one or more user interface devices 8, allowing users to create or modify process control modules and download these modules to the controller 11 via the data highway 105, and allowing users to create or modify operator interfaces, through which operators can view data and change data settings within process control routines. The configuration database (not shown) stores the created (e.g., configured) modules and / or operator interfaces.

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

[0034] In some configurations, the process control system 10 includes one or more gateways 7b, 7c to systems external to the proximate process control system 10 (also referred to herein as "edge gateways" and described in more detail below). Typically, such systems are customers or suppliers of information generated or enabled by the process control system 10. For example, a process control plant 10 may include a gateway node 7b for communicatively connecting the proximate process plant 10 to another process plant. Additionally or alternatively, a process control plant 10 may include a gateway node 7c for communicatively connecting the proximate 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 round database, a material handling system, a maintenance management system, a product inventory management system, a manufacturing scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, another provider's process control system, or other external system.

[0035] 1 illustrates only a single controller 11 with a finite number of field devices 15-22 and 40-46, wireless gateway 35, wireless adapter 52, access point 55, router 58, and wireless process control communications network 70 included in the example process plant 10, it should be noted that this example is merely an illustrative 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 processes within the plant 10.

[0036] Additionally, it should be noted that the process plant or control system 10 of FIG. 1 includes a field environment (e.g., a "process plant floor") and a back-end environment (e.g., server 12) communicatively connected by a data highway 105. As shown in FIG. 1, the field environment includes physical components (e.g., process control devices, networks, network elements, etc.) disposed, installed, and interconnected therein that operate to control a process during runtime. 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, disposed, or otherwise included within 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 disposed therein to produce one or more products.

[0037] The back-end environment of the process plant 10 includes various elements, such as computing devices 12, operator workstations 8, databases or data banks, etc., that are shielded and / or protected from the harsh conditions and materials of the field environment. With reference to FIG. 1 , the back-end environment includes, for example, the operator workstations 8, the server computing devices 12, and / or functionality that supports the runtime operation of the process plant 10. In some configurations, the various computing devices, databases, and other elements and equipment included in the back-end environment of the process plant 10 may be physically located at different physical locations, some of which may be local to the process plant 10 and some of which may be remote.

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

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

[0040] It is further understood that the set of devices 202 is not limited to only 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 set of devices 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, etc. Indeed, any of the components shown in FIG. 1 (e.g., components 7a-7c, 8, 11, 12, 15-22, 26, 28, 35, 40-46, 52, 55, 58, 60, and 70), as well as other components not shown, may be devices that generate data for distribution to the remote system 210. Accordingly, the set of devices 202 may be referred to herein as "data sources 202" or "data source devices 202."

[0041] 2 further illustrates a set of remote applications or services 208 that may be utilized for and / or by the process plant 10. The set of remote applications or services 208 may be executed or hosted on one or more remote systems 210. As real-time data is generated by the process plant 10 and received by the applications or services 208, at least some of the applications or services 208 operate in real time on the real-time data. Other applications or services 208 may operate or execute on data generated by the process plant 10 with less stringent timing requirements. Examples of applications / services 208 that are executed or hosted on remote systems 210 and that are consumers of data generated by the process plant 10 include applications that monitor and / or detect conditions and / or events occurring in the process plant 10 and applications or services that monitor at least a portion of the online processes running in the process plant 10 themselves. Other examples of applications / services 208 include descriptive and / or prescriptive analytics, which operate on data generated by the process plant 10 and, in some cases, may operate on knowledge gathered or discovered from analysis of data generated at the process plant, as well as data generated by and received from other process plants. Still other examples of applications / services 208 include one or more routines that implement prescriptive functions and / or changes implemented in the process plant 10, for example, as a result of another service or application. Other examples of applications and services 208 operate on knowledge gathered from analysis of historical data generated by the process plant and / or other process plants, or from comparing data of a process plant entity with data of the same or similar types of process plant entities.

[0042] The one or more remote systems 210 may be implemented in any desired manner, such as by a remote bank of network servers, one or more cloud computing systems, one or more networks, etc. For ease of explanation, the singular form is used herein to refer to one or more remote systems 210, i.e., "remote system 210," but it is understood that the term may refer to one system, multiple systems, or any number of systems. In some scenarios, a computing device 250 that analyzes process plant data may be included within the remote system 210.

[0043] Generally speaking, security architecture 200 provides end-to-end security from the field environment of process plant 10, where devices 202 are installed and operate, to remote systems 210 that provide applications and / or services 208 that consume and operate on data generated by process plant 10. Thus, data generated by devices 202 and other components of process plant 10 can be securely transferred to remote systems 210 for use by remote applications / services 208, while protecting plant 10 from cyber-attacks, intrusions, and / or other malicious events. In particular, security architecture 200 includes a field gateway 212 and an edge gateway 218 disposed between process plant 10 (e.g., between wireless gateways 205A, 205B of process plant 10) and remote systems 210.

[0044] Data leaving the process plant 10 and transmitted from input port 220 to output port 222 may be further protected by encryption. In one example, the field gateway 212 encrypts the data and delivers the encrypted data to input port 220. The encrypted and forwarded data traffic may be User Datagram Protocol (UDP) data traffic in one example, or JSON data traffic or other general-purpose communication format in another example.

[0045] The field gateway 212 is communicatively connected to the process control plant 10. As shown in FIG. 2 , the field gateway 212 is communicatively connected to wireless gateways 205A, 205B, which are disposed within the field environment of the process plant 10 and communicatively connected to one or more devices or data sources 202. As previously mentioned, the devices or data sources 202 and the wireless gateways 205A, 205B may communicate using the WirelessHART industrial protocol or other suitable wireless protocol configured to provide secure communications via one or more security mechanisms. For example, the WirelessHART industrial protocol provides 128-bit AES encryption, and the communication paths 204A, 204B may be protected accordingly.

[0046] Additionally, the communication connection 225 between the wireless gateways 205A, 205B and the field gateway 212 may be secured using the same or a different security mechanism as that utilized for the communication connections 204A, 204B, respectively. In one example, the communication connection 225 is secured by a Transport Layer Security (TLS) wrapper. For example, the wireless gateways 205A, 205B generate HART-IP formatted packets that are secured by the TLS wrapper for relay to the field gateway 212.

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

[0048] Data traveling from the edge gateway 218 to the remote system 210 may be delivered using one or more public and / or private networks, such as a private enterprise network, the Internet, a cellular router, backhaul Internet, or other types of backhaul connections. Importantly, data traveling from the edge gateway 218 to the remote system 210 is protected by using a fourth security mechanism or by using one of the security mechanisms described above. FIG. 2 illustrates data traffic delivered from the edge gateway 218 to the remote system 210 as being protected via a Shared Access Signature (SAS) token, which may be managed through 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 may be valid for only a limited period of time, such as two minutes, five minutes, 30 minutes, one hour, or less. The edge gateway 218 receives and uses the SAS token to secure and authenticate an AMQP (Advanced Message Queuing Protocol) connection to the remote system 210 over which content data is sent from the edge gateway 218 to the remote system 210.

[0049] Security is provided in the remote system 210 via a domain authentication service 232. Thus, only user interface devices 235 that are authenticated and authorized via the domain authentication service 232 can achieve access to at least a portion of the data available in the remote system 210, including, among other things, data generated by the device 202.

[0050] Thus, as described above, security architecture 200 provides end-to-end security for data generated by devices or data sources 202 while operating to control processes in process plant 10, for example, from initiation of the data by data source 202 to its transmission to remote system 210 enabled by one or more remote applications or services 208. Importantly, security architecture 200 provides this end-to-end security while preventing malicious attacks from occurring in process plant 10.

[0051] 2 illustrates the wireless gateways 205A, 205B as communicatively connecting the devices or data sources 202 to the field gateway 212, it should be noted that in some configurations, one or more of the wireless gateways 205A, 205B are omitted and source data is transmitted directly from the data sources 202 to the field gateway 212. For example, the data sources 202 may transmit 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 it an industrial protocol network used to transmit control signals between devices using an industrial communication protocol net (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.). Rather, the big data network of the process plant 10 may be an overlay network implemented for the process plant 10 that streams data between nodes for data processing and analysis purposes, for example. Nodes of the big data network may include, for example, data source 202, wireless gateways 205A, 205B, and field gateway 212, as well as any one or more of components 7a-7c, 8, 11, 12, 15-22, 26, 28, 35, 40-46, 52, 55, 58, 60, and 70 shown in FIG. 1 and other components. Thus, many nodes of a process plant data network each include a dedicated interface for process plant operations that typically utilize an industrial communication protocol and another dedicated interface for data processing / analysis operations that may utilize, for example, a streaming protocol.

[0052] With respect to Figure 2, it is further noted that in some embodiments, a wired gateway (not shown) can be utilized in place of one of the wireless gateways 205A, 205B. Still further, as indicated by box 235 shown in Figure 2, the field gateway 212 and the edge gateway 218 can be physically co-located, or the components 212 and 218 can be physically located across multiple locations. For example, one or more of the field gateway 212 or the edge gateway 218 can be located at the process plant 10. Additionally or alternatively, one or more of the field gateway 212 or the edge gateway 218 can be located remotely from the process plant 10.

[0053] The process plant 10 may be served by multiple field gateways 212, if desired, and any number of field gateways 210 may be served by a single edge gateway 218. In some embodiments, the remote system 210 is served by multiple edge gateways 218, if desired.

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

[0055] When the process plant data is received at the computing device 250, the computing device analyzes the process plant data to identify conditions of the corresponding process plant entities. An indication of the conditions is then transmitted to the user interface device 235, for example, via a domain authentication service. In this manner, an operator may view conditions occurring at various process plant entities within the process plant. The operator may then take appropriate actions to resolve any problems created by these conditions.

[0056] Distributed Ledger Architecture for Process Control Systems 2 as including a single edge gateway 218, the process plant 10 may include several edge gateways, each acting as a validating node in the distributed ledger network. Figure 3 shows an example distributed ledger system 300 for recording process plant data. 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, or any other suitable data generated by or related to one or more process plants.

[0057] The system 300 includes a distributed ledger 312 and multiple nodes 302, 304, 306, 308, and 310, which may be edge gateways within the process plant 10, such as the edge gateway 218, field devices, or any suitable computing devices operating in the process plant 10 or other process plants. Each node maintains a copy of the distributed ledger 312. As changes are made to the distributed ledger 312, each node receives the changes over the network 314 and updates its respective copy of the distributed ledger 312. A consensus mechanism may be used by the nodes 302-310 in the distributed ledger system 300 to determine whether it is appropriate to make a received change to the distributed ledger 312.

[0058] Thus, each node in the system has its own copy of the distributed ledger 312, which is identical to all other copies of the distributed ledger 312 stored by other nodes. The distributed ledger system 300 may be more robust than a central authority database system due to the decentralized nature of the distributed ledger. Therefore, there is no single point of failure in the distributed ledger system 300 as there is in a centralized system.

[0059] 4 illustrates example validating network nodes for settling transactions and an example transaction flow 400 on a distributed ledger network. Figure 4 includes two time frames 420 and 422, represented by the left and right sides of the dotted line, respectively, node A 402 and node B 404 (which may be two edge gateways within process plant 10, or may be two edge gateways in the same or different process plants, etc.), a set of transactions 408A-408D, a set of blocks of transactions 409A-409D, a distributed ledger 410, and a blockchain 418.

[0060] The block propagation flow 400 may begin with node A 402 receiving transaction 406 at time 420. If node A 402 verifies that transaction 406 is valid, node A 402 may add the transaction to a newly created 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 created block 408 as proof of the work done to generate block 408. Alternatively, block 408 may be generated using a proof-of-stake algorithm, whereby node A 402 “stakes” an amount of digital tokens to be used on the network, but the network itself determines which nodes create new blocks. In other embodiments, transaction 406 may be added to a pool of transactions until there are enough 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 A402 may add block 408 to node A402's copy of blockchain 418.

[0061] Although Proof-of-Work and Proof-of-Stake are described herein as consensus algorithms for selecting nodes to create new blocks, these are just a few example consensus algorithms and are not intended to be limiting. Additional consensus algorithms may be utilized, such as Delegated Proof-of-Stake, where, for example, 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, entanglement consensus algorithms, block lattice consensus algorithms, etc.

[0062] In either case, transactions 409A-409D may include updates to state database 416. State database 416 may include 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 newly created block 408 over the network at 412. Node B 404 may verify that block of transactions 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 updates to state database 416 that were rejected by the transactions in block 408. Node B 404 may then transmit block 408 to the rest of the network at time 314.

[0063] 5 illustrates example components of a validation network node 500 on a distributed ledger network for recording process plant data. The node 500 may include at least one processor 502, memory 504, a communications module 506, a set of applications 508, an external port 510, a blockchain manager 514, smart contracts 516, and an operating system 518. In some embodiments, the node 500 may generate new blocks of transactions or broadcast transactions to other network nodes by using the blockchain manager 514. Similarly, the node 500 may use the blockchain manager 514 in conjunction with the smart contracts 516 stored in the memory 504 to perform the functions disclosed herein. The memory 504 may further include a chain data 524 including, for example, a blockchain state database for storing the state of smart contracts deployed thereon.

[0064] 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 contracts 516 stored therein. In some embodiments, the node 500 may have more or fewer components than those described. The components of the node 500 are described in more detail below.

[0065] Node 500 may be used as part of a system that interacts with and / or manipulates transactions associated with data or events occurring in one or several process plants, as part of distributed ledger system 300 or another distributed or centralized network.

[0066] FIG. 6A illustrates an exemplary distributed ledger 600 including a blockchain having blocks 602-608 of transactions within a process control system. In some embodiments, the blockchain 600 includes several blocks 602-608 that are connected to each other to form a chain of blocks 602-608 of transactions. To cryptographically link the blocks and transactions, each block of the blockchain 600 organizes its transactions into a Merkle tree. In a Merkle tree, each transaction is hashed according to a cryptographic hashing algorithm (e.g., SHA-256), and the resulting output hash is then combined with the hash of another transaction. The combined result is then hashed according to a cryptographic hashing algorithm. This output is then combined with the hashes of two other transactions, and this process is repeated until all of the transactions in the block are combined and hashed to generate a Merkle root, which is used in the headers of blocks 602-608. If any single transaction in a block is tampered with, a different Merkle root is generated because the Merkle root is a combination of the hashes of all transactions in the block.

[0067] In other words, transactions may be hashed using a cryptographic hashing algorithm, such as the algorithm described above, and the hash of each transaction may be stored in a tree. Once the tree is constructed, the hashes of each neighboring node at the same level are hashed together to create a new node at a higher level in the tree. Thus, the node at the top of the tree, or Merkle root, depends on the hashes of each transaction stored below it in the tree. Each transaction may include a set of data. The set of data may include transaction data (e.g., input and output addresses, transaction value, document hash value, timestamp, transaction fee value, etc.) that identifies the data of the transaction and the nature of the transaction and what the transaction entails.

[0068] To verify that a block is valid, a node may compare the Merkle root of the block with the Merkle roots of the same block contained in other nodes' copies of the blockchain. The Merkle root can therefore be used as proof of the transactions contained in the block, and as proof that the contents of the block have not been tampered with if the Merkle root is the same in each node's copy of the block.

[0069] In one implementation, documents stored "on" the blockchain are documents hashed according to a cryptographic hash algorithm (e.g., SHA-256), and the resulting output hash is accepted by network nodes that satisfy the blockchain's consensus rules. Thus, documents can later be verified or validated by comparing the document's hash with the hash stored on the blockchain. For example, if a set of documents results in a SHA-256 hash recorded on the blockchain on a particular date, then the blockchain provides cryptographic proof that the documents existed as of that date.

[0070] One way to store a document on the blockchain is to broadcast a transaction to the network that includes a hash of the document, and the transaction will be included in the block if it satisfies all of the network's consensus rules. In some implementations, the blockchain is a permissioned ledger, meaning that only authorized network participants can broadcast transactions. In other implementations, only some authorized network participants may execute certain transactions. For example, product parameter data indicating characteristics of a product produced in the process plant 10 may be uploaded to the blockchain 600 by a field device when the field device determines the product characteristics (e.g., product temperature, product volume, product mass, product density, product pressure, etc.). Only a cryptographic hash of the data may be included in the blockchain 600 so that the data can be verified using the blockchain even if obtained by an off-chain party.

[0071] A validating network node may verify that a signed transaction or message was signed with a private cryptographic key corresponding to a published public cryptographic key owned by the field device collecting the measurement. In at least one implementation, valid identity proof may be enforced by the blockchain network as a consensus rule. Thus, any transaction attempting to add new product parameter data without cryptographic identity proof matching the identity authorized to add the new product parameter data is rejected by the network as not complying with the consensus rule. Each field device in the process plant 10 may be assigned a public / private key pair that is identified in the blockchain network as corresponding to the field device. Additionally, each field device may be authorized to collect specific types of measurements. For example, a first field device may be authorized to collect temperature measurements of a product, and a second field device may be authorized to collect volume measurements indicating the volume of a manufactured product. If a validating network node receives a transaction for product parameter data that is not from an authorized field device or that includes a type of measurement that the field device is not authorized to collect, the validating network node rejects the transaction.

[0072] FIG. 6B illustrates another exemplary distributed ledger 650 that includes a different architecture than that described in FIG. 6A. Similar to the distributed ledger 600 of FIG. 6A, the distributed ledger 650 of FIG. 6B includes a blockchain 660 having blocks 662-668 of transactions within a process control system. The blockchain 660 may be referred to as the main blockchain within the distributed ledger 650. In addition to the main blockchain 660, the distributed ledger 650 includes multiple side blockchains 670, 680, or side chains, maintained by different process plants having blocks 672-676, 682-686 of transactions. For example, the side chain 670 may be maintained by two process plants, i.e., Plant A and Plant B, to record transactions related to events occurring within or between the two process plants. These transactions may include Plant B sending a payment in the form of a token value to Plant A when Plant A ships a product to Plant B. Sidechain 680 may also be maintained by two process plants, Plant C and Plant D, to record transactions related to events occurring within or between Plant C and Plant D. These transactions may include Plant D recording the amount of oil it received from Plant C within a particular time period.

[0073] In some embodiments, the main blockchain 660 is maintained by several process plants, including plants A-D, and several other process plants. Also, in some embodiments, the side chains 670, 680 interact with the main blockchain 660, contributing at least some of the transactions in their respective blocks 672-676, 682-686 to the main blockchain 660. In this manner, the side chains 670, 680 may contain data from transactions associated with the process plants that maintain them. The main blockchain 660 may contain data from transactions associated with each of the process plants. Additionally, the side chains 670, 680 may contain private or confidential data that is not intended to be shared outside the process plant that maintains the particular side chain. Data from the side chain 670 that is not private or confidential is contributed to the main blockchain 660, while private or confidential data is not contributed to the main blockchain 660. For example, the sidechain 670 may execute a smart contract between plant A and plant B that transfers a token value from plant A to plant B when plant A receives product from plant B that meets certain quality standards. Plants A and B may not want to disclose all of the terms of the smart contract by deploying the smart contract to the main blockchain 660, or may not want each measurement of a product's characteristics to be disclosed to the public or a large group of process plants. Additionally, as more transactions are added to the main blockchain 660, the memory storage requirements of the main blockchain 660 increase. Therefore, verifying nodes in the distributed ledger network may reduce the memory requirements for storing some transactions from the main blockchain 660. In any case, if the smart contract determines that plant A has received product from plant B that meets the required quality standards, a transaction transferring a token value from plant A to plant B may be provided to the main blockchain 660.

[0074] In some embodiments, the main blockchain 660 is a public blockchain, meaning any party can view the distributed ledger, submit new information to be added to the ledger, or participate in the network as a validating node. The side chains 670, 680 are private or permissioned blockchains that keep chain data private among a group of entities authorized to participate in the side blockchain network (e.g., side chain 670 may be private between Plant A and Plant 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 side chains 670, 680. For example, the main blockchain 660 may be private among multiple process plants, including Plants A-D and several other process plants, while the side chain 670 is private between Plant A and Plant B.

[0075] In addition to or instead of side chains, 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 plant A and plant B, may open a payment channel, where an initial transaction exchanging a threshold amount of tokens between plant A and plant B is provided to the main blockchain 660. Plant A and plant B may then send portions of the threshold amount to each other and transact with each other without recording anything on the main blockchain 660, as long as none of the transactions result in one of the process plants having more than the threshold amount. Once the two process plants have completed their transactions with each other, they close the payment channel, providing the final token amount for each process plant in the main blockchain 660. For example, plant A may send two tokens to plant B, and then plant A and plant B may open a payment channel. Plant B can then send one token back to plant A so that each process plant has one token, so that plant B sends 0.5 tokens back to plant A as long as neither process plant has more than one token. In other embodiments, the distributed ledger 650 may include multiple blockchain layers, including separate blockchains that operate independently of each other. For example, a first blockchain layer may record transactions related to a supply chain, while a second blockchain layer may record transactions related to the exchange of tokens. The first blockchain layer may be public while the second blockchain layer is private, or vice versa.

[0076] In addition to protecting privacy through sidechain or off-chain transactions, some embodiments may maintain privacy on a public blockchain, such as blockchain 600 shown in Figure 6A. For example, transactions within blockchain 600 may obfuscate the identities of the parties to the transaction and the transaction amount through various encryption techniques.

[0077] 7A-7C illustrate another exemplary distributed ledger 700 that includes a different architecture than that described in FIG. 6A. The distributed ledger 700 of FIGS. 7A-7C includes multiple local blockchains 710, 720, each maintained by a different party or process plant. Each local blockchain 710, 720 includes blocks of transactions 712-716, 722-726 within a process control system. For example, multiple process plants may share resources such as oil from an oil pipeline; electricity from a power generation system; products via rail, road, sea, or air transport; liquid, gas, steam, fuel, or materials via a pipeline; or water from a water distribution system. Field devices in plant A may collect measurements about the shared resource, such as the amount of oil obtained from the pipeline, and broadcast the measurement data in transactions to plant A's local blockchain. Similarly, field devices in plant B may collect measurements about the shared resource and broadcast the measurement data in transactions to plant B's local blockchain.

[0078] As shown in FIG. 7B , transactions from each local blockchain 710, 720 are contributed to a global blockchain 730 for the respective party or process plant, where the global blockchain 730 is maintained by several process plants and / or via a cloud service with several cloud computing systems. For example, blocks from plant A's local blockchain 710 are contributed to plant A's global blockchain 730, blocks from plant B's local blockchain 720 are contributed to plant B's global blockchain, etc. After a threshold period or epoch, blocks may be contributed from the local blockchain to the corresponding global blockchain. In this manner, verifying nodes within a particular process plant that maintain each local blockchain may remove or prune blocks from the local blockchain that have contributed to the global blockchain other than the most recent block to reduce storage requirements.

[0079] As shown in FIG. 7B, block N (reference numeral 742), block N+1 (reference numeral 746), and block N+2 (reference numeral 748) are added to plant A's local blockchain 710 during time epoch E (reference numeral 740). After the threshold period of time epoch E expires, the validator node maintaining plant A's local blockchain 710 contributes blocks N through N+2 (reference numerals 742 through 746) to plant A's global blockchain 730. The validator node maintaining plant A's local blockchain 710 then removes or prunes block N (reference numeral 742) and block N+1 (reference numeral 744) from the local blockchain 710 to reduce storage requirements. At this point, the local blockchain 710 contains only the most recent block, block N+2 (reference numeral 746). Then, during time epoch 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 period of time epoch E+1 expires, the validator node maintaining plant A's local blockchain 710 contributes blocks N+3 through N+4 (reference numerals 752 through 754) to plant A's global blockchain 730. The validator node maintaining plant A's local blockchain 710 then removes or prunes blocks N+2 through N+3 (reference numerals 746, 752) from the local blockchain 710. At this point, the local blockchain 710 contains only the most recent block, block N+4 (reference numeral 754).

[0080] As shown in Figure 7C, validating nodes maintaining global blockchains, such as the global blockchain for plant A 730 and the global blockchain for plant B 770, combine the global blockchains 730, 770 to create a super blockchain 760 having state blocks 762, 764. Each state block 762, 764 includes each of the blocks from the global blockchains 730, 770 for a particular time period. For example, state block K (reference number 762) includes block N, block N+1, and block N+2, respectively, from each global blockchain 730, 770. State block K+1 (reference number 764) includes block N+3, block N+4, and block N+5, respectively, from each global blockchain 730, 770.

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

[0082] The distributed ledger architecture 700 described in Figures 7A-7C, which has a local blockchain, a global blockchain, and a super blockchain, 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 retrieve the 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 of the header of the state block containing the measurement data and comparing the actual Merkle root of the state block's header with the expected Merkle root. This allows competing entities analyzing the super blockchain 760 to verify that the state blocks 762, 764 within the super blockchain 760 have not been tampered with.

[0083] Smart contracts in process control systems As mentioned above, a process control system can deploy smart contracts on a distributed ledger to exchange value, for example, upon receiving a product in good condition. Smart contracts can also be deployed on a distributed ledger to enable machines, such as field devices, to transact on their own without human intervention.

[0084] FIG. 8 illustrates an example smart contract state 806 in a distributed ledger network within a process control system. FIG. 8 includes a blockchain 802, a block of transactions 804, and a secure write request smart contract state 806. A participant in the distributed ledger network or blockchain network (e.g., a plant operator, a configuration engineer, a process control system designer, etc.) may deploy a smart contract to establish, for example, the secure write request contract state 806. The deployed smart contract may expose methods and data to other participants in the blockchain network. Some of the data in the smart contract state may be private data that can only be changed by invoking a method in the smart contract or by authorized blockchain participants. One way to change the smart contract state 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 a block. Including data in the blockchain in a transaction sending it to the smart contract causes validating nodes to update the smart contract's state database, thus allowing network participants to access a rich state mechanism to manage secure write requests and ultimately write parameter data to safety instrumented system (SIS) devices.

[0085] The secure write request smart contract state 806 may include data to identify the operator sending the secure write request, the computing device the operator uses to send the secure write request, and / or the 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 runs 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 another cryptographic public key known by other network participants to belong to the operator's computing device.

[0086] In some embodiments, the contract owner may 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 ID number. For example, each SIS device may have a different unique identifier in the smart contract. The contract owner may specify the identifiers of the operators and / or computing devices authorized to perform secure writes. Subsequent data sent to the smart contract may include messages signed with a private key corresponding to the public key identifying the operator and / or computing device of the smart contract, thus providing cryptographic proof that the transaction was generated by an authorized operator and / or computing device. The private and public keys may be managed solely by the operator / computing device (e.g., the operator / computing device generates a public / private cryptographic key pair offline and provides only the public key to other network participants) to minimize the attack surface of any attacker attempting to forge a transaction. The private keys of the operator and / or computing device may be generated according to a securely stored seed value (e.g., on a physical piece of paper or multiple copies of paper) so that the private keys can be recovered in the event of data loss.

[0087] To write parameter data to the SIS device, the secure write request smart contract state 806 may obtain evidence of the secure write request. The evidence of the secure write request may include the names and / or path information of the parameters to be changed on the SIS device. The evidence may also include the new parameter values, and in some embodiments, the evidence may include a cyclical redundancy check (CRC) value or other error check value along with the new parameter values ​​to ensure that the parameter information is not corrupted or damaged. In some embodiments, in response to receiving the parameter information, the smart contract may provide a confirmation dialog to the operator's computing device that includes the name of the SIS device, the names and / or paths of the parameters to be changed on the SIS device, the new parameter values, and a confirm button for the operator to confirm the secure write request. In this scenario, the evidence may include an indication of whether the operator selected the confirm button.

[0088] 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 identity proof that it came from an operator and / or the operator's computing device authorized to perform the secure write request. Thus, the smart contract may compare the provided identity with a list of operators and / or computing devices authorized to perform secure write requests. In some embodiments, the smart contract may compare the provided identity with a list of operators and / or computing devices authorized to perform secure write requests for the particular SIS device that is the target of the secure write request.

[0089] Another aspect of the smart contract state 806 of a secure write request is the smart contract data. Smart contract data may be thought of like the private and public data of an object created according to an object-oriented programming paradigm, in that smart contract data may be updated directly from outside the object or may be updated only in limited ways, such as by invoking methods on the smart contract. Smart contract data may include the name and / or path of the parameter to be changed on the SIS device and the new parameter value. In some embodiments, smart contract data may include an indication of whether the parameter information was received without corruption. For example, a transaction including the parameter to be changed and the parameter information may also include a CRC value or other error check value. The smart contract may 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 may determine that the parameter information was received without corruption. Also, in some embodiments, smart contract data may include an indication of whether the secure write request was confirmed. For example, if the smart contract receives a transaction by the operator and / or the operator's computing device indicating that the operator selected a confirm button, the smart contract may determine that the secure write request has been confirmed.

[0090] For example, as shown in Figure 8, the smart contract data may include a parameter to lock / unlock the SIS device, a parameter value of "1" or "lock" indicating setting the parameter to lock the SIS device, a confirmed value of "1," "yes," or "true" indicating the secure write request was confirmed, and a received data uncorrupted value of "1," "yes," or "true" indicating the parameter information is intact. Thus, the smart contract may determine that new parameter values ​​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 the secure data write.

[0091] In some embodiments, the secure write request smart contract may provide parameter information to a target SIS device or a controller communicatively coupled to the target SIS device when the operator and / or computing device sending the secure write request is authorized to perform a secure data write, the parameter information is intact, and the secure write request is confirmed. In other embodiments, the secure write request smart contract does not determine whether the parameter information was received without corruption. Instead, in response to receiving the secure write request, the secure write request smart contract provides a first instance of parameter information to the target SIS device or controller, including the parameter name and / or parameter path, the new parameter value, and a CRC value. In response to receiving a confirmation of the secure write request, the secure write request smart contract also provides a second instance of parameter information to the target SIS device or controller. The controller or target SIS device then determines whether the parameter information in both instances is the same and whether the parameter information was received without corruption. If the parameter information in both instances is the same and the parameter information was received without corruption, the controller or target SIS device writes the new parameter value of the parameter to the target SIS device.

[0092] 8 illustrates a smart contract state 806 for a secure write request, which is merely an example smart contract for ease of explanation. Participants in a distributed ledger network (e.g., plant operators, configuration engineers, process control system designers, etc.) may deploy any suitable smart contract related to process control.

[0093] In another example, a smart contract may be deployed that obtains device information for a device within the process plant 10 that experiences a failure and provides the device information to a device supplier in response to receiving a request to share the device information. More specifically, when a device within the process plant 10, such as a process plant entity, experiences a failure, the device may send a transaction to a smart contract address stored in a distributed ledger. The transaction may be cryptographically signed to provide cryptographic proof of identity that it came from the device. In other embodiments, the process plant entity may act as an evidence oracle and send an indication of the failure to a controller, field device, or other process control device that generates the transaction. In either case, the transaction may include device information for the device, such as the device's identity, the make, model, and year of the device, the device's maintenance history, the type of failure, the damaged part within the device, etc.

[0094] In some embodiments, the smart contract transmits the device information to a maintenance personnel's computing device within the process plant 10 for the maintenance personnel to review the device information. Upon reviewing the device information, the maintenance personnel may determine that the device information needs to be reviewed by a device supplier for further investigation of the fault and / or provision of a replacement device or part. Accordingly, the maintenance personnel's computing device may generate a transaction requesting the smart contract to provide the device information to the device supplier. The transaction may be cryptographically signed to provide cryptographic identity proof that the transaction came from the maintenance personnel. In response to determining that the request to provide the device information to the device supplier came from an authorized maintenance personnel, the smart contract may provide the device information to the device supplier's computing device.

[0095] Another exemplary smart contract is a smart contract that obtains a token value from a first process plant, determines that a product meeting certain quality criteria has been 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 may receive an indication that the product has been received at the first process plant from an evidence oracle, such as a field device at the first process plant. The field device may also provide parameter data associated with the product that the smart contract compares to a set of quality metrics to determine whether the product meets the quality criteria. If the product meets the quality criteria, the smart contract provides the token value to the second process plant. Otherwise, the smart contract may return the token value to the first process plant.

[0096] Types of transactions recorded on a distributed ledger within a process control system The distributed ledger of the process control system may include many different types of transactions related to process control, including: 1) transactions related to the delivery or receipt of products at the process plant 10 and the quantities delivered / received, 2) transactions related to software or firmware updates at devices in the process plant 10, such as operator workstations, server devices, controllers, I / O devices, network devices, field devices, etc., 3) transactions related to quality control, production, or regulatory reporting at the process plant 10, 4) transactions recording process plant data, and 5) transactions recording the chain of custody via product tracking data.

[0097] In some scenarios, transactions are provided to a smart contract, for example to modify the smart contract state, while in other scenarios, transactions are not provided to a smart contract but are merely recorded on a distributed ledger as a secure, immutable, trustless record of information related to one or several process plants.

[0098] Transactions involving the delivery or receipt of products and the quantities delivered / received FIG. 9 illustrates an example transaction 906 representing an evidence transaction reporting the amount of oil received from an oil pipeline at process plant 10. While the example transaction 906 in FIG. 9 reports the amount of oil from an oil pipeline, this is merely 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 via rail, road, sea, or air transport; liquid, gas, steam, fuel, or materials via a pipeline; or water from a water distribution system. In either case, transaction 906 may be generated by a field device acting as an evidence oracle. When the field device detects oil flowing through a valve, the field device broadcasts transaction 906 to blockchain 902 in a block, such as block 904.

[0099] Transaction 906 may include a transaction ID and an originator, such as field device 456 in plant A (identified by a cryptographic identity certificate). Transaction 906 may also include identification information related to the product, the provider of the product (e.g., an oil producer), and information regarding the amount of product received. For example, the field device may be a flow sensor that determines the amount of oil taken at plant A over a particular period of time (e.g., an hour, a day, etc.) and includes that amount in the transaction. In other embodiments, the field device may include several flow rates at various time periods in a series of transactions, and the flow rates as a function of time may be used to determine the amount of oil received at plant A. Additionally, transaction 906 may include a cryptographic hash of information regarding the event, the product identifier, and the product provider identifier. In another implementation, the information regarding the event, the product identifier, and the product provider identifier is not stored as a cryptographic hash, but is directly accessible in block 904 by an observer or other network participant.

[0100] In this example, field devices in the process plant 10 receiving the product generate transactions, however, field devices in the process plant 10 or other entities providing the product may generate transactions in addition to or instead of transactions by field devices in the process plant 10 receiving the product.

[0101] Transactions related to software or firmware updates on devices within a process plant To prevent unauthorized software or firmware from being introduced into the process plant 10, software and firmware updates to devices within 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 for devices within the process plant 10, including the date and time of the update, the identity of the user performing the update (via cryptographic identity proof), and the changes to the previous version of the software and / or the new version of the software. A server device 12 or other computing device within the process plant 10 continuously or periodically (e.g., once per second, once per minute, once per hour, once per day, etc.) retrieves the current versions of software and firmware running on devices within the process plant 10. The server device 12 may also retrieve 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 on the distributed ledger. In some embodiments, the distributed ledger stores a cryptographic hash of the new version of the software or firmware and compares the current software or firmware running on the device with the cryptographic hash value to verify that the software or firmware has not been tampered with.

[0102] If the device's current software or firmware does not match the latest version of the software or firmware recorded on the distributed ledger, server device 12 may prevent the device from executing the current software or firmware. In some embodiments, server device 12 may revert 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 running on process plant 10.

[0103] 10 illustrates an example transaction 1006 representing an evidence transaction reporting a software or firmware update in a device within the 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 within the process plant 10 may include, for example, a wireless gateway 35, a router 58, wireless access points 7a, 55, an edge gateway, a wireless adapter 52, etc.

[0104] Transaction 1006 may include a transaction ID and the originator of the software or firmware change, such as John Doe (identified by a cryptographic identity certificate). Transaction 1006 may also include the identity of the device (operator workstation 1234) running the software or firmware (identified by a cryptographic identity certificate) and a description including the version number and the date and time of the update ("Updated to version 10.3.1.4 on January 15, 2019, at 6:02 AM"). Additionally, transaction 1006 may include a cryptographic hash of the software instructions for the new version of the software. In another implementation, the new version of the software is not stored as a cryptographic hash but is directly accessible at block 1004 by observers or other network participants. In some embodiments, consensus rules indicate that only authorized users may record software or firmware updates on the distributed ledger. Thus, when transaction 1006 is broadcast to the distributed ledger, validating nodes validate transaction 1006 if the originator is an authorized user. If the originator is not an authorized user, transaction 1006 will not be included in the distributed ledger and the software update will not match the latest version of the software recorded on the distributed ledger.

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

[0106] Transactions related to quality control, production, or regulatory reporting at a process plant Process plants have reporting and recordkeeping requirements to comply with regulatory agencies such as the Environmental Protection Agency (EPA). For example, the EPA has promulgated the Leak Detection and Repair (LDAR) regulation to minimize emissions of fugitive volatile organic compounds and hazardous air pollutants from leaking equipment, such as valves, pumps, and connectors, within process plants. To comply with the regulation and provide a secure, immutable, and trustless record, regulatory data can be recorded on a distributed ledger. For example, in response to a trigger event, such as an alarm, error, leak, repair event, process milestone, or corrective action, process control elements, such as field devices, controllers, and process plant entities, can generate transactions that include data from the trigger event, such as the time the event occurred, the duration of the event, process parameter values ​​for the process plant entities involved in the event, and product parameter values ​​for the products involved in the event. The regulatory data is then recorded on the distributed ledger so that it can be reviewed by regulatory authorities.

[0107] In some embodiments, when a trigger event occurs, it is detected by one of the process control elements. The process control element then notifies the other process control elements of the trigger event and assigns a unique identifier to the trigger event. In this manner, each of the process control elements can collect measurements related to the trigger event and broadcast transactions to the distributed ledger, each transaction including the same unique identifier for the trigger event.

[0108] In some embodiments, the regulatory data is recorded on a public blockchain so that anyone can view the regulatory data from the process plant 10. In other embodiments, the regulatory data is recorded on a private or permissioned blockchain that is accessible to the process plant 10 and the regulatory agency. In yet other embodiments, the regulatory data is recorded on a private or permissioned blockchain that is accessible to several process plants in the process plant network along with the regulatory agency.

[0109] 11 shows an example transaction 1106 representing an evidence transaction reporting process parameter or product parameter data. The transaction 1106 may be generated by a process plant entity, which may be a device within the process plant 10 used in part of a process that contains, transforms, creates, or transports physical materials, such as a valve, tank, mixer, pump, heater, etc.

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

[0111] Additionally, transaction 1106 may include a cryptographic hash of the product and / or process parameter data along with data related to the trigger event. In another implementation, the product parameter data, process parameter data, and other data related to the trigger event are not stored as cryptographic hashes, but are directly accessible in block 1104 by observers or other network participants.

[0112] As described above, trigger events may include alarms, errors, leaks, repair events, corrective actions, etc. In an exemplary scenario, the trigger event may be a leak in the process plant 10 caused by the opening of a relief valve. The relief valve may open when pressure in the process control system exceeds a threshold amount of pressure, or the relief valve may open proportionally to the amount of pressure detected at the valve. When the relief valve opens, the relief valve or one or several other field devices may detect the time of opening, the duration of the opening, the size of the opening, the pressure at which the relief valve opened, the flow rate of fluid leaking through the relief valve, and / or fluid characteristics such as the temperature of the fluid, the type of fluid, etc. In some embodiments, the amount of fluid leaking through the relief valve may also be determined based on the flow rate, the size of the opening, and the duration of the opening of the relief valve. The relief valve and / or one or several other field devices may then generate a transaction similar to transaction 1106 including the same unique identifier of the trigger event and / or the same description for the trigger event of a leak caused by the opening of the relief valve. Each transaction may also include process parameter data such as the time of opening, the size of the opening, the pressure of the relief valve, the flow rate of the fluid leaking from the relief valve, etc. The transaction may also include product parameter data such as the characteristics of the fluid, etc. The device generating the transaction then broadcasts the transaction to the distributed ledger network for validating nodes such as edge gateways to confirm that the transaction is valid and include the transaction in the distributed ledger.

[0113] A regulator reviewing the incident may request and retrieve from the distributed ledger the event data included in the transaction having the triggering event identifier. The regulator's computing device, such as computing device 235 shown in FIG. 2 , may then present the event data on a user interface. In other embodiments, the distributed ledger includes a cryptographic hash of the event data that is provided to the regulator's computing device 235 in response to a request to authenticate the event data. The event data is retrieved from another data source, such as a database communicatively coupled to server device 12 within process plant 10. The regulator's computing device 235 then calculates a cryptographic hash of the retrieved event data and compares the cryptographic hash of the retrieved event data with the cryptographic hash of the event data from the distributed ledger. If the cryptographic hashes are the same, the regulator's computing device 235 determines that the event data from the database has not been tampered with. Otherwise, the regulator's computing device 235 determines that the event data from the database is untrustworthy.

[0114] Transaction Record Process Plant Data In addition to recording process parameter data and product parameter data in transactions related to trigger events, process and product parameter data may be included in transactions not related to trigger events, for example, to maintain an accurate record of the operation of the process plant 10. Other types of process plant data, such as configuration data, user interaction data, maintenance data, commissioning data, plant network data, product tracking data, or any other suitable data generated by or related to one or more process plants, may also be included in the transactions. User interaction data may include actions performed by an operator or configuration engineer, for example, at an operator's workstation. An operator may adjust set points, respond to alarms, etc., via user controls on the operator workstation, which may be included in the transaction as user interaction data. In this manner, if a competing entity questions the quality of a product produced by the process plant 10, the process plant 10 may retrieve process plant data related to the product from the distributed ledger. The process plant 10 may then review the records of each of the process plant entities involved in producing the product, the parameter values ​​of the process plant entities when the product was produced, the parameter values ​​of the product at various stages in the production process, trigger events that occurred during the production of the product, etc. Thus, the process plant 10 may determine whether the product was properly produced to meet certain quality standards or whether an anomaly occurred during production that caused the product to not meet the quality standards.

[0115] Process plant data may also be used to perform root cause analysis of products. For example, a product may have a predicted shelf life, such as gasoline, which has a half-life of less than one month. In some embodiments, a computing device may predict the shelf life of a product based on product characteristics, including process parameter data and product parameter data, recorded on a distributed ledger during the product's manufacture. The computing device may also predict the product's shelf life based on historical data of similar components and / or similar products having process parameter data and product parameter data during manufacture. More specifically, the computing device may predict the product's shelf life based on the average shelf life of products of the same type (e.g., gasoline).

[0116] The computing device can 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, components can be classified as above average, average, or below average. The component designation can be stored in a database along with an associated ranking or quality score. Components with a quality score below a first threshold score or a ranking below a first threshold ranking can be classified as below average. Components with a quality score above a first threshold score and below a second threshold score or a ranking above a first threshold ranking can be classified as average. Components with a quality score above a second threshold score or a ranking above a second threshold ranking can be classified as above average.

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

[0118] 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 the previous product, the components of the previous product, and the characteristics of the previous product.

[0119] Additionally, if the actual shelf life of a product differs from the predicted shelf life, the computing device may retrieve process plant data related to the product from the distributed ledger to identify the cause. For example, the actual shelf life may be shorter than the predicted shelf life due to poor product quality. In another example, the actual shelf life may be shorter than the predicted shelf life due to heaters within the process plant 10 heating the product to an undesirable temperature.

[0120] Transactions that record the chain of custody via product tracking data To provide an accurate record of the chain of custody of a product within a supply chain, transactions may be generated that include the identity of the source or supplier of the product and entities that handled the product, such as manufacturers, distributors, distribution facilities, retailers, and customers who purchase the product. More specifically, a transaction may include product tracking data with an identity of the product, an identity of the product's supplier / manufacturer, an identity of the manufacturer / provider of each of the product's components, an identity of the entity in the supply that receives and handles the product, an identity of the retailer that sells the product, and / or an identity of the customer who 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 an identity of the delivering entity, an identity of the receiving entity, and an indication that the product is being transferred to the receiving entity.

[0121] Thus, a user, such as a customer, may retrieve, via a user interface device, each of the transactions related to a particular product from the distributed ledger using the product's identification information. The user interface device may then display, via the user interface, a representation of the product's supplier or source, and the entities that handled the product, such as manufacturers, distributors, distribution facilities, retailers, customers purchasing the product, etc. The user interface device may also display, via the user interface, a representation of the product's components. The user may then retrieve, via the user interface, each of the transactions related to a particular component of the product from the distributed ledger using the component's identification information. The user interface device may then display, via the user interface, a representation of the component's supplier or source, and the entities that handled the component, such as manufacturers, distributors, distribution facilities, etc.

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

[0123] 12 shows a flow diagram illustrating an example method 1200 for recording data in a process control system using a distributed ledger. The method 1200 may be performed by field devices 15-22, 40-46 in the process plant 10, a controller 11 in the process plant 10, or another computing device in the process plant 10, such as an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, or a network device 35.

[0124] At block 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, or a heat exchanger. 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, within, and / or controlled by the process control element (e.g., temperature of a fluid in a tank, flow rate of a fluid exiting a valve). Next, at block 1204, a transaction is generated that includes the 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 (block 1206) and augments the transaction with identity data of the entity, such as a public cryptographic key possessed by the entity (block 1208). For example, the transaction may be signed with a private cryptographic key corresponding to a public cryptographic key possessed by the entity.

[0125] At block 1210, the transaction is sent to participants in the distributed ledger network. For example, a field device may broadcast the transaction to the distributed ledger network. A validating node, such as an edge gateway, may then verify that the transaction is valid, add the transaction to a block of transactions, solve the cryptographic puzzle, and include the solution in the 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 of the other validating nodes in the distributed ledger network for inclusion in their respective copies of the distributed ledger.

[0126] In some embodiments, a validating node validates a transaction against a set of consensus rules and adds the transaction to a block if the transaction satisfies each of the consensus rules. For example, consensus rules may include that the originator of the transaction provide identity proof so that only authorized entities may originate transactions on the distributed ledger. Consensus rules may require that blocks and transactions adhere to formatting requirements and provide specific meta-information about the transaction (e.g., blocks must be under a size limit, transactions must contain a number of fields, etc.). Any transaction that does not satisfy the consensus rules is ignored by validating nodes receiving the transaction, and the transaction is not propagated to other nodes.

[0127] A validator node includes a transceiver that communicates with field devices, controllers, or other computing devices within the process plant 10 to broadcast transactions with distributed ledger data, such as process plant data. Additionally, a validator node may include memory for storing a copy of the distributed ledger, including a state database that stores the state of smart contracts deployed to the distributed ledger. Furthermore, a validator node may include applications such as a process data validator that applies a set of consensus rules to the distributed ledger data and appends the distributed ledger data to the validator node's copy of the distributed ledger if the distributed ledger data satisfies the consensus rules.

[0128] 13 shows a flow diagram depicting an example method 1300 for secure metering of untrusted data in a process control system using a distributed ledger. The method 1300 may be performed by the field devices 15-22, 40-46 in the process plant 10, the controller 11 in the process plant 10, or another computing device in the process plant 10, such as an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, or a network device 35. The method 1300 may also be performed by a validating node, such as an edge gateway, or a combination of a field device and a validating node.

[0129] At block 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, within, and / or controlled by the process control element (e.g., temperature of a fluid in a tank, flow rate of a fluid exiting a valve). Then, at block 1304, a transaction is generated that includes the 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 and augments the transaction with identity data of the entity, such as a public cryptographic key owned by the entity. For example, the transaction may be signed with a private cryptographic key corresponding to a public cryptographic key owned by the entity.

[0130] At block 1306, the transaction is sent to participants in the local distributed ledger network. There may be several local distributed ledgers, where each local distributed ledger is maintained by a different party or process plant. For example, the local distributed ledger network for Plant A may consist of an edge gateway within Plant A. The edge gateway may record transactions including process plant data related to events and devices within Plant A. The transactions are then added to the local distributed ledger at a threshold period or time epoch. After the threshold period expires (block 1308), the validating node maintaining the local distributed ledger contributes the transactions or blocks of transactions generated during the threshold period to the global distributed ledger network (block 1310). The global distributed ledger network may include validating nodes across multiple process plants, such as a cloud service with several cloud computing systems. The validating nodes may maintain a global distributed ledger (e.g., a global blockchain) for each process plant. Validation nodes in the local distributed ledger network may then remove or prune blocks from the local distributed ledger that were contributed to the global distributed ledger other than the most recent block. Validation nodes of the local distributed ledger may continue to generate blocks, broadcast them to the global distributed ledger network at the end of each time epoch, and remove local copies of blocks as they are added to the global blockchain.

[0131] Also, in some embodiments, each of the global blockchains of each respective entity or process plant is combined to create a super blockchain having state blocks, each state block containing each of the blocks from the global blockchain corresponding to a particular period or time epoch.

[0132] 14 shows a flow diagram illustrating an example method 1400 for recording quality control, production, or regulatory data in a process control system using a distributed ledger. The method 1400 may be performed by field devices 15-22, 40-46 in the process plant 10, a controller 11 in the process plant 10, or another computing device in the process plant 10, such as an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, or a network device 35.

[0133] At block 1402, a trigger event related to quality control is detected by a process control element. The trigger event may be an alarm, an error, a leak, a repair event, a process milestone, a corrective action, etc. In some embodiments, an indication of the trigger 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 trigger event.

[0134] In any event, event data for the trigger event is obtained at block 1404. The event data may include a unique identifier for the trigger event, a time of the trigger event, a duration of the trigger event, a description of the trigger event, an identification of the process control element involved in the trigger event, an identification of the product being manufactured by the process control element during the triggered event, etc. Then, at block 1406, a transaction is generated that includes the event data and / or a cryptographic hash of the event data for the trigger event. The transaction may also include an identification of the originator of the transaction, product parameter data for the product at the time of the trigger event, process parameter data for the process control element during the trigger event, or other suitable information. In some embodiments, several field devices, controllers, or other computing devices within the process plant 10 may generate a transaction related to the trigger event. For example, a first field device may generate a transaction that includes the temperature in a heater at the time of the trigger event, while a second field device may generate a transaction that includes the speed of a pump at the time of the trigger event.

[0135] At block 1408, the transaction is sent to participants in the distributed ledger network. For example, a field device may broadcast the transaction to the distributed ledger network. A validating node, such as an edge gateway, may then verify that the transaction is valid, add the transaction to a block of transactions, solve the cryptographic puzzle, and include the solution in the 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 of the other validating nodes in the distributed ledger network for inclusion in their respective copies of the distributed ledger.

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

[0137] The event data stored in the database is then compared to the cryptographic hash included in the distributed ledger to authenticate the event data (block 1412). If there is a match, the event data has not been tampered with. For example, a regulatory agency reviewing the incident may request and obtain a cryptographic hash of the event data from the distributed ledger included in the transaction having the triggering event identifier. The event data is obtained from another data source, such as a database communicatively coupled to the server device 12 within the process plant 10. The regulatory agency's computing device then calculates a cryptographic hash of the obtained event data and compares the cryptographic hash of the obtained event data with the cryptographic hash of the event data from the distributed ledger. If the cryptographic hashes are the same, the regulatory agency's computing device determines that the event data in the database has not been tampered with. Otherwise, the regulatory agency's computing device determines that the event data from the database is untrustworthy. In other embodiments, a computing device within the process plant 10 retrieves the event data stored in the database and the cryptographic hash of the event data from the distributed ledger and compares the event data with the cryptographic hash to authenticate the event data.

[0138] 15 shows a flow diagram illustrating an example method 1500 for recording the state of software or firmware in a process control system and connected instrumentation using a distributed ledger. The method 1500 may be performed by field devices 15-22, 40-46 in the process plant 10, a controller 11 in the process plant 10, or another computing device in the process plant 10, such as an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, or a network device 35.

[0139] At block 1502, the current state of software or firmware running on a device within the process plant 10 is obtained. For example, a device within the process plant 10 that receives a software or firmware update may obtain the new version of the software or firmware. The device may 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 block 1504, the device may generate a transaction that includes a representation of the current state of the software or firmware. For example, the representation may be a cryptographic hash of the software instructions for the new version of the software. The transaction may also include the originator of the software or firmware change identified by cryptographic identity proof, the identity of the device running the software or firmware, a description of the update, the date and time of the update, etc.

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

[0141] In some embodiments, a validator node validates a transaction against a set of consensus rules and adds the transaction to a block if the transaction satisfies each of the consensus rules. Also, in some embodiments, the consensus rules dictate that only authorized users may record software or firmware updates on the distributed ledger. Thus, when a transaction is broadcast to the distributed ledger, the validator node validates the transaction if the originator is an authorized user. If the originator is not an authorized user, the transaction will not be included in the distributed ledger and the software update will not match the latest version of the software recorded on the distributed ledger.

[0142] In any event, at block 1508, the state of the software or firmware running on the devices within the process plant 10 is obtained. For example, a 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 versions of the software and firmware running on the devices within the process plant 10. The software or firmware state obtained by the server device 12 is then compared to a 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 software or firmware state matches the cryptographic hash value of the software or firmware stored in the distributed ledger, the software or firmware continues to run 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, server device 12 then downloads the previous state of the software to the device, and the device resumes execution of the software in the previous state.

[0143] 16 shows a flow diagram illustrating an example method 1600 for creating smart contracts in a process control system using a distributed ledger. The method 1600 may be performed by field devices 15-22, 40-46 in the process plant 10, a controller 11 in the process plant 10, or another computing device in the process plant 10, such as an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, or a network device 35.

[0144] At block 1602, smart contracts associated with one or more process plants are generated. For example, the smart contract may transfer a token value from plant A to plant B when plant A receives product from plant B that meets certain quality standards. 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 failing device and provides the device information to a device supplier in response to receiving a request to share the device information.

[0145] At block 1604, the smart contract is deployed to an address stored in the distributed ledger. The deployed smart contract may expose methods and data to other participants in the distributed ledger network. Some of the data in the smart contract state may be private data that can only be changed by invoking methods in the smart contract or by authorized distributed ledger participants. One way to change the smart contract state 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.

[0146] In some embodiments, validating nodes such as edge gateways execute code encapsulated in smart contracts, and field devices act as evidence oracles, providing evidence transactions that modify the smart contract state.

[0147] 17 shows a flow diagram illustrating an example method 1700 for interacting with smart contracts in a process control system using a distributed ledger. The method 1700 may be performed by field devices 15-22, 40-46 in the process plant 10, a controller 11 in the process plant 10, or another computing device in the process plant 10, such as an operator workstation, a server device 12, a user interface device 8, an I / O device 26, 28, or a network device 35.

[0148] In block 1702, event data is obtained from events occurring within the process plant 10. The events may be a product delivered by or received at the process plant 10, the completion of a product manufactured at the process plant 10, a change in a product characteristic, a change in a process parameter value, a trigger event such as an alarm, an error, a leak, a repair event, a corrective action, or the like, a user interaction such as a request to write to a SIS device, a request to provide device information to a device supplier, or a request to transfer a token value upon receipt of a particular product, or any other suitable event occurring within 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 associated with the event, such as the date and time of the event, the duration of the event, a description of the event, etc.

[0149] A transaction is then generated at block 1704, including the event data and identifying information of the entity generating the transaction, such as a cryptographic public key assigned to the entity. The transaction may be cryptographically signed to provide cryptographic proof of identity of the entity generating the transaction. At block 1706, the transaction is sent to an address on the distributed ledger where the smart contract is deployed. In this manner, a validating node, such as an edge gateway, modifies the smart contract state according to the event data included in the transaction.

[0150] For example, a smart contract may transfer a token value from Plant A to Plant B when Plant A receives product from Plant B that meets certain quality standards. A field device in Plant A may generate a transaction including event data related to product quality, such as an identification of Plant A, an identification of the product, an indication that the product was received from Plant B, and product parameter data describing product characteristics (e.g., product temperature, product volume, product density, product viscosity, or product chemical composition). The field device may provide the transaction to the address of the smart contract, and the validating node may modify the smart contract state to include the product parameter data. In some embodiments, the smart contract compares the product characteristics included in the product parameter data to a set of minimum threshold requirements for the product to meet appropriate quality standards. If the product meets the quality standards, the smart contract may transfer the token value to Plant B. In some embodiments, a field device in Plant B may generate a transaction including product quality-related event data, such as process parameter data describing parameter values ​​of process plant entities in Plant B involved in the production of the product, the parameter values ​​being collected during the production of the product.

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

[0152] 1. A validating network node in a process plant on a distributed ledger network, the validating network node including: a transceiver configured to communicate with one or more field devices, each field device performing a physical function to control an industrial process in the process plant and exchanging distributed ledger data with peer network nodes, 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 verifier configured to apply a set of consensus rules to the distributed ledger data received from the peer network nodes, wherein the process data verifier is further configured to append the distributed ledger data received from the peer network nodes to the copy of the distributed ledger if the distributed ledger data satisfies the consensus rules.

[0153] 2. The validating network node of aspect 1, wherein the distributed ledger data received from the peer node includes an identity proof of the entity generating the transaction with the process plant data.

[0154] 3. The validating network node of any one of the preceding aspects, wherein, to append the distributed ledger data received from the peer node, the transaction validator is configured to solve a cryptographic puzzle based on the block of transactions, add the solution to the cryptographic puzzle to the block of transactions, append the block of transactions to a copy of the distributed ledger, and transmit the block of transactions to at least one of the peer network nodes in the distributed ledger network.

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

[0156] 5. The validation network node of any one of the preceding aspects, wherein the process data verifier is further configured to execute code in the smart contract and update a state database of the smart contract.

[0157] 6. The validating network node of any one of the preceding aspects, wherein the process data verifier is further configured to ignore distributed ledger data received from a peer network node if the distributed ledger data does not satisfy the consensus rules.

[0158] 7. The validation network node of any one of the preceding aspects, wherein the validation network node and the peer network node are devices within the same process plant.

[0159] 8. The validation network node of any one of the preceding aspects, wherein the validation network node and the peer network node are devices in multiple process plants.

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

[0161] 10. The method of aspect 9, wherein generating the transaction includes generating a cryptographic signature based on the transaction and augmenting the transaction with the cryptographic signature.

[0162] 11. The method of any one of aspect 9 or aspect 10, wherein data is obtained from a field device in the process plant and generating a transaction further includes obtaining identity data for the field device and augmenting the transaction with the identity data.

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

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

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

[0166] 15. The method of any one of aspects 9-14, wherein the distributed ledger network includes multiple layers, and further comprising: generating, at a first instance, transactions to be stored in a first layer of the distributed ledger; and generating, at a second instance, transactions to be stored in a second layer of the distributed ledger.

[0167] 16. The method of 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.

[0168] 17. The method of any one of aspects 9-16, wherein the distributed ledger is at least one of a blockchain, a tangle, a block lattice, or other directed acyclic graph.

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

[0170] 19. The method of any one of aspects 9-18, wherein generating the transaction includes generating a transaction including a cryptographic hash value corresponding to the process plant data.

[0171] 20. A system for recording data in a process control system using a distributed ledger maintained by multiple participants, the system including: one or more devices disposed in the process plant, each device performing a physical function to control an industrial process; and a computing device executing within the process plant, the computing device including 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 having instructions stored thereon, the instructions, when executed by the one or more processors, causing the computing device to obtain process plant data related to the one or more devices in the process plant, generate transactions including the process plant data, and transmit the transactions to at least one other participant in a distributed ledger network of the participants maintaining the distributed ledger for verification and recording of the transactions in the distributed ledger.

[0172] 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.

[0173] 22. The system of any one of aspects 20 or 21, wherein data is obtained from a field device in a process plant and, to generate a transaction, the instructions cause a computing device to obtain identity data for the field device and augment the transaction with the identity data.

[0174] 23. The system of any one of aspects 20-22, wherein the instructions further cause the computing device to add the transaction to a block of transactions, solve a cryptographic puzzle based on the block of transactions, add the solution to the cryptographic puzzle to the block of transactions, and transmit the block of transactions to at least one other participant in the distributed ledger network.

[0175] 24. The system of any one of aspects 20-23, wherein the distributed ledger network includes multiple layers, and the instructions further cause the computing device to generate, in a first instance, transactions that are stored in the first layer of the distributed ledger and, in a second instance, generate transactions that are stored in the second layer of the distributed ledger.

[0176] 25. The system of any one 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.

[0177] 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.

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

[0179] 28. The system of any one of aspects 20-27, wherein generating the transaction includes generating a transaction including a cryptographic hash value corresponding to the process plant data.

[0180] 29. A non-transitory computer-readable memory coupled to one or more processors and storing instructions that, when executed by the one or more processors, cause the one or more processors to receive transactions including process plant data generated by one or more field devices, each field device performing a physical function to control an industrial process within the process plant, store a copy of a distributed ledger, apply a set of consensus rules to the received transactions, append one of the received transactions to the copy of the distributed ledger if the received transaction satisfies the consensus rules, and transmit the appended transaction to at least one peer network node that stores a copy of the distributed ledger.

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

[0182] 31. The computer-readable memory of any one of aspect 29 or aspect 30, wherein, to append one of the received transactions, the instructions cause one or more processors to solve a cryptographic puzzle based on a block of transactions that includes the received transaction, add a solution to the cryptographic puzzle to the block of transactions, append the block of transactions to a copy of the distributed ledger, and transmit the block of transactions to a peer network node.

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

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

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

[0186] 35. The computer-readable memory of any one of aspects 29-34, wherein the peer network nodes are devices in multiple process plants.

[0187] 36. A method for secure metering of untrusted data in a process control system using a distributed ledger maintained by multiple participants, the method comprising: collecting measurements of a parameter in a process plant by field devices that perform a physical function to control an industrial process in the process plant; obtaining the measurements of the parameter by a computing device; generating transactions including the measurements; sending the transactions to at least one other participant to a local distributed ledger network of a participant maintaining a local distributed ledger; and after a threshold period of time, sending a plurality of transactions generated during the threshold period to at least one participant to a global distributed ledger network of a participant maintaining a global distributed ledger.

[0188] 37. The method of aspect 36, further comprising: 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.

[0189] 38. The method of any one of aspect 36 or aspect 37, further comprising, after the threshold period, transmitting one or more local blocks of transactions generated during the threshold period to at least one participant in the global distributed ledger network.

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

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

[0192] 41. The method of any one of aspects 36-40, wherein the parameter relates to a shared resource between multiple entities that operate multiple process plants.

[0193] 42. The method of any one of aspects 36-41, wherein the global distributed ledger includes multiple global distributed ledgers corresponding to multiple entities, each global distributed ledger including transactions stored in a local distributed ledger for the same respective entity as the global distributed ledger.

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

[0195] 44. The method of any one of aspects 36-43, wherein the local distributed ledger is a private blockchain viewable by the entity that operates the process plant.

[0196] 45. The method of any one of aspects 36-44, wherein generating a transaction including the measurement value includes generating a transaction including a cryptographic hash value corresponding to the measurement value.

[0197] 46. ​​The method of any one of aspects 36-45, wherein the shared resource among multiple entities operating the multiple process plants is a fluid in a fluid pipeline, and the parameter measurement is a quantity of fluid obtained by one of the multiple entities from the fluid pipeline.

[0198] 47. A system for secure metering of untrusted data in a process control system using a distributed ledger maintained by multiple participants, the system including: one or more devices disposed in a process plant, each performing a physical function to control an industrial process; one or more field devices disposed in the process plant, the one or more field devices configured to collect measurements of parameters within the process plant and provide the parameter measurements to one or more gateway devices; one or more edge gateways executing within the process plant, each including 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 having instructions stored thereon, the instructions, when executed by the one or more processors, causing the edge gateway device to obtain at least one of the parameter measurements, generate a transaction including the measurement value, and transmit the transaction to at least one other edge gateway in a local distributed ledger network of the edge gateway maintaining the distributed ledger; and, after a threshold time period, transmit a plurality of transactions generated during the threshold time period to at least one participant in a global distributed ledger network of a participant maintaining a global distributed ledger.

[0199] 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 send the local block of transactions to at least one other edge gateway in the local distributed ledger network.

[0200] 49. The system of any one of aspect 47 or aspect 48, wherein the instructions further cause the edge gateway to, after the threshold period, transmit one or more local blocks of transactions generated during the threshold period to at least one participant in the global distributed ledger network.

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

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

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

[0204] 53. The system of any one of aspects 47-52, wherein the global distributed ledger includes multiple global distributed ledgers corresponding to multiple entities, each global distributed ledger including transactions stored in a local distributed ledger of the same respective entity as the global distributed ledger.

[0205] 54. The system of any one of aspects 47-53, further including a computing device in the global distributed ledger network that maintains the global distributed ledger, the computing device including 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 having instructions stored thereon, the instructions, when executed by the one or more processors, causing the computing device to, for transactions generated during a threshold time period, add transactions from each of the plurality of global distributed ledgers to a state block of transactions, solve a cryptographic puzzle based on the state block of transactions, add the solution to the cryptographic puzzle to a local block of transactions, and transmit the state block of transactions to at least one other participant in the super blockchain network of participants maintaining the super blockchain.

[0206] 55. The system of any one of aspects 47-54, wherein the local distributed ledger is a private blockchain viewable by entities that operate the process plant.

[0207] 56. The system of any one of aspects 47-55, wherein the transaction includes a cryptographic hash value corresponding to the measurement value.

[0208] 57. The system of any one of aspects 47-56, wherein the shared resource among multiple entities operating the multiple process plants is a fluid in a fluid pipeline, and the parameter measurement is a quantity of fluid obtained by one of the multiple entities from the fluid pipeline.

[0209] 58. A validating network node in a process plant on a local distributed ledger network, the validating network node comprising: a transceiver configured to (i) communicate with one or more field devices, each performing a physical function to control an industrial process within the process plant and collecting parameter measurements within the process plant, and (ii) exchange local distributed ledger data with peer network nodes, the local distributed ledger data including transactions having the parameter measurements; a storage medium configured to store a copy of the distributed ledger; and a process data verifier configured to apply a set of consensus rules to the distributed ledger data received from the peer network node, wherein the process data verifier is 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; and the transceiver configured to, after a threshold period, transmit a plurality of transactions generated during the threshold period to at least one participant in a global distributed ledger network of participants maintaining a global distributed ledger.

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

[0211] 60. The validation network node of 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.

[0212] 61. The validation network node of any one of aspects 58-60, wherein at least one of the parameters relates to a shared resource between multiple entities operating multiple process plants.

[0213] 62. The validation network node of any one of aspects 58-61, wherein the global distributed ledger includes multiple global distributed ledgers corresponding to multiple entities, each global distributed ledger including transactions stored in a local distributed ledger of the same respective entity as the global distributed ledger.

[0214] 63. The validation network node of any one of aspects 58-62, wherein the local distributed ledger is a private blockchain viewable by entities that operate the process plant.

[0215] 64. The validating network node of any one of aspects 58-63, wherein the transaction includes a cryptographic hash value corresponding to the parameter measurement.

[0216] 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 in a process plant via one or more field devices, each performing a physical function to control an industrial process; obtaining event data from the trigger event, the event data including at least one of a time of the trigger event, a duration of the trigger event, product parameter data associated with the trigger event, or process parameter data associated with the trigger event; generating a transaction including the event data, the transaction being stored in the distributed ledger; and transmitting the transaction to at least one other participant in a distributed ledger network of participants maintaining the distributed ledger.

[0217] 66. The method of aspect 65, wherein the trigger event is at least one of an alarm, an error, a leak, a repair event, a process milestone, or a corrective action.

[0218] 67. The method of any one of aspect 65 or aspect 66, further including receiving a request for event data from a particular trigger event, retrieving the event data from the distributed ledger, and presenting the event data from the particular trigger event on a user interface.

[0219] 68. The method of any one of aspects 65-67, wherein generating transactions including the event data includes generating transactions including cryptographic hash values ​​corresponding to at least some of the event data.

[0220] 69. The method of any one of aspects 65-68, further comprising: storing the event data in a database; and, in response to a request to authenticate the event data, providing a cryptographic hash value corresponding to at least a portion of the event data from the distributed ledger along with the event data from the database to verify authenticity of the event data.

[0221] 70. The method of any one of aspects 65-69, wherein the trigger event is the opening of a relief valve, and the event data from the trigger event includes at least one of: a time that the relief valve was opened, a duration that the relief valve was open, a pressure value when the relief valve was opened, or an amount of liquid removed while the relief valve was open.

[0222] 71. The method of any one of aspects 65-70, wherein the distributed ledger is a private blockchain accessible by the process plant and regulatory authorities.

[0223] 72. The method of any one of aspects 65-71, wherein the distributed ledger is a public blockchain.

[0224] 73. The method of any one of aspects 65-72, wherein the transaction further includes a unique identifier of the trigger event.

[0225] 74. The method of any one of aspects 65-73, further comprising: transmitting an indication of the detected trigger event, including a unique identifier of the trigger 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 trigger event.

[0226] 75. A system for recording quality control, production, or regulatory data in a process control system using a distributed ledger maintained by multiple participants, the system including: one or more devices disposed within a process plant, each performing a physical function to control an industrial process; and a computing device executing within the process plant, the computing device including 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 having instructions stored thereon, the instructions, when executed by the one or more processors, causing the computing device, via the one or more devices, to detect a trigger event related to quality control within the process plant; obtain event data from the trigger event, the event data including at least one of a time of the trigger event, a duration of the trigger event, product parameter data associated with the trigger event, or process parameter data associated with the trigger event; generate a transaction including the event data; store the transaction in the distributed ledger; and transmit the transaction to at least one other participant in a distributed ledger network of the participant maintaining the distributed ledger for validation and recording of the transaction in the distributed ledger.

[0227] 76. The system of aspect 75, wherein the trigger event is at least one of an alarm, an error, a leak, a repair event, a process milestone, or a corrective action.

[0228] 77. The system of any one of aspect 75 or aspect 76, wherein the instructions further cause the computing device to receive a request for event data from a particular trigger event, retrieve the event data from the distributed ledger, and present the event data from the particular trigger event on a user interface.

[0229] 78. The system of any one of aspects 75-77, wherein the transaction includes a cryptographic hash value corresponding to at least a portion of the event data.

[0230] 79. The system of any one of aspects 75-78, wherein the instructions further cause the computing device to store the event data in a database and, in response to a request to authenticate the event data, provide a cryptographic hash value corresponding to at least a portion of the event data from the distributed ledger along with the event data from the database to verify authenticity of the event data.

[0231] 80. The system of any one of aspects 75-79, wherein the trigger event is the opening of a relief valve, and the event data from the trigger event includes at least one of the following: the time the relief valve was opened, the duration the relief valve was open, the pressure value when the relief valve was opened, or the amount of liquid removed while the relief valve was open.

[0232] 81. The system of any one of aspects 75-80, wherein the distributed ledger is a private blockchain accessible by the process plant and regulatory authorities.

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

[0234] 83. The system of any one of aspects 75-82, wherein the transaction further includes a unique identifier of the trigger event.

[0235] 84. The system of any one of aspects 75-83, wherein the instructions further cause the computing device to transmit an indication of the detected trigger event, including a unique identifier of the trigger event, to one or more devices within the process plant, for the one or more devices to generate a transaction including additional event data related to the trigger event.

[0236] 85. A validating network node in a process plant on a distributed ledger network, the validating network node comprising: a transceiver configured to communicate with one or more field devices, each field device performing a physical function to control an industrial process in the process plant and exchanging distributed ledger data with peer network nodes, the distributed ledger data including transactions with event data from trigger events; a storage medium configured to store a copy of the distributed ledger; and a process data verifier configured to apply a set of consensus rules to the distributed ledger data received from the peer network nodes, wherein the process data verifier is further configured to append the distributed ledger data received from the peer network nodes to the copy of the distributed ledger if the distributed ledger data satisfies the consensus rules.

[0237] 86. The validation network node of aspect 85, wherein the event data includes at least one of a time of the trigger event, a duration of the trigger event, product parameter data associated with the trigger event, or process parameter data associated with the trigger event.

[0238] 87. The validation network node of any one of aspects 85 or 86, wherein the trigger event is at least one of an alarm, an error, a leak, a repair event, or a corrective action.

[0239] 88. The validation network node of any one of aspects 85-87, wherein the distributed ledger data received from the peer node includes identity proof of one of the one or more field devices generating the transaction with the event data.

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

[0241] 90. The validating network node of any one of aspects 85-89, wherein the set of consensus rules includes at least one of: formatting requirements for a transaction or block of transactions; a mechanism for determining which of the peer network nodes will add the next transaction or block of transactions to the distributed ledger; or a cryptographic hashing algorithm for hashing process plant data included in each of the transactions.

[0242] 91. The validation network node of any one of aspects 85-90, wherein the distributed ledger is a private blockchain accessible by the process plant and regulatory authorities.

[0243] 92. The validation network node of any one of aspects 85-91, wherein the distributed ledger is a public blockchain.

[0244] 93. The validation network node of any one of aspects 85-92, wherein the transaction further includes a unique identifier of the trigger event.

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

[0246] 95. The method of aspect 94, wherein a current state of software or firmware executing within the process plant is obtained from a user's computing device that updated the current state, and generating the transaction further includes obtaining user identity data, augmenting the transaction with the user identity data in one or more processors, generating a cryptographic signature based on the transaction in one or more processors, and augmenting the transaction with the cryptographic signature in one or more processors.

[0247] 96. The method of any one of aspect 94 or aspect 95, wherein generating a transaction including a current state of software or firmware executing within the process plant includes generating a transaction including a cryptographic hash value corresponding to the current state of software or firmware executing within the process plant.

[0248] 97. The method of any one of aspects 94-96, further comprising: obtaining a state of the software or firmware running within 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 running within the process plant with a cryptographic hash value from the distributed ledger to verify that the software or firmware has not been tampered with.

[0249] 98. The method of any one of aspects 94-97, further comprising: preventing the software or firmware from executing within the process plant in response to determining that a state of the software or firmware executed within the process plant does not match a current state of the software or firmware stored in the distributed ledger according to a cryptographic hash value.

[0250] 99. The method of any one of aspects 94-98, further comprising reverting the software or firmware to a previous state.

[0251] 100. The method of any one of aspects 94-99, further comprising: causing a network or process control device to execute the software or firmware in response to determining that a state of the software or firmware executed within the process plant matches a current state of the software or firmware stored in the distributed ledger according to a cryptographic hash value.

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

[0253] 102. The method of any one of aspects 94-101, further comprising: comparing identity data in the transaction to a plurality of sets of identity data corresponding to users authorized to update the state of software or firmware executed within the process plant; and adding the transaction to a block of transactions if the identity data is included within the plurality of sets of identity data.

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

[0255] 104. A system for recording the state of software or firmware in a process control system and connected instrumentation using a distributed ledger maintained by multiple participants, the system including: one or more devices disposed within a process plant, each performing a physical function to control an industrial process; and a computing device executing within the process plant, the computing device including 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 having instructions stored thereon, the instructions, when executed by the one or more processors, causing the computing device to obtain a current state of the software or firmware executing within the process plant; the software or firmware executing within at least one of the one or more devices disposed within the process plant or a network device within the process plant, generate a transaction including the current state of the software or firmware executing within the process plant, store the transaction in the distributed ledger, and transmit the transaction to at least one other participant in a distributed ledger network of the participant maintaining the distributed ledger for verification and recording of the transaction in the distributed ledger.

[0256] 105. The system of aspect 104, wherein a current state of software or firmware executing within the process plant is obtained from a user's computing device that updated the current state, and to generate a transaction, the instructions cause the computing device to obtain identity data of the user, augment the transaction with the user's identity data, generate a cryptographic signature based on the transaction, and augment the transaction with the cryptographic signature.

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

[0258] 107. The system of any one of aspects 104-106, further including a server device including 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 having instructions stored thereon, the instructions, when executed by the one or more processors, causing the server device to obtain a state of software or firmware executing 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 executing in the process plant with a cryptographic hash value from the distributed ledger to verify that the software or firmware has not been tampered with.

[0259] 108. The system of any one of aspects 104-107, wherein the instructions are further to the server device to prevent the software or firmware from executing within the process plant in response to determining that a state of the software or firmware executing within the process plant does not match a current state of the software or firmware stored in the distributed ledger according to a cryptographic hash value.

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

[0261] 110. The system of any one of aspects 104-109, wherein the instructions cause the server device and further cause a network or process control device to execute the software or firmware in response to determining that a state of the software or firmware executing within the process plant matches a current state of the software or firmware stored in the distributed ledger according to a cryptographic hash value.

[0262] 111. The system of any one of aspects 104-110, wherein the instructions further cause the computing device to add the transaction to a block of transactions, solve a cryptographic puzzle based on the block of transactions, add the solution to the cryptographic puzzle to the block of transactions, and transmit the block of transactions to at least one other participant in the distributed ledger network.

[0263] 112. The system of any one of aspects 104-111, wherein the instructions further cause the computing device to compare identity data in the transaction with a plurality of sets of identity data corresponding to users authorized to update the state of software or firmware executed within the process plant, and add the transaction to a block of transactions if the identity data is included within the plurality of sets of identity data.

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

[0265] 114. A validating network node in a process plant on a distributed ledger network, the validating network node including: a transceiver configured to communicate with one or more field devices, each field device performing a physical function to control an industrial process within the process plant, and to exchange distributed ledger data with peer network nodes, the distributed ledger data including transactions having data representing a current state of software or firmware within the process plant; a storage medium configured to store a copy of the distributed ledger; and a process data verifier configured to apply a set of consensus rules to the distributed ledger data received from the peer network nodes, wherein the process data verifier is further configured to append the distributed ledger data received from the peer network nodes to the copy of the distributed ledger if the distributed ledger data satisfies the consensus rules.

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

[0267] 116. The validating network node of any one of aspect 114 or aspect 115, wherein the set of consensus rules includes at least one of: formatting requirements for a transaction or block of transactions; a mechanism for determining which of the peer network nodes will add the next transaction or block of transactions to the distributed ledger; or a cryptographic hashing algorithm for hashing software or firmware state included in each of the transactions.

[0268] 117. The validating network node of any one of aspects 114-116, wherein the distributed ledger data received from the peer node includes identity proof of a user of a device generating a transaction having data representing a current state of software or firmware executing within the process plant.

[0269] 118. A method for creating smart contracts 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 performing a physical function to control an industrial process; and deploying, by the one or more processors, the smart contract to an address stored in the distributed ledger maintained by the multiple participants to the distributed ledger network.

[0270] 119. The method of aspect 118, wherein the smart contract receives or provides token values ​​according to events occurring within the process plant.

[0271] 120. The method of any one of aspect 118 or aspect 119, wherein generating a smart contract associated with the process plant includes generating a smart contract that obtains a token value from a first process plant, determines that product has been transferred from a second process plant to the first process plant, and provides the token value to the second process plant.

[0272] 121. The method of any one of aspects 118-120, wherein the smart contract determines that the product has been transferred from the second process plant to the first process plant by receiving a transaction from the evidence oracle indicating that the product has been received at the first process plant.

[0273] 122. The method of any one of aspects 118-121, wherein generating the smart contract associated with the process plant further includes generating a smart contract that 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.

[0274] 123. The method of any one of aspects 118-122, wherein the smart contract receives one or more transactions from the evidence oracle, each transaction including a product parameter value or a process parameter value, and determines that the product meets or exceeds one or more quality metrics by comparing the product parameter value or the process parameter value to product or process parameter thresholds included in the one or more quality metrics.

[0275] 124. The method of any one of aspects 118-123, wherein generating a smart contract related to the process plant includes generating a smart contract that obtains device information for a device in the process plant that experiences a failure, and provides the device information to a device supplier in response to receiving a request to share the device information.

[0276] 125. The method of any one of aspects 118-124, wherein the smart contract obtains the device information by receiving a transaction from a proof oracle that includes the device information.

[0277] 126. The method of any one of aspects 118-125, wherein the smart contract receives a request to share device information by receiving a transaction including the request along with identity data of a user issuing the request, and the smart contract compares the identity data in the transaction to multiple sets of identity data corresponding to users authorized by the distributed ledger network to request that the device information be shared, and provides the device information to the device supplier if the identity data is included within the multiple sets of identity data.

[0278] 127. The method of any one of aspects 118-126, wherein generating the smart contract associated with the process plant includes generating a smart contract that receives parameters associated with a safety instrumented system (SIS) device and writes the parameters to the SIS device in response to determining that the operator who provided the parameters is an authorized operator.

[0279] 128. The method of any one of aspects 118-127, wherein the smart contract receives the parameters associated with the SIS device by receiving a transaction including the parameters along with identity data of an operator who provided the transaction, and determining that the operator who provided the parameters is an authorized operator includes comparing the identity data in the transaction with a plurality of sets of identity data corresponding to operators authorized to adjust the parameters associated with the SIS device.

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

[0281] 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 in a process plant having one or more field devices each performing a physical function to control an industrial process; generating, by a computing device, a transaction including the event data in response to deploying the smart contract to an address stored in the distributed ledger; and sending the transaction to a smart contract stored in the distributed ledger maintained by the multiple participants to the distributed ledger network.

[0282] 131. The method of aspect 130, further comprising: obtaining identity data of the computing device; augmenting, in one or more processors, the transaction with the identity data of the computing device; generating, in one or more processors, a cryptographic signature based on the transaction; and augmenting, in one or more processors, the transaction with the cryptographic signature.

[0283] 132. The method of any one of aspect 130 or aspect 131, further comprising: adding the transaction to a block of transactions; solving a cryptographic puzzle based on the block of transactions; adding the solution to the cryptographic puzzle to the block of transactions; and transmitting the block of transactions to at least one other participant in the distributed ledger network.

[0284] 133. The method of any one of aspects 130-132, wherein the smart contract obtaining a token value from a first process plant, determining that a product has been transferred from a second process plant to the first process plant, providing the token value to the second process plant, and obtaining event data from an event occurring within the process plant includes obtaining an indication that the product has been received at the first process plant, and generating a transaction including an identification of the first process plant, an identification of the product, and an indication that the product has been received at the first process plant from the second process plant.

[0285] 134. The method of any one of aspects 130-133, wherein obtaining an indication that the product has been received at the first process plant further includes obtaining one or more product parameter values ​​of the product or one or more process parameter values ​​of process plant entities involved in producing the product, and generating a transaction including the one or more product parameter values ​​or the one or more process parameter values.

[0286] 135. The method of any one of aspects 130-134, wherein the smart contract obtains device information for a device in the process plant where a failure occurs, and provides the device information to a device supplier in response to receiving a request to share the device information, and obtaining event data from an event occurring in the process plant includes obtaining the device information for the device and generating a transaction including identification information and the device information for the device.

[0287] 136. The method of any one of aspects 130-135, wherein the smart contract, in response to receiving parameters associated with a safety instrumented system (SIS) device and determining that the operator who provided the parameters is an authorized operator, writes the parameters to the SIS device, and obtaining event data from an event occurring within the process plant includes obtaining a request to change the parameters associated with the SIS device, and generating a transaction including identification information of the SIS device, the changed parameters, and new parameter values ​​for the changed parameters.

[0288] 137. A computing device for creating smart contracts in a process control system using a distributed ledger maintained by multiple participants, 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 having instructions stored thereon, the instructions, when executed by the one or more processors, causing the computing device to generate a smart contract associated with a process plant having one or more field devices, each performing a physical function to control an industrial process, and deploy the smart contract to an address stored in the distributed ledger maintained by the multiple participants to the distributed ledger network.

[0289] 138. The computing device of aspect 137, wherein the smart contract receives or provides a token value according to an event occurring within the process plant.

[0290] 139. The computing device of 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 has been transferred from a second process plant to the first process plant, and provides the token value to the second process plant.

[0291] 140. The computing device of any one of aspects 137-139, wherein the smart contract determines that the product has been transferred from the second process plant to the first process plant by receiving a transaction from the evidence oracle representing that the product has been received at the first process plant.

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

[0293] 142. The computing device of any one of aspects 137-141, wherein the smart contract receives one or more transactions from the evidence oracle, each transaction including a product parameter value or a process parameter value, and determines that the product meets or exceeds one or more quality metrics by comparing the product parameter value or the process parameter value to product or process parameter thresholds included in the one or more quality metrics.

[0294] 143. The computing device of any one of aspects 137-142, wherein the smart contract obtains device information for a device in the process plant where a failure occurs and provides the device information to a device supplier in response to receiving a request to share the device information.

[0295] 144. The computing device of any one of aspects 137-143, wherein the smart contract obtains the device information by receiving a transaction from a proof oracle that includes the device information.

[0296] 145. The computing device of any one of aspects 137-144, wherein the smart contract receives a request to share device information by receiving a transaction including the request along with identity data of a user issuing the request, and the smart contract compares the identity data in the transaction to multiple sets of identity data corresponding to users authorized by the distributed ledger network to request that the device information be shared, and provides the device information to the device supplier if the identity data is included within the multiple sets of identity data.

[0297] 146. The computing device of any one of aspects 137-145, wherein the smart contract receives parameters associated with a safety instrumented system (SIS) device and, in response to determining that the operator who provided the parameters is an authorized operator, writes the parameters to the SIS device.

[0298] 147. The computing device of any one of aspects 137-146, wherein the smart contract receives the parameters associated with the SIS device by receiving a transaction including the parameters along with identity data of an operator who provided the transaction, and determining that the operator who provided the parameters is an authorized operator includes comparing the identity data in the transaction with multiple sets of identity data corresponding to operators authorized to adjust the parameters associated with the SIS device.

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

[0300] 149. A system for interacting with smart contracts in a process control system using a distributed ledger maintained by multiple participants, the system including one or more devices disposed within a process plant, each performing a physical function to control an industrial process, wherein a computing device executing within the process plant includes 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 having instructions stored thereon, the instructions, when executed by the one or more processors, cause the computing device to obtain, via the one or more devices, event data from events occurring within the process plant, generate transactions including the event data in response to deploying a smart contract to an address stored in the distributed ledger, and send the transactions to the smart contract stored in the distributed ledger maintained by the multiple participants to the distributed ledger network.

[0301] 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 with the identity data of the computing device, generate a cryptographic signature based on the transaction, and augment the transaction with the cryptographic signature.

[0302] 151. The system of any one of aspect 149 or aspect 150, wherein the instructions further cause the computing device to add the transaction to a block of transactions, solve a cryptographic puzzle based on the block of transactions, add the solution to the cryptographic puzzle to the block of transactions, and transmit the block of transactions to at least one other participant in the distributed ledger network.

[0303] 152. The system of any one of aspects 149-151, wherein the smart contract obtains a token value from the first process plant, determines that a product has been transferred from a second process plant to the first process plant, provides the token value to the second process plant, and obtains event data from an event occurring within the process plant, and the instructions cause the computing device to obtain an indication that the product has been received at the first process plant and generate a transaction including an identification of the first process plant, an identification of the product, and an indication that the product has been received at the first process plant from the second process plant.

[0304] 153. The system of any one of aspects 149-152, wherein the instructions cause a computing device to obtain one or more product parameter values ​​of the product or one or more product parameter values ​​of process plant entities involved in producing the product, and generate a transaction including the one or more product parameter values ​​or one or more process parameter values, to obtain an indication that the product has been received at the first process plant.

[0305] 154. The system of any one of aspects 149-153, wherein the smart contract obtains device information for a device in the process plant where a failure occurs, provides the device information to a device supplier in response to receiving a request to share the device information, and, to obtain event data from an event occurring in the process plant, the instructions cause the computing device to obtain device information for the device and generate a transaction including identification information and device information of the device.

[0306] 155. The system of any one of aspects 149-154, wherein the smart contract receives parameters associated with a safety instrumented system (SIS) device, and, in response to determining that the operator who provided the parameters is an authorized operator, writes the parameters to the SIS device and retrieves event data from an event occurring within the process plant, the instructions cause the computing device to obtain a request to modify the parameters associated with the SIS device and generate a transaction including an identification of the SIS device, the modified parameters, and new parameter values ​​for the modified parameters.

[0307] When implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-transitory computer-readable memory, such as a magnetic disk, laser disk, solid-state memory device, molecular memory storage device, or other storage medium, such as in RAM or ROM of a computer or processor. Note that while the exemplary systems disclosed herein are disclosed as including, among other components, software and / or firmware running on hardware, such systems are merely exemplary and should not be considered limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components may be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, while the exemplary systems described herein are described as implemented in software running on processors of one or more computing devices, those skilled in the art will readily understand that the provided examples are not the only way to implement such systems.

[0308] Thus, while the present invention has been described with reference to specific examples, it will be apparent to those skilled in the art that these examples are illustrative only and are not intended to be limitations of the invention, and that modifications, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.

Claims

1. 1. A method for recording regulatory data in a process control system using a distributed ledger maintained by multiple participants, comprising: detecting a trigger 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, the trigger event being at least one of an alarm, an error, a leak, a repair event, a process milestone, or a corrective action; obtaining event data from the trigger event, the event data including at least one of a time of the trigger event, a duration of the trigger event, product parameter data associated with the trigger event, or process parameter data associated with the trigger event; generating a transaction including the event data, the transaction being stored in the distributed ledger; sending the transaction to at least one other participant in a distributed ledger network of participants maintaining the distributed ledger.

2. receiving a request for event data from a particular trigger event; obtaining the event data from the distributed ledger; The method of claim 1 , further comprising: displaying the event data from the particular trigger event in a user interface.

3. The method of claim 1 or claim 2, wherein generating a transaction including the event data includes generating the transaction including a cryptographic hash value corresponding to at least some of the event data.

4. storing the event data in a database; 4. The method of claim 3, further comprising: in response to a request to authenticate the event data, providing the cryptographic hash value corresponding to at least a portion of the event data from the distributed ledger along with the event data from the database to confirm authenticity of the event data.

5. the trigger event is the opening of a relief valve, and the event data from the trigger event is: The time the relief valve is open, the duration the relief valve is open; the pressure value when the relief valve is opened, or The method of claim 1 , wherein the amount of liquid removed while the relief valve is open is at least one of:

6. 6. The method of claim 1, wherein the distributed ledger is a private blockchain accessible by the process plant and a regulatory authority.

7. 7. The method of claim 1, wherein the distributed ledger is a public blockchain.

8. The method of claim 1 , wherein the transaction further includes a unique identifier of the triggering event.

9. 10. The method of claim 8, further comprising transmitting an indication of the detected trigger event, including the unique identifier of the trigger event, to one or more other process control elements within the process plant for the other process control elements to generate a transaction including additional event data related to the trigger event.

10. 1. A system for recording regulatory data in a process control system using a distributed ledger maintained by multiple participants, comprising: one or more devices disposed in the process plant, each performing a physical function to control an industrial process; a computing device executing within the process plant, one or more processors; A communication unit; a non-transitory computer-readable medium coupled to the one or more processors and the communication unit and having instructions stored thereon, wherein the instructions, when executed by the one or more processors, cause the computing device to: detecting, via one or more devices, a trigger event related to quality control within the process plant, the trigger event being at least one of an alarm, an error, a leak, a repair event, a process milestone, or a corrective action; obtaining event data from the trigger event, the event data including at least one of a time of the trigger event, a duration of the trigger event, product parameter data associated with the trigger event, or process parameter data associated with the trigger event; generating a transaction that includes the event data, the transaction being stored in the distributed ledger; transmitting the transaction to at least one other participant in a distributed ledger network of participants maintaining the distributed ledger for verification and recording of the transaction in the distributed ledger.

11. The instructions to the computing device further include: Receive a request for event data from a specific trigger event; Retrieving the event data from the distributed ledger; The system of claim 10 , further comprising: causing a user interface to display the event data from the particular trigger event.

12. The system of claim 10 or claim 11, wherein the transaction includes a cryptographic hash value corresponding to at least a portion of the event data.

13. The instructions to the computing device further include: storing the event data in a database; 13. The system of claim 12, wherein in response to a request to authenticate the event data, a cryptographic hash value corresponding to at least a portion of the event data from the distributed ledger along with the event data from the database is provided to verify authenticity of the event data.

14. the trigger event is the opening of a relief valve, and the event data from the trigger event is: The time the relief valve is open, the duration the relief valve is open; the pressure value when the relief valve is opened, or 14. The system of claim 10, further comprising at least one of: an amount of liquid removed while the relief valve is open.

15. 15. The system of claim 10, wherein the distributed ledger is a private blockchain accessible by the process plant and a regulatory authority.

16. 16. The system of claim 10, wherein the distributed ledger is a public blockchain.

17. The system of claim 10 , wherein the transaction further includes a unique identifier of the triggering event.

18. The instructions to the computing device further include:

20. The system of claim 17, further comprising: causing an indication of the detected trigger event, including the unique identifier of the trigger event, to be transmitted to the one or more devices within the process plant for the one or more devices to generate a transaction including additional event data related to the trigger event.

Images