Service electronic control unit and method for fault recovery in heterogeneous real-time systems

Abstract

A heterogeneous real-time system (10) includes a service ECU (30) and a main ECU (20). The main ECU (20) includes a microcontroller ([mu] C) and base software (RT-BS) having a real-time operating system (RT-OS) and a real-time application software component (RT-T) to execute a real-time task. The service ECU (30) includes a microprocessor ([mu] P) and a second operating system (s-OS) and at least one second application software component (SOA). The service ECU (30) further comprises backup software (BU) comprising a third real-time application software component (RT-T ') for executing the real-time task of the main ECU (20) by the service ECU (30) in the event of a failure of the main EUC (20). When it is detected that the main ECU (20) includes a failure, the service ECU (30) executes the virtual machine manager program (HV) such that the virtual machine manager program (HV) creates a second virtual machine (PAT2) for executing a third real-time application software component (RT-T '), and loads the backup software (BU) into the second virtual machine (PAT2) and runs the backup software (BU).

Description

Technical Field

[0001] Aspects of the present disclosure relate to a service electronic control unit (ECU) for fault recovery in a heterogeneous real-time system and a method for fault recovery in a heterogeneous real-time system. Further, the present disclosure relates to a heterogeneous real-time system including a service electronic control unit, a computer program and a computer readable medium. Background Art

[0002] In the past, the software of cars was primarily designed to perform safety-critical real-time tasks. With the trend towards the Internet of Things and autonomous driving, the need for service-oriented software is rapidly emerging into the current world. This causes fundamentally different software and hardware architectures to work together on the same car. At the same time, since human drivers are no longer a backup layer in the case of fully autonomous cars, the need for fault-tolerant software is also increasing.

[0003] The classic strategy for improving mission-critical availability is to double the amount of hardware for each critical device. This approach is costly and does not cover common cause failures when simply doubling the same hardware and software.

[0004] The typical electrical and electronic architecture for future automotive systems consists of two fundamentally different types of electronic control units (ECUs). On the one hand, there are ECUs developed to execute real-time critical software on microcontroller (μC) based hardware. On the other hand, there are ECUs designed to execute service-oriented applications on microprocessor (μP) based hardware.

[0005] The present disclosure aims to provide an electronic control unit (ECU) and method for fault recovery in a heterogeneous real-time system, which allows improving the availability of key software functions in the heterogeneous real-time system. Summary of the invention

[0006] According to the present disclosure, the above mentioned objects are achieved by a heterogeneous real-time system according to the features of claim 1 .

[0007] The above mentioned object is also achieved by a method according to the features of present claim 10 .

[0008] Advantageous embodiments are given in the dependent claims.

[0009] According to a first aspect, the above-mentioned object is achieved by a heterogeneous real-time system. The heterogeneous real-time system comprises a service ECU and a master electronic control unit (master ECU).

[0010] The master ECU comprises a microcontroller and / or basic software, the basic software having a real-time operating system and a real-time application software component to perform real-time tasks, in particular to perform real-time tasks according to predefined real-time constraints. Preferably, a first safety integrity requirement is assigned to the real-time task of the master ECU, i.e., the master ECU must perform the real-time task such that the first safety integrity requirement is met. Furthermore, the master ECU must perform the real-time task such that the real-time task is provided within a predefined time frame.

[0011] The service ECU comprises a microprocessor and a second operating system and at least one second application software component for executing the service oriented application. Preferably, a second safety integrity requirement is assigned to the service oriented application, wherein the second safety integrity requirement is lower than the first safety integrity requirement.

[0012] The service ECU includes a hypervisor program. The service ECU is configured to start the hypervisor program and execute the hypervisor program so that the hypervisor program provides a first virtual machine, which is configured to execute at least one second application software component. The first virtual machine includes a second operating system and at least one second application software component.

[0013] The service ECU also includes a non-volatile memory and backup software for backing up the execution of the real-time tasks of the main ECU in the event of a failure of the main ECU. The backup software includes a third real-time application software component for executing the real-time tasks of the main ECU through the service ECU in the event of a failure of the main ECU.

[0014] The backup software is stored in a non-volatile memory of the service ECU. The non-volatile memory may include a read-only memory (ROM). Preferably, recovery of the real-time task is initiated only when a fault of the master ECU is detected. Therefore, the service ECU is configured to monitor whether the master ECU includes a fault.

[0015] Furthermore, when the service ECU detects that the main ECU includes a fault, the service EUC is configured to trigger or instruct the virtual machine manager program so that the virtual machine manager program creates a second virtual machine for executing the third real-time application software component and allocates processing and storage and peripheral resources from the first virtual machine to the second virtual machine. In addition, the service ECU is configured to load the backup software into the second virtual machine and run the backup software. For example, the loading of the backup software and the startup execution of the backup software are controlled by the virtual machine manager program.

[0016] Furthermore, the service ECU is configured to execute the second operating system and the second application software component in the first virtual machine while executing the backup software in the second virtual machine in parallel.

[0017] As a reaction to the failure, the virtual machine manager instantiates a second virtual machine, in particular loads a backup of the critical functions (e.g. real-time tasks) and starts it. The virtual machine manager is responsible for interference avoidance. The restored critical real-time tasks can then run in parallel (by side) with the service-oriented applications of the service ECU on the same microprocessor or microcontroller. In particular, the second application software component can be executed during the creation of the second virtual machine.

[0018] The master ECU may also be referred to as a master embedded system, and the service ECU may also be referred to as a service embedded system.

[0019] The provided solution offers the advantage of being very flexible, since the software of the master EUC can be backed up with a service ECU that has a completely different hardware architecture. This flexibility can lead to a wider range of product varieties and / or cost reduction. Since the master ECU and the service ECU can use different hardware architectures, the design diversity can be increased. Therefore, the availability of the system can be increased overall.

[0020] This approach is cost-effective because no new redundant hardware is required to increase the availability of critical software functions.

[0021] Due to virtualization, the resources available for the first virtual machine are reduced and its performance may be degraded. Therefore, only when a failure of the main ECU is detected, the recovery of the real-time task is initiated (creating a second virtual machine and further virtualizing and loading the backup software). During the normal state, all system resources of the service ECU system are available to the service-oriented application, and the resources used for backup are occupied only in the failover state.

[0022] The heterogeneous real-time system may include more than one master ECU, and the service ECU may be configured to provide the backup functions described above to the more than one master ECU.

[0023] In at least one embodiment of the first aspect, the second operating system is a Portable Operating System Interface (POSIX) compliant operating system, and / or the at least one second application software component is a service-oriented application software component for executing a service-oriented application.

[0024] In at least one embodiment of the first aspect, the virtual machine manager program is stored in a non-volatile memory of the service ECU, and the service ECU is further configured to load the virtual machine manager program from the non-volatile memory into a program memory of the service ECU (particularly via a boot loader of the service ECU), and start the virtual machine manager program. Starting may include loading a kernel module.

[0025] The loading and starting of the virtual machine manager program can be done at any time before the failure of the main ECU occurs. Since the execution of the virtual machine manager consumes only a few resources, it can be permanently executed outside the second operating system of the service ECU. Therefore, the startup time of the virtual machine manager program itself is not important.

[0026] In at least one embodiment of the first aspect, the backup software further comprises a third basic software having a third real-time operating system. The restored real-time task may need to be run on the microprocessor of the service ECU, while the initial real-time task is executed on the microcontroller of the main ECU. This fact may require a redesign and re-implementation of the real-time tasks for the microprocessor system. Advantageously, this implementation increases the diversity of the real-time system, thereby contributing to increased failure safety.

[0027] In at least one embodiment of the first aspect, the basic software of the main ECU applies a security mechanism including at least memory separation and / or stack protection, and the third basic software of the backup software applies a security mechanism compatible with the security mechanism of the basic software of the main ECU in the following manner: the real-time application software component of the main ECU and the third real-time application software component can use the same source code but be compiled differently. This helps to reduce the workload of redesigning and re-implementing the real-time tasks of the microprocessor system.

[0028] In at least one embodiment of the first aspect, the third real-time operating system of the standby software and the real-time operating system of the main ECU are compatible in the following manner: the real-time application software component of the main ECU and the third real-time application software component can use the same source code but are compiled differently. Therefore, it is necessary to recompile the real-time application software component to transfer the program, but there is no need to change the source code of the real-time application software component. In this way, the workload of redesigning and re-implementing the real-time tasks of the microprocessor system can be minimized.

[0029] In at least one embodiment of the first aspect, the third basic software of the backup software is compatible with the basic software of the main ECU in such a way that the real-time application software component of the main ECU and the third real-time application software component can use the same source code but be compiled differently, which can reduce the workload of redesigning and re-implementing the real-time tasks of the microprocessor system.

[0030] In at least one embodiment of the first aspect, the virtual machine manager program is configured to provide interference avoidance for the first virtual machine and the second virtual machine, that is, the virtual machine manager program ensures that the system in the first virtual machine will not be affected by the system in the second virtual machine, and vice versa. For example, the first virtual machine is completely isolated from the second virtual machine. If one of the virtual machines crashes, the other will not be affected.

[0031] In at least one embodiment of the first aspect, the second virtual machine includes a software architecture according to the AUTOSAR Classic Platform standard, and the first virtual machine includes a software architecture according to the AUTOSAR Adaptive Platform standard.

[0032] According to a second aspect, the above-mentioned purpose is achieved by a method for fault recovery in a heterogeneous real-time system. The heterogeneous real-time system comprises a service ECU according to the first aspect and a main electronic control unit (main ECU). The main ECU comprises a microcontroller and / or basic software, the basic software having a real-time operating system and a real-time application software component to perform real-time tasks according to predefined real-time constraints. Preferably, a first safety integrity requirement is assigned to the real-time task of the main ECU.

[0033] The method according to the second aspect comprises the following steps:

[0034] -Monitoring whether the main ECU includes a fault by the service ECU, and when it is detected that the main ECU includes a fault,

[0035] -- triggering or executing the virtual machine manager program by the service ECU, so that the virtual machine manager program creates a second virtual machine for executing the third real-time application software component in addition to the existing first virtual machine, and allocates processing and storage and peripheral resources from the first virtual machine to the second virtual machine, and

[0036] -- Loading the backup software into the second virtual machine via the service ECU, in particular via the virtual machine manager program of the service ECU, and starting the execution of the backup software by the second virtual machine via the service ECU, in particular via the virtual machine manager program of the service ECU.

[0037] Therefore, the service ECU executes the second operating system and the second application software component in the first virtual machine and the backup software in the second virtual machine in parallel.

[0038] In at least one embodiment of the second aspect, the virtual machine manager program is stored in a non-volatile memory of the service ECU, and the method includes an additional step: before detecting that the main ECU includes a fault, triggering or executing the boot loader of the service ECU by the service ECU, so that the boot loader loads the virtual machine manager program from the non-volatile memory into the program memory to start the virtual machine manager program and create a first virtual machine including a second operating system and at least one second application software component.

[0039] The optional embodiments of the first aspect may also exist in the second aspect correspondingly and have corresponding effects.

[0040] According to a third aspect, the above mentioned object is achieved by a computer program which, when executed by a processor of a service ECU, causes the service ECU to carry out the steps of the method according to the second aspect.

[0041] According to a fourth aspect, the above mentioned object is achieved by a computer readable medium comprising the computer program according to the third aspect.

[0042] The computer program may be implemented as a computer-readable instruction code in any suitable programming language (such as JAVA, C++, etc.). The computer program may be stored on a computer-readable storage medium (CD-Rom, DVD, Blu-ray disc, removable drive, volatile or non-volatile memory, built-in memory / processor, etc.). The instruction code may program a computer or other programmable device (such as a control unit for an engine of a motor vehicle, in particular) to perform the desired function in this way. Further, the computer program may be provided on a network (such as the Internet) from which the user may download it as needed.

[0043] The optional embodiments of the first aspect and the second aspect may also exist in the third aspect and the fourth aspect correspondingly and have corresponding effects.

[0044] The present disclosure will be described in more detail below with reference to the accompanying drawings, which illustrate embodiments of the present disclosure. When viewing the following detailed description, these aspects and other aspects of the present disclosure will become more fully understood. After viewing the following description of specific exemplary embodiments of the present disclosure in conjunction with the accompanying figures, other aspects, features and embodiments of the present disclosure will become apparent to those of ordinary skill in the art. Although the features of the present disclosure may be discussed with respect to certain embodiments and figures below, all embodiments of the present disclosure may include one or more advantageous features discussed herein. In other words, although one or more embodiments may be discussed as having certain advantageous features, one or more of such features may also be used according to the various embodiments of the present disclosure discussed herein. In a similar manner, although exemplary embodiments may be discussed below as device, system or method embodiments, it should be understood that such exemplary embodiments may be implemented in various devices, systems and methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 illustrates an exemplary embodiment of a heterogeneous real-time system,

[0046] Figure 2 An exemplary flow chart of a procedure for failure recovery in a heterogeneous real-time system is illustrated,

[0047] Figure 3 The diagram shows the first stage of failure recovery in a heterogeneous real-time system.

[0048] Figure 4 Diagram showing the second phase of failure recovery in a heterogeneous real-time system, and

[0049] Figure 5 The diagram illustrates the third phase of failure recovery in a heterogeneous real-time system. DETAILED DESCRIPTION

[0050] The detailed description set forth below, in conjunction with the attached drawings, is intended to describe various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced.

[0051] The detailed description includes specific details in order to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some instances, certain structures and components are shown in block diagram form to avoid obscuring such concepts.

[0052] In the various figures, like reference numerals are used for elements having essentially the same function, but these elements need not be identical in all details.

[0053] Figure 1 An exemplary embodiment of a heterogeneous real-time system 10 is shown, in particular a heterogeneous automotive real-time system 10. The heterogeneous real-time system 10 comprises a main electronic control unit (main ECU) 20 and a service electronic control unit (service ECU) 30, which are arranged, for example, in a single vehicle.

[0054] The main ECU 20 comprises a microcontroller μC, basic software RT-BS having a real-time operating system RT-OS and real-time application software components (RT-T) to execute real-time tasks according to predefined real-time constraints, wherein a first safety integrity requirement is assigned to the real-time tasks.

[0055] The main ECU 20 may include a software architecture according to the AUTOSAR Classic Platform standard.

[0056] Figure 1 , Figures 3 to 5 The service ECU 30 shown in FIG. 4 comprises a microprocessor μP. The microprocessor μP may comprise more than one core, for example cores CORE1, CORE2. Alternatively, the ECU 30 may comprise a second microcontroller.

[0057] The service ECU 30 includes a second operating system o-OS (e.g., a Portable Operating System Interface (POSIX) compliant operating system) and at least one second application software component SOA (e.g., at least one service-oriented application software component for executing a service-oriented application). The service ECU 30 may include a software architecture according to the AUTOSAR Adaptive Platform standard.

[0058] Alternatively, the service ECU 30 may include a further real-time operating system and further real-time application software components for executing further real-time tasks according to further predefined real-time constraints. In this case, the service ECU 30 may also include a software architecture according to the AUTOSAR Classic Platform standard.

[0059] Figure 1 , Figure 3 , Figure 4 and Figure 5 The real-time system 10 shown in is heterogeneous both from a software perspective (because different software architectures have different types of operating systems) and from a hardware perspective (because different types of processor architectures are used to execute different software architectures).

[0060] The second safety integrity requirement is assigned to Figure 1 , Figure 3 , Figure 4 and Figure 5 The service-oriented application provided by the second application software component of the service ECU 30 shown in FIG. 1 , wherein the second integrity requirement is lower than the first integrity requirement.

[0061] The real-time tasks of the main ECU 20 may involve controlling the braking or steering systems of the vehicle. The service-oriented applications of the service ECU 30 may involve, for example, controlling the climate control of the passenger compartment.

[0062] For example, the real-time tasks of the main ECU 20 may include ASIL A level or ASIL B level or ASIL C level or ASIL D level, and the service-oriented applications of the service ECU 30 may include QM (Quality Management) level. ASIL refers to the Automotive Safety Integrity Level. It is a risk classification system defined by the ISO 26262 standard for the functional safety of road vehicles. There are QM and four ASILs - A, B, C and D.

[0063] The service ECU 30 includes a nonvolatile memory and a backup software BU. The backup software BU includes a third real-time application software component RT-T′ for executing the real-time tasks of the main ECU 20 by the service ECU 30 in the event of a failure of the main ECU 20. The backup software BU is stored in the nonvolatile memory of the service ECU 30.

[0064] Furthermore, the service ECU 30 includes a virtual machine manager program HV ( Figure 1 The service ECU 30 is configured to start a virtual machine manager program and execute the virtual machine manager program so that the virtual machine manager program provides a first virtual machine configured to execute at least one second application software component SOA. The first virtual machine PAT1 includes a second operating system s-OS and at least one second application software component SOA.

[0065] In the normal mode, the main ECU 20 executes real-time safety critical tasks or executes real-time software application components, respectively, while the first virtual machine of the service ECU 30 executes service oriented applications or executes at least one second application software component SOA, respectively.

[0066] The service ECU 30 is configured, for example, to monitor real-time safety-critical tasks on the main ECU 20, and thus can detect a failure of the main ECU 20. To implement failure recovery and failover on the service ECU 30, respectively, including monitoring of safety-critical real-time tasks on the main ECU 20 and control of a virtual machine manager (HV), can be handled by a failure recovery software application RA of the service ECU 30.

[0067] Figure 2 An exemplary flowchart of such a routine is shown. The routine is executed by the service ECU 30.

[0068] like Figure 2 As shown in FIG. 1 , the program starts in step S01 , for example when the vehicle is started.

[0069] The virtual machine manager program HV may be stored in the nonvolatile memory of the service ECU 30 , and may be loaded and started before a failure of the main ECU 20 is detected.

[0070] Therefore, in step S03 , the program triggers or instructs, for example, a boot loader of the service ECU 30 , so that the boot loader loads the virtual machine manager program HV from the nonvolatile memory NVM into the program memory and starts the virtual machine manager program HV.

[0071] For example, the virtual machine manager is loaded into a reserved memory area in the program memory, which area cannot be accessed by the second operating system s-OS of the service ECU 30 .

[0072] Since the execution of the virtual machine manager program HV consumes only few resources, it can be permanently executed outside the second operating system s-OS.

[0073] Alternatively, the virtual machine manager program HV may be loaded and started after a failure of the main ECU 20 is detected. However, since the time to load and start the virtual machine manager program HV adds up to the time until the real-time task can be executed by the service ECU 30, whether this option is possible depends on the time constraints of the real-time task of the main ECU 20.

[0074] In the case where the service ECU includes a microprocessor system with a POSIX-compatible operating system, the virtual machine manager program HV includes, for example, a partition type 2 virtual machine manager, in particular a jailhouse virtual machine manager, which is started from the POSIX-compatible operating system (e.g., Linux) of the service ECU 30. After the startup and initialization phase, it runs bare metal and is not affected by failures or even crashes of the host system (here, for example, a Linux system). The jailhouse virtual machine manager fully controls the hardware and does not require external support. However, unlike other bare metal virtual machine managers, it is loaded and configured by a normal Linux system. Its management interface is based on the Linux infrastructure.

[0075] In the case when the service ECU 30 includes a microcontroller system having a real-time operating system, the virtual machine manager program HV may include, for example, a partition type 1 virtual machine manager.

[0076] In step S05, the program starts monitoring whether the main ECU 20 includes a fault. For example, the monitoring continues until a fault of the main ECU 20 is detected. Step S05 is also Figure 3 It is shown in Figure 3 Again, it shows Figure 1 Real-time system 10.

[0077] In step S07 ( Figure 2 ), when the program detects that the ECU includes a fault, the program triggers or instructs the virtual machine manager program HV, so that the virtual machine manager program HV creates a second virtual machine PAT2 for executing the third real-time application software component, and allocates processing and storage and peripheral resources from the first virtual machine PAT1 to the second virtual machine PAT2. This step is also Figure 4 It is shown in Figure 4 Again, it shows Figure 1 The service ECU 30 is provided.

[0078] The hypervisor HV partitions the system and allocates physical resources (such as CPU cores or memory areas) to its clients in a one-to-one manner without overcommitting resources. Therefore, the overhead introduced by the hypervisor HV is low and has little impact on the real-time capabilities of the performed backup tasks.

[0079] As for the execution of the at least one second application software component and the associated second operating system, only reduced system resources of the first virtual machine PAT1 are available (compared to a normal mode when the main ECU 20 is not faulty), and performance may be degraded.

[0080] In step S09 ( Figure 2 ), the program instructs, for example, the virtual machine manager to load the backup software BU into the second virtual machine PAT2, and starts executing the backup software BU through the second virtual machine PAT2. This step is also Figure 5 It is shown in Figure 5 Again, it shows Figure 1 The service ECU 30 is provided.

[0081] The second virtual machine may include a software architecture according to the AUTOSAR Classic Platform standard, and the first virtual machine may include a software architecture according to the AUTOSAR Adaptive Platform standard.

[0082] In step S11( Figure 2 ), the procedure ends, for example when the vehicle is stopped or parked.

[0083] Reference mark

[0084] 10 heterogeneous real-time system; 20 main ECU; 30 service ECU; μC microcontroller; μP microprocessor; BU backup software; CORE1, CORE2 CPU cores; HV virtual machine manager program; NVM non-volatile memory; o-OS second operating system; PAT1 first virtual machine; PAT2 second virtual machine; RA fault recovery software application; RT-BS real-time basic software; RT-BS' second real-time basic software; RT-OS real-time operating system; RT-OS' third real-time operating system; RT-T real-time application software component; RT-T' third real-time application software component; SOA second application software component.

Claims

1. A heterogeneous real-time system (10), comprising a main electronic control unit (main ECU (20)) and a service electronic control unit (service ECU (30)) for fault recovery in the heterogeneous real-time system (10), - the main ECU (20) comprises a microcontroller (μC) and basic software (RT-BS), the basic software (RT-BS) having a real-time operating system (RT-OS) and a real-time application software component (RT-T) to perform real-time tasks according to predefined real-time constraints, wherein, assigning a first safety integrity requirement to the real-time task, - the service ECU (30) comprises a microprocessor (μP), a second operating system (s-OS) and at least one second application software component (SOA) for executing a service-oriented application, wherein the second operating system (o-OS) is a Portable Operating System Interface (POSIX) compliant operating system, - the service ECU (30) further comprises a non-volatile memory (NVM), a virtual machine manager program (HV) and a backup software (BU), - the backup software (BU) comprises a third basic software (RT-BS'), the third basic software (RT-BS') having a third real-time operating system (RT-OS') and a third real-time application software component (RT-T'), for executing the real-time task of the main ECU (20) by the service ECU (30) in the event of a failure of the main ECU (20), - the backup software (BU) is stored in the non-volatile memory (NVM) of the service ECU (30), and The service ECU (30) is configured to: - executing the virtual machine manager program (HV) such that the virtual machine manager program (HV) provides a first virtual machine (PAT1), the first virtual machine (PAT1) being configured to execute the at least one second application software component (SOA), - monitoring whether the main ECU (20) includes a fault, and when it is detected that the main ECU (20) includes a fault -- triggering or executing the virtual machine manager program (HV) so that the virtual machine manager program (HV) creates a second virtual machine (PAT2) for executing the third real-time application software component (RT-T') and allocates processing and storage and peripheral resources from the first virtual machine (PAT1) to the second virtual machine (PAT2), and --Load the backup software (BU) into the second virtual machine (PAT2) and run the backup software (BU).

2. The heterogeneous real-time system (10) according to claim 1, wherein: A second safety integrity requirement is assigned to the service-oriented application of the service ECU (30), wherein the second safety integrity requirement is lower than the first safety integrity requirement.

3. The heterogeneous real-time system (10) according to claim 1 or 2, wherein: The at least one second application software component (SOA) is a service-oriented application software component for executing the service-oriented application.

4. The heterogeneous real-time system (10) according to any one of claims 1 to 3, wherein: The virtual machine manager program (HV) is stored in the non-volatile memory (NVM) of the service ECU (30), and the service ECU (30) is further configured to load the virtual machine manager program (HV) from the non-volatile memory (NVM) and start the virtual machine manager program (HV).

5. The heterogeneous real-time system (10) according to any one of claims 1 to 4, wherein: The third real-time operating system (RT-OS') of the backup software (BU) is compatible with the real-time operating system (RT-OS) of the main ECU (20) in such a way that the real-time application software component of the main ECU and the third real-time application software component can use the same source code but be compiled differently.

6. The heterogeneous real-time system (10) according to any one of claims 1 to 5, wherein: The third basic software (RT-BS') of the backup software (BU) is compatible with the basic software (RT-BS) of the main ECU (20) in such a way that the real-time application software component of the main ECU and the third real-time application software component can use the same source code but be compiled differently.

7. The heterogeneous real-time system (10) according to any one of claims 1 to 6, wherein: The basic software (RT-BS) of the main ECU (20) applies at least a safety mechanism of memory separation and / or stack protection, and the third basic software (RT-BS') of the backup software (BU) applies a safety mechanism that is compatible with the safety mechanism of the basic software (RT-BS) of the main ECU (20) in the following manner: the real-time application software component of the main ECU and the third real-time application software component can use the same source code but be compiled differently.

8. The heterogeneous real-time system (10) according to any one of claims 1 to 7, wherein: The virtual machine manager program (HV) is configured to provide interference avoidance for the first virtual machine (PAT1) and the second virtual machine (PAT2).

9. The heterogeneous real-time system (10) according to any one of claims 1 to 8, wherein: The source codes of the third real-time application software component (RT-T') of the backup software (BU) and the real-time application software component (RT-T) of the main ECU (20) are different because the third real-time application software component (RT-T') is a re-implementation of at least a part of the real-time application software component (RT-T) of the main ECU (20), and / or wherein the compiled codes of the third real-time application software component (RT-T') of the backup software (BU) and the third real-time application software component (RT-T') of the main ECU (20) are compiled differently.

10. A method for failure recovery in a heterogeneous real-time system (10), wherein - the heterogeneous real-time system (10) comprises a service ECU (30) and a main electronic control unit (main ECU (20)), - the main ECU (20) comprises a microcontroller (μC) and basic software (RT-BS), wherein the basic software (RT-BS) has a real-time operating system (RT-OS) and a real-time application software component (RT-T') for executing real-time tasks, The service ECU (30) comprises a microprocessor (μP), a second operating system (s-OS) and at least one second application software component (SOA) for executing a service-oriented application, wherein: The second operating system (o-OS) is a Portable Operating System Interface (POSIX) compliant operating system, - the service ECU (30) further comprises a non-volatile memory (NVM), a virtual machine manager program (HV) and a backup (BU) software, - the backup software (BU) comprises a third basic software (RT-BS'), the third basic software having a third real-time operating system (RT-OS') and a third real-time application software component (RT-T'), for executing the real-time tasks of the main ECU (20) by the service ECU (30) in the event of a failure of the main ECU (20), - the backup software (BU) is stored in the non-volatile memory (NVM) of the service ECU (30), and The method comprises the following steps: - monitoring whether the main ECU (20) includes a fault by the service ECU (30), and when it is detected that the main ECU (20) includes a fault, - triggering or executing the virtual machine manager program (HV) by the service ECU (30), so that the virtual machine manager program (HV) creates a second virtual machine (PAT2) for executing the third real-time application software component (RT-T') in addition to the existing first virtual machine (PAT1), and allocates processing and storage and peripheral resources from the first virtual machine (PAT1) to the second virtual machine (PAT2), and --Loading the backup software (BU) into the second virtual machine (PAT2) through the service ECU (30), and starting the execution of the backup software (BU) through the service ECU (30).

11. The method according to claim 10, wherein: The virtual machine manager program (HV) is stored in the non-volatile memory (NVM) of the service ECU (30), and the method comprises the additional steps of: - before detecting that the main ECU (20) includes a fault, triggering or executing a boot loader of the service ECU (30) by the service ECU (30), so that the boot loader loads the virtual machine manager program (HV) from the non-volatile memory (NVM) into a program memory to start the virtual machine manager program (HV) and create the first virtual machine including the second operating system (s-OS) and the at least one second application software component (SOA).

12. A computer program which, when executed by a processor of a service ECU (30), causes the service ECU (30) to carry out the steps of the method according to claim 10 or 11.

13. A computer readable medium comprising a computer program which, when executed by a processor of a service ECU (30), causes the service ECU (30) to carry out the steps of the method according to claim 10 or 11.

Images