Service control unit and method for troubleshooting in a heterogeneous real-time system

Abstract

The heterogeneous real-time system (10) comprises a service ECU (30) and a primary ECU (20). The primary ECU (20) comprises a microcontroller (µC) and basic software (RT-BS) with a real-time operating system (RT-OS) and a real-time application software component (RT-T') for executing a 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). 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 primary ECU (20) by the service ECU (30) in the event of a fault in the primary ECU (20).If it is detected that the primary ECU (20) has a fault, the service ECU (30) executes a hypervisor program (HV) so that the hypervisor program (HV) creates a second virtual machine (PAT2) for executing the third real-time application software component (RT-T') and loads the backup software (BU) into the second virtual machine (PAT2) and executes the backup software (BU).

Description

Technical area

[0001] Aspects of the present disclosure relate to a service control unit (service ECU) for troubleshooting in a heterogeneous real-time system and a method for troubleshooting in a heterogeneous real-time system. Furthermore, the present disclosure relates to a heterogeneous real-time system comprising the service control unit, a computer program, and a computer-readable medium. background

[0002] In the past, automotive software was primarily designed to perform safety-critical real-time tasks. With the trend toward the Internet of Things and autonomous driving, the demand for service-oriented software is rapidly growing. This leads to fundamentally different software and hardware architectures working together in a car. At the same time, the need for fault-tolerant software is increasing, as the human driver is no longer available as a backup in a fully autonomous car.

[0003] A classic strategy for increasing the availability of critical tasks is to duplicate the hardware for each critical device. This is costly and does not cover common-cause failures if the same hardware and software are simply duplicated.

[0004] Typical electrical-electronic architectures for future automotive systems consist of two fundamentally different types of electronic control units (ECUs). On the one hand, there are ECUs designed 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] An object of the invention is to provide a control unit (ECU) and a method for troubleshooting in a heterogeneous real-time system that allows increasing the availability of critical software functionalities in the heterogeneous real-time system. Summary

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

[0007] Furthermore, the above-mentioned object is achieved by the method according to the features of the present claim 10.

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

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

[0010] The primary ECU comprises a microcontroller and / or basic software with a real-time operating system and a real-time application software component for executing a real-time task according to predefined real-time conditions. Preferably, the real-time task of the primary ECU is assigned a first safety integrity requirement, meaning that the primary ECU must execute the real-time task in such a way that the first safety integrity requirements are met. Furthermore, the primary ECU must execute the real-time task in such a way that the real-time task is delivered within a predefined time period.

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

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

[0013] The service ECU also includes non-volatile memory and backup software. The backup software is designed to ensure the execution of the real-time task of the primary ECU in the event of a primary ECU failure. The backup software includes a third real-time application software component for executing the real-time task of the primary ECU by the service ECU in the event of a primary ECU failure.

[0014] The backup software is stored in the non-volatile memory of the service ECU. The non-volatile memory may comprise read-only memory (ROM). Preferably, the recovery of the real-time task is only permitted if a fault is detected in the primary ECU. Therefore, the service ECU is configured to monitor whether the primary ECU has a fault.

[0015] Furthermore, when the service ECU detects that the primary ECU has a fault, the service ECU is configured to trigger or instruct the hypervisor program to provide a second virtual machine for executing the third real-time application software component, and to allocate processing, memory, and peripheral resources from the first virtual machine to the second virtual machine. Additionally, the service ECU is configured to load the backup software into the second virtual machine and execute the backup software. For example, the loading of the backup software and the starting of the execution of the backup software are controlled by the hypervisor 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 in parallel with the execution of the backup software in the second virtual machine.

[0017] The hypervisor instantiates the second virtual machine in response to the failure and, in particular, loads and starts the backup of the critical function, e.g., the real-time task. The hypervisor ensures freedom from interference. The restored critical real-time task can then run side-by-side with the service-oriented application 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 primary ECU can also be called the primary embedded system and the service ECU can also be called the embedded service system.

[0019] The proposed solution offers the advantage of being very flexible, as the software of the primary ECU can be backed up to a service ECU with a completely different hardware architecture. This flexibility can lead to greater product diversity and / or reduced costs. Because different hardware architectures can be used for the primary and service ECUs, design diversity can be increased. Thus, the overall availability of the system can be increased.

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

[0021] As a result of virtualization, the resources for the first virtual machine are reduced, and its performance may degrade. Therefore, the recovery of the real-time task (creating the second virtual machine and further virtualizing and loading the backup software) is only initiated if a failure of the primary ECU is detected. All system resources of the service ECU system are available to the service-oriented application during normal operation, and the backup resources are only allocated during failover.

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

[0023] In at least one embodiment of the first aspect, the second operating system is an operating system compatible with the portable operating system interface POSIX and / or the at least one second application software component is a service-oriented application software component for executing the service-oriented application.

[0024] In at least one embodiment of the first aspect, the hypervisor program is stored in the non-volatile memory of the service ECU, and the service ECU is further configured to load, in particular by a bootstrap loader of the service ECU, the hypervisor program from the non-volatile memory into a program memory of the service ECU and to boot the hypervisor program. Booting may include loading a kernel module.

[0025] Loading and booting the hypervisor program can occur at any time before the primary ECU fails. Because the hypervisor consumes very few resources, it can run continuously alongside the second operating system of the service ECU. Thus, the startup time of the hypervisor program itself is not critical.

[0026] In at least one embodiment of the first aspect, the backup software further comprises a third base software with a third real-time operating system. The restored real-time task may need to run on the microprocessor of the service ECU, while the original real-time task is executed on the microcontroller of the primary ECU. This circumstance may require a redesign and reimplementation of the real-time task for the microprocessor system. Advantageously, such an implementation increases the diversity of the real-time system and therefore contributes to increased fault tolerance.

[0027] In at least one embodiment of the first aspect, the base software of the primary ECU applies security mechanisms that include at least memory separation and / or stack protection, and the third base software of the backup software applies security mechanisms compatible with the security mechanisms of the base software of the primary ECU such that the real-time application software component of the primary ECU and the third real-time application software component can use the same source code, but compiled differently. This helps reduce the effort required to redesign and reimplement the real-time task for a microprocessor system.

[0028] In at least one embodiment of the first aspect, the third real-time operating system of the backup software and the real-time operating system of the primary ECU are compatible such that the real-time application software component of the primary ECU and the third real-time application software component can use the same source code, but compiled differently. Recompiling the real-time application software component is thus necessary for transferring the program, but no changes are required to the source code of the real-time application software component. In this way, the effort required to redesign and reimplement the real-time task for a microprocessor system can be minimized.

[0029] In at least one embodiment of the first aspect, the third base software of the backup software and the base software of the primary ECU are compatible such that the real-time application software component of the primary ECU and the third real-time application software component can use the same source code, but compiled differently. The effort required to redesign and reimplement the real-time task for a microprocessor system can be reduced.

[0030] In at least one embodiment of the first aspect, the hypervisor program is configured to provide mutual immunity to the first and second virtual machines. That is, the hypervisor program ensures that the system in the first virtual machine cannot 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 is not affected.

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

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

[0033] The method according to the second aspect comprises the following steps: - Monitoring by the service ECU whether the primary ECU has a fault, and if it is detected that the primary ECU has a fault, - - triggering or executing the hypervisor program by the service ECU, so that the hypervisor program creates, in addition to an existing first virtual machine, a second virtual machine for executing the third real-time application software component and allocates processing, memory and peripheral resources from the first virtual machine to the second virtual machine, and - - Loading the backup software by the service ECU, in particular the hypervisor program of the service ECU, into the second virtual machine and starting, by the service ECU, in particular the hypervisor program of the service ECU, the execution of the backup software by the second virtual machine.

[0034] Thus, 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.

[0035] In at least one embodiment of the second aspect, the hypervisor program is stored in the non-volatile memory of the service ECU, and the method comprises the additional step of: the service ECU triggering or executing a bootstrap loader of the service ECU before detecting that the primary ECU has a fault, such that the bootstrap loader loads the hypervisor program from the non-volatile memory into a program memory to boot up the hypervisor program and to create the first virtual machine having the second operating system and the at least one second application software component.

[0036] Optional embodiments of the first aspect may also be present in the second aspect and have corresponding effects.

[0037] 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.

[0038] 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.

[0039] The computer program may be implemented as 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, in particular, a control unit for a motor vehicle engine, to perform the desired functions. Furthermore, the computer program may be provided on a network, such as the Internet, from which it may be downloaded by a user as needed.

[0040] Optional embodiments of the first and second aspects may also be present in the third and fourth aspects and have corresponding effects.

[0041] The present disclosure is described in more detail below with reference to the accompanying drawings, which illustrate embodiments of the disclosure. These and other aspects of the present disclosure will become more fully understood upon review of the following detailed description. Other aspects, features, and embodiments of the present disclosure will become apparent to those skilled in the art upon review of the following description of specific exemplary embodiments of the present disclosure in conjunction with the accompanying figures. While features of the present disclosure may be discussed below with reference to certain embodiments and figures, all embodiments of the present disclosure may include one or more of the advantageous features discussed herein.In other words, although one or more embodiments may be discussed as having certain advantageous features, one or more such features may also be used according to the various embodiments of the disclosure discussed herein. Similarly, 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. Short description of the drawings Fig. 1 shows an exemplary embodiment of a heterogeneous real-time system, Fig. 2 shows an example flowchart of a program for debugging a heterogeneous real-time system, Fig. 3 shows a first phase of troubleshooting in a heterogeneous real-time system, Fig. 4 shows a second phase of error correction in a heterogeneous real-time system and Fig. Figure 5 shows a third phase of troubleshooting in a heterogeneous real-time system. Detailed description of the embodiments

[0042] The detailed description set forth below, in conjunction with the accompanying drawings, is intended as a description of various embodiments and is not intended to represent the only embodiments in which the concepts described herein may be practiced. The detailed description includes specific details to provide a thorough understanding of various concepts. However, it will be understood by those skilled in the art that these concepts may be practiced without these specific details. In some cases, certain structures and components are shown in block diagram form to avoid obscuring such concepts.

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

[0044] Fig. 1 shows an exemplary embodiment of a heterogeneous real-time system 10, in particular a heterogeneous motor vehicle real-time system 10. The heterogeneous real-time system 10 has a primary control unit (primary ECU) 20 and a service control unit (service ECU) 30, which are arranged, for example, in a single vehicle.

[0045] The primary ECU 20 comprises a microcontroller µC, a basic software RT-BS with a real-time operating system RT-OS and a real-time application software component (RT-T) for executing a real-time task according to predefined real-time conditions, wherein the real-time task is assigned a first safety integrity requirement.

[0046] The primary ECU 20 may have a software architecture according to the AUTOSAR Classic Platform standard.

[0047] The Fig. The service ECU 30 shown in Figures 1, 3 to 5 comprises a microprocessor µP. The microprocessor µP may comprise more than one core, for example, two cores CORE1, CORE2. Alternatively, the ECU 30 may comprise a second microcontroller.

[0048] The service ECU 30 has a second operating system (o-OS), for example, an operating system compatible with the POSIX portable operating system interface, and at least one second application software component (SOA), for example, at least one service-oriented application software component for executing a service-oriented application. The service ECU 30 can have a software architecture according to the AUTOSAR Adaptive Platform standard.

[0049] Alternatively, the service ECU 30 may include another real-time operating system and another real-time application software component for executing another real-time task according to another predefined real-time conditions. In this case, the service ECU 30 may also have a software architecture according to the AUTOSAR Classic Platform standard.

[0050] The Fig. 1, Fig. 3, Fig. 4 and Fig. The real-time system 10 shown in Figure 5 is heterogeneous both from a software point of view, since different software architectures with different types of operating systems are used to execute the various software architectures, and from a hardware point of view, since different processor architectures are used.

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

[0052] The real-time task of the primary ECU 20 may involve controlling a braking or steering system of the vehicle. The service-oriented application of the service ECU 30 may, for example, involve controlling the air conditioning of the passenger compartment.

[0053] For example, the real-time task of the primary ECU 20 may have an ASIL A, ASIL B, ASIL C, or ASIL D level, and the service-oriented application of the service ECU 30 may have a QM (quality control) level. ASIL stands for Automotive Safety Integrity Level. This 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.

[0054] The service ECU further includes a non-volatile 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 task of the primary ECU 20 by the service ECU 30 in the event of a failure of the primary ECU 20. The backup software BU is stored in the non-volatile memory of the service ECU 30.

[0055] Furthermore, the service ECU 30 has a (in Fig. 1 (not shown). The service ECU 30 is configured to boot the hypervisor program and execute the hypervisor program, so that the hypervisor program provides a first virtual machine configured to execute the at least one second application software component SOA. The first virtual machine PAT1 has the second operating system s-OS and the at least one second application software component SOA.

[0056] In normal mode, the primary ECU 20 executes the safety-critical real-time task or the real-time software application component, while the first virtual machine of the service ECU 30 executes the service-oriented application or the at least one second application software component SOA.

[0057] For example, the service ECU 30 is configured to monitor the safety-critical real-time task on the primary ECU 20 and can therefore detect a fault in the primary ECU 20. To facilitate fault recovery or failover on the service ECU 30, the monitoring of the safety-critical real-time task on the primary ECU 20 and the control of the hypervisor program (HV) can be handled by a fault recovery software application program RA of the service ECU 30.

[0058] Fig. Figure 2 shows an example flowchart of such a program. The program is executed by the service ECU 30.

[0059] As in Fig. 2, the program is started in a step S01, for example when the vehicle is started.

[0060] The hypervisor program HV can be stored in the non-volatile memory of the service ECU 30 and can be loaded and started before a fault of the primary ECU 20 is detected.

[0061] Therefore, in a step S03, the program triggers or instructs, for example, a bootstrap loader of the service ECU 30 so that the bootstrap loader loads the hypervisor program HV from the non-volatile memory NVM into a program memory and starts up the hypervisor program HV.

[0062] For example, the hypervisor is loaded into a reserved memory area in the program memory that the second operating system s-OS of the service ECU 30 cannot access.

[0063] Since the execution of the hypervisor program HV consumes very few resources, it can run permanently alongside the second operating system s-OS.

[0064] Alternatively, the hypervisor program HV could be loaded and booted after a fault is detected in the primary ECU 20. Since the time required to load and boot the hypervisor program HV adds 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 primary ECU 20.

[0065] If the service ECU has a microprocessor system with a POSIX-compatible operating system, the hypervisor program HV, for example, has a partition type 2 hypervisor, specifically the jailhouse hypervisor, which is started from the POSIX-compatible operating system of the service ECU 30, which is, for example, Linux. After the boot and initialization phase, it runs as bare metal and is not affected by errors or even a crash of the host system, for example, the Linux system. The jailhouse hypervisor takes full control of the hardware and requires no external support. However, unlike other bare-metal hypervisors, it is loaded and configured by a regular Linux system. Its management interface is based on the Linux infrastructure.

[0066] If the service ECU 30 comprises a microcontroller system with a real-time operating system, the hypervisor program HV may, for example, comprise a hypervisor of partitioning type 1.

[0067] In step S05, the program begins monitoring whether the primary ECU 20 has a fault. This monitoring continues, for example, until a fault is detected in the primary ECU 20. Step S05 is also in Fig. 3, in which again the real-time system 10 of Fig. 1 is shown.

[0068] In a step S07 ( Fig. 2) If the program detects that the ECU has a fault, the hypervisor program HV is triggered or instructed so that the hypervisor program HV creates a second virtual machine PAT2 to execute the third real-time application software component and allocates processing, memory, and peripheral resources from the first virtual machine to the second virtual machine PAT2. This step is also described in Fig. 4, in which again the service ECU 30 of Fig. 1 is shown.

[0069] The hypervisor program (HV) partitions the system and allocates physical resources, such as CPU cores or memory regions, to its guests on a one-to-one basis without overcommitting resources. Thus, the overhead introduced by the hypervisor program (HV) is minimal and has very little impact on the real-time capability of the backup task being executed.

[0070] With regard to the execution of the at least one second application software component and the related second operating system, only the reduced system resources of the first virtual machine PAT1 are available (compared to the normal mode in which the primary ECU 20 has no fault), the performance could be degraded.

[0071] In a step S09 ( Fig. 2) The program instructs, for example, the hypervisor to load the backup software BU into the second virtual machine PAT2 and to start the execution of the backup software BU by the second virtual machine PAT2. This step is also described in Fig. 5, in which again the service ECU 30 of Fig. 1 is shown.

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

[0073] In a step S11 ( Fig. 2) the program ends, for example when the vehicle stops or parks. Reference symbol 10 heterogeneous real-time system 20 Primary ECU 30 Service ECU µC microcontroller µP microprocessor BU Backup Software CORE1, CORE2 CPU core HV Hypervisor program NVM non-volatile memory o-OS second operating system PAT1 first virtual machine PAT2 second virtual machine RA Troubleshooting Software Application Program RT-BS real-time basic software RT-BS' second real-time base 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] Heterogeneous real-time system (10) comprising a primary control unit, primary ECU, (20) and a service control unit, service ECU (30), for troubleshooting in the heterogeneous real-time system (10), - wherein the primary ECU (20) comprises a microcontroller (µC) and basic software (RT-BS) with a real-time operating system (RT-OS) and a real-time application software component (RT-T) for executing a real-time task according to predefined real-time conditions, wherein the real-time task is assigned a first safety integrity requirement. - 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 an operating system compatible with a portable operating system interface POSIX, - the service ECU (30) further comprises a non-volatile memory (NVM), a hypervisor program (HV) and backup software (BU), - the backup software (BU) comprises a third basic software (RT-BS') with 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 primary ECU (20) by the service ECU (30) in the event of a failure of the primary 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 designed to - executing the hypervisor program (HV) such that the hypervisor program (HV) provides a first virtual machine (PAT1) which is designed to execute the at least one second application software component (SOA), - monitoring whether the primary ECU (20) has a fault, and if it is detected that the primary ECU (20) has a fault, - - triggering or executing the hypervisor program (HV) so that the hypervisor program (HV) creates a second virtual machine (PAT2) for executing the third real-time application software component (RT-T') and allocates processing, memory 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) and running the backup software (BU). [2] The heterogeneous real-time system (10) of claim 1, wherein the service-oriented application of the service ECU (30) is assigned a second safety integrity requirement, and wherein the second safety integrity requirement is lower than the first safety integrity requirement. [3] 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] Heterogeneous real-time system (10) according to one of claims 1 to 3, wherein the hypervisor 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 hypervisor program (HV) from the non-volatile memory (NVM) and to start up the hypervisor program (HV). [5] Heterogeneous real-time system (10) according to one of claims 1 to 4, wherein the third real-time operating system (RT-OS') of the backup software (BU) and the real-time operating system (RT-OS) of the primary ECU (20) are compatible such that the real-time application software component of the primary ECU and the third real-time application software component can use the same source code, but compiled differently. [6] Heterogeneous real-time system (10) according to one of claims 1 to 5, wherein the third basic software (RT-BS') of the backup software (BU) and the basic software (RT-BS) of the primary ECU (20) are compatible such that the real-time application software component of the primary ECU and the third real-time application software component can use the same source code, but compiled differently. [7] Heterogeneous real-time system (10) according to one of claims 1 to 6, wherein the basic software (RT-BS) of the primary ECU (20) applies security mechanisms comprising at least one of memory separation and stack protection, and the third basic software (RT-BS') of the backup software (BU) applies security mechanisms that are compatible with the security mechanisms of the basic software (RT-BS) of the primary ECU (20) such that the real-time application software component of the primary ECU and the third real-time application software component can use the same source code, but compiled differently. [8] Heterogeneous real-time system (10) according to one of claims 1 to 7, wherein the hypervisor program (AV) is designed to provide mutual freedom from interference for the first virtual machine (PAT1) and the second virtual machine (PAT2). [9] Heterogeneous real-time system (10) according to one of claims 1 to 8, wherein the source code 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 primary ECU (20) are different in that the third real-time application software component (RT-T') is a new implementation of at least a part of the real-time application software component (RT-T) of the primary ECU (20) and / or wherein the compiled code 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 primary ECU (20) were compiled differently. [10] A method for troubleshooting a heterogeneous real-time system (10), wherein - the heterogeneous real-time system (10) comprises the service ECU (30) and a primary control unit or primary ECU (20), - the primary ECU (20) comprises a microcontroller (µC) and basic software (RT-BS) with a real-time operating system (RT-OS) and a real-time application software component (RT-T') for executing a 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 an operating system compatible with a portable operating system interface POSIX, - the service ECU (30) further comprises a non-volatile memory (NVM), a hypervisor program (HV) and backup software (BU), - the backup software (BU) comprises a third basic software (RT-BS') with 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 primary ECU (20) by the service ECU (30) in the event of a failure of the primary 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 by the service ECU (30) whether the primary ECU (20) has a fault, and if it is detected that the primary ECU (20) has a fault, - - triggering or executing the hypervisor program (HV) by the service ECU (30) so that the hypervisor program (HV) creates, in addition to an existing first virtual machine (PAT1), a second virtual machine (PAT2) for executing the third real-time application software component (RT-T') and allocates processing, memory and peripheral resources from the first virtual machine (PAT1) to the second virtual machine (PAT2), and - - Loading the backup software (BU) by the service ECU (30) into the second virtual machine (PAT2) and starting, by the service ECU (30), the execution of the backup software (BU). [11] The method according to claim 10, wherein the hypervisor program (HV) is stored in the non-volatile memory (NVM) of the service ECU (30) and the method comprises the following additional steps: - triggering or executing a bootstrap loader of the service ECU (30) by the service ECU (30) before detecting that the primary ECU (20) has a fault, so that the bootstrap loader loads the hypervisor program (VV) from the non-volatile memory (NVM) into a program memory to boot the hypervisor program (HV) and to create the first virtual machine having the second operating system (s-OS) and the at least one second application software component (S). [12] A computer program which, when executed by a processor of a service ECU (30), causes the service ECU (30) to perform 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 perform the steps of the method of claim 10 or 11.

Images