Formation and verification of messages for measurement device

Abstract

A method for forming a message from a measurement device for data verification is provided. The method includes obtaining a previously determined unique identification of the measurement device, obtaining measurement data of the measurement device, and combining the previously determined unique identification of the measurement device with the measurement data.

Description

Technical Field

[0001] The embodiments described below relate to messages provided by measurement devices, and more particularly, to forming and validating messages of measurement devices. Background Art

[0002] Measuring equipment is often calibrated and maintained through various services. Therefore, the calibration and maintenance records of a particular measuring equipment may or may not be available to other organizations. For example, a manufacturer of a measuring equipment may calibrate the measuring equipment and make the calibration records available to a purchaser of the measuring equipment. The purchaser may be able to obtain the records due to a contractual relationship with the manufacturer. However, other organizations, such as government organizations, may need to rely on a client who acts as an intermediary to provide the records. To obtain such records, the client may refer to the manufacturer serial number of the measuring equipment. The serial number may be assigned to the measuring equipment by the manufacturer before the measuring equipment is shipped to the customer.

[0003] Additionally, measurement equipment may be used to transfer materials as part of a transaction. For example, a Coriolis meter may be used in the custody transfer of hydrocarbons or petroleum liquids from an offshore vessel to a shore tank. The transfer of hydrocarbons may involve the transfer of large quantities of hydrocarbons and therefore may involve significant monetary interests of the stakeholders in the transaction. Therefore, the stakeholders have a strong incentive to ensure that the total measured mass value of the custody transfer is correct. Ensuring that the total measured mass 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, transportation company, etc.) and third parties (e.g., a government collecting taxes) may wish to accurately record transaction details in a manner that cannot be subsequently altered and is usable without permission from either party. By way of illustration, a transferee may wish to deliver reliable information about hydrocarbons to a customer based on the most recent custody transfer, such as sampling of the hydrocarbons. Additionally or alternatively, parties to a custody transfer may wish to verify the calibration of a meter performing such measurements to ensure that the correct amount of mass is being measured.

[0005] Such verification can be seen as relying on verifying that the measuring device is authorized to provide the message and verifying that the message is provided by the measuring device.Therefore, there is a need to form and verify the message of the measuring device. Summary of the invention

[0006] A method for forming a message from a measuring device for data verification is provided. According to an embodiment, the method comprises obtaining a previously determined unique identification of the measuring device, obtaining measurement data of the measuring device, and combining the previously determined unique identification of the measuring device with the measurement data.

[0007] A measuring device configured to form a message is provided. According to an embodiment, the measuring device comprises: a memory configured to store a unique identification of the measuring device; and a processor communicatively coupled to the memory, the processor configured to execute the method as described above.

[0008] A decentralized network data gateway configured to form a message is provided. According to an embodiment, the decentralized network data gateway comprises: a memory configured to store a unique identification of a measurement device; and a processor communicatively coupled to the memory, the processor configured to execute one of the aforementioned methods.

[0009] A method for data verification of a message from a measuring device is provided. According to an embodiment, the method includes: receiving a message from a measuring device; obtaining a previously determined unique identifier of the measuring device from the message; comparing the previously determined unique identifier of the measuring device obtained from the message with previously determined unique identifiers listed in a white list; and determining whether the previously determined unique identifier of the measuring device obtained from the message matches the previously determined unique identifier listed in the white list.

[0010] A decentralized network data gateway for verifying a message from a measurement device is provided. According to an embodiment, the decentralized network data gateway includes: a memory configured to store a whitelist containing previously determined unique identifiers of whitelisted measurement devices; and a processor communicatively coupled to the memory, the processor configured to execute the method as described above.

[0011] aspect

[0012] According to one aspect, a method for forming a message from a measurement device for data verification includes obtaining a previously determined unique identification of the measurement device, obtaining measurement data of the measurement device, and combining the previously determined unique identification of the measurement device with the measurement data.

[0013] Preferably, obtaining the previously determined unique identification of the measuring device comprises: reading the previously determined unique identification from one or more registers of the measuring device.

[0014] Preferably, the previously determined unique identification of the measuring device is one of a public key obtained from the decentralized network and a serial number obtained from the measuring device.

[0015] Preferably, the serial number of the measuring device was previously associated with the public key.

[0016] Preferably, the method further comprises obtaining a checksum of the measuring device and combining the checksum with a previously determined unique identification of the measuring device.

[0017] Preferably, the checksum comprises one of a firmware checksum and a configuration checksum of the measuring device.

[0018] Preferably, the method further comprises: protecting the message for transmission to the cloud decentralized network via a secure channel.

[0019] Preferably, protecting the message for transmission to the cloud decentralized network via a secure channel comprises: protecting the message for transmission to an Internet of Things hub communicatively coupled to the cloud decentralized network.

[0020] According to one aspect, a measurement device configured to form a message comprises: a memory configured to store a unique identification of the measurement device; and a processor communicatively coupled to the memory, the processor configured to execute the method as described above.

[0021] According to one aspect, a decentralized network data gateway configured to form a message includes: a memory configured to store a unique identification of a measurement device; and a processor communicatively coupled to the memory, the processor configured to execute the method as described above.

[0022] According to one aspect, a method for performing data verification on a message from a measuring device includes: receiving a message from the measuring device; obtaining a previously determined unique identifier of the measuring device from the message; comparing the previously determined unique identifier of the measuring device obtained from the message with the previously determined unique identifiers listed in a whitelist; and determining whether the previously determined unique identifier of the measuring device obtained from the message matches the previously determined unique identifier listed in the whitelist.

[0023] Preferably, the message also comprises at least one checksum of the measuring device data.

[0024] Preferably, the method further comprises comparing at least one checksum of the measuring device data with a signed checksum stored in a memory of the decentralized network data gateway.

[0025] Preferably, the at least one checksum of the measurement device data comprises at least one of a firmware checksum and a configuration checksum.

[0026] Preferably, the method further comprises: obtaining from the cloud decentralized network a whitelist comprising previously determined unique identifiers listed in the whitelist.

[0027] Preferably, the method further comprises: storing the whitelist comprising the previously determined unique identifiers listed in the whitelist in a secure storage device of the decentralized network data gateway.

[0028] According to one aspect, a decentralized network data gateway for verifying messages from a measurement device includes: a memory configured to store a whitelist containing previously determined unique identifiers of whitelisted measurement devices; and a processor communicatively coupled to the memory, the processor configured to execute the method as described above. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0030] Figure 1 Shown is a front perspective view of a measuring device 5 configured to form a message.

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

[0032] Figure 3A and Figure 3B A single register ( Figure 3A ) and multiple register forms ( Figure 3B )'s memory 300.

[0033] Figure 4 A system 400 including a decentralized network 410 is shown.

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

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

[0036] Figure 8 A block diagram of a decentralized network measurement system 800 configured for data verification of messages from a measurement device 805 is shown.

[0037] Fig. 9 A detailed view of a decentralized network data gateway 810 is shown.

[0038] Fig.10 A flow chart view of a decentralized network measurement system 800 is shown.

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

[0040] Fig.12A method 1200 for forming a message from a measurement device for data validation is shown.

[0041] Fig.13 A method 1300 for data validation of a message from a measurement device is shown.

[0042] Fig.14 The measuring device 1400 is shown configured to form a message of the measuring device 1400 .

[0043] Fig.15 A decentralized network data gateway 1500 is shown that is configured to authenticate messages of a measurement device, such as the measurement device 1400 described above. DETAILED DESCRIPTION

[0044] Figures 1 to 15 The following description depicts specific examples of the best modes for teaching those skilled in the art how to make and use messages for forming and verifying measurement devices. 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 the variations of these examples that 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 constitute a variety of variations of messages for forming and verifying measurement devices. Therefore, the embodiments described below are not limited to the specific examples described below, but are limited only by the claims and their equivalents.

[0045] For example, messages including data such as measurements, device profiles, calibrations, etc. can be provided by the measuring device. The message can be formed according to a protocol that allows the data to be verified before being recorded to another system that can communicate with various stakeholders and non-stakeholders. Such formatting and verification may be particularly useful in the case where the data is recorded in a decentralized system or an untrusted system in an unchangeable form. That is, if the data provided can be verified as, for example, from an approved measuring device and has not been altered, the value of the data recorded to the decentralized system may have significantly greater value than the unverified data. In other words, combining the message formed to record and verify the message from the measuring system with the data recorded in the message using the decentralized system can significantly increase the value of the data to the stakeholders. As can be appreciated, the measuring device can be part of a controller-peripheral network, such as a Modbus network, which can affect the way the message is formed, as described below.

[0046] Controller-Peripheral Network

[0047] Figure 1 A front perspective view of a measuring device 5 configured to form a message is shown. Figure 1 As shown, the measuring device 5 is a meter that measures a property of a material flowing through the meter. More specifically, the measuring device 5 is shown as a Coriolis flow meter. Thus, Figure 1 The meter shown in is configured to measure the density and mass flow rate of the fluid. However, any suitable measuring device may be used. In the embodiment shown, the material may flow through the measuring device 5 via the inlet 5a and the outlet 5b. In alternative embodiments, other types of devices such as tuning fork density meters, flow control valves and systems, ultrasonic flow meters, pressure transducers, temperature sensors, etc. may be coupled to the measuring device 5.

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

[0049] 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 where it is advantageously shielded from a hazardous or harmful environment. In addition, the interface 20 may be remotely accessible, which may be advantageous for a user, for example, to compare data obtained from different measurement devices dispersed over a large area. Thus, the measurement device 5 may be part of a controller-peripheral network, as described below with reference to Figure 2 Will be discussed in more detail.

[0050] Controller-Peripheral Network

[0051] 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 measurement devices 220. Figure 2 As shown, the plurality of measuring devices 220 include reference Figure 1 The interface 20 described. Although not shown, reference Figure 1 The sensor assembly 10 is depicted as being coupled to each of a plurality of measurement devices 220. Figure 2As shown, the plurality of measuring devices 220 include first to third measuring devices 220 a to 220 c .

[0052] 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 measurement device 220a. Multiple measurement devices 220 may not be able to initiate commands or requests on the controller-peripheral network 200. A specific peripheral device among the multiple measurement devices 220 may respond to a command or request from the controller 210 only if the command or request is addressed to the specific peripheral device. The controller and peripheral devices of the controller-peripheral network may generally be referred to as devices of the controller-peripheral network.

[0053] 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 measuring devices 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 in the plurality of measuring devices 220 on the Modbus RTU network. As discussed above, a slave device cannot provide data to the Modbus RTU network without a request from the master device.

[0054] Referring to the controller-peripheral network 200 in Modbus RTU terminology, data as 8-bit bytes may be transmitted over the Modbus RTU network using serial transmission, one bit at a time. Each slave device in the Modbus RTU network may have a unique 8-bit address. The 8-bit address may be referred to as a unit number, but any suitable terminology may 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.

[0055] 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 to read and / or write to the register. The register can be a 16-bit data segment. For example, the register can be a signed or unsigned 16-bit integer. Therefore, for example, if a 32-bit integer value is required, 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.

[0056] Figure 3A and Figure 3B A single register ( Figure 3A ) and multiple register forms ( Figure 3B ) of the memory 300. Figure 3A As shown, the memory 300 is shown in a single register form, 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 register structure can be filled with data. That is, each of the plurality of registers in the memory 300 has Figure 3A The structure shown in Figure 1. Multiple registers are represented by Figure 3B The register numbering 302 is shown divided. Figure 3B Also shown are coils 310, discrete inputs 320, input registers 330, and holding registers 340.

[0057] Coil 310 may be a single bit register that may have a value of "0" or "1". Coil 310 may be a read and 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 a device, and write a value of "0" to turn off a subcomponent. In an alternative memory, the coil may not be employed in situations where a single bit binary value is not useful in a particular device.

[0058] Similar to coil 310, discrete input 320 can also be a single bit binary value "0" or "1". However, discrete input 320 can be read-only. 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 device can set the power state to "off". By way of illustration, the master device can send a request with a function code to write a value "1" to coil 310 that controls whether a 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.

[0059] 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 in that 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. Similar to coil 310, holding register 340 can be read and written by the master device. As discussed, the packet sent by the master device can include a function code. The function code indicates whether to read or write coil 310 or holding register 340 with data, or whether to write discrete input 320 or input register 330.

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

[0061] Table 1. Example function codes in Modbus packets

[0062] Function Code Register Type 1 Reading coil 2 Reading Discrete Inputs 3 Read Holding Registers 4 Read Input Register 5 Writing to a single coil 6 Writing to a single holding register 15 Writing to multiple coils 16 Writing to multiple holding registers

[0063] As can be appreciated, the function of the registers can be to read / write to a coil or holding register, or to read from a discrete input or input register. The registers can be configured and used as needed for a particular application, for example, to uniquely identify a measurement device on a controller-peripheral network, such as the measurement device 220 discussed above.

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

[0065] Decentralized Network

[0066] Figure 4 A system 400 is shown including a decentralized network 410. 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 represented 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 using 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.

[0067] 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 stake positions, 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 that maintains a blockchain 414 as an immutable database in which data in the immutable database is added only through consensus.

[0068] Node 412 may be any suitable device, server, system, computing resource, etc. capable of being 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 may also be employed. Node 412 may be configured to receive a transaction including one or more references to a previous transaction recorded to blockchain 414, a transaction to an address of a recipient recorded to blockchain 414, and a signature associated with the address of the sender. The transaction may be a ledger entry related to a flow measurement process, etc. The consensus algorithm may verify the transaction with the majority of nodes to all nodes in node 412. After verifying the transaction, the transaction may be recorded to the latest block 414a of blockchain 414.

[0069] For such verification 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. As can be appreciated, 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.

[0070] 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 414aa, but any suitable value may also 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 also be used. The values ​​of index 414aa and timestamp 414ab may be determined by node 412 using a verification algorithm.

[0071] The previous hash 414ac may be a hash 414ad of a block immediately before the latest block 414a. The hash 414ad may be a hash of various values ​​in the latest block 414a, such as an index, data, etc. The hash 414ad of the latest block 414a may be recorded in the immediately following block 414a as the previous hash 414ac. Thus, the blocks 414a of the blockchain 414 may be sequential. The sequence order of the block 414a may be verified by determining the 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 methods and other methods may be used to verify that the values ​​of the fields in the block 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.

[0072] As described above, data (e.g., messages, transactions, etc.) can be recorded to the blockchain 414. Data can be signed by a private key in a public key-private key pair. For example, a one-way algorithm (e.g., an elliptic curve digital signature algorithm) can use a message and a private key to generate a value. The value generated by the message and the signature can be a signature. Ownership of the 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 message and the private key (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 may have been used to generate the private key and public key pair.

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

[0074] Uniquely identify measuring devices

[0075] Figure 5 and Figure 6 The undivided unique identification register 500 and the divided unique identification register 600 are shown. It can be seen that 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 The illustrated, undivided unique identification register 500 includes a public key register 510. The public key register 510 is read-only and is of type A36. Although the public key register 510 is read-only, the manufacturer can write to the public key register 510. The public key register 510 has an address of 9001. The private key paired with the public key can be stored in a secure storage device of the measuring device, for example.

[0076] Reference Figure 6, the split unique identification register 600 includes a first public key register 610a and a second public key register 610b. For the sake of 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 read-only, but can be rewritable by the manufacturer. However, the first public key register 610a and the second public key register 610b are of type A18. In other words, the first public key register 610a and the second public key register 610b cannot save as many bits as the public key register 510. Therefore, the public key may not be stored in a single register, and 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.

[0077] As discussed above, private keys and public keys can be paired. More specifically, the private key is generated by, for example, a manufacturer of a measuring device such as measuring device 220, and the public key is generated based on the private key using a one-way encryption algorithm. The private key can be generated based on a value in a seed, such as 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 private key are kept confidential, while the public key can be shared. The manufacturer can store the private key in a secure memory of the measuring device that is unavailable to other parties except the manufacturer or elsewhere, such as a gateway managed by the manufacturer, and retain the seed. The public key can be used to generate a blockchain address so that the transaction including the blockchain address is recorded to 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 the transaction to show that the measuring device 220 has a private key.

[0078] Other unique identifiers may be used. For example, a token identifier may be used. A token identifier may be generated based on a file provided by, for example, a manufacturer of the measuring device 220. By way of illustration, a value may be obtained from, for example, a read-only register of the measuring device 220 and placed in a file. The file may be hosted on a file server with a link to the file. A file link may be generated based on the content of the file. An example is a content identifier ("CID") generated by a decentralized file hosting service such as the Interplanetary File System ("IPFS") according to the content of the file. The file link may be recorded as metadata in a token generation file such as a JavaScript Object Notation ("JSON") file, which a token generator may use to generate a non-homogeneous token, such as Ethereum Request for Comments Proposal 721 ("ERC721") or a token compliant with ERC20. Then, the token generator may generate a token identifier for the measuring device 220 accordingly. As may be appreciated, a token identifier is unique because the same token identifier cannot be generated again. Additionally, in the case of adopting a CID, the file stored at the file link cannot be modified. In contrast to the seeds discussed above, the files used to generate tokens do not need to be kept secret.

[0079] 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 number of bits. Thus, a register of type A242 may be suitable for the storage / use of cryptographic tokens and any other unique identifier that may require such a data type.

[0080] In the above method and other methods, a unique identification of the measuring device 220 can be generated and stored in the decentralized network 410 so that trust is not an issue. By way of illustration, the signature of the transaction signed by the measuring device 220 can be verified to be paired with the public key of the measuring device 220. Additionally, in another example, where a token identifier is used, the value of the input register in the measuring device 220 can be verified to be the same as the value recorded in the file at the file link of the token identifier. Therefore, interested parties and non-interested parties can determine that the data recorded to the decentralized network 410 is actually associated with the measuring device 220 identified by the unique identification without incurring risks associated with trust.

[0081] As discussed above, there may be several stakeholders involved in the delivery of fluids such as hydrocarbons. The stakeholders may include parties such as buyers, sellers, onshore facilities, transportation, 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 key issue because the technical details involved in ensuring the integrity of the measurement data may be difficult for a variety of reasons. For example, measurement systems such as fluid metering systems that include measurement equipment may be subject to a variety of conditions that affect the uncertainty associated with the data they present, including calibration and maintenance schedules, unstable process conditions, flow restrictions, and human errors, as described in more detail below with reference to FIG. 7.

[0082] Typical measurement system

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

[0084] The flow meter, flow computer, and supervisory computer may be owned by the seller of the fluid measured by the flow meter. For example, the seller may provide a measurement report to a buyer / government computer after the fluid is delivered from the seller to the buyer. The buyer / government computer may be owned by the buyer or government that may be interested in the delivery of the fluid measured by the flow meter. Thus, the seller, buyer, and / or government may be considered an interested party in the delivery of the fluid and, therefore, an interested party in the accurate measurement data of the delivery of the fluid.

[0085] The flow meter can be any suitable meter, such as a volume meter and / or a mass flow rate meter. The flow meter can provide a signal representing the fluid property of the fluid sensed by the flow meter. The flow meter can provide the original signal, the fluid property value, such as the 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 such as temperature and pressure, and generate a total flow rate, a standard flow rate, a mass flow rate and an energy flow rate and a total number. Therefore, although not shown for clarity, the measurement system 700 can also be communicatively coupled with other auxiliary devices, and the other auxiliary devices include temperature and / or pressure transmitters / transducers, gas chromatographs and / or densitometers.

[0086] The supervisory 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. As can be appreciated, there can also be additional electronic systems to analyze and detect faults in the equipment, and these systems can add a degree of integrity checking to the system.

[0087] Manual audits of metering systems are still common in order to ensure the integrity of the measurement data, but there are 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 parts, such as the flow meters, flow computers, and / or supervisory computers of the measurement system 700. In addition, auditors need to trust that the data recorded for audit purposes is accurate.

[0088] All equipment, their calibration records, and maintenance records may need to be reviewed during an audit. While electronic records may exist, they may have to reside on the seller's portion of the measurement system 700. Again, this may require another interested party 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 to independently cross-check the numbers and ensure data integrity. Obviously, this requires significant expense, both in capital costs and ongoing operating costs, and disputes are difficult to resolve without detecting an obvious source of error.

[0089] As mentioned above, by adopting a decentralized network such as Figure 4 The described decentralized network 410 can avoid the trust issues and costs associated with replicating the entire measurement system 700. That is, the decentralized network can replace the audit trail and ensure data reliability. However, this assumes 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.

[0090] Decentralized network gateway

[0091] Figure 8 8 is a block diagram of a decentralized network measurement system 800 configured to perform data verification on messages from a measurement device 805. Figure 8 As shown, the decentralized network measurement system 800 includes a flow measurement site 801 communicatively coupled to a cloud service 802 via a secure data transport 801a. The flow measurement site 801 includes a measurement device 805 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.

[0092] Still refer to Figure 8 , the cloud decentralized network 820 is shown to include a data verification distributed application ("DApp") 821, which is communicatively coupled to a virtual traffic computer DApp 822, an analysis DApp 824, and an operation DApp 826. The operation DApp 826 is communicatively coupled to the client DApp 827. Although Figure 8 is not shown, but as will be referred to below Fig.10 In more detail, the cloud decentralized network 820 may include a calibration DApp communicatively coupled to a data verification DApp 821. The data verification DApp 821 may check the measurement device 805 using the calibration DApp to show that the measurement device 805 has been calibrated according to regulatory requirements.

[0093] As will be described in more detail below, the measuring device 805 and / or the decentralized network data gateway 810 can be configured to provide, obtain and / or process three types of data in one or more messages to form or verify the message: measurement data, verification data and integrity data. The measurement data can be a process value for reporting fluid delivery in a measurement system. The measurement data is provided by the measuring device 805. The verification data can be one or more parameters that can be used to uniquely identify the measuring device 805 and verify the measuring device 805 against a white list, such as an identity white list. The verification data can come from the measuring device 805, or it can be compiled by the decentralized network data gateway 810. The integrity data can be one or more parameters that can be used to verify that the measuring device 805 configuration complies with the approved configuration for a specific measuring device 805. The integrity data can come from the measuring device 805, or it can be compiled by the decentralized network data gateway 810.

[0094] 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 measuring devices 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 in other protocols such as message queue telemetry transmission ("MQTT"), advanced message queue protocol ("AMQP"), hypertext transfer protocol ("HTTP"), Bluetooth, etc.

[0095] Exemplary measurement data may be any suitable measurement of a physical property such as density, flow rate, etc. The checksum may be any suitable value that may be used to check the value of a register in a measuring device such as the measuring device 805. For example, a cyclic redundancy check ("CRC") may be performed on the value in the register of the 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 the measuring device 805. A combination of these values ​​may be a unique identifier for the measuring device 805.

[0096] 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 or the decentralized network data gateway 810. 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 board revision number of a board such as 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.

[0097] 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. Additionally or alternatively, the decentralized network data gateway 810 can receive a checksum from the measurement device 805. The checksum of the measurement device 805 can be compared to an approved set of measurement devices 805, such as an integrity whitelist. By way of 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.

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

[0099] The data verification DApp 821 can also check whether the measurement device 805 has been calibrated by cross-checking the unique identification of the device with, for example, the calibration DApp, which will refer to Fig.11Similarly, the data verification DApp 821 can check whether the measurement device 805 has been maintained by cross-checking the unique identification of the measurement device 805 with the maintenance DApp. The data verification DApp 821 can also utilize the service DApp to check whether the service access has been made by an approved organization.

[0100] In the event that 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 may be watermarked as temporary. Stakeholders may be notified via their DApp interface to take any remedial actions, and may be required to sign off on these approved changes, for example, before the associated data is marked as final. This can include a more detailed error measurement process, which can be facilitated by software running on the analysis DApp 824 or elsewhere.

[0101] 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 validation DApp 821. For example, the virtual flow computer DApp 822 can be an exemplary volume conversion device that is configured to adjust the values ​​from the measurement device 805 according to process conditions such as temperature and pressure and generate numbers for the total flow rate, standard flow rate, mass flow rate, and energy flow rate, as well as the overall. However, as from Figure 8 As can be understood in the above, the virtual traffic computer DApp 822 is a DApp and therefore can perform any calculation as part of the cloud decentralized network 820. Therefore, the calculation can be recorded to the blockchain.

[0102] The analysis DApp 824 can be a remote monitoring and analysis platform to ensure the performance of the customer's metering equipment. For example, the analysis DApp 824 can form part of an audit chain. For example, the analysis DApp 824 can verify the data provided by the measurement device 805 via the data verification DApp 821. By way of illustration, the analysis DApp 824 can be a series of analysis routines for each device, in which, for example, an ultrasonic meter can be verified by checking the speed of sound ("SOS") against a separate device (e.g., a gas chromatograph) residing at the site and tracking key performance indicators (e.g., profile factor, turbulence, symmetry, etc.) against a stored and known good benchmark that varies over time. Such a comparison can include uncertainty values, which can also be recorded to the blockchain using the 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.

[0103] 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 DApp 827 can be an approval process in which an unauthorized change to the measuring device 805 is approved by a 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 a measurement report provided, for example, by the virtual flow computer DApp 822. Other client DApps can also be used.

[0104] As can be appreciated, 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 the information required to serve as an identity whitelist and integrity whitelist for the decentralized network measurement system 800 from the cloud decentralized network 820, as will be described in more detail below.

[0105] Decentralized network data gateway

[0106] Fig. 9 A detailed view of a decentralized network data gateway 810 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 communicatively coupled to the measurement device 805. The communication driver 812 is also communicatively coupled to a blockchain verifier 814. The blockchain verifier 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 a cloud service.

[0107] 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 also be used.

[0108] 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 an algorithm for verifying 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 that the data can be sent to the cloud decentralized network 820 described above.

[0109] 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. By way of 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 sent to a cloud service such as the cloud decentralized network 820 described above.

[0110] The IIoT sender service 818 can be any suitable circuit, algorithm, processor, etc. that can support the communication protocol to send 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 described 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.

[0111] 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 over, for example, a Modbus network. In the event that the measuring device providing data to the decentralized network data gateway 810 does not include a checksum or is unable to 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 an encryption algorithm on the read-only and / or readable and writable parameters of the device, and store the checksum via the data verification DApp 821 in the cloud decentralized network 820.

[0112] Read-only parameters may be writable by the manufacturer of the device, but not by other parties. Read-write parameters may be those parameters that may be read or written by those who have access rights to the read-write parameters via, for example, a communication port. Thus, for example, if a device does not store a firmware checksum, but does store something such as a firmware revision number of a board serial number for a board in the device, then these firmware revision numbers may be read by the decentralized network data gateway 810 and combined into a checksum.

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

[0114] Second, after the measurement device 805 has been verified, 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 the 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 may be beneficial or necessary, for example, by minimizing data transmission to the cloud decentralized network 820.

[0115] Third, the data can be signed. For example, the 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 allow the data verification DApp 821 to verify that the data is provided by the decentralized network data gateway 810.

[0116] Fourth, the operational integrity of the measuring device 805 can be verified. For example, the data verification DApp 821 can compare the unique identification of the data with the unique identification of any maintenance, calibration, and service records. By way of illustration, maintenance records can be indexed by unique identification values. Therefore, the data verification DApp 821 can execute an algorithm to check that the measuring device 805 has not expired for planned maintenance. In one embodiment, the cloud decentralized network 820 can store an "expiration date" date associated with the latest planned maintenance. If the date of the data provided by the measuring device 805 is less than the "expiration date", then the data can be indicated as coming from the maintained measuring device 805.

[0117] Fifth, the measured values ​​may be calculated. For example, in the custody transfer of hydrocarbons, the measured data may be summed to arrive at a total value. The calculation of the measured values ​​may be performed by the virtual flow computer DApp 822. Thus, the virtual flow computer DApp 822 may accumulate the data provided by the measurement device 805 and verified by the data verification DApp 821 until the custody transfer is complete. Additionally or alternatively, the virtual flow computer DApp 822 may calculate the measured values ​​concurrent with the measured data of the data provided by the measurement device 805. By way of illustration, the mass flow rate value may be calculated using the volume flow rate multiplied by the density of the fluid.

[0118] Sixth, the cloud decentralized network 820 can generate reports. For example, refer to Figure 8 , the virtual flow computer DApp 822 can generate measurement reports containing measurement values ​​determined by the virtual flow computer DApp 822. Similarly, the analysis DApp 824 can generate audit and inspection data reports, and the operation DApp 826 can generate work order reports. The reports can be generated, for example, periodically, upon request, etc.

[0119] In addition to physical devices such as reference Figure 8 and Fig. 9 In addition to the described measurement devices 805, the cloud decentralized network 820 can also be configured for use by third parties or non-interested parties. 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 that is notified of periodic recalibration by a flow meter may be able to add calibration data to the cloud decentralized network 820, as will be described in more detail below.

[0120] Acting as an exemplary calibration facility for non-stakeholders

[0121] Fig.10 8 shows a flowchart diagram of a decentralized network measurement system 800. Fig.10 As shown, the decentralized network measurement system 800 includes a measurement device 805 coupled to a decentralized network data gateway 810 via a secure data transport 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 verification DApp 821, a virtual traffic computer DApp 822, and an analysis DApp 824, which are communicatively coupled to each other. However, referring to Figure 8 The depicted client DApp 827 is shown as an exemplary calibration DApp 827a.

[0122] 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, which can be any suitable unique identifier, such as those described above. The measurement device 805 also provides checksums including firmware checksums and configuration checksums.

[0123] Fig.10 Also shown is an exemplary process performed by the decentralized network data gateway 810. More specifically, Fig.10 As shown, the decentralized network data gateway 810 verifies the source and performs blockchain formatting, which may generally be referred to as decentralized network formatting. Fig.10 In the example shown, the decentralized network data gateway 810 may verify the source by obtaining firmware and configuration information associated with the unique identification of the data provided by the measurement device 805. Additionally or alternatively, other data may be obtained.

[0124] like Fig.10As shown, the unique identification and 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 initial installation, the decentralized network data gateway 810 can read the firmware and configuration checksums from the measurement device 805 or any other device of the decentralized network measurement system 800. The auditor / approval / regulatory body representative can digitally sign these checksums using their client DApp 827 (e.g., on-site, remote, etc.). The decentralized network data gateway 810 will use the unique identification of the measurement device 805 as an index to store these approved checksums locally and / or to a storage service (e.g., IPFS).

[0125] When the decentralized network data gateway 810 receives data from the measurement device 805 or periodically receives data, the decentralized network data gateway 810 may first check 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 Figure 8 As shown in , the checksum provided by the measuring device 805 is verified against the stored approved version to ensure that nothing has been changed in the measuring device 805. In the event that a change is detected, the decentralized network data gateway 810 can issue an alert to notify all relevant stakeholders that something has been changed on the measuring device 805 without authorization. Approving entities can be given the option to approve the changes using their client DApp 827, otherwise the data will be marked as unapproved and any reports will have a visible indication of this unapproval, such as a watermark, stamp, data field, etc.

[0126] 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 use their client DApp 827 to propose the change, and then other stakeholders can use their client DApp 827 to approve the proposed change. The decentralized network data gateway 810 can then accept the updated checksums from the measurement device 805 and store these as an updated and approved set. As can be appreciated, 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.

[0127] 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.11As 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 reference Figure 8 Described cloud decentralized network 820. Fig.11 As shown, a calibration report 1113 is provided to the calibration DApp 827a.

[0128] The calibration technician may use the calibration facility 1107 to calibrate the measuring device 805. Once the measuring device 805 has been calibrated, the calibration technician may use the services provided by the cloud decentralized network 820. For example, Fig.11 As shown, the calibration DApp 827a can be used to read a quick response (QR) code on the measurement device 805 that stores a representation of the unique identification (e.g., public key, serial number) and other relevant details of the measurement device 805. The calibration technician can attach a 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 calibration technician's private key and / or the calibration facility 1107. The data verification DApp 821 of the cloud decentralized network 820 can use the public key of the calibration facility 1107 to check the data packet after checking whether the public key is whitelisted. Once verified, the data packet can be stored on the cloud decentralized network 820.

[0129] method

[0130] Fig.12 A method 1200 for forming a message from a measurement device for data verification is shown. Fig.12 As shown, method 1200 begins at step 1210, where a previously determined unique identifier of a measurement device is obtained. In step 1220, method 1200 obtains measurement data of the measurement device. In step 1230, method 1200 combines the previously determined unique identifier of the measurement device with the measurement data. Method 1200 may be configured to perform other steps.

[0131] For example, obtaining a previously determined unique identification of the measuring device may include: reading the previously determined unique identification from one or more registers of the measuring device. The previously determined unique identification of the measuring device may be one of a public key obtained from the decentralized network and a serial number obtained from the measuring device. The serial number of the measuring device may be previously associated with the public key.

[0132] Additionally or alternatively, the method 1200 may further include: obtaining a checksum of the measuring device, and combining the checksum with a previously determined unique identifier of the measuring device. The checksum may include one of a firmware checksum and a configuration checksum of the measuring device. The method 1200 may further include: protecting the message for transmission to the cloud decentralized network via a secure channel. For example, protecting the message for transmission includes: protecting the message for transmission to an IoT hub communicatively coupled to the cloud decentralized network.

[0133] The unique identification and the measurement data can be obtained from the measuring device via a single message or separate messages. That is, the measuring device can provide a first message containing the unique identification, and the measuring device can provide a second message containing the measurement data, which is continuous or non-continuous with the first message. Thus, for example, in the case of using separate messages, the message from the measuring device can be formed in the decentralized network data gateway. Alternatively, the message from the measuring device can be formed in the measuring device. Thus, the unique identification and the measurement data of the measuring device can be provided by the measuring device in a single message.

[0134] For example, in a Modbus network, method 1200 may have the following steps.

[0135] 1) The decentralized network data gateway requests measurement data in one or more polls (register groups).

[0136] 2) The decentralized network data gateway requests verification data in one or more polls.

[0137] 3) The decentralized network data gateway checks and verifies the data against the whitelist.

[0138] 4) The decentralized network data gateway reformats the message since the most recent validation, marks the message as valid / invalid, and reformats the message into a unified message signed by the decentralized network data gateway using its own private key for subsequent processing as described later.

[0139] In practice, the interval between requesting measurement data and verifying the data may be short enough to be difficult to spoof. Perhaps preferably, there may also be a mechanism whereby if the measurement device goes offline before the measurement data is verified, the decentralized network data gateway will either save the measurement data until the measurement device is back online and can be verified, or mark the measurement data as unverified and send it onwards.

[0140] Fig.13 A method 1300 for data verification of a message from a measurement device is shown. Fig.13As shown, in step 1310, method 1300 receives a message from a measuring device. In step 1320, method 1300 obtains a previously determined unique identifier of the measuring device from the message. In step 1330, method 1300 compares the previously determined unique identifier of the measuring device obtained from the message with the previously determined unique identifiers listed in the white list. In step 1340, method 1300 may determine whether the previously determined unique identifier of the measuring device obtained from the message matches the previously determined unique identifier listed in the white list.

[0141] As can be understood from the above discussion, the previously determined unique identifier can be any suitable value, such as a serial number of a measuring device, a public key stored in a secure storage device of the measuring device, etc. The previously determined unique identifier of the measuring device can be compared with a whitelist, such as an identity whitelist, in any suitable manner. By way of illustration, in the case where the decentralized network data gateway obtains a serial number from the measuring device, the decentralized network data gateway can determine that the unique identifier is associated with a public key stored in a secure storage device (e.g., an identity whitelist) of the decentralized network data gateway.

[0142] As can be understood from the foregoing discussion, the comparison between previously determined unique identifiers may be a direct comparison, or may not be a direct comparison. For example, a previously determined unique identifier may be processed into a hash value that is compared, for example, with a hash value stored in a decentralized network data gateway. Alternatively, in another example, a previously determined unique identifier may be combined with other values, such as other read-only register values ​​of a measuring device, and compared with a corresponding stored value. However, as can be understood, any suitable method for comparing a previously determined unique identifier with a unique identifier listed in a whitelist may be used.

[0143] The message may also include at least one checksum of the measuring device data. Therefore, method 1300 may also include: comparing at least one checksum of the measuring device data with a signed checksum stored in a memory of the decentralized network data gateway. In addition, the at least one checksum of the measuring device data may include at least one of a firmware checksum and a configuration checksum. Method 1300 may also include: obtaining a whitelist containing previously determined unique identifiers listed in the whitelist from the cloud decentralized network. In addition, method 1300 may also include: storing a whitelist containing previously determined unique identifiers listed in the whitelist in a secure storage device of the decentralized network data gateway.

[0144] Measuring equipment and decentralized network data gateway

[0145] Fig.14 14 shows a measuring device 1400 configured to form a message for the measuring device 1400. Fig.14 As shown, the measuring device 1400 includes a transducer 1410 and a device electronics 1420. The measuring device 1400 may be a representation of the measuring devices 220, 805, etc. described above, but any suitable measuring device may also be employed. As will be described in more detail below, the measuring device 1400 may be configured to perform various methods of forming a message from the measuring device 1400 for data verification, such as the method 1200 described above.

[0146] The transducer 1410 may be configured to sense a physical property. For example, the transducer 1410 may be configured to sense a property of a material such as a fluid. For example, the transducer 1410 may be a Coriolis sensor assembly including one or more tubes containing a fluid, a forked density meter, an ultrasonic flow meter, etc. The property may be density, mass flow rate, volume flow rate, etc. Fig.14 As can be seen, transducer 1410 is communicatively coupled to device electronics 1420 .

[0147] The transducer 1410 can be communicatively coupled to the device electronics 1420 using any suitable method. For example, the transducer 1410 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, for example, by the transducer 1410. 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 can represent the physical property in units of the physical property, or the signal can represent the physical property without units of the physical property. The one or more signals are provided to the device electronics 1420.

[0148] Device electronics 1420 may receive one or more signals from transducer 1410 and scale, condition, de-noise, etc. the one or more signals. Additionally or alternatively, device electronics 1420 may convert one or more signals into measurements in units of physical properties sensed by transducer 1410. Device electronics 1420 may also be configured to format the measurements to be provided to another device. For example, device electronics 1420 may provide data to other devices in a format that complies with a communication protocol, such as a communication protocol of a controller-peripheral network.

[0149] like Fig.14As shown, device electronics 1420 includes a processor 1421 communicatively coupled to a memory 1422. Processor 1421 is also communicatively coupled to an interface 1423 and a communication port 1424. Interface 1423 is shown as being communicatively coupled to processor 1421. Additionally, processor 1421 is communicatively coupled to a graphical user interface ("GUI") 1425 and an input device 1426.

[0150] Processor 1421 may be any suitable processor, such as a CPU, that executes an operating system and programs that operate through the operating system. For example, processor 1421 may be a single CPU, may be multiple processors in a single chip, may be distributed on different circuits, may be a virtual instance on a virtual machine, etc. Processor 1421 may be configured to process one or more signals provided by transducer 1410 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 1421 may include circuits, such as an application-specific integrated circuit ("ASIC") that may perform specific specialized tasks. For example, processor 1421 may include circuits that encrypt and / or decrypt data to and / or from memory 1422.

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

[0152] Interface 1423 may be any suitable interface that may receive and / or condition one or more signals provided by transducer 1410. For example, interface 1423 may include analog filters, analog-to-digital converters ("ADCs"), buffers, etc. Thus, interface 1423 may provide the received one or more signals to processor 1421 in a form suitable for processor 1421.

[0153] GUI 1425 can receive and display data from processor 1421. For example, GUI 1425 can receive and display measurements, checksum data, firmware numbers, configuration information, etc. Input device 1426 can be any suitable input device, such as a keyboard, pen, fingerprint reader, etc. More or fewer GUIs and input devices can be used.

[0154] The measuring device 1400 may be configured to form a message. For example, the processor 1421 may obtain a previously determined unique identifier of the measuring device 1400. For example, the processor 1421 may read a previously determined unique identifier from one or more registers of the measuring device 1400. The previously determined unique identifier of the measuring device 1400 may be one of a public key obtained from a decentralized network such as the cloud decentralized network 820 described above and a serial number obtained from the measuring device 1400. For example, the memory 1422 may (e.g., securely) store a previously determined unique identifier of the measuring device 1400. The serial number of the measuring device may have been previously associated with the public key. For example, as described in more detail above, the decentralized network data gateway 810 may store an association between a serial number and a public key obtained from the cloud decentralized network 820.

[0155] Additionally or alternatively, the measuring device 1400 or more particularly the processor 1421 may obtain a checksum of the measuring device 1400 and combine the checksum with a previously determined unique identifier of the measuring device 1400. The checksum may include one of a firmware checksum and a configuration checksum of the measuring device 1400. The processor 1421 may also protect messages for transmission to the cloud decentralized network via a secure channel. For example, the processor 1421 may protect messages for transmission to an IoT hub communicatively coupled to the cloud decentralized network 820 described above via a decentralized network data gateway, which will be described in more detail below.

[0156] Fig.15 1 shows a decentralized network data gateway 1500 configured to authenticate messages of a measurement device, such as the measurement device 1400 described above. Fig.15 As shown, the decentralized network data gateway 1500 includes a gateway server 1510 communicatively coupled to the measurement device 1400. The decentralized network data gateway 1500 can be representative of the decentralized network data gateway 810 described above, but any suitable decentralized network data gateway can also be used. As will be described in more detail below, the decentralized network data gateway 1500 can be configured to perform various methods.

[0157] The measuring device 1400 can be communicatively coupled to the gateway server 1510 using any suitable communication means. For example, the measuring device 1400 can provide measurement data via one or more signals such as digital signals and / or analog signals, and the digital signals and / or analog signals represent the value of one or more physical properties of the fluid sensed by the measuring device 1400, for example. One or more signals can be provided in any suitable form. For example, one or more signals can be superimposed, divided by channels, time-division multiplexed, frequency-division multiplexed, modulated, etc. The signal can represent the physical property in units of physical properties, or the signal can represent the physical property without using physical properties as units. One or more signals are provided to the gateway server 1510.

[0158] The gateway server 1510 may receive one or more signals from the measurement device 1400 and scale, adjust, denoise, demodulate, etc. the one or more signals. Additionally or alternatively, the gateway server 1510 may convert the one or more signals into a measurement value in units of a physical property sensed by the measurement device 1400. The decentralized network data gateway 1500 may also be configured to format the measurement value to be provided to a decentralized network, such as the cloud decentralized network 820 described above. For example, the decentralized network data gateway 1500 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.

[0159] like Fig.15 As shown, gateway server 1510 includes a processor 1521 communicatively coupled to memory 1522. Processor 1521 is also communicatively coupled to interface 1523 and cloud communication port 1524. Interface 1523 is shown as being communicatively coupled to processor 1521.

[0160] Processor 1521 can be any suitable processor, such as a CPU, that executes an operating system and programs that operate through the operating system. For example, processor 1521 can be a single CPU, can be multiple processors in a single chip, can be distributed on different circuits, can be a virtual instance on a virtual machine, etc. Processor 1521 can be configured to: process one or more signals provided by measuring device 1400 to determine, for example, measured values, convert measured values ​​into a form suitable for communication, receive and / or provide input and / or output data, etc. Additionally or alternatively, processor 1521 may include circuits, such as application-specific integrated circuits ("ASICs") that can perform specific specialized tasks. For example, processor 1521 may include circuits that encrypt and / or decrypt data to and / or from memory 1522.

[0161] The processor 1521 may be configured to communicate with the memory 1522 so as to read from and / or write to the memory 1522. Thus, the memory 1522 may provide data, such as measurement data, unique identification, firmware number, configuration information, etc. The memory 1522 may be configured to receive and store data provided by the processor 1521. The memory 1522 may be any suitable memory, such as a read-only memory ("ROM"), a random access memory ("RAM"), etc., and may be on a single circuit board, on a virtual memory running on a server, or via a cloud service, etc. The memory 1522 may also contain or include a secure memory. For example, a portion of the memory 1522 may be encrypted so that only an independent secure operating system in the processor 1521 can access the encrypted portion of the memory 1522.

[0162] Interface 1523 may be any suitable interface that may receive and / or condition one or more signals provided by measurement device 1400. For example, interface 1523 may include an analog filter, an analog-to-digital converter ("ADC"), a buffer, a demodulator, etc. Thus, interface 1523 may provide the received one or more signals to processor 1521 in a form suitable for processor 1521.

[0163] The decentralized network data gateway 1500 may be configured to verify a message of a measurement device, such as the measurement device 1400 described above. For example, the processor 1521 of the decentralized network data gateway 1500 may receive a message from the measurement device, and obtain a previously determined unique identifier of the measurement device from the message. The processor 1521 may also compare the previously determined unique identifier of the measurement device obtained from the message with the previously determined unique identifiers listed in the whitelist, and determine whether the previously determined unique identifier of the measurement device obtained from the message matches the previously determined unique identifier listed in the whitelist.

[0164] The message may also include at least one checksum of the measurement device data. Thus, the processor 1521 may compare the at least one checksum of the measurement device data with the signed checksum stored in the memory 1522 of the decentralized network data gateway 1500. The at least one checksum of the measurement device data may include at least one of a firmware checksum and a configuration checksum of the measurement device.

[0165] The decentralized network data gateway 1500 may also obtain a whitelist containing previously determined unique identifiers listed in the whitelist from a cloud decentralized network, such as the cloud decentralized network 820 described above. Therefore, the decentralized network data gateway 1500 may store the whitelist containing previously determined unique identifiers listed in the whitelist in a secure storage device of the decentralized network data gateway 1500, such as a secure storage device of the memory 1522. Therefore, the decentralized network data gateway may verify the message of the measuring device to ensure that the message is suitable for recording in the cloud decentralized network.

[0166] The embodiments described above provide methods 1200, methods 1300, measuring devices 1400, and decentralized network data gateways that can form and verify messages of measuring devices 1400. The formation of messages of measuring devices 1400 may include combining previously determined unique identifiers of measuring devices 1400 with measurement data. Thus, the message may be verified to be from measuring device 1400. Additionally or alternatively, the checksum may be compared to the signed checksum to ensure, for example, that the measuring device 1400 is approved for providing data to a cloud decentralized network. Thus, data provided by measuring device 1400, but by using firmware or configuration that has not yet been approved, may be automatically marked as unapproved.

[0167] Additionally or alternatively, the decentralized network data gateway 1500 may also be configured to verify the message. By way of illustration, the decentralized network data gateway 1500 may compare the previously determined unique identifier of the measuring device 1400 with a whitelisted unique identifier that has been signed and recorded to the cloud decentralized network. Similarly, the decentralized network data gateway 1500 may compare the checksum of the message with the signed checksum stored in the decentralized network data gateway 1500. Additionally or alternatively, the decentralized network data gateway 1500 may sign the message using a private key of the decentralized network data gateway 1500 or the measuring device 1400. The private key may be securely stored in the decentralized network data gateway.

[0168] The detailed description of the above embodiments is not an exhaustive description of all embodiments that the inventors envision falling within the scope of this specification. In fact, those skilled in the art will recognize that the specific elements of the embodiments described above can be combined or eliminated in various ways to create additional embodiments, and such additional 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 embodiments described above can be combined in whole or in part to produce additional embodiments within the scope and teachings of this specification.

[0169] 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 forming and verifying messages of a measuring device, and are not limited 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 method for forming a message from a measurement device for data verification, the method comprising: obtaining a previously determined unique identification of the measuring device; obtaining measurement data of the measuring device; as well as A previously determined unique identification of the measuring device is combined with the measurement data.

2. The method according to claim 1, wherein: Obtaining a previously determined unique identification of the measurement device includes reading the previously determined unique identification from one or more registers of the measurement device.

3. The method according to claim 1, wherein: The previously determined unique identification of the measuring device is one of a public key obtained from a decentralized network and a serial number obtained from the measuring device.

4. The method according to claim 3, wherein: The serial number of the measuring device was previously associated with the public key.

5. The method according to claim 1, further comprising: A checksum of the measuring device is obtained and the checksum is combined with a previously determined unique identification of the measuring device.

6. The method according to claim 5, wherein: The checksum includes one of a firmware checksum and a configuration checksum of the measurement device.

7. The method according to claim 1, further comprising: The message is protected for transmission to the cloud decentralized network over a secure channel.

8. The method according to claim 7, wherein: Securing the message for transmission to the cloud decentralized network via the secure channel includes securing the message for transmission to an IoT hub communicatively coupled to the cloud decentralized network.

9. A measuring device (1400) configured to form a message, the measuring device (1400) comprising: a memory (1422) configured to store a unique identifier of the measurement device (1400); as well as A processor (1421) communicatively coupled to the memory (1422), the processor (1421) being configured to execute the method according to one of the preceding claims 1 to 8.

10. A decentralized network data gateway (1500) configured to form a message, the decentralized network data gateway (1500) comprising: a memory (1522) configured to store a unique identification of the measurement device (1500); as well as A processor (1521) communicatively coupled to the memory (1522), the processor (1521) being configured to execute the method according to one of the preceding claims 1 to 8.

11. A method for data verification of a message from a measurement device, the method comprising: receiving a message from the measuring device; obtaining from the message a previously determined unique identification of the measuring device; comparing a previously determined unique identifier of the measuring device obtained from the message with previously determined unique identifiers listed in the whitelist; as well as A determination is made as to whether the previously determined unique identification of the measuring device obtained from the message matches a previously determined unique identification listed in the whitelist.

12. The method according to claim 11, wherein: The message also includes at least one checksum of the measuring device data.

13. The method according to claim 12, further comprising: At least one checksum of the measuring device data is compared with a signed checksum stored in a memory of the decentralized network data gateway.

14. The method according to claim 12, wherein: The at least one checksum of the measurement device data includes at least one of a firmware checksum and a configuration checksum.

15. The method according to claim 12, further comprising: A whitelist including previously determined unique identifiers listed in the whitelist is obtained from the cloud decentralized network.

16. The method according to claim 15, further comprising: The whitelist containing the previously determined unique identifiers listed in the whitelist is stored in a secure storage device of the decentralized network data gateway.

17. A decentralized network data gateway (1500) for verifying a message from a measurement device (1400), the decentralized network data gateway (1500) comprising: a memory (1522) configured to store a whitelist comprising previously determined unique identifications of the whitelisted measurement devices; as well as A processor (1521) communicatively coupled to the memory (1522), the processor (1522) being configured to execute the method according to one of the preceding claims 11 to 16.

Images