METHOD AND SIMULATOR FOR TESTING AT LEAST ONE CONTROL UNIT

Description

[0001] The invention relates to a method for testing at least one electronic control unit (ECU), wherein at least two separate networks are maintained on a simulator, in particular on a hardware-in-the-loop (HIL) system with at least one computing unit, preferably a real-time computing unit, or on a software-in-the-loop (SIL) simulation platform, wherein the ECU to be tested is connected to the simulator via a first network and a first ECU interface, e.g., via an Ethernet interface, or is emulated in the simulator as a participant in the first network. In the latter case, the ECU to be tested is a so-called virtual ECU. A virtual ECU is defined as an ECU that exists purely in software but already contains the serial code for the real ECU and of which there are different levels of implementation (https: / / www.dspace.com / de / gmb / home / news / engineers-insights / blog-virtuals-ecus-1808).(cfm#175_43575). In this document, the term "control unit" refers to both real and virtual control units, unless explicitly stated otherwise. When referring to virtual control units, the term "emulation" is generally used instead of "simulation" to distinguish the simulation of virtual control units from the simulation of the communication components of control units, which is also described. In this document, "simulated control units" refers only to software modules that merely simulate the communication components of control units.

[0002] The control unit to be tested is designed to communicate with at least one first additional control unit, wherein the communication of the first additional control unit is at least partially in the form of recorded messages, wherein a playback unit for playing back the recorded messages is connected to the second network or a third network on the simulator by means of at least one playback interface (e.g. another Ethernet interface), wherein the playback unit is connected to the simulator via the playback interface, for example as a separate device - such as a suitable computer with a program for playing back recorded messages such as the RTMaps™ program from Intempora.However, this could also be an internal playback unit for executing the program to play back recorded messages and an internal playback interface in the simulator, or a software-based interface between the playback unit and the simulator or simulation platform.The simulator maintains a queue for messages received in the second and / or third network, and at least parts of the communication between the control unit under test and at least the first other control unit are simulated by means of a simulation model maintained on the simulator and executed on at least one computing unit of the simulator, wherein at least parts of the communication of the control unit under test are simulated in the second network by means of a first software module of the simulation model, and wherein, in the first network on the simulator, the other control units communicating with the control unit under test are simulated as communication partners for the control unit under test by means of at least one further software module of the simulation model.

[0003] The invention also relates to a simulator for carrying out the method according to the invention.

[0004] A similar method for testing control units using a simulator is described in German patent application number 102020134185.7, in which a hardware-in-the-loop (HIL) simulator is connected between the control unit under test and other control units, and the HIL simulator forwards the messages it receives from the other control units to the control unit under test. Separate networks are maintained on the HIL simulator, and the communication between the communication partners connected to the other network is simulated for each of the control units connected to one network.

[0005] A playback unit for storing and playing back recorded messages is described, for example, in WO2020165067. This playback unit could be, for instance, a device for recording and playing back messages in a vehicle network, such as the one offered by dSPACE GmbH (https: / / www.dspace.com / de / gmb / home / products / hw / autera.cfm), but a playback unit could also be integrated into a simulator.

[0006] In general, US 2017 / 0220712 A1 describes a method for simulating, in the simplest possible way, other control units that are not physically present for testing a real or virtual control unit. For this purpose, these so-called residual bus control units are combined into a single, common residual bus control unit model, and common interfaces are generated.

[0007] The purpose of the invention is to advance the state of the art.

[0008] The task is accomplished by controlling the playback of messages recorded and transmitted from the playback unit to the simulator via the playback interface (e.g., also via the simulator's internal playback interface to the simulator's processing unit) using a playback code stored on the simulator. A command to start playback causes the recorded messages received by the simulator from the playback unit to be added to the queue and written to a message buffer. These messages are then passed to the control unit under test upon a trigger command from the simulation model. The simulation model, in this context, refers to the program running on the simulator that simulates the temporal sequences, messages, signals, and / or events required for testing the control unit under test, or initiates their transmission.

[0009] The advantage of the solution according to the invention is that the messages from the playback unit in the simulator (preferably provided by a HIL simulator or a suitable PC or a PC- or cloud-based SIL simulation platform such as VEOS® from dSPACE) are received in a separate network, namely the second or third network, which is separate from the first network to which the control unit under test is connected. By "network" here, it means that the communication participants in the respective network (real, virtual, and merely simulated control units) each have a unique identification (ID) and are essentially only directly connected to, or can only send messages to, the participants in their network. These networks can be real networks or virtual networks with virtual interfaces.

[0010] In the first network, parts of the communication between the other control units are simulated; in particular, expected messages for the control unit under test are generated. The content of such a message, or the message itself, is then extracted from the message buffer, and if necessary, the message and / or its content are manipulated before being forwarded to the control unit under test. The separation of the input and output networks enables such manipulation of the messages in the message buffer before transmission. For transmission, the messages are transferred to a send queue or a send buffer for the first control unit interface, and from there, via the first control unit interface, to the control unit under test.

[0011] Messages recorded in a vehicle can contain timestamps and security measures (e.g., a Message Authentication Code (MAC)) and / or be encrypted. Due to the time information verification and security measures typically implemented in control units, the control unit under test would immediately recognize that a message is outdated and discard it if it were simply forwarded. If a message is encrypted, the data would be unreadable if the encryption depends on a current timestamp. The invention is defined by the subject matter of the independent claims.

[0012] By using separate networks according to the invention, a recorded message sent by the playback unit can first be properly received by the first software module in the second network. All security measures are checked and all decryptions are performed correctly if the simulated control unit under test (i.e., the first software module) has the correct key material. The message contents are then readable, can be processed, and can also be modified (e.g., a timestamp can be updated) and are thus forwarded to the first network. There, the second software module re-secures and re-encrypts the manipulated data / messages and then sends them to the control unit under test.Since backups and encryption are also performed using the original keys, the control unit being tested cannot detect the manipulation and processes the received messages as if they had come from another real control unit.

[0013] In a further embodiment, the setup with separate networks allows at least one additional control unit interface to be provided on the simulator, with which the first additional control unit and / or a second additional real or virtual control unit is connected to the second network, wherein in the second network, by means of a further software module of the simulation model, the control unit to be tested is simulated as a communication partner for at least the first additional control unit, wherein messages received via the additional control unit interfaces from the first and / or the second additional control unit are placed in the queue and from there written to the message buffer.

[0014] Thus, the simulator preferably maintains a single queue for all messages received in the second and / or third network (an input network), i.e., for all messages, regardless of whether they are recorded messages from the playback unit or current messages from a real or virtually connected control unit.

[0015] The separate networks are particularly advantageous in this case because they allow a control unit simulated by a software module in one network to have the same IP address as the real or virtual control unit in the other network. The simulator is therefore completely transparent to the real and virtual control units; that is, the real and emulated control units appear to be communicating directly with each other. This allows messages to be manipulated "undetected" for testing purposes.

[0016] A further advantage of being able to connect real control units to the simulator and / or emulate additional virtual control units in the simulator and include them in the simulation is that the control units can be tested together. This situation is generally present with a HIL or SIL simulator, but in combination with the playback unit according to the invention on the simulator, it is possible to replace parts of the communication of the real or virtual control unit with recorded messages and vice versa.

[0017] Preferably, the messages have a label, wherein the message buffer on the simulator is set up such that a dedicated message buffer is provided for at least one predetermined message label, wherein each of the dedicated message buffers is set up to hold a certain number of messages with the corresponding label.

[0018] The messages in question are, for example, messages from an automotive system, such as CAN, FlexRay, or Ethernet messages. These messages might consist of an Ethernet frame, and the recorded messages also contain a timestamp assigned by the playback unit or upon reception at the simulator. This timestamp is then removed before playback to the control unit under test. This timestamp, assigned by the simulator or playback unit, is appended to the received messages in addition to any timestamps already present in the recorded messages.

[0019] The simulator is configured before the ECU test. The configuration specifies (e.g., in a database that the simulation model accesses during the simulation) which messages should be forwarded from the input side (here, the second network) to the output side (here, the first network), i.e., the ECU under test. Furthermore, the configuration allows you to specify which messages should have recorded playback. This is done by identifying the messages based on the socket information (which IP ports the message is sent over) and, if applicable, the message header information, i.e., the corresponding Protocol Data Unit (PDU), if the PDU has a header. Preferably, messages are assigned an index for each PDU.For each message (PDU) configured for forwarding, a dedicated message buffer is created during the initialization phase of the simulation model, which is set up to hold a specific number of PDUs of the corresponding identifier, for example four.

[0020] The ability to activate (start playback) and deactivate (end playback) recorded messages during the simulation runtime is highly desirable, especially for individual selected messages. This allows switching between forwarding recorded messages and forwarding messages from other control units.

[0021] In another embodiment, the simulation model includes a residual bus simulation, wherein messages from other control units are simulated in the residual bus simulation and wherein these simulated messages are written directly into a send buffer for transfer to the control unit under test, or wherein simulated messages with a specific identifier are written into the dedicated message buffer for messages with the corresponding identifier.

[0022] Such a residual bus simulation is typically performed on a HIL or SIL simulator, for example, when control units from the network of the control unit under test are not physically present or not yet available as virtual control units, but their communication is required for the test. An advantage here is that the residual bus simulation can be combined with the playback of recorded messages, allowing messages not included in the recordings to be added. It is also possible to replace incoming messages from the second or third network with messages from the residual bus simulation by overwriting the messages from the other control units or from the playback unit in the message buffer or even in the send buffer. The send buffer here refers to the buffer memory associated with the first interface.The residual bus simulation is preferably performed in the first network, so that the messages generated there can be written directly to the send buffer.

[0023] Preferably, the simulator is configured using the playback code to provide messages with meta-information before they are added to the queue, the meta-information indicating whether the message is a recorded message from the playback unit.

[0024] This metadata makes it possible to distinguish messages in the queue as to whether they originate from the playback unit or from one of the connected control units. Ideally, incoming messages from these other control units are also tagged with metadata indicating that they do not originate from the playback unit.

[0025] In a further development of the invention, from the start of playback of the recorded messages, when messages are transferred from the queue to the message buffer, the meta-information of the messages is queried and, based on the meta-information of the messages in the queue, those messages that were sent by the first additional control unit and / or the second additional control unit are discarded. Recorded messages from the playback unit are added to the queue, written to the message buffer, and transferred to the control unit under test according to the timing of the simulation model.

[0026] This mechanism allows for the expansion of the control unit testing. A hardware-in-the-loop (HIL) test setup with additional control units connected to a simulator enables testing the interaction of the control units using the actual hardware. However, such a laboratory setup cannot replicate arbitrary test drives. The inventive method allows for the simulation of complex driving maneuvers.

[0027] According to the invention, the transfer of messages from the second network to the first network is accomplished either by parsing the messages in the second network and subsequently passing parameters to the first network using a suitable program, or by storing the messages in a common memory area, in particular in the message buffer, wherein the message buffer is accessible from the first network, the second network, and / or the third network. The latter method minimizes resource consumption, as it avoids the need to copy the parameters.

[0028] The aforementioned software modules of the simulation model simulate real ECUs insofar as they replicate the communication components of an ECU, particularly service messages or signal transmission messages. For example, a request message from one of the other ECUs in the second network is received, and a corresponding response message is created and sent by the first software module, which simulates the ECU under test. The request message is forwarded to the ECU under test by passing it into the first network via the message buffer or by parsing, and from there it is transmitted to the ECU under test via the first ECU interface. Similarly, the response message is forwarded from the ECU under test to the corresponding other ECU. Other messages are event-driven. If a corresponding event occurs, e.g.,In the simulation of the simulation model, corresponding messages are generated by the software modules and sent by the simulator.

[0029] In another embodiment, recorded messages, which are service messages for service-based communication and are response messages, are held in the message buffer until a corresponding request message is received from the control unit under test. The header of the response message is then manipulated for transmission to the control unit under test in such a way that it is accepted by the control unit.

[0030] For example, the timestamp, the message authentication code (MAC), and / or a counter value are adjusted accordingly. This allows a message that would not normally be accepted by the control unit under test—for instance, because the counter value and a counter generated from the current counter value are not up-to-date—to be manipulated by the simulator, using the current counter value and appropriate encryption algorithms, so that it is accepted by the control unit under test.

[0031] Preferably, in the simulator, when each recorded message is received by the playback unit, it is checked whether it is a Service Discovery message, and in the case of a Service Discovery message, it is checked what reception status the message has for the corresponding service.

[0032] If multiple control units are connected to both the first and second networks (i.e., if at least one other control unit is connected to the network of the control unit under test), it is advantageous to extend the simulator configuration so that messages intended to be transmitted from, for example, a control unit connected to the second network to multiple control units on the first network are only forwarded via a simulated control unit. This means that messages sent from the first additional control unit to more than one control unit simulated by a software module are only forwarded by a dedicated software module, i.e., only written to the dedicated message buffer for the messages of this simulated control unit, in order to avoid duplicate transmission of the same messages.If the simulated control unit intended for forwarding is deregistered from the service in the recorded messages, forwarding to the other control units in the first network is no longer possible. By checking the service's reception status, timely configuration to an active control unit can be performed.

[0033] In a further development of the invention, the header of each received recorded message is checked, and if a timestamp is present, this recorded message is only played back when the simulation time in the simulator is greater than or equal to the time given by the timestamp, or alternatively, the recorded message is only played back when the difference to the timestamp of a previously received recorded message is greater than or equal to the time that has elapsed since the playback of the previously received recorded message.

[0034] This ensures that the recorded messages are played back at the correct time intervals.

[0035] In an alternative embodiment of the invention, the playback unit is connected to the third network via the playback interface, and the first additional control unit and / or the second additional control unit are connected to the second network via the additional control unit interface. This enables a clean separation of additional control units and the playback unit, as well as easy switching between receiving recorded messages and receiving current messages from a real or virtual control unit.

[0036] The problem is also solved by a simulator that is set up to carry out the method according to the invention.

[0037] The invention is explained in more detail below with reference to the drawings illustrating exemplary embodiments.

[0038] To illustrate the description, the figures show: Figure 1a: A schematic representation of the simulator according to the invention for carrying out the method for testing a control unit using a HIL system. Figure 1b: A schematic representation of the simulator according to the invention for carrying out the method for testing a control unit using a SIL system. Figure 2: A schematic representation of the simulator according to the invention for carrying out the method for testing one or more control units. Figure 3: A flowchart for the process of the method according to the invention.

[0039] Figure 1aFigure 1 shows a HIL simulator according to the invention, comprising a first network Stack1 (output side) and a second network Stack2 (input side). The control unit ECU1 under test is connected to the simulator HIL via its first control unit interface S1 and its Ethernet interface ETH. On the input side, a first additional control unit ECU2 and a second additional control unit ECU3 are connected to the second network Stack2 via the additional control unit interfaces S2 and S3 of the simulator HIL (the Ethernet interfaces on the additional control units ECU2 and ECU3 are not shown here). Furthermore, a playback unit RS is connected to the second network Stack2 via its playback interface SW. The purpose of this simulator is to test the communicative interaction between the control units, which in a real system would actually be connected in a control unit cluster.For testing purposes, the HIL simulator is interposed to allow manipulation of messages from the other control units ECU2 and ECU3. To simulate direct communication between the real control units and their intended partners, these partners are simulated within the respective network. This means that all expected messages and responses (reply messages, acknowledgments, etc.) are generated in the simulation or taken from the other network and sent to the real control units. The control unit under test, ECU1, is simulated in the second network, Stack2, using the first software module, ECU1'. The other control units, ECU2 and ECU3, are simulated in the first network, Stack1, using the additional software modules ECU2' and ECU1'.

[0040] All messages received via the other control unit interfaces S2 and S3 are placed in a queue Q, essentially a receive queue. From this queue Q, those messages configured to be forwarded to the control unit under test are written to a message buffer (not shown), which can be accessed from both the first network, Stack1, and the second network, Stack2.

[0041] The playback unit RS stores recorded messages, for example, from the recording of communication traffic during a test drive in a car equipped with the corresponding control units ECU1, ECU2, and ECU3. To enable the inclusion of messages from such a test drive in the test simulation, a playback code RA is stored in the second network, Stack2, which controls the playback of the recorded messages. The playback start time is determined in the configuration or by a user command, such as input via a graphical user interface (GUI). From this start time, messages received by the HIL simulator via the SW playback interface are added to the queue Q. In the HIL simulator, the recorded messages are tagged with metadata to identify them as messages from the playback unit RS.From the start of playback, only those messages from queue Q that, according to their meta-information, originate from the playback unit RS are written to the message buffer for forwarding to the first network, Stack1. Messages received from the connected control units during this time are discarded from queue Q. In the first network, Stack1, the data required for the messages expected by the control unit ECU1 under test is extracted from the message buffer, packaged as suitable messages (i.e., possibly manipulated), and sent to the control unit ECU1 via the first control unit interface, S1.

[0042] Figure 1bThis diagram shows the analog test setup for a SIL simulator S. The simulator can be implemented on a single PC, in a PC cluster, or in the cloud. Here, virtual ECUs VECU1, VECU2, and VECU3 are used for testing instead of real ones. All virtual ECUs VECU1, VECU2, and VECU3 are executed within the simulator, i.e., on a suitable simulation platform. Two separate networks, Stack1 and Stack2, are used to manipulate the communication between the virtual ECUs VECU1, VECU2, and VECU3. The virtual ECUs VECU1, VECU2, and VECU3 are integrated into the respective Stack1 and Stack2 networks via virtual interfaces VETH, VS1, VS2, and VS3, respectively, using virtual buses that simulate the behavior (timing, message triggering, etc.) of real buses.The participants not present as virtual control units in the respective network are also replaced in the communication simulation by software modules ECU1', ECU2' and ECU3', which send the expected or to be received messages to the virtual control units VECU1, VECU2, VEUC3 in their respective network Stack1, Stack2.

[0043] The RS playback unit is in Fig. 1b A software program for playing back recorded messages is provided and connected to the simulator via a VSW software interface, thus integrating it into the simulation. This software program is then implemented, for example, as another program on the PC, in the PC cluster, or in the cloud, where the simulator is also hosted. Integrating the playback of recorded messages works in the same way as... Fig. 1a is described.

[0044] Furthermore, it is also possible to simulate virtual control units VECU1, VECU2, and VECU3 on a HIL simulator, for example, if the control unit ECU1 to be tested already exists physically, but not all communication partners ECU2 and ECU3 have yet been physically implemented. In this case, the first additional control unit ECU2 could be physically connected to the simulator HIL, while a second additional control unit ECU3 could be emulated in the HIL simulator as a virtual control unit VECU3.

[0045] Another hybrid scenario would be to connect the control unit ECU1 under test to a real-time capable PC, on which the other communication partners are simulated as virtual control units VECU2 and VECU3 in a simulator S. Alternatively, a virtual control unit VECU1 under test could be tested with real communication partners ECU2 and ECU3.

[0046] Figure 2 shows an expansion of the situation in Figure 1a, which also applies to the test setup for a SIL simulator in Figure 1bThis is applicable. Here, another control unit, ECU4, is also connected to the second network, Stack1. If the control units ECU1 and ECU4, connected to the first network, Stack1, have both subscribed to a service from the first additional control unit, ECU2, then it is advantageous in the simulation to forward the messages from this service to the first network, Stack1, only once and only via a dedicated message buffer in the second network, Stack2 (software modules ECU1' and ECU4'), to avoid message duplication. For example, messages intended for ECU4' are also written to the dedicated message buffer for messages from this service to ECU1'. For playback of recorded messages, the system checks whether the control unit ECU1, through which the message forwarding for this service takes place, has unsubscribed from the service during recording.If this is the case, the configuration will be changed so that the redirection still takes place.

[0047] Figure 3Figure 1 shows a flowchart illustrating the process according to the invention. It depicts the path of messages during forwarding from the second network, Stack2, to the first network, Stack1. Messages from the other control units, ECU2 and ECU3, are received at one of interfaces S2 or S3. Recorded messages from the playback unit, RS, are received at the playback interface, SW. Upon receipt at interfaces S2, S3, and SW, the socket information of the messages is first checked. Based on this information and any additional information related to the corresponding PDU, a PDU ID is assigned. A timestamp is also assigned, and metadata is appended to the messages, indicating whether the messages originate from the playback unit, RS.The received messages are then placed in queue Q, regardless of which of the aforementioned interfaces they were received on. From queue Q, messages are written to a dedicated message buffer (PDU buffer) for forwarding to the first network, Stack1. The message identifier (PDU-ID) is checked beforehand. If the PDU-ID is configured for forwarding in the simulation settings, a corresponding dedicated message buffer is maintained. If playback mode is active, only recorded messages from the playback interface (SW) are written to the message buffer; messages from the other control units (ECU2 and ECU3) are discarded. Otherwise, the HIL simulator may be configured to only include messages from the other control units (ECU2 and ECU3) in the message buffer.During its execution on the simulator, the simulation model triggers the sending of the message to the control unit ECU1 under test by transferring the messages from the message buffer to the sending buffer for the first control unit interface S1 in response to a corresponding trigger command.

Claims

1. Method for testing at least one control unit (ECU1), at least two separate networks (Stack1, Stack2) being provided on a simulator (HIL, S), the control unit to be tested (ECU 1, VECU 1) is connected to the simulator (HIL) via a first network (Stack1) and a first control unit interface (S1) or is emulated in the simulator (S) as a participant in the first network (Stack1), the control unit to be tested (ECU1, VECU1) being intended to communicate with at least one first further control unit (ECU2, VECU2), wherein the communication of the first further control unit (ECU2, VECU2) is at least partly in the form of recorded messages, wherein a playback unit (RS) for playing back the recorded messages is connected to the second network (Stack2) or a third network on the simulator (HIL, S) by means of at least one playback interface (SW, VSW), wherein a queue (Q) for messages received in the second and / or the third network is provided on the simulator (HIL, S), and wherein the method comprises the steps of - simulating at least parts of the communication of the control unit under test with at least the first further control unit (ECU2, VECU2) by means of a simulation model provided on the simulator (HIL, S), wherein in the second network (Stack2) by means of a first software module (ECU1') of the simulation model at least parts of the communication of the control unit to be tested (ECU1, VECU1) are simulated, and wherein on the simulator (HIL, S) in the first network (Stack1) the further control units (ECU2, ECU3, VECU2, VECU3) communicating with the control unit to be tested (ECU1, VECU1) are simulated as communication partners for the control unit to be tested (ECU1, VECU) by means of at least one further software module (ECU2', ECU3') of the simulation model, - controlling by means of a playback code (RA) held on the simulator (HIL, S) the playback of the recorded messages, which are transmitted by the playback unit (RS) to the simulator (HIL, S) and received there, wherein a command to start playback having the effect that the recorded messages which the simulator receives from the playback unit (RS) are added to the queue (Q) and written from there into a message buffer in order to be transferred to the control unit to be tested (ECU1) in response to a trigger command from the simulation model.

2. Method according to claim 1, wherein at least one further control unit interface (S2, S3, VS2, VS3) is provided on the simulator (HIL) or in the simulator (S), with which the first further control unit (ECU2, VECU2) and / or a second further control unit (ECU3, VECU3) is connected to the second network (Stack2), wherein in the second network (Stack2) by means of the first software module (ECU1') of the simulation model the control unit to be tested (ECU1, VECU 1) is simulated as a communication partner at least for the first further control unit (ECU2, VECU2), incoming messages from the first and / or the second further control unit (ECU2, VECU2) being received in the queue (Q) via the further control unit interfaces (S2, S3) and written from there to the message buffer.

3. Method according to claim 1 or 2, wherein the messages have an identification (ID), wherein the message buffer is set up on the simulator (HIL, S) in such a way that a dedicated message buffer is provided for at least one predetermined message identification in each case, wherein each of the dedicated message buffers is set up to hold a specific number of messages with the corresponding identification.

4. Method according to claim 3, wherein the simulation model has a residual bus simulation, wherein messages are simulated in the residual bus simulation and wherein these simulated messages are written directly into a send buffer for transfer to the control unit to be tested (ECU1) or wherein simulated messages with a specific identification are written into the dedicated message buffer for messages with the corresponding identification.

5. Method according to one of the preceding claims, wherein the simulator is set up to provide messages with meta information before inclusion in the queue (Q), wherein the meta information provides information as to whether the message is a recorded message from the playback unit (RS).

6. Method according to claim 5, wherein from the start of the playback of the recorded messages, when messages are transferred from the queue (Q) to the message buffer, the meta information of the messages is interrogated and, according to the meta information on the messages in the queue (Q), those messages sent by the first further control unit (ECU2, VECU2) and / or the second further control unit (ECU3, VECU3) are discarded and only the recorded messages from the playback unit (RS) are written to the message buffer and transferred to the control unit to be tested (ECU1, VECU1).

7. Method according to one of the preceding claims, wherein the transfer of the messages from the second network (Stack2) to the first network (Stack1) takes place either by parsing the messages in the second network (Stack2) and a subsequent parameter transfer by means of a suitable program or by storing the messages in a common memory area, in particular in the message buffer, wherein the message buffer can be accessed both from the first network (Stack1) and from the second network (Stack2) and / or the third network.

8. Method according to one of the preceding claims, wherein the software modules (ECU1 ', ECU2', ECU3', ECU4') simulate real control units in that they simulate the communication components of a control unit (ECU1, ECU2, ECU3), in particular service messages or messages for signal transmission.

9. Method according to one of the preceding claims, wherein recorded messages, which are service messages, namely response messages, are retained until a corresponding request message is received from the control unit to be tested (ECU 1) and wherein the header of the response message for transfer to the control unit to be tested (ECU1, VECU1) is manipulated in such a way that it is accepted by the control unit to be tested (ECU 1, VECU1).

10. Method according to one of the preceding claims, wherein in the simulator (HIL, S), on receipt of each recorded message from the playback unit (RS), it is checked whether it is a service discovery message and, in the case of a service discovery message, it is checked which reception status the message has for the corresponding service.

11. Method according to one of the preceding claims, wherein the header of each received recorded message is checked and wherein, if a time stamp is present, the recorded message is not played until the simulation time in the simulator (HIL, S) is greater than or equal to the time given by the time stamp, or the recorded message is not played until the difference from the time stamp of a previously received recorded message is greater than or equal to the time that has elapsed since the previously received recorded message was played.

12. Method according to one of the preceding claims, wherein the playback unit (RS) is connected to the third network via the playback interface (SW, VSW) and the first further control unit (ECU2, VECU2) and / or the second further control unit (ECU3, VECU3) are connected to the second network (Stack2) via the further control unit interface (S2).

13. Simulator (HIL, S), which is set up to carry out the method according to one of the preceding claims.