Device, method and system for collecting immutable and trusted pump data

Abstract

The present disclosure relates to pump systems. This disclosure proposes a controller for a pump. The controller is configured to collect operational data related to the pump; send a first data packet comprising the operational data to a server; determine a hash value of the collected operational data; and send a second data packet comprising the hash value to a distributed ledger technology (DLT) network. For validating the stored operational data, the server is configured to obtain, from the DLT network, a first hash value corresponding to the stored operational data, and determine a second hash value of the stored operational data. Then, based on a comparison of the first hash value and the second hash value, the stored operational data can be validated (or authenticated) by the server. In this way, an immutable and trusted pump data storage can be achieved.

Description

[0001] DEVICE, METHOD AND SYSTEM FOR COLLECTING IMMUTABLE AND TRUSTED PUMP DATA

[0002] TECHNICAL FIELD

[0003] This disclosure relates generally to the field of industrial equipment management, for example, management of a pump. For instance, this disclosure provides devices, methods and a system for collecting immutable and trusted pump data.

[0004] BACKGROUND

[0005] Industrial pumps play a vital role in effectively transporting fluids across various processes and applications. In traditional pump systems, gathering and storing pump operational data is essential for providing, maintaining and managing pump operations.

[0006] Typically, the pump operational data is sent to a centralized server. Access to this data is granted to the pump owner, the pump operator, or any authorized third party who requires it for various purposes.

[0007] SUMMARY

[0008] The conventional way of collecting, managing, and storing pump operational data often present several challenges. For instance, the integrity and trustworthiness of the stored operational data can sometimes be questioned due to potential data manipulation and / or data hack. This lack of transparency and trust can hinder the effective management of pump operations, for instance, when the operational data is used for billing, regulatory compliance, maintenance decisions, or performance optimization.

[0009] In view of the above-discussed challenges, this disclosure aims to introduce a solution to ensure that pump operational data can be stored in an immutable and trusted manner, ensuring its integrity. Another objective may be to allow any third party and / or a server to be able to verify any pump operational data stored on the server. These and other objectives are achieved by solutions of this disclosure as described in the independent claims. Advantageous implementations are further defined in the dependent claims.

[0010] A first aspect of this disclosure provides a controller for a pump. The controller is configured to: collect operational data related to the pump; send a first data packet comprising the operational data to a server; determine a hash value of the collected operational data; and send a second data packet comprising the hash value to a distributed ledger technology (DLT) network.

[0011] The pump maybe a centrifugal pump. The pump maybe a fluid pump or a liquid pump, for example, a water pump. Optionally, the pump may be associated with the DLT network. The DLT network may also be referred to as a DLT platform.

[0012] By storing the hash value in the DLT network, the hash value is immutable and trusted. The pump operational data stored on the server can be verified using the hash value stored in the DLT network.

[0013] In an implementation form of the first aspect, the operational data may comprise one or more of: vibration data, pressure data, temperature data, flow rate data, power consumption data, and revolutions-per-minute (RPM) data, operation time, volume flow, event data, respectively, of the pump.

[0014] Optionally, the operational data may comprise processed data, such as summed or averaged data. For instance, vibration, pressure, flow rate, RPM, temperature data may be averaged. Power consumption, operation time, volume flow data maybe summed.

[0015] Optionally, the operational data maybe collected and sent in an event-driven manner, and / or periodically, and / or in response to a request (e.g., from the server), and / or manually (e.g., triggered by a pump operator). In a further implementation form of the first aspect, the first data packet and the second data packet each may further comprise an identification of the pump and / or a timestamp of the operational data.

[0016] Optionally, the identification of the pump and the timestamp of the operational data may be used by the server (e.g., as an index) to obtain a hash value of the respective operational data.

[0017] In a further implementation form of the first aspect, the controller may be configured to send the first data packet and the second data packet periodically.

[0018] Alternatively, the first data packet and the second data packet maybe sent in an event- driven manner.

[0019] In a further implementation form of the first aspect, the controller may be further configured to store a public-private key pair for authenticating the pump on the DLT network.

[0020] In a further implementation form of the first aspect, the public-private key pair maybe associated with a fund account on the DLT network.

[0021] In a further implementation form of the first aspect, the identification of the pump comprises a first part identifying the pump and a second part identifying one or more components of the pump.

[0022] It is noted that the first part is able to uniquely identify the pump as a whole (or as a single entity). The first part may remain fixed during the lifecycle of the pump. For instance, the first part may be generated during manufacturing of the pump and may be a random serial number (or any other serial number selected according to a pattern and / or algorithm). The second part is able to uniquely identify the one or more components of the pump - for example, may identify each individual component of the one or more components - and may be generated based on respective component identifier(s) of the pump component(s). The second part may be dynamic during the lifecycle of the pump, i.e., it may change. For instance, the second part maybe derived from the configuration and / or composition of the pump, such as its Bill of Materials (BOM).

[0023] The identification of the pump, which comprises both the first and second parts, can be included in each data packet transmitted from the pump to the server and the DLT network. This allows each data entry to be cryptographically linked not only to the physical pump, but also to its current component configuration. Based on the first part of the identification of the pump, the pump can be uniquely identified. Based on the second part of the identification of the pump, each component of the pump can be traced. For instance, any third party, such as systems, administrators external to the pump, can verify the operational data against the specific state (e.g. component configuration) of the pump at the time the operational data was recorded.

[0024] In a further implementation form of the first aspect, the controller is configured to generate the second part of the identification of the pump by hashing or concatenating one or more identifiers associated with the one or more components of the pump.

[0025] For instance, the second part maybe generated by using a hashing function (e.g., SHA- 256) on component identifier(s) of pump component(s) to create a fixed-length, integrity-protected signature representing a current component configuration of the pump. Alternatively, component identifiers of pump components can be concatenated to generate the second part of the identification of the pump. How the second part is generated shall not be limited in the present disclosure, as long as it can be used to identify the one or more components of the pump.

[0026] In a further implementation form of the first aspect, if at least one of the one or more components of the pump is changed, the controller is configured to modify the identification of the pump by modifying only the second part of the identification of the pump based on the at least one changed component.

[0027] It is noted that the first part of the identification of the pump may remain unchanged. The updated identification of the pump can be transmitted to the server and / or DLT network. A second aspect of this disclosure provides a pump. The pump comprises the controller according to the first aspect or any implementation form thereof.

[0028] Optionally, the controller maybe an internal module of the pump, i.e., the controller is integrated into the pump. Alternatively, the controller may be an external module attached to the pump, wherein the controller may be operatively connected to the pump so as to control the pump.

[0029] A third aspect of this disclosure provides a server. The server is configured to: receive, from a controller of a pump (or from a pump), a data packet comprising operational data of the pump; store the operational data in a storage unit; obtain, from a DLT network associated with the pump, a first hash value corresponding to the operational data; determine a second hash value of the operational data stored in the storage unit; and validate the operational data stored in the storage unit by comparing the first hash value and the second hash value.

[0030] Optionally, the data packet received from the controller may further comprise an identification of the pump (also referred to as pump ID) and / or a timestamp of the operational pump data.

[0031] Optionally, the operational data may be stored using a database.

[0032] In an implementation form of the third aspect, the server maybe further configured to send software information of the pump to the DLT network.

[0033] Optionally, the operational data may be indexed using the pump ID and / or the timestamp and / or the software information. Alternatively, any other information that can uniquely identify the operational data can be used as an index, such as a motor ID, or an electronic ID, or a MAC address of the pump, and so on. A fourth aspect of this disclosure provides a system. The system comprises the controller and the pump according to the first aspect and the second aspect, and the server according to the third aspect or its implementation form.

[0034] For instance, when the controller is comprised in the pump, the system comprises the pump and the server. When the controller is an external device attached to the pump, the system comprises the pump, the controller, and the server.

[0035] In an implementation form of the fourth aspect, the system may comprise multiple pumps (associated with multiple respective controllers) and one or more DLT networks. Each respective pump (and each respective controller) is associated with a respective DLT network. Each respective DLT network is configured to: receive, from the respective pump associated with the DLT network, a data packet comprising a hash value of operational data of the respective pump; and create a new block for storing the hash value of the operational data of the respective pump in the network.

[0036] In a further implementation form of the fourth aspect, for creating the new block for storing the hash value of the operational data of the respective pump in the network, the respective DLT network maybe configured to: broadcast a transaction about creating the new block in the respective DLT network; employ a consensus mechanism to validate the transaction; and create the new block to store the broadcast hash value when consensus is reached in the respective DLT network.

[0037] A fifth aspect of this disclosure provides a method applied to a controller for a pump. The method comprises the following steps: collecting operational data related to the pump; sending a first data packet comprising the operational data to a server; determining a hash value of the collected operational data; and sending a second data packet comprising the hash value to a distributed DLT network. In an implementation form of the fifth aspect, the operational data may comprise one or more of: vibration data, pressure data, temperature data, flow rate data, power consumption data, and revolutions-per-minute data, respectively, of the pump.

[0038] In a further implementation form of the fifth aspect, the first data packet and the second data packet each may further comprise an identification of the pump and / or a timestamp of the operational data.

[0039] In a further implementation form of the fifth aspect, the first data packet and the second data packet may be sent periodically.

[0040] In a further implementation form of the fifth aspect, the method may comprise storing a public-private key pair for authenticating the pump on the DLT network.

[0041] In a further implementation form of the fifth aspect, the public-private key pair may be associated with a fund account on the DLT network.

[0042] A sixth aspect of this disclosure provides a method applied to a server. The method comprises the following steps: receiving, from a controller of a pump (or from a pump), a data packet comprising operational data of the pump; storing the operational data in a storage unit; obtaining, from a DLT network associated with the pump, a first hash value corresponding to the operational data; determining a second hash value of the operational data stored in the storage unit; and validating the operational data stored in the storage unit by comparing the first hash value and the second hash value.

[0043] In an implementation form of the sixth aspect, the method may further comprise sending software information of the pump to the DLT network.

[0044] A seventh aspect of this disclosure provide a method comprising the following steps: collecting, by a controller of a pump, operational data related to the pump; sending, by the controller, a first data packet comprising the operational data to a server; receiving, by the server, the first data packet from the pump; storing, by the server, the operational data in a storage unit; determining, by the pump, a hash value of the collected operational data; sending, by the pump, a second data packet comprising the hash value to a distributed ledger technology, DLT, network; obtaining, by the server, the hash value from the DLT network as a first hash value; determining, by the server, a second hash value of the operational data stored in the storage unit; and validating, by the server, the operational data stored in the storage unit by comparing the first hash value and the second hash value.

[0045] An eighth aspect of this disclosure provides a computer program product comprising instructions which, when the program is executed by a first computer, cause the first computer to perform the method of the fifth aspect.

[0046] A ninth aspect of this disclosure provides a computer program product comprising instructions which, when the program is executed by a second computer, cause the second computer to perform the method of the sixth aspect.

[0047] A tenth aspect of this disclosure provide a computer program product comprising instructions which, when the program is executed by a server, a pump and a distributed ledger technology, DLT, network, causes the server, the pump and the DLT network to perform the method of the seventh aspect.

[0048] All steps that are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity that performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements or any kind of combination thereof.

[0049] BRIEF DESCRIPTION OF DRAWINGS

[0050] The above-described aspects and optional implementations will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

[0051] FIG. 1 shows a controller, a pump, and a server according to this disclosure;

[0052] FIG. 2 shows an example of a system according to this disclosure;

[0053] FIG. 3 shows a flowchart of a method applied to a controller for a pump according to this disclosure;

[0054] FIG. 4 shows a flowchart of a method applied to a server according to this disclosure;

[0055] FIG. 5 shows a flow chart of a method according to this disclosure;

[0056] FIG. 6 shows an exemplary flowchart of setting up a pump as a trusted meter;

[0057] FIG. 7 shows an exemplary flowchart of account creation;

[0058] FIG. 8 shows an exemplary flowchart of non-fungible token (NFT) contract generation; and

[0059] FIG. 9 shows an exemplary flowchart of data capture and process.

[0060] DETAILED DESCRIPTION OF EMBODIMENTS

[0061] Illustrative embodiments of a controller for a pump, a pump, and a system are described with reference to the figures. Although this description provides a detailed example of possible embodiments and implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0062] In this disclosure, an embodiment / example may refer to other embodiments / examples. For example, any description including but not limited to terminology, element, process, explanation, and / or technical advantage mentioned in one embodiment / example is applicable to the other embodiments / examples. The same elements are labeled with the same reference signs and may function similarly or likewise.

[0063] FIG. i shows a controller in for a pump no, the pump no, and a server 120, according to this disclosure.

[0064] The pump 110 of this disclosure is associated with a respective DLT network 130. This association may be preset (e.g., during manufacture of the pump 110), or may be configurable (e.g., during or after deployment of the pump 110).

[0065] The controller 111 is configured to collect operational data related to the pump 110, and send a first data packet 101 comprising the operational data to the server 120 (e.g., wirelessly). Further, the controller 111 is configured to determine a hash value of the collected operational data, and send a second data packet 102 comprising the hash value to the respective DLT network 130.

[0066] The controller 111 may be a unit, such as a module or the like, of the pump no. Optionally, the controller 111 may be an internal module of the pump. Alternatively, the controller 111 maybe an external module attached to the pump. This is not limited in this disclosure. The controller may be a microcontroller. The controller may comprise one or more processors or processing circuitry.

[0067] Optionally, the controller 111 may comprise such a processor (not shown) configured to execute a hashing function to generate the hash value of the operational data. The manner in which the hashing function is implemented is not limited. For instance, the hashing function maybe based on Secure Hash Algorithm (SHA), a MD5 algorithm, or a quantum -resistant cryptographic algorithm. For example, the SHA may be based on SHA-1, SHA-2, or SHA-3 (e.g., Keccak-256).

[0068] The server 120 is configured to receive the operational data of the pump no through the first data packet 101 (e.g., included in a wirelessly transmitted message), and store the operational data in a storage unit 121. The server 120 may be cloud-based or provide a cloud, into which the first data packet 101 is uploaded by the pump 110. Optionally, the stored operational data may be associated with an ID of the pump, and / or a timestamp of the operational data, and / or a software version of the pump. Optionally, the storage unit 121 may be an internal unit comprised in the server 120. Alternatively, the storage unit 121 maybe an external storage apparatus that the server 120 has access to. This is not limited in this disclosure. The storage unit 121 maybe any suitable memory or storage device. Optionally, the operational data maybe stored in a database of the storage unit 121.

[0069] There maybe various ways to collect and store the operational data. For instance, one possible way is to save all data and at regular intervals store all data in one entry of the storage unit. It is also possible to save, for instance, an average value of the data (e.g., pressure or temperature of the pump) in a predetermined time interval; or a summed values (operation time or volume of water). The operational data may comprise event data, such as a detection of a water hammer. Optionally, the collection and storage of the operational data maybe event driven.

[0070] To authenticate the operational data, the server 120 is configured to obtain, from the respective DLT network 130 associated with the pump no, a first hash value 104 corresponding to the operational data, and determine a second hash value of the operational data stored in the storage unit. The server 120 is then configured to validate the operational data stored in the storage unit 121 by comparing the first hash value and the second hash value.

[0071] Optionally, the authentication of the operational data may be trigged by a request received by the server 120. For instance, the request maybe sent by a third party to the server 120 to generate a report comprising information related to the operational data of the pump. For another example, the request maybe an audit request. Accordingly, the server 120 is adapted to verify the validity of the operational data stored in the storage unit 121 against the hash value stored in the DLT network 130. For instance, the server 120 may be configured to obtain, from the DLT network 130, the hashed operational data associated with the pump no (e.g., via a blockchain explorer,), and cross-validate the hashed operational data by hashing the un-hashed operational data stored in the storage unit 121.

[0072] Optionally, the server 120 maybe configured to send a third data packet 103 to the DLT network 130. The third data packet 103 comprises a software version associated with the controller 111 and / or the pump no. Optionally, the server 120 maybe configured to transmit the third data packet 103 in response to any software update of the controller 111 and / or the pump 110.

[0073] According to this disclosure, the distributed ledger technology (DLT) is used to record hash value of the operational data in a tamper-resistant manner, ensuring data integrity from the point of collection to the point of use. This approach may not only enhance the security and transparency of the data but also facilitate data validation and verification, which may be needed for regulatory compliance and operational audits.

[0074] Further optional features relating to the controller 111, the pump no, and the server 120 are given in the following.

[0075] Optionally, the server 120 maybe implemented as a conventional computer server. The server may be operated by a service provider of the pump no as a smart meter. The server 100 may comprise a communication interface (not shown), to allow communication with the pump 110 via a communication network (not shown).

[0076] Optionally, the pump 110 may be associated with a unique ID. How the unique ID is generated is not limited in this disclosure. In some embodiments, the unique ID may be generated by the server 100 before installation (i.e. during or after manufacture). The unique ID may be stored in the controller 111 of the pump no. In some embodiments, the pump 110 may comprise a memory (not shown) and a processor (not shown), which are be hosted on the controller 111. The pump 110 may be configured to collect, store and process data associated with the operation of the pump no. For example, the operational data may include, but not limited to one or more of: vibration data, pressure data, temperature data, flow rate data, power consumption data, RPM data of the pump.

[0077] Optionally, the first data packet 101 may further comprise the ID of the pump, and / or a timestamp of the operational data. For instance, the first data packet 101 may be: [operational data, (optional) pump ID, (optional) timestamp]. Similarly, the second data packet 102 may further comprise the ID of the pump, and / or the timestamp of the operational data. For instance, the second data packet 102 maybe: [hash(operational data), (optional) pump ID, (optional) timestamp]. Optionally, the timestamp may be indicative of a data and time, or a time period associated with the operational data. Optionally, the first data packet 101 and the second data packet 102 may be sent periodically (e.g., per hour, per day, per week, etc.). Optionally, at least the pump ID maybe used by the server 120 to obtain the hash value of the operational data from the DLT network 130. When there are multiple hash values of multiple pieces of operational data of the pump 120 exists in the DLT network 130, the timestamp and / or the software version may be further used to obtain a desired hash value.

[0078] Optionally, the controller no or the pump no may be further configured to store a public-private key pair for authenticating the pump on the DLT network. Optionally, the public-private key pair is associated with a fund account on the DLT network.

[0079] In a preferred embodiment, the DLT network 130 may be any public DLT network, such as a blockchain network (e.g., an Ethereum network and the like). Alternatively, it is also possible that the DLT network 130 maybe a private DLT network. How a DLT is implemented is generally known in the art, therefore is not described in more detail herein.

[0080] Optionally, in response to receiving the first data packet 101 and optionally the third data packet 103, the DLT network 130 may be configured to create a block for storing the following information in the DLT network 130: pump ID, hash value of the operational data; timestamp; and software version. By storing the hashed operational data on the DLT network 130, immutability of the operational data is enabled. Further, privacy of the operational data is ensured by storing the hash value of the operational data, not the operational data itself.

[0081] Optionally, for creating the block, the DLT network 130 maybe configured to broadcast a transaction about creating the block (i.e., the transaction that the block is to be created) in the DLT network; and employ a consensus mechanism to validate the transaction. When consensus is reached in the DLT network, the block is created to store the hash value (and any other optional data, e.g., pump ID, timestamp, software version).

[0082] Notably, the pump no discussed in this disclosure maybe a smart pump, e.g., a pump integrated with processing capabilities, sensors, software, and connectivity features that is able to send hashed operational data to the DLT network. The pump 110 discussed in this disclosure maybe a centrifugal pump.

[0083] The pump ID may comprise a first part identifying the pump and a second part identifying one or more components of the pump. The first part uniquely identifies the pump as a whole (distinguishes it from other pumps). The second part uniquely identifies the one or more components of the pump. The second part maybe generated by hashing one or more component identifiers associated with the one or more components of the pump.

[0084] In case that at least one of the one or more components of the pump is changed, the controller is configured to modify the identification of the pump by modifying only the second part of the identification of the pump based on the at least one changed component.

[0085] For instance, if one or more components (e.g., an impeller, sensor, or the like) of the pump are replaced during maintenance, the second part of the pump ID is updated using identification(s) associated with the replaced component(s). The first part of the pump ID remains unchanged, ensuring traceability to the original pump assembly. This approach enables lifecycle tracking of the pump through its operational lifetime. Optionally, previous version(s) of the pump ID maybe stored locally and / or remotely, enabling a historical view of component changes. This allows for enhanced analytics, auditing, and compliance tracking in regulated environments.

[0086] FIG. 2 shows an example of a system 200 according to this disclosure. The system 200 comprises one or more pumps 210-1, 210-2, and a server 220. Each respective pump 210-1, 210-2 is associated with a respective DLT network 230-1, 230-2.

[0087] Optionally, an association between a pump 210 and a respective DLT network 230 (or an address of the respective DLT network 230) maybe preset, e.g., during manufacture or initialization. Additionally or alternatively, the association maybe configurable, e.g., during pump deployment or during pump operation.

[0088] For instance, a pump 210 may be associated with a default DLT network 230 (e.g., during production or upon activation). When a pumper installer installs the pump 210, the pump 210 is connected to the server 220 and the corresponding DLT network 230. Optionally, if the pump 210 is assigned to a different user / location, the pump 210 may be assigned with a different DLT network (by the server 220, the pump installer, or the (new) pump user). In any case, the new association is notified to the server.

[0089] Optionally, a pump user or a pump installer may have access to set or modify to which DLT network the pump (or the pump controller) sends the second data packet. The server may also be configured to assign a DLT network to a respective pump. In any case, the association between a pump and a respective DLT network is known by the server. For instance, if the association is preset or configured by the server, it may be logged in the server. If the association is updated or modified, the pump (or its controller) may be adapted to notify the server about the updated or modified association.

[0090] Each pump 210-1, 210-2 and the server 220 of FIG. 2 maybe built based on the pump no, and the server 120 of FIG. 1, respectively. The controller is not shown in FIG. 2 for the sake of simplicity. FIG. 3 shows a flowchart of a method 300 applied to a controller for a pump according to this disclosure. The method 300 comprises the following steps:

[0091] Step 301: collecting operational data related to the pump;

[0092] Step 302: sending a first data packet comprising the operational data to a server;

[0093] Step 303: determining a hash value of the collected operational data; and

[0094] Step 304: sending a second data packet comprising the hash value to a DLT network.

[0095] It is noted that the method 300 may also be applied to a pump no, 210 comprising the controller 111.

[0096] The method 300 may share the same optional features of the controller 111 and / or the pump 110 introduced above in FIG. 1, which are not repeated herein.

[0097] FIG. 4 shows a flowchart of a method 400 applied to a server according to this disclosure. The method 400 comprises the following steps:

[0098] Step 401: receiving, from a controller of a pump, a data packet comprising operational data of the pump;

[0099] Step 402: storing the data packet in a storage unit;

[0100] Step 403: obtaining, from a DLT network associated with the pump, a first hash value corresponding to the operational data;

[0101] Step 404: determining a second hash value of the operational data stored in the storage unit; and

[0102] Step 405: validating the operational data stored in the storage unit by comparing the first hash value and the second hash value.

[0103] The method 400 may share the same optional features of the server 120 introduced above in FIG. 1, which are not repeated herein.

[0104] FIG. 5 shows a method 500 according to this disclosure. The method 500 comprises the following steps:

[0105] Step 501: collecting, by a controller of a pump, operational data related to the pump;

[0106] Step 502: sending, by the controller, a first data packet comprising the operational data to a server;

[0107] Step 503: receiving, by the server, the first data packet from the pump; Step 504: storing, by the server, the operational data in a storage unit;

[0108] Step 505: determining, by the pump, a hash value of the collected operational data;

[0109] Step 506: sending, by the pump, a second data packet comprising the hash value to a distributed ledger technology, DLT, network;

[0110] Step 507: obtaining, by the server, the hash value from the DLT network as a first hash value;

[0111] Step 508: determining, by the server, a second hash value of the operational data stored in the storage unit; and

[0112] Step 509: validating, by the server, the operational data stored in the storage unit by comparing the first hash value and the second hash value.

[0113] The method 500 may share the same optional features of the controller 111, the pump no, the server 120, and the DLT network 130 introduced above in FIG. 1, which are not repeated herein.

[0114] According to the above, this disclosure provides a solution that not only enhances the reliability and security of pump operational data but also facilitates its use in compliance, maintenance, and operational optimization scenarios. The ability to verify data authenticity through a DLT network also provides various application scenarios for using this trusted data in various regulatory, financial, and operational frameworks.

[0115] An application scenario of the solution of this disclosure is given in the following FIGs. 6-9, where a command center, a pump, and a DLT are involved. In the following, the command center maybe built based on the server 120 introduced in FIG. 1, the pump may be built based on the pump no (and the controller 111) introduced in FIG. 1, and the DLT maybe built based on the DLT network 130 introduced in FIG. 1.

[0116] FIG. 6 shows an exemplary flowchart of setting up a pump as a trusted meter. The following text describes the sequence diagram as depicted in FIG. 6. Each detailed text paragraph corresponds to each of the steps marked with numbers.

[0117] 1. Master Wallet Creation and Funding (applied to a Command Center): The Command Center establishes a master wallet, which is a fundamental financial mechanism within the system. This wallet is responsible for distributing funds for pump usage and other transactions within the DLT network (such as creating a block). The creation of the wallet is a one-time event, while its funding is a continuous process, signifying an operational model where initial setup is followed by ongoing maintenance. Initiation of the Master Smart Contract (applied to a DLT network): A master smart contract is initiated on the DLT network. This contract acts as a governing ledger for all transactions and interactions related to pump usage, providing a structured and secure means of managing the pump service ecosystem. Funding the Master Smart Contract (applied to the Command Center): Funds are added to the master smart contract to ensure liquidity for the pump usage transactions. This step ensures that the Command Center has sufficient resources to manage and facilitate the operations of the pump network. Bill of Material Creation (Production): In the production phase, a Bill of Material (BoM) is created, capturing the details of all components required for the assembly of the pump. This BoM is stored in the production management system, indicating readiness for the production stage. Pump Assembly (Production) : The physical assembly of the pump, including the edge module, is completed. This step is critical as it brings together the various parts to create a functional unit ready for deployment. Pump and Edge Computer Association (Production): A unique combination of the hardware parts (pump) and the edge computer is established, ensuring a Trusted Execution Environment. This combination allows for maintaining the integrity and security of the pump’s operational data. Pump ID Creation (Production to Command Center): Based on the BoM, a unique Pump ID is created and stored, which is essential for product lifecycle management. This ID serves as a digital fingerprint, enabling the tracking of each pump throughout its service life. 8. Pump ID and BoM Hashing (Command Center): To secure the integrity of the pump’s data and identity, the Pump ID and BoM are hashed by the Command Center. Hashing these components ensures that they are recorded on the blockchain in an immutable and non-reversible manner, providing a layer of security and traceability.

[0118] 9. Pump Shipment Readiness (Production to Pump): The final step in the production process is confirming the pump is ready for shipment. This signifies that all prior steps have been completed successfully, and the pump is prepared to be distributed to its destination.

[0119] Based on the above-described steps, the system is now ready for onboarding pumps and the associated customer accounts.

[0120] FIG. 7 shows an exemplary flowchart of account creation. The following text describes the sequence diagram as depicted in FIG. 7. Each detailed text paragraph corresponds to each of the steps marked with numbers. It is noted that in FIG. 7, pump purchase (step 1-4) may differ, but do not interfere with the digital setup of the pump.

[0121] 1. End User's Request for Pump Installation: The process initiates when an end user requests the installation of a pump. This step is critical as it triggers the series of actions leading to the creation of a functional and financial account for the pump service within the system.

[0122] 2. Pump Purchase by Installer: The installer, upon receiving a request from the end user, purchases the pump from the distributor. This transaction reflects the commercial relationship between the installation service providers and the pump distributors.

[0123] 3- Pump Delivery to Installer: The distributor delivers the pump to the installer. This logistical step is essential to bring the physical unit from the point of sale to the installation site. Pump Installation by Installer: The installer installs the pump at the end user's location. The installation marks the physical setup of the pump, preparing it for integration into the blockchain ecosystem. Pump Goes Online (Pump to Command Center): Once installed, the pump is powered and goes online. This signifies the beginning of digital integration, where the pump's operational data starts to communicate with Command Center, the managing entity. Pump Identification & Initiation (Command Center): Command Center identifies the pump and begins the initiation process. This step is essential to assign a unique digital identity to the pump, aligning it with the corresponding user account and service agreement. Edge Configuration Ready (Command Center): Command Center ensures that the edge configuration is ready, which includes activating the pump's digital wallet. The wallet will manage the microtransactions for services rendered by the pump. Sending Configuration to Edge (Command Center to Pump): The configuration, including the wallet activation action, is sent to the pump's edge device. This communication is fundamental for enabling the pump's onboard systems to start transactions and engage with the blockchain and provide a data flow between the Command Center and the pump. Add Pump & Smart Contract Registration (Command Center): Command Center registers the pump and its associated smart contract on the blockchain. This registration is critical for the pump to be recognized as an autonomous economic agent within the ecosystem. Add Funds to Wallet (Command Center to DLT): Command Center adds funds to the pump's wallet using the blockchain platform (DLT). This funding is necessary for the pump to initiate services and perform transactions. 11. Funds Added, Smart Contract Ready (DLT to Command Center): Once the funds are added, the smart contract becomes ready. This readiness indicates that the pump's wallet has a positive balance and the smart contract terms are active, thus allowing the pump to operate within the agreed parameters.

[0124] In this sequence, the end user's interaction marks the starting point of a process that culminates in the pump being a fully functional member of the service ecosystem. Each step involves precise coordination between different parties— End Users, Installers, Distributors, and Command Center— ensuring that the pump is not only installed physically but is also integrated into a digital framework that enables secure, transparent, and automated operations. This integration leverages blockchain technology for both the operational and financial aspects of the pump's service lifecycle, supporting a business model where pumps are offered as a service, complete with a prepayment and service validation mechanism.

[0125] The End User and the Pump is now connected through the Command Center and the DLT ready for use. However, the pump needs to understand the contract terms it operates. That is established in the next step of contract generation.

[0126] FIG. 8 shows an exemplary flowchart of NFT contract generation. The following text describes the sequence diagram as depicted in FIG. 8. Each detailed text paragraph corresponds to each of the steps marked with numbers.

[0127] 1. Contract Signing for Pump Service (End User to Command Center): The process begins with the end user signing a service contract with the Command Center. This agreement stipulates the terms of service for the pump, including usage, maintenance, and payment details.

[0128] 2. Contract Conversion (Command Center): The Command Center translates the signed contract into digital form, encapsulating all relevant parties' identifiers (Pump ID, End User ID, and possibly distributor, installer, government and other relevant 3rd party IDs). It also codifies the revenue distribution terms directly into the contract code, enabling the subsequent smart contract to enforce the financial aspects of the service agreement with precision and low administrative cost.

[0129] 3. Initiate NFT Contract Minting (Command Center to DLT): With the digital version of the contract prepared, the Command Center initiates the minting of a non-fungible token (NFT) contract on DLT platform. This NFT contract will represent the binding agreement and its terms.

[0130] 4. NFT Minting and Smart Contract Creation (DLT): The DLT platform conducts the NFT minting process, generating a smart contract from the minted NFT. This newly created NFT, known as the Contract NFT, embodies the terms of the pump service contract and is inherently equipped to interact with the blockchain for transaction enforcement and revenue distribution.

[0131] 5. Contract NFT Storage in Pump Wallet (DLT to Pump): The minted Contract NFT is then transmitted to the pump's digital wallet, securely stored within the pump's operational ecosystem. The wallet now contains not only the operational funds but also the NFT that governs the service conditions, ensuring that the pump operates under the agreed terms and facilitates correct revenue allocation.

[0132] Through these steps, the NFT contract minting process effectively bridges the gap between a physical service agreement and a blockchain-verified contractual obligation. It allows for the tokenization of the service terms, enabling automated enforcement of contract conditions and revenue distribution among stakeholders. By storing the Contract NFT in the pump's wallet, the system assures that all transactions related to the pump's service are transparent, traceable, and in alignment with the established agreement. This ensures that all parties, including the end user, the pump itself, and the service entities, operate under a common, immutable set of rules laid out by the smart contract on the blockchain.

[0133] FIG. 9 shows an exemplary flowchart of data capture and process. The following text describes the sequence diagram as depicted in FIG. 9. Each detailed text paragraph corresponds to each of the steps marked with numbers. Pump Signals Transaction Readiness (Pump): The pump indicates that it is ready to perform a financial transaction, signalling a status of operational readiness to interact with the blockchain. Loading Funds from Wallet to Smart Contract (Pump to DLT): The pump loads funds from its wallet into the smart contract (SC). This step represents the transfer of value, earmarking funds for future transactions related to pump services. Funds secured in Smart Contract (DLT): The DLT confirms that the funds have been securely allocated within the smart contract, effectively escrowing the assets in preparation for transaction validation. Sending Secured Hash to SC (Pump to DLT): The pump sends a secured hash of operational data to the smart contract. This hash serves as an encrypted summary of transaction data, ensuring privacy and security. Issuing Probable Claim for Positive SC Balance (Pump to Command Center): The pump issues a probable claim to the Command Center for a positive smart contract balance through a Non-Interactive Zero-Knowledge Proof (NIZKP). This cryptographic proof enables the pump to demonstrate sufficient funds without revealing the exact balance, maintaining confidentiality. Receives claim, operations data, and NIZKP (Command Center): The Command Center receives the claim, along with the operations data and the NIZKP, validating the pump's ability to continue operation. Data Capture (Pump to Pump) : The pump captures data regarding its operation. This could include metrics on water flow, usage time, or other relevant operational parameters. Steps 6 and 7 may occur in parallel. Hash Aggregated Pump Data (Pump to DLT): The pump sends a hash of the aggregated operational data to the blockchain. By aggregating and then hashing this data, the pump ensures that individual data points cannot be isolated, and privacy is maintained.

[0134] 9. Data entry with hash (Command Center): The Command Center enters this hashed data into their system for record-keeping and further processing.

[0135] 10. Calculation for Usage Based on Hashed Data (Pump to DLT): The pump performs calculations for usage, relying solely on the hashed data. This process determines the cost of the consumed services, readying the information for transactional purposes. n. Decrement fund balance (DLT): As a result of the calculation, the DLT decrements the fund balance in the smart contract, reflecting the cost of the services utilized by the pump.

[0136] 12. New NIZKP (Pump): Upon completion of the transactions and adjustments to the balance, a new Non-Interactive Zero-Knowledge Proof is generated. This new proof will be used for the next cycle of transactions, maintaining the privacy and integrity of the process.

[0137] Through these steps, the blockchain-enabled pump system captures, processes, and securely transmits operational data, ensuring accurate billing and service provision while preserving the privacy of all parties involved. The use of NIZKP is particularly beneficial, since it allows for the proof of balance without disclosure, an innovative approach that leverages the unique capabilities of blockchain technology.

[0138] The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed matter, from the studies of the drawings, this disclosure, and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutually different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. Claims1. A controller (in) for a pump (no), the controller being configured to: collect operational data related to the pump (no); send a first data packet (101) comprising the operational data to a server (120); determine a hash value of the collected operational data; and send a second data packet (102) comprising the hash value to a distributed ledger technology, DLT, network (130).

2. The controller (111) according to claim 1, wherein the operational data comprises one or more of: vibration data, pressure data, temperature data, flow rate data, power consumption data, and revolutions-per-minute data, operation time, volume flow, event data, respectively, of the pump.

3. The controller (111) according to claim 1 or 2, wherein the first data packet (101) and the second data packet (102) each further comprises an identification of the pump and / or a timestamp of the operational data.

4. The controller (111) according to any one of claims 1 to 3, configured to send the first data packet (101) and the second data packet (102) periodically.

5. The controller (111) according to any one of claims 1 to 4, further configured to store a public-private key pair for authenticating the pump (no) on the DLT network (130).

6. The controller (111) according to claim 5, wherein the public-private key pair is associated with a fund account on the DLT network (130).

7. The controller (111) according to any one of claims 3 to 6, wherein the identification of the pump comprises a first part identifying the pump and a second part identifying one or more components of the pump.

8. The controller (111) according to claim 7, configured to generate the second part of the identification of the pump by hashing or concatenating one or more identifiers associated with the one or more components of the pump.

9. The controller (in) according to claim 7 or 8, wherein if at least one of the one or more components of the pump is changed, the controller is configured to modify the identification of the pump by modifying only the second part of the identification of the pump based on the at least one changed component.

10. A pump (no) comprising the controller (111) according to any one of claims 1 to 9-11. A server (120) configured to: receive, from a controller (111) of a pump (no), a data packet (101) comprising operational data of the pump; store the operational data in a storage unit (121); obtain, from a DLT network (130) associated with the pump (no), a first hash value corresponding to the operational data; determine a second hash value of the operational data stored in the storage unit (121); and validate the operational data stored in the storage unit by comparing the first hash value and the second hash value.

12. The server (120) according to claim 11, further configured to send software information of the pump to the DLT network (130).

13. A system (100) comprising a pump and a controller according to one of claims 1 to 10 and a server (120) according to claim 11 or 12.

14. The system (100) according to claim 13, further comprising a plurality of pumps and one or more distributed ledger technology, DLT, networks (130), wherein each respective pump is associated with a respective DLT network, and each respective DLT network is configured to:receive, from the respective pump associated with the DLT network, a data packet comprising a hash value of operational data of the respective pump; and create a new block for storing the hash value of the operational data of the respective pump in the network.

15. The system (100) according to claim 14, wherein for creating the new block for storing the hash value of the operational data of the respective pump in the network, the respective DLT network is configured to: broadcast a transaction about creating the new block in the respective DLT network; employ a consensus mechanism to validate the transaction; and create the new block to store the hash value when consensus is reached in the respective DLT network.

16. The system (100) according to claim 14 or 15, wherein the respective DLT network is a blockchain network.

17. A method (500) comprising: collecting (501), by a controller of a pump, operational data related to the pump; sending (502), by the controller, a first data packet comprising the operational data to a server; receiving (503), by the server, the first data packet from the pump; storing (504), by the server, the operational data in a storage unit; determining (505), by the pump, a hash value of the collected operational data; sending (506), by the pump, a second data packet comprising the hash value to a distributed ledger technology, DLT, network; obtaining (507), by the server, the hash value from the DLT network as a first hash value; determining (508), by the server, a second hash value of the operational data stored in the storage unit; and validating (509), by the server, the operational data stored in the storage unit by comparing the first hash value and the second hash value.

18. A computer program product comprising instructions which, when the program is executed by a server, a pump and a distributed ledger technology, DLT, network, causes the server, the pump and the DLT network to perform the method according to claim 17.

Images