EP4091054A1

EP4091054A1 - Method and apparatus for reconfiguring an autonomous vehicle in the event of a fault

Info

Publication number: EP4091054A1
Application number: EP21700423.3A
Authority: EP
Inventors: Tobias Kain; Maximilian Wesche; Julian-Steffen Müller; Hendrik Decke
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2020-01-15
Filing date: 2021-01-12
Publication date: 2022-11-23
Also published as: CN114930300A; WO2021144271A1; DE102020203420A1; US20230054109A1; DE102020203420B4

Abstract

The invention relates to a method for reconfiguring an autonomous vehicle (50) in the event of a fault, wherein application entities (60-x, 61-x) are executed in a distributed manner across a plurality of computing nodes (70-x) in accordance with a predefined configuration (62), wherein a fault in an application entity (60-x, 61-x) and/or in an operating system and/or in a piece of hardware is detected by means of the at least one monitor device (2), wherein the detected fault is isolated by means of a switching device (3) by switching to application entities (61-x) which are redundant with respect to the affected application entities (60-x), and wherein predefined redundancy conditions (11) and/or segregation conditions (12) are restored for the application entities (60-x, 61-x) by the reconfiguration, by an application placement device (4), of the configuration (62) , wherein the reconfiguration is carried out such that the number of times application entities (60-x, 61-x) are switched to other computing nodes (70-x) to establish the predefined redundancy conditions (11) and/or segregation conditions (12) will be or is minimised. The invention also relates to a corresponding apparatus (1) and to a vehicle (50) comprising such an apparatus (1).

Description

description

Method and device for reconfiguring an automated vehicle

Vehicle in the event of a fault

The invention relates to a method and a device for reconfiguring an automatically driving vehicle in the event of a fault. The invention also relates to a vehicle with such a device.

Modern machines have an ever-increasing number of technical components that interact with one another. In order to ensure continued operation even in the event of a fault in one or more of these components, the FDIR (Fault, Detection, Isolation, Recovery) method is known from the field of aviation. Here, errors are recognized by monitoring. A detected fault is then isolated by switching from an affected component to a redundant component with the same functionality. After switching, an attempt is made to restore redundancy by activating additional components. So far, however, a human fallback level has always been available that can manually take over control if the method fails.

The invention is based on the object of creating a method and a device for reconfiguring an automatically driving vehicle in the event of a fault, with which operation can be maintained in an improved manner even without a human fallback level.

The object is achieved according to the invention by a method with the features of claim 1 and a device with the features of claim 8. Advantageous refinements of the invention emerge from the subclaims.

In particular, a method is provided for reconfiguring an automatically driving vehicle in the event of a fault, with application instances being carried out according to a predefined configuration, distributed across a number of calculation nodes, wherein at least some of the application instances recorded sensor data are fed to at least one sensor and at least some of the application instances generate and provide control signals for controlling the vehicle, the application instances and / or operating systems and / or hardware corresponding to the computing nodes using at least one Monitor device are monitored, an error in an application instance and / or in an operating system and / or in hardware is detected by means of the at least one monitor device, the detected error by switching to application instances that are redundant to the respective application instances concerned, using a switching device is isolated, and wherein for the application instances predetermined redundancy conditions and / or segregation conditions are restored by reconfiguring the configuration by means of an application placement device, wherein the reconfiguration is carried out in such a way that a number of shifts from application instances to other computation nodes necessary to establish the predefined redundancy conditions and / or segregation conditions is minimized or is minimized.

Furthermore, in particular a device for reconfiguring an automatically driving vehicle in the event of a fault is created, with application instances being carried out in the vehicle according to a predetermined configuration distributed over a number of calculation nodes, with at least some of the application instances being supplied with acquired sensor data from at least one sensor and with at least one Part of the application instances, control signals for controlling the vehicle are generated and provided, comprising at least one monitor device, a switchover device, and an application placement device, wherein the at least one monitor device is set up to assign the application instances and / or operating systems and / or hardware corresponding to the computing nodes monitor and detect an error in an application instance and / or in an operating system and / or in hardware, the switching device being set up for this i st to isolate the detected error by switching to application instances that are redundant to the respective application instances concerned, by means of a switching device, the application placement device being set up to restore redundancy conditions and / or segregation conditions predetermined for the application instances by reconfiguring the configuration, and reconfiguring in this way to carry out that a number of shifts from application instances to other computation nodes necessary to establish the specified redundancy conditions and / or segregation conditions is minimized. The method and the device make it possible to maintain an operation or an automated drive of the vehicle without the presence of a human fallback level after the occurrence of a fault in one or more application instances. The reconfiguration takes place in such a way that a number of shifts from application instances to other computation nodes necessary to establish the specified redundancy conditions and / or segregation conditions is minimized. Since each individual move of an application instance requires both time and resources (computing resources and memory resources) and, in addition, redundancy conditions and / or segregation conditions may not be met for a period of the move, each move is safety-critical and should therefore be avoided if possible. In particular, based on a current active configuration and the specific parameters of the application instances and the calculation nodes, the application placement device tries to calculate a new configuration that fulfills the redundancy conditions and / or segregation conditions, the configuration being calculated in such a way that to activate the new configuration, as few application instances as possible have to be moved to other calculation nodes. To this end, the application placement device solves, in particular, an application placement problem.

One advantage of the method and the device is that the automated driving vehicle is reconfigured in such a way that a number and duration of safety-critical shifts of application instances during reconfiguration is minimized.

An application is provided by means of at least one application instance. An application instance is in particular a process that provides a specific functionality and that is executed on at least one calculation node. For example, an application instance can provide one of the following functionalities in connection with automated driving: environment perception, localization, navigation, trajectory planner or a prognosis of one's own behavior and / or the behavior of objects in the vicinity of the vehicle, etc. For this purpose, at least some of the application instances receive sensor data that were recorded by means of at least one sensor and / or data from other application instances. At least some of the application instances provide control signals for the vehicle. The application instances can in particular be in an active and in at least one passive operating state operate. In the active operating state, the application instance has a direct influence on the control of the vehicle. In at least one passive operating state, however, an application instance runs redundantly next to an active application instance of the same type, receives the same input data and generates the same output data or control signals, but has no influence on the control of the vehicle. Different levels of the passive state can be provided, which differ, for example, only in how quickly a passive application instance can be transferred to the active operating state. In the context of the method, both the active and the passive application instances are monitored in particular. In the event of an error affecting passive application instances, the method can then be carried out accordingly, isolating and switching being omitted and an affected passive application instance being merely terminated and replaced by a newly started passive application instance with the same functionality, so that redundancy conditions are restored are made.

A configuration includes, in particular, an assignment of active and passive application instances to individual calculation nodes. The configuration specifies in particular which application instance is executed on which calculation node, as well as the respective associated operating states of the application instances. The configuration is dependent on predefined redundancy conditions and / or segregation conditions, which are given or are given as a function of the functionalities of the application instances. For example, it can be provided that the redundancy condition prescribes simple redundancy. An active application instance and a passive application instance are then operated for an application or a functionality. Depending on the application scenario, different redundancy conditions can be provided for the same functionalities, e.g. single (e.g. pedestrian detection on a motorway) or multiple redundancy (e.g. quadruple redundancy for pedestrian detection in a play street).

A segregation condition is, in particular, a specification for a number of different calculation nodes on which an application must be executed by means of redundant application instances. A segregation condition can affect both software and hardware. For example, a segregation condition can include that redundant application instances of an application must each be executed on a predetermined number of different operating systems. Furthermore, for example, a segregation condition can include that redundant application instances of an application must be executed separately from one another on a predetermined number of different calculation nodes.

The vehicle is in particular a motor vehicle. In principle, however, the vehicle can also be another land, water, air, rail or space vehicle.

It can be provided that a monitoring device is used for each application instance. Furthermore, it can be provided that a monitor device is used for each operating system and / or each hardware. As a result, monitoring can be carried out more reliably and more quickly, so that an error can be detected more quickly.

Parts of the device, in particular the at least one monitor device, the switching device and / or the application placement device, can be designed individually or collectively as a combination of hardware and software, for example as program code that is executed on a microcontroller or microprocessor. However, it can also be provided that parts are designed individually or combined as an application-specific integrated circuit (ASIC).

In one embodiment, it is provided that the application instances are assigned or assigned a priority class, with configurations for subsets that are formed or are formed from application instances of at least one of the assigned priority classes being calculated individually for reconfiguration. This makes it possible to adapt a configuration or to reconfigure the vehicle even if, after an error has occurred, there are no longer enough resources (e.g. due to defective calculation nodes etc.) available for all previously active applications or application instances. The prioritization of the application instances by means of the priority classes then makes it possible in particular to calculate configurations for the different priority classes individually and thereby ensure or enable continued operation of the automatically driven vehicle, albeit with possibly a reduced scope of functions. The priority classes are, in particular, a measure of how important or security-relevant an application instance classified as a result is. The priority classes can include, for example, the following four classes: HIGHEST, HIGH, LOW, LOWEST. In principle, however, more or fewer priority classes can also be provided. The configuration is calculated, for example, using one of the following methods: integer linear programming, evolutionary game theory, or reinforcement learning.

In one embodiment it is provided that the subsets are formed in such a way that the subsets successively only include application instances whose assigned priority classes achieve a respective minimum priority class. As a result, a priority of the priority classes comprised by subsets can be successively increased. Application instances to which a priority class is assigned that is below a predetermined minimum priority class are not included in a subset considered. This makes it possible to prioritize when calculating the configurations for the subsets. Based on the priority classes mentioned above, for example, the following four subsets (S ₁ to S ₄ ) can be formed, with different minimum priority classes being used for each of the subsets:

S ₁ = HIGHEST υ HIGH υ LOW υ LOWEST,

S ₂ = HIGHEST υ HIGH υ LOW,

S ₃ = HIGHEST υ HIGH,

S ₄ = HIGHEST.

A configuration can now be calculated for each of these subsets by means of the application placement device. If no configuration can be calculated for one of the subsets, for example because there is no solution, solutions for configurations of the other subsets can be used.

In one embodiment it is provided that the configurations for the subsets are calculated at least partially parallel to one another by means of the application placement device. In particular, it is provided that the configurations for the subsets are all calculated parallel to one another by means of the application placement device. After all (or some of the) computation processes running in parallel have (been) completed, the application placement facility selects the best solution and reconfigures the vehicle. In this case, a solution of that subset is preferred which includes most of the subsets with the highest priority classes. _{For the subsets S 1} to S ₄ described above by way of example, this means that one is successful The calculated configuration for the subset S _{3 is} preferred over a successfully calculated configuration for the subset S ₄ . Accordingly, a configuration for S _{1 is} preferred over a configuration of S ₂ , S ₃ and S ₄ etc. Only if no configuration could be calculated for a subset and no configuration could be calculated for a subset that is higher in terms of the priority classes included, a Configuration selected for a lower-priority subset and implemented by reconfiguring.

In one embodiment it is provided that the configurations for the subsets are at least partially calculated sequentially by means of the application placement device. In particular, it is provided that the configurations for the subsets are all calculated sequentially by means of the application placement device. This has the advantage that the entire computing resources for computing a configuration can be made available for a single subset, so that computing time can be reduced, in particular minimized.

In a further-developing embodiment, it is provided that the configurations are first calculated for those subsets which in each case comprise the largest number of highest priority classes. This does not allow any kind of ranking to be established. For the subsets defined above, this would mean that the configurations for the subsets are calculated one after the other in the following order: S ₁ , S ₂ , S ₃ , S ₄ . In particular, the configuration for a subsequent subset is only calculated if a calculation for a subset under consideration has not led to success, that is, if no solution for a configuration could be found for the subset under consideration.

In one embodiment, it is provided that the calculation is aborted when a predetermined maximum calculation time is reached or exceeded, the already calculated configuration being selected for reconfiguration which includes application instances with the largest number of highest priority classes in each case. This has the advantage that time specifications can be met. Even if an (overall) optimal solution cannot be found, at least one solution can be found and made available for reconfiguration. Specifying the maximum calculation time makes it possible to define a response time when an error occurs, within which the calculation or the reconfiguration must be carried out. This allows in particular Security requirements with regard to time-critical processes or time-critical application instances are met.

In principle, this embodiment can be used both in a parallel and in a sequential calculation. In the case of a parallel calculation, it can generally be assumed that a calculation time for the subsets with the smallest number of application instances is the shortest. Therefore, in the case of calculation processes carried out in parallel, the calculation processes for such subsets will be completed first. As the more complex calculation processes for the other subsets are gradually completed over time, improved solutions for configurations are also gradually available. If the maximum calculation time is reached, the ongoing calculation processes are stopped and the best of the existing solutions for a configuration is selected and used when reconfiguring.

In the case of a sequential calculation, provision can be made in particular that the configurations for the subsets with the lowest number of highest priority classes are calculated first (in the above example, the sequential calculation would therefore be in the order: S ₄ , S ₃ , S ₂ , S ₁ respectively). After the specified calculation time has elapsed, the best available configuration is selected, that is, the one that includes the greatest number of highest priority classes.

Further features for the configuration of the device emerge from the description of configurations of the method. The advantages of the device are in each case the same as in the embodiments of the method.

Furthermore, a vehicle is also created, comprising at least one device according to one of the described embodiments.

The invention is explained in more detail below on the basis of preferred exemplary embodiments with reference to the figures. Here show:

Fig. 1 is a schematic representation of an embodiment of the device for

Reconfiguring an automated driving vehicle in the event of a fault; 2a to 2c are schematic representations of configurations to illustrate the invention;

3 shows a schematic illustration of an embodiment of the method for reconfiguring an automatically driving vehicle in the event of a fault;

4 shows a schematic representation of a configuration calculated after the occurrence of an error with insufficient resources;

Fig. 5 is a schematic representation of a further embodiment of the method.

1 shows a schematic illustration of an embodiment of the device 1 for reconfiguring an automated driving vehicle 50 in the event of a fault.

In the vehicle 50, application instances 60, 61 are executed distributed over a number of calculation nodes in accordance with a predetermined configuration 62. The application instances 60, 61 provide, for example, functionality for perception of the surroundings, localization, navigation and / or trajectory planning. At least some of the application instances 60, 61 are supplied with sensed sensor data 10 to at least one sensor 51 of the vehicle 50 (or other sensors, for example, which sense the surroundings of the vehicle 50). At least some of the application instances 60, 61 generate and provide control signals 30 for controlling the vehicle 50. The provided control signals 30 of the respectively active application instances 60 are fed to an actuator 52 of the vehicle 50, which implements an automated drive of the vehicle 50.

The device 1 comprises a monitor device 2, a switchover device 3 and an application placement device 4. In particular, provision is made that a monitor device 2 is provided for each of the application instances 60, 61, for each operating system and for each hardware providing the computing nodes (for the sake of clarity only one monitor device 2 shown). Parts of the device 1 can be designed individually or collectively as a combination of hardware and software, for example as program code that is executed on a microcontroller or microprocessor. It can also be provided that the provision of a functionality of the application instances 60, 61 and the device 1 takes place jointly, for example by means of a data processing device of vehicle 50.

The application instances 60, 61 and / or operating systems and / or hardware corresponding to the computing nodes are monitored by the monitoring device 2. The monitoring device 2 detects errors in the application instances 60, 61 and / or the operating systems and / or in the hardware.

If an error is detected, the detected error is isolated by means of the switchover device 3 by switching to passive application instances 61, which are redundant to the application instances 60 affected by the error. To this end, the switching device 3 activates the respective redundant passive application instance 61, which takes over the functionality of the application instance 60 affected by the error, while the application instance 60 affected is deactivated. This takes place, for example, by means of a switchover signal 63. If several application instances 60 are affected, the respective redundant passive application instances 61 are activated accordingly.

Once the switchover has taken place, predetermined redundancy conditions 11 and / or segregation conditions 12 for the application instances 60, 61 are restored by reconfiguring the configuration 62 using the application placement device 4.

The redundancy conditions 11 include, in particular, specifications as to which application instance 60 should or must be operated with which redundancy (none, single, double, multiple). The reconfigured configuration 62 is set by configuring the application instances 60, 61 accordingly. The reconfiguration here includes, in particular, starting and setting up further passive application instances 61 in order to (again) meet a respective redundancy condition 11 and / or segregation condition 12. If a previously passive application instance 61 is activated due to an error and a previously active application instance 60 is deactivated for isolation, a new passive application instance 61 is set up and started on one of the computing nodes so that the redundancy is restored. If there are several application instances 60 to be isolated, the procedure is corresponding.

It is provided here that the reconfiguration is carried out in such a way that a number of for establishing the predetermined redundancy conditions 11 and / or Segregation conditions 12 necessary shifts from application instances 60, 61 to other calculation nodes is minimized or is minimized.

It can be provided that the device 1 comprises a fail-safe device 5. The vehicle 50 can be transferred to a safe state by means of the failover device 5 if at least one predefined redundancy condition 11 can no longer be met due to the reconfiguration or at least one segregation condition 12 can no longer be met. This is the case, for example, when the error means that there are no longer enough resources (e.g. computing power, memory, etc.) available for the security-relevant application instances 60, 61. The vehicle 50 is then driven to the edge of the road, for example, by the fail-safe device 5, and is parked, with automated further travel being blocked.

The procedure of the application placement device 4 when calculating a configuration 62 is described below by way of example. As already described, the application placement device 4 is responsible for placing application instances 60, 61 so that the predefined redundancy conditions 11 and / or segregation conditions 12 can be restored. For this purpose, the application placement device 4 tries to find computation nodes that have sufficient resources (in particular computing power, memory and installed software) to be able to execute new application instances 60, 61 so that an isolated application instance 60, 61 can be replaced. If there are insufficient resources available, the application placement device 4 can stop application instances 60, 61 with lower priority in order to be able to provide resources for an application instance 60, 61 with higher priority.

In the following example, an application placement problem is solved using the integer linear programming method.

First, the application placement problem is formulated. For this purpose, the following parameters are extracted from a current state of the vehicle and the newly started application entity (s) 60, 61. These parameters are then fed to a solver for the application placement problem as input parameters:

- I: The set of application instances 60, 61 to be placed. - A: The set of applications, where ∀ a ∈ A: a ≤ I. Furthermore, the following must apply: ∀ a ₁ ∈

- N: set of computation nodes.

- C *: configuration matrix which describes the current configuration or the currently active placement, where C _i ^* _{, n} = 1, if i ∈ I is carried out by n ∈ N; otherwise C _i ^* _{, n} = 0. It should be noted that for each new application _{instance i new} ∈ /, for example application instances that are intended to restore the redundancy conditions that existed before the error occurred, the following applies: ∀n ∈ N: C _i ^* _new , _n = 0.

- R. The placement boundary matrix, where R _{in ,,} = 1 if n ∈ N satisfies all software conditions of ie I; otherwise R _{i, n} = 0.

- Φ _n : The storage capacity of ne N.

- Ω _n : The computing capacity of ne N.

- Φ _i : The memory requirements of ie I.

- ω _i : The memory requirements of ie I.

- π _a : The minimum number of computation nodes on which ae A must be executed, i.e. the segregation condition in terms of hardware.

On the basis of these parameters, the application placement device 4 calculates a new configuration matrix C, where C _in, = 1, if ie I is to be executed on ne N; otherwise C _in, = 0. Hence there exist 2 ^{| I | * | N |} potential solutions. However, not all of these solutions are valid.

To define the conditions that make a configuration valid, five linear boundary conditions are defined below:

Boundary condition 1:

An application instance 60, 61 must be executed by exactly one calculation node:

Boundary condition 2:

The sum of the storage requirements of all application instances 60, 61 that are executed on a calculation node must not exceed the storage capacity of this calculation node:

Boundary condition 3:

The sum of the computing power demand of all application instances 60, 61 that are executed on a computing node must not exceed the computing capacity of this computing node:

Boundary condition 4:

An application instance 60, 61 only runs on a computing device that provides software that is required by the application instance 60, 61:

Boundary condition 5:

The application instances 60, 61 belonging to the same application must run on a minimum number of different computing devices, that is to say the hardware segregation condition must be met for each application. To express this condition in a linear way, a matrix of auxiliary variables h is introduced, which is defined as felgt:

With the help of the auxiliary matrix, this condition can be defined using the following linear expressions:

To clarify the boundary condition 5, consider the following example. With the assumption of the following input variables and the configuration matrix C, it is shown that boundary condition 5 applies to the application, but not to _{application a 2.}

First we consider application a ₁ : causes boundary condition 5.3 that h causes _{a1, n1} = 0. Furthermore Boundary condition 5.2 that

This means that boundary condition 5.4 also applies, since:

Next it is shown that boundary condition 5 does not hold _{for application a 2:}

There applies (Note that the following also applies: and boundary condition 5.2 apply must, applies 1. There applies C and boundary condition 5.3 apply must, this means that boundary condition 5.4 is not fulfilled, the following applies:

Although the defined boundary conditions limit a solution space, a large number of valid solutions can exist. In order to determine which of the solutions are most preferred, the solver is instructed to find the configuration or placement that maximizes the following optimization criterion: On the basis of this optimization criterion, configurations or application placements are preferred which minimize a number of shifts from application instances 60, 61 to other calculation nodes. This goal is pursued, since a smaller number of shifts in particular reduces the time required for reconfiguration.

FIGS. 2a, 2b and 2c show schematic representations of configurations 62 to illustrate the method described in this disclosure. FIG. 2a shows an original (initial) configuration 62. FIG. 2b shows a configuration 62 as calculated by the application placement device. FIG. 2c shows a configuration 62 which is a valid solution to the application placement problem, but which requires a total of five relocations of application instances 60-x.

In the example shown, it is assumed that the configuration 62 comprises four applications, which with the help of the active application instances 60-1, 60-2, 60-3, 60-4 and the redundant passive application instances 61-1, 61-2, 61-3, 61-4 are provided, as well as four computation nodes 70-1, 70-2, 70-3, 70-4.

The four applications require the following resources:

Furthermore, the following resources are provided by the four calculation nodes 70-x (abbreviated as "BK" in the table):

It is further assumed that, based on the configuration 62 shown in FIG. 2a, the computation node 70-2 has a defect and can no longer be used. As a result, the application instances 60-1 and 61-2 can no longer be provided either. In this situation, the switching device switches one of the passive application instances 61-1 to the “active” operating state (illustrated by the change in the reference number from 61-1 to 60-1).

After the switchover, new passive application instances 61-2, 61-2 are started by the application placement device in order to restore the redundancy condition that applied before the defect in the calculation node 70-2.

Starting from the currently active configuration 62 (ie the configuration 62 shown in FIG. 2a) as well as parameters for the applications and the calculation nodes 70-x, the application placement device calculates a new configuration 62 or a new application placement, the fewest possible Makes shifts of application instances 60- x, 61 -x necessary.

One solution to the application placement device that requires only a single shift is shown in FIG. 2b. This application placement only requires the relocation of the passive application instance 61-3. The application instance 61-3 is moved from the computing node 70-3 to the computing node 70-4.

The example was constructed in such a way that at least one application instance 60-x, 61-x must be moved. The configuration 62 shown in FIG. 2b is therefore the optimal configuration 62 with regard to the optimization goal of the application placement device of having to move as few application instances 60-x, 61-x as possible.

In addition to this solution, there are many other valid solutions. However, these do not achieve the optimization goal and are therefore not regarded as optimal solutions. In FIG. 2c, a configuration 62 of such a non-optimal solution is shown by way of example, for which five shifts are necessary. If there are not enough resources (computing nodes, computing power and memory, etc.), the application placement device can also stop application instances 60-x, 61-x. In the following, two embodiments of the method and the device are described which can provide solutions in the case of limited resources.

3 shows a schematic representation of an embodiment of the method. In the embodiment it is provided that a priority class is or is assigned to each of the application instances. In the above example with the four applications, the following priority classes are assumed for the sake of clarity:

Application 1: LOW

Application 2: HIGHEST

Application 3: HIGH

Application 4: HIGH

For reconfiguration, configurations for subsets that are formed or are formed from application instances of at least one of the assigned priority classes are each calculated individually. It is also provided that the subsets are formed in such a way that the subsets gradually only include application instances whose assigned priority classes achieve a respective minimum priority class. In particular, the following subsets S ₁ , S ₂ , S ₃ , S _{4 result} :

For the calculation, it is then provided that the configurations for the subsets S ₁ , S ₂ , S ₃ , S ₄ are calculated in parallel to one another, i.e. at the same time by means of calculation threads executed in parallel with one another, by means of the application placement device, as shown schematically in FIG. 3 where the calculation threads are illustrated over time t. The application placement facility then selects the best or most optimal from the calculated configurations. Provision can be made for the calculation to be aborted when a predefined maximum calculation time 20 is reached or exceeded, the already calculated configuration being selected for reconfiguration which includes application instances with the largest number of highest priority classes in each case. In this way, the reconfiguration or the calculation can be controlled in particular in time-critical situations.

If a maximum calculation time 20 is provided, then there would only be configurations for subsets S3 and S4, whereas the maximum calculation time 20 would not have been sufficient for subsets S1 and S2.

On the basis of the configuration 62 shown in FIG. 2a, it is now assumed that it is not the calculation node 70-2 that fails, but rather the calculation node 70-3. As a result, not all application instances 60-x, 61-x that were executed before the defect occurred can be distributed to the remaining calculation nodes 70-1, 70-2, 70-4, since some boundary conditions (see above) are not met can be. With the priority classes defined above, however, at least one configuration 62 or an application placement can be calculated that takes into account the applications or application instances 60-x, 61-x to which the priority classes HIGH and HIGHEST are assigned. 4 shows a resulting configuration 62.

In Fig. 5 a schematic representation of an embodiment of the method is shown. In principle, the embodiment is designed like the embodiment described above in connection with FIGS. 3 and 4. However, it is provided that the configurations 62 for the subsets S ₁ , S ₂ , S ₃ , S ₄ are calculated sequentially by means of the application placement device. This has the advantage that full computing power can be provided when calculating a configuration for a subset S ₁ , S ₂ , S ₃ , S ₄ . It is further provided here that the configurations 62 are first calculated for those subsets which each comprise the largest number of highest priority classes, that is to say in the example according to the sequence: S ₁ , S ₂ , S ₃ , S ₄ .

In particular, it is provided that the calculation is only continued if a previous calculation was unsuccessful or did not lead to a solution or configuration 62 (indicated in FIG. 4 by an “X”). In the example shown, only a solution or a configuration 62 would be found for the subset S4, that is to say it can only an application placement or a configuration 62 are calculated in which the applications with the HIGHEST priority class are taken into account.

List of reference symbols

1 device

2 monitor setup

3 changeover device

4 Application placement facility

5 Failure protection device 10 Sensor data 11 Redundancy condition 12 Segregation condition 20 Maximum calculation time 30 Control signals

50 vehicle

51 sensor

52 Actuators

60, 60-x application instance (active)

61, 61 -x application instance (passive) 62 configuration

63 Changeover signal

70-x calculation node

S _x subset t time

Claims

1. A method for reconfiguring an automatically driving vehicle (50) in the event of a fault, with application instances (60-x, 61-x) being executed according to a predetermined configuration (62) distributed over a plurality of calculation nodes (70-x), with at least one part the application entities (60-x, 61-x) recorded sensor data (10) are supplied to at least one sensor (51) and at least some of the application entities (60-x, 61-x) control signals (30) to

Controlling (51) the vehicle (50) are generated and provided, the application instances (60-x, 61-x) and / or operating systems and / or hardware corresponding to the calculation nodes (70-x) using at least one monitor device (2 ) are monitored, an error in an application instance (60-x, 61-x) and / or in an operating system and / or in hardware being detected by means of the at least one monitor device (2), the error detected being detected by switching to application instances (61 -x), which are redundant to the respective application instances (60-x) concerned, is isolated by means of a switching device (3), and where for the application instances (60-x, 61 -x) predetermined redundancy conditions (11) and / or Segregation conditions (12) can be restored by reconfiguring the configuration (62) by means of an application placement device (4), the reconfiguration being carried out in such a way that a number of given redundancy conditions (11) and / or segregation conditions (12) necessary shifts from application instances (60-x, 61-x) to other computation nodes (70-x) is minimized or is minimized.

2. The method according to claim 1, characterized in that the application instances (60-x, 61-x) are each assigned or assigned a priority class, with configurations (62) for subsets (S _x ) consisting of application instances ( 60-x, 61-x) at least one of the assigned priority classes are formed or are formed, are each calculated individually.

3. The method according to claim 2, characterized in that the subsets (S _x ) are formed in such a way that the subsets (S _x ) successively only include application instances (60-x, 61-x) whose assigned priority classes achieve a respective minimum priority class .

4. The method according to any one of claims 2 or 3, characterized in that the configurations (62) for the subsets (S _x ) are calculated at least partially parallel to one another by means of the application placement device (4).

5. The method according to any one of claims 2 to 4, characterized in that the configurations (62) for the subsets (S _x ) are at least partially calculated sequentially by means of the application placement device (4).

6. The method according to claim 5, characterized in that the configurations (62) _{are calculated here first for those subsets (S x} ) which each comprise the largest number of highest priority classes.

7. The method according to any one of claims 4 to 6, characterized in that the calculation is aborted when a predetermined maximum calculation time (20) is reached or exceeded, the configuration (62) already calculated being selected for reconfiguration, the application instances (60 -x, 61-x) with the largest number of highest priority classes.

8. Device (1) for reconfiguring an automatically driving vehicle (50) in the event of a fault, with application instances (60-x, 61-x) in the vehicle (50) distributed over several calculation nodes (70- x), wherein at least some of the application instances (60-x, 61-x) recorded sensor data (10) are supplied to at least one sensor (51) and at least some of the application instances (60-x, 61-x) Control signals (30) for controlling the vehicle (50) are generated and provided, comprising: at least one monitor device (2), a switching device (3), and an application placement device (4), wherein the at least one monitoring device (2) is set up to monitor the application instances (60-x, 61-x) and / or operating systems and / or hardware corresponding to the computing nodes (70-x) and to detect an error in an application instance ( 60-x, 61-x) and / or in an operating system and / or in hardware, the switching device (3) being set up to detect the detected error by switching to application instances (61-x) that are relevant to each Application instances (60-x) are redundant, to be isolated, the application placement device (4) being set up to restore redundancy conditions (10) and / or segregation conditions (12) predetermined for the application instances by reconfiguring the configuration (62), and the reconfiguration in this way perform that a number of shifts of users necessary to establish the specified redundancy conditions (11) and / or segregation conditions (12) calculation instances (60-x, 61-x) to other calculation nodes (70-x) is minimized.

9. The device according to claim 8, characterized in that the application instances (60-x, 61-x) are each assigned a priority class, the application placement device (4) further being set up to reconfigure configurations (62) for subsets (S _x ), which are formed or are formed from application instances (60- x, 61-x) of at least one of the assigned priority classes, each to be calculated individually.

10. Vehicle (50) comprising at least one device (1) according to claim 8 or 9.