SELF-TESTING AUTOMATION SYSTEM

Abstract

A self-testing automation system includes a decentralized distributed ledger-type database comprising a plurality of subscriber nodes, wherein the subscriber nodes exchange data with one another per transaction, and the database stores the transactions in data blocks which are linked together; a regulating mechanism which is implemented into each of the subscriber nodes, said regulating mechanism comprising information on the number and identity of all of the subscriber nodes as well as rules relating to actions, properties, and states of each of the subscriber nodes; and a plurality of automation components which are subscriber nodes of the decentralized database. Each of the subscriber nodes is designed to test or validate transactions between the subscriber nodes at all times using the regulating mechanism, and each of the subscriber nodes is designed to carry out at least one measure if a violation of the regulating mechanism is detected.

Claims

1-13. (canceled)

14. An automation technology system, comprising: a decentralized, distributed database according to the distributed-ledger technology, especially a blockchain, comprising a plurality of subscriber nodes, wherein the subscriber nodes are designed to exchange data, or information, with one another per transaction, wherein the database is designed to store the transactions, especially in data blocks linked to each other; a rule set which is implemented on each of the subscriber nodes, wherein the rule set comprises information about the number and identity of all of the subscriber nodes, as well as rules relating to actions, properties, and states of each of the subscriber node; and a plurality of automation components, which are subscriber nodes of the decentralized database, wherein each of the subscriber nodes is designed to check or validate transactions between the subscriber nodes at all times based upon the rule set, and wherein each of the subscriber nodes is designed to carry out at least one measure when a violation of the rule set is detected.

15. The system of claim 14, wherein the decentralized database comprises the automation components as subscriber nodes.

16. The system of claim 13, wherein the decentralized database comprises further subscriber nodes, in addition to the automation components.

17. The system of claim 14, according to at least one of the preceding claims, wherein the rule set is stored as program code on each of the subscriber nodes, the program code being executed by the subscriber nodes.

18. The system of claim 14, wherein the rule set includes algorithms which, when executed on the subscriber nodes, carry out a check of an impending violation of the rule set.

19. The system of claim 18, wherein the algorithms comprise AI-based evaluations for checking an impending violation of the rule set.

20. The system of claim 19, wherein the results obtained after an AI evaluation of a subscriber node are communicated to the algorithms of the further subscriber nodes.

21. The system of claim 18, wherein the algorithms comprise threshold-based evaluations for checking an impending violation of the rule set.

21. The system of claim 18, wherein the rule set has different types of algorithms, and wherein the subscriber nodes are designed to select and execute at least one of the algorithms as a function of their respectively available resources.

22. The system of claim 14, wherein the rule set claim 14, wherein the rule set has a dynamic component and a static component, wherein the content of the static component is not changeable, and wherein the content of the dynamic component is changeable and/or expandable.

23. The system of claim 22 which is designed in such a way that the content of the dynamic component is changed and/or expanded in the event of an agreement of a predetermined portion of the subscriber nodes.

24. The system of claim 14, wherein the rule set comprises the following rules: services by means of which the subscriber nodes are allowed to communicate in each case with other subscriber nodes according to the rule set; a permitted value range in which measured values contained in the transactions of the subscriber nodes are provided; a maximum packet rate and bandwidth of a respective subscriber node; a maximum number of simultaneous connections of a subscriber node; a maximum ratio of time and new connections of a subscriber node; a maximum time for existing connections from or to a subscriber node; error rate for connections between subscriber nodes; resource usage of a subscriber node; measurement and control value behavior automation communications patterns parameter settings data and communications heuristics or patterns meta-communications data; interface usage of a subscriber node.

25. The system of claim 14, wherein each of the subscriber nodes is designed to carry out at least one of the following measures when a violation of the rule set is detected: generating and outputting an alarm message; blocking the communications within the database with an affected subscriber node; stopping the communications outside the database with an affected subscriber node; generating and outputting an analysis report about the detected violation of the rule set; closing ports; stopping the services of each subscriber node.

Description

[0050] The invention is explained in greater detail with reference to the following figures. The following are shown:

[0051] FIG. 1: an explanation of a database designed according to the distributed-ledger technology; and

[0052] FIG. 2: a first exemplary embodiment of the system according to the invention.

[0053] FIG. 1 shows an explanation of a decentralized database DB designed according to a distributed-ledger technology. In the present case, the database DB is based upon blockchain technology. Blockchain technology has become known as the backbone of the “Bitcoin” Internet currency. A blockchain, i.e., a chain of linked data blocks BL1, BL2, BL3, allows a high degree of data integrity. The mode of operation of a database DB which is used for the invention is briefly explained below.

[0054] As a rule, a given data block BL1, BL2, BL3 is made up of at least two components: On the one hand, this is a data field DF. Data in the form of transactions TA are stored in this data field DF. The transaction TA refers to a transmission of the data from a first subscriber node TK1, TK2, . . . , TK6 to a second subscriber node TK1, TK2, . . . , TK6 in a communications network—for example, the Internet. A transaction TA contains a transmitted value, e.g., data of the field device FG, and the transmitter and the receiver of the transaction TA. Subscriber nodes TK1, TK2, . . . , TK6 are all devices which form the database or are connected thereto and allow the distributed-ledger functionality.

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

[0056] On the other hand, 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 by sometimes complex calculations. For this purpose, all transactions TA of the data field of a block BL1, BL2, BL3 are calculated to an intermediate value. For example, the Merkle root of the total number of transactions TA is calculated for this. The exact functional principle is not addressed here. For this purpose, reference is made to https://en.wikipedia.org/wiki/Merkle_tree.

[0057] This calculated intermediate value is then converted with the checksum #1, #2, #3 of the previous data block BL1, BL2, BL3 to the checksum #1, #2, #3 of the current data block BL1, BL2, BL3. For example, the data block BL2 shown in FIG. 1 contains a checksum #2. This checksum #2 was thus 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. Analogously, the data block BL3 shown in FIG. 1 contains a checksum #3. This checksum #3 was thus calculated from the transactions TA stored in the data field DF of the data block B3 and the checksum #2 of the preceding data block BL2.

[0058] The integrity of the data, i.e., the protection of the data from subsequent manipulation, is thus ensured by storing the checksum #1, #2, #3 of the preceding data block BL1, BL2 in the respective following data block BL2, BL3. A blockchain is thus made up of a series of data blocks BL1, BL2, BL3, in each of which one or more transactions TA are combined and provided with the checksum #1, #2, #3. A modification of data produces a modified intermediate value, thereby also modifying the checksum #1, #2, #3 of the respective data block BL1, BL2, BL3. The subsequent data block BL1, BL2, BL3 thus no longer matches the preceding data block BL1, BL2, BL3. In doing so, data of a once successfully validated data block BL1, BL2, BL3 can no longer be changed by an attacker.

[0059] New data blocks BL1, BL2, BL3 are created at regular intervals. All transactions TA which were created after the point in time at which the last data block BL1, BL2, BL3 was created are stored in the data field of the new data block BL1, BL2, BL3.

[0060] The complexity of the block creation can be increased due to the fact that the established checksum #1, #2, #3 must have a predefined format. For example, it is specified that the checksum must be 24 characters long, wherein the first four characters must have the numerical value 0. For this purpose, in addition to the intermediate value of the transactions TA and the checksum of the previous data block, a numerical sequence to be determined, called a “nonce” and having a fixed length, is used for calculating the checksum #1, #2, #3 of the current data block BL1, BL2, BL3. The calculation of the new checksum #1, #2, #3 takes longer, because there are only a few nonces that lead to the calculation of a checksum #1, #2, #3 with the given criteria. Finding such a suitable nonce in this case causes the described additional time expenditure.

[0061] After the checksum #1, #2, #3 of a new data block BL1, BL2, BL3 has been created, the data block is transmitted to all subscriber nodes TK1, TK2, . . . , TK6. The validatable subscriber nodes TK1, TK2, TK3, TK4 then check 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 subscriber nodes TK. In particular, a successful validation of more than half of all validatable subscriber nodes TK1, TK2, TK3, TK4 is required for this purpose. An attacker would therefore, for introducing/creating a foreign, malicious data block BL1, BL2, BL3, have to manipulate or control a large number of validatable subscriber nodes TK1, TK2, TK3, TK4, to successfully validate the introduced data block BL1, BL2, BL3. As the number of validatable subscriber nodes TK1, TK2, TK3, TK4 increases, this must be regarded as an almost impossible undertaking.

[0062] The validation of a data block BL1, BL2, BL3 requires significantly less effort than the creation of the data block BL1, BL2, BL3. The checksum #1, #2, #3 is back-calculated, and the intermediate value of the transactions TA or the checksum #1, #2, #3 of the previous data block BL1, BL2, BL3 is recovered and compared to the actual intermediate value or to 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.

[0063] The following describes how a self-monitoring system for an automation technology plant can be set up with the aid of such a database DB:

[0064] FIG. 2 schematically illustrates the system according to the invention. The database DB, which is constructed as described above, is essentially composed of six subscriber nodes TK1, TK2, TK3, TK4, TK5, TK6, which are designed as full nodes. Each of them stores an image AB of the content of the database DB, i.e., the chain of the data blocks DB1, DB2, DB3. The subscriber nodes TK1, TK2, TK3, TK4 are automation components—for example, field devices (subscriber nodes TK1, TK2, TK3). By executing distributed-ledger software or a software stack, these automation components can act as subscriber nodes, load the image of the content of the database DB, and write data to the database and verify transactions. However, it cannot verify transactions. Examples of such field devices are mentioned in the introductory part of the description. The field devices collect, for example, measured values of a process-engineering process and transmit them within the database—for example, to a control unit (subscriber nodes TK4).

[0065] The subscriber nodes TK5 and TK6 are IT components; in particular, in the case of the subscriber node TK5, it is a cloud server, and, in the case of the subscriber node TK6, it is an operating PC of a user. If these two subscriber nodes are introduced into the OT network of the plant or have process-relevant operating applications, they likewise fall under the definition of an automation component.

[0066] A rule set is integrated as program code on each of the subscriber nodes TK1, . . . . It contains information about the number and identity of all subscriber nodes TK1, . . . , TK6, as well as rules relating to actions, properties, and states of each of the subscriber nodes TK1, . . . , TK6, and, during execution, allows a subscriber node TK1, . . . , TK6 to check the transactions of the subscriber nodes according to the rule set RG, and thus allows anomalies to be recognized. In the sense of the blockchain technology used as a database in the present example, such a rule set can be implemented as a smart contract.

[0067] The violation of a rule set, or an anomaly resulting therefrom, can be detected by means of two different methods. Both are implemented by corresponding algorithms, which, depending upon the available resources of the subscriber nodes TK1, . . . , TK6, can be implemented thereon.

[0068] On the one hand, the algorithms enable threshold-based evaluations. In the process, contents of transactions of the subscriber nodes TK1, . . . , TK6 are compared to the data in the rule set RG. If they deviate from one another or deviate from one another by a certain value (threshold value), this represents an anomaly or a rule violation.

[0069] Alternatively, the algorithms provide AI-based evaluations for checking an impending violation of the rule set RG. For example, algorithms which use neural networks or deep-learning-based algorithms are suitable. The results of the algorithms obtained after an AI evaluation of a subscriber node TK1, . . . TK6 can be communicated to the further subscriber nodes TK1, . . . , TK6 in order to establish a store of experience.

[0070] Likewise, the rule set contains a catalog of measures, linked to detected anomalies, whereby actions for eliminating faults and/or actions for preventing further errors/attacks are initiated.

[0071] In the following, a first exemplary embodiment shall be described, in which it is determined on the basis of the rule set RG whether a violation of the rule set RG or an anomaly is present:

[0072] A new, unknown device attempts to join the database DB as a new subscriber node. However, joining the database is possible only if it is permitted in the rule set RG that a potential subscriber be provided with unique identification information, which is also defined as an authorized subscriber in the rule set RG.

[0073] Here, a distinction can be made between three different cases, which trigger different reactions of the subscriber nodes.

[0074] On the one hand, the request to join may be unplanned and unintentional. In this case, the requesting device has no authorization. Its identification information is therefore not listed in the rule set RG, such that it cannot authenticate or identify itself. The subscriber nodes TK1, . . . , TK6 receive the request for access as a transaction, check its content—in this case, the sender identification—and detect a rule violation (possible by way of a threshold-based evaluation and/or by AI algorithm). As the resulting measure associated with this rule violation, any contractually non-compliant communication or transaction within the database DB with this device is prevented (Layer 7 or Edge/Switch can block).

[0075] In a second case, the request to join is planned and intended. The new potential subscriber node of the database makes the request for access. The subscriber nodes TK1, . . . , TK6 receive the request for access as a transaction, and check its content—in this case, the sender identification—and that it is present in the rule set RG. The device thus has a valid authorization and can authenticate or identify itself. Subsequently, the device is included as a new subscriber node in the database DB.

[0076] In a second case, the request to join is unplanned, but desired. In this case as well, the requesting device has no authorization. Its identification information is therefore not listed in the rule set RG, such that it cannot authenticate or identify itself. The subscriber nodes TK1, . . . , TK6 receive the request for access as a transaction, check its content—in this case, the sender identification—and detect a rule violation. As a measure, however, the existing subscriber nodes TK1, . . . , TK6 agree to insert the new identification information of the requesting device into the rule set RG. This can take place by the existing subscriber nodes TK1, . . . , TK6 checking the identification of the device and its rule set to be introduced, or negotiating a new rule set, based upon the new information of the device and the previous information of the existing rule set RG. In both cases, the device is either accepted or discarded as a new subscriber node in a majority procedure, i.e., a voting process. In the event that the device is accepted as new subscriber node, it must likewise agree to the newly-negotiated rule set RG.

[0077] The device can also be added as a new subscriber node by presenting its identification information and agreeing to the previous rule set RG, without introducing new rules itself. The existing subscriber nodes TK1, . . . TK6 check the identification information and include the device as a new subscriber node after it is checked whether the existing rule set RG can be adhered to by the properties of the new subscriber node. The above-described majority procedure or the voting process can also be carried out for this purpose.

[0078] Finally, a further exemplary embodiment is described for the method according to the invention. The subscriber nodes TK1, TK2, TK3, as field devices, continually collect measured values of a process-engineering process and transmit them to the superordinate unit (subscriber node TK4). A value range within which the measured values are allowed to vary has been defined by calibration and official verification and stored in the rule set RG. The subscriber nodes TK1, . . . , TK6 check the measured values, contained in the transactions of the subscriber nodes TK1, TK2, TK3, according to the rule set RG. If the value range is exceeded or fallen short of, these generate a warning to the plant operator as a measure. The value range being exceeded or fallen short of can be detected by a threshold-based evaluation or by means of AI algorithms. In the event that a subscriber node TK1, . . . , TK6 uses AI algorithms, the latter can also predict the value range being foreseeably exceeded or fallen short of, even if this has not yet occurred (“predictive maintenance”).

LIST OF REFERENCE SYMBOLS

[0079] AK1, . . . , AK4 Automation components [0080] BL1, BL2, BL3 Data block [0081] BO Dashboard [0082] DB Decentralized database [0083] EL Electronics unit [0084] FG Field device [0085] KN Communications network [0086] KS Communications Interface [0087] RG Rule set [0088] TA Transaction [0089] TK1, . . . , TK6 Subscriber nodes [0090] #1, #2, #3 Hash values of the data blocks