Validation of Measurement Data Sets Using Oracle Consensus

Abstract

A method includes obtaining, at a node, a first measurement dataset indicative of at least one first observables of an event, obtaining, at the node, a second measurement dataset indicative of at least one second observables of the event, triggering a comparison between the first measurement dataset and the second measurement dataset, and selectively triggering at least one validation measure for either the first measurement dataset or the second measurement dataset depending on a result of the comparison, where the first measurement dataset is provided by a first measurement device, the second measurement dataset is provided by a second measurement device, and the at least validation measure is implemented at a distributed database.

Claims

1.-12. (canceled)

13. A method for validating measurement datasets, comprising: obtaining, at a node, a first measurement dataset indicative of at least one first observables of an event, the first measurement dataset being provided by a first measurement device; obtaining, at the node, a second measurement dataset indicative of at least one second observables of the event, the second measurement dataset being provided by a second measurement device; triggering a comparison between the first measurement dataset and the second measurement dataset; and triggering selectively at least one validation measure for one of the first measurement dataset and the second measurement dataset depending on a result of the comparison, the at least one validation measure being implemented at a distributed database.

14. The method of claim 13, wherein the node comprises a node of an infrastructure of the distributed database; and wherein the comparison is provided by a smart contract of the distributed database.

15. The method of claim 13, wherein the node comprises a third-party node; and wherein the comparison is implemented at the third-party node.

16. The method of claim 13, wherein the at least one validation measure comprises storing a variable indicative of at least one of the result of the comparison, the first measurement dataset, and the second measurement dataset in the distributed database.

17. The method of claim 13, wherein the at least one validation measure comprises triggering a settlement process based on a deviation between the first measurement dataset and the second measurement dataset.

18. The method of claim 13, wherein the comparison is based on a predefined agreement indicative of a metric of the comparison.

19. A method, comprising: obtaining, at a second measurement device, a first measurement dataset indicative of at least one first observables of an event, the first measurement dataset being provided by a first measurement device; capturing, at the second measurement device, a second measurement dataset indicative of at least one second observables of the event; performing, at the second measurement device, a comparison between the first measurement dataset and the second measurement dataset; and triggering selectively at least one validation measure for one of the first measurement dataset and the second measurement dataset depending on a result of the comparison, the one or more validation measures being implemented at a distributed database.

20. The method of claim 19, wherein the at least one validation measure comprises storing a variable indicative of at least one of the result of the comparison, the first measurement dataset, and the second measurement dataset in the distributed database.

21. The method of claim 4, further comprising: checking the variable by the first measurement device.

22. The method of claim 20, further comprising: checking the variable by the first measurement device.

23. The method of claim 19, wherein the at least one validation measure comprises triggering a settlement process based on a deviation between the first measurement dataset and the second measurement dataset.

24. The method of claim 19, wherein the comparison is based on a predefined agreement indicative of a metric of the comparison.

25. The method of claim 24, wherein the metric is based on at least one of (i) a time-shift between capturing of the at least one first observables and capturing of the at least one second observables, and (ii) a tolerance range between the first measurement dataset and the second measurement dataset.

26. The method of claim 19, wherein the at least one first observables are different from the at least one second observables.

27. A node, comprising: a communication interface; and at least one processor; wherein the at least one processor is configured to: obtain, via the communication interface and from a first measurement device, a first measurement dataset indicative of at least one first observables of an event, obtain, via the communication interface and from a second measurement device, a second measurement dataset indicative of at least one second observables of the event, trigger a comparison between the first measurement dataset and the second measurement dataset, and trigger selectively at least one validation measure for one of the first measurement dataset and the second measurement dataset depending on a result of the comparison, the at least one validation measure being implemented at a distributed database.

28. A measurement device, comprising: a communication interface; and at least one processor; wherein the at least one processor is configured to: obtain, via the communication interface and from a further measurement device, a first measurement dataset indicative of at least one first observables of an event, capture a second measurement dataset indicative of at least one second observables of the event, perform a comparison between the first measurement dataset and the second measurement dataset, and trigger selectively at least one validation measure for one of the first measurement dataset and the second measurement dataset depending on a result of the comparison, the at least one validation measure being implemented at a distributed database.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0066] The invention is described by exemplary embodiments in the accomplished figures in detail, in which:

[0067] FIG. 1 schematically illustrates an exemplary system in accordance with the invention, where the system includes multiple oracles and a blockchain infrastructure;

[0068] FIG. 2 is a flowchart of a method in accordance with an exemplary embodiment of the invention;

[0069] FIG. 3 is a functional flowchart including signaling in accordance with an exemplary embodiment of the invention;

[0070] FIG. 4 is a functional flowchart including signaling in accordance with a further exemplary embodiment of the invention;

[0071] FIG. 5 is a flowchart of a method in accordance with a further exemplary embodiment of the invention;

[0072] FIG. 6 is a functional flowchart including signaling in accordance with a further exemplary embodiment of the invention; and

[0073] FIG. 7 is a functional flowchart including signaling in accordance with an exemplary embodiment of the invention.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

[0074] Some examples of the present disclosure generally provide for a plurality of circuits or other electrical devices. All references to the circuits and other electrical devices and the functionality provided by each are not intended to be limited to encompassing only what is illustrated and described herein. While particular labels may be assigned to the various circuits or other electrical devices disclosed, such labels are not intended to limit the scope of operation for the circuits and the other electrical devices. Such circuits and other electrical devices may be combined with each other and/or separated in any manner based on the particular type of electrical implementation that is desired. It is recognized that any circuit or other electrical device disclosed herein may include any number of microcontrollers, a graphics processor unit (GPU), integrated circuits, memory devices (e.g., FLASH, random access memory (RAM), read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), or other suitable variants thereof), and software which co-act with one another to perform operation (s) disclosed herein. In addition, any one or more of the electrical devices may be configured to execute a program code that is embodied in a non-transitory computer readable medium programmed to perform any number of the functions as disclosed.

[0075] In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are taken to be illustrative only.

[0076] The drawings are to be regarded as being schematic representations and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software, or a combination thereof.

[0077] Hereinafter, techniques are described that facilitate validating measurement datasets provided by oracles. As a general rule, oracles can be implemented by hardware oracles and/or software oracles. A hardware oracle can measure, e.g., using a sensor, one or more physical observables of a physical event. Examples would include measurement of electrical characteristics, e.g., electrical current or electrical voltage, fluid flow or fluid volume, pressure, temperature, operational activity of an industrial machine such as oil change, operating mode, switch on/switch off, etc.; logistics such as dispatch, waypoint passing, delivery, etc. Software oracles can provide measurement data indicative of software-defined events, e.g., website updates, data availability, and/or service downtime.

[0078] Various examples described herein facilitate validating a given measurement dataset based on a consensus between (i) the one or more observables of the given measurement datasets associated with a given event, and (ii) one or more observables of one or more further measurement datasets, also associated with the same given event. Thereby, independent or largely independent information on one and the same event can be obtained and a respective comparison between these measurement datasets can be triggered. Based on the result of the comparison, it would then be possible to trigger or to not trigger (selectively trigger) at least one validation measure for the measurement datasets. These one or more validation measures can be implemented at a distributed database.

[0079] Such techniques are based on the finding that by using independent or largely independent measures for one and the same given event, it becomes possible to identify malfunctioning or fraud associated with an oracle. Thus, the trust level for the measurement datasets can be increased.

[0080] As a general rule, various options are available for implementing the validation measures. To give a few examples, the validation measures can include validating or invalidating the measurement datasets. For example, a variable may be stored in the distributed database, where the variable is indicative of the positive or negative result of the comparison. It would also be possible that the variable is indicative of the underlying measurement datasets, i.e., it would be possible that the measurement datasets are selectively stored in the distributed database, depending on the result of the comparison. Further, in case of lack of consensus, it would be possible to inform involved stakeholders accordingly, i.e., one or more nodes that would rely on the measurement datasets.

[0081] FIG. 1 schematically illustrates a system 70.

[0082] The system 70 includes oracles 101, 102. Each one of the oracles 101, 102 includes a control circuitry 105. For example, the control circuitry 105 could include a processor and a non-volatile memory. The processor could load program code from the non-volatile memory and execute the program code to perform various functionality such as: measuring data for a measurement dataset indicative of one or more physical observables of an event; transmitting the measurement dataset; processing raw data of the measurement dataset; implementing or triggering a comparison between the measurement dataset and further measurement dataset from another oracle, and/or to validate the measurement dataset.

[0083] In further detail, as illustrated in FIG. 1, each one of the oracles 101, 102 includes an input interface 106, e.g., a sensor for a hardware oracle or a communication interface for a software-implemented input interface. The input interfaces 106 of the oracles 101, 102 are configured to measure observables 85, 86 of an event 81.

[0084] As a general rule, the event 81 could be a physical event and the observables 85, 86 could be physical observables. It would also be possible for the event 81 to be a software event, or for the observables 85, 86 to correspond to software observables 85, 86.

[0085] The oracles 101, 102 can provide respective measurement dataset 91, 92 to a network 71. The measurement dataset 91 provided by the oracle 101 is indicative of the observable 85 of the event 81, while the measurement dataset 92 provided by the oracle 102 is indicative of the observable 86 of the event 81. In particular, it would be possible that the observable 85 differs from the observable 86. More generally speaking, different oracles can provide measurement datasets that are indicative of different observables. For example, a first oracle could provide measurement datasets indicative of a temperature, while a second oracle provides measurement datasets indicative of pressure, to give just one example. Thereby, independent information and multiple measures of the event 81 can be obtained. This helps to validate the measurement datasets 91, 92.

[0086] As illustrated, in FIG. 1, the oracles 101, 102 are also directly connected via a backbone communication line 72. This is generally optional. For example, it would be possible that the oracles 101, 102 are arranged next to each other, because they observe the same event 81. For example, the oracle 101 and the oracle 102 may be arranged in the same apparatus or machine. In such scenarios, close-range communication may be used to implement the backbone communication line 72. As a general rule, a data throughput of the backbone communication line 72 may be higher than a data throughput of the communication network 71. As a further general rule, a downtime/service availability may be better for the backbone communication line 72 if compared to the downtime/data availability of the communication network 71.

[0087] Because the network 71 can have a limited data throughput, sometimes it is not feasible to include raw measurement data in the measurement datasets 91, 92. Rather, some data compression or data pre-processing may be implemented at the oracles 101, 102, respectively, before transmitting the measurement datasets 91, 92 towards the communication network 71.

[0088] In the example of FIG. 7, the communication network 71 is also connected to a distributed database infrastructure 150. The distributed database infrastructure 150 includes multiple mining nodes 151, 152, 153 that store and access a distributed database 159. For example, a smart contract 90 may be implemented on the distributed database 159.

[0089] Hereinafter, various examples will be described in connection with an implementation of the distributed database 159 as blockchain. However, in other examples, the distributed database 159 may be implemented in another manner, e.g., by a blockless distributed database, etc.

[0090] Each one of the mining nodes 151, 152, 153 can attempt to store variables as transactions in the blockchain 159. The smart contract 90 can define self-executable program code. To this end, the mining nodes 151, 152, 153 can provide the host environment to execute such program code.

[0091] The system 70 also includes stakeholder nodes 111, 112. Each stakeholder nodes 111, 112 includes a processor 115 that can load and execute program code stored by a respective non-volatile memory 117. The stakeholder nodes 111, 112 are connected to the networks 71 via respective interfaces 116.

[0092] The stakeholder nodes 111, 112 may be operated by an operator that relies on functionality implemented by, e.g., the smart contract 90 of the blockchain 159. Corresponding functionality may rely on the validity of the measurement datasets 92. Therefore, each one of the stakeholder nodes 111, 112 is associated with an operator that has an interest in the validation of the measurement datasets 91, 92.

[0093] In the example of FIG. 1, the system 70 also includes a third-party node 121. For example, the third-party node 121 could implement supervisory control and data acquisition (SCADA) functionality. The third-party node includes, in a manner comparable to the stakeholder nodes 111, 112, a processor 125 that can load and execute program code from a non-volatile memory 127. The third-party node 121 is connected to the network 71 via an interface 126. The third-party node 121 is operated by an operator independent of the operators of the stakeholder nodes 111, 112. Sometimes such an independent operator is referred to as a central authority.

[0094] The inset of FIG. 1 also illustrates details with respect to the mining nodes 151, 152, 153 of the blockchain infrastructure 150 (the inset in FIG. 1 is illustrated with the dashed lines). Each one of the mining nodes 151, 152, 153 includes a processor 155. The processor 155 can load program code from a memory 157 and can execute the program code. The processor 155 can communicate, via an interface 156, e.g., with the network 71. Each one of the mining nodes 151, 152, 153 may store a replica of the blockchain 159.

[0095] Next, details with respect to the functioning of the system 70 will be explained in connection with the following FIGs.

[0096] FIG. 2 is a flowchart of a method in accordance with exemplary embodiments of the invention. The method of FIG. 2 may be executed by the processor 125 of the third-party node 121, upon loading respective program code from the memory 127. It would also be possible for the method of FIG. 2 to be executed by the processor 155 of one of the mining nodes 151, 152, 153, upon loading respective program code from the memory 157.

[0097] At block 5001, a first measurement dataset is obtained. The first measurement dataset is indicative of at least one observables of an event provided by a first oracle. For example, the measurement dataset 91 could be obtained from the oracle 101 and the measurement dataset 91 could be indicative of the physical observable 85 of the event 81 (cf. FIG. 1).

[0098] At block 5002, a second measurement dataset is obtained. The second measurement dataset is indicative of one or more second observables of the event, i.e., the same event for which at block 5001 the first measurement data is obtained. The second measurement data is provided by a second oracle. For example, the measurement dataset 92 could be obtained from the oracle 102, where the measurement dataset 92 is indicative of the observable 86 of the event 81 (cf. FIG. 1).

[0099] Next, at block 5003, a comparison between the first measurement dataset (obtained at block 5001) and the second measurement dataset (obtained at block 5003) is triggered.

[0100] Block 5003 could include sending a trigger or request message to execute the comparison. Block 5003 could also include executing the comparison locally, e.g., at the third-party node 121 or the respective mining node 151, 152, 153. For example, block 5003 could include invoking a corresponding function of a smart contract of a blockchain, e.g., invoking a corresponding function of the smart contract 90 of the blockchain 159 (cf. FIG. 1). In such a scenario, the comparison, in other words, is provided by a smart contract.

[0101] In other examples, the comparison could be implemented locally at the third-party node 121.

[0102] As a general rule, various options are available for implementing the comparison at block 5003. The comparison can vary along with the type of measurement dataset and, more specifically, with the type of observables indicated by the first and second measurement datasets obtained in block 5001 and 5002. To give an example, it would be possible that the comparison is based on a predefined agreement indicative of a metric of the comparison. The metric can define a ruleset for comparing the various involved measurement datasets and the various involved physical observables. In particular, using an appropriate metric, it is even possible to compare different observables, e.g., temperature with pressure, or operational statistics of a field device with current consumption, to give just a few examples. In some examples, the comparison could be implemented by a machine-learning algorithm that is trained to detect abnormalities in the behavior of the multiple physical observables. In other examples, a predefined rule set could be analytically defined.

[0103] For example, a tolerance range could be defined by the metric. The tolerance range may specify certain acceptable ranges of deviation between the first measurement dataset and the second measurement dataset.

[0104] Alternatively or additionally, it would be possible to base the metric on a time shift between capturing of the at least one first observables indicated by the first measurement data and the capturing of the at least one second observables indicated by the second measurement dataset. Such techniques can be based on the finding that an increased time shift can limit the possibility of (cross-) validating the first measurement data and the second measurement data, respectively.

[0105] Next, at block 5004, a result of the comparison is checked. Depending on the result of the comparison, one or more (Positive or negative) validation measures are selectively triggered at block 5005 or 5006, respectively. The at least one validation measure pertains to the first measurement dataset and/or the second measurement dataset. In particular, the at least one validation measure can be implemented at the blockchain, e.g., at the blockchain 159.

[0106] In detail, if at block 5004 it is judged that the comparison yields a positive result, i.e., a (cross-) validation of the first measurement dataset and the second measurement dataset is positively obtained, then a positive validation measured can be taken at block 5005; otherwise, a negative validation measure can be taken at block 5006.

[0107] As a general rule, various options are available for implementing positive and negative validation measures, e.g., in connection with blocks 5005 and 5006. To give just a few examples, a positive validation measure that could be taken as part of executing block 5005 could pertain to storing the first measurement data and/or the second measurement data in the blockchain, e.g., in the blockchain 159. It would also be possible for a flag indicator to be appropriately set, where the flag indicator is stored in the blockchain, e.g., the blockchain 159. The flag indicator could indicate whether a (cross-) validation was successful or not. Yet another validation measure may include transmitting a corresponding report message to at least one of the stakeholder nodes 111, 112. Thereby, parties interested in the validation can be appropriately informed.

[0108] In case the comparison yields a negative result, it would be possible to trigger, as part of execution of block 5006, a settlement process. The settlement process can include a predefined rule set or workflow for the case of a deviation between the first measurement dataset and the second measurement dataset. For example, the settlement could be associated with a trust level of the first oracle providing the first measurement dataset and/or the trust level of the second oracle providing the second measurement dataset. Then, if there are deviations between the first measurement dataset and the second measurement dataset, the particular measurement dataset may prevail that has the larger associated trust level.

[0109] FIG. 3 is an signaling flowchart illustrating the functioning of the system 70. For example, the signaling in accordance with FIG. 3 could implement the method of FIG. 2, in particular when executed by the infrastructure 150.

[0110] At block 3001, the oracle 101 captures the measurement dataset 91 that is indicative of the observable 85 of the event 81.

[0111] As a general rule, measurement datasets as described herein may include a time series of measurement data points. For example, the oracles may sample the events by capturing multiple data points with a certain sampling rate. Some pre-processing of this raw data may occur, when generating the corresponding measurement dataset. For example, filters such as a low-pass filter may be applied. Measurement data points may be integrated.

[0112] At block 3002, the measurement dataset is digitally signed, to generally provide a security protection. For example, this can be implemented using cryptographic keying material associated with the oracle 101. A public-private keying material configuration could be used.

[0113] Blocks 3003 and 3004 respectively corresponding to blocks 3001 and 3002, but for the oracle 102 and the measurement dataset 92.

[0114] Next, the oracle 101 triggers storing the measurement dataset 91 in the blockchain 159. For this, a corresponding request can be transmitted to the blockchain infrastructure 150, e.g., to one or more of the mining nodes 151, 152, 153. One or more of the mining nodes 151, 152, 153 can then create a new block to be changed with pre-existing blocks of the blockchain 159, where the new block includes a variable that includes or is indicative of the measurement dataset 91 (see block 3006). This can include solving a cryptographic puzzle, e.g., proof-of-work or proof-of-stake.

[0115] Blocks 3007 and 3008 respectively correspond to blocks 3005 and 3006, but for the oracle 102 and the measurement dataset 92.

[0116] Next, the comparison between the measurement dataset 91 and the measurement dataset 92 is performed. This includes, at block 3009, the smart contract 90 performing a look-up for the variables associated with the measurement dataset 91 and the measurement dataset 92 and applying a predefined metric 93 thereto. The predefined metric 93 can be obtained through a negotiation at 3010 between the stakeholder nodes 111, 112. The metric 93 defines how the measurement dataset 91 and the measurement dataset 92 are compared and what criteria of consensus of the oracles 101, 102 are.

[0117] Next, at block 3011, the result of the comparison in accordance with block 3009 is checked. Again, this can be functionality that is implemented by the smart contract 90. Block 3011, as such, corresponds to block 5004 (cf. FIG. 2).

[0118] In case of a positive result of the comparison, i.e., consensus between the oracles 101, 102, a corresponding variable 95 is written to the blockchain 159, at block 3012. This variable 95 is indicative of the consensus, i.e., the positive result of the comparison. Otherwise, at block 3013, a corresponding variable 96 indicative of the lack of consensus is written to the blockchain 159.

[0119] In block 3014, a warning or notification can be triggered, as a settlement process. The warning is issued to the stakeholder nodes 111, 112.

[0120] The various blocks 3001-3013 that have been explained so far correspond to a capturing phase 6000 and a validation phase 6001. During the capturing phase 6000, the measurement datasets 91, 92 are captured at the oracles 101, 102. During the validation phase 6001, a check can be performed to determine whether consensus exists between the measurement datasets 91, 92 provided by the oracles 101, 102.

[0121] As will be appreciated, in the scenario of FIG. 3 it is possible to implement the validation phase 6001 in a close temporal relationship with the capturing phase 6000 of the measurement datasets 91, 92. This has the advantage that unvalidated measurement datasets 91, 92 can timely be identified. The trust level of the various entries in the blockchain 159 can be high. For example, in case a lack of consensus is identified timely after capturing the measurement datasets 91, 92, various counter-measures may be available to the settlement process (that may not be available if the lack of consensus is only identified later). For example, an alternative oracle may be deployed. For example, a measurement dataset may be re-captured. For example, maintenance of the oracles 101, 102 may be triggered.

[0122] FIG. 3 also illustrates aspects with respect to an application phase 6002 in which the measurement datasets 91, 92 are used for further processing. Here, the various measurement datasets 91, 92 can be retrieved from the blockchain 159. It is then possible to implement certain functionality based on the measurement datasets 91, 92 at blocks 3015 and 3016, at the stakeholder nodes 111, 112. Each stakeholder associated with a stakeholder node 111, 112 can trust in the correctness of the measurement datasets 91, 92 for executing the respective functionality at blocks 3015, 3016, respectively, because of the validation during the validation phase 6001.

[0123] FIG. 4 is a functional flowchart illustrating details with respect to the functioning of the system 70 of FIG. 1. For example, the signaling in accordance with the example of FIG. 4 could implement the method as described in connection with FIG. 2, in particular when executed by the third-party node 121.

[0124] The example of FIG. 4 generally corresponds to the example of FIG. 3. However, in the example of FIG. 4, the comparison is not implemented by the blockchain infrastructure 150, but is rather implemented by the third-party node 121.

[0125] In FIG. 4, blocks 3101 and 3102 correspond to blocks 3001 and 3002 according to FIG. 3, respectively. Furthermore, blocks 3103 and 3104 correspond to blocks 3003 and 3004 according to FIG. 3.

[0126] At block 3105, the oracle 101 provides the measurement dataset 91 to the third-party node 121. At 3107, the oracle 102 provides the measurement dataset 92 to the third-party node 121.

[0127] Next, at block 3109, the third-party node 121 implements the comparison between the measurement dataset 91 and the measurement dataset 92. Again, this is based on the metric 93 obtained from a corresponding agreement 3110.

[0128] At block 3111, the result of the comparison is checked. Depending on the result, at least one validation measure is taken. In particular, block 3112 corresponds to block 3012 according to FIG. 3, block 3113 corresponds to block 3013 according to FIG. 3, and block 3114 corresponds to block 3014 according to FIG. 3.

[0129] In the example of FIG. 4, the application phase 6002 corresponds to the application phase 6002 of the example of FIG. 3.

[0130] FIG. 5 is a flowchart of a method in accordance with an exemplary embodiment. For example, the method of FIG. 5 could be executed by the control circuitry 105 of the oracle 102, e.g., upon loading program code from an associated memory.

[0131] At block 5011, second sensor data is captured. This can include obtaining a readout of a corresponding sensor, e.g., sensor 106 of the oracle 102 (cf. FIG. 1). For example, block 5011 can include sampling a corresponding physical observable at a sampling rate.

[0132] At block 5012, a first measurement dataset is obtained. For example, the measurement dataset 91 may be obtained from the oracle 101.

[0133] Next, at block 5013, a comparison is implemented between the first measurement dataset (obtained at block 5012) and the second measurement dataset (captured at block 5011). Block 5013 as such corresponds to block 5003. In the example of FIG. 5, however, the comparison can be implemented locally at the respective oracle.

[0134] At block 5014, the result of the comparison is checked. Block 5014 corresponds to block 5004. Depending on the result of the comparison, one or more validation measures are taken.

[0135] Here, blocks 5015, 5016 respectively correspond to blocks 5005, 5006.

[0136] The scenario of FIG. 5 allows implementation of the comparison between the measurement datasets at a low level, i.e., in the signal processing chain close to the data source such as the sensor 106 of the respective oracle 101, 102 (cf. FIG. 1). This can have multiple advantages. Firstly, it would be possible to implement the comparison based on the measurement datasets including raw data points that have not been significantly pre-processed or compressed. For example, a high temporal resolution, without down sampling or low-pass filtering may be subject to the comparison. For example, it may not be required to implement significant analysis to the raw measurement data points, i.e., it may not be required to perform analysis such as object detection, feature detection, and/or down sampling, before implementing the comparison. The reason is that a high throughput, high-availability data communication link can exist between the multiple oracles (cf. FIG. 1: backbone communication line 72). A second advantage lies in the close temporal relationship between the capturing of the measurement datasets, e.g., at block 5011, and the implementation of the comparison. This limits possible attack vectors: the time window available for manipulation of the measurement datasets is limited if compared to other scenarios in which the measurement datasets are compared by another node (e.g., by a mining node 151, 152, 153 of the blockchain infrastructure 150, such as explained in connection with FIG. 3; or a third-party node 121, as explained in connection with FIG. 4). This low-latency comparison can also be helpful in scenarios in which a service availability between the oracles and the respective nodes implementing the comparison (cf. FIG. 1: network 71) is significant; in such scenarios, a buffering of the measurement datasets at the oracles may be required and the comparison can be delayed which opens the attack vectors.

[0137] FIG. 6 is a functional flowchart illustrating details with respect to the functioning of the system 70 (cf. FIG. 1). For example, the signaling as illustrated in FIG. 6 could be used to implement the method of FIG. 5.

[0138] At block 3201 the measurement dataset 91 is captured. At block 3202, the measurement dataset 91 is signed. Blocks 3201, 3202 thus corresponds to blocks 3001, 3002, respectively (cf. FIG. 3).

[0139] At block 3205, the oracle 101 provides the measurement dataset 91 to the oracle 102, e.g., via the backbone communication line 72.

[0140] At block 3203, the measurement dataset 92 is captured at the oracle 102. Block 3203 thus corresponds to block 3003 (cf. FIG. 3).

[0141] At block 3209, the comparison between the measurement dataset 91 and the measurement dataset 92 is performed at the oracle 102. Block 3209 thus corresponds to block 3009 (cf. FIG. 3).

[0142] At block 3211, a result of the comparison is checked and, depending on the result, at least one validation measure is selectively triggered.

[0143] In the example of FIG. 6, in case of a positive result of the comparison 3211, i.e., consensus between the oracles 101, 102, the measurement dataset 91 (and, optionally, the measurement dataset 92) is stored in the blockchain 159, block 3206. Optionally, the measurement dataset 92 may be previously signed, at block 3204. As such, block 3204 corresponds to block 3004 (cf. FIG. 3).

[0144] To store the measurement dataset 91 (and optionally the measurement dataset 92), the oracle 102 provides the measurement dataset 91 (and, optionally, the measurement dataset 92) to the blockchain infrastructure 150 and the mining nodes 151, 152, 153 can chain a new block including a variable indicative of the measurement dataset 91 (and, optionally, the measurement dataset 92). As such, the storing of the variable indicative of the measurement dataset 91 in the blockchain 159 at block 3206 corresponds to a validation measure taken in case of a positive result of the comparison. As a general rule, it would be possible, alternatively or additionally to storing the variable indicative of the measurement dataset 91, to store a variable indicative of the measurement dataset 92 and/or a variable indicative of the result of the comparison, e.g., a flag (cf. FIG. 3: blocks 3012, 3013).

[0145] Next, at block 3220, the oracle 101 checks the variable in the blockchain 159. For example, the execution of block 3220 can be triggered by providing the measurement dataset 91 at 3205 to the oracle 102. Alternatively or additionally, block 3220 could be triggered by storing the measurement dataset 91 in the blockchain 159 at block 3206. For example, the smart contract 90 may transmit a respective notification to the oracle 101.

[0146] Block 3220, i.e., the check implemented by the oracle 101, provides for a measure to verify whether consensus has been validated. If the check at block 3220 yields a negative result, the oracle 101 can trigger a settlement process as block 3214. Block 3214 corresponds to block 3014 (cf. FIG. 3).

[0147] The application phase 6002 of the example of FIG. 6 corresponds to the application phase 6002 of FIG. 3.

[0148] Summarizing, above, techniques have been described that enable validation of the consensus between multiple oracles, e.g., between the oracles 101 and 102 according to the system 70 of FIG. 1. The consensus can be validated by implementing a comparison between respective measurement datasets. As herein described, in accordance with to the disclosed multiple options are available for implementing the comparison. In particular, the node and/or a point in time at which the comparison is implemented can vary from option to option. For example, a comparison can be implemented at the oracles (cf. FIG. 6), thereby facilitating a low-level comparison of raw measurement data points and in a close temporal context with the capturing of the measurement data points. It would also be possible to implement the comparison at a central authority that is independently operated from the stakeholders of any application implemented based on the measurement datasets, e.g., using a third-party node (cf. FIG. 4) or a smart contract implemented in the blockchain (cf. FIG. 3).

[0149] As a general rule, the techniques described herein may find application in various use-case scenarios. To give a few examples: it would be possible to implement pay-per-use scenarios in electrical power grids. Here, a first oracle may capture measurement datasets indicative of electrical characteristics such as electrical current or electrical voltage of an electrical load, e.g., a pump, connected to the electrical power grid. A second oracle may capture a measurement dataset indicative of another physical observable, e.g., operational characteristics of the load, in the scenario of the pump e.g. flow rate. Thus, multiple independent physical observables of one and the same event, here, operation of the pump, can be obtained. The stakeholders can be associated with the operator of the pump, i.e., the consumer, and the operator of the power grid, i.e., the service provider. Both can have an interest in accurate determination of the electrical power consumption of the pump.

[0150] Another use case relates to lifecycle monitoring of an industrial field device, e.g., to determine warranty claims, second-life applications, residual value, and/or leasing or rent royalties. Here, the event can be an oil change at the industrial field device. A first oracle can capture measurement datasets indicative of a user input to a human machine interface of the industrial field device, e.g., pertaining to activation of a service mode associated with the oil change. This would be a software oracle. A second hardware oracle could capture measurement datasets that are indicative of a switch activation at the cover lid of the oil tank of the industrial field device. The comparison can then be based on a plausibility analysis between both measurement datasets. A further measurement dataset associated with a further physical observable could relate to the current consumption of the industrial field device, because it can be expected that the load imposed by the industrial field device is reduced in response to the oil change.

[0151] A third use case pertains to tracking of shipping of goods. Here, a first oracle could capture measurement data that is indicative of a first radio frequency identity tag readout at dispatch, while a second oracle could capture a measurement dataset that is indicative of radio frequency identity tag readout at arrival.

[0152] For illustration, above, various scenarios have been described in which the comparison is implemented in the validation phase 6001 prior to the application phase 6002. However, in various exemplary embodiments, it would be possible to co-implement the validation phase 6001 and the application phase 6002, cf. FIG. 7. In FIG. 7, a separate capturing phase 6000 is defined in which the measurement datasets 91, 92 are captured by the oracles 101, 102 and respectively written to the blockchain 159. In FIG. 7, blocks 3301-3308 correspond to blocks 3001-3008 (cf. FIG. 3), respectively.

[0153] In the scenario of FIG. 7, the comparison could be co-implemented with the functionality at block 3015 and/or block 3016, i.e., as additional blocks 3351 and/or 3352. Then, depending on a check of the result of these comparisons at blocks 3353 and/or 3355, a respective settlement process may be triggered at block 3354, as a validation measure.

[0154] For further illustration, various examples have been described above in connection with an implementation of the blockchain as the blockchain 159. Similar techniques may be readily applied for other kinds and types of blockchains.

[0155] Furthermore, various examples have been described in which separate mining nodes 151, 152, 153 of the blockchain infrastructure 150 are available to store datasets or data in the blockchain 159. In other examples, it would be possible that the oracles 101, 102 also implement mining functionality, i.e., can directly store the datasets or data into the blockchain 159.

[0156] Thus, while there have been shown, described and pointed out fundamental novel features of the invention as applied to a preferred embodiment thereof, it will be understood that various omissions and substitutions and changes in the form and details of the methods described and the devices illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit of the invention. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Moreover, it should be recognized that structures and/or elements and/or method steps shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.