DE102019219667B3 - Computer program product for a peer-to-peer computer network - Google Patents

Abstract

The invention relates to a computer program product for a peer-to-peer computer network (24), the computer program product, when it is executed on decentralized processor units (8, 25) of a peer-to-peer computer network (24) arranged in a motor vehicle, the decentralized Instructs processor units (8, 25) to access an action data set (27.2, 28.2, 29.2) that has been generated by a central processor unit (3) of the motor vehicle, the action data set (27.2, 28.2, 29.2) containing information that the central processor unit (3) intends to instruct an action of the motor vehicle. Furthermore, the decentralized processing units (8, 25) are instructed to validate the intended action before it is instructed by the central processing unit (3), and to allow the central processing unit (3) to instruct the intended action if the action is successfully validated and to forbid the central processing unit (3) from instructing the intended action if the action has not been successfully validated.

Description

The invention relates to a computer program product for a peer-to-peer computer network. In particular, the invention relates to a method for validating and controlling an action of a motor vehicle by means of a peer-to-peer computer network. In this context, particular claims are made of a corresponding peer-to-peer computer network and a motor vehicle with the peer-to-peer computer network.
In the prior art, for example, in the US 2018/0 374 283 A1 discloses a method and an apparatus for validating vehicle transactions. From the WO 2019/156916 A1 a system for the validation of vehicle operations using a blockchain emerges.

One object of the present invention can be seen in ensuring that an action of a motor vehicle, in particular a critical function in the context of autonomous driving, is carried out precisely under the correct safety conditions and in a clearly defined sequence. The object is achieved by the subjects of the independent claims. Advantageous embodiments are the subject matter of the subclaims, the following description and the figures.

A computer program product, a method and a peer-to-peer computer network for validating and controlling or executing an action of a motor vehicle and a motor vehicle with the peer-to-peer computer network are proposed. Decentralized processor units belonging to the peer-to-peer computer network can access the computer program product, for which purpose the computer program product is stored, for example, on a computer-readable memory unit, e.g. a memory chip or on a hard drive or server, in particular each decentralized processor unit of the peer-to-peer. Peer computer network can be stored.

In the context of the present invention, it is proposed in particular to use blockchain technology not outside but within a single unit, in this case inside an autonomous motor vehicle, in order to validate functions that require a high level of security (e.g. ASIL D). This is done using various hardware blocks developed for this purpose. According to the present invention, in particular, several such hardware blocks are provided in order to solve an internal blockchain within the autonomous motor vehicle. In other words, the present invention provides a technology in particular for safety functions in an autonomous driving context, the safety functions being checked or validated by means of a vehicle-internal peer-to-peer computer network and, if validation is successful, stored in an internal blockchain. The proposed approach ensures that the critical functions in the context of autonomous driving are carried out under the correct safety conditions after the validation has been carried out internally in the vehicle.

In this sense, according to a first aspect of the invention, a computer program product for a peer-to-peer computer network is provided. When executed on decentralized processor units of a peer-to-peer computer network arranged in a motor vehicle, the computer program product instructs the decentralized processor units to access an action data set that has been generated by a central processor unit of the motor vehicle, the action data set containing information about it that the central processor unit intends to instruct an action of the motor vehicle.

The central processor unit and the decentralized processor units can each comprise a processor and a memory. The processor units described in the context of the present invention can also be referred to as computers. The computer program product according to the first aspect of the invention can be stored on the respective memory of the processor units or computers, the respective processor being able to access the respective memory unit by means of a communication interface in order to execute the computer program product stored thereon. The central processor unit connected to the peer-to-peer computer network can form a computer of the peer-to-peer computer network. In other words, the peer-to-peer computer network can include the central processor unit.

The “action” feature includes automated functions of the motor vehicle. The automated functions do not have to be instructed and executed, in particular controlled, by a vehicle occupant. This includes, for example, driving functions such as braking, accelerating or steering the motor vehicle and related functions in an autonomous or semi-autonomous driving mode. Furthermore, for example, the automatic control of the external light system, including indicators, also represent an action. The automatic management of the software or firmware for controlling the motor vehicle and its driver assistance systems also represent an action, for example installing or updating firmware. All of these actions constitute an event when they are performed. These actions or events are carried out by the decentralized Processor units of the peer-to-peer computer network validated before the central processor unit may instruct them and before the action may be carried out.

The central processor unit can in particular be arranged in a central control unit (Central Electronic Control Unit or, for short: Central ECU) of the motor vehicle. The control device can execute an action of the motor vehicle by means of the central processor unit, in particular control it, for example a driving function, so that the motor vehicle can drive autonomously or at least partially autonomously.

The “intended” action is that action which the central processing unit intends to instruct. “Instruct” is to be understood in particular to mean that the central processor unit initiates the action, for example an autonomous driving function of the motor vehicle. For this purpose, the central processor unit can transmit a corresponding instruction to a relevant functional unit, for example to a driver assistance system. It is possible, but not necessary, for the central processor unit to also carry out the action itself, in particular to control it. The action itself can be controlled, for example, by means of a processor unit (ECU) of a driver assistance system, which can furthermore include in particular at least one sensor and at least one actuator. An “actuator” (derived from the English expression “actuator”) can be understood to mean an element that is set up to convert electrical signals into a mechanical movement or into another physical quantity. The electrical signals can include commands emanating from a control computer, for example. The other physical quantities can be a pressure or a temperature, for example. The actuator can be, for example, a hydraulic cylinder or an electric motor. For example, a brake, a drive unit or a steering system of the motor vehicle can be actuated by means of the actuator.

The decentralized processor units represent blockchain hardware blocks within the motor vehicle. The number of blockchain hardware blocks can be defined by project requirements such as power budget and time budget. The decentralized processor units can, for example, access the action data record in that the central processor unit transmits the action data record to the decentralized processor units. For this purpose, the computer program product can comprise corresponding program code with instructions for the central processor unit. Alternatively, the decentralized processor unit can also be stored in a memory unit which the decentralized processor units can access.

Furthermore, when the computer program product is executed on the decentralized processor units, it instructs the decentralized processor units to validate the intended action before it is instructed by the central processor unit. If the action has been successfully validated, the computer program, when it is executed on the decentralized processing units, instructs the decentralized processing units to allow the central processing unit to instruct the intended action. If, however, the action has not been successfully validated, the computer program, when it is executed on the decentralized processor units, instructs the decentralized processor units to forbid the central processor unit from instructing the intended action.

The “allowing” can be implemented, for example, in that the peer-to-peer computer network instructs the central processor unit to instruct the motor vehicle action intended by the central processor unit and successfully validated by the peer-to-peer computer network. Furthermore, the peer-to-peer computer network can notify the central processor unit that the action intended by the central processor unit has been successfully validated by the peer-to-peer computer network. In this case, the central processing unit can decide whether it instructs the intended and validated action or not.

The “prohibition” can be implemented, for example, in that the peer-to-peer computer network instructs the central processor unit not to instruct the motor vehicle's action intended by the central processor unit and successfully validated by the peer-to-peer computer network. Furthermore, the peer-to-peer computer network can be set up to block the action if the action intended by the central processing unit has not been successfully validated by the peer-to-peer computer network. In this case, for example, access by the central processor unit to the non-validated action can be denied.

According to the present invention, every action carried out by the autonomous vehicle should be viewed as a specific event and, in particular, should be validated over the entire peer-to-peer computer network. Because the intended action is first validated by the decentralized processor units of the peer-to-peer computer network before the planned action is instructed by the central processor unit and then carried out, it can be ensured that the intended action is performed under the correct conditions and in the correct order.

• - Zugreifen auf einen Aktionsdatensatz mittels der dezentralen Prozessoreinheiten, wobei der Aktionsdatensatz von einer zentralen Prozessoreinheit des Kraftfahrzeugs generiert worden ist, und wobei der Aktionsdatensatz Informationen darüber enthält, dass die zentrale Prozessoreinheit beabsichtigt, eine Aktion des Kraftfahrzeugs anzuweisen,
• - Validieren der beabsichtigten Aktion mittels der dezentralen Prozessoreinheiten, bevor die beabsichtigte Aktion durch die zentrale Prozessoreinheit angewiesen wird,
• - Erlauben, dass die zentrale Prozessoreinheit die beabsichtigte Aktion anweist, wenn die Aktion erfolgreich validiert worden ist, und
• - Verbieten, dass die zentrale Prozessoreinheit die beabsichtigte Aktion anweist, wenn die Aktion nicht erfolgreich validiert worden ist.

Furthermore, according to a second aspect of the invention, a method for validating and controlling an action of a motor vehicle by means of a peer-to-peer computer network is proposed, the peer-to-peer computer network comprising several decentralized processor units which are arranged in a motor vehicle. The method comprises the steps

• - Access to an action data record by means of the decentralized processor units, the action data record having been generated by a central processor unit of the motor vehicle, and the action data record containing information about the fact that the central processor unit intends to instruct the motor vehicle to take an action,
• - Validation of the intended action by means of the decentralized processor units before the intended action is instructed by the central processor unit,
• Allowing the central processing unit to instruct the intended action if the action has been successfully validated, and
• Prohibiting the central processing unit from instructing the intended action if the action has not been successfully validated.

• - auf einen Aktionsdatensatz zuzugreifen, der von einer zentralen Prozessoreinheit des Kraftfahrzeugs generiert worden ist, wobei der Aktionsdatensatz Informationen darüber enthält, dass die zentrale Prozessoreinheit beabsichtigt, eine Aktion des Kraftfahrzeugs anzuweisen,
• - die beabsichtigte Aktion zu validieren, bevor sie durch die zentrale Prozessoreinheit angewiesen wird,
• - der zentralen Prozessoreinheit zu erlauben, die beabsichtigte Aktion anzuweisen, wenn die Aktion erfolgreich validiert worden ist, und
• - der zentralen Prozessoreinheit zu verbieten, die beabsichtigte Aktion anzuweisen, wenn Aktion nicht erfolgreich validiert worden ist.

Furthermore, according to a third aspect of the invention, a peer-to-peer computer network for validating and controlling an action of a motor vehicle is provided, the peer-to-peer computer network comprising several decentralized processor units, the decentralized processor units being set up to

• - to access an action data record that has been generated by a central processor unit of the motor vehicle, the action data record containing information about the fact that the central processor unit intends to instruct an action of the motor vehicle,
• - to validate the intended action before it is instructed by the central processing unit,
• allowing the central processing unit to instruct the intended action if the action has been successfully validated, and
• to forbid the central processing unit from instructing the intended action if action has not been successfully validated.

In addition, according to a fourth aspect of the invention, an autonomously driving motor vehicle is proposed which comprises a peer-to-peer computer network according to the third aspect of the invention and a central processor unit, wherein the central processor unit is set up to generate the action data set to which the decentralized processor units of the peer-to-peer computer network can access. The autonomously driving motor vehicle is, for example, an automobile (e.g. a passenger vehicle weighing less than 3.5 t), motorcycle, scooter, moped, bicycle, e-bike, bus, utility vehicle or truck (bus and truck e.g. with a weight of over 3.5 t), but also around a rail vehicle, a ship, an aircraft such as a helicopter or an airplane. In other words, the invention can be used in all areas of transport such as automotive, aviation, nautical, astronautical, etc. The motor vehicle can, for example, belong to a vehicle fleet.

The following statements in connection with embodiments of the present invention apply - albeit often described in connection with the computer program product according to the first aspect of the invention, equally to the method according to the second aspect of the invention, to the peer-to-peer computer network according to the third Aspect of the invention and for the autonomously driving motor vehicle according to the fourth aspect of the invention.

Several computers or processor units can communicate with one another in a computer network. The computer network can be implemented on the Internet. A “peer-to-peer computer network” can be understood to mean a computer-computer connection or a processor unit-processor unit connection in which all computers or processor units are connected to one another and, in particular, have equal rights. The contrast to a peer-to-peer connection is the client-server model, in which a central server offers a service and a client uses this service.

In one embodiment, the computer program product, when it is executed on the decentralized processor units, instructs the decentralized processor units to store the action intended by the central processor unit in a blockchain if the action has been successfully validated.

A blockchain can be implemented in the peer-to-peer computer network in which all computers both use and provide services. The network participants, ie the computers or processor units that form the peer-to-peer computer network, can be in different groups, for example in the first Network participants and second network participants are divided. The first network participants, for example the central processing unit, send action data records and receive instructions. Second network participants, for example the decentralized processor units, can validate transactions in comparison to the first network participants, in particular check the actions intended by the central processor unit, that is to say check for validity or legitimacy. For this purpose, the second network participants are set up to carry out special validation processes in a consensus procedure.

In other words, the action data records can be checked for validity by the second network participants and, in particular, a “digital fingerprint” of the successfully validated action data records can be attached to the blockchain in a new block. To validate the transactions, the second network participants (authorization nodes) execute a match algorithm, also known as a consensus algorithm. This matching algorithm ensures that the next block in a blockchain is the only true block. In addition, the matching algorithm ensures that the blockchain is not changed by third parties. Examples of match algorithms are the Proof of Work, Proof of Authority, Proof of Stake, Proof of Activity, Proof of Burn, Proof of Capacity and the Proof of Elapsed Time Algorithm.

Blockchain technology is also known as Distributed Ledger Technology, especially in the financial services sector, i.e. a technology for a decentralized general ledger. The decentralized ledger is not stored centrally but is stored on many different computers on which it is updated. The decentralized general ledger is created automatically by the blockchain or the decentralized storage of the action data records on different computers. Characteristics of this technology are its decentralization, immutability and transparency.

In simple terms, a blockchain is a chain of blocks in which transactions, in the context of the present invention these are the actions of the motor vehicle described above, are linked to one another. The transactions or transaction data records are combined into blocks, checked for validity and added to the previous chain of blocks in a consensus process. This chain of blocks forms the decentralized general ledger. So a customer carries out a transaction in the blockchain. Every participant knows that this transaction took place.

According to the invention, the action intended by the central processor unit is validated by checking whether safety-relevant prerequisites for carrying out the intended action are met. A safety-relevant prerequisite includes the states of the vehicle, e.g. driving states, states of the drive train, the sensors or the states of electronic elements of the interior or exterior such as lighting. An action can also represent a safety-relevant prerequisite, e.g. that the motor vehicle is brought to a standstill or steered by sensors.

The decentralized processor units can, for example, access a database in which all security-relevant requirements for carrying out the intended action are stored. In particular, safety-relevant prerequisites for a large number of actions that can be instructed by the central processor unit can be stored in the database. The central processor unit can also be set up to access the database. If, for example, the central processor unit intends to instruct the action that firmware is updated, then this should take place when the motor vehicle is at a standstill (safety-relevant requirement). This safety-relevant requirement can be stored in the database. In the course of the validation, the decentralized processor units check whether this safety-relevant requirement is met, e.g. by accessing corresponding sensor data, and allow (if the safety-relevant requirement is met) or prohibit (if the security-relevant requirement is not met) the central processor unit, to instruct the intended action.

According to the invention, an action data record representing the intended action is stored in a hierarchical list with safety-relevant requirements of the vehicle. In the course of the validation, the decentralized processor units can check whether all the safety-relevant requirements that are classified in the hierarchical list above the data record representing the intended action are met. If this check turns out positive, ie that the decentralized processor units determine that all security-relevant requirements are met, which are classified in the hierarchical list above the data record representing the intended action, then the decentralized processor units can allow the central processor unit to instruct the intended action. However, if the check turns out negative, that is to say that the decentralized processor units determine that not all security-relevant prerequisites are met, which are classified in the hierarchical list above the data record representing the intended action, then the decentralized Processor units prohibit the central processing unit from instructing the intended action.

For example, updating the firmware may be the intended action. In the hierarchical list, the action to bring the vehicle to a standstill can be classified as a safety-relevant action above the intended action to update the firmware. The decentralized processor units can check whether the driving condition is present, that the vehicle is at a standstill. If this is the case, the decentralized processing units will allow the central processing unit to instruct to update the firmware. However, if the decentralized processor units determine that the motor vehicle has not yet been brought to a standstill, the decentralized processor units will forbid the central processor unit from performing the intended function.

In order to carry out the validation, the entire blockchain in particular should be solved and the calculated hash values or hash keys should be correct, otherwise the event will be discarded. In this sense, the decentralized processor units check calculated hash keys in a further embodiment. If the check shows that the calculated hash keys are correct, the decentralized processor units allow the central processor unit to instruct the action, in particular to instruct the driver assistance system to carry out the intended autonomous driving function. However, if the check reveals that the calculated hash keys are incorrect, the decentralized processor units prohibit the central processor unit from instructing the action, in particular instructing the driver assistance system to carry out the intended autonomous driving function.

If the intended action is valid, i.e. it was considered valid in the course of the validation by the consensus process, no participant can change the legitimacy of this transaction. For this purpose, two successive blocks of the blockchain can be linked with one another through the use of cryptographic procedures. In particular, a hash key can link two consecutive blocks with one another by mathematically “chaining” the blocks with one another. Each block typically contains the hash key of the previous block. The hash key can be generated from the data of the previous block. The hash key can be viewed as a “digital fingerprint” of the relevant block or its transaction data. In particular, the hash key can fix the sequence and time of the transactions in such a way that they cannot be changed. The hashing behind the hash key can create a non-decryptable one-way function. A hash function can generate a mathematical algorithm that maps transaction data of any size to a bit string of a fixed size. Such a bit string is typically 32 characters long and represents the transaction data for which the hash encryption was carried out. The so-called Secure Hash Algorithm (SHA) is often used in blockchains, especially the SHA-256, which generates a nearly unique hash key as a digital fingerprint.

The decentralized general ledger or the blockchain is thus designed in such a way that it prevents, in particular, a subsequent change to an entered transaction data record. In this way, the validated actions of the motor vehicle can be recorded in an unchangeable ledger. As a result, the transactions are saved particularly securely against subsequent manipulation.

Blockchain technology is based on distributing an event to different nodes and only evaluating it as validated if more than 50% of the nodes have agreed that the event is valid. In this sense, in one embodiment, the decentralized processor units allow the central processor unit to instruct the intended action if the action has been successfully validated by more than 50% of the decentralized processor units. If, however, the action has been successfully validated by less than 50% of the decentralized processor units, then the decentralized processor units in this embodiment forbid the central processor unit from instructing the intended action.

In one embodiment, the action is an autonomous driving function of the motor vehicle. The autonomous driving function enables the motor vehicle to drive independently, ie without a vehicle occupant controlling the motor vehicle. Thus, the autonomous driving function includes that the motor vehicle is set up - in particular by means of the central processor unit - to carry out, for example, steering, blinking, acceleration and braking maneuvers without human intervention. In particular, the autonomous driving function should meet the requirements of ASIL D (“ASIL D function”). ASIL D is an abbreviation for Automotive Safety Integrity Level D and refers to the highest classification of the initial danger (risk of injury) according to ISO 26262 and to the strictest safety level of this standard to avoid an unreasonable residual risk.

If the central processing unit intends in the context of autonomous driving, a To instruct or carry out a critical action or operation, it must first register this operation in the vehicle-internal peer-to-peer computer network, and the operation should in particular be validated by all blockchain hardware blocks (decentralized processor units) distributed in the vehicle. By validating the autonomous driving function by means of the decentralized processor units, before the autonomous driving function is instructed by the central processor unit and before the autonomous driving function is carried out by the motor vehicle, it enables an ASIL D function to be carried out under the correct conditions and in the correct sequence , because at the time the ASIL D function is executed, all previous requirements must have already been validated and preferably recorded in the internal blockchain.

In connection with the autonomous driving function of the motor vehicle, the action data record can contain information about the fact that the central processor unit intends to instruct a driver assistance system of the motor vehicle to carry out an autonomous driving function of the motor vehicle.

The driver assistance system is set up by means of an electronic control unit (ECU) to autonomously intervene, in particular in a drive (in particular by braking and accelerating), in a steering system or in a signaling device (e.g. lights and indicators) of the motor vehicle. For this purpose, the driver assistance system can access data from sensors of the motor vehicle (e.g. radar, LIDAR, camera or ultrasonic sensors) and in particular control actuators of the motor vehicle based on the sensor data. The actuator is set up in particular to convert an electrical signal (control command) received by the ECU into mechanical movements or changes in physical variables such as pressure or temperature and thus to actively intervene in the control of the motor vehicle.

The intended autonomous driving function is validated by the decentralized processor units of the peer-to-peer computer network before it is instructed by the central processor unit. If the intended autonomous driving function has been successfully validated, the decentralized processor units allow the central processor unit to instruct the driver assistance system to carry out the intended autonomous driving function. If the intended autonomous driving function has been successfully validated, it will continue to be preferably stored in the blockchain. However, if the intended autonomous driving function has not been successfully validated, the decentralized processor units forbid the central processor unit from instructing the driver assistance system to carry out the intended autonomous driving function.

• 1 ein autonom fahrendes Kraftfahrzeug mit mehreren Computern eines Peer-to-Peer Computernetzwerks und
• 2 Details eines Peer-to-Peer Computernetzwerks für das Kraftfahrzeug nach 1.

In the following, exemplary embodiments of the invention are explained in more detail with reference to the schematic drawing, the same or similar elements being provided with the same reference symbols. Here shows

• 1 an autonomously driving motor vehicle with several computers in a peer-to-peer computer network and
• 2 Details of a peer-to-peer computer network for the motor vehicle according to 1 .

1 shows a motor vehicle 1 , which can be, for example, a passenger vehicle (car). A vehicle occupant 2 can in the motor vehicle 1 be transported. The vehicle occupant 2 does not have to be in the control of the motor vehicle 1 intervene as the motor vehicle 1 is set up to drive autonomously. For this purpose, the motor vehicle has, for example, a driver assistance system explained in more detail below 16 to autonomous driving. Corresponding autonomous driving functions, which in particular fulfill ASIL D, can be performed by means of a central processor unit in the form of a central computer 3rd be instructed. The central computer 3rd includes a processor 4th , a storage unit 5 and a network device 6th . On the storage unit 5 is a computer program product 7th saved.

1 also shows a first decentralized processor unit in the form of a first decentralized computer 8th . The first decentralized computer 8th includes a processor 9 , a storage unit 10 and a network device 11 . On the storage unit 10 is a computer program product 12th saved. The first decentralized computer 8th can be on a security database 13th access. Also the central computer 3rd can access the security database 13th access. In the security database 13th one or more hierarchical lists can be saved. In the exemplary embodiment shown, it is a first hierarchical list 14.1 , a second hierarchical list 14.2 and a third hierarchical list 14.3 .

The first hierarchical list 14.1 comprises several action data sets, in the exemplary embodiment shown it is a first action data set 15.1 , a second action record 15.2 , a third action record 15.3 , a fourth action dates
sentence 15.4 , a fifth action record 15.5 and a sixth action record 15.6 . The action records 15.1 to 15.6 can, for example, each have an automated action of the motor vehicle 1 or a state of the motor vehicle 1 represent. The first list 14.1 is hierarchical because automated actions with a higher order number, e.g. the second automated action that is triggered by the second action record 15.2 is represented, may only be carried out if the execution of all automated actions with a lower order number - in the exemplary embodiment shown, this is the first automated action that is identified by the first action data record 15.1 is represented - is completed. The second hierarchical list 14.2 and the third hierarchical list 14.3 have the same structure as the first hierarchical list 14.1 , but with different action records.

For example, the central computer 3rd intend to instruct the second action to be followed by the second action record 15.2 is represented. The second action can include, for example, that firmware is updated. The central computer can initiate this 3rd for example, a corresponding instruction to yourself or to another processor unit 23 which is set up and intended for the execution of the second action. The central computer 3rd however, it is only allowed to itself or the additional processor unit 23 instructing the user to update the firmware if the first action has been carried out beforehand.

At the first action, which is caused by the first action record 15.1 is represented, it can be, for example, an autonomous driving function that is provided by the driver assistance system 16 can be executed. The driver assistance system 16 comprises for this purpose a processor in the exemplary embodiment shown 17th , a storage unit 18th , a network facility 19th , a sensor 20th , e.g. a camera system, and an actuator 21st . On the storage unit 18th is a computer program product 22nd saved. The computer program product 22nd Instructions contain on sensor data (e.g. a visual survey of the surroundings of the motor vehicle 1 ) to access by the sensor 20th have been generated, and based on the sensor data, the actuator 21st to control so that the autonomous driving function is carried out. The autonomous driving function can include, for example, that the motor vehicle 1 is brought to a standstill.

For example, according to ASIL D, it may be required that firmware in a motor vehicle 1 is only updated when the motor vehicle 1 has been brought to a standstill (safety-relevant requirement). This safety-relevant requirement is in the safety database in the form of the first hierarchical list 14.1 thereby stored or implemented by the first action or the first action data record 15.1 is hierarchically higher than the second action or the second action data record 15.2 .

In the course of a validation, decentralized processor units can check, for example the by 1 shown first decentralized computer 8th , a peer-to-peer computer network explained in more detail below 24 whether this safety-relevant requirement is met. If the validation determines that the first action has been taken, then the central computer 3rd allows to instruct the second action. If, however, it is found in the course of the validation that the first action has not yet been carried out, then the central computer 3rd forbidden to instruct the second action. The network device 19th of the driver assistance system 16 be connected to the network devices of the decentralized processor units, for example to the network device 11 of the first decentralized computer 8th .

In the aforementioned computer programs 7th , 12th and 22nd it can be the same computer program product, ie the same computer program product is on the relevant storage unit 5 , 10 , 18th the computer 3rd , 8th , 16 saved. Alternatively, different computer program products can also be stored on the storage units 5 , 10 , 18th the computer 3rd , 8th , 16 be saved.

2 shows the peer-to-peer computer network 24 that in the motor vehicle 1 is arranged. The peer-to-peer computer network 24 includes multiple computers 3rd , 8th , 16 and 25th communicating with each other. Within the peer-to-peer computer network 24 are all computers 3rd , 8th , 16 and 25th interconnected and equal. The central computer 3rd , the first decentralized computer 8th and the driver assistance system 16 with its processor 17th and its storage unit 18th reproduce in the example 2 one computer each on the peer-to-peer computer network 24 . The peer-to-peer computer network 24 can also use other decentralized computers 25th include, both with each other and with the other computers 3rd , 8th and 16 are connected. The network facilities 6th , 11 and 19th set up for the computer 3rd , 8th and 16 a connection to the peer-to-peer computer network 24 a. Also the other decentralized computers 25th can each have a network device by means of which they are connected to the peer-to-peer computer network 24 are connected. In particular, storage units of the further decentralized computer can be used 25th the same computer program product 12th stored on the first decentralized computer 8th is stored. In this way, the first decentralized computer in particular 8th and the other decentralized ones computer 25th by the computer program product 12th to carry out the validation and control of automated actions of the motor vehicle 1 be instructed, which is explained in more detail below.

The central computer 3rd can be within the peer-to-peer computer network 24 for example, fulfill the function of a first network subscriber when he intends, for example, to update the firmware, ie the central computer 3rd only sends and receives transactions or transaction data records. Furthermore, the central computer 3rd within the peer-to-peer computer network 24 also fulfill the function of a second network participant, ie in this case it can also validate action data sets and, in the case of successful validation, in a block of a blockchain 26th to save. In this context, “validate” can in particular be understood to mean that the action data records are checked with regard to their validity and legitimacy.

2 shows a first block 27 , a second block 28 and a third block 29 the blockchain 26th . To the third block 29 further blocks can be appended, and before the first block shown 27 there are also other blocks. Each of the blocks shown 27 to 29 is a data record or a data record block and contains, for example, a first hash key 27.1 , 28.1 or. 29.1 , a successfully validated action record 27.2 , 28.2 or. 29.2 and a second hash key 27.3 , 28.3 or. 29.3 . The second hash key 27.3 , 28.3 or. 29.3 can each based on the successfully validated action record 27.2 , 28.2 or. 29.2 of the relevant block 27 to 29 are generated, ie the generated or calculated second hash key 27.3 of the first block 27 is based, for example, on the successfully validated action data set 27.2 of the first block 27 .

The blocks 27 to 29 are through the hash key 27.1 , 28.1 ., 29.1 as 27.3 , 28.3 , 29.3 chained together. This concatenation can be designed in such a way that the first hash key 27.1 of the first block 27 matches the second hash key of the previous block (not shown). The first hash key is correct in the same way 28.1 of the second block 28 with the second hash key 27.3 of the first block 27 match the first hash key 29.1 of the third block 29 matches the second hash key 28.3 of the second block 27 match etc.

As part of the validation, it can be checked whether this match of the hash key 27.1 , 28.1 ., 29.1 as 27.3 , 28.3 , 29.3 given is. For example, the action record 28.2 of the second block 28 the first action record 15.1 be that through 1 is shown and which represents the first action that the motor vehicle 1 is brought to a standstill.

For example, if the first remote computer 8th the action record 29.2 of the third block 29 has successfully validated (e.g. by receiving the information that the motor vehicle 1 has been brought to a standstill), the first decentralized computer can 8th the central processing unit 3rd allow the intended action to be instructed by the action record 29.2 is represented. Furthermore, the decentralized computer 8th additionally check whether the first hash keyi 29.1 of the third block 29 with the second hash key 28.3 of the second block 28 matches. If this is the case, the decentralized computer can 8th the action record 29.2 in the third block 29 and based on the action record 29.2 the second hash key 29.3 of the third block 29 as its "digital fingerprint". If the first remote computer 8th the action record 29.2 of the third block 29 but has not successfully validated (e.g. by receiving the information that the motor vehicle 1 has not been brought to a standstill), the first decentralized computer can 8th the central processing unit 3rd forbid to instruct the intended action by the action record 29.2 is represented. In this case, the action record 29.2 not in the third block 29 the blockchain 26th registered.

Checking whether the first hash key 29.1 of the third block 29 with the second hash key 28.3 of the second block 28 matches, in particular, can be used by all computers 3rd , 8th , 16 , 25th of the peer-to-peer computer network 24 be performed. For example, the third action record 29.2 only then to the third block 29 be entered if more than half of the computers 3rd , 8th , 16 , 25th of the peer-to-peer computer network 24 during the test found that the first hash key 29.1 of the third block 29 with the second hash key 28.3 of the second block 28 matches.

List of reference symbols

1

Motor vehicle

2

Vehicle occupant

3

central processing unit

4th

processor

5

Storage

6th

Network setup

7th

Computer program product

8th

first decentralized processor unit

9

processor

10

Storage

11

Network setup

12th

Computer program product

13th

Security database

14.1

first hierarchical list

14.2

second hierarchical list

14.3

third hierarchical list

15.1

first action record first hierarchical list

15.2

second action record, first hierarchical list

15.3

third action record, first hierarchical list

15.4

fourth action record, first hierarchical list

15.5

fifth action record, first hierarchical list

15.6

sixth action data record, first hierarchical list

16

Driver assistance system for autonomous driving of the motor vehicle

17th

processor

18th

Storage

19th

Network setup

20th

sensor

21st

Actuator

22nd

Computer program product

23

Processor unit for firmware updates

24

Peer-to-peer computer network

25th

further decentralized computers

26th

Blockchain

27

first block of the blockchain

27.1

first hash key of the first block of the blockchain

27.2

first action record of the first block of the blockchain

27.3

second hash key of the first block of the blockchain

28

second block of the blockchain

28.1

first hash key of the second block of the blockchain

28.2

first action record of the second block of the blockchain

28.3

second hash key of the third block of the blockchain

29

third block of the blockchain

29.1

first hash key of the third block of the blockchain

29.2

first action record of the third block of the blockchain

29.3

second hash key of the third block of the blockchain

Claims (9)

Computer program product (12) for a peer-to-peer computer network (24), wherein the computer program product (12) when it is on decentralized processor units (8, 25) of a peer-to-peer computer network (24) arranged in a motor vehicle (1) is executed, instructs the decentralized processor units (8, 25) to access an action data record (15.1-15.6; 27.2, 28.2, 29.2) generated by a central processor unit (3) of the motor vehicle (1), the action data record (15.1-15.6; 27.2, 28.2, 29.2) contains information about the fact that the central processor unit (3) intends to instruct an action of the motor vehicle (1), validate the intended action before being instructed by the central processor unit (3) will - allow the central processing unit (3) to instruct the intended action if the action has been successfully validated, and - prohibit the central processing unit (3) from displaying the intended action u if the action has not been successfully validated, - the computer program product (12), when it is executed on the decentralized processor units (8, 25), instructs the decentralized processor units (8, 25) to be sent by the central processor unit (3) to validate the intended action by checking whether safety-relevant prerequisites (15.1-15.6) for performing the intended action are met, - with an action data record (15.2) representing the intended action in a hierarchical list (14.1) with the safety-relevant prerequisites (15.1; 15.3-15.6) is stored, and the computer program product (12), when it is executed on the decentralized processor units (8, 25), instructs the decentralized processor units (8, 25) to check whether all safety-relevant requirements ( 15.1) are fulfilled, which are classified in the hierarchical list (14.1) above the action data record (15.2) representing the intended action, - to allow the central processor unit (3) to instruct the intended action when the The test shows that all safety-relevant prerequisites (15.1) are met, which are classified in the hierarchical list (14.1) above the action data record (15.2) representing the intended action, and - to forbid the central processor unit (3) from instructing the intended action, if the check reveals that not all safety-relevant requirements (15.1) are met, which are classified in the hierarchical list above the action data record (15.2) representing the intended action. Computer program product (12) according to Claim 1 wherein the computer program product (12), when it is executed on the decentralized processor units (8, 25), instructs the decentralized processor units (8, 25) to carry out the action intended by the central processor unit (3) in a blockchain (26) to be saved when the action has been successfully validated. Computer program product (12) according to one of the preceding claims, wherein the computer program product (12), when it is executed on the decentralized processor units (8, 25), instructs the decentralized processor units (8, 25), - to validate the action intended by the central processor unit (3) by checking calculated hash keys (27.1, 28.1, 29.1, 27.3, 28.3, 29.3), - to allow the central processing unit (3) to instruct the intended action if the check shows that the calculated hash keys (27.1, 28.1, 29.1, 27.3, 28.3, 29.3) are correct, and - To forbid the central processor unit (3) from instructing the intended action if the check shows that the calculated hash keys (27.1, 28.1, 29.1, 27.3, 28.3, 29.3) are incorrect. Computer program product (12) according to one of the preceding claims, wherein the computer program product (12), when it is executed on the decentralized processor units (8, 25), instructs the decentralized processor units (8, 25), - to allow the central processing unit (3) to instruct the intended action if the action has been successfully validated by more than 50% of the decentralized processing units (8, 25), and - To prohibit the central processor unit (3) from instructing the intended action if the action has been successfully validated by less than 50% of the decentralized processor units (8, 25). Computer program product (12) according to one of the preceding claims, wherein the intended action is an autonomous driving function (15.1) of the motor vehicle (1). Computer program product (12) according to Claim 5 wherein - the action data set (15.1) contains information that the central processor unit (3) intends to instruct a driver assistance system (16) of the motor vehicle (1) to carry out an autonomous driving function of the motor vehicle (1), - the computer program product (12 ), when it is executed on the decentralized processor units (8, 25), instructs the decentralized processor units (8, 25) to validate the intended autonomous driving function before it is instructed by the central processor unit (3), - the central processor unit (3) to allow the driver assistance system (16) to execute the intended autonomous driving function when the intended autonomous driving function has been successfully validated, and - to forbid the central processor unit (3) to instruct the driver assistance system (16) to execute the intended autonomous driving function Carry out driving function if the intended autonomous driving function has not been successfully validated. A method for validating and controlling an action of a motor vehicle (1) by means of a peer-to-peer computer network (24), the peer-to-peer computer network (24) comprising a plurality of decentralized processor units (8, 25) which are in a motor vehicle ( 1) are arranged, the method comprising the steps of - accessing an action data set (15.1 - 15.6; 27.2, 28.2, 29.2) by means of the decentralized processor units (8, 25), the action data set (15.1 - 15.6; 27.2, 28.2, 29.2) has been generated by a central processor unit (3) of the motor vehicle (1), and wherein the action data record (15.1-15.6; 27.2, 28.2, 29.2) contains information that the central processor unit (3) intends to instruct an action of the motor vehicle (1), - validation of the intended action by means of the decentralized processor units (8, 25) before the intended action is instructed by the central processor unit (3), - allow the central processing unit (3) instructs the intended action if the action has been successfully validated, and - prohibiting the central processing unit (3) from instructing the intended action if the action has not been successfully validated. Peer-to-peer computer network (24) for validating and controlling an action of a motor vehicle (1), the peer-to-peer computer network (24) comprising several decentralized processor units (8, 25), the decentralized processor units (8, 25 ) are set up to - To access an action data set (15.1-15.6; 27.2, 28.2, 29.2) which has been generated by a central processor unit (3) of the motor vehicle (1), the action data set (15.1-15.6; 27.2, 28.2, 29.2) providing information about it contains that the central processor unit (3) intends to instruct the motor vehicle (1) to take an action, - to validate the intended action before it is instructed by the central processing unit (3), - to allow the central processing unit (3) to instruct the intended action if the action has been successfully validated, and - To forbid the central processing unit (3) from instructing the intended action if the action has not been successfully validated. Autonomously driving motor vehicle (1) comprising - a peer-to-peer computer network (24) according to Claim 8 and - a central processor unit (3), the central processor unit (3) being set up to generate the action data record (15.1-15.6; 27.2, 28.2, 29.2) to which the decentralized processor units (8, 25) of the peer-to-peer -Peer computer network (24) can access.

Images