EP4684312A1

EP4684312A1 - Method for starting a software program of an automotive computing unit, automotive computing unit and computing system for a motor vehicle

Info

Publication number: EP4684312A1
Application number: EP24713421.6A
Authority: EP
Inventors: Mena Nagiub Takwa Hanna
Original assignee: Valeo Schalter und Sensoren GmbH
Current assignee: Valeo Schalter und Sensoren GmbH
Priority date: 2023-03-21
Filing date: 2024-03-18
Publication date: 2026-01-28
Also published as: CN121002497A; DE102023106985A1; WO2024194256A1

Abstract

For starting a software program of an automotive computing unit (3), wherein the software program comprises a minimal viable software component, MVSC, (9) and at least one further software component (10a, 10b), a partitioning software component, PSC, (8) is verified by a validation module (7) of the automotive computing unit (3) and the verified PSC (8) is started by the validation module (7). A verification of the MVSC (9) is initiated by the PSC (8) and the verified MVSC (9) is started by the PSC (8). After the verified MVSC (9) has been started by the PSC (8), a verification of the at least one further software component (10a, 10b) is initiated by the PSC (8) and the verified at least one further software component (10a, 10b) is started by the PSC (8).

Description

Method for starting a software program of an automotive computing unit, automotive computing unit and computing system for a motor vehicle

The present invention is directed to a method for starting a software program of an automotive computing unit, to a corresponding automotive computing unit and to computing system for a motor vehicle comprising such an automotive computing unit.

Booting systems for starting operating systems or other software programs of automotive computing units are known. Such systems may use a hardware security module, HSM, to verify a software image before execution of the first line of code. A goal of the verification is to ensure that the software image to be started is a secure image and is not manipulated or altered by a system hacker or attacker.

On the one hand, a mode of operation of the HSM denoted as foreground secure boot mode may be used, wherein each software component is verified and started individually and the execution is blocked until the verification is complete. When a software component is verified it can be started and then this software component will start the verification of the next software component. The sequence of execution of the software components may be denoted as the chain of trust. The chain of trust starts with an initial trusted component denoted as the core of trust or the root of trust, which is the HSM in this case.

On the other hand, a mode of operation of the HSM denoted as background secure boot mode may be used, wherein the individual software components are already started while the HSM is still verifying it. If the HSM detects that the software component is valid, then the system will continue to execute it. However, if the HSM detects that the software component is invalid, then its execution is stopped immediately.

For computing systems of motor vehicle, such as electronic control units, ECUs, and in particular zone control units, ZCUs, body control units, BCU, domain control units, DCU or gateway units, it is desirable to start a software program of an automotive computing unit, which may be a microcontroller unit, MCU, or a system-on-a-chip, SoC, for example, fast. There may be time constraints that require to start within a predefined time, for example in the order of 100 ms or below. Modern MCUs and HSM components support this from a hardware perspective, however, from a system perspective, in particular when the software is integrated in the hardware, known systems may not be able to match such constraints.

For example, the time required by the HSM to verify a software program is a function of the size of the corresponding image file stored on the read-only memory, ROM. This means that, if the image file has large memory requirements, which may, in particular be the case with modern AUTOSAR (automotive open system architecture) architectures, the HSM may take a rather long time to verify the software program, especially if a complex verification algorithm is used. When using the foreground secure boot mode, this may impact the starting time and said time constraints may be missed. On the other hand, in the background secure boot mode, a long verification time may cause the HSM to detect that the software program is invalid only after it has already been started and potentially has caused the undesired effects.

It is an objective of the present invention to provide an improved concept for starting a software program of an automotive computing unit including a verification of the software program, which reduces the time required until the software program may be started, in particular without reducing the level of security.

This objective is achieved by the respective subject matter of the independent claims. Further implementations and preferred embodiments are subject matter of the dependent claims.

The improved concept is based on the idea to use a validation module of the automotive computing unit as an initial core of trust to verify a partitioning software component and using the verified partitioning software component as a new core of trust for verifying and starting first a minimal viable software component of the software program and then at least one further software component of the software program.

According to an aspect of the invention, a method for starting a software program of an automotive computing unit is provided. Therein, the software program comprises a minimal viable software component, MVSC, and at least one further software component. A partitioning software component, PSC, is verified by a validation module of the automotive computing unit and the verified PSC is started by the validation module. A verification of the MVSC is initiated by the PSC, in particular after the PSC has been verified and started. The verified MVSC is started by the PSC. After the verified MVSC has been started by the PSC, a verification of the at least one further software component is initiated by the PSC and the verified at least one further software component is started by the PSC.

It is noted that the described steps of the method represent a scenario, in which the result of the verification of the PSC as well as the result of the verification of the MVSC and the results of the respective verifications of the at least one further software components are all positive or, in other words, these components are found to be valid as a result of the respective verifications. If one of the respective verifications yields a negative result or, in other words, it is found that the respective component is not valid as a result of the respective verification, the respective invalid component may not be started and the subsequent method steps may for example not be carried out and/or further security measures may be initiated. The security measures may for example include aborting the starting of the software program and/or generating a failure or security message.

In particular, if the result verification of the PSC is negative, the PSC is not started by the validation module and, consequently, the MVSC and the at least one further software component are not verified or started by the PSC. Furthermore, in case the verification of the PSC is positive and the verification of the MVSC is negative, the MVSC is not started by the PSC. In particular, also the at least one further software component may in this case not be verified or started.

In case the verification of the PSC and the verification of the MVSC are both positive but the result of the verification of one of the at least one further software component is negative, the respective invalid one of the at least one further software component is not started. Depending on the actual implementation, if the at least one further software component comprises more than one further software component, the PSC may proceed with the verification and, provided a positive result of the verification, with starting of the remaining further software components. In alternative implementations, the starting of the software program is aborted and none of the remaining further software components is verified or started.

The at least one further software component may consist of a single further software component and the verification of the single further software component is carried out by the PSC after the verified MVSC has been started. Alternatively, the at least one further software component may comprise two or more further software components. The two or more further software components may be verified and/or started by the PSC in a sequential manner one after the other after the verified MVSC has been started. Alternatively, depending on the implementation of the PSC, it may also be possible to start the verification of the two or more further software components or a fraction of them in parallel or to carry out the verification in a staggered manner such that the individual verification processes may partially overlap. In any case, the verification of any of the two or more further software components begins only after the verified MVSC has been started.

The automotive computing unit is a computing unit, which is suitable for being used in a motor vehicle, for example in an electronic control unit, ECU, in particular a zone control unit, ZCU, a body control unit, BCU or a domain control unit, DCU, or a gateway unit.

A computing unit may in particular be understood as a data processing device, which comprises processing circuitry. The computing unit can therefore in particular process data to perform computing operations. This may also include operations to perform indexed accesses to a data structure, for example a look-up table, LUT.

In particular, the computing unit may include one or more computers, one or more microcontrollers, and/or one or more integrated circuits, for example, one or more application-specific integrated circuits, ASIC, one or more field-programmable gate arrays, FPGA, and/or one or more systems on a chip, SoC. The computing unit may also include one or more processors, for example one or more microprocessors, one or more central processing units, CPU, one or more graphics processing units, GPU, and/or one or more signal processors, in particular one or more digital signal processors, DSP. The computing unit may also include a physical or a virtual cluster of computers or other of said units.

In various embodiments, the computing unit includes one or more hardware and/or software interfaces and/or one or more memory units.

A memory unit may be implemented as a volatile data memory, for example a dynamic random access memory, DRAM, or a static random access memory, SRAM, or as a nonvolatile data memory, for example a read-only memory, ROM, a programmable read-only memory, PROM, an erasable programmable read-only memory, EPROM, an electrically erasable programmable read-only memory, EEPROM, a flash memory or flash EEPROM, a ferroelectric random access memory, FRAM, a magnetoresistive random access memory, MRAM, or a phase-change random access memory, PCRAM. The MVSC is for example adapted to carry out one or more functions of a highest priority, also denoted as minimal functions. These minimal functions can be considered to be encapsulated into the MVSC as a single standalone software. It depends on the actual implementation how the individual functions of the whole software program are distributed between the MVSC and the at least one further software component. The at least one further software component implements respective functions that are of a lower priority compared the highest priority of the minimal functions.

The PSC may be understood as a partitioning software component in the sense that it is adapted to partition the available resources, such as physical or virtual processors and/or physical or virtual memory units, of the automotive computing unit and to assign them to the MVSC on the one hand and to the at least one further software component on the other hand.

The validation module can for example be considered as an initial core of trust. The initial core of trust can be a hardware and/or software component, preferably it is implemented as a hardware core of trust. The initial core of trust is for example inherently trusted and is for example secure by design, such as a hardware security module, HSM. However, the initial core of trust can also be a hardware and/or software component, which already has been verified to be secure prior to carrying out the method according to the invention, for example by an HSM.

According to the inventive method, the PSC is first verified and started by the validation module and therefore can be considered as a new core of trust for the remaining steps.

That the PSC initiates the respective verification of the MVSC and the at least one further software component can be understood such that, for example, the PSC itself carries out the respective verification or the PSC calls another module of the automotive computing unit, for example the validation module, to carry out the verification.

The software program may be an operating system software. This is, however, not mandatory. In particular, the software program may also be an application software program.

By means of the method according to the invention, the MVSC as well as the at least one further software component are all started only after successful verification of the respective component. Consequently, the security when starting the software program can be kept very high, for example as in the case of a forward secure boot operation. In particular, the PSC acts as a new core of trust, which is able to initiate or carry out the verifications of the different components in a predefined order, such that the MVSC is verified first and can therefore be started before the at least one further software component has been verified or even started.

Therefore, the time until the MVSC is started and, consequently, the minimal functions can be actually carried out is reduced due to the partitioned treatment of the MVSC verification and the verification of the at least one further software component.

According to several implementations of the method, the validation module is implemented as an HSM of the automotive computing unit.

In this way, a highly reliable verification of the PSC, and in some implementations of the MVSC and/or the at least one further software component upon initiation of the PSC, may be realized by using powerful known verification algorithms and exploiting that the HSM is a hardware component, which is secure by design.

According to several implementations, the verification of the MVSC is initiated by the PSC is carried out by the validation module, in particular the HSM in respective implementations.

For example, the PSC may initiate the verification of the MVSC by sending a respective command for starting the verification to the validation module. The validation module then carries out the verification in response to that command.

Consequently, the respective verification algorithm used for verifying the MVSC does not have to be implemented in the PSC itself. This reduces the size, in particular the memory requirements, of the PSC and reduces the time for verifying the PSC by the validation module and consequently the time until the MVSC can be verified and started. Moreover, the validation module must nevertheless be able to verify the PSC by using corresponding verification algorithms. Thus, the verification algorithms do not have to be implemented twice.

According to several implementations, the verification of the at least one further software component is initiated by the PSC is carried out by the validation module, in particular the HSM in respective implementations. Consequently, the respective verification algorithm used for verifying the at least one further software component does not have to be implemented in the PSC itself. This reduces the size, in particular the memory requirements, of the PSC and reduces the time for verifying the PSC by the validation module and consequently the time until the MVSC can be verified and started.

According to several implementations, an interrupt is generated by the verified MVSC, when the verification of the MVSC is completed, and the interrupt is transmitted by the MVSC to the PSC. The verified MVSC is started by the PSC in response to the transmitted interrupt.

In several implementations, the PSC is a bootloader software module of the automotive computing unit.

This has for example the advantage that the automotive computing unit can use the bootloader software module as the new core of trust next to other tasks carried out by the bootloader software module, which are not part of the method according to the invention. The bootloader software module is able to initiate verifications and start components of the software program in a temporarily defined manner as described for the method above. Consequently, the bootloader software module is inherently able to act as a partitioning software component.

According to several implementations, the PSC is the bootloader software module and the interrupt is generated as a timer interrupt or as a software interrupt.

According to at least one further implementation, the PSC is a hypervisor software module.

In this case, the hypervisor software module may set up respective software virtual machines and the verification and start of the MVSC and the at least one further software component may be done based on the respective software virtual machines.

This has for example the advantage that the automotive computing unit can use the hypervisor software module as the new core of trust next to other tasks carried out by the hypervisor software module, which are not part of the method according to the invention. By design, the hypervisor software module is inherently able to act as a partitioning software component. Using the hypervisor software module as the PSC also has the advantage that it can optimize the utilization of the hardware resources and processor cores of the automotive control unit.

According to several implementations, the PSC is the hypervisor software module and the interrupt is generated as a hypervisor software interrupt.

According to several implementations, the at least one further software component comprises a first further software component and a second further software component.

According to several implementations, a verification of the first further software component and a verification of the second further software component are initiated in parallel by the PSC, after the verified MVSC has been started by the PSC.

In other words, for initiating the verification of the second further software component, the PSC does not wait until the verification of the first further software component is completed or vice versa, respectively. Consequently, the time until the first and the second further software component can be started is further reduced.

For example, the PSC may initiate the verification of all further software components of the at least one further software component in parallel.

According to several implementations, a verification of the first further software component is initiated by the PSC after the verified MVSC has been started by the PSC. When the verification of the first further software component is completed, the verified first further software component is started by the PSC. After the verified first further software component has been started by the PSC, a verification of the second further software component is initiated by the PSC.

In particular, when the verification of the second further software component is completed, the verified second further software component is started by the PSC.

For example, a command, for example a further interrupt, may be generated by the first further software component when it has been started and transmitted to the PSC and the PSC initiates the verification of the second further software component in response to that command or further interrupt. In this way, it may be achieved, that the second further software component is verified only if the verification of the first further software component is successful. This can be extended to all further software components of the at least one further software component such that one after the other is verified only if the preceding further software component has been verified successfully. Furthermore, in this way also PSC may be used that are not able to initiate or handle more than one verification at a time.

According to several implementations, the verification of the MVSC and/or the verification of the at least one further software component, for example the first and/or second further software component, is carried out using a cipher-based message authentication code, CMAC, algorithm, for example by the validation module, in particular the HSM.

In this way, a high level of security and reliability of the verification may be achieved.

For use cases or use situations which may arise in the method and which are not explicitly described here, it may be provided that, in accordance with the method, an error message and/or a prompt for user feedback is output and/or a default setting and/or a predetermined initial state is set.

According to a further aspect of the invention, an automotive computing unit is provided. The automotive computing unit comprises at least one memory device, which stores a software program, wherein the software program comprises a minimal viable software component, MVSC, and at least one further software component and wherein the at least one memory device stores a partitioning software component, PSC. The automotive computing unit comprises a validation module, which is configured to verify the PSC and to start the verified PSC. The PSC is adapted to initiate a verification of the MVSC and to start the verified MVSC. The PSC is adapted to initiate a verification of the at least one further software component after the verified MVSC has been started by the PSC and to start the verified at least one further software component.

According to several implementations, the automotive computing unit is implemented as a microcontroller, also denoted as microcontroller computing unit, MCU.

According to several implementations of the automotive computing unit, the validation module is a hardware security module, HSM. According to several implementations, the at least one memory device comprises a nonvolatile memory device, in particular a read-only memory, ROM, which stores the software program. The at least one memory device comprises a further memory device, in particular a volatile memory device, for example a flash memory. The PSC is adapted to load the verified MVSC from the non-volatile memory device into the further memory device for starting the verified MVSC.

Further implementations of the automotive computing unit according to the invention follow directly from the various embodiments of the method according to the invention and vice versa. In particular, individual features and corresponding explanations as well as advantages relating to the various implementations of the method according to the invention can be transferred analogously to corresponding implementations of the automotive computing unit according to the invention. In particular, the automotive computing unit according to the invention is designed or programmed to carry out the method according to the invention. In particular, the automotive computing unit according to the invention carries out the method according to the invention.

According to a further aspect of the invention, a computing system for a motor vehicle is provided, wherein the computing system comprises an automotive computing unit according to the invention. The computing system is an ECU or a BCU or a ZCU or a DCU or a gateway unit.

Further features of the invention are apparent from the claims, the figures and the figure description. The features and combinations of features mentioned above in the description as well as the features and combinations of features mentioned below in the description of figures and/or shown in the figures may be comprised by the invention not only in the respective combination stated, but also in other combinations. In particular, embodiments and combinations of features, which do not have all the features of an originally formulated claim, may also be comprised by the invention. Moreover, embodiments and combinations of features which go beyond or deviate from the combinations of features set forth in the recitations of the claims may be comprised by the invention.

In the following, the invention will be explained in detail with reference to specific exemplary implementations and respective schematic drawings. In the drawings, identical or functionally identical elements may be denoted by the same reference signs. The description of identical or functionally identical elements is not necessarily repeated with respect to different figures. In the figures,

Fig. 1 shows schematically a motor vehicle with an exemplary implementation of a computing system for a motor vehicle according to the invention;

Fig. 2 shows schematically a flow diagram of an exemplary implementation of a method for starting a software program of an automotive computing unit according to the invention; and

Fig. 3 shows schematically a flow diagram for a further exemplary implementation of a method for starting a software program of an automotive computing unit.

Fig. 1 shows schematically a motor vehicle 1 with an exemplary implementation of a computing system 2 according to the invention. The computing system 2 may for example be implemented as an ECU, a BCU, a ZCU, a DCU or a gateway unit. The computing system 2 may for example be adapted for controlling one or more sensors 5 of the vehicle 1 and/or further components 6 of the vehicle 1 .

The computing system 2 comprises an exemplary implementation of an automotive computing unit 3 according to the invention. The automotive computing unit 3 may for example be implemented as an MCU or an SoC. The computing system 2 may optionally comprise further electronic devices 4, such as memory devices, interfaces, peripherals, further MCUs or SoCs etc.

An automotive computing unit 3 according to the invention, for example an automotive computing unit 3 as used in a computing system 2 as shown in Fig. 1 , comprises at least one memory device (not shown), which stores a software program. In particular, the software program may be started by using a method for starting a software program according to the invention.

A schematic flow diagram of an exemplary implementation of such a method is shown in Fig. 2.

The software program comprises a minimal viable software component, MVSC, 9 and at least one further software component. In the non-limiting example of Fig. 2, the at least one further software component comprises a first further software component 10a and a second further software component 10b. The at least one memory device stores a partitioning software component, PSC, 8. Furthermore, the automotive computing unit 3 comprises a validation module 7, for example a hardware security module, HSM.

In a step 200 of the method, the validation module 7 is started or woke up and in step 210 the start of the validation module 7 is completed and the validation module 7 is ready. In step 220 the validation module 7 verifies the PSC 8 and the verified PSC 8 is started by the validation module 7 in step 230. In case a result of the verification of the PSC 8 in step 220 is negative, the starting procedure may be aborted, for example. Otherwise, the PSC 8 initiates a verification of the MVSC 9 in step 240.

In case the verification of the MVSC 9 is successful, the PSC 8 starts the MVSC 9 in step 250. Otherwise, the starting procedure may be aborted, for example, and, in particular, neither the MVSC 9 nor the at least one further software component 10a, 10b are started.

In case the MVSC 9 has been successfully verified and started by the PSC 8, the verification of the at least one further software component 10a, 10b is initiated by the PSC 8 and the verified at least one further software component 10a, 10b is started by the PSC 8. In the example of Fig. 2, the verification of the first further software component 10a is initiated by the PSC 8 in step 260 and, in case of a successful verification of the first further software component 10a, it is started in step 270. The verification of the second further software component 10b is initiated by the PSC 8 in step 280 and, in case of a successful verification of the second further software component 10b, it is started in step 290.

The steps 260 and 280 may be carried out in parallel or partly in parallel. In other implementations, step 280 is carried out only after the first further software component 10a has been successfully verified in step 260 and started in step 270.

Fig. 3 shows a schematic flow diagram of a further exemplary implementation of a method for starting a software program according to the invention. In this implementation, the validation module 7 is for example implemented as a bootloader software module.

In this case an interrupt vector table 11 of the processor, in particular CPU, of the automotive computing unit 3 may be configured such that the MVSC 9 and the at least one further software component 10a, 10b can generate respective interrupts 11a, 11 b, which can be transmitted to the PSC 8. This can for example be done using software interrupts or using a timer with timer interrupts. In this way, the PSC 8 can be woke up when the MVSC 9 or the at least one further software component 10a, 10b, respectively, have been successfully verified and are ready to be started so that the PSC 8 can start their execution. The PSC 8 is therefore set as Interrupt Service Routing, ISR, and the interrupts are assigned to the PSC 8.

In step 300, the validation module 7 is started or woke up and in step 310 the start of the validation module 7 is completed and the validation module 7 is ready. In step 320 the validation module 7 verifies the PSC 8 and the verified PSC 8 is started by the validation module 7 in step 330. In case a result of the verification of the PSC 8 in step 320 is negative, the starting procedure may be aborted, for example. Otherwise, the PSC 8 initiates a verification of the MVSC 9 in step 340. In case the verification of the MVSC 9 is successful, the PSC 8 starts the MVSC 9 in step 350.

When the MVSC 9 has been successfully verified and is thus ready to be started, it may trigger an interrupt request 11 b to the PSC 8 and/or it may trigger a further interrupt request 11 a to the PSC 8 when the MVSC 9 has been started successfully in step 350. The PSC 8 can then handle interrupt request by requesting the validation module 7 to verify the first further software component 10a in step 360.

When the first further software component 10a has been verified, it may generate an interrupt request 1 1 b, which may be handled by the PSC 8 by loading the verified first further software component 10a and starting its execution in step 370. When the first further software component 10a has been started and is ready, it may generate a further interrupt request 11 a and send it to the PSC 8, which handles it by requesting the validation module 7 to verify the second further software component 10b in step 380. When the second further software component 10b has been verified, it may generate an interrupt request 11 b, which may be handled by the PSC 8 by loading the verified second further software component 10b and starting its execution in step 390.

In case the at least one further software component 10a, 10b comprises more than two further software components, the steps described with respect to the first further software component 10a and the second further software component 10b may be repeated until all further software components of the at least one further software component 10a, 10b have been verified and started.

In further implementations, a hypervisor software module can be used as the PSC 8. In this case, based on the implementation of the hypervisor software module and the processor of the automotive computing unit 3, the MVSC 9 and the at least one further software component 10a, 10b become software virtual machines.

The described steps remain as for the bootloader software module as the PSC 8. In particular, the validation module 7 is started and verifies the hypervisor software module, and the hypervisor software module is started after verification and becomes the new core of trust. The hypervisor software module verifies the MVSC 9 virtual machine, for example using the validation module 7 and then starts the MVSC 9 virtual machine. The hypervisor software module requests the validation module 7 to verify the software virtual machine according to the first further software component 10a and after successful verification loads the verified software virtual machine according to the first further software component 10a and starts its execution.

When the MVSC 9 virtual machine meets its predefined time deadline for secure booting and the system enters a normal operation mode, then the MVSC 9 virtual machine can for example trigger the hypervisor software module to start the software virtual machine according to the second further software component 10b on the same core as the MVSC 9 virtual machine in order to optimize the utilization of the shared resources and cores. The respective steps are repeated until virtual machines according to all further software components of the at least one further software component 10a, 10b have been verified and started.

As described, in particular with respect to the figures, the invention provides an improved concept for starting a software program of an automotive computing unit including a verification of the software program, which reduces the time required until the software program may be started, in particular without reducing the level of security.

By analyzing the secure boot requirements, it is desirable to ensure that after a predefined time, the automotive computing unit is able to carry out minimal functions until other components are loaded and ready to run. These minimal functions can be encapsulated into a standalone software component denoted as MVSC, which is started first. Thereby, the tradeoff between meeting the time constraint for the secure booting and utilizing the system resources may be handled to keep the cores well balanced. On the other hand, starting untrusted software components as for background secure booting methods may be avoided.

Claims

1 . Method for starting a software program of an automotive computing unit (3), wherein the software program comprises a minimal viable software component, MVSC, (9) and at least one further software component (10a, 10b); a partitioning software component, PSC, (8) is verified by a validation module (7) of the automotive computing unit (3) and the verified PSC (8) is started by the validation module (7); a verification of the MVSC (9) is initiated by the PSC (8) and the verified MVSC (9) is started by the PSC (8); and after the verified MVSC (9) has been started by the PSC (8), a verification of the at least one further software component (10a, 10b) is initiated by the PSC (8) and the verified at least one further software component (10a, 10b) is started by the PSC (8).

2. Method according to claim 1 , wherein the validation module (7) is a hardware security module, HSM, of the automotive computing unit (3).

3. Method according to claim 2, wherein the verification of the MVSC (9) initiated by the PSC (8) is carried out by the validation module (7); and/or the verification of the at least one further software component (10a, 10b) initiated by the PSC (8) is carried out by the validation module (7).

4. Method according to one of the preceding claims, wherein when the verification of the MVSC (9) is completed, an interrupt (11 a, 11 b) is generated by the verified MVSC (9) and transmitted to the PSC (8); and the verified MVSC (9) is started by the PSC (8) in response to the transmitted interrupt (11 a, 11 b).

5. Method according to claim 4, wherein the PSC (8) is a bootloader software module; and the interrupt (11a, 11b) is generated as a timer interrupt or as a software interrupt.

6. Method according to one of the claims 1 to 4, wherein the PSC (8) is a hypervisor software module; and the interrupt is generated as a hypervisor software interrupt.

7. Method according to one of the preceding claims, wherein the at least one further software component (10a, 10b) comprises a first further software component (10a) and a second further software component (10b); and after the verified MVSC (9) has been started by the PSC (8), a verification of the first further software component (10a) and a verification of the second further software component (10b) are initiated in parallel by the PSC (8).

8. Method according to one of claims 1 to 6, wherein the at least one further software component (10a, 10b) comprises a first further software component (10a) and a second further software component (10b); after the verified MVSC (9) has been started by the PSC (8), a verification of the first further software component (10a) is initiated by the PSC (8); when the verification of the first further software component (10a) is completed, the verified first further software component (10a) is started by the PSC (8); after the verified first further software component (10a) has been started by the PSC (8), a verification of the second further software component (10b) is initiated by the PSC (8).

9. Method according to one of the preceding claims, wherein the verification of the MVSC (9) and/or the verification of the at least one further software component (10a, 10b) is carried out using a cipher-based message authentication code, CMAC, algorithm.

10. Automotive computing unit (3) wherein the automotive computing unit (3) comprises at least one memory device, which stores a software program, wherein the software program comprises a minimal viable software component, MVSC, (9) and at least one further software component (10a, 10b) and wherein the at least one memory device stores a partitioning software component, PSC, (8); the automotive computing unit (3) comprises a validation module (7), which is configured to verify the PSC (8) and start the verified PSC (8); the PSC (8) is adapted to initiate a verification of the MVSC (9) and to start the verified MVSC (9); and the PSC (8) is adapted to initiate a verification of the at least one further software component (10a, 10b) after the verified MVSC (9) has been started by the PSC (8) and to start the verified at least one further software component (10a, 10b).

11 . Automotive computing unit (3) according to claim 10, wherein the automotive computing unit (3) is a microcontroller.

12. Automotive computing unit (3) according to one of claims 10 or 11 , wherein the validation module (7) is a hardware security module, HSM.

13. Automotive computing unit (3) according to one of claims 10 to 12, wherein the at least one memory device comprises a non-volatile memory device, which stores the software program, and a further memory device; the PSC (8) is adapted to load the verified MVSC (9) from the non-volatile memory device into the further memory device for starting the verified MVSC (9).

14. Computing system (2) for a motor vehicle (1), wherein the computing system (2) is an electronic control unit or a body control unit or a zone control unit or a domain control unit or a gateway unit and the computing system comprises an automotive computing unit (3) according to one of claims 10 to 13.