Use of automotive Ethernet as the main bus system within vehicles is now within reach. To cope with the growing complexity of networks on a safety level, existing test methods are no longer sufficient as they only focus on individual system components and disregard systemic verification. To counteract this weakness, testing strategies for automotive Ethernet must in future be able to capture the increasingly complex interactions between the individual protocols and ECUs.
Particularly with a view to autonomous driving and the future network architectures in vehicles, Ethernet is one of the future-proof and promising technologies. The advantages of this type of networking lie in the transmission of high (10GBase-T1, standardized since 2020) but also low data rates (10Base-T1S, standardized since 2019), in scalable fail-safety and reliability, and with the possibility of interacting with the environment via WLAN and 5G, as is the case with so-called C2X communication (Car-to-X). All these aspects relate to both safety-relevant and comfort-oriented areas of driving. Since the founding of the Open Alliance in 2011, the integration of automotive Ethernet has been increasing, initially in subsystems of camera/sensor systems, but also in the infotainment area (initially BroadR-Reach, from 2014 100Base-T1, first transceiver ICs from Broadcom).
To keep the increasing number of control units for assisted and autonomous driving within manageable limits in the course of this development, an increasing degree of integration of the systems in the vehicle is also necessary so that fewer ECUs perform more functions overall. The aim of this reduced hardware complexity is to save costs and weight, but this subsequently leads to a proportional increase in software complexity in the system. At the same time, the number of automotive Ethernet protocols is also increasing to meet the ever-increasing software requirements.
“In order to ensure the continued reliable functioning of systems networking together via automotive Ethernet, especially highly automated driving systems, it is therefore essential to also adapt the test methodology to the growing complexities,” said Harald Faltheiner, development engineer hardware and systems engineering at Arrk Engineering. “This is because growing networking also increases the interactions between hardware and software layers, which have simply received too little attention to date.”
The step from consumer to automotive Ethernet
Over the past 10 years, automotive Ethernet has become increasingly established as a communication system in vehicle components. During testing, the ISO/OSI reference model, which has been standardized for network protocols since the mid-1980s, has been used as a basis. This model assigns the individual processing steps in the signal chain to seven logical layers (physical, data link, network, transport, session, presentation and application), which become more abstract toward the top, so that they can be considered in isolation from each other. In contrast, the TCP/IP reference model, which has been authoritative since the development of the internet protocol family, divides the system with network, internet, transport and application, into only four layers that build on each other and are also each thought of as sections.
“This blinkered view of the individual layers no longer does justice to the increasing protocol density. Interactions are inevitably overlooked, especially between the lowest physical layer and the higher, application-oriented software layers,” explained Faltheiner.
This discrepancy is due, among other things, to the fact that the Ethernet systems developed since the 1970s in the consumer and business segments differ from automotive Ethernet primarily in the area of the physical layer. This is because while many already established standard protocols, such as TCP/IP, UDP and the IPvx protocols, could simply be adopted or adapted accordingly for use in automotive, the industry places significantly higher demands on the networking technology in terms of hardware, which standard Ethernet with its shielded twisted pair cables cannot fulfil. Automotive Ethernet must withstand a high temperature range – typically up to AEC-Q Grade 1 (-40°C to +125°C) – as well as extreme mechanical loads, comply with strict EMC limits, have the lowest possible power consumption in standby mode and also be cost- and weight-efficient. These and other requirements have been achieved over the past 10 years through a variety of measures involving adjustments to the hardware and software.
Mastering system complexity through multidimensional testing
The service-oriented Ethernet protocol SOME/IP for inter-process communication for client-server applications was introduced especially for use in the automotive industry, as was the DoIP protocol, which is used for diagnostic purposes. Both operate on the top three layers. Also in the higher layers, AVB/TSN is particularly relevant for automotive Ethernet because it enables low-latency transmission of audio and video data. By extending the TSN standard, protocols for low latency (802.1Qbv, 802.1Qbu, 802.1Qch), high reliability (802.1Qca, 802.1Qci, 802.1CB), and in-vehicle network configuration and synchronization (802.1AS, 802.1Qcc) were added. In addition, IPSec ensures access control, data integrity, authentication and confidentiality. Each of these protocols is already very complex in its own right, which is why the focus in previous test procedures – such as those defined by TC8 of the Open Alliance – has been on the respective verification and understanding in detail. However, since all data packets are ultimately transported over the physical layer, this approach completely ignores the closely interwoven interaction of protocols at the hardware and software levels.
“In order to contain these existing gaps in the testing of vehicle networks, which are growing with increasing complexity, Arrk Engineering has developed a test methodology that covers the entire system from a comprehensive perspective,” explained Faltheiner.
The first step of this solution approach is the introduction of an interaction analysis; both in existing and new tests. In this way, control units are not only to be tested in isolation, as is customary with suppliers or manufacturers, but also with regard to their functionality in the system network. In doing so, the specialists at Arrk Engineering basically assume that there are protocols that can lead to malfunctions when interacting with each other.
Secondly, the system is specifically loaded so that the probability of unwanted interactions occurring between the control units and the protocols increases. It is essential to apply or change several parameters simultaneously – such as the sum of the functions executed, the voltage, the number of protocols or the timing – and to record and track every step of the test procedure in detail (see below). On the one hand, this is the only way to define appropriate criteria for evaluating a test as ‘failed’ or ‘passed’. On the other hand, this ensures that a specific failure, such as the failure of a display system, can also be traced back to a concrete trigger within the system complex.
Automotive Ethernet as the networking system of the future
While in most cases today a system architecture with domains and a central gateway is still used and can only be implemented as a subsystem within the automotive Ethernet, the so-called zone-based architecture (see below) is already coming within reach in the course of high integration. This flexible and scalable concept allows networking to take place at the core via Ethernet switches, which forward all the signals. Automotive Ethernet is an adequate networking technology for the zone-based architecture. In principle, there is the possibility of establishing automotive Ethernet as a system bus sooner or later in the context of increasingly automated driving systems.
“In this context, we can assume that the release rate of new protocols for automotive Ethernet will continue to increase,” noted Faltheiner. “Therefore, it is particularly important to consider the corresponding testability in parallel with the protocol development and to release both – protocol and test specifications – at the same time.”
To address this constant need for further development, Arrk’s engineers pay explicit attention to its future viability in their comprehensive test methodology, so that strategies and concepts can be easily adapted and extended to take into account new protocols.
