Method and test system for forwarding Ethernet messages

Abstract

The invention relates to a method for transmitting and processing messages of a first and a second control device by means of a test system, the test system having: a first controller and a first TCP / IP stack for messages of the first control device and a second controller and a second TCP / IP stack for messages of the second control device; a message memory for exchanging messages with the first TCP / IP stack and the second TCP / IP stack, in which messages from the first TCP / IP stack are transmitted to the message memory and forwarded to the second TCP / IP stack and vice versa, the messages being selectable by means of a first program for processing for test purposes before forwarding, and a second program for processing for test purposes before forwarding. The messages selected for processing are forwarded by the first or second controller to the respective first or second TCP / IP stack and stored therefrom in the message memory and processed, with the test system having a filter program by means of which unselected messages are transmitted directly from the first controller to the second controller or vice versa.

Description

Technical Field

[0001] The present invention relates to a method for transmitting and processing messages exchanged between first and second control devices via a test system. Background Technology

[0002] Such a method or test system is used, for example, for hardware-in-the-loop (HIL) testing when it is necessary to test the communication between two control units, such as in the automotive field.

[0003] The test system is connected to a first control device via a first port and to a source and / or destination for messages to be sent and / or received by a second control device via a second port. The test system has a first controller and a first TCP / IP stack for messages to the first control device, and a second controller and a second TCP / IP stack for messages to the second control device, as well as a message store for exchanging messages with the first and second TCP / IP stacks. In the test system, messages from the first TCP / IP stack are transferred to the message store and forwarded to the second TCP / IP stack, and vice versa; that is, communication can also be bidirectional. Here, a first program can be used to select messages—for example, through user input regarding IP addresses, port numbers, or elements from an AUTOSAR description file—for processing for testing purposes before forwarding. Such a first program is provided, for example, by an Ethernet configuration package from dSPACE GmbH. This tool is also responsible for message forwarding, appropriate configuration of communication for testing, and message processing. The first program is stored on the test system or on a personal computer connected to the test system for configuration purposes. It can also consist of multiple programs or modules. Using the first program, an application, or executable application, is generated to execute test methods on the test system.

[0004] DE102021125399A1 illustrates a method and a test system in which a hardware-in-the-loop (HIL) simulator is connected as a test system between communication participants.

[0005] The communication participant can be a control device directly, but it can also be a source and / or destination of messages used to control the device, such as a replay system that plays previously recorded messages.

[0006] In the DE102021125399A1 test system, a message from a control device is forwarded by either the first or second controller to the corresponding first or second TCP / IP stack (depending on the port the message enters at), and from there stored in a message memory so that it can either be forwarded directly to the corresponding other TCP / IP stack or processed beforehand. All messages are then forwarded to the corresponding other controller.

[0007] By testing this process in the system, a lot of time is wasted in communication between the participants. Summary of the Invention

[0008] The objective of this invention is to further improve upon existing technologies.

[0009] According to the method of the present invention, the test system has a filtering procedure implemented by parameterizable filtering code, by means of which messages not selected for processing are directly transmitted from the first controller to the second controller or vice versa. In this case, the method can also be executed bidirectionally.

[0010] The filter receives unselected message packets at the driver level of the message controller (e.g., Ethernet controller) and then forwards them to the TCP / IP stack. The filter can be implemented, for example, as a mechanism within the kernel of a test system.

[0011] When messages do not need to be routed through the TCP / IP stack and drivers, the system experiences a significant performance improvement in message delivery.

[0012] In a preferred embodiment, for filtering, the receiving port number, the IP address of the sender and / or receiver of the message to be processed, or a description of elements related to the message to be processed from the AUTOSAR description file are used. In particular, parameterizable filtering code provides the possibility of receiving these parameters at runtime. This enables the transmission of filtering parameters after service discovery, i.e., at runtime, in service-based communication. These parameters can be transmitted to the filtering program by the first program or by the user via a user interface or via a file.

[0013] In one implementation, the filter is implemented in hardware. This allows for even faster execution of the filtering process. In this case, the first and second controllers are implemented together with the filter on a common programmable network card. To implement it in hardware, parameterizable filter code (typically functionally or semantically restricted C code, where pointers cannot be used) is translated into simple bytecode that the network card can directly execute.

[0014] In another implementation, a filtering procedure examines the protocol fields of Ethernet messages received from the first controller at the second layer (data link layer in the OSI model) using a filter at the third layer (network layer in the OSI model) and / or the fourth layer (transport layer in the OSI model) to determine whether to forward the message directly to the second controller. The same applies to the opposite communication direction.

[0015] In one implementation, the XDP (Fast Data Path) path is used for message filtering. The XDP path is used in conjunction with a so-called Extended Berkeley Packet Filter (eBPF). The functionality of the eBPF program is, for example, integrated into the kernel of the Linux operating system as a standard. This operating system can also be used for testing. The XDP filter is an early so-called "hook" in the kernel's receive path. It resides in the network interface controller (NIC) driver, immediately after interrupt handling and memory allocation for the stack.

[0016] In another implementation, these messages are Ethernet messages used for service-based communication. Then, preferably at runtime, after the so-called service discovery phase, the filter is parameterized during message exchange to determine which participants exchange which messages. The filter is then parameterized by passing the current port number and IP address used for the messages as parameters.

[0017] The filtering code used for XDP filters is written as program code, typically in C. It is then compiled into an eBPF program, loaded into the kernel, and activated so that it can be used there. Activation is achieved via a "software switch," that is, a setting in software that causes the filter program to not only be loaded but also executed during test runs. Such a software switch can also be used when the filter is implemented in hardware.

[0018] According to the present invention, in the filtering code, filtering criteria such as port numbers (which are only known after service discovery) appear only as parameters and can therefore be passed only at runtime (especially after service discovery). Thus, it is not necessary to inform the filtering program of these parameters before simulation.

[0019] Preferably, multiple filter settings can be set simultaneously or multiple filter settings can be combined. This allows for the examination of more complex conditions.

[0020] In one implementation, the filter is parameterized via a graphical user interface to configure the selection of messages to be processed. In this implementation, filter parameters such as port numbers, IP addresses, or IDs are entered by the user into the graphical user interface or selected from a list of choices. In the background, pre-prepared code snippets are combined to generate the filter code, without requiring the user to write any code.

[0021] A graphical user interface can also be constructed as part of the first program.

[0022] In another embodiment, a first switch device is connected between the first control device and the first port, and thus the first control device is connected to the test system via the first switch device, which is connected to the first controller. Here, a third control device is also connected to the test system via the first switch device and the first port, and messages from the first controller and the second control device are sent to and / or received by the test system and forwarded to the second control device, and processed if necessary beforehand. Messages not selected for processing are forwarded directly from the first controller to the second controller via a filtering procedure, or vice versa (depending on the communication direction).

[0023] Therefore, the method according to the invention is not limited to testing communication between two control devices, but can be extended to a greater number of control devices. Messages from the second control device—entering at the second port and thus at the second controller and guided by the test system—are sent by the first controller to the first switch device, which then forwards the message to either the first or third control device based on the message's destination. In principle, the entire network of control devices can be connected to the switch device.

[0024] In one implementation, the source and / or destination (i.e., the messages to be sent and / or received) of messages for the second control device are provided by the second control device itself or by a TAP (Test Access Point), another switching device, or another message storage device (i.e., by a reproduction system or so-called playback system, where previously recorded stored messages are played back). In this way, if the test system is connected between the two control devices, direct communication between the two control devices can be tested, or how one control device reacts to stored messages from previous communications can be tested. Messages for the second control device can also be extracted from the second control device via the TAP and sent to the first control device through the test system, or messages for the second control device can be received at the TAP and forwarded to the second control device. It is also possible that the test system is connected to a network of multiple control devices via another switching device, which send messages to and receive messages from the first control device.

[0025] As mentioned earlier, the first control device can also be indirectly connected to the test system via the first port through the first switch device, where other control devices can also be connected to the first switch device. This enables the testing and processing of communication between the two networks.

[0026] Whether the first control device is connected to the test system indirectly or directly is usually not clearly distinguished here.

[0027] This task is also addressed by a test system configured to execute the method according to the invention. The test system includes a computing unit, a first port, a first controller and a first TCP / IP stack for messages from a first control device, a second port, a second controller and a second TCP / IP stack for messages from a second control device, and a message store for exchanging messages with the first and second TCP / IP stacks. Furthermore, the test system has a first program configured to transmit messages from the first TCP / IP stack to the message store and forward them to the second TCP / IP stack, and vice versa. The test system also has a first program configured to receive selection criteria for messages so as to process selected messages before forwarding. The test system has a filtering program implemented by parameterizable filtering code, wherein the test system is configured to transmit messages not selected for processing directly from the first controller to the second controller, or vice versa, by means of the filtering program. The filtering program may consist of multiple programs.

[0028] In this way, messages do not have to go through the long and time-consuming path via the TCP / IP stack and message store. Attached Figure Description

[0029] The present invention will now be described in more detail with reference to the accompanying drawings, in which:

[0030] Figure 1 A schematic diagram of a test system connected between two control devices is shown;

[0031] Figure 2 A schematic diagram illustrating the path of a message through a testing system in the prior art is shown;

[0032] Figure 3 A schematic diagram showing the path of a message through the test system according to the present invention is shown;

[0033] Figure 4a -b illustrates a schematic diagram of the message path through the test system according to the invention, wherein control devices are connected to the test system in different configurations;

[0034] Figure 5 A schematic diagram of the message path through the test system according to the present invention is shown, wherein the filtering procedure is implemented in the hardware layer. Detailed Implementation

[0035] Figure 1 The diagram illustrates a test system (HIL) that receives messages from a first control unit ECU A, stores them in an Rx / Tx message memory, processes them using a first program, and then sends the messages to a second control unit ECU B. To be transparent to the control unit, the test system (HIL) acts as a simulated second control unit ECU B' receiving messages from the first control unit ECU A. The first control unit ECU A cannot distinguish the simulated second control unit from the real second control unit ECU B because all reactions, names, and identifiers are precisely mimicked. Similarly, when further sending messages to the second control unit ECU B, the first control unit ECU A is mimicked by a simulated control unit ECU A', giving the second control unit ECU B the impression that it receives messages directly from the first control unit ECU A. With appropriate adjustments, communication proceeds in the opposite direction through the test system (HIL) when messages are sent from the second control unit ECU B to the first control unit ECU A and received there. Only one direction is depicted throughout the following diagrams.

[0036] Figure 2 The diagram schematically illustrates the path of a message through the testing system (HIL).

[0037] First, messages from the first control unit ECU A are received at the hardware level by the first network interface controller NIC A. At the kernel level, Ethernet driver A is associated with the first controller NIC A, providing software instructions for the first controller to process messages. With the help of Ethernet driver A, all messages are passed to the first TCP / IP stack A. This first TCP / IP stack resides at the TCP / IP or UDP layer of the system (Layer 4 of the OSI model). From this stack, an executable application (application) created by the first program runs, operating at the user level of the test system to process messages as needed in the message memory (not explicitly shown). It is also possible for the executable application (application) to add further new messages to the message stream; this is also known as injection. Next, messages to be sent to the second control unit ECU B are passed from the message memory to the second TCP / IP stack B. Through this second TCP / IP stack B and with the help of the second Ethernet driver B, messages are sent from the second network interface controller NIC B to the second control unit ECU B. Messages from the second control unit ECU B arrive at the first control unit ECU A via the reverse path. This method can, in principle, be applied bidirectionally.

[0038] Figure 3 Only a test system with an extension of the eBPF filter at the driver level according to the present invention is shown. This filter ensures that only specific messages are received in the TCP / IP stack. For example, the filtering code might look like this:

[0039]

[0040] This filter only allows the driver to send messages destined for port 30495 to the TCP / IP stack. All other messages are sent directly to the second driver B. They do not need to be allocated to the stack and can be directly sent to the second control unit ECU B.

[0041] More complex conditions can also be implemented for filtering, for example:

[0042]

[0043] Here, not only a specific target port but also a specific address must be given so that the message can be sent through the user layer.

[0044] Figure 4aThe illustration schematically depicts one embodiment of the invention, in which two control devices, namely a first control device ECU A and a third control device ECU C, are connected via a first switch device SW on a first controller NIC A. In this case, the third control device ECU C must also be simulated by a simulator for the second control device ECU B.

[0045] Figure 4b Another variation is shown where the second control unit ECU B is not directly connected to the test system, but rather via a switch device SW. A fourth control unit ECU D is also connected to this switch SW. In this configuration, messages from the first control unit ECU A and / or the third control unit ECU C can be transmitted via the test system to the second control unit ECU B and / or the fourth control unit ECU D. The reverse communication direction is also possible. In this case, the fourth control unit must also be simulated using the test system as a communication partner on the other side of the test system.

[0046] Therefore, switches SW are connected not only to the first controller but also to the second controller. Messages from multiple control units ECU A, ECU B, ECU C, and ECU D are received and forwarded by the test system through these switches. Thus, the test system can be connected between the control unit networks to transparently transmit, intercept, or process messages for testing purposes.

[0047] Figure 5 An embodiment of the invention is illustrated, wherein the filtering procedure is implemented at the hardware level. This embodiment is feasible when controller NIC A and NIC B are located on the same network card.

Claims

1. A method for transmitting and processing messages between a first control unit (ECU A) and a second control unit (ECU B) via a test system (HIL), wherein, The test system (HIL) is connected to a first control device (ECU A) via a first port and to a source and / or destination for messages for a second control device (ECU B) via a second port. The test system (HIL) has a first controller (NIC A) and a first TCP / IP stack for messages from the first control device, and a second controller (NIC B) and a second TCP / IP stack for messages from the second control device (ECU B). It also has a message store for exchanging messages with the first and second TCP / IP stacks. In the test system (HIL), messages from the first TCP / IP stack are sent to the message store and forwarded to the second TCP / IP stack, and vice versa. Messages can be selected by a first procedure for processing for testing purposes before forwarding. Messages selected for processing are forwarded by the first or second controller (NIC B) to the corresponding first or second TCP / IP stack and stored therein in the message store for processing. The processed messages are then forwarded to the corresponding other controller (NIC A, NIC B). B), wherein the test system (HIL) has a filter program, which is implemented by parameterizable filter code, by means of which unselected messages are transmitted directly from the first controller (NIC A) to the second controller (NIC B) or vice versa.

2. The method according to claim 1, wherein, For filtering purposes, the filter receives, in particular, the port number received at runtime, the IP address of the sender and / or receiver of the message to be processed, or a description of elements from the AUTOSAR description file related to the message to be processed.

3. The method according to claim 1 or 2, wherein, The filtering procedure is implemented in hardware.

4. The method according to claim 1 or 2, wherein, The protocol field of Ethernet messages received by the first controller (NIC A) at layer 2 is examined at layer 3 and / or layer 4 using a filtering procedure to determine whether the message should be forwarded directly to the second controller (NIC B).

5. The method according to any one of the preceding claims, characterized in that, The filtering procedure is provided at least in part by an XDP filter.

6. The method according to any one of the preceding claims, wherein, The message is an Ethernet message used for service-based communication, and the filtering code is parameterized at runtime after the service discovery phase is completed by passing the current port number and IP address of the message to be processed as parameters to the filtering program.

7. The method according to claim 6, wherein, The filter generates parameterized program code, which is then compiled and used with the extended Berkeley Package Filter (eBPF) program.

8. The method according to any one of the preceding claims, wherein, Configure multiple filter settings.

9. The method according to any one of the preceding claims, wherein, The filtering procedure can be parameterized via graphical user input to configure the selection of messages to be processed.

10. The method according to any one of the preceding claims, wherein, A first switch device (SW) is connected between a first control unit (ECU A) and a first port, and the first control unit (ECU A) is connected to a test system (HIL) via the first switch device (SW). The first switch device (SW) is connected to a first controller (NIC A). A third control unit (ECU C) is connected to the test system (HIL) via the first switch device (SW) and the first port. The first controller (NIC A) sends messages from the second control unit (ECU B) to the third control unit (ECU C) and / or receives messages from the third control unit (ECU C) and forwards them by the test system (HIL) to the second control unit (ECU B) and processes them beforehand if necessary. Messages not selected for processing are forwarded directly from the first controller (NIC A) to the second controller (NIC B) via a filtering procedure or vice versa.

11. The method according to any one of the preceding claims, wherein, The source and / or destination of messages for the second control device (ECU B) are provided by the second control device (ECU B) itself, or by the TAP or another exchange device (SW) or another message storage, particularly the playback system.

12. A test system (HIL) for performing the method according to any one of the preceding claims, wherein, The test system (HIL) has a computing unit, a first port, a first controller (NIC A) and a first TCP / IP stack for messages from a first control device (ECU A), a second port, a second controller (NIC B) and a second TCP / IP stack for messages from a second control device (ECU B), and a message storage for exchanging messages with the first and second TCP / IP stacks. The test system (HIL) has a first program configured to transmit messages from the first TCP / IP stack to the message storage and forward them to the second TCP / IP stack, and vice versa. The first program is configured to receive selection criteria for messages so as to process selected messages before forwarding them for testing purposes. The test system (HIL) has a filtering program implemented through parameterizable filtering code. The test system (HIL) is configured to transmit messages not selected for processing directly from the first controller (NIC A) to the second controller (NIC B), or vice versa, using the filtering program.

Images