Methodology to Validate the Functions of Communication in Automotive Ethernet
Automotive Ethernet with BroadR-Reach as physical layer is ultimately finding its way into the modern vehicle. By using high-definition cameras and by implementing more and more sensors, the requirements of transferring masses of data permanently increase.
Ethernet communication is already an advanced technology standard with few weaknesses - for it has a rather long history being used in the telecommunications and IT sector. But, using Ethernet for use in the automotive sector brings new challenges to testing for automotive devices. Traditional bus systems like CAN or LIN set high requirements in regards to validating the physical layer. Usually, communication via more simple protocols work properly, assuming the layer is in 100% conformance. The validation of applications using the CAN bus is mostly done through data loggers and rest-bus simulations to check the function of the systems.
Ethernet is enhancing the Engine Control Unit (ECU) by adding new functional applications which also take over the partial control of the communication network, in addition to its common use, for instance, ADAS/engine control. Please note, that the switch with AVB/TSN functions showed in the image is only a part of the overall architecture.
What does that mean in regards to the functional validation of the ECU or of the System Under Test? Surely, the classical approach of testing core system functions with a rest-bus simulation is still valid. Furthermore, it is still necessary to record data for analyzing data packets.
What’s new is that the application for communication (the switch with the implemented AVB/TSN functionality) needs to be tested. Thus, it is required to have a kind of rest-bus simulation for the communication layer as well, in order to test these functionalities. This is quite a challenge, especially for the tester, since he must simulate not only the expected communication but also malfunctions in the network (best & worst case simulations). Depending on the development status, the test process should also include a conformance check of implemented protocols as well as the validation of cyber security functions.
Further considerations bring up the question, is the validation of the switch only necessary when selecting respective hardware and software components? Or, do these functions need to be repeated after every restart, and in different development statuses? Basically, there is no definite answer to that question. It will always depend on the design of the overall ECU architecture, as well as its security relevant functions. Normally, in modern ECUs, resources like CPU or memory chips are being used jointly by different applications like the example shows. That means, changing a core function has indirect influence on the functions of the switch since there might be less processor performance or memory available. Even though the switch application works entirely independently, it is still recommended to continuously check the functions anyway.
Classical test methods will stay essential for integrating new communication technologies. But, also innovative, technology-aligned test methods need to be developed as part of the introduction of Ethernet in the Automotive setting. They should be determined in the respective test specifications and added to existing processes.