SYSTEM AND METHOD FOR TAMPER-PROOF MANAGEMENT OF DATA FROM A FIELD DEVICE OF AUTOMATION TECHNOLOGY

Description

[0001] The invention relates to a system and a method for the tamper-proof management of data of a field device by means of a decentralized database according to the distributed ledger technology, in particular a blockchain, wherein the decentralized database comprises a plurality of participant nodes consisting of validation-capable and / or read-authorized participant nodes, wherein a field device of automation technology is provided which has an electronic unit and a communication interface.

[0002] Field devices used in industrial plants are already known from the state of the art. Field devices are widely used in process automation technology as well as in manufacturing automation technology. Field devices essentially refer to all devices used close to the process and that supply or process-relevant data or information. Field devices are used to record and / or influence process variables. Measuring devices or sensors are used to record process variables. These are used, for example, for pressure and temperature measurement, conductivity measurement, flow measurement, pH measurement, level measurement, etc. and record the corresponding process variables such as pressure, temperature, conductivity, pH value, level, flow, etc. Actuators are used to influence process variables.These include, for example, pumps or valves that can influence the flow of a fluid in a pipe or the fill level in a container. In addition to the previously mentioned measuring devices and actuators, field devices also include remote I / Os, wireless adapters, and generally devices located at the field level.

[0003] A large number of such field devices are produced and distributed by the Endress+Hauser Group.

[0004] In modern industrial plants, field devices are usually connected to higher-level units via communication networks such as field buses (Profibus ®< , Foundation ®< Fieldbus, HART ®< , etc.). These higher-level units are usually control units such as a PLC (programmable logic controller). The higher-level units are used, among other things, for process control and for commissioning the field devices. The measured values ​​recorded by the field devices, in particular sensors, are transmitted via the respective bus system to one (or possibly several) higher-level units, which then further process the measured values ​​and forward them to the plant's control center. The control center is used for process visualization, process monitoring and process control via the higher-level units.In addition, data transmission from the higher-level unit to the field devices via the bus system is also required, in particular for the configuration and parameterization of field devices and for the control of actuators.

[0005] Field devices generate a wide variety of different data. This data includes, in addition to the measurement data from sensors mentioned above, which provides a plant operator with information about the current process values ​​of the measuring points in their plant, for example, control data, e.g., for controlling an actuator. Furthermore, this data includes diagnostic, historical, and / or status data, which informs the plant operator about problems with the field devices or the current status of individual field devices, as well as calibration / parameterization data.

[0006] Nowadays, it's common practice to store this data in a central location within the plant, for example, in a database on a workstation PC at the plant's control level. However, this comes with disadvantages: If the database fails, is destroyed, or becomes unreadable, the data stored in it is lost.

[0007] Certain applications or parts of a system must be officially approved. It is essential that calibration certificates are issued for the field devices and that the data generated by the field device can be created according to the calibration certificate or can be assigned to it.

[0008] Nowadays, this data, or rather the calibration certificates, are recorded on-site in an electronic operating log. For verification, an authority must go to the plant operator on-site and check this operating log for accuracy. This requires resources from both the plant operator and the authority. The plant operator's resource expenditure lies, for example, in procuring and maintaining the necessary technical resources and in ensuring that the data is stored in an unalterable manner in the operating log. Furthermore, the operating log must be immediately available when the authority requests it. The authority's resource expenditure lies, for example, in the deployment of personnel who have to go to the plant on-site and check the data there.

[0009] Often, the systems that contain the operating log and the means for transmitting and recording data are only available as proprietary solutions for individual field device manufacturers. However, such proprietary systems are unpopular with plant operators because they impose additional maintenance costs and complexity on the plant.

[0010] The object of the present invention is therefore to provide a tamper-proof and location-independent alternative to an operating log.

[0011] The object is achieved by a system for the tamper-proof management of data of a field device of automation technology according to claim 1, and by a method according to claim 10.

[0012] The system is intended to include: A decentralized database based on distributed ledger technology, in particular a blockchain, comprising a plurality of participant nodes, including validatable participant nodes; a field device of automation technology, comprising an electronic unit, wherein the electronic unit is configured to execute a distributed ledger software stack, and having a communication interface for establishing a communication connection to the decentralized database via a wireless or wired communication network, wherein the field device is configured to generate data, comprising verifiable measured values ​​and / or calibration certificates, wherein the field device, after executing the distributed ledger software stack, acts as a light node of the decentralized database and is configured to transmit the data to the decentralized database via the communication network, to provide it with a time stamp, and to write it in encrypted form to the decentralized database,wherein the validatable participant nodes are configured to validate the transmitted data, wherein the decentralized database is configured to store the data if at least a predetermined proportion of the validatable participant nodes successfully validate the data.

[0013] The system according to the invention allows for tamper-proof storage of data from a field device, for example, its verifiable measured values ​​and / or calibration certificates, using a distributed ledger database. One example of such a database is blockchain technology. However, other technologies for distributed ledger databases also exist, for example, based on "block directed acyclic graphs (blockDAG)" or "transaction-based directed acyclic graphs (TDAG)" technology.

[0014] Such a distributed ledger database is decentralized and implemented on a multitude of computing units that communicate with each other. These computing units are referred to as participants. There are different types of participants: Full nodes, each of which stores an image of the database. Furthermore, these are used to verify transactions, for example, by storing / adding new data to the database. They are also used to calculate new "blocks" (see description of the Fig. 1 ). In the context of the invention, all full nodes are validatable participant nodes.

[0015] Light nodes are participant nodes that have limited functionality compared to full nodes. For example, they may only be able to write data to the database, but the database contents are not stored on a light node, and / or they may not participate in the verification or calculation of new "blocks."

[0016] Because the field device data is stored encrypted in the database, it is contained on all full nodes, but can only be read by participant nodes that contain details regarding the encryption, for example a key.

[0017] Field devices mentioned in connection with the invention have already been listed as examples in the introductory part of the description.

[0018] According to an advantageous development of the system according to the invention, the decentralized database additionally comprises read-authorized participant nodes, wherein the read-authorized participant nodes are configured to decrypt and read the stored data of the field device in the decentralized database. The read-authorized participant nodes can be either full nodes or light nodes. The read-authorized participant nodes have knowledge of encryption and have, for example, received the key required for decryption ("public key"). The plant operator or authorities, for example, can access the stored data via such participant nodes.

[0019] According to a preferred development of the system according to the invention, it is provided that at least one of the subscriber nodes, or a device connected to the decentralized database, is designed to execute an analysis program, wherein the analysis program is designed to generate alarm messages based on an analysis of the verifiable measured values ​​of the field device stored in the decentralized database.

[0020] The measured values ​​can therefore not only be stored for documentation / proof purposes, but can also be used for a "predictive maintenance" application.

[0021] In an advantageous embodiment of the system according to the invention, it is provided that the analysis program is designed to compare the stored measured values ​​of the field device that are subject to verification with at least one predetermined limit value during the analysis, and wherein the analysis program is designed to generate the alarm message in the event that at least one of the measured values ​​that are subject to verification exceeds or falls below the predetermined limit value.

[0022] In an advantageous embodiment of the system according to the invention, the decentralized database is designed to store and execute smart contracts as program code using the participant nodes. Smart contracts are computer protocols that map or verify contracts or technically support the negotiation or execution of a contract. The smart contracts are loaded and executed, for example, when the data from the field device is read by the respective participant node with read authorization. For example, executing such a smart contract enables the calibration certificate to be checked, for example, whether it was still valid for a specific measured value of the field device. Furthermore, penalty payments can be levied using a smart contract if a measured value determined by the field device shows unauthorized deviations or if a calibration certificate has expired.

[0023] An analysis program as described above can be integrated and executed on the database in a similar way to a smart contract.

[0024] In an advantageous embodiment of the system according to the invention, the decentralized database is a private database. A private database is only available to a specific group. Unlike a public database, there is one or more responsible persons who are responsible for maintaining the database. They also determine, for example, who performs which actions and who has access to certain data in the database.

[0025] In an advantageous embodiment of the system according to the invention, the communication network is based on an Ethernet protocol. If the communication interface of the field device allows wireless communication, wide-range standards such as 5G, LTE, etc. can be used.

[0026] In an advantageous embodiment of the system according to the invention, the field device, as a light node of the decentralized database, is designed to time-stamp the data transmitted via the communication network. This allows, for example, the measured values ​​requiring verification to be assigned to a specific calibration certificate. Calibration certificates contain information about the start and end dates of the calibration certificate.

[0027] In an advantageous embodiment of the system according to the invention, the system according to the invention additionally comprises a further light node of the decentralized database in the form of an automation component, in particular a control unit, or a further field device, wherein the further light node has a timer and is designed to generate time stamps and transmit them to the decentralized database, wherein the decentralized database is designed to compare the time stamps contained in the data of the field device with the time stamps of the further light node. The further light node, which is in particular an automation component adjacent to the field device, for example an automation component used in the same measuring point, serves as a further instance for reliable data from the field device by verifying the time stamp.

[0028] The procedure is intended to include the following procedural steps: Establishing a communication connection between the field device and the decentralized database by means of the communication interface via a wired or wireless communication network; adding the field device to the decentralized database as a light node by executing a distributed ledger software stack by means of the electronics unit; generating data by means of the field device, comprising verifiable measured values ​​and / or calibration certificates; transmitting the data via the communication network to the decentralized database, wherein the data is encrypted; validating the decentralized database by means of the validatable participant nodes; writing the data to the decentralized database if at least a predetermined proportion of the validatable participant nodes successfully validate the data.

[0029] According to an advantageous embodiment of the method according to the invention, it is provided that the method additionally comprises decrypting and reading the data by means of the read-authorized subscriber nodes.

[0030] The invention is explained in more detail with reference to the following figures. Fig. 1 : an explanation of a database designed according to distributed ledger technology; and Fig: 2 : an embodiment of the system according to the invention.

[0031] Fig. 1 shows an explanation of a database DB designed according to a distributed ledger technology. In this case, the database DB is based on blockchain technology. Blockchain technology became known as the backbone of the internet currency "Bitcoin." A blockchain, i.e., a chain of linked data blocks BL1, BL2, BL3, allows for high data integrity. The following briefly explains the functionality of a database DB used for the invention.

[0032] A data block BL1, BL2, BL3 typically consists of at least two components: First, there is a data field DF. This data field DF stores data in the form of transactions TA. A transaction TA refers to the transmission of data from a first participant node TK1, TK2, ..., TK6 to a second participant node TK1, TK2, ..., TK6 in a communications network, such as the Internet. A transaction TA contains a transmitted value, such as data from the field device FG, as well as the sender and receiver of the transaction TA. Participant nodes TK1, TK2, ..., TK6 refer to all devices that form the database or are connected to it and enable distributed ledger functionality.

[0033] A data field DF of a data block BL1, BL2, BL3 contains at least one transaction TA, more often several transactions TA.

[0034] Secondly, a data block BL1, BL2, BL3 contains a checksum #1, #2, #3. Such a checksum #1, #2, #3 is a hash value and is created through sometimes complex calculations. For this purpose, all transactions TA in the data field of a block BL1, BL2, BL3 are calculated to produce an intermediate value. For this purpose, for example, the Merkle root of the total number of transactions TA is calculated. The exact functional principle will not be discussed here. For this purpose, please refer to https: / / en.wikipedia.org / wiki / Merkle_tree.

[0035] This calculated intermediate value is then calculated with the checksum #1, #2, #3 of the previous data block BL1, BL2, BL3 to obtain the checksum #1, #2, #3 of the current data block BL1, BL2, BL3. For example, the Fig. 1 The data block BL2 shown contains a checksum #2. This checksum #2 was calculated from the transactions TA stored in the data field DF of the data block B2 and the checksum #1 of the preceding data block BL1. Similarly, the Fig. 1 The data block BL3 shown contains a checksum #3. This checksum #3 was calculated from the transactions TA stored in the data field DF of data block B3 and the checksum #2 of the preceding data block BL2.

[0036] The integrity of the data, i.e. the protection of the data against subsequent manipulation, is thus ensured by storing the checksum #1, #2, #3 of the previous data block BL1, BL2 in the subsequent data block BL2, BL3. A blockchain therefore consists of a series of data blocks BL1, BL2, BL3, each of which summarizes one or more transactions TA and provides them with the checksum #1, #2, #3. Changing data generates a changed intermediate value, which also changes the checksum #1, #2, #3 of the respective data block BL1, BL2, BL3. The subsequent data block BL1, BL2, BL3 therefore no longer matches the previous data block BL1, BL2, BL3. Once successfully validated, data from a data block BL1, BL2, BL3 can no longer be changed by an attacker.

[0037] New data blocks BL1, BL2, and BL3 are created at regular intervals. All transactions (TA) created after the last data block BL1, BL2, and BL3 was created are stored in the data field of the new data block BL1, BL2, and BL3.

[0038] The complexity of block creation can be increased by requiring the created checksum #1, #2, #3 to follow a predefined format. For example, it is specified that the checksum must be 24 digits long, with the first four digits having the numeric value 0. For this purpose, in addition to the intermediate value of the transactions TA and the checksum of the previous data block, a sequence of numbers to be determined, called a "nonce," with a specified length, is used to calculate the checksum #1, #2, #3 of the current data block BL1, BL2, BL3. Calculating the new checksum #1, #2, #3 takes correspondingly longer, since there are only a few nonces that lead to the calculation of a checksum #1, #2, #3 with the predefined criteria. Finding such a suitable nonce causes the additional time expenditure described above.

[0039] After the checksum #1, #2, #3 of a new data block BL1, BL2, BL3 has been created, the data block is transmitted to all participant nodes TK1, TK2, ..., TK6. The validatable participant nodes TK1, TK2, TK3, TK4 now verify the checksum #1, #2, #3 of the new data block BL1, BL2, BL3. Only after successful validation is the data block BL1, BL2, BL3 stored in all participant nodes TK. In particular, this requires successful validation by more than half of all validatable participant nodes TK1, TK2, TK3, TK4. Therefore, to inject / create a malicious data block BL1, BL2, BL3, an attacker would have to manipulate or control a large number of validatable participant nodes TK1, TK2, TK3, TK4 in order to successfully validate the injected data block BL1, BL2, BL3. As the number of validatable participant nodes TK1, TK2, TK3, TK4 increases, this is considered virtually impossible.

[0040] Validating a data block BL1, BL2, BL3 requires significantly less effort than creating the data block BL1, BL2, BL3. The checksum #1, #2, #3 is recalculated, the intermediate value of the TA transactions, or the checksum #1, #2, #3 of the previous data block BL1, BL2, BL3, is retrieved, and compared with the actual intermediate value, or with the actual checksum #1, #2, #3 of the previous data block BL1, BL2, BL3. If these values ​​match, the data block BL1, BL2, BL3 is successfully validated.

[0041] The following describes how data from a field device in process automation can be stored in a tamper-proof manner using such a database DB and read out for verification purposes: Fig. 2The system according to the invention is shown schematically. The database DB, which is structured as described above, essentially consists of four participant nodes TK1, TK2, TK3, TK4, which are designed as full nodes. These each store an image AB of the contents of the database DB, i.e., the chain of data blocks DB1, DB2, DB3. Two further, read-capable participant nodes TK5, TK6 are connected to the database DB. Furthermore, a field device FG of the automation technology is connected to the database DB by means of a communication interface KS via a communication network KN, in particular an Ethernet-based one.

[0042] By running a distributed ledger software stack, the field device FG becomes a participant node and acts as a light node in the database DB, meaning it can write data to the database DB. However, it cannot verify transactions. Likewise, it does not contain an image AB of the contents of the database DB.

[0043] The field device FG records measurement values ​​that require documentation and must be verified by an authority at irregular intervals. For this reason, the field device uploads these measurement values ​​and associated calibration certificates as DATA data to the database DB. Before transmission, the database encrypts this DATA data with a private key. The transmitted DATA data is then validated as a TA transaction by the validation-capable participant nodes TK1, TK2, TK3, and TK4 and stored in a data field DF of a data block in the database.

[0044] For verification purposes, the authority can access the database DB and read the DATA data using a computer acting as a read-capable participant node (TK5). For this purpose, the participant node (TK5) has previously received a public key that enables decryption.

[0045] In the same way, the system operator is able to access the database DB and read out the data DATA using a computer that acts as a read-capable subscriber node TK6.

[0046] A dashboard BO is displayed for both participant nodes TK5 and TK6, which visualizes the data. In this case, the dashboard DO consists of two columns. The first column shows the name of the participant node TK1, ..., TK6 whose data is stored. The second column shows the data assigned to the participant node TK1, ..., TK6 shown in the first column, for example, the measured values ​​of the field device FG and any associated calibration certificates.

[0047] As a further feature, so-called smart contracts can be stored in the database DB. Smart contracts are computer protocols that map or verify contracts or provide technical support for the negotiation or execution of a contract. These can be stored and executed as program code in the database using the participant nodes TK1, ..., TK6. Execution occurs particularly when the DATA data is read on the read-capable participant nodes TK5, TK6. For example, executing such a smart contract makes it possible to check the calibration certificate, for example, whether it was still valid for a specific measured value of the field device. Furthermore, a smart contract can be used to levy penalties if a measured value determined by the field device FG shows unauthorized deviations or if a calibration certificate has expired.

[0048] Similar to smart contracts, analysis programs can be stored in the database DB, which can be executed when the data is read by the participant nodes TK5, TK6. Such an analysis program serves, for example, the purpose of comparing the stored, verifiable measured values ​​of the field device FG with at least one predetermined limit during the analysis and generating an alarm message if at least one of the verifiable measured values ​​exceeds or falls below the predetermined limit. List of reference symbols

[0049] BL1, BL2, BL3 Data block BODashboard DBDecentralized database DATAData ELElectronic unit FGField device KNCommunication network KSCommunication interface TATransaction TETransaction creation unit TK1, ..., TK6Participant node #1, #2, #3Hash values ​​of the data blocks

Claims

1. A system for the manipulation-proof management of data of a field device (FG) from the field of automation technology, comprising: - A decentralized database (DB) based on distributed ledger technology, in particular a blockchain, comprising a number of participating nodes (TK1, TK2, ... , TK6), comprising validatable participating nodes (TK1, TK2, TK3, TK4) and read-authorized participating nodes (TK5, TK6), wherein the read-authorized participating nodes (TK5, TK6) are configured to decrypt and read the saved data (DATA) of the field device (FG) in the decentralized database (DB), and wherein the decentralized database (DB) is configured to save and execute smart contracts as a program code using the participating nodes (TK1, TK2, ... , TK6); - A field device (FG) from the field of automation technology, with an electronic unit (EL), wherein the electronic unit (EL) is configured to execute a distributed ledger software stack, and with a communication interface (KS) for establishing a communication connection to the decentralized database (DB) via a wireless or wired communication network (KN), wherein the field device (FG) is configured to generate data (DATA), comprising reportable measured values and calibration certificates, wherein the calibration certificates contain information about the start of validity and the end of validity of the relevant calibration certificate, wherein the field device (FG) acts as a light node of the decentralized database (DB) after executing the distributed ledger software stack and is configured to transmit the data (DATA) to the decentralized database (DB) via the communication network (KN), to give it a timestamp, and to write it to the decentralized database (DB) in encrypted form, wherein the validatable participating nodes (TK1, TK2, TK3, TK4) are configured to validate the transmitted data (DATA), wherein the decentralized database (DB) is configured to save the data (DATA), if at least a predetermined proportion of the validatable participating nodes (TK1, TK2, TK3, TK4) successfully validates the data (DATA), and wherein the read-authorized participating nodes (TK5, TK6) are configured to execute the smart contracts while the data (DATA) is being read and to check the calibration certificate by executing one of the smart contracts to verify whether it was still valid for a certain measured value of the field device.

2. The system as claimed in claim 1, wherein at least one of the participating nodes (TK1, TK2, ... , TK6), or a device connected to the decentralized database (DB), is configured to execute an analysis program, wherein the analysis program is configured to generate alarm messages based on an analysis of the reportable measured values of the field device (FG) saved in the decentralized database (DB).

3. The system as claimed in claim 2, wherein the analysis program is configured to compare the saved reportable measured values of the field device (FG) with at least one predetermined limit value during the analysis, and wherein the analysis program is configured to generate the alarm message in the event that at least one of the reportable measured values is above or below the predetermined limit value.

4. The system as claimed in at least one of the preceding claims, wherein the decentralized database (DB) is a private database.

5. The system as claimed in at least one of the preceding claims, wherein the communication network (KN) is based on an Ethernet protocol.

6. The system as claimed in claim 1, further comprising an additional light node of the decentralized database (DB) in the form of an automation component, in particular a control unit, or an additional field device, wherein the additional light node has a timer and is configured to generate timestamps and transmit them to the decentralized database (DB), wherein the decentralized database (DB) is configured to compare the timestamps contained in the data (DATA) of the field device (FG) with the timestamps of the additional light node.

7. A method for the manipulation-proof management of data (DATA) of a field device (FG) using a decentralized database (DB) based on distributed ledger technology, in particular a blockchain, wherein the decentralized database (DB) comprises a number of participating nodes (TK1, TK2, ... , TK6), consisting of validatable and / or read-authorized participating nodes (TK1, TK2, TK3, TK4), wherein a field device (FG) from the field of automation technology is provided, said field device having an electronic unit (EL) and a communication interface (KS), wherein the decentralized database (DB) is configured to save and execute smart contracts as a program code using the participating nodes (TK1, TK2, ... , TK6), comprising: - Establishing a communication connection between the field device (FG) and the decentralized database (DB) using the communication interface (KS) via a wired or wireless communication network (KN); - Adding the field device (FG) to the decentralized database (DB) as a light node by executing a distributed ledger software stack using the electronic unit (EL); - Generating data (DATA) using the field device (FG), comprising reportable measured values and calibration certificates, wherein the calibration certificates contain information about the start of validity and the end of validity of the relevant calibration certificate; - Transmitting the data (DATA) via the communication network (KN) to the decentralized database (DB) via the communication network (KN), wherein the data (DATA) is given a timestamp and is encrypted; - Validating the decentralized database (DB) using the validatable participating nodes (TK1, TK2, TK3, TK4); - Writing the data (DATA) to the decentralized database (DB), if at least a predetermined proportion of the validatable participating nodes (TK1, TK2, TK3, TK4) successfully validates the data (DATA); - Decrypting and reading the data (DATA) using read-authorized participating nodes (TK5, TK6), wherein the smart contracts are executed while the data (DATA) is being read, wherein by executing one of the smart contracts, the calibration certificate is checked to verify whether it was still valid for a certain measured value of the field device.