Industrial equipment uniquely identifying controller peripheral network

Abstract

Uniquely identified industrial equipment (1300) of a controller peripheral network (200) is provided. The uniquely identified industrial equipment (1300) comprises: an electronic device (1320), the electronic device (1320) comprising: a processor (1321) configured to communicate with the controller peripheral network (200); and a memory (1322) communicatively coupled to the processor (1321). The memory (1322) is defined by the controller peripheral network (200) and is configured to store a unique identification obtained from a decentralized network (410) external to the controller peripheral network (200).

Description

Technical Field

[0001] The embodiments described below relate to industrial equipment of a controller peripheral network, and more particularly to industrial equipment that uniquely identifies a controller peripheral network. Background Art

[0002] Industrial equipment is often calibrated and maintained by various services. Therefore, the calibration and maintenance records of a particular industrial equipment may or may not be available to other organizations. For example, the manufacturer of the industrial equipment may calibrate the industrial equipment and make the calibration records available to the purchaser of the industrial equipment. Due to the contractual relationship with the manufacturer, the purchaser may be able to obtain the records. However, other organizations, such as government organizations, may need to rely on customers who act as intermediaries to provide records. In order to obtain such records, customers can refer to the serial number of the manufacturer of the industrial equipment. The serial number can be assigned to the industrial equipment by the manufacturer before the industrial equipment is shipped to the customer.

[0003] In addition, industrial equipment may be used to transfer materials as part of a transaction. For example, a Coriolis meter may be used to transfer hydrocarbons or petroleum liquids from a vessel to an onshore storage tank. The transfer of hydrocarbons may involve the transfer of large quantities of hydrocarbons, and therefore may involve significant monetary interests of stakeholders in the transaction. Therefore, stakeholders have a strong incentive to ensure that the total measured quality value of the custody transfer is correct. Ensuring that the total measured quality value is correct requires that the records associated with the custody transfer are reliable.

[0004] For example, parties to a custody transfer (e.g., buyer, seller, terminal, shipping company, etc.) and third parties (e.g., a taxing government) may wish to accurately record transaction details in a manner that cannot be subsequently altered and is usable without permission from either party. As an illustration, a transferee may wish to convey reliable information about hydrocarbons to customers based on a recent custody transfer rather than, for example, sampling the hydrocarbons. Additionally or alternatively, parties to a custody transfer may wish to verify the calibration of an instrument performing such measurements to ensure that the correct amount of mass is measured.

[0005] The industrial equipment may be a peripheral device of a controller peripheral device network. Therefore, the industrial equipment may include a network address. In addition, as discussed above, the industrial equipment may include a manufacturer's serial number. However, the network address and the manufacturer's serial number are not unique, because the information provided by the industrial equipment can be reliably associated with the industrial equipment. In addition, the network address and the manufacturer's serial number are static, because the industrial equipment may not have more than two addresses or two serial numbers. Therefore, it is necessary to uniquely identify the peripheral devices of the controller peripheral device network. Summary of the invention

[0006] A uniquely identified industrial equipment of a controller peripheral network is provided, including an electronic device. According to an embodiment, the uniquely identified industrial equipment includes: a processor, the processor is configured to communicate with the controller peripheral network; and a memory, the memory is communicatively coupled to the processor, the memory is defined by the controller peripheral network and is configured to store a unique identification obtained from a decentralized network outside the controller peripheral network.

[0007] A method for uniquely identifying industrial equipment of a controller peripheral network is provided. According to an embodiment, the method includes obtaining a unique identification from a decentralized network with the industrial equipment and storing the unique identification in a memory of the industrial equipment, the memory being defined by the controller peripheral network.

[0008] aspect

[0009] According to one aspect, uniquely identified industrial equipment of a controller peripheral network includes: an electronic device, the electronic device including: a processor, the processor is configured to communicate with the controller peripheral network; and a memory, the memory is communicatively coupled to the processor, the memory is defined by the controller peripheral network and is configured to store a unique identification obtained from a decentralized network outside the controller peripheral network.

[0010] Preferably, the memory defined by the controller peripheral network comprises registers mapped according to a protocol of the controller peripheral network.

[0011] Preferably, the unique identification is stored in at least one of the registers.

[0012] Preferably, the unique identification comprises one of a public key and a token identifier of the uniquely identified industrial equipment.

[0013] Preferably, the memory is further configured to store a private key paired with the unique identifier.

[0014] Preferably, the uniquely identified industrial equipment further comprises a communication port, the communication port being communicatively coupled to the processor, the communication port being configured to communicate with the controller peripheral network.

[0015] A method for uniquely identifying industrial equipment of a controller peripheral network, the method comprising: obtaining a unique identifier from a decentralized network using the industrial equipment, and storing the unique identifier in a memory of the industrial equipment, the memory being defined by the controller peripheral network.

[0016] Preferably, the memory defined by the controller peripheral network comprises registers mapped according to a protocol of the controller peripheral network.

[0017] Preferably, the unique identification is stored in at least one of the registers.

[0018] Preferably, the unique identification comprises one of a public key and a token identifier of the uniquely identified industrial equipment.

[0019] Preferably, the memory is further configured to store a private key paired with the unique identifier.

[0020] Preferably, obtaining the unique identifier from the decentralized network using the industrial equipment includes: obtaining the unique identifier from the decentralized network using a communication port that is communicatively coupled to the controller peripheral device network. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Like reference numerals represent like elements throughout the drawings. It should be understood that the drawings are not necessarily drawn to scale.

[0022] Figure 1 A front perspective view of an industrial equipment 5 is shown which is configured as a uniquely identified peripheral device of a controller peripheral device network.

[0023] Figure 2 An exemplary controller peripheral network 200 is shown.

[0024] Figure 3A and Figure 3B A single register format for uniquely identifying industrial equipment in a controller peripheral network is shown ( Figure 3A ) and multi-register form ( Figure 3B )'s memory 300.

[0025] Figure 4 A system 400 for uniquely identifying industrial equipment on a controller peripheral network is shown.

[0026] Figure 5 and Figure 6 An unpartitioned unique identification register 500 and a partitioned unique identification register 600 are shown.

[0027] FIG. 7 shows a typical measurement system 700 .

[0028] Figure 8 A block diagram of a decentralized network measurement system 800 for uniquely identifying industrial equipment is shown, with the decentralized network measurement system 800 being shown as a measurement device 805 .

[0029] Fig. 9 A detailed view of a decentralized network data gateway 810 for uniquely identifying industrial equipment of a controller peripheral network is shown.

[0030] Fig.10A flow chart view of a decentralized network measurement system 800 including uniquely identified industrial equipment is shown.

[0031] Fig.11 A data flow 1100 of a calibration report according to a detailed view of the cloud decentralized network 820 is shown.

[0032] Fig.12 A method 1200 for uniquely identifying industrial equipment of a controller peripheral network is shown.

[0033] Fig.13 Uniquely identified industrial equipment 1300 is shown. DETAILED DESCRIPTION

[0034] Figures 1 to 13 The following description depicts specific examples to teach those skilled in the art how to develop and use the best mode of implementation of industrial equipment for uniquely identifying a network of controller peripherals. For the purpose of teaching the principles of the invention, some conventional aspects have been simplified or omitted. Those skilled in the art will understand that variations from these examples fall within the scope of this specification. Those skilled in the art will understand that the features described below can be combined in various ways to form multiple variations of industrial equipment that uniquely identifies a network of controller peripherals. Therefore, the embodiments described below are not limited to the specific examples described below, but are limited only by the claims and their equivalents.

[0035] Controller Peripheral Network

[0036] Figure 1 A front perspective view of an industrial device 5 configured as a unique identifier for a controller peripheral network is shown. In the illustrated embodiment, the industrial device 5 is a meter that measures a property of a material flowing through the meter. More specifically, the industrial device 5 is shown as a Coriolis flow meter. Thus, Figure 1 The instrument shown is configured to measure the density and mass flow of the fluid. However, any suitable industrial equipment may be used. In the embodiment shown, the material may flow through the industrial equipment 5 via the inlet 5a and the outlet 5b. In alternative embodiments, other types of equipment such as tuning fork density meters, flow control valves and systems, pressure sensors, temperature sensors, etc. may be coupled to the industrial equipment 5.

[0037] The interface 20 may also be communicatively coupled to the industrial equipment 5. That is, the interface 20 may send signals and / or receive signals from the industrial equipment 5. The signals may include, for example, measurements representing properties of materials flowing through the industrial equipment 5. Additionally or alternatively, the signals may include, for example, drive signals, flow control signals (where the industrial equipment 5 includes a flow control device, etc.), or other signals sent to the industrial equipment 5. The signals may be electrical, optical, or any other suitable form that may be sent via conductors, wireless communication links, etc.

[0038] like Figure 1 As shown, the industrial equipment 5 includes an interface 20 that is communicatively coupled to the sensor assembly 10. The interface 20 can send signals and / or receive signals from the sensor assembly 10. The signal may include, for example, a measurement value representing a property of a material flowing through the industrial equipment 5. Additionally or alternatively, the signal may include, for example, a drive signal, a flow control signal (in the case where the industrial equipment 5 includes a flow control device, etc.), or other signals sent to the sensor assembly 10. The signal may be electrical, optical, or any other suitable form that can be sent via a conductor, a wireless communication link, etc.

[0039] In the illustrated embodiment, the interface 20 is proximate to the sensor assembly 10. In alternative embodiments, the interface 20 may be at a location not proximate to the sensor assembly 10. For example, the interface 20 may be in a control room remote from the sensor assembly 10, wherein the interface 20 is beneficially shielded from a hazardous or harmful environment. In addition, the interface 20 may be remotely accessible, which may be beneficial to a user, for example, for comparing data obtained from different measurement devices dispersed over a large area. Thus, the industrial equipment 5 may be as will be described below with reference to Figure 2 The controller peripheral network portion is discussed in more detail.

[0040] Controller Peripheral Network

[0041] Figure 2 An exemplary controller peripheral network 200 is shown. Figure 2 As shown, the controller peripheral device network 200 includes a controller 210 and a plurality of industrial equipment 220. Figure 2 As shown, the plurality of industrial equipment 220 includes reference Figure 1 Although not shown, reference Figure 1 The sensor assembly 10 is depicted as being coupled to each of a plurality of industrial equipment 220. Figure 2 As shown, the plurality of industrial equipment 220 includes first to third peripheral devices 220 a to 220 c .

[0042] The controller peripheral network 200 may be referred to as a master-slave network and operates as a master-slave network. More specifically, the controller 210 of the controller peripheral network 200 may use the controller peripheral network protocol to send commands or requests to specific peripherals on the controller peripheral network 200, such as the first peripheral 220a. Multiple industrial equipment 220 may not be able to initiate commands or requests on the controller peripheral network 200. If a command or request is sent to a specific peripheral of the multiple industrial equipment 220, the specific peripheral may only respond to the command or request from the controller 210. The controller and peripherals of the controller peripheral network may generally be referred to as devices of the controller peripheral network.

[0043] The controller peripheral network 200 may be a Modbus remote terminal unit ("RTU") network, but any suitable controller peripheral network may be used. In a Modbus RTU network, the controller 210 may be a master device that polls a plurality of industrial equipment 220, which may be one or more devices configured as slaves on the Modbus RTU network. That is, the controller 210 may send a request over the Modbus RTU network for data from a particular peripheral device of the plurality of industrial equipment 220 on the Modbus RTU network. As discussed above, a slave device cannot provide data to the Modus RTU network without a request from the master device.

[0044] Referring to the controller peripheral device network 200 under Modbus RTU conditions, data can be transmitted one bit at a time in 8-bit bytes through the Modbus RTU network using serial transmission. Each slave device in the Modbus RTU network can have a unique 8-bit address. The 8-bit address can be referred to as a unit number, but any suitable terminology can also be used. The packet sent by the master device includes the address or unit number of the slave device. The packet may include a message intended for the addressed slave device. If the slave device recognizes the address or unit number, the slave device may need to respond within a certain time frame, otherwise the master device will determine that a "no response" error has occurred. When the slave device responds to a request from the master device, data exchange occurs.

[0045] More specifically, in Modbus RTU, each data exchange can be defined as a request from a master device to an addressed slave device and a corresponding response from the addressed slave device. Requests and responses can be sent as packets. Each packet can be considered to have a predefined structure. In Modbus RTU, a packet can include a device address, a function code, a register number, a register count, data, and a checksum field. Other formats can be used in other controller peripheral networks. The data in the packet can be written and read at the register of the device. The protocol of the controller peripheral network can be used to define how the register is read and / or written. The register can be a 16-bit data slice. For example, the register can be a signed or unsigned 16-bit integer. Therefore, for example, a 32-bit integer value is required, and a pair of 16-bit wide registers can be read. Using Modbus as an exemplary controller peripheral network, the memory structure of the Modbus register is described in more detail below.

[0046] Figure 3A and Figure 3B A single register format is shown for uniquely identifying industrial equipment in a controller peripheral network ( Figure 3A ) and multiple register forms ( Figure 3B ) of the memory 300. Figure 3A As shown, the memory 300 is shown in the form of a single register, wherein the single register includes a coil 310, a discrete input 320, an input register 330, and a holding register 340. Therefore, Figure 3A The structure of the registers in the memory 300 is shown. Figure 3B 300 shows how the structure of the registers can be filled with data. That is, each of the multiple registers in the memory 300 has Figure 3A The structure shown in . A plurality of registers are identified by register numbers 302, such as Figure 3B As shown. Figure 3B Also shown are coils 310, discrete inputs 320, input registers 330, and holding registers 340.

[0047] Coil 310 may be a single-bit register that may have a value of "0" or "1". Coil 310 may be a read-write register. That is, the master device may write data to or read data from coil 310 in memory 300. Coil 310 may be preferred in situations where a single-bit binary value may be sufficient. For example, the master device may write a value of "1" to coil 310 to turn on a subcomponent of the device, and write a value of "0" to turn off the subcomponent. In an alternative memory, the coil may not be used in situations where a single-bit binary value is not useful in a particular device.

[0048] Similar to coil 310, discrete input 320 can also be a single-bit binary value of "0" or "1". However, discrete input 320 can only be read. That is, the master device can only read values ​​from discrete input 320, but cannot write values. Therefore, if the discrete input 320 value is "1", the device can set the power state of the subcomponent discussed above to "on", and if the discrete input 320 value is "0", the power state is set to "off". As an illustration, the master device can send a request with a function code to write a value of "1" to coil 310 to control whether the subcomponent in the device is turned on, and send a subsequent request to read the discrete input 320 associated with the power state of the subcomponent to determine whether the subcomponent is powered on.

[0049] Input register 330 and holding register 340 can exceed single bit length.For example, input register 330 and holding register 340 can be 16-bit long words.Input register 330 can be similar to discrete input 320 because they can be read-only.That is, the master device can read values ​​from input register 330, but cannot write values ​​to input register 330. Holding register 340 can be read and written by the master device similarly to coil 310.As discussed, the package sent by the master device can include function code.Function code indicates whether coil 310 or holding register 340 is read or written data, or whether discrete input 320 or input register 330 is written.

[0050] Specifically, the Modbus function code may determine the access of the Modbus register. Table 1 below shows some exemplary function codes.

[0051] Table 1. Example function codes in Modbus package

[0052] Function code Register Type 1 Reading coil 2 Reading Discrete Inputs 3 Read Holding Registers 4 Read Input Register 5 Writing a single coil 6 Writing to a Single Holding Register 15 Writing multiple coils 16 Writing to Multiple Holding Registers

[0053] It will be appreciated that the function of the register may be to read or write to a coil or holding register or to read from a discrete input or input register. The register may be configured and used as required by a particular application, for example, to uniquely identify industrial equipment such as the industrial equipment 220 discussed above on a controller peripheral network.

[0054] In order to ensure that the unique identification of a measurement device of a controller peripheral network correctly identifies the measurement device, it may be necessary to compare the unique identification with a record external to the controller peripheral network. Such a record may be maintained by the manufacturer of the measurement device or a third-party record keeping service. However, relying on such a record may require trust. A decentralized network may provide records in a manner that does not require trust. An exemplary decentralized network is described in more detail below.

[0055] Decentralized Network

[0056] Figure 4 A system 400 for uniquely identifying industrial equipment on a controller peripheral network is shown. Figure 4 As shown, the system 400 includes a decentralized network 410 and the controller peripheral device network 200 described above. The decentralized network 410 is shown to include a plurality of nodes 412. Although seven nodes 412 are depicted, only two of the nodes 412 are indicated by reference numerals for clarity. The decentralized network 410 also includes a blockchain 414. The blockchain 414 includes a plurality of blocks 414a linked together with hash values. As an illustration, the latest block 414a of the blockchain 414 is shown in more detail. The blockchain 414 is stored, updated, maintained, and protected by the nodes 412.

[0057] The decentralized network 410 can be a network of computing resources represented by nodes 412 that can store data persistently and immutably. For example, the decentralized network can be a blockchain network, where nodes can locate, perform work, etc. to reach a network consensus that data should be recorded in an immutable database. Figure 4 As shown, the decentralized network 410 may be a blockchain network including nodes 412, the network maintaining a blockchain 414 as an immutable database, wherein data in the immutable database is only added through consensus.

[0058] Node 412 can be any suitable device, server, system, computing resource, etc. that can be a node of decentralized network 410. Node 412 is shown as forming a peer-to-peer ring network, but any suitable network topology and protocol can be used. Node 412 can be configured to receive transactions including one or more references to previous transactions recorded to blockchain 414, payments to the recipient address recorded to blockchain 414, and signatures associated with the sender address. The consensus algorithm can authenticate transactions to all nodes 412 by majority. After authenticating the transaction, the transaction can be recorded to the latest block 414a of blockchain 414.

[0059] For such authentication and recording, block 414a is shown as including fields including index 414aa, timestamp 414ab, previous hash 414ac, hash 414ad, and data 414ae. For clarity, the latest block 414a is shown in block format, but any suitable representation may be used. It is understood that all blocks 414a in blockchain 414 may have Figure 4 All fields shown in . Index 414aa, timestamp 414ab, previous hash 414ac, and hash 414ad may be used to authenticate and protect data 414ae, as will be described in more detail below.

[0060] Index 414aa may be a sequence value indicating the sequence order of block 414a in blockchain 414. For example, index 414aa may be equal to Figure 4 414a, but any suitable value may be used. Similarly, timestamp 414ab may be a value indicating the time when block 414a was added to blockchain 414, but any suitable timestamp may be used. The values ​​of index 414aa and timestamp 414ab may be determined by node 412 using an authentication algorithm.

[0061] The previous hash 414ac may be a hash 414ad of a block immediately preceding the latest block 414a. The hash 414ad may be a hash of various values ​​(e.g., an index, data, etc. in the latest block 414a). The hash 414ad of the latest block 414a may be recorded as the previous hash 414ac in the immediately subsequent block 414a. Thus, the blocks 414a of the blockchain 414 may be sequential. The sequential order of the blocks 414a may be verified by determining hash values ​​of other fields of the given block 414a and comparing the determined hash values ​​with the previous hash 414ac of the block 414a immediately following the given block 414a. These and other methods may be used to verify that the values ​​of the fields in the blocks 414a of the blockchain 414 have not been altered, thereby ensuring the integrity of the data 414ae. Thus, the data 414ae may be considered a permanent and unchangeable record.

[0062] As described above, data (e.g., messages, transactions, etc.) can be recorded to blockchain 414. Data can be signed by a private key in a public-private key pair. For example, a one-way algorithm (e.g., an elliptic curve digital signature algorithm) can generate a value using a message and a private key. The value generated by the message and the private key can be a signature. Ownership of a private key can be verified by using the public key of the private key used to sign the message. The message can also be verified using the original message and the public key or an associated address. Thus, for example, the owner of the private key and the message (e.g., proof that the private key was used to sign a transaction) can be verified without revealing the signer's private key or any seed that can be used to generate the private and public key pair.

[0063] A peripheral device, such as one of the industrial equipment 220, can be uniquely identified by employing a public key and a private key pair. More specifically, the public key and the private key are generated when a transaction is initiated, for example, by the manufacturer of the industrial equipment 5. Figure 5 Such a configuration is discussed in more detail.

[0064] Uniquely identified industrial equipment

[0065] Figure 5 and Figure 6The undivided unique identification register 500 and the divided unique identification register 600 are shown. As can be seen, the undivided unique identification register 500 and the divided unique identification register 600 include a readable and writable column, a type column, an address column, and a register description column. Figure 5 As shown, the undivided unique identification register 500 includes a public key register 510 and a private key register 520. Both the public key register 510 and the private key register 520 are readable and writable and are of type "A36". The address of the public key register 510 is 9001, and the address of the private key register 520 is 9019. The description of the public key register 510 is "public key 1", and the description of the private key register 520 is "private key 1".

[0066] Reference Figure 6 , the split unique identification register 600 includes a first public key register 610a and a second public key register 610b. For clarity, the private key row is not shown. Similar to the public key register 510, the first public key register 610a and the second public key register 610b are readable and writable. However, the first public key register 610a and the second public key register 610b are of type A18. That is, the first public key register 610a and the second public key register 610b cannot store as many bits as the public key register 510. Therefore, the public key may not be stored in a single register, but may need to be split into two registers. Therefore, the first public key register 610a and the second public key register 610b are marked as "public key part 1" and "public key part 2" respectively.

[0067] The private key and the public key can be paired. More specifically, the private key is generated by, for example, a manufacturer of a measuring device, and the public key is generated from the private key using a one-way encryption algorithm. The private key can be generated by the manufacturer of the industrial equipment 220. The private key can be generated based on the value in the seed (e.g., a series of random words, numbers, etc.). A one-way encryption algorithm (e.g., elliptic curve multiplication) can generate a public key pair based on the private key. The seed and the private key are kept confidential, while the public key can be shared. The manufacturer can store the private key in an undivided unique identification register 500 and a divided unique identification register 600, and save the seed. The public key can be used to generate a blockchain address so that a transaction including the blockchain address can be recorded in the latest block 414a of the decentralized network 410. The private key can be used to sign any transaction recorded to the decentralized network 410. More specifically, a hash value can be generated as an input to a transaction to show that the industrial equipment 220 has a private key.

[0068] Other unique identifiers can be used. For example, a token identifier can be used. A token identifier can be generated based on a file provided by a manufacturer of, for example, industrial equipment 220. As an illustration, a value from a read-only register of, for example, industrial equipment 220 can be obtained and placed in a file. The file can be hosted on a file server with a link to the file. A file link can be generated based on the content of the file. An example is a content identifier ("CID") generated by a decentralized file hosting service (e.g., Interplanetary File System ("IPFS")) based on the content of the file. The file link can be recorded as metadata in a token generation file (e.g., a JavaScript Object Notation ("JSON") file), which a token generator can use to generate an unalterable token, such as an Ethereum Request for Comment 721 ("ERC721") or an ERC20 compatible token. The token generator can then generate a token identifier for the industrial equipment 220 accordingly. It is understood that the token identifier is unique because it is impossible to generate the same token identifier again. In addition, when a CID is adopted, the file stored at the file link cannot be modified. In contrast to the seed discussed above, the file used to generate the token does not need to be kept confidential.

[0069] Additionally or alternatively, other registers may be used depending on the type of unique identifier used. For example, a register of type A242 in the Modbus protocol may hold any data defined by a plurality of bits. Thus, a register of type A242 may be suitable for storage / use of cryptographic tokens, as well as any other unique identifier that may require such a data type.

[0070] In the above method and other methods, a unique identifier of the industrial equipment 220 can be generated and stored in the decentralized network 410 so that trust is no longer an issue. As an illustration, the signature of a transaction signed by the industrial equipment 220 can be verified as being paired with the public key of the industrial equipment 220. In addition, in another example, where a token identifier is used, the value of an input register in the industrial equipment 220 can be verified to be the same as the value recorded in the file at the file link of the token identifier. Therefore, stakeholders and non-stakeholders can determine that the data recorded to the decentralized network 410 is actually associated with the industrial equipment 220 identified by the unique identifier without incurring risks associated with trust.

[0071] As discussed above, several stakeholders may be involved in the transfer of fluids (e.g., hydrocarbons). Stakeholders may include contracting parties such as buyers, sellers, onshore facilities, transportation, etc., and regulatory agencies such as state or national governments. Trust may be involved when stakeholders share information that can verify that the measurements are correct. Trust may be a critical issue because the technical details involved in ensuring the integrity of the measurement data may be difficult for various reasons. For example, measurement systems including measurement equipment such as fluid metering systems may suffer from various conditions that affect the uncertainty associated with the data presented by these measurement systems, including calibration and maintenance schedules, unstable process conditions, flow restrictions, and human errors, as described in more detail below with reference to FIG. 7.

[0072] Typical measurement system

[0073] FIG7 shows a typical measurement system 700. As shown in FIG7, the measurement system 700 includes a flow meter that is communicatively coupled to a flow computer that is communicatively coupled to a monitoring computer. The monitoring computer is communicatively coupled to a buyer / government computer. The monitoring computer is shown as being configured to transmit measurement reports to the buyer / government computer. Thus, the monitoring computer can provide electronic transmission of measurement data to the buyer / government computer.

[0074] The flow meter, flow computer, and monitoring computer may be owned by the seller of the fluid measured by the flow meter. For example, after the fluid is transferred from the seller to the buyer in trust, the seller may provide a measurement report to the buyer / government computer. The buyer / government computer may be owned by the buyer or government that may have an interest in the transfer of the fluid measured by the flow meter. Thus, the seller, buyer, and / or government may be considered stakeholders in the trust transfer of the fluid and, therefore, stakeholders in accurate measurement data of the fluid transfer.

[0075] The flow meter can be any suitable instrument, such as a volumetric and / or mass flow meter. The flow meter can provide a signal representing the fluid properties of the fluid sensed by the flow meter. The flow meter can provide a raw signal, a fluid property value, such as an uncorrected fluid property value, etc. to the flow computer. The flow computer can receive a signal representing the fluid property measured by the flow meter from the flow meter. The flow computer can calculate the fluid property value based on the received signal. For example, the flow computer can be an exemplary volume conversion device, which is configured to adjust the value from the flow meter according to process conditions (e.g., temperature and pressure) and generate a gross flow, a standard flow, a mass flow, and an energy flow and a total amount of digital. Therefore, although not shown for clarity, the measurement system 700 can also be communicatively coupled with other auxiliary devices, including temperature and / or pressure transmitters / sensors, gas chromatographs and / or density meters.

[0076] The monitoring computer can collate information from the flow computer and other flow computers and generate a measurement report. The measurement report can include information related to the flow meter and other flow meters, measurements obtained from the flow meter, and / or any other suitable values. It will be appreciated that there may be additional electronic systems to analyze and detect faults in the equipment, and that these systems may add a degree of integrity checking to the system.

[0077] To ensure the integrity of the measurement data, manual review of metering systems remains prevalent but suffers from several challenging issues. For example, metering systems are often found in hazardous and challenging environments. In addition to logistical considerations, there are health and safety considerations when sending auditors to the site. In addition, between audits, stakeholders may not trust that the seller is maintaining their portion of the measurement system 700, such as the flow meters, flow computers, and / or monitoring computers. Furthermore, auditors are required to trust that the data recorded for audit purposes is accurate.

[0078] During an audit, it may be necessary to check all equipment, its calibration records, and maintenance records. While electronic records may exist, they may necessarily exist in the seller's portion of the measurement system 700. Again, this may require another stakeholder and / or auditor to trust the seller's maintenance of the electronic records. One possible remedy is for the buyer to duplicate the entire measurement system as a means of independently cross-checking numbers and ensuring data integrity. Obviously, this requires a huge expense, both in terms of capital expenditures and ongoing operating costs, and it is difficult to resolve disputes if no obvious source of error is detected.

[0079] As discussed above, trust issues and the costs associated with replicating the entire measurement system 700 can be addressed by using a decentralized network (e.g., see Figure 4 The decentralized network 410 described above can be used to avoid this. That is, the decentralized network can replace the audit trail and ensure data reliability. However, the premise is that the data provided by the seller is correct. Therefore, the gateway of the decentralized network can ensure that the data recorded to the decentralized network can be correct.

[0080] Decentralized network gateway

[0081] Figure 8 8 is a block diagram of a decentralized network measurement system 800 for uniquely identifying industrial equipment, which is shown as a measurement device 805. Figure 8As shown, the decentralized network measurement system 800 includes a flow measurement site 801, which is communicatively coupled to a cloud service 802 via a secure data transmission 801a. The flow measurement site 801 includes a measurement device 805, which is communicatively coupled to a decentralized network data gateway 810. The cloud service 802 is shown as including a cloud decentralized network 820 communicatively coupled to an IoT hub 830. Figure 8 As shown, the decentralized network data gateway 810 is communicatively coupled to the cloud decentralized network 820 via the IoT hub 830. Fig. 9 The decentralized network data gateway 810 is described in more detail.

[0082] Still refer to Figure 8 , the cloud decentralized network 820 is shown to include a data authentication distributed application ("DApp") 821, which is communicatively coupled to a virtual flow computer DApp 822, a Plantweb metering advisor ("PWAM") analysis DApp 824, and an operation DApp 826. The operation DApp 826 is communicatively coupled to a client DApp 827. Although in Figure 8 Not shown, as will be referred to below Fig.10 Described in more detail, the cloud decentralized network 820 may include a calibration DApp that is communicatively coupled to a data authentication DApp 821. The data authentication DApp 821 may check the measurement device 805 using the calibration DApp to indicate that the measurement device 805 has been calibrated according to regulatory requirements.

[0083] The measuring device 805 is shown as a general flow meter, but any suitable measuring device may be used. The measuring device 805 may be the one described above with reference to Figure 2 and Figure 4 One of the industrial equipment 220 described. Figure 8 , the measuring device 805 can provide data to the decentralized network data gateway 810. For example, the measuring device 805 can provide measurement data, checksums, firmware data, unique IDs, configuration information, etc. The data can be provided according to any suitable protocol. For example, the data can be provided in messages such as the Modbus RTU packets described above. The messages can be encapsulated into other protocols (e.g., message queue telemetry transport ("MQTT"), advanced message queue protocol ("AMQP"), hypertext transfer protocol ("HTTP"), Bluetooth, etc.).

[0084] Exemplary measurement data may be any suitable measurement of a physical property (e.g., density, flow, etc.). A checksum may be any suitable value that may be used to check the value of a register in a measuring device such as measuring device 805. For example, a cyclic redundancy check ("CRC") may be performed on the value in the register of measuring device 805. The unique identifier may be a public key, a serial number provided by the manufacturer of the measuring device, and / or one or more values ​​in a read-only register (e.g., a Modbus input register) of measuring device 805. A combination of these values ​​may be a unique identifier for measuring device 805.

[0085] Additionally or alternatively, the decentralized network data gateway 810 may create a unique identification for the measurement device 805 and store the unique identification in the measurement device 805. For example, the decentralized network data gateway 810 may obtain a public key from the cloud decentralized network 820 and associate a read-only register value of the measurement device 805, such as a serial number, a combination of register values, etc., with the public key. Some exemplary read-only registers of the measurement device 805 may be a central processing unit (“CPU”) board serial number, a revision number of a board (e.g., a field programmable gate array (“FPGA”), a data acquisition board, etc.). The association between the public key and the read-only register value may be stored in a hardware security module 816 of the decentralized network data gateway 810.

[0086] The decentralized network data gateway 810 receives data from the measurement device 805 and verifies that the data was sent by the measurement device 805. For example, the decentralized network data gateway 810 can recalculate the checksum based on the provided data. As an illustration, the decentralized network data gateway 810 can verify that the firmware checksum provided by the measurement device 805 is the same as the expected firmware checksum. Fig. 9 Describe these and other details.

[0087] Reference Figure 8 , the data authentication DApp 821 can authenticate the data provided by the measurement device 805. For example, the data authentication DApp 821 can maintain a secure storage of unique identifiers (e.g., public keys, addresses, etc.) of devices, stakeholders, and non-stakeholders that are allowed to send data to the cloud decentralized network 820. The secure storage of unique identifiers of devices, stakeholders, and non-stakeholders can be used as an identifier whitelist. As will be described below, Fig.10 As described, the data authentication DApp 821 can interact with the decentralized network data gateway 810 to ensure that only measurement devices listed in the whitelist can communicate with the cloud decentralized network 820.

[0088] The Data Authentication DApp 821 can also check that the measurement device 805 has been calibrated by cross-checking the unique identification of the device with, for example, the Calibration DApp. Fig.11 Similarly, the data authentication DApp 821 can check that the measurement device 805 has been maintained by cross-checking the unique identification of the measurement device 805 with the maintenance DApp. The data authentication DApp 821 can also use the service DApp to check that the service access has been implemented by an approved organization.

[0089] If any of the above checks fail, the application can alert the relevant stakeholders on the cloud decentralized network 820 and record the difference in a dedicated audit trail data store. Any reports generated using data that failed the check can be watermarked as temporary. Stakeholders can be notified of any remedial actions via their DApp interface, and, for example, stakeholders can be required to sign off on the changes as approved before the associated data is marked as final. This can include more detailed error measurement processing, which can be facilitated by software running on the PWAM analysis DApp 824 or elsewhere.

[0090] The virtual flow computer DApp 822 performs any suitable calculations similar or identical to those performed by the flow computer described above with reference to FIG. 7 . For example, the virtual flow computer DApp 822 can calculate fluid property values ​​based on data provided by the data authentication DApp 821. For example, the virtual flow computer DApp 822 can be an exemplary volume conversion device configured to adjust the values ​​from the measurement device 805 according to process conditions (e.g., temperature and pressure) and generate numbers for gross flow, standard flow, mass flow, and energy flow and totals. However, as from Figure 8 As can be understood in the example, the virtual traffic computer DApp 822 is a DApp, and therefore any computation can be performed as part of the cloud decentralized network 820. Therefore, the computation can be recorded to the blockchain.

[0091] The PWAM analysis DApp 824 can be a remote monitoring and analysis platform that can ensure the performance of the customer's metering equipment. For example, the PWAM analysis DApp 824 can form part of an audit chain. For example, the PWAM analysis DApp 824 can verify the data provided by the measurement device 805 via the data authentication DApp 821. As an illustration, the PWAM analysis DApp 824 can be a series of analysis routines for each device, where, for example, an ultrasonic meter can be verified by checking the speed of sound ("SOS") for a stand-alone device (e.g., a gas chromatograph) residing on site and tracking key performance indicators (e.g., profile factor, turbulence, symmetry, etc.) against stored and known benchmarks over time. Such a comparison can include an uncertainty value, which can also be recorded to the blockchain using a signature of the gas chromatograph and / or the decentralized network data gateway 810. The analysis module can be used for various devices on the decentralized network measurement system 800.

[0092] Thus, the client DApp 827 can obtain information from the operating DApp 826 and optionally perform actions based on the information. For example, the client DApps 827 can be an approval process, where unauthorized changes to the measuring device 805 are approved by the regulatory body after reviewing the information related to the measuring device 805. Such approval can, for example, remove the temporary status of the data provided by the measuring device 805. Such data can then be included in the measurement report provided, for example, by the virtual flow computer DApp 822. Other client DApps can be employed.

[0093] It will be appreciated that various DApps may be employed to perform decentralized (i.e., trustless) functions based on data provided by the measurement device 805. However, such decentralized functions may necessarily rely on the integrity of the data provided by the measurement device 805. Therefore, the decentralized network data gateway 810 may obtain information required to serve as an identification whitelist and an integrity whitelist for the decentralized network measurement system 800 from the cloud decentralized network 820, as will be described in more detail below.

[0094] Decentralized network data gateway

[0095] Fig. 9 A detailed view of a decentralized network data gateway 810 for uniquely identifying industrial equipment of a controller peripheral network is shown. Fig. 9 As shown, the decentralized network data gateway 810 receives data from the measurement device 805, but the decentralized network data gateway 810 can also be configured to receive data from other measurement devices. Fig. 9As shown, the decentralized network data gateway 810 includes a communication driver 812 that is communicatively coupled to the measurement device 805. The communication driver 812 is also communicatively coupled to a blockchain validator 814. The blockchain validator 814 is communicatively coupled to a hardware security module 816 and an Industrial Internet of Things ("IIoT") sender service 818. The IIoT sender service 818 is shown as providing IIoT protocol data to the cloud service.

[0096] The communication driver 812 can be any suitable communication driver that can communicate with one or more measurement devices such as the measurement device 805. For example, the communication driver 812 can be software that supports an industrial communication protocol that can communicate with the measurement devices on the measurement system. Examples of industrial communication protocols include Modbus, Open Platform Communications ("OPC"), and Highway Addressable Remote Transducer ("HART"), but any suitable communication protocol can be used.

[0097] The blockchain verifier 814 can be any suitable circuit, algorithm, processor, etc. that can verify that the source of the data provided to the communication driver 812 is a trusted source. For example, the blockchain verifier 814 can be the following algorithm: it is used to verify that the measurement device 805 can be trusted and can be allowed to send data to the cloud. More specifically, the blockchain verifier 814 can determine that the measurement device 805 is the actual provider of the data and the data can be sent to the cloud decentralized network 820 described above.

[0098] The hardware security module 816 can be any suitable circuit, software, processor, etc. that can securely store one or more private keys of the decentralized network data gateway 810. For example, the hardware security module 816 can be an algorithm that securely stores the private key of the decentralized network data gateway 810. As an illustration, a trusted platform module or other secure storage technology can be used. The private key of the decentralized network data gateway 810 can be used to sign data being sent to a cloud service (e.g., the cloud decentralized network 820 described above).

[0099] The IIoT sender service 818 can be any suitable circuit, algorithm, processor, etc. that can support a communication protocol for sending data to the cloud. Fig. 9 As shown, the IIoT sender service 818 can be software that supports the IoT protocol for sending data to the cloud service. Examples of IoT protocols include MQTT and AMQP. As discussed above, the cloud service can be a cloud decentralized network 820. The decentralized network data gateway 810 can be configured to perform various steps to ensure the integrity of the data provided to the cloud decentralized network 820.

[0100] To ensure the integrity of the data provided by the measuring device 805, the decentralized network data gateway 810 can read a checksum from the measuring device 805 using, for example, the American Standard Code for Information Interchange ("ASCII") representation for transmission across, for example, a Modbus network. In the event that the measuring device providing data to the decentralized network data gateway 810 does not include or cannot provide a checksum to the decentralized network data gateway 810, the decentralized network data gateway 810 can be configured to calculate the checksum by implementing a cryptographic algorithm on a writable parameter of the device and storing it in the cloud decentralized network 820 via a data authentication DApp 821.

[0101] The decentralized network data gateway 810 and the data authentication DApp 821 can be configured to perform the following steps. First, the decentralized network data gateway 810 can communicate with the data authentication DApp 821 to obtain the latest whitelist. For example, the decentralized network data gateway 810 can obtain the whitelist periodically, occasionally, such as when an event occurs, etc. Additionally or alternatively, the data authentication DApp 821 can provide the whitelist in response to a request from the decentralized network data gateway 810. The measurement device 805 can be verified against the whitelist. Therefore, the data authentication DApp 821 can check previous messages sent between downloads of the whitelist and take any necessary actions for any differences found.

[0102] Second, after the measurement device 805 is authenticated, the decentralized network data gateway 810 can format the message into an IoT message format supported by the cloud decentralized network 820. Such formatting can include adding checksums, batching data, etc. In the case where the measurement device 805 does not provide a checksum, it may be necessary to add a checksum. Batching of data by, for example, minimizing data transmission to the cloud decentralized network 820 may be beneficial or necessary.

[0103] Third, the data can be signed. For example, a signature can be obtained from the hardware security module 816 and used to sign the data to be provided to the cloud decentralized network 820. The signature can enable the data authentication DApp 821 to verify that the data is provided by the decentralized network data gateway 810.

[0104] Fourth, the operational integrity of the measuring device 805 can be verified. For example, the data authentication DApp 821 can compare the unique identification of the data with the unique identification of any maintenance records, calibration records, and service records. As an illustration, the maintenance records can be indexed by the unique identification value. Therefore, the data authentication DApp 821 can execute an algorithm that checks that the measuring device 805 has not expired due to planned maintenance. In one embodiment, the cloud decentralized network 820 can store an "effective" date associated with the most recent planned maintenance. If the date of the data provided by the measuring device 805 is less than the "effective" date, the data can be indicated as coming from the maintained measuring device 805.

[0105] Fifth, the measurement values ​​may be calculated. For example, in a managed transfer of hydrocarbons, the measurement data may be added to obtain a total value. The calculation of the measurement values ​​may be performed by the virtual flow computer DApp 822. Thus, the virtual flow computer DApp 822 may accumulate data provided by the measurement device 805 and authenticated by the data authentication DApp 821 until the managed transfer is complete. Additionally or alternatively, the virtual flow computer DApp 822 may calculate the measurement values ​​that occur simultaneously with the measurement data of the data provided by the measurement device 805. As an illustration, the mass flow value may be calculated using the volume flow multiplied by the density of the fluid.

[0106] Sixth, the cloud decentralized network 820 can generate reports. For example, refer to Figure 8 , the virtual flow computer DApp 822 can generate a measurement report containing the measurement values ​​determined by the virtual flow computer DApp 822. Similarly, the PWAM analysis DApp 824 can generate audit and verification data reports, and the operations DApp 826 can generate work order reports. The reports can be generated, for example, periodically, on demand, etc.

[0107] In addition to reference Figure 8 and Fig. 9 In addition to the physical devices of the described measurement devices 805, the cloud decentralized network 820 can be configured for use by third parties or non-stakeholders. For example, a third party can ensure the integrity of the measurement reports provided by the virtual flow computer DApp 822. As an example, an independent calibration facility where flow meters are sent for periodic recalibration may be able to add calibration data to the cloud decentralized network 820, as will be described in more detail below.

[0108] Serve as an exemplary calibration facility for non-stakeholders

[0109] Fig.10 FIG. 8 is a flowchart diagram of a decentralized network measurement system 800 including uniquely identified industrial equipment. Fig.10As shown, the decentralized network measurement system 800 includes a measurement device 805, which is coupled to a decentralized network data gateway 810 via a secure data transmission 801a. The decentralized network data gateway 810 is communicatively coupled to a cloud decentralized network 820. Fig.10 As shown, the cloud decentralized network 820 is depicted in an alternative detailed view. More specifically, the cloud decentralized network 820 is shown to include a data authentication DApp 821, a virtual traffic computer DApp 822, and a PWAM analysis DApp 824 that are communicatively coupled to each other. However, referring to Figure 8 The depicted client DApp 827 is shown as an exemplary calibration DApp 827a.

[0110] like Fig.10 As can be seen in FIG. 8 , the measurement device 805 provides data having various data fields to the decentralized network data gateway 810. More specifically, the measurement device 805 provides measurement data including speed, SOS, and profile. In addition, the measurement device 805 provides a unique identifier such as described above, which can be any suitable unique identifier. The measurement device 805 also provides a checksum including a firmware checksum and a configuration checksum.

[0111] Fig.10 Also shown is an exemplary process performed by the decentralized network data gateway 810. More specifically, the decentralized network data gateway 810 verifies the source in step 1 and performs blockchain formatting, which can generally be referred to as decentralized network formatting. The decentralized network data gateway 810 can verify the source by obtaining firmware and configuration information associated with the unique identification of the data provided by the measurement device 805.

[0112] For example, the unique identification and the firmware checksum and configuration checksum can be used to verify that the measurement device 805 is authorized to send measurement data to the cloud decentralized network 820. For example, during the initial installation, the decentralized network data gateway 810 can read the firmware checksum and configuration checksum from the measurement device 805 or any other device of the decentralized network measurement system 800. Auditors / approval / regulatory representatives can digitally sign these checksums using their client DApps 827 (e.g., on-site, remotely, etc.). These approved checksums will be stored locally and / or stored to a storage service (e.g., IPFS) by the decentralized network data gateway 810 using the unique identification of the measurement device 805 as an index.

[0113] When the decentralized network data gateway 810 receives data from the measurement device 805 or periodically receives data from the measurement device 805, the decentralized network data gateway 810 may first verify the unique identifier of the measurement device 805 against a whitelist, which may be stored locally or remotely. If the measurement device 805 passes the whitelist check, the decentralized network data gateway 810 may then verify the unique identifier of the measurement device 805 against a stored, approved version such as Figure 8 805 to ensure that nothing in the measuring device 805 has been altered. When a change is detected, the decentralized network data gateway 810 can send out an alert to notify all relevant stakeholders that something has changed on the measuring device 805 without authorization. Approving authorities can be given the option to approve the change using their client DApps 827, otherwise the data will be marked as unapproved and any reports will have a visible indication of this, such as a watermark.

[0114] Furthermore, to avoid such problems, in the event that an operator wishes to change parameters or firmware on a measurement device 805, the operator can first propose the change using their client DApps 827, and other stakeholders can then approve the proposed change using their client DApps 827. The decentralized network data gateway 810 can then accept updated checksums from the measurement device 805 and store these checksums as an updated, approved set. It will be appreciated that the decentralized network data gateway 810 can be employed in other processes, such as calibration processes, to ensure the integrity of the data provided by the measurement device 805.

[0115] Fig.11 1100 is shown as a data flow of a calibration report according to a detailed view of the cloud decentralized network 820. Fig.11 As shown, data flow 1100 includes measurement device 805 providing data to calibration facility 1107. Calibration facility 1107 is shown as providing calibration report 1113. Fig.11 1113 may be provided to the reference Figure 8 Described cloud decentralized network 820. Fig.11 As shown, the calibration report 1113 is provided to the calibration DApp 827a.

[0116] The calibration technician may use the calibration facility 1107 to calibrate the measurement device 805. Once the measurement device 805 is calibrated, the calibration technician may use the services provided by the cloud decentralized network 820. For example, Fig.11As shown, the calibration DApp 827a can be used to read a quick response (QR) code on the measurement device 805, which stores a unique identification (e.g., public key, serial number) and other relevant details of the measurement device 805. The calibration technician can attach the calibration report 1113 to the data packet and submit the calibration report 1113 to the cloud decentralized network 820 using the calibration DApp 827a and the private key of the calibration technician and / or the calibration facility 1107. The PWAM analysis DApp 824 of the cloud decentralized network 820 can check the data packet using the public key of the calibration facility 1107 after checking that the public key is whitelisted. Once verified, the data packet can be stored on the cloud decentralized network 820.

[0117] method

[0118] Fig.12 A method 1200 for uniquely identifying industrial equipment of a controller peripheral network is shown. Fig.12 As shown, the method 1200 obtains a unique identifier from a decentralized network using industrial equipment in step 1210. In step 1220, the method 1200 stores the unique identifier in a memory of the measurement device, the memory being defined by the controller peripheral network.

[0119] The memory defined by the controller peripheral network may include registers mapped according to the protocol of the controller peripheral network. For example, the memory may be the registers described above with reference to Figure 5 and Figure 6 The depicted undivided unique identification register 500 or the divided unique identification register 600. Thus, the unique identification may be stored in at least one of the registers.

[0120] The unique identifier may include one of a public key and a token identifier of the uniquely identified industrial equipment. For example, as described above, the public key may be obtained and stored in the undivided unique identifier register 500. In addition, the memory may also be configured to store a private key paired with the unique identifier. For example, Figure 5 As shown, the private key may be stored in an undivided unique identification register at address 9019, but any suitable register or address may be used.

[0121] Obtaining the unique identifier from the decentralized network using the industrial equipment may include: obtaining the unique identifier from the decentralized network using a communication port communicatively coupled to the controller peripheral network, as described below with reference to Fig.13 Will be described in more detail.

[0122] Industrial Equipment

[0123] Fig.13 The uniquely identified industrial equipment 1300 is shown. Fig.13 As shown, industrial equipment 1300 includes sensor 1310 and electronic device 1320. Industrial equipment 1300 can be a representation of uniquely identified industrial equipment 220, measurement device 805, etc., but any suitable measurement device can be used. As will be described in more detail below, industrial equipment 1300 can be configured to perform various methods such as the above-mentioned method 1200 to determine and use the unique identification of the measurement device.

[0124] Sensor 1310 may be configured to sense a physical property. For example, sensor 1310 may be configured to sense a property of a material such as a fluid. For example, sensor 1310 may be a Coriolis sensor assembly including one or more conduits containing a fluid, a fork-shaped density meter, an ultrasonic flow meter, etc. The property may be density, mass flow, volume flow, etc. Fig.13 As can be seen in FIG. 1 , the sensor 1310 is communicatively coupled to the electronic device 1320 .

[0125] The sensor 1310 can be communicatively coupled to the electronic device 1320 using any suitable method. For example, the sensor 1310 can provide one or more signals such as digital signals and / or analog signals representing the value of one or more physical properties of the fluid sensed by the sensor 1310, for example. The one or more signals can be provided in any suitable form. For example, the one or more signals can be superimposed, divided by channels, time-division multiplexed, frequency-division multiplexed, modulated, etc. The signal may or may not represent the physical property in units of the physical property. The one or more signals are provided to the electronic device 1320.

[0126] The electronic device 1320 may receive one or more signals from the sensor 1310 and scale, adjust, denoise, etc. the one or more signals. Additionally or alternatively, the electronic device 1320 may convert the one or more signals into a measurement value in units of a physical property sensed by the sensor 1310. The electronic device 1320 may also be configured to format the measurement value to provide to another device. For example, the electronic device 1320 may provide data to other devices in a format that complies with a communication protocol, such as a communication protocol of a controller peripheral device network.

[0127] like Fig.13As shown, electronic device 1320 includes processor 1321, which is communicatively coupled to memory 1322. Processor 1321 is also communicatively coupled to interface 1323 and communication port 1324. Interface 1323 is shown as being communicatively coupled to processor 1321. In addition, processor 1321 is communicatively coupled to graphical user interface ("GUI") 1325 and input device 1326.

[0128] Processor 1321 may be any suitable processor, such as a CPU that executes an operating system and programs operated by the operating system. For example, processor 1321 may be a single CPU, multiple processors in a single chip, processors distributed on different circuits, virtual instances on a virtual machine, etc. Processor 1321 may be configured to process one or more signals provided by sensor 1310 to determine, for example, a measurement value, convert the measurement value into a form suitable for communication, receive and / or provide input and / or output data, etc. Additionally or alternatively, processor 1321 may include circuits such as an application-specific integrated circuit ("ASIC") that can perform specific specialized tasks. For example, processor 1321 may include circuits that encrypt data to memory 1322 and / or decrypt data from memory 1322.

[0129] The processor 1321 may be configured to communicate with the memory 1322 so as to read from and / or write to the memory 1322. Thus, the memory 1322 may provide data such as measurement data, unique identification, firmware number, configuration information, etc. The memory 1322 may be configured to receive and store data provided by the processor 1321. The memory 1322 may be any suitable memory, such as, for example, a read-only memory ("ROM"), a random access memory ("RAM"), etc. The memory 1322 may also include or be composed of a secure memory. For example, a portion of the memory 1322 may be encrypted so that only a separately protected operating system in the processor 1321 can access the encrypted portion of the memory 1322.

[0130] Interface 1323 may be any suitable interface that may receive and / or condition one or more signals provided by sensor 1310. For example, interface 1323 may include an analog filter, an analog-to-digital converter ("ADC"), a buffer, etc. Thus, interface 1323 may provide the received one or more signals to processor 1321 in a form suitable for processor 1321.

[0131] GUI 1325 may receive and display data from processor 1321. For example, GUI 1325 may receive and display measurements, checksum data, firmware numbers, configuration information, etc. Input device 1326 may be any suitable input device, such as a keyboard, pen, fingerprint reader, etc. More or fewer GUIs and input devices may be employed.

[0132] Thus, the uniquely identified industrial equipment 1300 can be configured to perform various methods. For example, the memory 1322 can be defined by a controller peripheral network such as the controller peripheral network 200 described above. The memory 1322 can be configured to store a unique identification obtained from a decentralized network (e.g., the decentralized network 410 described above) outside the controller peripheral network.

[0133] The memory 1322 defined by the controller peripheral network may include registers mapped according to the protocol of the controller peripheral network, such as the undivided unique identification register 500 and the divided unique identification register 600 described above. Therefore, the unique identification is stored in at least one of the registers. The unique identification may include one of a public key and a token identifier of the uniquely identified industrial equipment. The memory 1322 may also be configured to store a private key paired with the unique identification. It is understood that the communication port 1324 may be configured to communicate with the controller peripheral network to obtain a unique identification from a decentralized network.

[0134] The above embodiment provides a method 1200 and a uniquely identified industrial equipment 1300. The unique identification of the uniquely identified industrial equipment 1300 can be obtained from a decentralized network. The unique identification can be stored in the industrial equipment. Therefore, the uniquely identified industrial equipment 1300 can, for example, sign data (e.g., messages or transactions) that can be recorded to the decentralized network 410 or more specifically to the blockchain 414 of the decentralized network 410. Therefore, the message or transaction and the identity of the uniquely identified industrial equipment 1300 can be verified by other stakeholders, devices, etc. This can achieve automatic and trustless recording, verification, etc. of various transactions, messages, records, etc.

[0135] The detailed description of the above embodiments is not an exhaustive description of all embodiments contemplated by the inventors within the scope of this specification. Indeed, those skilled in the art will recognize that certain elements of the above embodiments may be combined or eliminated in various ways to create other embodiments, and such other embodiments fall within the scope and teachings of this specification. It will also be apparent to those of ordinary skill in the art that the above embodiments may be combined in whole or in part to create additional embodiments within the scope and teachings of this specification.

[0136] Therefore, although specific embodiments are described herein for illustrative purposes, various equivalent modifications may be made within the scope of this specification as will be appreciated by those skilled in the relevant art. The teachings provided herein may be applied to other methods of uniquely identifying industrial equipment of a controller peripheral network, and not only to the embodiments described above and shown in the accompanying drawings. Therefore, the scope of the embodiments described above should be determined according to the appended claims.

Claims

1. A uniquely identified industrial equipment (1300) of a controller peripheral network (200), the uniquely identified industrial equipment (1300) comprising: An electronic device (1320), the electronic device (1320) comprising: a processor (1321) configured to communicate with a controller peripheral network (200); and A memory (1322), the memory (1322) being communicatively coupled to the processor (1321), the memory (1322): defined by said controller peripheral network (200); and The controller is configured to store a unique identifier obtained from a decentralized network (410) external to the controller peripheral network (200).

2. The uniquely identified industrial equipment (1300) according to claim 1, wherein: The memory (1322) defined by the controller peripheral network (200) includes registers (500, 600) mapped according to a protocol of the controller peripheral network (200).

3. The uniquely identified industrial equipment (1300) according to claim 2, wherein: The unique identification is stored in at least one of the registers (500, 600).

4. The uniquely identified industrial equipment (1300) according to claim 1, wherein: The unique identification includes one of a public key and a token identifier of the uniquely identified industrial equipment (1300).

5. The uniquely identified industrial equipment (1300) according to claim 1, wherein: The memory (1322) is also configured to store a private key paired with the unique identifier.

6. The uniquely identified industrial equipment (1300) according to claim 1, further comprising: A communication port (1324) is communicatively coupled to the processor (1321), and the communication port (1324) is configured to communicate with the controller peripheral device network (200).

7. A method for uniquely identifying industrial equipment of a controller peripheral network, the method comprising: Obtaining a unique identifier from a decentralized network using the industrial equipment; as well as The unique identification is stored in a memory of the industrial equipment, the memory being defined by the controller peripheral network.

8. The method according to claim 7, wherein: The memory defined by the controller peripheral network includes registers mapped according to a protocol of the controller peripheral network.

9. The method according to claim 8, wherein: The unique identification is stored in at least one of the registers.

10. The method according to claim 7, wherein: The unique identification includes one of a public key and a token identifier of the uniquely identified industrial equipment.

11. The method according to claim 7, wherein: The memory is further configured to store a private key paired with the unique identification.

12. The method according to claim 7, wherein: Obtaining the unique identifier from the decentralized network using the industrial equipment includes obtaining the unique identifier from the decentralized network using a communication port that is communicatively coupled to the controller peripheral network.

Images