Method and apparatus for reconfiguring an autonomously driving vehicle in a fault situation

By distributing application instances on multiple computing nodes and using monitoring, switching and application placement devices, the automated fault detection and recovery of automatic driving vehicles in case of failures is solved, and safe and rapid reconfiguration without human intervention is achieved, ensuring the continuous operation of vehicles.

CN114930300BActive Publication Date: 2025-07-22VOLKSWAGEN AG
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202180008573.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2020-03-17
Filing Date
2021-01-12
Publication Date
2025-07-22
Estimated Expiration
2041-01-12

AI Technical Summary

Technical Problem

In the case of failure of automatic driving vehicles, the prior art requires manual backup intervention to maintain operation, and lacks automated fault detection, isolation and recovery mechanisms.

Method used

By distributing application instances on multiple computing nodes, detecting faults with monitoring devices, isolating and switching to redundant application instances by switching devices, minimizing the number of transfers to re-establishing redundancy and isolation conditions, and achieving continuous operation of automatic driving.

Benefits of technology

Without manual intervention, safe and rapid reconfiguration of automatic driving vehicles in the event of failure conditions is achieved, reducing the calculation and resource requirements of failover, and ensuring the continuous operation of vehicles.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114930300B_ABST
    Figure CN114930300B_ABST
Patent Text Reader

Abstract

The invention relates to a method for reconfiguring an autonomously driving vehicle (50) in the event of a fault, wherein application instances (60-x, 61-x) are executed distributed over a plurality of computing nodes (70-x) according to a predefined configuration (62), a fault in an application instance (60-x, 61-x) and / or in the operating system and / or in the hardware is identified by means of the at least one monitoring device (2), wherein the identified fault is isolated by switching, by means of a switching device (3), to an application instance (61-x) redundant with respect to the respective application instance (60-x) involved, and wherein the predefined redundancy conditions (11) and / or isolation conditions (12) for the application instances (60-x, 61-x) are re-established by means of a switching configuration of the configuration (62) by means of an application placement device (4), wherein the switching configuration is carried out in such a way that the number of transfers of the application instances (60-x, 61-x) required for establishing the predefined redundancy conditions (11) and / or isolation conditions (12) to other computing nodes (70-x) is minimized or minimized. The invention also relates to a corresponding device (1) and a vehicle (50) having such a device (1).
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to a method and a device for reconfiguring an autonomously driving vehicle in a fault situation. Furthermore, the present invention also relates to a vehicle having such a device. Background Art

[0002] Modern machines have an increasing number of interacting technical components. In order to ensure continued operation even when one or more of these components fail, FDIR (Fault, Detection, Isolation, Recovery) methods are known from the aviation field. Here, faults are identified by monitoring devices. The identified faults are then isolated by switching from the component involved to a component with the same function redundantly prepared. After the switch, an attempt is made to re - establish redundancy by enabling additional components. However, so far, when the method fails, there has always been a manual backup level that can take over control manually. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a method and a device for reconfiguring an autonomously driving vehicle in a fault situation, by means of which operation can be better maintained even without a manual backup level.

[0004] In particular, a method for reconfiguring an autonomously driving vehicle in a fault situation is provided, in which application instances are executed according to a predefined configuration distributed over a plurality of computing nodes, in which sensor data detected by at least one sensor is fed to at least some of the application instances, and in which control signals for controlling the vehicle are generated and provided by at least some of the application instances, in which the application instances and / or the operating system and / or the hardware corresponding to the computing nodes are monitored by at least one monitoring device, in which a fault in the application instances and / or the operating system and / or the hardware is identified by the at least one monitoring device, in which the identified fault is isolated by switching, by means of a switching device, to an application instance (which is redundant with respect to the application instance involved), and in which the predefined redundancy conditions and / or isolation conditions for the application instances are re - established by means of an application placement device for a switched configuration (or a transformed configuration) of the configuration, wherein the switched configuration is carried out such that the number of transfers of application instances to other computing nodes required to establish the predefined redundancy conditions and / or isolation conditions is minimized or minimized.

[0005] Furthermore, there is provided in particular a device for reconfiguring an autonomously driving vehicle in the event of a fault, wherein, in the vehicle, application instances are executed according to a predefined configuration distributed over a plurality of computing nodes, wherein sensor data detected by at least one sensor is fed to at least some of the application instances, and wherein control signals for controlling the vehicle are generated and provided by at least some of the application instances. The device includes at least one monitoring device, at least one switching device, and at least one application placement device, wherein the at least one monitoring device is configured to monitor the application instances and / or the operating system and / or the hardware corresponding to the computing nodes and to identify faults in the application instances and / or the operating system and / or the hardware, wherein the switching device is configured to isolate the identified faults by switching, by means of the switching device, to application instances that are redundant with respect to the application instances concerned, wherein the application placement device is configured to re-establish the predefined redundancy conditions and / or isolation conditions for the application instances by switching the configuration, and the switching of the configuration is carried out such that the number of transfers of application instances to other computing nodes required to establish the predefined redundancy conditions and / or isolation conditions is minimized.

[0006] The method and the device enable the operation or autonomous driving of the vehicle to be maintained in the absence of a manual fallback level after a fault has occurred in one or more of the application instances. The switching of the configuration is carried out such that the number of transfers of application instances to other computing nodes required to establish the predefined redundancy conditions and / or isolation conditions is minimized. Since each individual transfer of an application instance requires not only time but also resources (computing resources and storage resources) and the redundancy conditions and / or isolation conditions are not satisfied for some time during the transfer, each transfer is critical for safety and must therefore be avoided as much as possible. In particular, the application placement device therefore attempts to calculate a new configuration that satisfies the redundancy conditions and / or isolation conditions starting from the currently enabled configuration and from the specific parameters of the application instances and the computing nodes, wherein the configuration is calculated such that as few application instances as possible have to be transferred to other computing nodes in order to enable the new configuration. The application placement device in particular solves the Application Placement Problem.

[0007] One advantage of the method and the device is that the reconfiguration of the autonomously driving vehicle is carried out such that the number and duration of the safety-critical transfers of application instances are minimized during the switching of the configuration.

[0008] The application is provided by at least one application instance. The application instance in particular provides a defined function and a program executed on at least one computing node. For example, the application instance can provide one of the following functions in connection with autonomous driving: environment perception, positioning, navigation, trajectory planning, or predicting its own behavior and / or the behavior of objects in the environment of the vehicle. For this purpose, at least a part of the application instance obtains sensor data detected by at least one sensor and / or data of other application instances. At least a part of the application instance provides control signals for the vehicle. The application instance can in particular operate in an active and at least one passive operating state. In the active operating state, the application instance has a direct influence on the control of the vehicle. In contrast, in at least one passive operating state, the application instance operates redundantly together with 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 set, which differ, for example, only in how quickly the passive application instance can switch to the active operating state. In the context of this method, in particular both the active and the passive application instances are monitored. In the event of a fault involving a passive application instance, the method can be accordingly executed, where isolation and switching can be omitted and only the involved passive application instance is ended and replaced by a restarted passive application instance with the same function, thereby re-establishing the redundancy condition.

[0009] The configuration in particular includes the assignment of active and passive application instances to separate computing nodes. The configuration in particular determines which application instance is executed on which computing node and the respectively corresponding operating state of the application instance. The configuration depends on predefined redundancy conditions and / or isolation conditions, which are predefined according to the function of the application instance. For example, it can be predefined that the redundancy condition provides single redundancy. Then the active application instance and the passive application instance are run for the application or the function. Different redundancy conditions can be predefined for the same function depending on the application scenario, for example single redundancy (e.g., pedestrian recognition on a highway) or multiple redundancy (e.g., quadruple redundancy for pedestrian recognition in a street where children can play).

[0010] The isolation condition is in particular a specification of the number of different computing nodes on which the application must be executed by redundant application instances. The isolation condition can relate to both software and hardware. For example, the isolation condition can include that the redundant application instances of the application must be executed on a predefined number of different operating systems respectively. Furthermore, for example, the isolation condition can include that the redundant application instances of the application must be executed on a predefined number of different computing nodes separately from each other.

[0011] The vehicle is in particular a motor vehicle. In principle, the vehicle can also be other ground, waterborne, airborne, rail or space vehicles.

[0012] It can be stipulated that a monitoring device is used for each application instance. In addition, it can be stipulated that a monitoring device is used for each operating system and / or each piece of hardware respectively. Thereby, monitoring can be carried out more reliably and quickly, so that faults can be identified faster.

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

[0014] In one embodiment, it is stipulated that application instances are each assigned or have a priority class assigned to them, where, for the switching configuration, the configuration is calculated separately for each subset, and the subset is formed from the application instances of at least one assigned priority class. This enables, when there are no longer sufficient resources (e.g., due to a computing node failure, etc.) available for all previously enabled applications or application instances after a fault occurs, to adjust the configuration or reconfigure the vehicle. Determining the priority order of application instances by means of the priority class in particular enables the configuration to be calculated separately for different priority classes, and thereby ensures or enables the continuous operation of the autonomous vehicle, although the scope of functions may be reduced if necessary. The priority class is in particular the degree of how important or how safety-related the classified application instance is. The priority class can for example include the following four classes: highest, high, low, lowest. But in principle more or fewer priority classes can be stipulated.

[0015] The calculation of the configuration is carried out, for example, by one of the following methods: integer linear programming, evolutionary game theory or reinforcement learning.

[0016] In one embodiment, it is stipulated that the subset is formed such that the subset gradually only includes the application instances of the assigned priority classes up to the corresponding minimum priority class. In this way, the priority of the priority classes included in the subset can be gradually increased. Application instances with an assigned priority class lower than a predefined minimum priority class are not included in the subset under discussion. This enables the determination of the priority order when calculating the configuration for the subset. Based on the priority classes exemplarily described above, for example, the following four subsets (S1 to S4) can be formed, where different minimum priority classes are used for each subset:

[0017] S1 = highest ∪ high ∪ low ∪ lowest

[0018] S2 = highest ∪ high ∪ low

[0019] S3 = highest ∪ high

[0020] S4 = highest

[0021] For each of these subsets, a configuration can now be calculated with the aid of an application placement device. If, for example, no configuration is calculated for one of the subsets because there is no solution, the solution for the configurations of the other subsets can be used.

[0022] In one embodiment, it is provided that the configurations are calculated for the subsets at least partly in parallel by means of an application placement device. In particular, it is provided that the configurations are calculated for the subsets all in parallel by means of an application placement device. After the end of all (or part of) the calculations carried out in parallel with each other, the application placement device selects the best solution and switches the configuration of the vehicle. Here, preferably, the solution of the subset that includes most of the subsets with the highest priority class is included. For the subsets S1 to S4 illustrated by way of example above, this means that the configuration calculated successfully for subset S3 is preferred over the configuration calculated successfully for subset S4. Correspondingly, the configuration for S1 is preferred over the configurations for S2, S3, and S4, and so on. Only if no configuration can be calculated for a subset and also no configuration can be calculated for the subset that is highest with respect to the included priority classes, the configuration for the subset with the lowest priority is selected and implemented by switching the configuration.

[0023] In one embodiment, it is provided that the configurations are calculated for the subsets at least partly serially by means of an application placement device. In particular, it is provided that the configurations are calculated for the subsets all serially by means of an application placement device. The advantage thereof is that the total computing resources can be provided for calculating the configuration for a single subset, such that the computing time is reduced, in particular minimized.

[0024] In an improved embodiment, it is provided here that first the configurations are calculated for the subsets that include the largest number of highest priority classes respectively. Thereby, a specific kind of order can be avoided. For the subsets defined above, this means that the configurations are calculated for the subsets successively in the following order: S1, S2, S3, S4. Here, in particular, only if the calculation for the subset under discussion is not successful, i.e., no solution is found for the configuration of the subset under discussion, are the configurations calculated for the subsequent subsets.

[0025] In one embodiment, it is stipulated that if the pre-stipulated maximum calculation time is reached or exceeded, the calculation is interrupted, where the calculated configuration is selected for the switching configuration, and the calculated configuration includes application instances with the maximum number of highest-priority classes respectively. The advantage thereof is that the time stipulation can be met. Even if the (overall) best solution cannot be found, at least one solution can be found and provided for the switching configuration. The pre-determined maximum calculation time realizes the definition of the response time in case of a fault, within which the calculation or the switching configuration must be carried out. Thereby, in particular, the safety stipulations in processes with important time influence or application instances with important time influence can be met.

[0026] In principle, this embodiment can be used both in parallel calculation and in sequential calculation. In parallel calculation, it can generally be considered that the calculation time for the subset with the smallest number of application instances is the shortest. Therefore, in the calculation process executed in parallel, the calculation process for such a subset ends first. Since the even more complex calculation processes for other subsets gradually end as time goes by, better solutions for the configuration are also gradually provided. If the maximum calculation time is reached, the ongoing calculation processes are stopped, and the best solution among the existing solutions is selected for the configuration and used for the switching configuration.

[0027] In the case of sequential calculation, it can in particular be stipulated that the configuration is calculated first for the subset with the smallest number of highest-priority classes respectively (in the above example, the sequential calculation is thus carried out in the order S4, S3, S2, S1). After the pre-determined calculation time has expired, the best configuration existing respectively, i.e., the configuration including the maximum number of highest-priority classes, is selected.

[0028] Further features with respect to the design of the device are derived from the description of the design of the method. Here, the advantages of the device are the same as the advantages in the design of the method respectively.

[0029] Furthermore, a vehicle is realized, which includes at least one device according to one of the above embodiments. Description of the Drawings

[0030] The present invention will be further elaborated below with reference to the accompanying drawings according to the preferred embodiments. In the drawings:

[0031] Figure 1 A schematic diagram showing an embodiment of a device for reconfiguring an autonomously driving vehicle in a fault situation;

[0032] Figures 2a to 2c A schematic diagram showing the configuration for explaining the present invention;

[0033] Figure 3 A schematic diagram showing an embodiment of a method for reconfiguring an autonomously driving vehicle in a fault situation;

[0034] Figure 4 Schematic diagram showing the configuration calculated after a failure when resources are insufficient;

[0035] Figure 5 Schematic diagram showing another embodiment of the method. Detailed implementation

[0036] Figure 1 Schematic diagram showing an embodiment of device 1 for reconfiguring an autonomous vehicle 50 in a failure situation.

[0037] In vehicle 50, application instances 60, 61 are executed distributed over a plurality of computing nodes according to a predefined configuration 62. The application instances 60, 61 provide functions for, for example, environmental perception, positioning, navigation, and / or trajectory planning. The detected sensor data 10 of at least one sensor 51 (or other sensors that detect the environment of vehicle 50, for example) of vehicle 50 is fed to at least some of the application instances 60, 61. Control signals 30 for controlling vehicle 50 are generated and provided by at least some of the application instances 60, 61. The control signals 30 provided by the separately enabled application instance 60 are fed to the actuator device 52 of vehicle 50, which implements the autonomous driving of vehicle 50.

[0038] Device 1 includes a monitoring device 2, a switching device 3, and an application placement device 4. In particular, it is stipulated that for each application instance 60, 61, for each operating system, and for each hardware providing the computing nodes, a monitoring device 2 is provided (only one monitoring device 2 is shown for clarity). Parts of device 1 can be designed separately or integrally as a combination of hardware and software, for example, designed as program code executed on a microcontroller or microprocessor. Furthermore, it can be stipulated that the provision of the functions of application instances 60, 61 and device 1 is jointly implemented, for example, by the data processing device of vehicle 50.

[0039] The application instances 60, 61 and / or the operating system and / or the hardware corresponding to the computing nodes are monitored by the monitoring device 2. The monitoring device 2 identifies faults in the application instances 60, 61 and / or the operating system and / or the hardware.

[0040] If a fault is identified, the identified fault is isolated by switching to a passive application instance 61 (redundant with respect to the application instance 60 involved in the fault respectively) by means of the switching device 3. The switching device 3 enables the corresponding redundant passive application instance 61 for this purpose, which takes over the function of the application instance 60 involved in the fault, while the involved application instance 60 is deactivated. This is achieved, for example, by a switching signal 63. If multiple application instances 60 are involved, the respectively redundant passive application instances 61 are enabled accordingly.

[0041] If a switchover is to be effected, the switching configuration of the configuration 62 is used by means of the application placement device 4 to re - establish the redundancy condition 11 and / or the isolation condition 12 predefined for the application instances 60, 61.

[0042] The redundancy condition 11 includes in particular a specification as to which application instance 60 should or must operate with which redundancy (none, single, dual, multiple). The configuration 62 of the switched configuration is set by the corresponding configured application instances 60, 61. The switching configuration here in particular includes starting up and setting up a further passive application instance 61 in order to (re -) satisfy the corresponding redundancy condition 11 and / or the isolation condition 12. If the previously passive application instance 61 is enabled and the previously active application instance 60 is deactivated for isolation when redundancy is required due to a fault, the new passive application instance 61 is set up on one of the computing nodes and started up, thereby re - establishing the redundancy. This is carried out accordingly when there are a plurality of application instances 60 to be isolated.

[0043] It is hereby specified that the switching configuration is carried out in such a way that the number of transfers of the application instances 60, 61 to other computing nodes required to establish the predefined redundancy condition 11 and / or the isolation condition 12 is minimized.

[0044] It can be specified that the device 1 includes a fail - safe device 5. If at least one predefined redundancy condition 11 can no longer be satisfied by the switching configuration or at least one isolation condition 12 can no longer be satisfied, the vehicle 50 can be switched by means of the fail - safe device 5 to a safer state. This is the case, for example, if a fault results in there no longer being sufficient resources in general (such as computing power, memory, etc.) available for the safety - relevant application instances 60, 61. The vehicle 50 is then, for example, driven by the fail - safe device 5 to the side of the road and parked, where automatic continued driving is prevented.

[0045] The operation of the application placement device 4 during the calculation of the configuration 62 is explained below by way of example. As described above, the application placement device 4 is responsible for placing the application instances 60, 61 in order to be able to re - establish the predefined redundancy condition 11 and / or the isolation condition 12. For this purpose, the application placement device 4 attempts to find computing nodes with sufficient resources (in particular computing power, memory and installed software) in order to be able to execute the new application instances 60, 61 in order to be able to replace the isolated application instances 60, 61. If insufficient resources are available, the application placement device 4 can deactivate application instances 60, 61 with a lower priority in order to make resources available for application instances 60, 61 with a higher priority.

[0046] In the following example, the application placement problem (Application Placement Problem) is solved, for example, by an integer linear programming method.

[0047] First, formulate an arithmetic expression for the application placement problem. To this end, extract the following parameters from the current state of the vehicle and one or more newly launched application instances 60, 61. Then, these parameters are fed as input parameters into a solution method (solver) for the application placement problem.

[0048] - I: The set of application instances 60, 61 to be placed.

[0049] - A: The set of applications for which In addition, the following must apply:

[0050] - N: The set of computing nodes.

[0051] - C*: A configuration matrix that describes the current configuration or the currently enabled placement, where, if i ∈ I is executed by n ∈ N, otherwise Note here that for each new application instance i neu ∈ I, for which it is desired to re-establish the redundancy conditions that existed before the failure, the following applies:

[0052]

[0053] - R: A placement restriction matrix, where R i,n = 1 if all software conditions for n ∈ N and i ∈ I are satisfied; otherwise R i,n = 0.

[0054] - Φ n : The storage capacity of n ∈ N.

[0055] - Ω n : The computing capacity of n ∈ N.

[0056] - φ i : The storage requirement of i ∈ I.

[0057] - ω i : The computing requirement of i ∈ I.

[0058] - π a : The minimum number of computing nodes on which a ∈ A must be executed, i.e., the hardware isolation condition.

[0059] Based on these parameters, the application placement device 4 calculates a new configuration matrix C, where C i,n = 1 if i ∈ I should be executed on n ∈ N; otherwise C i,n = 0. Thus, there are 2 |I|*|N| potential solutions. However, not all of these solutions are valid.

[0060] To define the conditions for a configuration to be valid, five linear boundary conditions are defined below:

[0061] Boundary condition 1:

[0062] An application instance 60, 61 must be executed by exactly one computing node:

[0063]

[0064] Boundary condition 2:

[0065] The sum of the storage requirements of all application instances 60, 61 executed on a computing node is not allowed to exceed the storage capacity of that computing node:

[0066]

[0067] Boundary condition 3:

[0068] The sum of the computing power requirements of all application instances 60, 61 executed on a computing node is not allowed to exceed the computing power of that computing node:

[0069]

[0070] Boundary condition 4:

[0071] An application instance 60, 61 runs only on a computing node that provides the software required by the application instance 60, 61:

[0072]

[0073] Boundary condition 5:

[0074] Application instances 60, 61 belonging to the same application must run on a minimum number of different computing nodes, i.e., the hardware isolation condition must be satisfied for each application. To express this condition linearly, an auxiliary variable matrix is introduced, which is defined as:

[0075]

[0076] With the help of this auxiliary matrix, this condition can be defined by the following linear expression:

[0077]

[0078] To illustrate boundary condition 5, consider the following example. By assuming the following input variables and configuration matrix C, it is shown that boundary condition 5 applies to application a1 but not to application a2.

[0079] N = {n1, n2, n3, n4}, I = {i1, i2, i3, i4, i5, i6}

[0080] where a1 = {i1, i2, i3} and a2 = {i4, i5, i6},

[0081]

[0082]

[0083] First, discuss the application of a1:

[0084] Since Boundary condition 5.3 causes In addition, boundary condition 5.2 causes Because

[0085] This results in boundary condition 5.4 also applying because:

[0086]

[0087] Next, it is shown that boundary condition 5 does not apply to the application of a2:

[0088] Because (Note that there is also: ) And boundary condition 5.2 must apply, so Because (x ∈ {4, 5, 6} and y ∈ {2, 3, 4}) And boundary condition 5.3 must apply, so This results in boundary condition 5.4 not being satisfied because:

[0089]

[0090] Although the defined boundary conditions limit the solution space, there will be multiple valid solutions. To determine which solutions are the most preferred, the solver is instructed to find the configuration or placement that maximizes the following optimization criterion:

[0091]

[0092] Due to this optimization criterion, the configuration or application placement with the minimum number of transfers of application instances 60, 61 to other computing nodes is preferred. Pursuing this goal is because a smaller number of transfers especially reduces the time cost when switching configurations.

[0093] Figure 2a 、 2b and 2c shows a schematic diagram of configuration 62 to illustrate the method described in the present disclosure. Figure 2a The original (initial) configuration 62 is shown herein.Figure 2b Shows the configuration 62 calculated by the application placement device. Figure 2c Shows the configuration 62, which is a valid solution to the application placement problem but causes the application instance 60-x to require a total of five transfers.

[0094] In the example shown, it is considered that the configuration 62 includes four applications, which are provided by the active application instances 60-1, 60-2, 60-3, 60-4 and the passive application instances 61-1, 61-2, 61-3, 61-4 redundant thereto, and includes four computing nodes 70-1, 70-2, 70-3, 70-4.

[0095] These four applications require the following resources:

[0096] Application 1 Application 2 Application 3 Application 4 Storage requirement 50 15 15 10 Computing requirement 30 20 30 10 Required software x x, y x, z y, z Hardware isolation 2 2 2 1

[0097] In addition, the following resources are provided by the four computing nodes 70-x (abbreviated as "BK" in the table).

[0098] BK 1 BK 2 BK 3 BK 4 Storage capacity 70 70 120 40 Computing capacity 60 50 100 90 Installed software x, z x, y x, y, z x, y, z

[0099] It is also considered based on Figure 2a the shown configuration 62 that the computing node 70-2 fails and can no longer be used. This results in the application instances 60-1 and 61-2 no longer being provided either. In this case, the switching device switches one of the passive application instances 61-1 to the "active" operating state (illustrated by the change of the reference numeral from 61-1 to 60-1).

[0100] After the switching, the new passive application instances 61-2, 61-2 are started by the application placement device to reconstruct the redundancy condition applicable before the failure of the computing node 70-2.

[0101] Based on the currently enabled configuration 62 (i.e., Figure 2a the configuration 62 shown in

[0102] Figure 2b and the parameters for the applications and the computing nodes 70-x, the application placement device calculates a new configuration 62 or a new application placement, which requires as few transfers of the application instances 60-x, 61-x as possible.

[0103] The solution of the application placement device that requires only a single transfer is shown in Figure 2bThe configuration 62 shown in [Figure] is the best configuration 62 with respect to the optimization goal of the application placement device, that is, the application instances 60-x, 61-x must be transferred as few as possible.

[0104] In addition to this solution, there are multiple other valid solutions. However, these solutions do not achieve the optimization goal and are therefore not considered the best solutions. Figure 2c The configuration 62 that exemplarily shows such a non-optimal solution in [Figure] requires five transfers for it.

[0105] If there are not enough resources (computing nodes, computing power, storage, etc.), the application placement device can also stop the application instances 60-x, 61-x.

[0106] Two embodiments of the method and device are described below, which can provide solutions in the case of limited resources.

[0107] Figure 3 The schematic diagram of the embodiment of the method is shown in [Figure]. In the embodiment, it is stipulated to assign priority classes to the application instances respectively. In the above example with four applications, for the sake of clarity, the following priority classes are considered, for example:

[0108] Application 1: Low

[0109] Application 2: Highest

[0110] Application 3: High

[0111] Application 4: High

[0112] To switch the configuration, the configuration is calculated separately for each subset formed by the application instances from at least one assigned priority class. It is also stipulated that the subset is formed such that the subset gradually only includes the application instances whose assigned priority classes reach the corresponding minimum priority class. In particular, the following subsets S1, S2, S3, S4 are formed.

[0113] S1 = Highest ∪ High ∪ Low ∪ Lowest

[0114] S2 = Highest ∪ High ∪ Low

[0115] S3 = Highest ∪ High

[0116] S4 = Highest

[0117] To calculate, it is then stipulated that the configurations for the subsets S1, S2, S3, S4 are calculated in parallel with each other by the application placement device, that is, calculated simultaneously by computing threads that execute in parallel with each other, as Figure 3 schematically shown in [Figure], where the computing threads are shown at time t. Then the application placement device selects the best or optimal configuration among the calculated configurations.

[0118] It can also be stipulated that if the pre-stipulated maximum calculation time 20 is reached or exceeded, the calculation is interrupted, wherein the calculated configuration is selected for the switching configuration, and the calculated configuration includes application instances with the maximum number of highest-priority classes respectively. Thereby, it is possible to control the switching configuration or calculation especially in cases where time has an important influence.

[0119] If the maximum calculation time 20 is stipulated, then there are only configurations for subsets S3 and S4, while the maximum calculation time 20 is not sufficient for subsets S1 and S2.

[0120] Based on Figure 2a the configuration 62 shown in, it can be considered that it is not a failure of computing node 70-2, but a failure of computing node 70-3. As a result, not all application instances 60-x, 61-x executed before the failure can be distributed to the remaining computing nodes 70-1, 70-2, 70-4, because some boundary conditions (see above) cannot be satisfied. However, through the priority classes defined above, at least one configuration 62 or application placement can be calculated, which takes into account the applications or application instances 60-x, 61-x with high and the highest corresponding priority classes. Figure 4 The resulting configuration 62 is shown.

[0121] Figure 5 The schematic diagram of the implementation manner of the method is shown in. In principle, this implementation manner is designed as the implementation manner combined with Figure 3 and Figure 4 described above. However, it is stipulated that for subsets S1, S2, S3, S4, the configuration 62 is calculated serially through the application placement device. This has the advantage that all computing capabilities can be provided when calculating the configurations for subsets S1, S2, S3, S4. It is also stipulated here that the configuration 62 is first calculated for the subset including the maximum number of highest-priority classes respectively, that is, in the example according to the order: S1, S2, S3, S4.

[0122] In particular, it is stipulated that the calculation is continued only when the previous calculation is unsuccessful or no solution or configuration 62 (represented by "X" in Figure 4 ) is obtained. In the shown example, only one solution or one configuration 62 is found for subset S4, that is, only one application placement or one configuration 62 can be calculated, and the application with the highest priority class is considered.

[0123] List of reference numerals:

[0124] 1 Device

[0125] 2 Monitoring device

[0126] 3 Switching device

[0127] 4 Application placement device

[0128] 5 Fault safety device

[0129] 10 Sensor data

[0130] 11 Redundancy condition

[0131] 12 Isolation condition

[0132] 20 Maximum calculation time

[0133] 30 Control signal

[0134] 50 Vehicle

[0135] 51 Sensor

[0136] 52 Actuator device

[0137] 60, 60 - x Application example (active)

[0138] 61, 61 - x Application example (passive)

[0139] 62 Configuration

[0140] 63 Switching signal

[0141] 70 - x Computing node

[0142] S x Subset

[0143] t Time

Claims

1. A method for reconfiguring an autonomously driving vehicle (50) in a fault situation, wherein, Application instances (60-x, 61-x) are distributed across multiple computing nodes (70-x) and executed according to a predefined configuration (62), where sensor data (10) detected by at least one sensor (51) is fed to at least some of the application instances (60-x, 61-x), and where control signals (30) for controlling (51) a vehicle (50) are generated and provided by at least some of the application instances (60-x, 61-x), where the application instances (60-x, 61-x) and / or the operating system and / or the hardware corresponding to the computing nodes (70-x) are monitored by at least one monitoring device (2), where faults in the application instances (60-x, 61-x) and / or the operating system and / or the hardware are identified by the at least one monitoring device (2), where the identified faults are isolated by switching, by means of a switching device (3), to application instances (61-x) that are redundant with respect to the respective application instances (60-x) involved, and where, by means of an application placement device (4), a switched configuration of the configuration (62) is established, and the predefined redundancy conditions (11) and / or isolation conditions (12) for the application instances (60-x, 61-x) are re-established, where the switched configuration is performed such that the number of transfers of application instances (60-x, 61-x) to other computing nodes (70-x) required to establish the predefined redundancy conditions (11) and / or isolation conditions (12) is minimized or minimized, thereby solving the application placement problem, where a configuration that maximizes the following optimization criterion is selected from the valid solutions determined by a plurality of boundary conditions: Among them, C*: indicates the configuration matrix of the current configuration, where, If i ∈ I is executed through n ∈ N, otherwise And C: the new configuration matrix, where C i,n = 1 if i ∈ I should be executed on n ∈ N; otherwise it is C i,n = 0, and I: the group of application instances to be placed, N: the group of computing nodes (70 - x).

2. The method according to claim 1, wherein The application instances (60-x, 61-x) are each assigned or assigned a priority class, where, for the switched configuration, the configuration (62) is calculated separately for each subset (Sx), which is formed by the application instances (60-x, 61-x) of at least one assigned priority class.

3. The method according to claim 2, characterized in that, The subset (Sx) is formed such that the subset (Sx) gradually includes only the application instances (60-x, 61-x) of the assigned priority classes up to the respective minimum priority class.

4. The method according to claim 2, wherein The configuration (62) is calculated for the subsets (Sx) at least partly in parallel by means of the application placement device (4).

5. The method according to claim 2, wherein The configuration (62) is calculated for the subsets (Sx) at least partly serially by means of the application placement device (4).

6. The method according to claim 5, characterized in that, First, the configuration (62) is calculated here for the subset (Sx) that includes the largest number of application instances of the highest priority class.

7. The method according to any one of claims 4 to 6, characterized in that If a predefined maximum calculation time (20) is reached or exceeded, the calculation is interrupted, where the calculated configuration (62) that includes the application instances (60-x, 61-x) with the largest number of the highest priority classes is selected for the switched configuration.

8. An apparatus (1) for reconfiguring an autonomously driving vehicle (50) in case of a fault situation, wherein, In the vehicle (50), application instances (60-x, 61-x) are executed distributed over a plurality of computing nodes (70-x) according to a predefined configuration (62), wherein sensor data (10) detected by at least one sensor (51) is fed to at least some of the application instances (60-x, 61-x), and wherein control signals (30) for controlling the vehicle (50) are generated and provided by at least some of the application instances (60-x, 61-x). The apparatus comprises at least one monitoring device (2), at least one switching device (3) and at least one application placement device (4), wherein the at least one monitoring device (2) is configured to monitor the application instances (60-x, 61-x) and / or the operating system and / or the hardware corresponding to the computing nodes (70-x) and to identify faults in the application instances (60-x, 61-x) and / or the operating system and / or the hardware, wherein the switching device (3) is configured to isolate the identified faults by switching to an application instance (61-x) that is redundant with respect to the respective application instance (60-x) involved, and wherein the application placement device (4) is configured to re-establish the predefined redundancy conditions (10) and / or isolation conditions (12) for the application instances by a switched configuration of the configuration (62), and the switched configuration is carried out such that the number of transfers of the application instances (60-x, 61-x) to other computing nodes (70-x) required to establish the predefined redundancy conditions (11) and / or isolation conditions (12) is minimized, wherein for this purpose an application placement problem is solved, and a configuration is selected from the valid solutions determined by a plurality of boundary conditions that maximizes the following optimization criterion: Among them, C*: represents the configuration matrix of the current configuration, where, If i ∈ I is executed through n ∈ N, otherwise And C: the new configuration matrix, where C i,n = 1 if i ∈ I should be executed on n ∈ N; otherwise it is C i,n = 0, and I: the group of application instances to be placed, N: the group of computing nodes (70 - x).

9. The device according to claim 8, characterized in that, The application instances (60-x, 61-x) are each assigned a priority class, wherein the application placement device (4) is further configured to calculate the configuration (62) separately for a subset (Sx) formed by the application instances (60-x, 61-x) of at least one assigned priority class for the switched configuration.

10. A vehicle (50) comprising at least one apparatus (1) according to claim 8 or 9.

Citation Information

Patent Citations

  • Fault-Tolerance Pattern And Switching Protocol For Multiple Hot And Cold Standby Redundancies

    CN107229221A

  • Fault-tolerant system architecture for the control of a physical system, in particular a machine or a motor vehicle

    US20170249214A1