METHOD AND SYSTEM FOR TESTING AT LEAST ONE ELECTRONIC CONTROL UNIT AS A VIRTUAL CONTROL UNIT ON A SIMULATOR AND CORRESPONDING SIMULATOR

Description

[0001] The invention relates to a method for testing at least one electronic control unit as a virtual control unit on a simulator with at least one simulator computing unit, wherein the electronic control unit has a hardware configuration with at least one computing unit and an external interface for exchanging data and a software configuration associated with the hardware configuration, wherein the software configuration comprises an internal functionality and an external interface functionality, wherein the electronic control unit is mapped to the virtual control unit by adopting the internal functionality of the software configuration of the electronic control unit as the internal functionality of a software configuration of the virtual control unit and by replacing the external interface functionality of the electronic control unit by a data transfer functionality of the software configuration of the simulator computing unit,wherein the software configuration of the virtual control unit is translated into executable code for the simulator computing unit and executed on the simulator. Furthermore, the invention relates to a system for testing at least one electronic control unit as a virtual control unit on a simulator, wherein the system comprises the simulator as well as a hardware configuration and a software configuration of the electronic control unit associated with the hardware configuration, wherein the simulator comprises at least one simulator computing unit, wherein the hardware configuration of the electronic control unit comprises at least one computing unit and an external interface for exchanging data, wherein the software configuration comprises an internal functionality and an external interface functionality, wherein the simulator maps the electronic control unit to the virtual control unit,by adopting the internal functionality of the software configuration of the electronic control unit as the internal functionality of a software configuration of the virtual control unit, and by replacing the external interface functionality of the electronic control unit with a data transfer functionality of a software configuration of the simulator computing unit, wherein the software configuration of the virtual control unit is translated into executable code for the simulator computing unit and executed on the simulator in the operating state of the simulator. Furthermore, the invention also relates to a corresponding simulator and a related computer program.

[0002] Methods and systems of the type described above are used in the field of control unit development, more specifically in the development and testing of software for control units. Control units are small computers with an external interface. Via this external interface, the control unit is in active connection with a technical-physical process and / or in communication with other control units. From the control unit's perspective, data can therefore be exchanged via the external interface in both the transmit and receive directions. The external interface can be a very simple process interface for exchanging exclusively measured data, such as an analog current interface or a digital PWM interface, but it can also be an advanced communication interface that implements, for example, a (field)bus protocol (e.g., CAN, TTP, FlexRay, Ethernet).The external interface can have a number of the aforementioned interface functionalities. The external interface of the hardware configuration is operated in software by the external interface functionality of the control unit's software configuration.

[0003] The control unit's processing unit processes and analyzes received signals or messages, for example, further processing them using a control algorithm. The corresponding calculated variables are then output as control unit output variables via the external interface. This functionality of the control unit's software configuration, which is essentially related to the functionality implemented by the processing unit, is referred to here as internal functionality. Electronic control units are widely used in a variety of applications, including the automotive sector, aerospace, and, more generally, industrial applications such as the process industry.The computing unit in currently widely used electronic control units is usually a microcontroller, a digital signal processor, or sometimes programmable circuit structures, for example in the form of field programmable gate arrays (FPGA).

[0004] Software development for control units is often mapped out in the so-called V-cycle. In the V-cycle, various development stages are completed, starting with an abstract functional test, for example of a control algorithm, without any reference to the later control unit hardware (model-in-the-loop), continuing with the test of program code for the series control unit that will later be used, which is of interest here. However, the series control unit is not yet available but is only mapped in software as a virtual control unit (software-in-the-loop, SIL), continuing with the testing of the physically existing series control unit with the series control unit program code in a fully or partially simulated environment (hardware-in-the-loop, HIL), and finally with the testing of the series control unit in the actual physical environment.This is a chain of development steps that is established and used as standard in the industry and has proven to be effective in reliably developing and intensively testing software for electronic control units.

[0005] The applicant supports the various stages of the V-cycle with appropriate hardware and software tools. The method, system, and simulator considered here represent the software-in-the-loop testing use case, which the applicant supports with the VEOS environment (see product brochure "VEOS Platform for PC-based simulation of models and ECU network communication," February 2020, dSPACE GmbH).

[0006] The electronic control unit is mapped to the virtual control unit by adopting the internal functionality of the software configuration of the electronic control unit as the internal functionality of a software configuration of the virtual control unit: therefore, as part of the test of the virtual control unit, the program code intended for the electronic control unit is actually tested by executing the program code on the simulator computing unit after it has been compiled for the simulator computing unit.

[0007] DE 10 2013 212839 A1 also describes a method for developing and / or testing a microcontroller using a virtual prototype. This virtual prototype is a simulation model of the target microcontroller to be provided, which is functionally identical to the target hardware. The same software as on the real, physical microcontroller can be executed on and / or with the simulation model of the microcontroller.

[0008] Furthermore, the external interface functionality of the electronic control unit, which is therefore related to the external interface of the electronic control unit, is replaced by a data transfer functionality of the software configuration of the simulator computing unit, whereby the software configuration of the virtual control unit is translated into executable code for the simulator computing unit and executed on the simulator. This can mean, for example, that the sending of a CAN bus message, i.e. the call of an external interface functionality of the electronic control unit, is replaced by a corresponding write command to the area of ​​a shared memory, which is accessible to both the software-implemented virtual control unit on the simulator computing unit and the communication partner—also implemented in software, which will not be discussed in detail here.This means that calls to driver components of the external interface on the real electronic control unit are not transferred to the virtual control unit on the simulator, but are replaced by the data transfer functionality of the software configuration of the simulator computing unit.

[0009] If multiple electronic control units are to be tested, for example, because they together form the relevant on-board network of a motor vehicle and interact with each other there, each of the control units is described by a hardware configuration and a software configuration, i.e., simply by describing the existing hardware components and the software components assigned to them. Each of the electronic control units is then mapped to a virtual control unit on the simulator. In terms of software, the various virtual control units each form a separate unit on the simulator; however, they can all be executed, for example, on the same simulator processing unit.It is also possible for different virtual ECUs to be calculated on different simulator processing units of the simulator, provided the simulator has multiple processing units (e.g., multiple processor modules, multiple kernels of a processor). Depending on the technical implementation, the data transfer functionality with which the various virtual ECUs can exchange information on the simulator also changes. This approach has several advantages, particularly because the structure of the network of the electronic ECUs to be tested in the real world is retained in the virtual world of the simulator and the virtual ECUs implemented there.

[0010] Control units are increasingly being used that have a much more complex hardware structure, for example, they not only have a microcontroller or a digital signal processor and an external interface, but also a large number of different computing units that are based on very different technologies and are often implemented in an integrated manner as a system-on-chip (SoC).

[0011] The object of the invention is to provide an automatic testing option for such electronic control units with various computing units of different types, which enables the handling of a complex hardware structure and the transfer of this structure to a simulator in a simple and automatic manner.

[0012] The object is achieved in the method described above for testing at least one electronic control unit as a virtual control unit on a simulator with at least one simulator computing unit in that the hardware configuration of the electronic control unit has at least a first computing unit and a second computing unit of different types, and that the software configuration comprises at least internal functionalities for the first computing unit and the second computing unit, wherein at least the internal functionality of the first computing unit calls an internal function of the internal functionality of the second computing unit. In the present application, it is important that the various computing units of the electronic control unit make use of one another, i.e. that they use and call the internal functionality provided by the respective computing unit.

[0013] For example, the first processing unit could be a "normal" CPU, such as an ARM Cortex-A CPU. This CPU utilizes the internal functionality of the second processing unit, which could be, for example, a matrix accelerator. In this respect, there are two processing units of different types. In other words, this means that there is a data exchange between the first processing unit and the second processing unit. The first processing unit, for example, tells the second processing unit which data the second processing unit should use to perform which function, and the second processing unit returns the result of this application of its internal functionality to the first processing unit.

[0014] According to the invention, it is further provided that a description of the hardware configuration and the software configuration of the electronic control unit, including the assignment of the internal functionalities to the computing units and the internal functionalities themselves, is provided. This means nothing other than that the description names the components of the hardware configuration of the control unit as a whole, and that the description also names the software configuration in the form of the internal functionalities on the respective computing units of the hardware configuration of the control unit, so that it is clear which components of the hardware configuration are used and which components of the software configuration or which internal functionalities are intended for execution there.

[0015] The inventive embodiment of the method further provides that, by evaluating the description of the electronic control unit, each processing unit of each type with an associated internal functionality is mapped to a virtual sub-processing unit of a corresponding type, wherein the internal functionality of the mapped processing unit is transferred to an internal functionality of the virtual sub-processing unit that can be executed on the simulator processing unit. The term "virtual sub-processing unit" clarifies that, from the user's perspective, the electronic control unit continues to be transferred to a single virtual control unit, which, however, has virtual sub-processing units that take into account the fact that the electronic control unit has a plurality of processing units.The aim is to continue to provide the user with a structurally identical representation of this complex electronic control unit on the simulator, despite the complicated structure of the electronic control unit with a plurality of computing units.

[0016] According to the inventive embodiment of the method, it is further provided that, by evaluating the provided internal functionalities of the first computing unit and the second computing unit, it is determined which computing units are exchanging data with each other by accessing an internal functionality of another computing unit, and that the accesses to internal functions of another computing unit are replaced by a data transfer functionality of the software configuration of the simulator computing unit. This requires that, in the evaluation step, it is known which internal functionalities the various computing units essentially have. Depending on the type of computing unit, the corresponding syntax of the software configuration of the respective computing unit must be known in the evaluation step.Depending on the format in which the software configuration of the respective computing unit is available, the syntax of the internal functionality must be known in the evaluation at the high-level programming level or, if necessary, also in binary code, etc.

[0017] The object is achieved in the system described at the outset in that the hardware configuration of the electronic control unit has at least a first processing unit and a second processing unit of different types, that the software configuration of the electronic control unit comprises at least internal functionalities for the first processing unit and the second processing unit, wherein at least the internal functionality of the first processing unit calls an internal function of the internal functionality of the second processing unit, that the simulator receives a description of the hardware configuration and the software configuration of the electronic control unit, including the assignment of the internal functionalities of the software configuration of the electronic control unit to the processing units of the electronic control unit and the internal functionalities of the processing units of the electronic control unit itself,that the simulator, by evaluating the description of the electronic control unit, maps each processing unit of each type of the electronic control unit with an associated internal functionality to a virtual sub-processing unit of a corresponding type, wherein the internal functionality of the electronic control unit of the mapped processing unit is transferred into an internal functionality of the virtual sub-processing unit that can be executed on the simulator processing unit, and that the simulator, by evaluating the provided internal functionalities of the first processing unit of the electronic control unit and the second processing unit of the electronic control unit, determineswhich computing units of the electronic control unit are in data exchange with each other by accessing an internal function of another computing unit of the electronic control unit, and the access to internal functions of another computing unit in the virtual control unit is replaced by a data transfer functionality of the software configuration of the simulator computing unit.

[0018] Accordingly, the invention is solved by the simulator of the system which carries out the described method.

[0019] As a result, the inventive embodiment of the method, the system and the simulator makes it possible to automatically map a control unit with a complex hardware configuration comprising a plurality of processing units to a virtual control unit having a complex internal structure with a plurality of virtual sub-processing units, wherein the user of the automatically performed method does not have to worry about the complex and error-prone transfer of the complex internal structure of the real control unit to corresponding components of a virtual control unit. The method makes it possible to check whether the program code - and precisely the program code - that implements the internal functionality of the electronic control unit has the expected functionality and the expected behavior, without the electronic control unit actually being present.The behavior of the internal functionality on the virtual sub-processing unit can be compared with the expected behavior in a further process step and if the actual behavior deviates from the expected behavior, the deviation is signaled externally by the simulator and, if necessary, documented by a protocol.

[0020] The different types of computing units of the real ECU can be, for example, processors (CPU), microcontrollers (µC), graphics processors (GPU), programmable logic gates (FPGA), neural network accelerators (NNA), matrix accelerators (MACC), and security chips (e.g. for cryptographic functionalities, key databases, etc.).

[0021] The invention is defined in method claim 1 and in the corresponding further independent claims 9, 11 and 12.

[0022] A preferred embodiment of the method, system, and simulator is characterized in that several computing units of identical type in the electronic control unit are mapped to exactly one virtual sub-processing unit of this type, in particular, all computing units of identical type in the electronic control unit are mapped to exactly one virtual sub-processing unit of this type. This means, for example, that several graphics processors of the electronic control unit are mapped to one virtual sub-processing unit, which contributes to improved clarity of the structure of the overall virtual control unit, but can also contribute to a more economical implementation of the virtual control unit (smaller code volume, fewer required simulation modules).

[0023] In a further preferred embodiment of the method, system, and simulator, the transfer of the internal functionality of the mapped computing unit of the electronic control unit into an internal functionality of the virtual sub-processing unit executable on the simulator computing unit comprises the use of a simulation module for the mapped computing unit of the electronic control unit that can be run on the simulator computing unit. These can, for example, be simulation modules that are often provided by the manufacturers of the actual computing units of the electronic control unit, for example, as part of the software development environment (Software Development Kit, SDK) for the respective computing unit.In this case in particular, it is advisable to map several computing units of the same type in the electronic control unit to exactly one virtual sub-processing unit of this type, so that several instances of a simulation module do not have to be operated in parallel (and possibly also purchased and licensed).

[0024] Another development of the method, system and simulator is characterized in that the internal function of the internal functionality of the second computing unit called by the internal functionality of the first computing unit relates to the loading or saving of data from or into the memory area of ​​the second computing unit.

[0025] A preferred embodiment of the method, system, and simulator further provides that the evaluation of the provided internal functionalities of the first processing unit and the second processing unit is carried out based on the binary code of the internal functionalities executable on the electronic control unit and / or based on the high-level source code of the internal functionalities. The evaluation is carried out automatically by a corresponding syntax analysis of the corresponding binary code or the high-level source code.

[0026] In a further preferred embodiment of the method, system and simulator, for a computer-based graphical simulation environment, in particular for a computer-based graphical simulation environment of the simulator, each virtual sub-processing unit is represented as a block, i.e. as a block of a signal flow diagram in block diagram form.

[0027] In connection with the representation of virtual sub-processing units as blocks, a further preferred embodiment of the method, system, and simulator provides that the blocks of the virtual processing units whose processing units have been identified as being connected to each other for data exchange are marked with data transfer ports on the corresponding blocks, with the data transfer being identified by a signal line connecting the data transfer ports of the virtual processing units. This results in an intuitive understanding of the functional relationship between different virtual sub-processing units, as the user is accustomed to from block diagrams.

[0028] The problem is also solved with a computer program that includes instructions that, when the program is executed by a simulator computing unit of a simulator, cause the simulator to execute the previously described method for testing a virtual control unit.

[0029] In detail, there are numerous possibilities for designing and developing the method, system, and simulator according to the invention. Reference is made, on the one hand, to the claims subordinate to the independent claims and, on the other hand, to the following description of exemplary embodiments in conjunction with the drawings. The drawings show: Fig. 1 schematically shows a method, a system and a simulator for testing an electronic control unit as a virtual control unit, wherein each electronic control unit has only one computing unit, Fig. 2 schematically shows the method according to the invention, the system and the simulator for testing an electronic control unit as a virtual control unit, wherein the electronic control unit has several computing units and is automatically mapped onto the virtual control unit in a structure-preserving manner, Fig. 3 schematically shows a complex electronic control unit with different types of computing units, Fig. 4 schematically shows the mapping of the electronic control unit according to Fig. 3 to a virtual control unit and Fig. 5 schematically shows a network of five virtual control units, of which a virtual control unit has several virtual sub-processing units.

[0030] In the Fig. 1 bis 5 In each case, a method 1 for testing at least one electronic control unit 2 as a virtual control unit 3 on a simulator 4 with at least one simulator computing unit 5 is shown, either in its entirety or in various aspects. A corresponding system 4, 6, 7 and a corresponding simulator 4 are depicted similarly and analogously.

[0031] Everything stated below regarding method 1 applies equally and mutatis mutandis to systems 4, 6, 7 and simulator 4.

[0032] Method 1 includes not only the testing of the virtual control unit 3 on the simulator 4, but also the preceding steps to obtain the real, electronic control unit 2 as a virtual control unit 3. The goal is to at least partially test the software of the real, electronic control unit 2 on the simulator 4, which generally has nothing to do with the hardware of the control unit 2; in the simplest case, the simulator 4 can be a PC. However, this is precisely the interesting feature of the test method 1 described here: namely, that the software of the production control unit 2—which may not exist until a much later date—can be tested in advance even without the original hardware of the control unit 2.

[0033] In any case, the electronic control unit 2 has a hardware configuration 6 with a computing unit 6a and an external interface 6b for exchanging data with communication partners outside the control unit 2, and furthermore a software configuration 7 associated with the hardware configuration 6. The hardware configuration 6 and the associated software configuration 7 are thus the hardware and software features of the electronic control unit 2.

[0034] Fig. 1 shows the simple case in which the two illustrated electronic control units 2 each have only a single processing unit 6a. It is indicated that additional control units 2 may be present, as is common, for example, in a control unit network in a motor vehicle. The control units 2 themselves and the components of the control units 2 are each identified by identical reference numerals, which is irrelevant here; the relevant meaning is readily apparent.

[0035] The software configuration 7 comprises an internal functionality 7a and an external interface functionality 7b. The two electronic control units 2 communicate with each other via their respective external interfaces 6b.

[0036] The electronic control unit 2 is mapped to the virtual control unit 3 (dashed lines running from left to right in Fig. 1 ), by adopting the internal functionality 7a of the software configuration 7 of the electronic control unit 2 as the internal functionality 8a of a software configuration 8 of the virtual control unit 3. If the computing unit 6a of the control unit 2 is a microcontroller whose internal functionality 7a, for example a control algorithm, is present in C code, and the simulator computing unit 5 of the simulator 4 is an x86 processor, then it is possible to adopt the C code of the control unit 2 by compiling the C code for the target hardware, i.e., the x86 processor of the simulator 4, whereby the internal functionality 7a of the control unit 2 can actually be tested without changes using the virtual control unit 3.

[0037] Furthermore, the electronic control unit 2 is mapped to the virtual control unit 3 by replacing the external interface functionality 7b of the electronic control unit 2 with a data transfer functionality 9a of a software configuration 10 of the simulator computing unit 5, wherein the software configuration 8 of the virtual control unit 3 is translated into executable code for the simulator computing unit 5 and executed on the simulator 4. In Fig. 1 In the case shown, the external interface functionality 7b of the electronic control unit 2 is the driver functionality of a serial fieldbus according to the CAN (Controller Area Network) standard. This functionality is not transferred to the simulator 4 because its hardware configuration does not have a corresponding feature. Instead, data exchange means available on the simulator 4 are used: this is the data transfer functionality 9a of the software configuration 10 of the simulator processing unit 5, which here involves the use of a shared memory solution, see Fig. 1 right.

[0038] Translating the software configuration 8 of the virtual control unit 3 into executable code for the simulator computing unit 5 and executing the code on the simulator 4 enables testing of the internal functionality 7a of the control unit 2 without the control unit 2 actually being present. The results achieved on the simulator 4 when executing the code can be compared with the expected behavior, thus revealing deficiencies in the internal functionality 7a of the software configuration 7 of the electronic control unit 2—even automatically.

[0039] In Fig. 2 The more complex and primarily interesting case is now shown, where the hardware configuration 6 of the electronic control unit 2 has at least a first computing unit 6a1, a second computing unit 6a2, and also a third computing unit 6a3 of different types; the only important thing is that more than one computing unit is present. This is increasingly the case with modern control unit architectures; the trend is toward concentrating computing capacity on a circuit board, often even on a complex chip, so-called system-on-chip (SoC) solutions. When conducting the test, the user of method 1 for testing a complex electronic control unit 2 also wants to work only with "the" electronic control unit 2, with its outer boundary in the form of the external interface 6b, regardless of how complex the internal structure or the hardware configuration 6 of the electronic control unit 2 is.

[0040] The multiple computing units 6a1, 6a2, 6a3 of the electronic control unit 2 entail that the software configuration 7 of the electronic control unit 2 comprises at least internal functionalities 7a1, 7a2, 7a3 for the first computing unit 6a1 and the second computing unit 6a2 and, of course, also for the third computing unit 6a3, wherein at least the internal functionality 7a1 of the first computing unit 6a1 calls an internal function f_i of the internal functionality 7a2 of the second computing unit 6a2 11. Thus, there is no longer just a data exchange with external communication partners of the control unit 2, but also a data exchange between the multiple computing units 6a1, 6a2 of the control unit 2.

[0041] In the method 1 it is further provided that a description 12 of the hardware configuration 6 and the software configuration 7 of the electronic control unit 2 including the assignment 13 of the internal functionalities 7a1, 7a2, 7a3 of the software configuration 7 of the electronic control unit 2 to the computing units 6a1, 6a2, 6a3 of the electronic control unit 2 is provided 15 and also the internal functionalities 7a1, 7a2, 7a3 of the computing units 6a1, 6a2, 6a3 of the electronic control unit 2 themselves are provided 15.

[0042] Furthermore, the method provides that by evaluating the description 12 of the electronic control unit 2, each computing unit 6a1, 6a2, 6a3 of each type of the electronic control unit 2 with an associated internal functionality 7a1, 7a2, 7a3 is mapped 16 to a virtual sub-processing unit 13.1, 13.2, 13.3 of a corresponding type, wherein the internal functionality 7a1, 7a2, 7a3 of the mapped computing unit 6a1, 6a2, 6a3 of the electronic control unit 2 is transferred into an internal functionality 8a1, 8a2, 8a3 of the virtual sub-processing unit 13.1, 13.2, 13.2 that can be executed on the simulator computing unit 5.

[0043] Finally, by means of evaluation 14 of the provided internal functionalities 7a1, 7a2, 7a3 of the first computing unit 6a1 of the electronic control unit 2 and the second computing unit 6a2 of the electronic control unit 2 - and in the example according to Fig. 2 The third computing unit 6a3 of the electronic control unit 2 also determines which computing units 6a1, 6a1, 6a3 of the electronic control unit 2 are in data exchange with each other by accessing an internal function f_i of another computing unit 6a1, 6a1, 6a3 of the electronic control unit 2. The accesses 11 to internal functions f_i of another computing unit 6a1, 6a1, 6a3 are replaced in the virtual control unit 3 by an (internal) data transfer functionality 9b of the software configuration 7 of the simulator computing unit 5.

[0044] As a result, even in the case of a complex control unit 2, an automated process now produces a corresponding virtual control unit 3 with sub-processing units 13.1, 13.2, 13.3 with an (internal) data transfer functionality 9b of the software configuration 7 of the simulator processing unit 5, the implementation of which, however, does not require the user to actively ensure.

[0045] In Fig. 3 A complex electronic control unit 2 with various types of computing units 6a is shown. In this case, these are processors (CPUs), microcontrollers (µCs), graphics processors (GPUs), programmable logic gates (FPGAs), neural network accelerators (NNAs), and matrix accelerators (MACCs). Furthermore, the control unit 2 has a plurality of external interfaces 6b in the form of Ethernet interfaces (ETHs), which provide a corresponding bandwidth to handle the potentially high data transfer to and from the computing units 6a.

[0046] The Fig. 3 and 4 show a variant of the method 1, in which the electronic control unit 2 according to Fig. 3 is transferred to a corresponding virtual control unit 3. The special feature here is that several computing units 6a of identical type of the electronic control unit 2, i.e. processors (CPU), microcontrollers (µC), graphics processors (GPU), programmable logic gates (FPGA), neural network accelerators (NNA) and matrix accelerators (MACC), are mapped to exactly one virtual sub-processing unit 13.1, 13.2, 13.3, 13.4, 13.5 and 13.6 of this type; in fact, all computing units 6a of identical type of the electronic control unit 2 have been mapped to exactly one virtual sub-processing unit 13 of this type. Fig. 3 shows, using the dashed boxes, which computing units 6a of identical type of the electronic control unit 2 are mapped to which virtual sub-computing units 13.

[0047] Fig. 4 shows the resulting virtual control unit 3. For reasons of clarity, the internal functionalities of the electronic control unit 2 and the internal functionalities of the virtual control unit 3 are not explicitly shown. In Fig. 4 it can be seen which sub-processing units 13.1 and 13.3 as well as 13.1 and 13.4 are exchanging data via (internal) data transfer functionalities 9b.

[0048] Fig. 4 further shows that the transfer of the internal functionality of the depicted computing unit 6a, such as a graphics processor (GPU) and programmable logic gate (FPGA) of the electronic control unit 2, into an internal functionality of the virtual sub-processing unit 13.3, 13.4 that can be executed on the simulator computing unit 5 involves the use of a simulation module 17.1, 17.2 that can be executed on the simulator computing unit 5 for the depicted computing units, such as a graphics processor (GPU) and programmable logic gate (FPGA) of the electronic control unit 2. The code for programming such special chips cannot be readily transferred to a simulator computing unit 5 or implemented using the means of the software configuration 10 of the simulator computing unit 5. The manufacturers of special-type computing units often offer simulators for standard computers that enable the code of the special-type computing units to be executed on these standard computers.Such tools are used here as the simulation modules 17.1, 17.2.

[0049] When carrying out method 1, it may happen that the internal function f_i of the internal functionality 7a2 of the second computing unit 6a2 called by the internal functionality 7a1 of the first computing unit 6a1 relates to the loading or saving of data from or into the memory area of ​​the second computing unit 6a2 (see general Fig. 2 ). If the first processing unit 6a1 is, for example, a processor (CPU) and the second processing unit 6a2 is, for example, an acceleration module (accelerator), of whatever type, then the call could look like this using a pseudocode example: First processing unit 6a1 (CPU): ... / / Announcement of the data to be processed "Source" CopyToAccelerator(Source[]) / / Start the internal function (kernel) on the second processing unit / / (Accelerator) specifying the result location "Target" runAccelerator(Target[], kernel) ... / * Release control * / ... listenOrWaitFor accelerator / / Copy the result from Target for further use in / / first processing unit 6a1 CopyFromAccelerator(Target) Second processing unit 6a2 (Accelerator): / / Function "kernel" on the accelerator function kernel(in ,out): do something with (in) assign result to out

[0050] The instructions used on the first processing unit 6a1, i.e., the CPU, to access the functionality of the second processing unit 6a2 are often provided by a software development environment from the manufacturer of the second processing unit 6a2, in this case, the accelerator. Data exchange between the processing units can, for example, take place via a shared memory to which both processing units 6a1 and 6a2 have access.

[0051] The example of the interaction between different processing units 6a1, 6a2 based on the pseudocode is useful because it makes it clear that method 1 performs the evaluation 14 of the provided internal functionalities 7a1, 7a2, 7a3 of the first processing unit 6a1 and the second processing unit 6a2, as well as the third processing unit 6a3, based on the binary code of the internal functionalities 7a1, 7a2, 7a3 executable on the electronic control unit 2 and / or based on the high-level source code of the internal functionalities 7a1, 7a2, 7a3. In the example shown, the evaluation 14 is performed using an analysis tool that analyzes the source code. This automatic analysis tool has knowledge of corresponding functions that effect a data transfer or a call to internal functionalities 7a1, 7a2, 7a3 in a processing unit 6a1, 6a2, 6a3.In the example above, the analysis tool implementing evaluation 14 must search the source code for, among other things, the commands "CopyToAccelerator" and "runAccelerator".

[0052] Fig. 5 shows that in the method 1 and the simulator 4 it is also provided in particular that for a computer-based graphical simulation environment 21, in particular of the simulator 4, each virtual sub-processing unit 13.1, 13.2, 13.3, 13.4, 13.5 is represented as a block 18, as is known from block diagram representations.

[0053] Fig. 5 shows a network with five virtual control units 3, of which the centrally displayed virtual control unit 3 has several virtual sub-processing units 13.1, 13.2, 13.3, 13.4, 13.5. In Fig. 5 It is also shown that the blocks 18 of the virtual sub-processing units 13.1, 13.2, 13.3, 13.4, 13.5, which virtual sub-processing units 13.1, 13.2, 13.3, 13.4, 13.5 have been recognized as being connected to one another in data exchange, are marked with data transfer ports 19 on the corresponding blocks 18, wherein the data transfer is marked by a signal line 20 connecting the data transfer ports 19 of the virtual sub-processing units 13.1, 13.2, 13.3, 13.4, 13.5. Bezugszeichen

[0054] 1Procedure 2Electronic control unit 3Virtual control unit 4Simulator 5Simulator processing unit 6Hardware configuration of the electronic control unit 6aProcessing unit of the electronic control unit 6a1First processing unit of the electronic control unit 6a2Second processing unit of the electronic control unit 6bExternal interface of the electronic control unit 7Software configuration of the electronic control unit 7aInternal functionality of the software configuration of the electronic control unit 7bExternal interface functionality of the software configuration of the electronic control unit 8Software configuration of the virtual control unit 8aInternal functionalities of the software configuration of the virtual control unit 9a, 9bData transfer functionality (external,internal) of the software configuration of the simulator computing unit 10Software configuration of the simulator computing unit 11Calling an internal function of the internal functionality of the second computing unit 12Description of the hardware configuration and the software configuration of the electronic control unit 13.1, 13.2Virtual sub-computing units of the virtual control unit 14Evaluation of the internal functionalities of the computing units of the electronic control unit 15Provision of the description of the hardware configuration and the software configuration of the electronic control unit 16Mapping of the computing units of the electronic control unit to a virtual computing unit 17Simulation module executable on the simulator computing unit 18Blocks 19Data transfer ports 20Signal lines 21Computer-based graphical simulation environment f_iInternal function of the internal functionality of the second computing unit,

Claims

1. A method (1) for testing at least one electronic control device (2) as a virtual control device (3) on a simulator (4) having at least one simulator computing unit (5), the electronic control device (2) comprising a hardware configuration (6) having at least one computing unit (6a) and an external interface (6b) for exchanging data, and comprising a software configuration (7) associated with the hardware configuration (6), the software configuration (7) comprising an internal functionality (7a) and an external interface functionality (7b), the electronic control device (2) being mapped onto the virtual control device (3) by adopting the internal functionality (7a) of the software configuration (7) of the electronic control device (2) as the internal functionality (8a) of a software configuration (8) of the virtual control device (3) and by replacing the external interface functionality (7b) of the electronic control device (2) with a data transfer functionality (9a) of a software configuration (10) of the simulator computing unit (5), the software configuration (8) of the virtual control device (3) being translated into executable code for the simulator computing unit (5) and executed on the simulator (4), characterized in that the hardware configuration (6) of the electronic control device (2) comprises at least one first computing unit (6a1) and a second computing unit (6a2) of different types, and in that the software configuration (7) of the electronic control device (2) comprises at least internal functionalities (7a1, 7a2) for the first computing unit (6a1) and the second computing unit (6a2), wherein at least the internal functionality (7a1) of the first computing unit (6a1) invokes (11) an internal function (f_i) of the internal functionality (7a2) of the second computing unit (6a2), and in that a description (12) of the hardware configuration (6) and the software configuration (7) of the electronic control device (2), including the association (13) of the internal functionalities (7a1), (7a2) of the software configuration (7) of the electronic control device (2) with the computing units (6a1), (6a2) of the electronic control device (2), and the internal functionalities (7a1, 7a2) of the computing units (6a1, 6a2) of the electronic control device (2) themselves are provided (15), and in that, by evaluating the description (12) of the electronic control device (2), each computing unit (6a1, 6a2) of each type of electronic control device (2) having an associated internal functionality (7a1, 7a2) is mapped (16) onto a virtual sub-computing unit (13.1, 13.2) of a corresponding type, wherein the internal functionality (7a1, 7a2) of the electronic control device (2) of the mapped computing unit (6a1, 6a2) is converted into an internal functionality (8a1, 8a2) of the virtual sub-computing unit (13.1, 13.2) able to be executed on the simulator computing unit (5), and in that the evaluation (14) of the provided internal functionalities (7a1, 7a2) of the first computing unit (6a1) of the electronic control device (2) and of the second computing unit (6a2) of the electronic control device (2) is used to determine which computing units (6a1, 6a2) of the electronic control device (2) are in data exchange with each other by accessing an internal function (f_i) of another computing unit (6a1, 6a2) of the electronic control device (2) and the accesses (11) to internal functions (f_i) of another computing unit (6a1, 6a2) at the virtual control device (3) are replaced by a data transfer functionality (9b) of the software configuration (10) of the simulator computing unit (5).

2. The method (1) according to claim 1, characterized in that different types of computing units (6a1, 6a2, 6a3) of the electronic control device (2) are: processors (CPU), microcontrollers (µC), graphics processors (GPU), programmable logic gates (FPGA), neural network accelerators (NNA), matrix accelerators (MACC), security chips.

3. The method (1) according to claim 1 or 2, characterized in that a plurality of computing units (6a) of identical type of the electronic control device (2) are mapped to exactly one virtual sub-computing unit (13) of this type, in particular all computing units (6a) of identical type of the electronic control device (2) are mapped to exactly one virtual sub-computing unit (13) of this type .

4. The method (1) according to any one of the claims 1 to 3, characterized in that the converting of the internal functionality (8a1, 8a2, 8a3) of the mapped computing unit (6a1, 6a2, 6a3) of the electronic control device (2) into an internal functionality (8a1, 8a2, 8a3) of the virtual sub-computing unit (13.1, 13.2, 13.3) executable on the simulator computing unit (5) comprises the use of a simulation module (17, 17.1, 17.2) executable on the simulator computing unit (5) for the mapped computing unit (6a1, 6a2, 6a3) of the electronic control device (2).

5. The method (1) according to any one of the claims 1 to 4, characterized in that the internal function (f_i) of the internal functionality (7a2) of the second computing unit (6a2) called by the internal functionality (7a1) of the first computing unit (6a1) relates to the loading or saving of data from or to the memory area of the second computing unit (6a2).

6. The method (1) according to any one of the claims 1 to 5, characterized in that the evaluating (14) of the provided internal functionalities (7a1, 7a2) of the first computing unit (6a1) and the second computing unit (6a2) of the electronic control device (2) is performed on the basis of the binary code of the internal functionalities (7a1, 7a2) executable on the electronic control device (2) and / or on the basis of the high-level source code of the internal functionalities (7a1, 7a2).

7. The method (1) according to any one of the claims 1 to 6, characterized in that for a computer-based graphical simulation environment (21), in particular of the simulator (4), each virtual sub-computing unit (13.1, 13.2, 13.3, 13.4, 13.5) is represented as a block (18).

8. The method (1) according to claim 7, characterized in that the blocks (18) of the virtual sub-computing units (13.1, 13.2, 13.3, 13.4, 13.5), said virtual sub-computing units (13.1, 13.2, 13.3, 13.4, 13.5) having been recognized as being connected to each other in data exchange, are identified by means of data transfer ports (19) on the corresponding blocks (18), wherein the data transfer is characterized by a signal line (20) connecting the data transfer ports (19) of the virtual sub-computing units (13.1, 13.2, 13.3, 13.4, 13.5).

9. A system (4, 6, 7) for testing at least one electronic control device (2) as a virtual control device (3) on a simulator (4), the system comprising the simulator (4) as well as a hardware configuration (6) and a software configuration (7) associated with the hardware configuration (6) of the electronic control device (2), the simulator (4) comprising at least one simulator computing unit (5), the hardware configuration (6) of the electronic control device (2) comprising at least one computing unit (6a) and an external interface (6b) for exchanging data, the software configuration (7) comprising an internal functionality (7a) and an external interface functionality (7b), the simulator (4) mapping the electronic control device (2) to the virtual control device (3) by the internal functionality (7a) of the software configuration (7) of the electronic control device (2) being adopted as the internal functionality (8a) of a software configuration (8) of the virtual control device (3) and by replacing the external interface functionality (7b) of the electronic control device (2) with a data transfer functionality (9a) of a software configuration (10) of the simulator computing unit (5), the software configuration (8) of the virtual control device (3) being converted into executable code for the simulator computing unit (5) and executed on the simulator (4) in the operating state of the simulator (4), characterized in that the hardware configuration (6) of the electronic control device (2) comprises at least one first computing unit (6a1) and a second computing unit (6a2) of different types, and in that the software configuration (7) of the electronic control device (2) comprises at least internal functionalities (7a1, 7a2) for the first computing unit (6a1) and the second computing unit (6a2), wherein at least the internal functionality (7a1) of the first computing unit (6a1) invokes (11) an internal function (f_i) of the internal functionality (7a2) of the second computing unit (6a2), and in that the simulator (4) receives (15) a description (12) of the hardware configuration (6) and of the software configuration (7) of the electronic control device (2), including the association (13) of the internal functionalities (7a1), (7a2) of the software configuration (7) of the electronic control device (2) with the computing units (6a1), (6a2) of the electronic control device (2), and the internal functionalities (7a1, 7a2) of the computing units (6a1, 6a2) of the electronic control device (2) themselves, and in that the simulator (4) maps (16) each computing unit (6a1, 6a2) of each type of the electronic control device (2) to an associated internal functionality (7a1, 7a2) on a virtual sub-computing unit (13.1, 13.2) of corresponding type by evaluating the description (12) of the electronic control device (2), wherein the internal functionality (7a1, 7a2) of the electronic control device (2) of the mapped computing unit (6a1, 6a2) is transcribed to an internal functionality (8a1, 8a2) of the virtual sub-computing unit (13.1, 13.2) executable on the simulator computing unit (5), and in that the simulator (4) determines, by evaluating (14) the provided internal functionalities (7a1, 7a2) of the first computing unit (6a1) of the electronic control device (2) and of the second computing unit (6a2) of the electronic control device (2), which computing units (6a1, 6a2) of the electronic control device (2) are in data exchange with each other by accessing an internal function (f_i) of a different computing unit (6a1, 6a2) of the electronic control device (2) and the accesses (11) to internal functions (f_i) of another computing unit (6a1, 6a2) at the virtual control device (3) being replaced by a data transfer functionality (9b) of the software configuration (10) of the simulator computing unit (5).

10. The system (4, 6, 7) according to claim 9, characterized in that the simulator computing unit (5) of the simulator (4) is programmed by means of a program such that, when the program is executed, said computing unit performs the method (1) according to any one of the claims 2 to 8.

11. A simulator (4), corresponding to the simulator (4) of the system (4, 6, 7) according to claims 9 or 10, comprising a simulator computing unit (5) for testing an electronic control device (2) as a virtual control device (3), the simulator (4) comprising a data transfer functionality (9a) and a software configuration (10) of the simulator computing unit (5), the simulator computing unit (5) being programmed by means of a program such that said unit performs the method (1) according to any one of the claims 1 to 8 when the program is executed.

12. A computer program comprising commands causing a simulator computing unit (5) of a simulator (4) to perform the method 1 according to any one of the claims 1 to 8 when the program is executed by said unit.