Computer-implemented method for providing data, especially for compliance monitoring

Description

[0001] The invention relates to a computer-implemented method for providing data, in particular for compliance tracking.

[0002] Products and systems can pose a potential hazard and are therefore subject to guidelines, regulations, and laws, compliance with which is monitored by authorities or so-called notified bodies. This monitoring can cover the design, manufacture, documentation, assembly, commissioning, operation, and disposal.

[0003] Dismantling, meaning the entire life cycle of the system or product.

[0004] The legislator prescribes a testing and certification process for this, which is carried out by conformity assessment bodies with the appropriate competence.

[0005] From DE 10 2017 121 296 A1 a test environment for automation tasks is known, for generating test signals and documenting results.

[0006] From EP 2 037 340 A1, a safety switching device with a test module is known, which can be controlled by a control unit. The control unit can be verified by a test process, whereby the generated test results are evaluated.

[0007] The publications XP033334708, XP033280449, and XP055482191 disclose blockchain technologies with consensus procedures.

[0008] Depending on the industry, plant, system or product, monitoring-relevant areas or parts are identified during the design or planning phase, and the applicable requirements from standards, guidelines, regulations and laws are specified.

[0009] Basic and detailed designs are executed accordingly, documented, checked and released for execution.

[0010] During and after completion of the construction phase, the realized technical system / product prototype is tested against the approved plan and, according to the test result, released for commissioning or placing on the market (declaration of conformity, operating permit).

[0011] To maintain compliant operation, recurring or random inspections (e.g., for plant or product safety) are carried out and documented as required. Likewise, proper dismantling and disposal documentation are necessary at the end of the service life and are documented accordingly.

[0012] For example, in process plants, documentation exists for each phase of the system lifecycle.

[0013] This procedure is the responsibility of the manufacturer or operator and their representatives.

[0014] Loss of this documentation, or parts thereof, can lead to the revocation of the operating license, product recalls, the need for reconstruction, plant shutdowns, and consequently, significant losses. Failure to comply with regulations and laws may also result in imprisonment.

[0015] Documenting compliance with all laws and regulations, including the corresponding test certificates, is currently a comprehensive and complex task requiring the involvement of at least three parties (manufacturer, inspector, operator) and numerous qualified personnel. This documentation must be archived for many decades and also revised regularly to ensure its availability at any time, for example, in the event of an audit or an industrial accident. All root cause analyses, corrective actions, and especially liability issues must incorporate the current information contained herein.

[0016] To date, verification and documentation are carried out through manual, paper-based processes. The resulting paper documentation, including inspection stamps and initials, is extensive, time-consuming, slow, and inflexible.

[0017] The use of physical stamps to release documents is inadequate, tamper-proof, and cannot be automated.

[0018] The acceptance testing of, for example, fail-safe controllers that already provide digital checksums in verified digital systems is based on paper documentation.

[0019] The use of traditional document formats prevents automation and necessitates the processing of larger units. Flexible, granular, and modular processing of subsystems, or the replacement of individual products within a larger system, always requires the revision of larger systems, with corresponding effort.

[0020] Producing multiple originals is costly in terms of distribution and archiving, generating high administrative costs over many decades.

[0021] It is therefore the object of the invention to remedy this situation. This object is achieved by a computer-implemented method for providing data, comprising the features of claim 1.

[0022] Advantageous or preferred embodiments are the subject of dependent claims 2-9.

[0023] The instances can be assigned to various participants, such as a supplier, a plant manufacturer, a quality manager, and a notifying body. The first instance is the one that starts a blockchain by creating the first data block. By using proof-of-authority, the required computing power is reduced compared to proof-of-work authentication, and it is also possible to update the blockchain more quickly by adding new data blocks. A proof-of-authority grants an instance the authority to validate transactions (e.g., through validators) and include them in blocks. The proof-of-authority can be provided by the first instance. Alternatively or additionally, it can also be stipulated that subsequent instances can provide proof-of-authority.

[0024] Verifying the proof of authority involves submitting the data block to be added to the blockchain, along with the proof of authority, to the other instances. These instances verify the proof of authority and, if successful, grant permission to add the data block to the blockchain. A criterion can be specified for this permission, for example, that half of the instances must grant permission.

[0025] The inventive method achieves the following advantages: 1. Tamper-proof: The implicit tamper-proof nature of blockchain architecture enables the digitization of certification stamps. 2. Quality: Human error is minimized by transferring workflows into digital processes and automating them. 3. Integrity in collaboration: High trust between participating parties is established through a high level of access authorization and the tamper-proof nature of the stored data. 4. Data availability and access speed: Digitization in a distributed, automatically replicated database achieves unprecedented data speed. 5. Transparency and auditability: Structuring and modularizing data in digital processes allows for a better understanding of content and flow. Auditability is simplified, and investment risk becomes calculable and reduced.The operator's insurance premiums decrease. 6. Acceleration: Planning, construction, and commissioning can be significantly accelerated; document processing and on-site inspections are eliminated. Measures to maintain production can be initiated immediately. 7. Effort and cost reduction: Automation within the blockchain offers additional efficiency gains in workflows for all parties.

[0026] Furthermore, due to the retention of the basic certification process (verification of the data by auditors or notified bodies) and high-quality authentication, the impact of an attack on the human-machine interface can be well detected and thus limited.

[0027] Complete digitization now allows for the exchange of non-document-like data between stakeholders. This means that proprietary software data formats can be exchanged and used for purposes such as testing. For example, the program developed for a fail-safe controller can be submitted to TÜV as a proprietary Simatic file, including the associated checksum. TÜV can then check this file for errors, for example, in a test simulation, without disclosing its testing mechanisms and tools. This improves the quality of the testing and, consequently, the safety of the systems.

[0028] This function can be significantly simplified by agreeing on and using vendor-neutral data formats.

[0029] Additionally, traditional documentation in the form of PDF documents or similar can also be stored in the blockchain, so that traditional paper documentation can be generated from the blockchain, e.g., at relevant milestones (design freeze, building acceptance, preliminary handover, etc.).

[0030] Smart contracts are software-based agreements that can contain a wide variety of contractual terms. During the contract's lifespan, certain linked actions (e.g., payouts) can be executed automatically when a corresponding trigger occurs (e.g., fulfillment of contractual conditions). For example, the blockchain can be used to provide error handling measures. If a component of a system, such as a field device, malfunctions, the corresponding error signal triggers the data block structured as a smart contract. This then initiates appropriate error handling measures, such as deactivating the defective field device and notifying the customer about its replacement.

[0031] For a transparent and globally accepted application of the described technology, smart contracts can be published as open source code wherever possible. Publication (via Git Hub) serves to facilitate the review, testing, and improvement of the technology, thereby also enhancing the security of products and systems. By providing the source code, including the associated checksum of the compiled smart contract, users can verify the use of smart contracts on a blockchain at any time, thus reducing disputes.

[0032] This results in the following advantages: 1. New automated protective measures: By linking the current compliance status online in the blockchain, new autonomous protective measures can be triggered during plant operation (e.g., initiating a plant shutdown), which also incorporate management aspects of safety. 2. Self-documentation: Through the integration of product-specific smart contracts, safety-related properties can be documented and verified during planning and execution (e.g., in configuration management according to safety integrity level SIL). 3. New services in the area of ​​plant safety and compliance: The technology enables new digital services in the area of ​​product and system safety, which can be implemented with this platform.

[0033] According to one embodiment, the test trigger signal requests a test signal. In other words, the smart contract causes a test signal to be generated within a predetermined time period. This automates the test triggering process.

[0034] In another embodiment, a test signal is provided by the smart contract. The test signal is generated by the smart contract itself. Therefore, no further intervention is required, for example, to manually trigger a test signal. Instead, the test signal is generated automatically.

[0035] According to another embodiment, the smart contract provides a reset signal. This ensures that, following a successful test, the system is returned to a state that corresponds to the state before the test.

[0036] According to another embodiment, the smart contract provides a feedback signal. This feedback signal updates the blockchain and archives and publishes the successfully passed test.

[0037] According to another embodiment, the peer-to-peer network is a private network. Therefore, the blockchain is a federated blockchain or consortium blockchain, i.e., a non-public blockchain.

[0038] According to another embodiment, the proof-of-authority verification has at least a limited validity period. Limited validity means that the proof-of-authority verifications have an expiration date, and after this date, any subsequent authority can no longer add further data blocks to the blockchain. This can, for example, reflect the requirement that proof of an audit must be provided within a predetermined timeframe. Furthermore, this prevents misuse, as the proof-of-authority verifications do not have an unlimited lifespan.

[0039] According to another embodiment, the proof of authority has at least substantive validity. Substantive validity means that the proof of authority only authorizes predetermined inputs, such as confirmation that an audit has been conducted. In other words, the proof of authority is subject-matter bound. This also helps to prevent misuse.

[0040] According to another embodiment, the proof-of-authority verification has at least user-specific validity. User-specific validity means that the proof-of-authority verifications only authorize a specific, predetermined instance to make predetermined inputs, such as confirmation that an audit has been conducted. In other words, the proof-of-authority verifications are individualized or user-specific.

[0041] According to another embodiment, one of the data blocks is designed as a smart contract that provides proof-of-authority evidence upon the fulfillment of a predetermined condition. For example, one of the data blocks can be configured to provide proof-of-authority evidence upon the fulfillment of a predetermined condition. Thus, not only does the first instance generate the proof-of-authority evidence, but the respective proof-of-authority evidence is only generated and provided once the predetermined conditions of a preceding step, such as proof of intermediate tests or preliminary checks, have been verified by an entry in the blockchain. This eliminates the need to generate proof-of-authority evidence "in advance" and securely archive it to prevent unauthorized access, thereby increasing security.

[0042] According to another embodiment, a correction function is provided for modifying and / or marking at least one data block. This can be achieved using a smart contract that, upon explicit consent from all parties involved, identifies or highlights errors or incorrect data. For example, this can then enable interpretation in cases of incorrect content.

[0043] Furthermore, the invention includes such a system and computer program products. A first computer program product can be provided for a first instance, while a second computer program product is provided for the subsequent instances. A third computer program product can be a smart contract that provides an error handling measure upon the occurrence of a predetermined error condition and / or triggers a functional test upon the occurrence of a test trigger signal.

[0044] According to another aspect, the invention relates to a computer-implemented method for testing a technical system, in particular for conformity tracking, comprising the following steps: Loading and / or executing a test control transaction, wherein ∘ in particular the test control transaction is loaded from a network application, ∘ the test control transaction includes control commands and reference data; controlling a test module, wherein ∘ the control commands control the test module in such a way that a test signal for a subsystem of the technical system is generated; acquiring measurement data for the subsystem in response to the test signal, wherein ∘ the measurement data is acquired by the test module, ∘ in particular the measurement data is acquired by a sensor of the test module; calculating a test result based on the measurement data and the reference data; controlling the technical system depending on the test result and / or executing a control function depending on the test result.

[0045] According to another embodiment, a test trigger signal (37) requests the loading and / or execution of the test control transaction.

[0046] According to another embodiment, the activities of the system and / or the test module are recorded and stored in a log file or data record or in transactions.

[0047] According to another embodiment, the test control transaction includes a smart contract or is a smart contract.

[0048] According to another embodiment, a reset signal (42) is provided for the subsystem depending on the test result, or the control function provides a reset signal (42) for the subsystem depending on the test result.

[0049] According to another embodiment, a feedback signal (40) is provided for the subsystem depending on the test result, or the control function provides a feedback signal (40) for the subsystem depending on the test result.

[0050] According to another embodiment, for example, the test result is stored in a confirmation transaction.

[0051] Alternatively or additionally, the measurement data can be stored in a measurement data transaction.

[0052] Alternatively or additionally, the test result is calculated based on the measurement data from the measurement data transaction. Alternatively or additionally, the confirmation transaction and / or the measurement data transaction and / or the test control transaction are secured by a respective proof of authority. For example, the confirmation transaction and / or the measurement data transaction is secured by a proof of authority from the technical system, the subsystem, or the plant operator. For example, the test control transaction is secured by a proof of authority from an entity, a trusted entity (e.g., TÜV), or a third party. Alternatively or additionally, the confirmation transaction and / or the measurement data transaction and / or the test control transaction are stored in a respective data block.Alternatively or additionally, supplementary / metadata for verification purposes is stored in a confirmation transaction. Alternatively or additionally, the respective data block includes, for example, the respective proof-of-authority evidence for the corresponding transaction.

[0053] According to another embodiment, the network application is executed in or by the peer-to-peer network (1), wherein in particular the peer-to-peer network (1) is a private network.

[0054] According to another embodiment, the proof-of-authority evidence (10) has at least a limited period of validity.

[0055] According to another embodiment, the proof-of-authority evidence (10) has at least a substantive validity.

[0056] According to another embodiment, the proof-of-authority evidence (10) has at least user-related validity.

[0057] According to another embodiment, a data block (4a, 4b, 4c) is designed as a smart contract which provides the proof-of-authority proof (10) upon the existence of a predetermined condition.

[0058] According to another embodiment, a healing function is provided for changing and / or marking at least one of the data blocks (4a, 4b, 4c).

[0059] According to another aspect, the invention relates to a system for providing data, comprising means for carrying out the steps of the method according to any one of claims 1 to 12.

[0060] According to another aspect, the invention relates to a device or system for testing a technical system, in particular for conformity tracking, comprising: For example, a loading module, wherein: ∘ for example, the loading module is configured to load and / or execute a test control transaction, ∘ for example, the test control transaction is loaded from a network application, ∘ for example, the test control transaction includes control commands and reference data; for example, a test module, wherein: ∘ for example, the test module is configured to be controlled by means of the control commands, ∘ for example, the control commands control the test module in such a way that a test signal for a subsystem of the technical system is generated; for example, a sensing module, wherein: ∘ for example, the sensing module is configured to acquire measurement data for the subsystem in response to the test signal, ∘ for example, the measurement data is acquired by the test module, ∘ for example, the measurement data is acquired by a sensor of the test module; ∘ for example, the sensing module is the sensor;For example, a calculation module, wherein, for example, the calculation module is configured to calculate a test result based on the measurement data and the reference data; for example, a control module, wherein, for example, the control module is configured to control the technical system depending on the test result and / or to execute a control function depending on the test result.

[0061] According to another aspect, the invention relates to a computer program product comprising instructions which, when the program is executed by a computer, cause it to perform at least one of the steps of claims 1 to 12, wherein the computer is assigned to the first instance (5a).

[0062] According to another aspect, the invention relates to a computer program product comprising instructions which, when the program is executed by a computer, cause it to perform at least one of the steps of claims 1 to 12, wherein the computer is assigned to one of the further instances (5b, 5ca).

[0063] Blockchain technology, also known as distributed ledger technology, is currently a hotly debated topic. It can be implemented as a distributed database system or a network application. Beyond applications for decentralized payment systems (e.g., Bitcoin), new applications are being developed in the financial industry. In particular, transactions between companies can be carried out securely and without intermediaries or clearinghouses, thus protecting them from manipulation. This enables new business models without a trusted intermediary, reduces transaction costs, and allows for the flexible offering of new digital services without the need to establish dedicated infrastructure and trust relationships. A transaction record (or simply transaction) protected by a blockchain includes, for example, program code, which can also be referred to as a "smart contract."

[0064] Unless otherwise specified in the following description, the terms "perform," "calculate," "computer-aided," "compute," "determine," "generate," "configure," "reconstruct," and the like preferably refer to actions and / or processes and / or processing steps that modify and / or generate data and / or convert data into other data, wherein the data may be represented or exist as physical quantities, for example, as electrical impulses. In particular, the term "computer" should be interpreted as broadly as possible to encompass all electronic devices with data processing capabilities.Computers can therefore be, for example, personal computers, servers, programmable logic controllers (PLCs), handheld computer systems, pocket PC devices, mobile phones and other communication devices that can process data using a computer, processors and other electronic devices for data processing.

[0065] In the context of the invention, "computer-aided" can, for example, be understood to mean an implementation of the method in which, in particular, a processor performs at least one process step of the method.

[0066] In the context of the invention, a processor can be understood to mean, for example, a machine or an electronic circuit. A processor can be, in particular, a central processing unit (CPU), a microprocessor, or a microcontroller, for example, an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc. A processor can also be, for example, an integrated circuit (IC), in particular an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit), or a digital signal processor (DSP) or a graphics processing unit (GPU).A processor can also be understood to be a virtualized processor, a virtual machine, or a soft CPU. It can, for example, also be a programmable processor that is equipped with configuration steps for executing the aforementioned method according to the invention, or is configured with configuration steps such that the programmable processor realizes the features of the method, the component, the modules, or other aspects and / or partial aspects of the invention according to the invention.

[0067] In connection with the invention, a "storage unit" or "storage module" and the like can be understood to mean, for example, volatile memory in the form of random-access memory (RAM) or permanent memory such as a hard drive or a data carrier.

[0068] In the context of the invention, a "module" can be understood to mean, for example, a processor and / or a memory unit for storing program instructions. For example, the processor is specifically configured to execute the program instructions in such a way that the processor performs functions to implement or realize the method according to the invention or a step thereof. A module can also be, for example, a node of the distributed database system and / or a network application that, for example, implements the specific functions / features of a corresponding module. The respective modules can also be designed as separate or independent modules. For this purpose, the corresponding modules can, for example, include further elements. These elements are, for example, one or more interfaces (e.g., database interfaces, communication interfaces – e.g.,...).A network interface (e.g., WLAN interface) and / or an evaluation unit (e.g., a processor) and / or a storage unit. The interfaces allow data to be exchanged (e.g., received, transmitted, sent, or made available). The evaluation unit allows data to be compared, checked, processed, assigned, or calculated, for example, using a computer and / or automatically. The storage unit allows data to be stored, retrieved, or made available, for example, using a computer and / or automatically.

[0069] The term "comprise", particularly with regard to data and / or information, can, for example, be understood in connection with the invention as (computer-aided) storage of corresponding information or data in a data structure / data record (which is, for example, stored in a storage unit).

[0070] In the context of the invention, "assigning," particularly with regard to data and / or information, can be understood, for example, as a computer-aided assignment of data and / or information. For instance, a first piece of data is assigned a second piece of data by means of a storage address or a unique identifier (UID), in which, for example, the first piece of data is stored together with the storage address or unique identifier of the second piece of data in a data record.

[0071] In the context of the invention, "providing," particularly with regard to data and / or information, can be understood, for example, as computer-aided provision. Provisioning is carried out, for example, via an interface (e.g., a database interface, a network interface, an interface to a storage unit). Through this interface, corresponding data and / or information can be transmitted, sent, retrieved, and / or received during provision.

[0072] In the context of the invention, "providing" can also refer to, for example, loading or storing a transaction with corresponding data. This can be done, for example, on or from a storage module. "Providing" can also refer to transferring (or sending or transmitting) corresponding data from one node to another in the blockchain or distributed database system (or its infrastructure) or network application.

[0073] In the context of the invention, a "checksum," such as a data block checksum, a data checksum, a node checksum, a transaction checksum, a chain checksum, or the like, can be understood to mean, for example, a cryptographic checksum or cryptographic hash or hash value that is generated or calculated, in particular, by means of a cryptographic hash function over a data record and / or data and / or one or more of the transactions and / or a subset of a data block (e.g., the block header of a block in a blockchain or the data block header of a data block in the distributed database system (or network application), or only a subset of the transactions in a data block). A checksum can, in particular, be a checksum(s) or hash value(s) of a hash tree (e.g., a Merkle tree, a Patricia tree).Furthermore, this can also include, in particular, a digital signature or a cryptographic message authentication code. Checksums can be used, for example, to implement cryptographic protection / tamper protection for transactions and the data (records) stored within them at different levels of the database system. If, for example, a high level of security is required, checksums are generated and verified at the transaction level. If a lower level of security is required, checksums are generated and verified at the block level (e.g., for the entire data block or only for a portion of the data block and / or a subset of the transactions).

[0074] In the context of the invention, a "data block checksum" can be understood as a checksum that is calculated, for example, over part or all of the transactions of a data block. A node can then, for example, verify / determine the integrity / authenticity of the corresponding part of a data block using the data block checksum. Additionally or alternatively, the data block checksum can also be generated, in particular, over transactions of a previous data block / predecessor data block of the data block. The data block checksum can, in particular, also be implemented using a hash tree, for example, a Merkle tree [1] or a Patricia tree, wherein the data block checksum is, in particular, the root checksum of the Merkle tree, a Patricia tree, or a binary hash tree. In particular, transactions are secured by means of further checksums from the Merkle tree or Patricia tree (e.g.,(using the transaction checksums), where the further checksums are, in particular, leaves in the Merkle or Patricia tree. The data block checksum can thus, for example, secure transactions by forming the root checksum from the further checksums. The data block checksum can, in particular, be calculated for transactions of a specific data block of data blocks. In particular, such a data block checksum can be incorporated into a subsequent data block of the specific data block in order to, for example, concatenate this subsequent data block with its preceding data blocks and, in particular, to make the integrity of the distributed database system (or the network application) verifiable. In this way, the data block checksum can, for example, take over the function of the concatenation checksum or be incorporated into the concatenation checksum. The header of a data block (e.g.,a new data block or the data block for which the data block checksum was generated) may, for example, include the data block checksum.

[0075] In the context of the invention, a "transaction checksum" can be understood as a checksum that is generated, in particular, over a transaction of a data block. Additionally, the calculation of a data block checksum for a corresponding data block can be accelerated, since, for example, already calculated transaction checksums can be used directly as leaves of, for instance, a Merkle tree.

[0076] The invention provides, for example, checksums (e.g., transaction checksums) for pre-standardized or predefined safety-related functions (e.g., for testing the subsystem or a function or safety function of the subsystem). Such safety-related functions are, for example, the same across the systems (e.g., the technical system) and are preferably adapted to the specific system. With a system-specific adaptation, a new checksum for the corresponding adapted safety-related function results. The adapted safety-related function and / or the associated checksum is used, for example, throughout the system's lifetime and / or as a reference for modifications. For example, the structure of the system and / or safety-related functions is mapped using the Merkle tree and its structure.

[0077] In the context of the invention, a "chaining checksum" can be understood as a checksum that, in particular, identifies or references a respective data block of the distributed database system (or network application) to the preceding data block of the distributed database system (or network application) (often referred to in the literature as a "previous block hash") [1]. For this purpose, a corresponding chaining checksum is generated for the respective preceding data block. For example, a transaction checksum or the data block checksum of a data block (i.e., an existing data block of the distributed database system or network application) can be used as the chaining checksum to chain a new data block with an (existing) data block of the distributed database system (or network application).It is also possible, for example, to calculate a checksum based on the header of the preceding data block or on the entire preceding data block and use it as a chain checksum. This can also be calculated for several or all preceding data blocks. It is also possible, for example, to calculate the chain checksum based on the header of a data block and the data block checksum. However, each data block of the distributed database system (or network application) preferably includes a chain checksum calculated for, or relating to, a preceding data block, and more preferably, the immediately preceding data block of that data block. It is also possible, for example, to calculate a corresponding chain checksum based on only a portion of the corresponding data block (e.g., the preceding data block).This allows, for example, the creation of a data block comprising an integrity-protected part and an unprotected part. This would make it possible to create a data block whose integrity-protected part is immutable, while whose unprotected part can be modified later (e.g., to store personal data in the unprotected part). Integrity protection in this context means, in particular, that any modification of integrity-protected data can be detected using a checksum.

[0078] The data stored in a data block transaction, for example, can be provided in various ways. Instead of the data itself, such as user data like measurement data or data / ownership information for assets, a data block transaction might only contain the checksum for that data. This checksum can be implemented in different ways. For example, it could be a data block checksum of a data block (containing the corresponding data) from another database or the distributed database system (or network application), a transaction checksum of a data block containing the corresponding data (from the distributed database system / network application or another database), or a data checksum calculated directly from the data.

[0079] Additionally, the corresponding transaction can include a reference or indication of a storage location (e.g., the address of a file server and information on where the corresponding data can be found on the file server; or the address of another distributed database / network application that contains the data). The corresponding data could then, for example, also be provided in a further transaction of another data block of the distributed database system / network application (e.g., if the corresponding data and the associated checksums are contained in different data blocks). It is also conceivable, however, that this data could be provided via a different communication channel (e.g., via another database and / or a cryptographically secured communication channel).

[0080] In addition to the checksum, a supplementary data record (e.g., a reference or information about a storage location) can also be stored in the corresponding transactions, specifying in particular a storage location where the data can be retrieved. This is especially advantageous for keeping the data size of the blockchain or the distributed database system / network application as small as possible.

[0081] In the context of the invention, "security-protected" can refer, for example, to protection that is implemented, in particular, by a cryptographic method. This can be achieved, for instance, by using the distributed database system (or the network application) for providing, transmitting, or sending the corresponding data / transactions. This is preferably achieved by combining various (cryptographic) checksums, which, in particular, work synergistically together to improve, for example, the security or cryptographic security of the transaction data. In other words, "security-protected" in the context of the invention can also be understood as "cryptographically protected" and / or "tamper-proof," with "tamper-proof" also being referred to as "integrity-protected."

[0082] In the context of the invention, “concatenating data blocks of a distributed database system / network application” can, for example, be understood to mean that data blocks each comprise information (e.g. concatenation checksum) that refers to or points to another data block or several other data blocks of the distributed database system (or network application) [1][4][5].

[0083] In the context of the invention, "inserting into the distributed database system / network application" and the like can be understood, for example, as transmitting a transaction or transactions, or a data block containing its transactions, to one or more nodes of a distributed database system / network application. If these transactions are successfully validated (e.g., by the node(s)), they are concatenated as a new data block with at least one existing data block of the distributed database system / network application [1][4][5]. For this purpose, the corresponding transactions are stored, for example, in a new data block. In particular, this validation and / or concatenation can be performed by a trusted node (e.g., a mining node, a blockchain oracle, or a blockchain platform).In particular, a blockchain platform can be understood as a blockchain as a service, as proposed by Microsoft and IBM. Specifically, a trusted node and / or a node can each embed a node checksum (e.g., a digital signature) in a data block (e.g., in the data block they validate and generate, which is then chained together) to enable identification of the data block's creator and / or the node itself. This node checksum indicates which node, for example, chained the corresponding data block with at least one other data block in the distributed database system (or network application).

[0084] In the context of the invention, "transaction" or "transactions" can refer, for example, to a smart contract [4] [5], a data structure, or a transaction record, which in particular comprises one or more transactions. "Transaction" or "transactions" in the context of the invention can also refer, for example, to the data of a transaction within a data block of a blockchain.

[0085] A transaction can, in particular, comprise program code that, for example, implements a smart contract. For instance, in the context of this invention, a transaction can also be understood as a control transaction and / or a confirmation transaction. Alternatively, a transaction can be, for example, a data structure that stores data (e.g., control commands and / or contract data and / or other data such as video data, user data, measurement data, etc.).

[0086] Specifically, terms like "storing transactions in data blocks," "storing transactions," and similar terms refer to direct or indirect storage. Direct storage can mean, for example, that the corresponding data block (of the distributed database system / network application) or the corresponding transaction of the distributed database system / network application contains the respective data. Indirect storage can mean, for example, that the corresponding data block or transaction contains a checksum and optionally an additional data record (e.g., a reference or a location reference) for the corresponding data, and thus the corresponding data is not directly stored in the data block (or transaction) (i.e., only a checksum for this data is stored).In particular, when storing transactions in data blocks, these checksums can be validated, for example, as explained under "Inserting into the distributed database system / network application".

[0087] In the context of the invention, "program code" (e.g., a smart contract or chain code) can be understood to mean, for example, one or more program instructions, which are stored, in particular, in one or more transactions. The program code is, in particular, executable and is executed, for example, by the distributed database system / network application. This can be realized, for example, by means of an execution environment (e.g., a virtual machine), wherein the execution environment or the program code is preferably Turing-complete. The program code is preferably executed by the infrastructure of the distributed database system / network application [4][5]. For example, a virtual machine is implemented by the infrastructure of the distributed database system (or the network application).

[0088] In the context of the invention, a "smart contract" can be understood to mean, for example, executable program code [4][5] (see in particular the definition of "program code"). The smart contract is preferably stored in a transaction of a distributed database system / network application (e.g., a blockchain), for example, in a data block of the distributed database system (or the network application). For example, the smart contract can be executed in the same way as explained in the definition of "program code," particularly in the context of the invention.

[0089] In the context of the invention, "smart contract process" can be understood in particular as the execution of program code (e.g., control commands) in a process by the distributed database system / network application, wherein, for example, the corresponding infrastructure of the distributed database system / network application executes the program code.

[0090] In the context of the invention, "proof-of-work" can be understood, for example, as solving a computationally intensive task that depends in particular on the data block content / content of a specific transaction [1][4][5]. Such a computationally intensive task is also referred to, for example, as a cryptographic puzzle.

[0091] In the context of the invention, a "network application" can refer, for example, to a decentralized distributed database, a distributed database system, a distributed database, a peer-to-peer application, a distributed storage management system, a blockchain, a distributed ledger, a distributed storage system, a distributed ledger technology (DLT)-based system (DLTS), an audit-proof database system, a cloud, a cloud service, a blockchain in a cloud, or a peer-to-peer database. Different implementations of a blockchain or a DLTS can also be used, such as a blockchain or a DLTS using a directed cyclic graph (DAG), a cryptographic puzzle, a hashgraph, or a combination of these implementation variants [6][7]. Different consensus algorithms can also be implemented.This could be, for example, a consensus mechanism using a cryptographic puzzle, gossip about gossip, virtual voting, or a combination of these methods (e.g., gossip about gossip combined with virtual voting) [6][7]. If, for example, a blockchain is used, it can be implemented using either a Bitcoin-based or an Ethereum-based implementation [1][4][5]. A "distributed database system" or a "network application" can also be understood as a distributed database system or a network application where at least some of its nodes and / or devices and / or infrastructure are implemented in a cloud. For example, the corresponding components are implemented as nodes / devices in the cloud (e.g., as a virtual node in a virtual machine). This can be done, for example, using VMware, Amazon Web Services, or Microsoft Azure.Due to the high flexibility of the implementation variants described, it is particularly possible to combine aspects of the implementation variants mentioned, for example by using a hashgraph as a blockchain, where the blockchain itself can also be blockless.

[0092] For example, when a Directed Acyclic Graph (DAG) is used (e.g., IOTA or Tangle), transactions, blocks, or nodes of the graph are connected to each other via directed edges. This means, in particular, that all edges always have the same direction, similar to how time is measured. In other words, it is not possible to traverse the graph backward (i.e., against the common direction). "Acyclic" here means, specifically, that there are no loops when traversing the graph.

[0093] The distributed database system / network application can be, for example, a public distributed database system / network application (e.g., a public blockchain) or a closed (or private) distributed database system / network application (e.g., a private blockchain).

[0094] For example, if it is a public distributed database system or a public network application, this means that new nodes and / or devices can join or be accepted by the distributed database system or network application without authorization, authentication, login information, or credentials. In particular, the operators of the nodes and / or devices can remain anonymous in such a case.

[0095] For example, if the distributed database system / network application is a closed distributed database system, new nodes and / or devices require, for example, a valid credential and / or valid authentication information and / or valid credentials and / or valid login information to be able to join or be accepted by the distributed database system / network application.

[0096] A distributed database system / network application can also be a distributed communication system for data exchange. This could be, for example, a network or a peer-to-peer network.

[0097] A distributed database system can, for example, also be a decentralized distributed database system and / or a decentralized distributed communication system.

[0098] A "network application" can also refer to a network application infrastructure, or the network application can encompass a corresponding network application infrastructure. This infrastructure can include, for example, nodes and / or communication networks and / or data interfaces and / or other components to implement or execute the network application. The network application can, for example, be a distributed network application (such as a distributed peer-to-peer application or a distributed database system) that runs on multiple nodes of the network application infrastructure.

[0099] In the context of the invention, a "data block," which may also be referred to as a "link" or "block" depending on the context and implementation, can be understood, for example, as a data block of a distributed database system / network application (e.g., a blockchain or a peer-to-peer database), which is implemented as a data structure and preferably comprises one or more transactions. In an implementation, for example, the database (or database system) can be a DLT-based system (DLTS) or a blockchain, and a data block can be a block of the blockchain or the DLTS. A data block can, for example, include information about the size (data size in bytes) of the data block, a data block header, a transaction counter, and one or more transactions [1].The data block header can include, for example, a version, a chain checksum, a data block checksum, a timestamp, a proof-of-work statement, and a nonce (a unique value, random value, or counter used for the proof-of-work statement) [1][4][5]. A data block can also be, for example, just a specific memory area or address range of the total data stored in the distributed database system / network application. This allows, for example, the implementation of blockless distributed database systems / network applications, such as the IoT Chain (ITC), IOTA, and Byteball. In this context, the functionalities of blockchain blocks and transactions are combined in such a way that, for example,The transactions themselves, the sequence or chain of transactions (of the distributed database system / network application), are secured (i.e., stored in a security-protected manner). For this purpose, for example, the transactions themselves can be linked together using a chain checksum. This can preferably be achieved by using a separate checksum or the transaction checksum of one or more transactions as a chain checksum, which is stored in the corresponding new transaction when a new transaction is saved in the distributed database system / network application. In such an embodiment, a data block can, for example, also contain one or more transactions, with one data block corresponding to one transaction in the simplest case.

[0100] In the context of the invention, "nonce" can refer, for example, to a cryptographic nonce (an abbreviation for "used only once"[2] or "number used once"[3]). In particular, a nonce denotes a single combination of numbers or letters that is preferably used only once in the respective context (e.g., transaction, data transmission).

[0101] In the context of the invention, "preceding data blocks of a (specific) data block of the distributed database system / network application" can, for example, refer to the data block of the distributed database system / network application that directly precedes a (specific) data block. Alternatively, "preceding data blocks of a (specific) data block of the distributed database system / network application" can also refer to all data blocks of the distributed database system / network application that precede the specific data block. This allows, for example, the chain checksum or the transaction checksum to be calculated specifically for the data block (or its transactions) directly preceding the specific data block, or for all data blocks (or their transactions) preceding the first data block.

[0102] In the context of the invention, a "blockchain node," "node," "node of a distributed database system / network application," and the like can be understood to mean, for example, devices (e.g., field devices, mobile phones), computers, smartphones, clients, or participants that perform operations (with) the distributed database system / network application (e.g., a blockchain) [1][4][5]. Such nodes can, for example, execute transactions of a distributed database system / network application or its data blocks, or insert or chain new data blocks with new transactions into the distributed database system / network application. In particular, this validation and / or chaining can be performed by a trusted node (e.g., a mining node) or exclusively by trusted nodes.A trusted node is, for example, a node that has additional security measures in place (e.g., firewalls, access restrictions to the node, or similar) to prevent manipulation of the node. Alternatively or additionally, when concatenating a new data block with the distributed database system / network application, a trusted node can store a node checksum (e.g., a digital signature or a certificate) in the new data block. This provides proof that the corresponding data block was inserted by a specific node or indicates its origin. Regarding the devices (e.g.,The term "device" refers, for example, to devices within a technical system and / or industrial plant and / or automation network and / or manufacturing plant, which are also, in particular, nodes of the distributed database system / network application. These devices can be field devices or Internet of Things (IoT) devices, which are also nodes of the distributed database system / network application. Nodes can also include at least one processor to execute their computer-implemented functionality.

[0103] In the context of the invention, a "blockchain oracle" and the like can be understood to mean, for example, nodes, devices, or computers that have a security module. This module may include, for example, software protection mechanisms (e.g., cryptographic methods), mechanical protection devices (e.g., a lockable housing), or electrical protection devices (e.g., tamper protection or a protection system that deletes the data of the security module in the event of unauthorized use / handling of the blockchain oracle). The security module may, for example, include cryptographic keys necessary for calculating checksums (e.g., transaction checksums or node checksums).

[0104] In the context of the invention, a "computer" or a "device" can be understood to mean, for example, a computer (system), a client, a smartphone, a device, or a server, each of which is located outside the blockchain or is not a participant in the distributed database system / network application (e.g., the blockchain) (i.e., it does not perform any operations on the distributed database system / network application or only queries it without carrying out transactions, inserting data blocks, or calculating proof-of-work proofs). Alternatively, a computer can also be understood to mean, in particular, a node of the distributed database system / network application. In other words, a device can be understood to mean, in particular, a node of the distributed database system / network application or a device outside the blockchain or the distributed database system / network application.A device outside the distributed database system / network application can, for example, access the data (e.g., transactions or control transactions) of the distributed database system / network application and / or be controlled by nodes (e.g., via smart contracts and / or blockchain oracles). If, for example, a node controls or manages a device (e.g., a device configured as a node or a device outside the distributed database system / network application), this can be done, for example, via a smart contract, which is stored, in particular, in a transaction of the distributed database system / network application. A computer or device can also be part of the infrastructure that, for example, executes, implements, or comprises the network application or the distributed database system.

[0105] Furthermore, the following terms can be understood, for example, in the context of the invention as follows.

[0106] A "fail-safe control system" (which can also be referred to as a safety-related system) can be understood, for example, as a system (e.g., according to DIN EN 61508-4:2002-11) that both performs the necessary safety functions required to achieve or maintain a safe state for the EUC and is also intended to achieve the necessary safety integrity for the required safety functions, either on its own or with other safety-related systems and other risk-reducing measures.

[0107] A fail-safe control system can be, for example, a programmable electronic system for protection or monitoring. Such a control system can include, for example, one or more programmable electronic devices, including one, several, or all elements of the system, such as power supplies, sensors and other input devices, data links and other communication channels, as well as actuators and other output devices.

[0108] In the context of the invention, "EUC" (en: equipment under control) can refer, for example, to a device, machine, apparatus or system that is used, for example, for manufacturing, material processing, transport, medical or other activities.

[0109] In connection with the invention, a "safety function" or "protective circuit" can be understood, for example, as a function that is performed, e.g., by a safety-related system or other risk-reducing measures, and is intended to achieve or maintain a safe state for the EUC, taking into account a defined hazardous incident.

[0110] In connection with the invention, a "protection logic" (which can be referred to as safety-related software) can be understood to mean, for example, software and / or program code and / or an application that is used to perform safety functions and / or additionally to perform test functions in a safety-related system and / or in a fail-safe controller.

[0111] In the context of the invention, a "safe state" can be understood, for example, as the state of the EUC in which safety (e.g., a predetermined operational safety of the technical system) is achieved.

[0112] In the context of the invention, a "test module" can be understood to mean, for example, a test device or test harness, or a device that is capable (to a reasonable extent) of simulating the operating environment of the software or hardware during development by applying test cases to the software and recording the response. The test module can also include, for example, test case generators and devices for verifying the test results (either automatically against values ​​assumed to be correct, or by manual analysis).

[0113] In the context of the invention, a "control signal" can be understood, for example, as a signal that is transmitted between the software and / or hardware components involved for the purpose of carrying out tests.

[0114] In the context of the invention, a "trigger" can be understood, for example, as an initiator that, according to specifications and / or reference data, initiates and / or controls the safety-related function and / or the test device. A trigger can be, for example, a person who activates the safety-related function or software that, for example, causes it through simulation in the sensor (e.g., the so-called HART function of intelligent field devices).

[0115] In connection with the invention, "reference data" can be understood to mean, for example, specifications and / or requirements that are specified for a protective circuit by an entity (e.g., the notified body), such as the duration between triggering and reaching the safe state.

[0116] A preferred embodiment of the method according to the invention is explained below with reference to the accompanying schematic drawings. These show: Fig. 1 a schematic representation of a peer-to-peer network, Fig. 2 a schematic representation of one in which in Fig. 1 The peer-to-peer network shown used blockchain technology. Fig. 3 a schematic representation of a memory expansion for performance improvement, Fig. 4 a schematic representation of a process flow, Fig. 5 a schematic representation of a further process flow concerning an application in systems in process or manufacturing plants within the framework of plant planning, Fig. 6 a schematic representation of a procedure for a functional test, Fig. 7 a schematic representation of a further procedure for a functional test, Fig. 8 a schematic representation of a further procedure for a functional test, Fig. 9 and Fig. 10 show a further embodiment of the invention.

[0117] It will initially be on Fig. 1 Reference made to.

[0118] Shown is a distributed peer-to-peer network 1, which is designed to implement a computer-implemented method for providing data, in the present embodiment for compliance tracking of a system or plant.

[0119] In the present embodiment, the peer-to-peer network 1 comprises four nodes 2a, 2b, 2c, 2d.

[0120] In this context, a peer-to-peer network 1 is understood to be a computer network in which all nodes 2a, 2b, 2c, 2d are equal, in contrast to a computer network with a client-server architecture.

[0121] Each of the nodes 2a, 2b, 2c, 2d can be connected to a computer or a cloud computer. The resulting computing power of the overall system forms the hardware basis.

[0122] For compliance tracking of a system or plant, only a limited and specifically authorized group of users needs access to the data. Therefore, in this example – as will be explained in detail later – a private blockchain is created.

[0123] In the Fig. 1 In the scenario shown, the first node 2a is assigned to a supplier, the second node 2b to a factory or plant constructor, the third node 2c to an inspector or notifying body, and the fourth node 2d to an operator.

[0124] Each node 2a, 2b, 2c, 2d contains not only hardware components but also software components in the form of computer program products, which are blockchain software (stack), whose tasks and functions will be explained in detail later.

[0125] Furthermore, a user interface may be provided for conformity tracking, or existing planning, engineering, or project management software may be integrated. In the latter case, the user interface of existing software (e.g., COMOS – a unified database platform for plant manufacturers) is adapted so that the required conformity information, along with corresponding metadata, can be published in a distributed ledger or retrieved as needed to enable further processing.

[0126] A distributed ledger is a specific form of electronic data processing and storage. A distributed ledger, or "distributed ledger," is a decentralized database that allows network participants shared read and write access. Unlike a centrally managed database, this network does not require a central authority to make new entries. New data records can be added by the participants themselves at any time. A subsequent update process ensures that all participants always have access to the latest version of the database. A specific type of distributed ledger is a blockchain.

[0127] It will now also be applied to Fig. 2 Reference made to.

[0128] The diagram shows Blockchain 3. Blockchain 3 is understood to be a continuously expanding list of data records that are linked together using cryptographic methods. Each block typically contains a cryptographically secure checksum of the previous block, as well as, optionally, a timestamp and other transaction data.

[0129] In the present embodiment, blockchain 3 comprises a first data block 4a containing a first data record, a second data block 4b containing a second data record, and a third data block 4c containing a third data record. During a conformance tracking process, the first data block 4a is generated in a first step, thus starting blockchain 3. In subsequent steps, the second data block 4b containing the second data record and the third data block 4c containing the third data record are added, thereby extending blockchain 3.

[0130] Each of the data blocks 4a, 4b, 4c is assigned a corresponding checksum 6a, 6b, 6c, such as a hash value. To determine the checksum 6a, 6b, 6c, a hash function such as the SHA-256 algorithm (Secure Hash Algorithm) can be used.

[0131] The data records of the respective data blocks 4a, 4b, 4c each contain a block number 7a, 7b, 7c representing the respective position in the blockchain 3, one or more digital signatures 8a, 8b, 8c representing the respective user, data 9a, 9b, 9c relating to compliance tracking, such as test certificates etc., and the respective checksum 6a, 6b, 6c of the previous data block 4a, 4b.

[0132] Thus, the first data block 4a, being the first data block 4a, does not have a checksum of a predecessor block, while the second data block 4b has the first checksum 6a of the first data block 4a and the third data block 4b has the second checksum 6b of the second data block 4b.

[0133] The first data block 4a is assigned to a first instance 5a, in this exemplary embodiment the supplier 11, while the second data block 4b is assigned to a second instance 5b, e.g. the factory / plant manufacturer 12, and the third data block 4c is assigned to a third instance 5c, e.g. the notifying body 14. Other assignments are also possible.

[0134] The first instance 5a, i.e., the instance that starts the blockchain 3 with the first data block 4a, is intended in the present embodiment to issue proof-of-authority proofs 10. In other words, the first instance 5a can be considered the origin or base instance.

[0135] The proof-of-authority evidence 10 is transmitted to the other instances 5b and 5c. The proof-of-authority evidence 10 enables the other instances 5b and 5c to add further data blocks 4b and 4c to blockchain 3.

[0136] The proof-of-authority evidence 10 can have a limited validity period and / or a content-related validity and / or a user-related validity.

[0137] A limited validity period means that the proof-of-authority evidence 10 has an expiration date, and after this date has passed, one of the other instances 5b, 5c is no longer able to add further data blocks 4b, 4c to the blockchain 3. This can, for example, reflect the requirement that proof of an audit must be provided within a predetermined timeframe. Furthermore, this prevents misuse, as a proof-of-authority evidence 10 does not have an unlimited lifespan.

[0138] Substantive validity means that the proof-of-authority documents only authorize predetermined entries, such as confirmation that an audit has been conducted. In other words, the proof-of-authority documents are subject-matter bound. This also helps to prevent misuse.

[0139] User-specific validity means that the proof-of-authority evidence 10 only authorizes a specific, predetermined instance 5a, 5b, 5c to make predetermined entries, such as confirmation that an audit has been conducted. In other words, the proof-of-authority evidence 10 is individualized or user-specific.

[0140] It is also possible that one of the data blocks 4a, 4b, or 4c is implemented as a smart contract. Smart contracts are software-based agreements in which a wide variety of contractual terms can be defined. During the contract's term, certain linked actions (e.g., payouts) can be executed automatically when a corresponding trigger (e.g., fulfillment of contractual conditions) occurs.

[0141] Thus, one of the data blocks 4a, 4b, 4c can be configured to provide a proof-of-authority document 10 upon the occurrence of a predetermined condition. Therefore, not only does the first instance 5a generate the proof-of-authority documents 10, but the respective proof-of-authority documents 10 are only generated and provided once the predetermined conditions of a preceding step, such as proof of intermediate tests or preliminary checks, have been met. This eliminates the need to generate proof-of-authority documents 10 "in advance" and securely archive them to prevent unauthorized access, thereby increasing security.

[0142] Furthermore, one of the data blocks 4a, 4b, 4c can be configured to provide an error handling measure in the event of a predetermined error. For example, blockchain 3 can be used to provide error handling measures. If a component of a system, such as a field device, malfunctions, the corresponding error signal triggers the data block 4a, 4b, 4c, which is configured as a smart contract. This triggers an appropriate error handling measure, such as deactivating the defective field device and notifying the user for replacement. Additionally, a remediation function is provided for modifying one or more of the data blocks 4a, 4b, 4c.

[0143] Since a limited number of known participants are involved, a dedicated smart contract with a remediation function can be implemented to address errors in the technology's implementation. With the explicit consent of all participants, this function identifies or highlights errors or incorrect data. This can be advantageous in the initial implementation phase. In the event of data reduction or a technically necessary migration, the transfer of data storage to a newly initiated Blockchain 3 can be planned.

[0144] It will now also be applied to Fig. 3 Reference made to.

[0145] The diagram illustrates mass data processing for performance improvement. A replication system 24, such as IPFS, can be used for this purpose, where, for example, a pointer is encrypted and archived in the blockchain 3, which refers to corresponding storage areas of the replication system 24. This can be viewed as an operating system or a distributed and highly available runtime environment.

[0146] It will now be further referred to Fig. 4 An example of a process flow is explained.

[0147] The process is divided into three phases: a first phase I compliant design and planning, a second phase II compliant construction, and a third phase III compliant operation, maintenance and care.

[0148] In the first phase I, the supplier 11, the plant manufacturer 12, a quality manager 13 and the notifying body 14 are involved in the present embodiment.

[0149] In the second phase II, in the present embodiment, a plant manufacturer (assembly 15) and another notifying body 16 are involved.

[0150] In the third phase III, the operator 17, another notifying body 18 and a supervisory authority 19 are involved in the present embodiment.

[0151] After a distributed peer-to-peer network 1 has been set up, in the first phase I of the present embodiment, supplier 11, as the first instance 4a, creates, for example, the first data block 4a for the blockchain 3 with a first checksum 6a. Furthermore, supplier 11, as the first instance 4a, creates the proof-of-authority evidence 10.

[0152] In contrast to the present embodiment, the blockchain can also be initiated by the operator 17 or by the supervisory authority 19, such as TÜV, on behalf of the operator 17, since the operator 17 is the first party responsible for ensuring the plant's conformity. Therefore, the following parties must be authorized to feed data into the blockchain 3: the operator 17, then the supervisory authority 19 (such as TÜV or other authorities), then the plant manufacturer 12, then its supplier 11, and then various other stakeholders. The operator 17 or the supervisory authority 19 can administer who is authorized to publish and / or read data and when. The order of data provision depends on the respective regulatory requirements, the necessary technical systems, and many other plant-specific constraints.

[0153] In a further step, the plant engineer 12, as a second instance 4b, generates, for example, the further data block 4b with a further checksum 6b, and in a further step, the quality manager 13 generates the further data block 4c with a further checksum 6c.

[0154] The checksums 6a and 6b from the previous data block 6a and 6b are inserted into the respective subsequent data blocks. Thus, the checksum 6a from the first data block 4a is inserted into the next data block 4b, and the further checksum 6b is inserted into the next data block 4c.

[0155] The further data blocks 4b, 4c will only be added to the blockchain 3 after the plant manufacturer 12 has authorized itself as the second instance 4b and the quality manager 13 with a respective proof-of-authority 10.

[0156] Afterwards, Blockchain 3 is available to all the aforementioned participants, and copies of Blockchain 3 are further distributed to all nodes 2a, 2b, 2c, 2d.

[0157] In a further step, the notifying authority 14, after verifying the documentation archived in blockchain 3, creates a certificate 20 and adds it to blockchain 3, for example as a document such as a PDF, after authorizing itself with a respective proof of authority 10. The certificate 20 is then available for inspection by all the aforementioned parties. Furthermore, copies of blockchain 3 are distributed to all nodes 2a, 2b, 2c, and 2d.

[0158] In the second phase II, the circle of participants is enlarged to include the plant manufacturer Montage 15 and the additional notifying body 16, which are provided with respective proof-of-authority evidence 10 for this purpose.

[0159] Plant manufacturer Montage 15 generates another data block with an additional checksum and adds it to Blockchain 3 after authorizing itself with its proof-of-authority document 10. Subsequently, notified body 16, after verifying the documentation archived in Blockchain 3, adds a certificate 21 to Blockchain 3, again after authorizing itself with its proof-of-authority document 10. Alternatively, this can also be done by the plant manufacturer instead of the notified body.

[0160] In the third phase III, the circle of participants is increased again, namely to include the operator 17, the further notifying body 18 and the supervisory authority 19, which are provided with respective proof-of-authority evidence 10 for this purpose.

[0161] If necessary, the operator 17 generates another data block (not shown), e.g. for documenting proper maintenance and testing.

[0162] Subsequently, the further notifying body 18 and the supervisory authority 19, after each verifying the documentation archived in the blockchain 3, add further certificates 22, 23 to the blockchain 3, after authorizing themselves with their proof-of-authority evidence 10.

[0163] Thus, Blockchain 3 provides a virtually tamper-proof, distributed (because replicated) and therefore highly available data storage and execution environment in which compliance tracking can now be carried out automatically.

[0164] It will now also be pointed out that Fig. 5 Reference is made to illustrate a further example of its application in systems within process or manufacturing plants during the planning of the plant.

[0165] In process plants, the blockchain 3 and the data that can be stored with its help are an integral part of the process plant, comparable to the traditional audit documentation maintained with the plant. The blockchain 3 is maintained, for example, by the responsible owner / possessor or operator 17 in their capacity as the first instance 5a. In other words, participants can change their roles; that is, the role or function of the first instance 5a passes from the suppliers 11 to the operator 17.

[0166] For this purpose, the operator 17 initiates the creation or maintenance of the blockchain 3 and administers the necessary smart contracts 29a, 29b, 29c. Required parties, e.g., the plant manufacturer 12, its suppliers 11, the notified body 14, the supervisory authority 19, etc., are authorized to contribute information according to their role. Authentication is provided by the blockchain 3 and can be further extended if necessary, e.g., by two-factor authentication or shared multi-party keys.

[0167] The selection and implementation of the necessary / desired smart contracts 29a, 29b, 29c can be initiated and controlled by the responsible party, e.g., the operator 17. If necessary, they can utilize a competent partner, such as the notified body 14, which validates and releases these smart contracts.

[0168] At the beginning of the process, for example, the operator 17 and a planner, such as the plant manufacturer 12, specify relevant requirements for the blockchain 3 of the factory / plant, e.g., together with the supervisory authority 19 and the notifying body 14, regarding functional safety, pressurized components, explosion protection, emissions, CE marking, and other requirements. Subsequent expansion through the addition of further smart contracts is taken into account.

[0169] These processes are carried out independently and autonomously.

[0170] A manufacturer 25 of products, e.g. of fail-safe controllers, makes standardized smart contracts 29a, 29b, 29c publicly available for its product types 26a, 26b, 26c together with respective product documentation 30a, 30b, 30c, e.g. in an online catalog 31, which include documentation of suitability, such as a certificate from an auditor.

[0171] Certification of product types 26a, 26b, 26c can also be carried out here by a notified body 14 via the blockchain 3.

[0172] The Smart Contracts 29a, 29b, 29c enable the automated verification of planning, execution and support repeatable checks as part of compliance tracking.

[0173] Manufacturers of planning tools load these smart contracts 29a, 29b, 29c into their planning systems 28, such as COMOS or Teamcenter, via a suitable interface as library components.

[0174] Firstly, safety-relevant properties, e.g. the existing certificate 20, are made available and the correct integration of the products into dds planning system 28 or tools is ensured.

[0175] The product-specific certified smart contracts 29a, 29b, 29c are encrypted, but the source code is viewable and verifiable via a checksum (not shown), such as a hash, also in the planning system 28 (or later during compliance tracking in the blockchain 3). This ensures transparency and auditability.

[0176] As part of the plant planning process, the plant manufacturer now integrates the products in accordance with their specified properties. The planning system 28 ensures compliant use.

[0177] When instantiating the products for a specific plant, a unique plant-related reference identifier is assigned in planning system 28.

[0178] To release a solution configured in planning system 28, the product configuration 32 is now published in the conformity tracking system from planning system 28. Configuration 32, pre-checked by planning system 28, can optionally be further reviewed and approved by the notified body 14 and issued with a certificate 33.

[0179] The associated smart contracts 29a, 29b, 29c have now reached the "Released Planning" milestone and are therefore ready for confirmation of compliant implementation.

[0180] The physical products / devices are designed in such a way that they can now make the required implementation code available via a readable key or a suitable identifier on the component. This can be, for example, a combination of suitability for the required safety integrity level (SIL level), the instance number / serial number, the manufacturer, and the product type, which were transferred to the product during manufacturing. These codes are read from the implemented system and transferred to Blockchain 3 for documentation. Smart contracts 29a, 29b, and 29c verify this and confirm conformity autonomously. If necessary, a final check is carried out by the notified body 14.

[0181] This provides a self-certifying and automated configuration management system that ensures the correct use of the products.

[0182] It will now be further elaborated with reference to the Fig. 6 bis 8 A procedure for functional testing is explained.

[0183] The focus will now initially be on Fig. 6 Reference made to.

[0184] Shown is a protection logic 34 of a fail-safe controller 41 and a blockchain 3 embedded in a runtime environment 35 as well as a smart contract 36.

[0185] During operation, a test trigger signal 37 triggers the smart contract 36, which in turn generates a test signal 38 that is applied to the protection logic 34. The result is a trigger signal 39.

[0186] Furthermore, a feedback signal 40 is generated to update the blockchain 3.

[0187] Upon receiving feedback signal 40, the test result is archived in blockchain 3.

[0188] It will now also be applied to Fig. 7 Reference made to.

[0189] The in Fig. 7 The scenario depicted differs from the one in Fig. 6 The scenario depicted is characterized by the fact that the test trigger signal 37 must be manually present within a time window predetermined by the smart contract 36 and acts on a sensor 43, such as an emergency stop button, of a safety circuit 27. Thus, the safety circuit 27 is monitored, which in the present embodiment additionally includes an actuator 44, such as a steam valve actuator, and a sensor 45, such as a sensor for detecting an end position.

[0190] Additionally, a reset signal 42 is generated by the smart contract 36 to reset the protection logic 34. The reset signal 42 restores the protection logic 34 to the state it was in before the functional test.

[0191] Furthermore, a feedback signal 40 is generated to update the blockchain 3.

[0192] It will now also be applied to Fig. 8 Reference made to.

[0193] Higher-quality systems sometimes offer a pre-built test facility, such as a test logic 46, to allow this test to be repeated during the operating period of the system (usually when it is shut down).

[0194] The in Fig. 8 The scenario depicted differs from the one in Fig. 7 by the fact that the smart contract 36 itself provides the test signal 38 and connects to the test logic 46 for the protection logic 34.

[0195] Thus, during a functional test, the correct interaction of the individual components, such as sensors 43, 45, transmission, detection, protection logic 34, trigger signal 39, transmission and actuators 44, can be ensured. This is carried out for the first time before acceptance.

[0196] Through a trigger signal 39, which can be documented in Blockchain 3, this functional test, along with the logging of the signals and the devices involved, allows a successful and compliant functional test to be performed automatically and registered or confirmed in Blockchain 3. This requires suitable logic in the control system (control system), which must be appropriate for this purpose (typically validated and approved by TÜV).

[0197] Additionally, a component of the fail-safe control system is required that can transmit events to Blockchain 3. This is the event triggering the protection (input), possibly processing states, and the setting of the outputs.

[0198] These states, along with the necessary metadata (automation device, timestamp, etc.), are transferred directly to Blockchain 3, enabling evaluation and documentation of the results. The transfer can be encrypted, for example.

[0199] In conjunction with an active, fault-tolerant program code that can be uniquely identified in the blockchain 3 via the checksum 6a, 6b, 6c, complete documentation of the process is possible.

[0200] The checksums 6a, 6b, 6c are preferably separate checksums and / or individual checksums that were generated, for example, for a corresponding program code.

[0201] Alternatively or additionally, in conjunction with the documentation of the fault-tolerant program code active at the time of the test, which is secured against modification in the protection system via its own checksum, a complete and seamless documentation of the process can be achieved by including this checksum in the blockchain.

[0202] To fully capture the protection logic 34 (including the physical aspects), e.g., the closing of a valve, further measurements may need to be included in the functional test. This could be the cessation of flow, a drop in pressure, or feedback of the end position of a fitting.

[0203] Since a fail-safe component with so-called channel drivers forms the interface to the corresponding input / output card, the physical implementation of the entire fail-safe system, including the input / output cards, cabling, bus system, and field devices, cannot be automatically read and documented without a new function in the control system. However, by incorporating intelligent field devices (HART, Profibus), at least the inclusion of these areas is possible. For this purpose, the control system can, for example, read encrypted identifiers from the devices and document them in Blockchain 3 along with the test values ​​of the fail-safe controller.

[0204] If still necessary, the notified body 14 can now support the evaluation of the data available in blockchain 3 and grant formal approval.

[0205] Operator 17 is essentially still responsible for the overall management (administration of the smart contracts 29a, 29b, 29c, authorization and role distribution) of the cooperation and for initiating the necessary measures.

[0206] The execution of a recurring functional test can be carried out in the control system of a power plant by the verified fail-safe system. The control system is programmed so that a recurring test is triggered automatically after a configurable period or manually by a switching action of the authorized operator.

[0207] The successful test result (here e.g. test of the triggering of standstill operation by an emergency stop button) is documented in a tamper-proof manner in the blockchain 3 using a smart contract 29a, 29b, 29c.

[0208] If the functional test fails or is not triggered within the required test interval, the Blockchain 3 can automatically interrupt plant operation (automatic shutdown) or trigger a corresponding official notification after a correspondingly defined time has elapsed (see also IEC 61508-1 Chapter 6.2.5).

[0209] Another automatable function is the comparison of plans released for execution with the actual execution in the area of ​​mechanical components, e.g. pressurized components.

[0210] By using appropriate data formats, such as 3D data from the execution planning, an automated comparison of the target and actual states (photographed or 3D-scanned real-world execution) can trigger automated commissioning approval. For this purpose, a verified camera (verified = a camera product or software tested and approved by TÜV for this purpose) can be used based on blockchain technology, providing tamper-proof images in Blockchain 3.

[0211] Another embodiment is described in the Fig. 9 and 10 depicted.

[0212] Specifically, a computer-implemented method and / or system for testing a technical system is presented, whereby the method or system is particularly suitable for conformity monitoring of the technical installation. For example, a subsystem, such as an actuator (e.g., a pneumatic actuator 44 of the steam quick-closing valve of the technical system), or several devices are tested to determine whether they meet specified requirements. A device and / or a subsystem can, for example, be a protective circuit of the technical system and / or be part of the protective circuit of the technical system to be tested and / or be the protection logic 34.

[0213] The system comprises a test module (e.g., a test device) of a fail-safe controller 41 and a runtime environment 35 in the form of a network application (e.g., a blockchain), as well as a test control transaction 36, which is implemented, for example, at least partially as a smart contract. The test module can be implemented, for example, via the protection logic 34, as a component of the network application, or as a smart contract. Alternatively, the protection logic 34 can include or correspond to the test module. Alternatively, the test module includes the protection logic 34.

[0214] During operation, a test trigger signal 37 triggers the test control transaction 36. This can be done, for example, by a first entity AT1 via a data interface I. The entity AT1 could be, for example, a blockchain oracle that provides a corresponding trigger or transmits it to the network application. Alternatively, the entity AT1 could also be a person, a test user, or software for automated testing of the technical system.

[0215] The trigger may be activated, for example, by a sensor reading exceeding a predefined threshold or by a time-based control mechanism. There may be multiple types of triggers, each performing different tests or checks on a device within the system. The trigger encodes which test is to be performed on which device. For instance, the type and / or scope of a permissible test is defined by a relevant (authorized) entity (e.g., the notified body), which may specify the required trigger and / or relevant reference data.

[0216] The test control transaction 36 includes control commands and / or reference data to check a corresponding device of the technical system (e.g. a plant, a process plant, an automation system).

[0217] For example, multiple tests or checks for a device can be encoded / included in test control transaction 36 or other test control transactions. A corresponding test control transaction includes corresponding device-specific and / or test-specific control commands and / or reference data, whereby the corresponding device-specific and / or test-specific control commands and / or reference data are selected by means of the trigger. In other words, corresponding test control transactions can encode device-specific and / or test-specific tests and / or checks for devices of the technical system, whereby a corresponding test and / or check is selected by means of data that the trigger includes or encodes.

[0218] The trigger loads the test control transaction 36 relevant for a test or inspection. This test control transaction 36 can, for example, be loaded into the test module, or the network application, the test control transaction 36, or a smart contract can generate a control signal. The network application and / or the test control transaction 36, the smart contract, the protection logic 34, and / or other components of the system can then... Fig. 9 The systems shown may include the test module in whole or in part, depending on which component, e.g., which function of the test module, is implemented.

[0219] Depending on which component generates the signal and to which component the signal is transmitted, the control signal can be implemented differently. For example, if the network application, the test control transaction 36, or the smart contract generates the control signal, the control signal can be implemented as a test signal 38. If the protection logic 34 generates the control signal, the control signal can be implemented as a trigger signal 39.

[0220] For example, if a test signal 38 is generated, it is applied to the protection logic 34. The result is, for example, a trigger signal 39.

[0221] The control signal generated during a test or verification is preferably specific for a test or verification of a function of the devices involved in the protection circuit and / or the devices integrated in the protection circuit themselves.

[0222] The protective circuit includes sensor 43 and / or 45, which provide measurement data 40a and 40b. Sensor 43 provides, for example, measurement data from the process being monitored, which may also be simulated for testing purposes. Sensor 45 provides, for example, measurement data that can be acquired in response to the control signal (e.g., a test signal) and / or the activation of the protective effect.

[0223] These measurement data 40a, 40b are acquired by the test module, whereby the sensors 43, 45 are communicatively connected to the test module, e.g., via a bus or input / output modules IF, or the sensors 43, 45 transmit the measurement data 40a, 40b directly to the test module. For such data communication, or further communication between the components of the system, the technical system, or the network application, the system shown includes several data interfaces IF to enable the corresponding data exchange.

[0224] For example, the pneumatic actuator 44 is actuated by the trigger signal 39 and the steam quick-release valve is closed.

[0225] Alternatively or additionally, the trigger signal 39 or the control signal controls an entity by means of which the pneumatic actuator 44 or the corresponding test can be performed.

[0226] In another variant, the test is performed semi-automatically, with the entity being a computer that indicates to a test user that the protective effect of the "overspeed" protection circuit should be tested. For this purpose, the test user moves the actuator of the quick-closing valve, and its position is detected by sensor 45 (e.g., a position sensor).

[0227] A test result is then determined based on the measurement data and the corresponding reference data. This determination can be performed, for example, by the test module or test control transaction 36. During this test, it is determined, for example, whether the measurement data meets, falls below, or exceeds the reference data. If the measurement data matches the reference data, the corresponding test is considered passed. If the measurement data deviates from the reference data, for example, by a permissible tolerance value, the corresponding test can be marked as passed and stored in the test result. If the measurement data deviates from the reference data and / or exceeds a corresponding tolerance value, the corresponding test is marked as failed and is preferably stored in the test result.

[0228] Depending on the test result, the technical system and / or the device is controlled and / or a control function is executed. For example, if the device meets the specifications defined by the reference data, the technical system and / or the device is put into an operational state. In other words, if the test is passed, the technical system and / or the device is, for example, put into operation, or an operating mode of the device or the technical system is activated for use via the control function, or the operating authorization is extended by another interval.

[0229] In variants of the invention, multiple tests or inspections can be performed on the device and / or other devices of the technical system and the test results stored. Only when, for example, a predetermined number of tests or inspections (e.g., 100% of all tests or inspections, or 80% of all tests) and / or predetermined specific tests or inspections (e.g., safety-critical tests must be passed 100%) are completed, is the technical system controlled and / or the device controlled and / or a control function executed. For example, only then is the technical system and / or the device put into an operating mode that allows its use (e.g., regular operational operation). In a power plant, this could, for example, involve activating control functions that allow the power plant to start up so that it can operate at full load or enter regular grid operation.

[0230] The measurement data 40a, 40b from sensors 43, 45 can, for example, represent a feedback signal. The measurement data 40a, 40b can encode, comprise, or be implemented as a corresponding feedback signal.

[0231] In some variants, the measurement data 40a, 40b are acquired and used to update the network application (e.g., the blockchain 35) by, for example, storing the corresponding measurement data 40a, 40b in a feedback signal 40 and transmitting it from the protection logic 34 or the test module to the test control transaction 36 or the network application. For this purpose, the measurement data 40a, 40b can first be transmitted to the protection logic 34 or the test module. The protection logic 34 or the test module then stores the measurement data 40a and / or the measurement data 40b and / or the test result in the feedback signal 40 and transmits it, for example, to the test control transaction 36 or the network application.

[0232] The feedback signal 40 or the communication between protection logic 34 and test control transaction 36 and / or the network application can, for example, contain test-related information (e.g., identification and diagnostic data of the runtime environment 41 of the protection logic) for documentation and archiving purposes.

[0233] In other variants, the test result (which can also be referred to as the test result) is archived in the network application (e.g. the blockchain 3) in response to the measurement data 40a, 40b.

[0234] In other variations, for example, the test result is stored in a confirmation transaction. Additionally or alternatively, the measurement data is stored in a measurement data transaction. Additionally or alternatively, the test result is calculated based on the measurement data from the measurement data transaction. Additionally or alternatively, the confirmation transaction and / or the measurement data transaction and / or the test control transaction are secured by a respective proof of authority. Additionally or alternatively, the confirmation transaction and / or the measurement data transaction and / or the test control transaction are stored in a respective data block. Additionally or alternatively, the respective data block includes, for example, the respective proof of authority for the corresponding transaction.

[0235] The test result can be stored, for example, by means of a corresponding confirmation transaction and can be transmitted to a corresponding entity (e.g., a notifiable body or a trusted entity) as message P or as the confirmation transaction (e.g., in step S13 or the data from step S13). Fig. 10 ).

[0236] In another variant, the system includes a monitoring module, which is configured to store the activities of the system and / or the test module in a log file or a data record or in transactions.

[0237] For example, the invention can be used as follows. Since the time for the re-testing of the technical system (e.g., a power plant) as determined by TÜV is expiring, proof of a successful functional test must be provided.

[0238] A smart contract (e.g., test control transaction 36) associated with the protection circuit exists, which, according to the specifications of the certified body (TÜV), can process the requirements regarding the trigger signal and protective effect, as well as the time specification and, if applicable, coefficients (e.g., protection system without fault). For this purpose, test control transaction 36 includes the necessary control commands and reference data. Additionally, test control transaction 36 can include the test module or control the test module.

[0239] In its initial state, test control transaction 36 did not trigger the protection logic (S1). The protection logic's feedback to the smart contract is: Protection not triggered (S1a). Therefore, the system is not blocked and is ready for a functional test. Testing procedure:

[0240] An authorized tester AT1, e.g. an employee of the certified body or testing software, activates the test mode (test trigger signal 37) via the data interface I (e.g. a web interface).

[0241] The smart contract (which can also be referred to as program code, program commands, or chain code) active for overspeed protection in test control transaction 36 activates a timer (e.g., a 30-minute test window) and waits for feedback that the protection has been triggered ("Speed ​​> X" measurement data 40a of sensor 43) and that the protective effect has occurred ("Quick-closing valve feedback Closed" measurement data 40b of sensor 45). For this purpose, the smart contract or test control transaction 36 can be executed with the smart contract, and the test module can be controlled as described above.

[0242] Additionally, the smart contract and / or the test control transaction 36 and / or the test module checks, based on the timestamps of the measurement data 40a, 40b, whether the response was achieved within the reference data, i.e., the specified reference time (e.g., 10 seconds).

[0243] For example, another entity AT2 (e.g., a person, a controlled device, or a software component) can trigger the protection by actually generating the critical process state while the plant is at a standstill or by simulation at sensor 43 (S2).

[0244] The trigger signal (S3) registered in the protection logic 34 is transmitted to the smart contract and / or the test control transaction 36 and / or the test module (S4). The protection logic 34 is activated and triggers the protection command (S5 command "CLOSED" signal 39). The valve should therefore be closed (to reduce the turbine speed) by transmitting the protection command to the actuator 44 (e.g., the actuator of the steam quick-closing valve) (S5). Additionally, the protection logic transmits the successful trigger (S6) to the test control transaction 34. The steam quick-closing valve closes, and the position sensor 45 reports "CLOSED" (S7 = measurement data 40b) back to the protection logic and / or the test control transaction 36 and / or the test module (S8). The feedback on whether a safe state has been requested and achieved is therefore recorded by sensors 43, 45 and the corresponding measurement data 40a, 40b. This can, for example,Depending on the chosen implementation, the data may also be transferred to the smart contract and / or the test control transaction 36 and / or the test module. The smart contract and / or the test control transaction 36 and / or the test module then calculate the test result, taking the reference data into account.

[0245] The following results may occur during the verification or calculation process, which are preferably stored in the test result and / or control the technical system depending on the test result and / or execute a control function: Successful:

[0246] If the triggering (measurement data 40a) and protective effect (measurement data 40b) change from 0 to 1 in the correct sequence within the specified reference time (e.g., 20 seconds), a successful test (S13) is documented (with timestamps) – in other words, measurement data 40a and 40b demonstrate compliance with the specifications (reference data). This evaluation is preferably performed by the test module.

[0247] The protection circuit's functional enable via the smart contract and / or test control transaction 36 and / or the test module remains active until the next recurring test. This enable is set in the protection logic (S9). This is preferably controlled by executing the control function based on the test result. Test not completed:

[0248] If the test window time (e.g., 30 minutes) has elapsed and no trigger signal (38 or 40a) is registered in the smart contract and / or in test control transaction 36 and / or in the test module (S4), the expired test is documented (e.g., by creating or saving corresponding transactions in the network application) (S13). The test can then be repeated (37). If a successful test is not reported in a timely manner via the smart contract and / or test control transaction 36 and / or the test module (e.g., a predefined period for submitting a successful test is exceeded) (S10), another entity AT3 (e.g., a certified body) receives a corresponding notification and becomes active (S13). If the repeated test is successful, the other entity is informed of this repeated successful test (S13).This can be achieved, for example, through appropriate transactions of the network application and / or documented. The additional entity AT3 could be, for example, software or a person from a certification authority who, depending on the audit result, controls the technical system and / or executes or releases a control function for the technical system. Test failed:

[0249] If the test is not completed correctly, one possible measure is to permanently trigger the protection command via the smart contract, preventing the quick-closing valve from opening. This can be achieved, for example, by executing the control function (S10) depending on the test result, which enforces the protective action (quick-closing valve command "CLOSED"). Thus, the system is blocked by the protection logic 34. This state is transmitted to the test control transaction 36 and / or the test module (S12) and documented and monitored there.

[0250] For example, the system can be released again by means of a reset mechanism in the smart contract and / or in the protection logic and / or in the test control transaction 36 and / or in the test module to cancel the protection command (S11).

[0251] Since the report of an unsuccessful test is stored in the blockchain and transferred to the responsible parties (e.g., entity AT3), troubleshooting and error correction can be carried out under supervision.

[0252] The smart contract and / or the test control transaction 36 and / or the test module can, for example, be configured such that resetting the smart contract and / or the test control transaction 36 and / or the test module is only possible by the assigned authority or the certified body (e.g., the further entity AT3) (key management and authorization in the blockchain). This can be done, for example, by means of corresponding transactions of the network application and / or be documented.

[0253] In another variant, the sensor 43 and / or the sensor 45 includes a processor or a microcontroller to generate simulated sensor data 40a, 40b and to test the technical system, the device, or a response of the technical system or the device to simulated sensor data 40a, 40b. A sensor with a processor or microcontroller can also be referred to as a smart sensor. In other words, this variant relates, for example, to a computer-implemented method in which a test signal 38 or a control signal is provided by the smart contract and / or the test control transaction 36 and / or the test module, wherein the test control transaction 36 and / or the test module preferably includes the smart contract.

[0254] For example, the smart contract itself generates the test signal or control signal. Therefore, no further intervention is required, e.g., to manually trigger a test signal. Rather, the test signal is generated automatically.

[0255] For example, the sensor 43 can be replaced by an intelligently designed sensor 43, such as an intelligent pressure gauge with a simulation function. This allows, for example, the monitoring of the safety circuit 27, which in the present embodiment additionally includes an actuator, such as a steam quick-closing valve, and a sensor 45, such as a sensor for detecting an end position.

[0256] In another implementation, the test is triggered automatically by the smart contract: In a suitable state of the technical system (e.g., standstill), which is signaled to the smart contract by the protection logic, a test trigger signal 37 automatically triggers the smart contract 36. The protection logic and / or the test module are controlled by the smart contract or the test control transaction in such a way that a test signal 38 is generated. This then triggers the protection via the protection logic 34, if necessary. The successful protection action is registered in the protection logic and / or the test module, and the corresponding measurement data is then stored in the network application (e.g., the blockchain).

[0257] A functional test for an overspeed protection system with automatic triggering using intelligent sensors can be implemented as follows: Initial state:

[0258] Since the time for re-testing as determined by TÜV is expiring, proof of a successful functional test must be provided again.

[0259] A smart contract exists, assigned to the protection circuit or device, which, according to the specifications of the certified body (TÜV), can process the requirements regarding the trigger signal and protective effect, as well as the time specification and, if applicable, coefficients (e.g., protection system without fault and technical system at standstill). This is preferably encoded in the reference data and control commands of the test control transaction. Accordingly, the test control transaction can either include the smart contract or correspond to it.

[0260] The smart contract did not trigger the protection logic or the device in its initial state. The feedback from the protection logic to the smart contract is: Protection not activated. Therefore, the system is not blocked and is ready for a functional test. Testing procedure process:

[0261] An authorized tester, e.g., an employee of the certified body (e.g., entity AT1), activates the test mode via the data interface I (e.g., a communication interface) with the corresponding signal 37.

[0262] The smart contract triggers – for example, via the protection logic – a simulation 38 in sensor 45 (e.g., configured as an intelligent sensor) to activate the protection and simultaneously sets a timer (e.g., a 10-minute test window) that monitors the test process and retracts the simulation after a defined time has elapsed or after the test has ended. Sensor 45 then provides the protection logic and / or the test module with measurement data that simulates the impermissible process state. The protection logic reacts to this simulated measurement data, and the reaction of the protection system to this simulated measurement data is monitored as described.

[0263] The smart contract now monitors, based on the feedback, whether the protection has been triggered ("Speed ​​>X" Signal 40a) and whether the protective effect has occurred ("Quick-closing valve feedback Closed" Signal 40b).

[0264] Additionally, the smart contract uses the timestamps of the signals to check whether the response was achieved within the specified time.

[0265] For example, the trigger signal 39, generated in the protection logic, is also transmitted to the smart contract. The protection logic is activated and triggers the protection command (command CLOSED 39). The steam quick-closing valve closes and reports "CLOSED" (signal 40b) back to the protection logic. This is also transmitted to the smart contract. Successful:

[0266] If the trigger (40a) and protective effect (40b) change from 0 to 1 in the correct sequence within the specified time, a successful test is documented (with timestamps). The smart contract enables the protective circuit's function. The simulation in the functional logic is reset.

[0267] For example, an electrical measurement value can be generated in the sensor or test module for a simulation (HART simulation). The turbine speed is 0. However, the encoder or the corresponding sensor then delivers, for example, 12 mA corresponding to 10,000 RPM, and this triggers the protection or a corresponding safety function.

[0268] The functional release of the protection circuit by the Smart-Contract 36 remains in effect until the next recurring test. Test failed:

[0269] If cause and effect are not achieved in the correct sequence and time interval, or if the test window (10 minutes) has expired and no trigger signal 40a is registered in the smart contract, an error occurs, for example, because the simulation did not trigger. These corresponding specifications can be stored in the reference data, for example.

[0270] One possible measure is to permanently trigger the protection command via the smart contract, preventing the quick-closing valve from opening. After the fault has been rectified, the system must be reactivated via a reset mechanism in the smart contract and the protection logic.

[0271] Since the report of an unsuccessful test is stored in the blockchain and transmitted to the responsible parties, troubleshooting and error correction can be carried out under supervision.

[0272] The smart contract can be designed in such a way that resetting it is only possible by the assigned authority or the certified body (key management and authorization in the blockchain). Further embodiments are shown below:

[0273] comprising a device or system for testing a technical system, in particular for conformity tracking: For example, a loading module, wherein: ∘ the loading module is configured to load and / or execute a test control transaction, ∘ the test control transaction is loaded from a network application, ∘ the test control transaction includes control commands and reference data; for example, a test module, wherein: ∘ the test module is configured to be controlled by means of the control commands, ∘ the control commands control the test module in such a way that a test signal for a subsystem of the technical system is generated; for example, a sensing module, wherein: ∘ the sensing module is configured to acquire measurement data for the subsystem in response to the test signal, ∘ the measurement data is acquired by the test module, ∘ the measurement data is acquired by a sensor of the test module; ∘ the sensing module is the sensor;For example, a calculation module, wherein, for example, the calculation module is configured to calculate a test result based on the measurement data and the reference data; for example, a control module, wherein, for example, the control module is configured to control the technical system depending on the test result and / or to execute a control function depending on the test result.

[0274] The loading module and / or the test module and / or the calculation module and / or the control module can, for example, be implemented as separate hardware and / or software modules. Alternatively or additionally, these modules are designed as a smart contract and can, for example, be fully or partially implemented by the protection logic and / or the test control transaction.

[0275] In another variant, the detection module is formed by sensors 43 and 45.

[0276] In another variant, the calculation module and / or the control module is formed by the test module and / or the protection logic (explained in previous examples).

[0277] In another variant, the charging module is implemented by the test module and / or the network application (explained in previous examples).

[0278] In another variant, the system or device includes a monitoring module, wherein the monitoring module is configured to store the activities of the system and / or the test module in a log file or record or in transactions.

[0279] The device or system (or the other embodiments and their variants) may, for example, additionally comprise one or more further components, such as a processor, a memory unit, further communication interfaces (e.g., Ethernet, WLAN, USB, fieldbus, PCI), an input device, in particular a computer keyboard or a computer mouse, and a display device (e.g., a monitor). The processor may, for example, comprise several further processors, which can be used in particular to implement further embodiments.

[0280] Another embodiment relates to a computer-implemented method for providing data, in particular for compliance tracking, in a distributed peer-to-peer network (1), comprising the steps: Providing at least one initial data block (4a), in particular with data representative for compliance tracking, to generate a blockchain (3) with an initial checksum (6a) by an initial instance (5a) of the peer-to-peer network (1); providing at least one proof-of-authority proof (10) to verify a further data block (4b, 4c); generating the further data block (4b, 4c) representative for compliance tracking with a further checksum (6b, 6c) and at least the first checksum (6a) by another instance (5b, 5c) of the peer-to-peer network (1); verifying the proof-of-authority proof (10); adding the further data block (4b, 4c) to the first data block (4a) upon successful verification of the proof-of-authority proof (10) to form the blockchain (3); and making the blockchain (3) available in the distributed peer-to-peer network (1) wherein one of the data blocks (4a, 4b, 4c) is designed as a smart contract (36, 29a, 29b, 29c) which provides an error handling measure in the event of a predetermined error case and / or triggers a functional test in the event of a test trigger signal (37).

[0281] In one variant of the embodiment, the computer-implemented method requests the test trigger signal (37) and a test signal (38).

[0282] In one variant of the embodiment, the test signal (38) is provided by the smart contract (36, 29a, 29b, 29c).

[0283] In one variant of the embodiment, the smart contract (36, 29a, 29b, 29c) provides a reset signal (42).

[0284] In one variant of the embodiment, the smart contract (29a, 29b, 29c) includes a feedback signal (40).

[0285] In one variant of the embodiment, the peer-to-peer network (1) is a private network.

[0286] In one variant of the embodiment, the proof-of-authority evidence (10) has at least a limited period of validity.

[0287] In one variant of the embodiment, the proof-of-authority evidence (10) has at least substantive validity.

[0288] In one variant of the embodiment, the proof-of-authority proof (10) has at least user-related validity.

[0289] In one variant of the embodiment, a data block (4a, 4b, 4c) is designed as a smart contract, wherein the smart contract provides the proof-of-authority proof (10) upon the existence of a predetermined condition.

[0290] In one variant of the embodiment, a healing function is provided for changing and / or marking at least one of the data blocks (4a, 4b, 4c).

[0291] Another embodiment involves a system for providing data, wherein the system is a means for carrying out the steps of the procedure according to the aforementioned embodiment and / or one of its variants.

[0292] Another embodiment relates to a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to execute at least one of the steps of the aforementioned embodiment and / or one of its variants, wherein the computer is assigned to the first instance (5a).

[0293] Another embodiment relates to a computer program product comprising instructions which, when the program is executed by a computer, cause it to execute at least one of the steps of the aforementioned embodiment and / or one of its variants, wherein the computer is assigned to one of the further instances (5b, 5c).

[0294] Another form of implementation concerns a computer program product comprising instructions which, when the program is executed by a computer, cause it to perform at least one of the steps of the embodiment mentioned and / or one of its variants of a smart contract (29a, 29b, 29c).

[0295] Scanning or recording and image processing allows for the capture of a wide variety of characteristics (material identification, manufacturing marks, etc.), which can be used for automated testing or certification with Smart Contracts 29a, 29b, 29c. [1] Andreas M. Antonopoulos "Mastering Bitcoin: Unlocking Digital Cryptocurrencies", O'Reilly Media, December 2014 [2] Roger M. Needham, Michael D. Schroeder "Using encryption for authentication in large networks of computers" ACM: Communications of the ACM. Band 21, Nr. 12 Dezember 1978, [3] Ross Anderson "Security Engineering. A Guide to Building Dependable Distributed Systems" Wiley, 2001 [4] Henning Diedrich "Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralized Autonomous Organizations", CreateSpace Independent Publishing Platform, 2016 [5] "The Ethereum Book Project / Mastering Ethereum" https: / / github.com / ethereumbook / ethereumbook, Stand 5.10.2017 [6] Leemon Baird "The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance", Swirlds Tech Report SWIRLDS-TR-2016-01, 31.5.2016 [7] Leemon Baird "Overview of Swirlds Hashgraph", 31.5.2016 [8] Blockchain Oracles https: / / blockchainhub.net / blockchain-oracles / Stand 14.03.2018

Claims

1. A computer-implemented method for testing a technical system for conformity tracking, comprising the steps of: - loading and / or executing a test control transaction, wherein ∘ the test control transaction comprises or is a smart contract, ∘ a test trigger signal (37) requests loading and executing the test control transaction, ∘ in particular, the test control transaction is loaded from a network application, ∘ the test control transaction comprises control commands and reference data; - controlling a test module, wherein ∘ the control commands control the test module such that a test signal is generated for a subsystem of the technical system; - acquiring measurement data for the subsystem in response to the test signal, wherein ∘ the measurement data is acquired by the test module, ∘ in particular, the measurement data is acquired by a sensor of the test module; - calculating a test result, wherein ∘ a test result is calculated on the basis of the measurement data and the reference data, - controlling the technical system depending on the test result, and / or executing a control function depending on the test result, wherein - the test result is stored in a confirmation transaction, - the measurement data is stored in a measurement data transaction, - the test result is calculated on the basis of the measurement data of the measurement data transaction, - the confirmation transaction, the measurement data transaction, and the test control transaction are secured by means of a respective proof-of-authority verification, - the confirmation transaction, the measurement data transaction, and the test control transaction are stored in a respective data block of a block chain, - additional / meta data is stored for testing in a confirmation transaction, and - the respective data block includes the respective proof-of-authority verification of the corresponding transaction.

2. The computer-implemented method of claim 1, wherein, depending on the test result, a reset signal (42) is provided for the subsystem, or the control function provides a reset signal (42) for the subsystem depending on the test result.

3. The computer-implemented method of any one of claims 1 or 2, wherein, depending on the test result, a feedback signal (40) is provided for the subsystem, or the control function provides a feedback signal (40) for the subsystem depending on the test result.

4. The computer-implemented method of any one of the preceding claims, wherein - the network application is executed in a peer-to-peer network (1) or is executed by the peer-to-peer network (1), - in particular, the peer-to-peer network (1) is a private network.

5. The computer-implemented method of any one of the preceding claims, wherein the proof-of-authority verification (10) has at least a time-limited validity period.

6. The computer-implemented method of any one of the preceding claims, wherein the proof-of-authority verification (10) has at least one content validity.

7. The computer-implemented method of any one of the preceding claims, wherein the proof-of-authority verification (10) has at least one user-related validity.

8. The computer-implemented method of any one of the preceding claims, wherein a data block (4a, 4b, 4c) is configured as a smart contract providing the proof-of-authority verification (10) if a predetermined condition is met.

9. The computer-implemented method according to any one of the preceding claims, wherein a healing function is provided for altering and / or identifying at least one of the data blocks (4a, 4b, 4c).