VEHICLE CONTROL UNIT WITH SYNCHRONOUS DRIVER

Description

Technical area

[0001] The invention relates to a vehicle control unit with a processor for executing a synchronous driver for storing vehicle status data in a flash memory. In particular, the invention relates to a dedicated flash driver for executing real-time flash accesses. State of the art

[0002] The AUTOSAR (AUTomotive Open System Architecture) architecture is a standard for the development of software components for the automotive sector, which emerged from the merger of various automobile manufacturers. AUTOSAR has the following characteristics: a) Implementation and standardization of basic functions that are modular and interchangeable with modules from third-party manufacturers. b) Scalability with regard to different vehicle types, i.e., implementation of scaled solutions that can benefit from well-tested and high-quality standard modules. c) Possibilities for redundant design, especially for safety-critical areas. d) Embedding of modules from other manufacturers. e) Maintainability throughout the entire product lifecycle. f) Software updates and upgrades throughout the vehicle's life.

[0003] However, it has been shown that persistent storage of information in the AUTOSAR architecture cannot be achieved in real time. This is because the implementation there is based on a FIFO (First-In First-Out) principle, in which all software components of the system write to a queue. This queue is then processed sequentially (asynchronously), so no exact processing time can be determined. The worst-case scenario yields values ​​that are outside the requirements for many applications. For example, one requirement is that a crash event be saved within 10ms.

[0004] The document AUTOSAR: "Requirements on Memory Services", November 30, 2020, XP55901834, describes basic software modules of the AUTOSAR service layer.

[0005] The AUTOSAR document "Requirements on Flash Driver", November 30, 2020, XP55901837, describes requirements for the AUTOSAR flash driver module. The AUTOSAR document "Specification of Flash Driver", November 30, 2020 (2020-11-30), XP55901841, describes the properties of a flash driver with respect to AUTOSAR.

[0006] The document AUTOSAR: "Layered Software Architecture", November 30, 2020, XP55901843, describes the software architecture of AUTOSAR, in particular the approach of the hierarchical structure of the AUTOSAR software.

[0007] The document AUTOSAR: "Specification of Flash Driver", November 30, 2020, XP055901841, available at: https: / / www.autosar.org / fileadmin / user_upload / standards / classic / 20-11 / AUTOSAR_SWS_FlashDriver.pdf, describes in detail the requirements for the flash driver and the functionalities it supports. Description of the invention

[0008] It is an object of the invention to provide a vehicle control device in which persistent storage of information in real time can be ensured for certain critical applications, such as the recording of a vehicle crash.

[0009] The invention is based on the idea of ​​implementing an additional, non-AUTOSAR-compliant driver with a synchronous interface. In the event of a write command, the AUTOSAR driver's execution is stopped, the flash hardware context is saved, and the new write command is executed directly. The previous state of the flash hardware is then restored, and the AUTOSAR driver's continuation is permitted again.

[0010] This solution allows real-time requirements to be implemented at a unit-cost-neutral level. No additional external hardware components are required.

[0011] A similar implementation is not yet known. An alternative solution would be to connect an additional external memory (e.g., via SPI), but this would result in increased hardware costs.

[0012] According to a first aspect of the invention, the object is achieved by a vehicle control unit having a processor and a flash memory, wherein the processor is configured to execute a plurality of processes, each process being assigned to a corresponding vehicle control component; wherein the processor is configured to execute an asynchronous driver configured to write vehicle state data of the respective process in a corresponding process context to the flash memory in response to a write request from a respective process of the plurality of processes, wherein the writing to the flash memory is performed by the asynchronous driver according to a first-in-first-out (FIFO) characteristic;wherein the processor is further configured to execute a synchronous driver configured, in response to a write request from a predetermined process of the plurality of processes, to stop execution of the asynchronous driver on the processor and to write vehicle state data of the predetermined process to the flash memory, wherein the stopping of the asynchronous driver occurs while saving the corresponding process context under which the asynchronous driver writes to the flash memory at the time of the stopping, wherein the synchronous driver is further configured, after writing the vehicle state data of the predetermined process to the flash memory, to reactivate the asynchronous driver while restoring the saved process context.

[0013] This provides the technical advantage that the synchronous driver can ensure that vehicle status data from the predetermined process is written to the flash memory in real time. The vehicle control unit can thus implement the real-time requirement at a unit-cost-neutral level, without the need for additional external hardware components.

[0014] According to an exemplary embodiment of the vehicle control unit, the predetermined process of the plurality of processes is a process that is designed to log exceptional conditions of the vehicle, in particular in the event of a vehicle crash or the occurrence of undefined conditions in the vehicle control unit.

[0015] This provides the technical advantage that in exceptional situations, such as an accident or vehicle crash, important information about the vehicle status can be logged very quickly in the flash memory without having to wait for the data storage to be processed by other processes relating to normal vehicle situations.

[0016] According to an exemplary embodiment of the vehicle control unit, the flash memory is a vehicle error memory configured to log data relating to an error state of the respective vehicle control components.

[0017] This provides the technical advantage that, by reading the vehicle error memory, maintenance personnel are efficiently informed about error situations that have occurred during the vehicle's operating life and can use this information to decide which components in the vehicle are faulty and should be checked or replaced.

[0018] According to an exemplary embodiment of the vehicle control unit, the synchronous driver is configured to write the vehicle state data of the predetermined process into the flash memory in real time.

[0019] This provides the technical advantage of enabling the persistent storage of important vehicle states in real time. The distinction between important and less important states can be predetermined by predetermining one or more of the processes running on the processor, e.g., the process related to the crash module or the exception module. Only these predetermined processes run via the synchronous driver, and their information can be recorded in real time.

[0020] According to an exemplary embodiment of the vehicle control unit, the asynchronous driver is designed to process the write requests of the respective processes of the plurality of processes sequentially according to the FIFO characteristic without ensuring a predetermined processing time.

[0021] This provides the technical advantage that all other processes that do not correspond to the predetermined process(es) can also record their vehicle status data in the flash memory, albeit not in real time. This allows the user to decide which processes they consider critical and route them via the synchronous driver, while all other processes are routed via the asynchronous driver. However, the user should be aware that not all processes can run via the synchronous driver. The number of predetermined processes that run via the synchronous driver should be significantly smaller than the number of (non-predetermined) processes that continue to run via the asynchronous driver.

[0022] According to an exemplary embodiment of the vehicle control unit, the saving and restoring of the corresponding process context depends on a hardware design of the processor, in particular a design of specific hardware registers of the processor.

[0023] This achieves the technical advantage that, by saving and restoring the corresponding process context, writing information via two drivers that alternately access the flash memory does not result in undefined states in the flash memory. Writing to the flash memory by the asynchronous driver can thus be efficiently interrupted and resumed in the correct process and memory context after the synchronous driver has completed writing. Writing to the flash memory requires specific processor hardware registers, which are restored to their original state after writing.

[0024] According to an exemplary embodiment of the vehicle control unit, the predetermined process of the plurality of processes has a dedicated interface to the synchronous driver to transmit the write request of the predetermined process to the synchronous driver.

[0025] This provides the technical advantage that the vehicle status data to be written to the flash memory can be efficiently transferred via the dedicated interface to the synchronous driver. The functionality of the asynchronous driver can be retained, so no changes to this software module are required.

[0026] The synchronous driver and the asynchronous driver can be configured to run on the processor according to an Automotive Open System Architecture, AUTOSAR, architecture.

[0027] This provides the technical advantage that the real-time requirements enabled by the synchronous driver can be easily implemented in the AUTOSAR architecture without the need for additional hardware.

[0028] The synchronous driver can be implemented in a Complex Device Driver (CDD) software component according to the AUTOSAR architecture on the processor and have access to hardware registers of the processor.

[0029] This provides the technical advantage that the synchronous driver can be programmed to suit the user's specific needs and can be connected directly to the flash memory via the processor's hardware registers.

[0030] The asynchronous driver can be implemented in a Microcontroller Abstraction Layer, MCAL, software component according to the AUTOSAR architecture on the processor.

[0031] This achieves the technical advantage that the asynchronous driver and the synchronous driver can work together efficiently and an interface for stopping or restarting the asynchronous driver by the synchronous driver can be easily implemented via existing interfaces between the MCAL component and the CDD component of the AUTOSAR architecture.

[0032] According to an exemplary embodiment of the vehicle control unit, the flash memory is designed to persistently store the vehicle state data of the individual processes.

[0033] This provides the technical advantage that the vehicle status data is stored in the flash memory so that, for example, maintenance personnel can still access it at the next workshop appointment.

[0034] According to an exemplary embodiment of the vehicle control device, the synchronous driver is configured to execute the writing of the vehicle state data of the predetermined process into the flash memory within a time interval of at most 10 ms.

[0035] This provides the technical advantage that real-time requirements, such as the 10ms mentioned above, can be met by implementing the synchronous driver.

[0036] According to an exemplary embodiment of the vehicle control unit, the predetermined process is associated with a vehicle crash module, wherein the predetermined process is configured to transmit the write request to the synchronous driver in response to a crash event, wherein the write request includes data of the crash event, and the synchronous driver is configured to log the data of the crash event in the flash memory.

[0037] This provides the technical advantage that the synchronous driver makes it possible to detect a crash and record corresponding data about the crash event, which would not be possible with an asynchronous driver due to the sequential recording of events.

[0038] According to a second aspect of the invention, the object is achieved by a method for controlling write requests from a plurality of processes that are executed on a processor of a vehicle control unit, wherein each process is assigned to a corresponding vehicle control component, and wherein the vehicle control unit has a flash memory for storing vehicle state data of the individual processes, wherein the method comprises the following steps: in response to a write request from a respective process of the plurality of processes to an asynchronous driver executed on the processor, writing vehicle state data of the respective process in a corresponding process context to the flash memory by the asynchronous driver, wherein writing to the flash memory by the asynchronous driver occurs according to a first-in-first-out (FIFO) characteristic;In response to a write request from a predetermined process of the plurality of processes to a synchronous driver executing on the processor, the synchronous driver suspends execution of the asynchronous driver, and the synchronous driver writes vehicle state data of the predetermined process to the flash memory, wherein the asynchronous driver suspends execution while saving the corresponding process context under which the asynchronous driver is writing to the flash memory at the time of the suspension; and after the vehicle state data of the predetermined process is written to the flash memory, the synchronous driver reactivates the asynchronous driver while restoring the saved process context.

[0039] This achieves the technical advantage that the method can ensure that the synchronous driver writes vehicle state data from the predetermined process to the flash memory in real time. The method can thus be executed on a vehicle control unit (ECU), which can implement the real-time requirement at a unit-cost-neutral level without the need for additional external hardware components.

[0040] According to a third aspect of the invention, the object is achieved by a computer program having a program code for executing the method according to the second aspect on a vehicle control unit according to the first aspect.

[0041] This provides the technical advantage that the computer program can be easily executed on a vehicle control unit, which can implement the real-time requirement at no cost to the unit and without the need for additional external hardware components. Short character description

[0042] The invention is described in more detail below using exemplary embodiments and the figures. The figures show: Fig. 1 shows a schematic representation of a vehicle control unit 100 according to the disclosure; Fig. 2 shows a schematic representation of the AUTOSAR architecture in which an asynchronous driver 120 and a synchronous driver 130 are integrated according to an embodiment; and Fig. 3 shows a schematic representation of a method for controlling write requests from a plurality of processes to a flash memory according to the disclosure.

[0043] In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense. Further, it is to be understood that the features of the various embodiments described herein may be combined with one another unless specifically indicated otherwise.

[0044] The aspects and embodiments are described with reference to the drawings, where like reference numerals generally refer to like elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects of the invention. However, it may be apparent to one skilled in the art that one or more aspects or embodiments may be practiced with a lesser level of specific detail. In other instances, well-known structures and elements are shown in schematic form to facilitate describing one or more aspects or embodiments. It is understood that other embodiments may be utilized and structural or logical changes may be made without departing from the concept of the present invention.

[0045] The following description refers to asynchronous and synchronous drivers, processes, and process contexts.

[0046] A synchronous driver is a driver that ensures synchronous, i.e., concurrent, execution. A synchronous driver, as used in this disclosure, ensures simultaneous execution of a memory access in response to a write request. Thus, the memory access occurs at the same time as the write request arrives at the synchronous driver. However, delays in the execution of the driver and in the execution of the memory access must be taken into account, so a certain delay must be included here.

[0047] An asynchronous driver is a driver that does not guarantee synchronous, i.e., concurrent, execution. An asynchronous driver, as used in this disclosure, ensures sequential execution of a memory access operation depending on the presence of other memory requests or write requests from other processes. This means that a certain amount of time passes before the memory access operation can be performed. This time depends on the overall system and cannot be defined in general terms. For example, the write requests of all processes are processed according to a FIFO characteristic, i.e., the first-arrived write requests are processed first, and the last-arrived write requests are processed last. The FIFO characteristic can be implemented using a queue.

[0048] A process, as described in this disclosure, is a computer program at runtime. More specifically, a process is the concrete instantiation of a program for its execution within a computer system, supplemented by further information and resource allocations of the operating system for this execution.

[0049] The processes are managed by the operating system's process scheduler. This can either let a process continue computing until it terminates or blocks, or it can interrupt the currently running process after a short period of time, allowing the scheduler to switch between different active processes, creating the illusion of concurrency even if no more than one process is running at any given time.

[0050] The process context refers to all information relevant to the execution and management of processes. To manage processes, an operating system must store information about the process. The user context refers to the process data in the assigned address space. The hardware context refers to the contents of the CPU registers at the time the process is executing. This information must be saved if one process is interrupted by another during multitasking. The system context refers to information that the operating system stores about the process from its perspective, such as the process number, the files opened by the process, information about parent or child processes, priorities, time spent, etc.

[0051] Flash memories, as described in this disclosure, are digital memory devices for non-volatile storage without maintenance power consumption.

[0052] Fig. 1 shows a schematic representation of a vehicle control unit 100 according to the disclosure. The vehicle control unit 100 includes a processor 101 or microcontroller and a flash memory 140.

[0053] The processor 101 is configured to execute a plurality of processes 111, 112, 113, 114, each process being associated with a corresponding vehicle control component.

[0054] The processor 101 is further configured to execute an asynchronous driver 120, which is configured to write 121 vehicle state data of the respective process in a corresponding process context to the flash memory 140 in response to a write request 115 from a respective process of the plurality of processes 111, 112, 113, 114. Writing 121 to the flash memory 140 is performed by the asynchronous driver 120 according to a first-in-first-out (FIFO) characteristic, i.e., writing 121 occurs sequentially. The write requests are processed in the order in which they arrive.

[0055] The processor 101 is further configured to execute a synchronous driver 130, which is configured, in response to a write request 116 from a predetermined process 114 of the plurality of processes 111, 112, 113, 114, to stop 131 the execution of the asynchronous driver 120 on the processor 101 and to write 132 vehicle state data of the predetermined process 114 into the flash memory 140. The stopping 131 of the asynchronous driver 120 is performed while securing the corresponding process context under which the asynchronous driver 120 writes 121 into the flash memory 140 at the time of the stopping 131.

[0056] The synchronous driver 130 is further configured to reactivate 131 the asynchronous driver 120 after writing 132 the vehicle state data of the predetermined process 114 into the flash memory 140, restoring the saved process context.

[0057] The predetermined process 114 of the plurality of processes 111, 112, 113, 114 may be a process configured to log exceptional conditions of the vehicle, for example, in the event of a vehicle crash or the occurrence of undefined conditions in the vehicle control unit 100.

[0058] The flash memory 140 may be a vehicle fault memory configured to log data relating to a fault condition of the respective vehicle control components.

[0059] The synchronous driver 130 may be configured to write 132 the vehicle state data of the predetermined process 114 into the flash memory 140 in real time.

[0060] The asynchronous driver 120 may be configured to process the write requests 115 of the respective processes of the plurality of processes 111, 112, 113, 114 sequentially according to the FIFO characteristic, without ensuring a predetermined processing time.

[0061] Saving and restoring the corresponding process context may depend on a hardware design of the processor 101, for example, a design of specific hardware registers of the processor 101.

[0062] The predetermined process 114 of the plurality of processes 111, 112, 113, 114 may have a dedicated interface to the synchronous driver 130 to transmit the write request 116 of the predetermined process 114 to the synchronous driver 130.

[0063] The synchronous driver 130 and the asynchronous driver 120 may be implemented according to an Automotive Open System Architecture, AUTOSAR, architecture 200, as described in more detail below. Figure 2 described, run on processor 101.

[0064] For example, the synchronous driver 130 may be implemented in a Complex Device Driver (CDD) software component 240 according to the AUTOSAR architecture 200 on the processor 101 and provide access to hardware registers of the processor 101.

[0065] The asynchronous driver 120 can be implemented in a Microcontroller Abstraction Layer, MCAL, software component 260 according to the AUTOSAR architecture 200 on the processor 101.

[0066] The flash memory 140 can be designed to persistently store the vehicle state data of the individual processes 111, 112, 113, 114.

[0067] The synchronous driver 130 may be configured to execute the writing 132 of the vehicle state data of the predetermined process 114 into the flash memory 140 within a maximum time interval of 10 ms.

[0068] For example, the predetermined process 114 may be assigned to a vehicle crash module and configured to transmit the write request 116 to the synchronous driver 130 in response to a crash event. The write request 116 may include data from the crash event. The synchronous driver 130 may be configured to log the crash event data in the flash memory 140.

[0069] Fig. 2 shows a schematic representation of the AUTOSAR architecture 200, in which an asynchronous driver 120 and a synchronous driver 130 are integrated according to an embodiment. The asynchronous driver 120 and the synchronous driver 130 are implemented as described above. Figure 1 described.

[0070] The AUTOSAR 200 architecture comprises a complete base software for ECUs as an integration platform for hardware-independent software applications. AUTOSAR provides exchange formats or description templates for a seamless configuration process of the base software and the integration of the application software on an ECU. AUTOSAR also provides a specification of interfaces for typical automotive applications from all areas in terms of syntax and semantics, which should serve as a standard for the application software.

[0071] The AUTOSAR architecture 200 comprises a hardware-independent application layer App 210, a real-time environment RTE ("Real Time Environment") 220, an operating system Os 230, a CDD ("Complex Device Driver") layer 240, a basic software (BSW) layer 250, and a microcontroller abstraction layer (MCAL) 260.

[0072] The RTE 220 is a middleware layer and provides communication services for the application software 210. These communicate with each other or with the services via the RTE 220. One advantage of this software 220 is the ability to group functions and relocate them to other ECUs ("Electronic Control Units"). Furthermore, functions can also be encapsulated via the RTE 220, thus becoming independent of the communication technology.

[0073] The AUTOSAR OS 230 operating system implements real-time behavior and time monitoring, as well as runtime security mechanisms. AUTOSAR OS 230 can be scaled depending on the application.

[0074] The MCAL layer 260 ensures that applications of the application layer 210 based on it are microcontroller-independent and can therefore be used on many different microcontrollers.

[0075] The CDD layer 240 is used to implement complex sensor evaluation and actuator control with direct access to the microcontroller using specific interrupts and / or complex microcontroller peripherals as well as external devices, such as communication transceivers or ASICs, to meet specific functional and timing requirements. Furthermore, the CDD layer 240 is used to implement extended services or protocols or to encapsulate legacy functions of a non-AUTOSAR system. The synchronous driver ("DirectFls") 130 is implemented as a component of the CDD layer 240.

[0076] The basic software 250 provides the functionality of an ECU (Electronic Control Unit). Hardware access occurs via this layer. AUTOSAR defines a software architecture for control units that decouples the software from the device's hardware. AUTOSAR defines a largely automated configuration process for the software, which is composed of individual functional modules, the software components, which can be developed independently of one another and by different manufacturers. This process links the software components into a specific project.

[0077] The MCAL layer 260 provides access to the microcontroller. Access is via a standardized interface. This makes modules in higher layers independent of the respective controller. The MCAL layer 260 provides basic microcontroller functions, such as initializing the clock generator and CPU operating modes, memory bus, interrupts, and controlling the watchdog timer (WDT) and the timing module. The MCAL layer 260 also implements the basic configuration of all microcontroller ports (PORTs), digital inputs / outputs (DIO), input capture unit (ICU), pulse-width modulated signal outputs (PWM), and analog-to-digital converters (ADCs), as well as controlling internal and external Flash ROM and EEPROM components. The MCAL layer 260 also provides drivers for internal and external SPI, CAN, LIN, and FlexRay controllers. The asynchronous driver (FIs) 120 is implemented in the MCAL layer 260.

[0078] As described above, the synchronous driver ("DirectFIs") 130 is implemented as a component of the CDD layer 240. Since one of the key tasks of the driver 130 is saving and restoring the hardware context, the software must be adapted for each platform. PowerPC and Tricore are currently supported. The synchronous driver 130 can be used, for example, for the "Save Crash Event" and "Save Exceptions" functions, which deal with saving vehicle status data in accident situations and exceptional situations, respectively.

[0079] The interface for writing data can be implemented as follows, for example: Std_ReturnType DirectFIs_Write(const uint32 u32TargetAddress, const uint8* pu8SourceAddressPtr, const uint8 u8Length); This allows a value at the address indicated by the pointer pu8SourceAddressPtr to be written with a length of u8Length (e.g. 8 bits) to the address u32TargetAddress in the flash memory.

[0080] Fig. 3 shows a schematic representation of a method for controlling write requests of a plurality of processes to a flash memory according to the disclosure.

[0081] The method 300 is for controlling write requests of a plurality of processes that are executed on a processor of a vehicle control unit, as described above. Figure 1 described in more detail. Each process is assigned to a corresponding vehicle control component. The vehicle control unit has a flash memory for storing vehicle status data of the individual processes, as described above. Figure 1 described.

[0082] The method 300 comprises the four steps described below: In response to a write request from a respective process of the plurality of processes to an asynchronous driver executing on the processor, writing 301 vehicle state data of the respective process in a corresponding process context to the flash memory by the asynchronous driver, wherein writing to the flash memory by the asynchronous driver occurs according to a first-in-first-out, FIFO, characteristic.In response to a write request from a predetermined process of the plurality of processes to a synchronous driver executing on the processor, the synchronous driver halts 302 execution of the asynchronous driver, and the synchronous driver writes 303 vehicle state data of the predetermined process to the flash memory, wherein the halting of the asynchronous driver occurs while preserving the corresponding process context under which the asynchronous driver is writing to the flash memory at the time of the halt.

[0083] After writing the vehicle state data of the predetermined process to the flash memory, reactivating 304 the asynchronous driver by the synchronous driver and restoring the saved process context.

[0084] These four steps correspond to the functionality of the vehicle control unit 100, as described above. Figure 1described in more detail. The method 300 can be used on such a vehicle control unit 100.

[0085] Furthermore, a computer program with a program code for executing the method 300 on a vehicle control unit 100, as described above, Figure 1 described, provided. LIST OF REFERENCE SYMBOLS

[0086] 100Vehicle control unit 101Processor 111Process 112Process 113Process 114Predetermined process, e.g., to crash 120Asynchronous driver 130Synchronous driver 140Flash memory 115Write request of a process 116Write request of the predetermined process 121Writing of the asynchronous driver to the flash memory 132Writing of the synchronous driver to the flash memory 131Control command (stop, reactivate) of the synchronous driver 200AUTOSAR Architecture 210Application Layer 220RTE (Real Time Environment) 230OS or Operating System 240CDD (Complex Device Driver) Software Component 250BSW (Basic Software Modules) Software Component 260MCAL (Microcontroller Abstraction Layer) Software Component 300Method for controlling a plurality of processes on a vehicle control unit 301Writing by the asynchronous driver 302Pausing the asynchronous driver by the synchronous driver 303Writing by the synchronous driver 304Reactivating the asynchronous driver by the synchronous driver

Claims

1. Vehicle control unit (100) having a processor (101) and a flash memory (140), the processor (101) being designed to perform a plurality of processes (111, 112, 113, 114), each process being associated with a corresponding vehicle control component; wherein the processor (101) is designed to execute an asynchronous driver (120) that is designed to respond to a write request (115) of a respective process of the plurality of processes (111, 112, 113, 114) by writing (121) vehicle state data pertaining to the respective process in an applicable process context to the flash memory (140), the flash memory (140) being written to (121) by the asynchronous driver (120) in accordance with a first-in-first-out, FIFO, characteristic; wherein the processor (101) is furthermore designed to execute a synchronous driver (130) that is designed to respond to a write request (116) of a predetermined process (114) of the plurality of processes (111, 112, 113, 114) by stopping (131) execution of the asynchronous driver (120) on the processor (101) and writing (132) vehicle state data pertaining to the predetermined process (114) to the flash memory (140), the asynchronous driver (120) being stopped (131) by saving the applicable process context under which the asynchronous driver (120) is writing (121) to the flash memory (140) at the time of the stopping (131), wherein the synchronous driver (130) is furthermore designed to reactivate (131) the asynchronous driver (120) by restoring the saved process context after the vehicle state data pertaining to the predetermined process (114) have been written (132) to the flash memory (140).

2. Vehicle control unit (100) according to Claim 1, wherein the predetermined process (114) of the plurality of processes (111, 112, 113, 114) is a process that is designed to log exception states of the vehicle, in particular in the event of a vehicle crash or in the event of undefined states arising in the vehicle control unit (100).

3. Vehicle control unit (100) according to Claim 1 or 2, wherein the flash memory (140) is a vehicle error memory that is designed to log data regarding an error state of the respective vehicle control components.

4. Vehicle control unit (100) according to one of the preceding claims, wherein the synchronous driver (130) is designed to write (132) the vehicle state data pertaining to the predetermined process (114) to the flash memory (140) in real time.

5. Vehicle control unit (100) according to one of the preceding claims, wherein the asynchronous driver (120) is designed to process the write requests (115) of the respective processes of the plurality of processes (111, 112, 113, 114) sequentially in accordance with the FIFO characteristic without guaranteeing a predetermined processing time.

6. Vehicle control unit (100) according to one of the preceding claims, wherein the saving and restoring of the applicable process context is dependent on a hardware design of the processor (101), in particular a design of specific hardware registers of the processor (101).

7. Vehicle control unit (100) according to one of the preceding claims, wherein the predetermined process (114) of the plurality of processes (111, 112, 113, 114) has a dedicated interface to the synchronous driver (130) in order to relay the write request (116) of the predetermined process (114) to the synchronous driver (130).

8. Vehicle control unit (100) according to one of the preceding claims, wherein the flash memory (140) is designed to persistently store the vehicle state data pertaining to the individual processes (111, 112, 113, 114).

9. Vehicle control unit (100) according to one of the preceding claims, wherein the synchronous driver (130) is designed to execute the writing (132) of the vehicle state data pertaining to the predetermined process (114) to the flash memory (140) within a time interval of 10 ms maximum.

10. Vehicle control unit (100) according to one of the preceding claims, wherein the predetermined process (114) is associated with a vehicle crash module, the predetermined process (114) being designed to respond to a crash event by relaying the write request (116) to the synchronous driver (130), the write request (116) comprising data pertaining to the crash event, wherein the synchronous driver (130) is designed to log the data pertaining to the crash event in the flash memory (140).

11. Method (300) for controlling write requests of a plurality of processes that are performed on a processor of a vehicle control unit, each process being associated with a corresponding vehicle control component, and the vehicle control unit having a flash memory for storing vehicle state data pertaining to the individual processes, wherein the method (300) comprises the following steps: in response to a write request of a respective process of the plurality of processes to an asynchronous driver executed on the processor, the asynchronous driver writing (301) vehicle state data pertaining to the respective process in an applicable process context to the flash memory, the flash memory being written to by the asynchronous driver in accordance with a first-in-first-out, FIFO, characteristic; in response to a write request of a predetermined process of the plurality of processes to a synchronous driver executed on the processor, the synchronous driver stopping (302) execution of the asynchronous driver and the synchronous driver writing (303) vehicle state data pertaining to the predetermined process to the flash memory, the asynchronous driver being stopped by saving the applicable process context under which the asynchronous driver is writing to the flash memory at the time of the stopping; and after the vehicle state data pertaining to the predetermined process have been written to the flash memory, the synchronous driver reactivating (304) the asynchronous driver by restoring the saved process context.

12. Computer program having a program code for carrying out the method (300) according to Claim 11 on a vehicle control unit (100) according to one of Claims 1 to 10.