Method and apparatus for agreeing on collaboration between a first system and a second system

Abstract

A method (10, 30, 40) for agreeing on a collaboration between a first system (11) and a second system (12), characterized by the following features: ‑ the first system (11) sends (14) the first system (11)'s assumptions about the second system (12) and the first system (11)'s guarantees to the second system (12), ‑ the second system (12) sends (15) the second system (12)'s assumptions about the first system (11) and the second system (12)'s guarantees to the first system (11), ‑ if the mutual assumptions and guarantees correspond to each other, concludes a digital security contract between the first system (11) and the second system (12), and ‑ records the security contract in a transaction database (13).

Description

Technical Field

[0001] The invention relates to a method for agreeing on a collaboration between a first system and a second system. The invention further relates to a corresponding device, a corresponding computer program and a corresponding storage medium. Background Art

[0002] In computer networks, any protocol that leads to agreement (consensus) on the order of certain transactions, for example involving data updates, is called a decentralized transaction system or transaction database (distributed ledger). A common manifestation of such a system uses the blockchain.

[0003] For example, US 9,794,074 B2 discloses a computer system connected to a blockchain. The computer system receives consistency data for consistency between a first data transaction associated with a first identifier and a second data transaction associated with a second identifier. A first blockchain transaction is generated based on the data stored in the blockchain. At least one other blockchain transaction is generated, which divides the consistency into two different transactions: one transaction between the first identifier and a mediator (Vermittler), and the second transaction between the mediators. These are collected in the blockchain via other blockchain transactions. Summary of the invention

[0004] The invention provides a method for agreeing on a collaboration between a first system and a second system, a corresponding device, a corresponding computer program and a corresponding storage medium according to the independent claims.

[0005] The method according to the invention is based on the following understanding: more and more safety-critical systems must cooperate in operation. These systems are sometimes developed by different manufacturers. Therefore, these systems must cooperate with other systems, the performance and characteristics of which are unknown at the time of their design. Examples of such systems are heterogeneous vehicles that are exchanged with each other (austauschen) for example for traffic smoothing or regulation or for emergency services, highly automated trucks that form a convoy and automatically follow a leading truck with a human driver, conditionally automated trucks that form a convoy and automatically follow a leading highly automated truck, snowplows that automatically follow a laterally staggered plow driven by a human on an airport or ski slope, cars that cooperate with a pilot system on a parking lot, agricultural robots that fertilize or harvest fields like a group of people (gleich einem Schwarm) or manufacturing robots that move on the driving surface and cooperate with other robots or even humans to perform common tasks.

[0006] Due to possible hazards, high requirements should be placed on the operational safety of these "systems of systems". To accomplish such dynamic configuration while taking into account safety requirements, so-called safety contracts have been proposed in the literature. At the moment of their design, a series of (formally described) assumptions and guarantees are defined for each system according to this scheme. Under the given assumptions, the guarantees of each system can also be analyzed within the scope of the design using known safety analysis techniques. At runtime, potentially cooperating systems exchange their assumptions and guarantees with each other. Then, each system decides whether the guarantees of the other system correspond to its assumptions. If they are consistent, a safety contract is concluded, which means that as long as the assumptions of each system are met, its own guarantees are also met. The assumptions and guarantees can also contain parameters in order to enable more flexibility.

[0007] For example, two highly automated trucks that are supposed to form a convoy should be considered. Here it should be assumed that the vehicles will be from different manufacturers, but the safety contract format and exchange protocol should already be agreed upon at design time. The assumption of one truck may be that when the truck following it brakes, it is informed within a predefined time interval X. During this time, the guarantee may be that when the truck itself brakes, the truck following it on its side is informed within a predefined time interval Y. Obviously, a safety contract can only be concluded and thus a convoy can only be formed if Y < X, and the two trucks must check this.

[0008] The proposed scheme additionally takes into account the situation where there is generally a risk of system failures. If a system fails, it may violate its guarantee, and if the system cooperates with other systems at the moment of failure, it breaks its safety contract. Although safety contracts have a technical origin, especially because humans are not involved in the conclusion of safety contracts and if different manufacturers are involved, such a situation may give rise to legal problems or require clarification of possible insurance claims.

[0009] In this case, the basic feature of the scheme according to the invention is that each system that has successfully concluded a safety contract with another system creates a data record containing this information and transmits this information to a transaction database. When the other system malfunctions and violates the safety contract by violating the issued guarantee in this way, the other system cannot deny the conclusion of the contract. In this way, legal security is achieved for the manufacturer. The manufacturer does not have to trust a single entity storing the safety contract, however the manufacturer must agree to the proposed protocol and implement it.

[0010] Advantageous developments and improvements of the basic idea described in the independent claim are possible by means of the measures listed in the dependent claims. It can therefore be provided that the participating systems, after accepting the collaboration, each repeatedly send an environment model to the transaction database, and the transaction database adds the environment model to the blockchain. In the event of an error, these data cannot be denied and help to reconstruct the situation. If one of the participating systems fails, it is thus easier for its manufacturer to prove not only that a security contract existed but also that another system has violated it.

[0011] According to a further aspect, it can be provided that the participating systems, after accepting the collaboration, each repeatedly send a decentralized value (hash) of the environment model to the transaction database, and the transaction database only adds these decentralized values ​​to the blockchain. The hash of the environment model has a much smaller size than the entire model and can therefore be sent to the transaction database much faster. In the event of an accident, the manufacturer can prove that the environment documented in the system database has not been changed.

[0012] According to another aspect, it can be provided that the systems establish a mutual transaction channel, via which they exchange information and signed notifications after receiving the block with the security contract. This concept reduces the scope of communication with the transaction database, thereby typically reducing transaction costs (in the form of cryptocurrency). In addition, in the event of an error, it can be automatically identified which system actually violated the security contract, and the fine can be automatically settled with the deposit (in the form of cryptocurrency) that the two systems had to raise when creating the digital contract. Because the last agreed information and its timestamp are known and stored in the transaction database, the aforementioned embodiment also improves legal security in the event of an accident.

[0013] According to another aspect, it can be provided that the blockchain of the transaction database is distributed over a number of terminals and that the systems participating in the security contract manage digital wallets from which they pay the terminals for adding blocks. With such wallets, it is possible to pay "explorers" (miners), wherein the participating systems can pay these prospectors an amount that is inversely proportional to the time required to verify the information relevant for legal security and to add it to the blockchain. Furthermore, if the participating systems pay for the money involved in this way or if they themselves provide services to other systems, for example in the case of a vehicle driving ahead, wherein the vehicle driving ahead helps the following vehicle to estimate the possibility of an overtaking maneuver on the other side of a bend ahead and is paid for this, a true "economy of things" (EoT) can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Embodiments of the invention are shown in the drawings and are explained in more detail in the following description.

[0015] Figure 1 A method is shown according to which two systems agree on a legal collaboration with the aid of a blockchain.

[0016] Figure 2 A variant of the method is shown in which the transaction database is equipped with computing functions and thus can draw up a security contract.

[0017] Figure 3 A variant of the method is shown, in which the systems set up an intelligent channel for exchanging information. In this case, one system sends information that the other system considers to be erroneous. With the help of the calculation function of the digital contract in the transaction database, it can be checked which system is legitimate (im Recht) and which one has the final vote winning (überstimmend) information.

[0018] Figure 4 A control device according to the invention is shown schematically. DETAILED DESCRIPTION

[0019] Figure 1 The timeline of two systems (11, 12) of different manufacturers of a distributed transaction database (13) is shown. The systems (11, 12) communicate with the distributed transaction database (13) via an Internet connection; the communication between the systems (11, 12) takes place directly from vehicle to vehicle (car to car, C2C) or also via an Internet connection. First, the two systems (11, 12) exchange their assumptions and guarantees (14, 15), and each system checks (16, 17): whether the assumptions and guarantees are consistent, that is, whether a safety contract can be concluded. If this is the case, each system (11, 12) sends a data record (18, 19) to the transaction database (13). The respective data record (18, 19) can contain basic information that a safety contract has been concluded and the characteristics or all of the agreed assumptions and guarantees. Since both systems (11, 12) create data records (18, 19), each data record (18, 19) may contain an identification (identifier, ID) of the "other party" (12 or 11).

[0020] This ID should be unique within the distributed transaction database (13) and be comparable to a so-called wallet ID for a cryptocurrency.

[0021] In the time interval until the data record (18, 19) is accepted into the distributed transaction database (13), two possible paths emerge: either the system (11, 12) accepts the collaboration and renounces the ultimate legal security (Rechtssicherheit) until the data record (18, 19) is added to the blockchain, or the system waits until the data record (18, 19) has been added before cooperating (23). Figure 1 In an embodiment of the present invention, both systems (11, 12) wait until the systems obtain confirmation from the transaction database (13) that the block has been successfully added.

[0022] Once the data records (18, 19) have been deposited in the transaction database (13) and the new block (21) has been received by both systems (11, 12), each system (11, 12) can check (22, 23) whether the other party (12 or 11) has created a consistent data record (19 or 18). If the data record has not been added, the ID of the opposing party is wrong; if the data record has been added but its ID is inconsistent, an error or attack is very likely and the collaboration is abandoned. Figure 1 In the embodiment, the data records (18, 19) of the two systems (11, 12) are consistent and the two systems accept the collaboration (23).

[0023] Now we should consider the following situation: a system (11, 12) fails and violates its warranty or safety contract, e.g. Figure 1 As shown in the case of the second system (12) on the right side of the drawing. If possible, the first system (11) monitors the data received from the second system (12) and checks whether the system fulfills the agreed guarantees. If the corresponding monitoring component determines that the safety contract has been violated (25), the monitoring component ends the cooperation (26) and attempts to put the system (11) into a safe state. Since complex guarantees cannot be monitored at all, this may not be possible in individual cases. In each case, both manufacturers have access to the safety contract that has been concluded by the two systems (11, 12), and therefore one of them cannot deny the conclusion of the contract. Therefore, in the event of a violation of the guarantee or an accident, each manufacturer must prove that its system (11, 12) has fulfilled the safety contract. It should be noted that this action (Vorgehen) basically corresponds to the method that is common after an accident between conventional vehicles, in which street traffic rules correspond to the safety contract.

[0024] A first variant of the method (10) assumes the following problem: if a participating system (11, 12) fails, its manufacturer can prove that a safety contract exists, but cannot prove that the other system (12, 11) has violated the safety contract. One possibility for facilitating this proof is that the safety contract contains a clause according to which both systems (11, 12) must periodically send a representation of their system states (camera images, positions in a map, etc.) including their environment models as defined in the safety contract to a distributed transaction database (13).

[0025] A second variant is similar to the first variant, wherein however each system (11, 12) creates a cryptographic hash of its entire environment model and stores the model and the hash in a local database.

[0026] The third variant (30- Figure 2 ) The possibility of using several distributed transaction databases for distributed calculation of executable instructions contained in data records on multiple terminal devices. A known example of such a transaction database is the cryptocurrency Ethereum, which performs corresponding functions for digital contracts. It is therefore also possible to Figure 2 As shown in , two systems (11, 12) send their assumptions and guarantees to a distributed transaction database (13) with computing power. The distributed transaction database (13) evaluates the assumptions and guarantees and, in case of success, stores the security contract (31). Once the systems (11, 12) have each obtained a block with their security contract (32), the systems begin to collaborate (23).

[0027] Figure 3The fourth variant (40) shown in expands the third variant as follows: Blockchains such as "Lightning" and "Raiden" have already introduced the concept of a so-called transaction or state channel. The state channel is a direct communication channel between systems (11, 12) and a digital contract in the blockchain concluded by these systems (11, 12). The systems (11, 12) exchange information directly via this channel. If the receiving system (11, 12) agrees with the received message, it confirms the respectively received information (42, 44, 46) with a cryptographically signed notification (43, 45). If the two systems (11, 12) want to end the cooperation, or if one of the systems (11, 12) concludes that the received information (here 46) violates the safety contract, for example, the braking force of the correspondingly equipped vehicle exceeds the maximum value defined in the safety contract, it can perform a settlement function (47) in the digital contract in the blockchain. The two systems ( 11 , 12 ) must then “convince” the digital contract to a certain extent of the final harmonious state by the systems notifying their agreement.

[0028] The embodiments described so far focus on the legal security of the systems (11, 12) that are collaborating due to the manipulation safety of the blockchain. However, since computing power is used for maintaining and updating the blocks, a reward for the proof of work (PoW) provided for this is also desirable. Therefore, a fifth variant of the method (10) provides that the participating systems are equipped with a mechanism for conducting transactions, for example by means of a digital wallet, in order to store units of virtual currency as value units for the collaboration.

[0029] According to a sixth variant, the inclusion of system credibility evaluated by previous partners can limit the choice of partners for future collaboration. In view of this application scenario, the virtual cryptographic wallet can also store the aforementioned credibility. For example, this will make it possible to authenticate products for use in specific interaction scenarios (and thereby assign credibility to the products), whereby collaboration is limited to products that should be compatible in principle. The trust expressed to another system may increase over time depending on the quantity and quality of its collaboration. The resulting evaluation is beneficial not only to the terminal devices participating in the blockchain, but also to certification bodies and other trustees.

[0030] According to a seventh variant, the final security contract can be sent by the system instead of the blockchain to a central server or database trusted by the manufacturer of the system.

[0031] like Figure 4As illustrated in the schematic diagram in FIG. 1 , the method can be implemented, for example, in software or hardware or in a hybrid form of software and hardware, for example in a control device ( 50 ).

Claims

1. A method (10, 30, 40) for agreeing on a collaboration between a first system (11) and a second system (12), characterized by the following features: - the first system (11) sends the first system (11)'s assumptions about the second system (12) and the first system (11)'s guarantees to the second system (12), - sending by the second system (12) the assumptions of the second system (12) about the first system (11) and the guarantees of the second system (12) to the first system (11), and - if the mutual assumptions and guarantees correspond to each other, a digital security contract is concluded between said first system (11) and said second system (12), and - receiving, by the second system (12), the first system (11)'s assumptions about the second system (12) and the first system (11)'s guarantees for the second system (12), - receiving, by the first system (11), the second system (12)'s assumptions about the first system (11) and the second system (12)'s guarantees for the first system (11), - recording said digital security contract in a transaction database (13), - the first system (11) verifies (16) whether the guarantee of the second system (12) corresponds to the assumption of the first system (11) and sends a first item (18) with the signature of the security contract and the second system (12) to the transaction database (13), - the second system (12) verifies (17) whether the guarantee of the first system (11) corresponds to the assumption of the second system (12) and sends a second item (19) with the signature of the security contract and of the first system (11) to the transaction database (13), - the transaction database (13) adds (20) the first item and the second item to a blockchain and sends the added items of the blockchain (21) to the first system (11) and the second system (12), - said first system (11) verifies (22) said second item, - said second system (12) verifies (23) said first item, - if the one item and the second item are consistent, the first system (11) and the second system (12) accept the cooperation and then respectively repeatedly send the decentralized values ​​of the environment model to the transaction database (13), - the transaction database (13) adds the decentralized value to the blockchain, and If one of the first system (11) and the second system (12) concludes that the security contract has been violated (25) by the other system (12, 11), one of the first system (11) and the second system (12) ends the collaboration (26).

2. The method (10, 30, 40) according to claim 1, characterized by the following features: - the first system (11) and the second system (12) respectively repeatedly send the environment model to the transaction database (13) after accepting the collaboration, and - The transaction database (13) adds the environment model to the blockchain.

3. The method (10, 30, 40) according to claim 1 or 2, characterized by the following features: - receiving, by the transaction database (13), the assumptions of the first system (11) about the second system (12), the guarantee of the first system (11) to the second system (12), the assumptions of the second system (12) about the first system (11), and the guarantee of the second system (12) to the first system (11), - the transaction database (13) verifies whether the guarantees of the second system (12) correspond to the assumptions of the first system (11), and vice versa, draws up (31) the security contract and adds the corresponding block to the blockchain, - the transaction database (13) sends the block with the security contract (32) to the first system (11) and the second system (12), and - When the first system and the second system receive the block, the first system (11) and the second system (12) accept (23) cooperation.

4. The method (10, 30, 40) according to claim 3, characterized by the following features: - the first system (11) and the second system (12) establish a mutual transaction channel, - after receiving the block (41) with the security contract, the first system (11) and the second system (12) exchange information (42, 44, 46) and signed notifications (43, 45) via the transaction channel, - if one of the first system (11) and the second system (12) receives information (46) that the security contract is violated, one of the first system (11) and the second system (12) requests the transaction database (13) to mediate, - the transaction database (13) notifies another system (12, 11) of the mediation, requests information (46) from the other system regarding the supposed violation of the security contract, and verifies the information (49) according to the security contract.

5. The method (10, 30, 40) according to claim 1 or 2, characterized by the following features: - The blockchain is distributed across multiple terminal devices, - the first system (11) and the second system (12) manage digital wallets, and - Paying the terminal device from the wallet for adding blocks.

6. A computer program product, comprising a computer program, the computer program comprising instructions which, when the computer program is executed by a computer, cause the computer to perform the method (10, 30, 40) according to any one of claims 1 to 5.

7. A machine-readable storage medium having stored thereon a computer program included in the computer program product according to claim 6.

8. A device for establishing a collaboration between a first system (11) and a second system (12), the device being configured to carry out a method (10, 30, 40) according to any one of claims 1 to 5.

Images