Method for simulating a computing unit, in particular a control unit of a vehicle

Abstract

The invention relates to a method for simulating a computing unit, in particular a control unit of a vehicle, wherein software is executable in the computing unit, wherein, during execution of this software in the computing unit, individual events are each executed at a respective start time, comprising determining event information relating to the respective start time of the individual events; performing a computer-implemented simulation (200, 400) of the computing unit; and executing the individual events in the simulation (200, 400) in each case depending on the determined event information.

Description

[0001] The present invention relates to a method for simulating a computing unit, in particular a control unit of a vehicle, as well as a computing unit and a computer program for carrying out the method. Background of the invention

[0002] In computing units in technical applications, such as control units, software can be executed to control a corresponding technical device. For example, software executed in a control unit of a (motor) vehicle can be used to control vehicle functions, such as engine control or driver assistance functions, etc. To develop and validate such computing units, including the software, the system can be simulated in a computer-implemented simulation. It can be important to be able to replicate the software execution in the simulation as realistically as possible. Disclosure of the invention

[0003] According to the invention, a method for simulating a computing unit, as well as a computing unit and a computer program for implementing the method, are proposed, having the features of the independent patent claims. Advantageous embodiments are the subject of the dependent claims and the following description.

[0004] The computing unit can in particular be a control unit for controlling a technical device, in particular a (motor) vehicle. Software can be executed in the computing unit, wherein during the execution of this software in the computing unit individual events or software events are each executed at a respective start time. The start time is in particular a time at which the execution of the respective event begins. Accordingly, an end time is in particular a time at which the execution of the respective event is ended or at which the event has been fully carried out. These software events can each in particular involve the execution of individual software components orSoftware functions include (control flow events), and in particular the execution of memory accesses to a memory unit, in particular to a specific memory area or to data stored in this memory area (data flow events). For example, these software events can be executed in a vehicle control unit to control vehicle functions, e.g., in the course of engine control, a driver assistance function, etc. The individual events are executed in the processing unit in a specific sequence or processing order, whereby this sequence can be described, in particular, by the individual start times.

[0005] Within the scope of the method, event information is determined regarding the respective start time of the individual events. The event information can also, in particular, relate to the respective end time of the individual events and thus to an execution time or execution duration of the respective event. In particular, the event information represents sequence information that characterizes the precise temporal sequence of the individual events relative to one another. The event information particularly expediently characterizes when the execution of a respective event begins in the computing unit, particularly in temporal relation to an immediately preceding event.

[0006] A computer-implemented simulation of the computing unit is performed, whereby, for example, the hardware and an operating system, as well as, in particular, a middleware or runtime environment of the computing unit, are simulated in a simulation computing unit. For example, software packages for simulating (vehicle) control units can be used for this purpose, e.g., the so-called "Functional Mock-up Interface" (FMI), ETAS RTA-OS VRTA, ETAS VECU-Builder, ETAS COSYM, ETAS Model Simulator, etc.

[0007] The software executable by the computing unit is executed in the simulation or in the computing unit simulated therein. The individual events in the simulation are each executed depending on the specific event information. With the help of the event information, the individual events in the simulation are particularly expediently executed in a sequence and in a temporal relationship relative to one another as is the case in the actual computing unit. The individual events, in particular directly consecutive events, can be particularly expediently executed in the simulation in such a way that the simulation times at which processing of the respective events begins in the simulation correspond to the start times of these events in the actual computing unit.In this way, the execution of the software in the computing unit can be simulated particularly precisely, realistically, and with bit accuracy. The invention can therefore be particularly useful in improving the development and validation of computing units such as control units using simulations.

[0008] In order to perform a conventional simulation of a computing unit or control unit, scheduling is often used to execute software events or software components, which is also configured in the operating system of the computing unit to be simulated. During the simulation, the operating system of the computing unit to be simulated is often simulated, but with idealized (preconfigured) scheduling points for periodically executed components. However, the time between the start and end of the execution of a software event or software component in a concurrent system can depend on many factors, e.g., the specific input (data and timing), the execution times of other components with a higher scheduling priority on the same core, and the system load on hardware resources shared with other processor cores (e.g., memory cache, DRAM controller, etc.).), as well as the hardware used in the computing unit to be simulated. Therefore, differences in the control flow actually occurring in a specific situation in the real computing unit and in the simulation can occur in the conventional way. These differences in control flow can lead to differences in data flow, i.e. in the order of write and read accesses of different software components to common variables. In conventional simulations, the execution of the software can therefore differ significantly from the execution in the real computing unit to be simulated. A bit-precise simulation is therefore often not possible.

[0009] In contrast, the present invention enables controlled control and data flow in the simulation. Control flow and data flow events in the computing unit to be simulated can be determined and recorded, for example, with timestamps. In the simulation, it is then particularly useful to enforce the same sequence of these events. This enables bit-accurate simulation.

[0010] According to one embodiment, the execution of the individual events in the simulation, depending on the specific event information, comprises blocking, delaying, or preventing the execution of a respective event until the respective start time of this event is reached. When the respective start time of this event is reached, the execution of the respective event is activated, released, or permitted. In this way, it is possible, in particular, to prevent individual events in the simulation from being executed in a different order or in a different temporal relationship to one another than is the case in the actual computing unit. In the simulation, compliance with the actual execution sequence of the computing unit to be simulated can thus be expediently enforced.

[0011] According to one embodiment, a hold function or wait function is executed in the simulation, which blocks the execution of the respective event until the respective start time of this event is reached, and activates the execution of the respective event when the respective start time of this event is reached. For example, such a hold function can be implemented in the simulation for each of the events. For example, this hold function can be realized by using breakpoints or wait points. If the software executable in the computing unit to be simulated is concurrent software, so that software components are executed there simultaneously, it is particularly expedient to block corresponding simultaneous or concurrent events in the simulation by means of corresponding wait points.Continued execution is activated specifically for the waitpoint corresponding to a subsequent, next event. Within the waitpoints, corresponding events can be executed, such as task switching, middleware function calls, or read / write accesses to shared variables. In the simulation, execution is then not concurrent, but sequential.

[0012] According to one embodiment, the halt functions are each inserted or implemented into the software as a software unit or software function. For example, during source code instrumentation, condition variables ("Posix Thread Condition Variables", pthread_cond_wait(...)) or semaphores can be inserted into the source code of the software. Furthermore, instrumentation can be performed, in particular binary instrumentation, for example, to insert debugging breakpoints into the software.

[0013] Alternatively or additionally, according to one embodiment, a hardware unit is provided or used to execute the halt functions. This hardware unit can be implemented in a simulation computing unit that performs the simulation. For example, the hardware unit can be a hardware breakpoint, e.g., an ARM debug module (ARM CoreSight Debug Cell).

[0014] According to one embodiment, executing the individual events in the simulation based on the determined event information includes determining a processing sequence or execution sequence ("event queue") for executing the individual events based on the determined event information. The individual events are executed in the simulation according to the determined processing sequence. In particular, the start times of the individual events can be translated into the execution sequence according to which the events are then processed in the simulation. In this way, it can be achieved, in particular, that the events in the simulation are processed in the same order as in the actual computing unit to be simulated.

[0015] According to one embodiment, determining the event information comprises executing a tracing function or a trace point, a tracing function, or a tracking function, which, during the execution of the software in the computing unit, determines, records, or collects the respective start time of the individual events as event information. For example, a separate tracing function can be provided for each event. The tracing functions can each record the respective start time as a timestamp. Furthermore, these tracing functions can, in particular, also determine the respective end times and / or properties or parameters relating to the individual events as event information.These tracing functions can be expediently implemented in the computing unit to be simulated so that the event information can be collected during the actual execution of the software in the computing unit to be simulated. In particular, the execution of the software can be monitored or tracked in this way during regular operation of the computing unit in order to then be able to reproduce the software in the simulation as realistically and bit-accurately as possible. In this way, control flow and data flow events can be recorded with timestamps in the computing unit to be simulated, and compliance with the same order of the recorded events can be enforced in the simulation. In particular, the system execution of the computing unit is not slowed down, or at least not significantly, by the trace functions, and the system function of the computing unit is not affected.For example, in the automotive sector, event information can be collected using tracing functions during test drives. For example, the standardized ASAM measurement data format (Measurement Data Format, MDF) can be used for this purpose. This MDF standard includes, for example, the measurement of ECU variables, the measurement of bus data, and the storage / archiving of measurement data.

[0016] According to one embodiment, the tracing functions are each inserted into the software as a software unit, in particular into a source code and / or into a machine code and / or into a compiler or linker of the software. For example, source code instrumentation can be performed, whereby special function calls ("trace hook callouts") can be inserted into the source code. For example, function wrapping can also be performed, whereby function calls can be intercepted ("wrapped") using linker commands, e.g., in the GNU compiler or linker using the "gcc -wrap" function. Furthermore, branches to function calls or hook functions can be inserted into the machine code, for example, during instrumentation or binary code instrumentation.This can be achieved, for example, with special compiler functions ("Compiler Instrumentation") during binary code generation ("Static Binary Instrumentation") or by dynamic retranslation ("Dynamic Retranslation") during execution ("Dynamic Binary Instrumentation"). For this purpose, the so-called instrumentation framework "Va-Igrind" can be used, for example, to create dynamic analysis tools.

[0017] Alternatively or additionally, according to one embodiment, the tracing functions are executed using a hardware unit in the computing unit. For example, fully automated hardware tracing can be performed using the processor unit of the computing unit. For example, an ARM tracing module (ARM CoreSight Embedded Trace Macrocell) can be used for this purpose.

[0018] According to one embodiment, the tracing functions are replaced by the hold functions for the simulation after the event information has been determined. After the respective event information, in particular the respective start times, has been recorded by the tracing functions for each event during the regular operation of the computing unit, the hold functions can then be used particularly expediently to replicate or maintain the corresponding event information or start times in the simulation during the simulation.

[0019] According to one embodiment, the computing unit has a first processor unit with at least one processor core and a second processor unit with at least one processor core. Each of the processor cores executes an operating system, wherein the two processor cores can in particular also execute different operating systems. During the execution of the software in the computing unit, first events are each executed at a respective first start time in the first processor unit. Second events are each executed at a respective second start time in the second processor unit. Determining the event information comprises determining first event information relating to the respective first start time of the individual first events and determining second event information relating to the respective second start time of the second events.As part of the computer-implemented simulation of the computing unit, the first processor unit and the second processor unit are each simulated in the simulation computing unit. In the simulation, the individual first events in the simulated first processor unit and the individual second events in the simulated second processor unit are executed both depending on the first event information and depending on the second event information. In this way, the execution sequence of the respective events can be maintained in each of the simulated processor units - also taking mutual consideration into account - as is also the case in the actual computing unit. The simulations of the two processor units can, for example, exchange corresponding timestamps for the globally next event.

[0020] For example, control units in vehicles can be concurrent systems in which different software components can be executed simultaneously on different processors and / or processor cores. On a single processor core, software components can run concurrently using preemptive scheduling, for example. The "Autosar" software platform can be used for this purpose. For safety-critical systems, periodic scheduling can often be used, with different components generally being able to be executed with different periodicities. Particularly useful, such control units can be realistically simulated within the scope of the embodiments of the invention, which can improve the development and validation of the control units.The method is particularly useful for concurrent systems with a single (multi-core) processor and operating system, as well as for systems with multiple (potentially different) multi-core processors and operating systems. For multi-processor systems, a distributed event queue or multiple communicating event queues can be used for synchronization or sequencing.

[0021] According to one embodiment, the individual events each comprise an execution of a software component or software function (control flow events) and / or an execution of a memory access (data flow events). For example, during the execution of individual software components, a memory access can be performed, in particular to read and / or write to specific data. For example, the start times or execution start times of the individual software components as well as the start times or access start times of the individual memory accesses can be determined as event information. Both the control flow and the data flow can then be realistically recreated in the simulation.

[0022] A computing unit according to the invention is configured, in particular in terms of programming, to carry out a method according to the invention.

[0023] The implementation of a method according to the invention in the form of a computer program or computer program product with program code for carrying out all method steps is also advantageous, since this entails particularly low costs, in particular if an executing control unit is also used for other tasks and is therefore already present. Finally, a machine-readable storage medium is provided with a computer program stored thereon, as described above. Suitable storage media or data carriers for providing the computer program are, in particular, magnetic, optical and electrical memories, such as hard disks, flash memories, EEPROMs, DVDs, and others. Downloading a program via computer networks (Internet, intranet, etc.) is also possible. Such a download can be wired or cable-based or wireless (e.g. via a WLAN network, a 3G, 4G, 5G or 6G connection, etc.).

[0024] Further advantages and embodiments of the invention will become apparent from the description and the accompanying drawings.

[0025] The invention is illustrated schematically in the drawing using exemplary embodiments and is described below with reference to the drawing. Short description of the drawings Fig. 1 schematically shows in a view a) a computing unit and in a view b) a simulation of the computing unit according to an embodiment of the invention. Fig. 2 schematically shows in a view a) a computing unit and in a view b) a simulation of the computing unit according to an embodiment of the invention. Embodiment(s) of the invention

[0026] In Fig. Figure 1a schematically shows a computing unit designated 100, which is embodied, for example, as a control unit of a (motor) vehicle, e.g., as an engine control unit for engine control. Within the scope of one embodiment of the invention, the control unit 100 is to be simulated in a computer-implemented simulation, e.g., for (further) development and validation.

[0027] An operating system 110, a middleware or runtime environment 120, and software or application software 130 are executed in the control unit 100. The software 130 can comprise a plurality of software components or software functions 131, 132. During the execution of the software 130 in the control unit 100, individual events are executed at a respective start time and up to a respective end time. These events include, for example, the execution of the individual software components (control flow events) and the execution of memory accesses (data flow events). For example, a corresponding memory access can occur during the execution of each of these individual software components.

[0028] During the execution of software 130 in control unit 100, e.g., during a test drive of the vehicle, event information is determined regarding the respective start times of the individual events. For example, the respective start times at which the execution of the respective software components or the respective memory accesses begins are recorded as event information.

[0029] For this purpose, a tracing unit 150 can be implemented in the control unit 100. This tracing unit executes a tracing function during the execution of the software 130 in order to record a respective start time as a timestamp using a timer 140, indicated by the dashed arrows 151. The tracing unit 150 further determines properties or parameters of the event initiated at the respective start time. The individual recorded timestamps are stored by the tracing unit 150, together with the associated properties, as event information in a file 155.

[0030] The tracing unit 150 can be implemented in the control unit 100 as a software unit and / or as a hardware unit. For example, the software architecture of the control unit 100 can be based on the "Autosar Classic" software platform. The "Autosar Runtime Environment" (RTE), for example, can be used as the middleware 120. Autosar RTE, for example, supports a so-called "RteVfbTraceClient" interface for configuring and acquiring trace functions, which allows the tracing unit 150 to be integrated into the control unit 100 as a software unit.

[0031] Depending on the specific event information, the simulation of the control unit 100 will be performed as described below with respect to Fig. 1b is explained.

[0032] In Fig. 1b schematically illustrates the simulation of control unit 100 according to one embodiment of the invention and is designated by 200. The computer-implemented simulation 200 is executed by a simulation computing unit, e.g., a computer.

[0033] A simulation controller 210 is provided for the higher-level control of the simulation 200. During the simulation 200, a middleware 220, corresponding to the middleware 120 of the actual control unit 100, and an application software 230 comprising a plurality of software components 231, 232, corresponding to the software 130 of the actual control unit 100, are executed, each managed by the simulation controller 210.

[0034] During simulation 200, the individual events of software 230 are each executed depending on the specific event information. For this purpose, file 155 with the event information stored therein is read by a unit 250 for determining an execution sequence. Depending on the event information, in particular depending on the start times, this unit 250 determines a processing sequence ("event queue") according to which the individual events are to be executed and processed sequentially. This processing sequence is transmitted to simulation controller 210 so that simulation controller 210 can activate the execution of the individual events in the correct order.

[0035] The simulation controller 210 blocks the execution of a respective event until the respective start time of that event is reached. When the respective start time of the corresponding event is reached, the simulation controller 210 activates the execution of that event, indicated by the dashed arrows 251.

[0036] For this purpose, hold functions, wait functions, or wait points are used, which can be inserted into the software 230 as software units, for example, by inserting condition variables ("Posix Thread Condition Variables", pthread_cond_wait(...)) into the source code or source text of the software 230 during source code instrumentation. For example, the tracing functions used in the real control unit 100 can be replaced by these hold functions. The simulation controller 210 activates the next blocked, waiting event according to the execution sequence of the unit 250.

[0037] The invention thus enables controlled control and data flow in the simulation. By recording control flow and data flow events in the real control unit 100 with timestamps, the simulation 200 can be enforced to maintain the same order of recorded events. This enables a bit-accurate simulation.

[0038] The method is particularly suitable for concurrent systems with a single (multi-core) processor and operating system, as well as for systems with multiple (potentially different) multi-core processors and operating systems. For a multi-processor system, a distributed event queue can be used for synchronization or scheduling.

[0039] Sequencing used as following in relation to the Fig. 2a and Fig. 2b is explained.

[0040] Fig. 2a schematically shows a computing unit 300 to be simulated, which, for example, corresponds to the computing unit 100 of Fig. 1a is also designed as an (engine) control unit of a (motor) vehicle and is to be simulated in a computer-implemented simulation within the scope of an embodiment of the method according to the invention.

[0041] The control unit 300 has a first processor unit with at least one processor core, which executes a first operating system 310', a first middleware 320', and a first application software 330' with a plurality of software components 331', 332'. Furthermore, the control unit 300 has a second processor unit with at least one processor core, which executes a second operating system 310', a second middleware 320', and a second application software 330' with a plurality of software components 331', 332'. Furthermore, the control unit 300 has a global timer 340, so that the two processor units have a common time base. The two operating systems 310' and 310' can, in particular, be different operating systems. For example, the first processor unit can be based on the "Autosar Classic" software platform, and the second processor unit on the "Autosar Adaptive" platform.For example, “Bosch AOS” can be used as middleware 320 on “Autosar Adaptive”.

[0042] During operation of control unit 300, first events are executed in the first processor unit at a respective first start time, and second events are executed in the second processor unit at a respective second start time. These first and second events can also each include the execution of software components or the execution of memory accesses. For each of these first and second events, corresponding event information, in particular the respective start times, is determined during operation of control unit 300, e.g., during a test drive of the vehicle.

[0043] As above with regard to Fig. As explained in Figure 1a, tracing functions can be used for this purpose. For example, a first tracing unit 350' can be provided for the first processor unit, which executes a tracing function during the execution of the first software 330' in order to capture a respective first start time as a timestamp with the aid of the timer 340, if desired, together with parameters of the first event started at the respective start time as first event information, indicated by the dashed arrows 351'. This first event information is stored in a first file 355'.

[0044] Accordingly, a second tracing unit 350" can be provided for the second processor unit, which executes tracing functions during the execution of the second software 330" in order to record the corresponding second start times as a time stamp, if desired together with parameters of the second event started at the respective second start time, as second event information, indicated by the dashed arrows 351". The second tracing unit 350" stores this second event information in a second file 355".

[0045] Since the two processor units have a common time base, the first and second event information can be captured in a global sequence by means of the tracing units 350', 350". The simulation of the control unit 300 is carried out depending on the first event information and the second event information.

[0046] In Fig.2b, simulation 400 of the control unit 300 according to an embodiment of the method according to the invention is shown schematically.

[0047] During simulation 400, the first processor unit of control unit 300 is simulated. A first simulation controller 410' is provided for this purpose. Managed by this first simulation controller 410', a first middleware 420', corresponding to the first middleware 320' of control unit 300, and a first application software 430' comprising software components 431', 432', corresponding to the first software 330' of control unit 300, are executed.

[0048] Furthermore, the second processor unit of the control unit 300 is simulated, for which a second simulation controller 410" is provided. Managed by this second simulation controller 410", a second middleware 420" and a second application software 430" with software components 431", 432" are executed, corresponding to the second middleware 320" and the second software 330" of the control unit 300.

[0049] During simulation 400, the individual first events are executed depending on the first event information. For this purpose, a first unit 450' is provided, which reads in file 355' with the first event information and, depending on this first event information, determines a first processing sequence according to which the first events are to be processed. The processing sequence is transmitted to the first simulation controller 410'. The first simulation controller 410' blocks the execution of a respective first event until the respective first start time is reached and activates the execution of this first event when the respective first start time is reached, indicated by the dashed arrows 451'.

[0050] In a corresponding manner, the individual second events are executed depending on the second event information, with a second unit 450 reading the file 355 with the second event information and determining a second processing sequence for the second events. The second simulation controller 410 blocks the execution of the second events until the corresponding second start time is reached and activates the execution as soon as the respective second start time is reached, indicated by the arrows 451.

[0051] In this way, the sequence of events can be maintained in each of the simulated processor units according to the actual computing unit 300. Furthermore, the first simulation controller 410' and the second simulation controller 410" can communicate with each other for this purpose and, for example, exchange time stamps about the globally next event, indicated by the arrows 415.

[0052] Each of the simulated processor units thus has its own event queue and simulation controller. One of the simulation controllers can, for example, assume a higher-level role and can then, for example, activate a waiting event either on its own processor or via the other simulation controller. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited non-patent literature

[0000] Functional Mock-up Interface (FMI), ETAS RTA-OS VRTA, ETAS VECU Builder

[0006] Posix Thread Condition Variables", pthread_cond_wait(.

[0036]

Claims

[1] Method for simulating a computing unit (100, 300), in particular a control unit of a vehicle, wherein software (130, 330', 330") is executable in the computing unit (100, 300), wherein during the execution of this software (130, 330', 330") in the computing unit (100, 300) individual events are executed at a respective start time, comprising the steps: Determining event information regarding the respective start time of each event; Performing a computer-implemented simulation (200, 400) of the computing unit (100, 300); and Execute the individual events in the simulation (200, 400) depending on the specific event information. [2] The method of claim 1, wherein executing the individual events in the simulation (200, 400) depending on the determined event information comprises: Blocking the execution of a respective event until the respective start time of that event is reached; Activate the execution of the respective event when the respective start time of this event is reached. [3] The method of claim 2, wherein executing the individual events in the simulation (200, 400) depending on the determined event information comprises: Executing a hold function which blocks the execution of the respective event in the simulation (200, 400) until the respective start time of this event is reached, and activates the execution of the respective event when the respective start time of this event is reached. [4] The method of claim 3, further comprising: Inserting the holding functions as a software unit into the software; and / or Providing a hardware unit to perform the hold functions. [5] Method according to one of the preceding claims, wherein the execution of the individual events in the simulation (200, 400) depending on the determined event information comprises: Determining a processing sequence for executing the individual events depending on the specific event information; Execute the individual events in the simulation (200, 400) according to the specified processing order. [6] A method according to any one of the preceding claims, wherein determining the event information comprises: Executing a tracing function which determines the respective start time of the individual events during the execution of the software (130, 330', 330") in the computing unit (100, 300). [7] The method of claim 6, further comprising: Inserting the tracing functions as a software unit into the software (130, 330', 330"), in particular into a source code and / or into a machine code and / or into a compiler or linker of the software; and / or Executing the tracing functions by means of a hardware unit in the computing unit (100, 300). [8] Method according to claim 6 or 7, as far as dependent on claim 3, further comprising: Replacing the tracing functions after determining the event information with the hold functions for the simulation. [9] Method according to one of the preceding claims, wherein the computing unit (300) comprises a first processor unit with at least one processor core and a second processor unit with at least one processor core, wherein, during the execution of the software (330', 330") in the computing unit (300), first events are executed at a respective first start time in the first processor unit and second events are executed at a respective second start time in the second processor unit, wherein determining the event information comprises determining first event information and second event information, wherein the first event information relates to the respective first start time of the individual first events and wherein the second event information relates to the respective second start time of the second events, wherein performing the computer-implemented simulation (400) of the computing unit (300) comprises simulating the first processor unit and simulating the second processor unit, wherein executing the individual events in the simulation comprises executing the individual first events in the simulated first processor unit and executing the individual second events in the simulated second processor unit depending on the first event information and depending on the second event information. [10] Method according to one of the preceding claims, wherein the individual events each comprise an execution of a software component and / or an execution of a memory access. [11] Computing unit which is designed to carry out all method steps of a method according to one of the preceding claims. [12] Computer program which causes a computing unit to carry out all the method steps of a method according to one of claims 1 to 10 when executed on the computing unit. [13] A machine-readable storage medium having stored thereon a computer program according to claim 12.

Images