A Perspective on Ethernet in Automotive Communications—Current Status and Future Trends

Abstract

Automated driving requires correct perception of the surrounding environment in any driving condition. To achieve this result, not only are many more sensors than in current Advanced Driver Assistant Systems (ADAS) needed, but such sensors are also of different types, such as radars, ultrasonic sensors, LiDARs, and video cameras. Given the high number of sensors and the bandwidth requirements of some of them, high-bandwidth automotive-grade networks are required. Ethernet technology is a suitable candidate, as it offers a broad selection of automotive-grade Ethernet physical layers, with transmission speeds ranging from 10 Mbps to 10 Gbps. In addition, the Time-Sensitive Networking (TSN) family of standards offers several features for Ethernet-based networks that are suitable for automotive communications, such as high reliability, bounded delays, support for scheduled traffic, etc. In this context, this paper provides an overview of Ethernet-based in-car networking and discusses novel trends and future developments in automotive communications.

1. Introduction

In the past, the car was a mechanical system with the primary function of moving people around efficiently. Therefore, the number of on-board electronic components was small and their impact on the cost of the car was low. In car design, the focus was on vehicle control and the user experience mainly depended on the hardware. Later on, the introduction of novel functions such as Advanced Driver Assistance Systems (ADAS) and infotainment shifted the focus towards including comfort and safety, and therefore, car software started playing an increasingly important role.

Nowadays cars are cyber-physical systems consisting of a high number of electronic components, called Electronic Control Units (ECUs), interconnected through communication networks to exchange data and control messages. The impact of on-board electronics on the car’s design complexity and cost increased significantly. In fact, over the past two decades, the number of ECUs has steadily grown as an effect of both the availability of different types of sensors and of ECU specialization. Today, Automated Driving requires support for time-critical and safety-critical traffic flows and poses compelling requirements on in-car communications, especially in terms of bandwidth, reliability and predictability [1].

In light of this context, Automotive Ethernet is the prime candidate for the main in-car network technology [2]. In fact, Automotive Ethernet technology offers a broad range of bit rates, from 10 Mbps up to 10 Gbps. Automotive-grade Ethernet physical layers that are able to correctly operate in harsh conditions are standardized, and most of them are already available. Moreover, the IEEE Time-Sensitive Networking (TSN) family of standards [3,4,5] offers several features that are suitable for automotive communications, such as fault-tolerant and accurate time synchronization, bounded latency, support for scheduled traffic, high reliability, etc.

This paper provides a perspective on in-car networking, with a focus on Ethernet-based communications. Starting from the traditional in-car network architectures and technologies, the paper discusses the current status, novel trends and future developments of Ethernet and TSN standards for automotive communications.

The paper is structured as follows. Section 2 presents an overview of the current in-car network architectures and technologies. Section 3 offers a perspective on Automotive Ethernet and the IEEE Audio Video Bridging (AVB) standards. Section 4 focuses on the TSN standards that are relevant to automotive communications. Section 5 addresses the ongoing evolution of car architecture and the relevant challenges. Section 6 highlights some of the main ongoing developments relevant to automotive TSN-based communications. Finally, Section 7 summarizes the paper and outlines future trends.

2. Current In-Car Network Architectures and Technologies

Originally, in-car networks had a “flat” architecture, as each system was developed independently of the others. Such an unstructured network topology raised some issues, because the network complexity grew with the interdependence of functions, thus making debugging difficult and not allowing for cost optimization.

Later on, leveraging the concept of functional domains, in-car network architectures turned to structured architectures (as it is shown in Figure 1), also called “domain-based”, that are still in use today, although there will be a transition to another type of architecture, i.e., the zonal one, in the near future. The various functional domains differ for the functions provided and the constraints of the supported applications.

2.1. Automotive Functional Domains

Table 1. The traditional automotive functional domains.

Functional Domain	Description	Networking Technologies
Powertrain	Control of engine and transmission	CAN, CAN FD, FlexRay
Chassis	Control of the vehicle stability and dynamics according to steering/braking solicitations and driving conditions (e.g., ground surface, wind, etc.)	CAN, CAN FD, FlexRay
Body and Comfort	Control of doors, windows, roof, and seats, climate control, etc.	LIN, CAN, CAN FD
Multimedia/ Infotainment	Audio CD, DVD players, MP3 players, TV, Rear Seat Entertainment, navigation information services, etc.	MOST, CAN
Human Machine Interface	Advanced display technologies	MOST, CAN
ADAS	Lane Departure Warning, Traffic Sign Recognition, Night vision, Pedestrian detection, Parking assistant, etc.	CAN, FlexRay

presents the traditional functional domains and the correspondent legacy in-car communication technologies, which will be discussed in Section 2.2.

The main automotive communication requirements are described in the following.

Communication predictability is the property that enables the network designer to assess whether all the real-time frames will be delivered to the destination within their deadlines, before starting the network operation. This means that all the components of the frame end-to-end delay can be calculated, in an exact or stochastic way [6,7,8,9,10].

Fault-tolerance is the network ability to deliver a service even following the occurrence of a fault (e.g., message faults, defective circuits, line failure). Redundancy, either spatial or temporal, and bus guardians are examples of measures used to achieve fault-tolerance.

Bandwidth requirements highly depend on flows. Some flows, i.e., the raw video flows originating from the cameras used for ADAS or for automated driving require high bandwidth, while the flows of the typical control loops in the powertrain domain do not need it.

Low cost is always beneficial in the automotive domain. For instance, the LIN and CAN network protocols, which will be described in Section 2.2, are very successful and broadly used as they work well and are cheap.

Security is becoming increasingly important with the growing of the inter-domain communications and with the increased openness of the car to flows coming from the external world (e.g., car-to-x communications) [11]. CAN, for example, was not designed with security in mind, and therefore it contains vulnerabilities that hackers have already exploited in well-known attacks that were abundantly reported in the press and in social media in recent years.

Energy efficiency is an important aspect, especially when the engine is not running. To save energy, automotive networks offer sleep and wake-up modes and partial networking. One requirement is that when the car is started or restarted, it needs to be fully operational within two seconds.

All the above-mentioned aspects are important, however, to what extent one of them dominates over the other ones very much depends on the specific application/functional domain. For instance, in the body and comfort domain, low cost is more important than bandwidth, while powertrain applications demand higher bandwidth and predictable communications. Very high bandwidth, predictability and security are required for the multimedia and infotainment domains. ADAS and Automated Driving require very high bandwidth, deterministic communications, security, and fault-tolerance.

2.2. Legacy In-Car Networking Technologies

Traditional in-car networking technologies include:

• LIN [12]. The Local Interconnect Network (LIN) is a low-cost, low-speed broadcast serial communication system on a single wire, widely used in production cars. LIN is simple, cheap and it is typically found in body and comfort subsystems. LIN adopts a bus topology, with a maximum total length of 40 m. It is based on a shared medium and follows a Master–Slave transmission protocol, with one master and up to 16 slaves forming a LIN cluster. A LIN Description File is used in the design phase to configure the scheduling behavior of the LIN cluster. LIN offers services to put nodes into a sleep mode (go-to-sleep command) and to wake them up before new data is sent on the bus, in order to optimize energy consumption.
• CAN [13]. The Controller Area Network (CAN) is the most widely used in-car network technology [14]. It is found in many functional domains, i.e., powertrain, body and comfort, and multimedia (to send control messages). CAN is a multimaster serial bus that implements Carrier Sense Multiple Access with Bitwise Arbitration (CSMA/BA) to access the shared channel. Each CAN message has a maximum payload of 8 bytes and starts with an Arbitration field that includes the message identifier (11 bits in the CAN 2.0A version, 29 in the CAN 2.0B one) plus another bit (called the Remote Transmission Request bit). The Identifier field gives the message priority. If multiple messages begin to be transmitted at the same time, an arbitration phase starts. At the end of this phase, the highest priority message goes through unaffected, while the others are stopped. CAN offers several speeds, i.e., 125 Kbps, 250 Kbps, 500 Kbps, and up to 1 Mbps, but the higher the speed, the shorter the maximum bus length (e.g., 1 Mbps works for bus lengths up to 40 m). This is because the CAN arbitration procedure relies on the fact that a sending node monitors the bus while transmitting. Therefore, the signal must be able to propagate to the most remote node and return back before the bit value is decided. This requires the bit time (i.e., the time between two consecutive bits of the same frame) to be at least twice as long as the propagation delay, which limits the data rate. For in-car usage, the typical maximum CAN speed is 500 Kbps. CAN provides error detection and recovery mechanisms and fault-confinement mechanisms to identify permanent failures. CAN is able to offer predictability in real-time communications, but may introduce transmission jitter, i.e., the channel access time instant of a periodic message is not deterministic, but may vary, depending on the presence of ongoing transmissions on the shared channel.
  CAN FD [13] introduces improvements in terms of longer payloads than traditional CAN (0–8, 12, 16, 20, 24, 32, 48, and 64 bytes) and higher transmissions speeds (2 Mbps, 5 Mbps). The longer payload helps reduce segmentation of long messages and add security features. Compared to CAN, the higher speed allows CAN FD to offer higher throughput and faster software downloads at the end-of-production line or during maintenance in garages for software updates [15]. CAN FD controllers also support Classical CAN frames, i.e., CAN FD controllers can send and receive classical CAN frames as well as CAN FD frames. Both protocols (Classical CAN and CAN FD) are standardized in ISO 11898-1:2015.
  CAN XL [16] represents the next step in CAN evolution [17,18]. The “XL” part of the name is because CAN XL provides “extra large” payloads of up 2048 bytes and a data rate of up to 20 Mbps. Specified by CiA 610-1 (CAN in Automation) and currently standardized as part of ISO11898-1, CAN XL is a CAN data link layer that fills the gap between CAN FD and Ethernet 100BASE-T1. CAN XL protocol controllers are also backward-compatible, i.e., they are able to perform Classical CAN and CAN FD communication. CAN XL also enables, among other things, transparent tunneling of Ethernet frames and the use of the TCP/IP stack (https://www.bosch-semiconductors.com/ip-modules/can-protocols/can-xl/ (accessed on 23 December 2022)).
• FlexRay [19]. The FlexRay protocol implements deterministic and fault-tolerant communications for time- and safety-critical applications, applying Time Division Multiple Access (TDMA) and using two channels for redundancy. The transmission speed is 10 Mbps and can reach 20 Mbps if the two redundant channels are used to transmit different data.
  The communication follows an offline-defined schedule based on the network cycle that consists of a communication cycle, during which transmissions occur, and of a network idle time that is used for clock synchronization. The communication cycle is split into a static segment (pure TDMA transmissions), a dynamic segment (based on minislotting), and a symbol window. FlexRay offers payload lengths up to 64 bytes, multiple topologies (i.e., bus, star, multistar), a bus guardian that prevents faulty nodes from transmitting within time slots not assigned to them to improve fault-tolerance, and support for power management, i.e., sleep modes and fast wake-up times. FlexRay was mainly intended for the chassis and the x-by-wire domain [20,21]. However, the limited flexibility of the TDMA communications, the complexity of building a schedule for the dynamic segment, the higher cost of the FlexRay technology compared with other in-car network technologies, and the crisis of the automotive sector in the years in which the FlexRay standard was published have contributed to its limited adoption in commercial cars. In the future, it is very likely that FlexRay will be replaced by Automotive Ethernet.
• MOST [22]. The Media Oriented Serial Transport (MOST) is the current automotive infotainment backbone for high-quality audio, video, data and real-time control over a single medium. MOST is able to network up to 64 devices, such as radio, amplifier, DVD, telephone, microphone, e-Call, navigation, displays, and headphones, in a ring topology. Different transmission speeds are available, i.e., 25 Mbps on Polymeric Optical Fiber (POF), 50 Mbps on Unshielded Twisted Pairs (UTP), and 150 Mbps (POF). MOST is a synchronous network driven by a single Timing Master, which is able to stream audio and video data with different possible data rates. A MOST system covers all the layers of the ISO-OSI model and organizes the network traffic in a continuous sequence of frames that are generated by a Timing Master (typically, the Head Unit of the infotainment system) with a fixed frequency. Two frequencies are used: 48 kHz (professional audio) and 44.1 kHz (audio CD). The communication around the ring is one-directional. The Timing Master starts a frame transmission from its transmit port to the receive port of the next node in the ring, which in turn synchronously transmits the frame on its transmit port to the next node’s receive port, and so on. Synchronous frames are continually transmitted from the Timing Master to the next node in the ring, which in turn puts its source data into the frame and transmits the frame to the next node in the ring.

Table 2. Current in-car networking technologies.

	LIN	CAN	CAN FD	FlexRay	MOST
Max. Bandwidth	20 Kbps	up to 1 Mbps	up to 5 Mbps	20 Mbps	25, 50, 150 Mbps
Cost	very low	low	low	low	high
Cabling	1-wire	UTP	UTP	UTP	POF (25, 50) UTP (150)
Topology	bus	bus	bus	bus, star, hybrid	ring, star
Safety-critical applications	no	yes	yes	yes	no
Main applications	body and comfort	several	several	safety-critical, x-by-wire	multimedia, infotainment

summarizes the main features of current in-car networks.

Point-To-Point Technologies

Today, cameras or displays with high-definition (HD) or sophisticated Light Detection and Ranging (LiDAR) sensors require data rates that go beyond 1 Gbps. Serializer/Deserializer (SerDes), also called low-voltage differential signaling (LVDS), pixelink, or high speed video link, are the general names for the point-to-point technologies that support the high-speed transmission of binary data to transmit pixel-precise information on the lowest layers of the ISO/OSI layering model [23]. The primary use of a SerDes is to provide data transmission over a single line or a differential pair in order to minimize the number of I/O pins and interconnects. Although it is often used synonymously with SerDes, LVDS is the physical principle of SerDes interfaces. In fact, LDVS is a standard that specifies electrical characteristics of a differential, serial signaling standard that operates at low power and can run at very high speeds using inexpensive twisted-pair copper cables. LVDS is a physical layer specification only; many data communication standards and applications use it and add a data link layer as defined in the OSI model on top of it.

2.3. Heterogeneity of Current In-Car Network Architectures

Nowadays different network technologies are used in the different functional domains [24]. However, several distributed applications also require communication between these different domains, i.e., inter-domain communications. For instance, the active suspensions on several high-end vehicles require real-time interaction among ADAS cameras, powertrain sensors, and chassis actuators.

Due to the existence of multiple not directly compatible networking technologies, the inter-domain communications have to be supported by complex gateways that require application knowledge. This is an issue, as the gateway has to be adapted every time a change in the application is made. Moreover, there is a performance penalty due to the protocol conversion operated by the gateways. For example, infotainment interfaces are required to provide the driver with prompt and timely interaction [25], however, sometimes such interfaces are slow to respond to the user’s inputs because infotainment systems must wait to receive information from other components that belong to other subsystems in other functional domains. Another example is the lack of synchronization between the instrument clusters and the dashboard screens on some cars, which may cause occasional loss of visual consistency for indications and alerts, thus degrading the quality of the user experience.

A common networking technology offering high bandwidth, bounded latency, reliability, and synchronized operations of the ECUs through a common network time would solve the problems described above and simplify the car’s electronic architecture.

3. Ethernet for Automotive Communications

Automated driving poses new challenges, as it requires correct perception of the surrounding environment in any driving condition. To achieve this result, not only are many more sensors than in current ADAS needed, but such sensors are also of different types, such as radars, ultrasonic sensors, LiDARs, and video cameras. Given the high number of sensors and the bandwidth requirements of some of them (e.g., cameras, LiDARs), high-bandwidth automotive-grade networks are required.

Ethernet technology is a suitable candidate, as it offers high bit rates of up to 10 Gbps. Moreover, automotive-grade Ethernet Physical layers able to correctly operate in harsh conditions under high electromagnetic radiation and thermo-mechanical stress are standardized, and most of them are already available. Consequently, Automotive Ethernet represents the main in-car networking solution for current and future automotive architectures. The main reasons that originally triggered interest in Ethernet for automotive communication were the higher bandwidth provided as compared to other in-car networks, the support offered to the Internet Protocol (IP) stack, and its wide use and acceptance, thanks to IEEE standardization and openness [26]. Moreover, the large community of developers and users generated positive market expectations in terms of a high number of good-quality chips available at low development and manufacturing costs.

Thanks to the IEEE standardization, Automotive Ethernet is nowadays unanimously considered the solution for achieving a homogeneous in-vehicle network that will replace the multiple small networks connected via gateways that are currently used in cars.

A broad range of data rates for automotive usage is available, i.e.,

• 100 Mbps (standardized as IEEE 802.3bw-2015);
• 1 Gbps (standardized as IEEE 802.3bp-2016);
• 10 Mbps (standardized as IEEE 802.3cg-2019, also known as 10Base-T1S);
• 2.5, 5, and 10 Gbps (standardized as IEEE 802.3ch-2020, also known as Multi-Gig Automotive Electrical Ethernet PHY).

The migration from domain-based to zonal architectures, which use Ethernet links to support autonomous operation, demands data rates higher than 10 Gbps. Consequently, the IEEE standardization project “Greater than 10 Gb/s Electrical Automotive Ethernet”-P802.3cy (https://standards.ieee.org/project/802_3cy.html (accessed on 23 December 2022)) that addresses 25, 50, and 100 Gbps rates is on its way to being approved in 2023.

However, Ethernet was not designed with real-time traffic in mind, but as a best-effort network. As a result, special mechanisms had to be introduced to provide real-time traffic with bounded delays that can be analytically obtained through timing analysis [27,28,29]. Early studies in the literature proposed applying traffic-shaping techniques to bound the interference of best-effort traffic on real-time flows over Ethernet networks in order to provide statistical guarantees on the timely delivery of real-time frames [7,30,31]. Later on, Credit-Based Shaping (CBS) was adopted by the AVB family of standards [32] to limit the traffic bursts of real-time flows so that they could be provided with bounded latency over Switched Ethernet. While this is very well suited to the needs of audio/video traffic, CBS is not suitable for supporting safety-critical control traffic, as shaping can delay the frame transmissions, thus introducing transmission jitter. To handle time- and safety-critical traffic, the TSN family of standards [3] introduced time-aware shaping in the IEEE 802.1Q switches.

In the following subsection, the main features of the AVB standards are discussed.

IEEE Audio Video Bridging

The IEEE AVB family of standards was developed by the IEEE 802.1 Working Group to provide improved synchronization, bounded latency, and reliability over IEEE 802.1Q networks. The main AVB standards are the following:

• IEEE 802.1AS-2011: Timing and Synchronization for Time-Sensitive Applications
• IEEE 802.1Qav-2009: Forwarding and Queuing for Time-Sensitive Streams (FQTSS)
• IEEE 802.1Qat-2010: Stream Reservation Protocol (SRP).

The IEEE 802.1AS-2011 [33] achieves a common notion of time in the network through a suite of protocols that enable the end stations and switches to synchronize their local clocks with each other. In particular, first, a Best Master Clock algorithm is run to choose the node with the best local clock quality. Such a node, called the grandmaster, acts as the time reference source in the network. Second, the Generalized Precision Time Protocol (gPTP) is used to send the grandmaster clock value to the other network nodes along a spanning-tree path.

The IEEE 802.1Qat [34] defines the SRP, which makes it possible to register and reserve bandwidth for some real-time traffic classes, called the Stream Reservation (SR) classes. This is achieved by reserving resources within the switches along the complete path between the talker (i.e., the source node) and the listener (i.e., the destination node).

The IEEE 802.1Qav [35] provides prioritization for the flows belonging to the SR classes and applies traffic shaping to the SR frames to prevent traffic bursts. In particular, for each SR traffic class, the standard provides formulas to calculate the maximum frame size and the maximum number of frames belonging to the class that can be sent in a given time interval. To enforce such a limit, a Credit-Based Shaper is applied at the output ports of both the switches and end nodes. This way, it is possible to guarantee bounded latency to the frames belonging to the SR classes.

With the AVB standards, Ethernet became able to provide bounded latency to real-time flows, i.e., 2 ms for SR Class A and 50 ms for SR Class B over 7 hops in the network.

In automotive communications, AVB can effectively support the transmission of audio/video streams in the multimedia domain, but it is not suitable for time-critical and safety-critical control traffic. For this reason, starting from 2012, the IEEE TSN family of standards was defined, which broadened the scope from audio/video to multiple types of flows, with diverse QoS and generally more stringent requirements [36]. The TSN standards that are relevant to automotive communications are described in the next section.

4. TSN Standards for Automotive Communications

The TSN family is a set of standards, a flexible “tool-set” developed by the IEEE 802.1 Working Group that adds a number of novel features to IEEE 802.1Q switches. Each TSN standard introduces protocols and mechanisms that provide a given property, such as ultra-low latency, reliability, clock synchronization robustness, etc. Depending on the application context, the single TSN standards can be flexibly combined with each other to build a solution that fulfills all the requirements of a given application. Figure 2 shows the main TSN standards that are relevant for in-car communications.

4.1. Bounded Low Latency

Among the standards in this class, there are the previously discussed IEEE 802.1Qat and IEEE 802.1Qav amendments that belong to the AVB family of standards. In fact, TSN not only adds new features to the IEEE 802.1Q standard, but also retains the original functions, e.g., the ones introduced by AVB have been part of the IEEE 802.1Q standard since 2014.

The main TSN standards that address bounded low latency are described below.

The IEEE 802.1Qbv-2015 [37] Enhancements for Scheduled Traffic introduces the transmission gate mechanism to support scheduled traffic, a traffic class that requires that frame transmissions occur following a predefined time schedule. The transmission gate mechanism is based on opening or closing the gates that are associated with each queue of a port of an IEEE 802.1Q switch to either allow or block the transmission of frames from each queue. Gate operations follow a given time schedule implemented as a a gate control list, i.e., a list of timed gate operations that repeats cyclically.

The IEEE 802.1Qbu-2016 Frame Preemption amendment [38] is also relevant to bounded low latency. In combination with the IEEE 802.3br, the IEEE 802.1Qbu implements frame preemption to intersperse express frames (i.e., real-time frames) among best-effort ones. To realize frame preemption, a dual-MAC stack is used within IEEE 802.1Q switches in order to distinguish between express (i.e., time-critical and non-preemptable) and preemptable frames (i.e., best-effort) and handle them differently. The standard makes it possible to suspend the transmission of a preemptable frame and allow for one or more express frames to be transmitted. When the express frames have been transmitted, the transmission of the preempted frame is resumed. The advantage of preemption is the medium access delay reduction for time-critical frames, as they do not need to wait for the transmission of an entire best-effort frame, but can preempt it at some point. However, such a benefit becomes less significant at higher speeds, as the transmission time decreases.

The IEEE 802.1Qch [39] standard, Cyclic Queuing and Forwarding, introduces a mechanism for receiving and transmitting frames alternately for a fixed interval of time, called a cycle time. The real-time frames that are gathered during a cycle are then transmitted in the following one, to minimize transmission jitter and guarantee bounded end-to-end delays.

The IEEE 802.1Qcr-2020 [40] amendment to the IEEE 802.1Q standard defines Asynchronous Traffic Shaping (ATS) over full-duplex links with constant bit data rates. The protocol works over the port transmission queues and realizes traffic shaping at a stream level through a token bucket that limits the burst size of a given stream. Mixed real-time traffic types, such as periodic, rate-constrained, and event-driven (sporadic) are supported. An eligibility time is assigned to each received frame. When the current time is higher than or equal to the eligibility time of a frame, the latter can be enqueued to be transmitted.

4.2. Timing and Synchronization

The IEEE 802.1AS-2011 standard of the AVB family provides synchronization with microsecond accuracy and handles loss of the active grandmaster electing a new one. However, the handover procedure provided in IEEE 802.1AS-2011 is not very fast and might cause time jumps at some nodes. For this reason, its revision, called IEEE 802.1AS-2020, supports multiple synchronized grandmasters and multiple synchronization paths to enable seamless low-latency handover and a quick recovery of time synchronization in failure modes.

4.3. Reliability

Besides the already mentioned IEEE 802.1AS-2020, another TSN standards that improves reliability is IEEE 802.1CB [5], which introduces frame replication and elimination for reliability (FRER). By exploiting the frame identification capability, the IEEE 802.1CB standard provides frame duplication and transmission over multiple disjoint paths to increase the probability that at least one replica will be successfully delivered to the final destination. Once the first replica has been delivered to the destination, the other ones in transit will be discarded. If the end stations are not able to implement frame duplication and elimination, transparent proxy functioning of the closest switches is envisaged.

Furthermore, the IEEE 802.1Qci [41] Per-Stream Metering and Monitoring was developed to improve reliability. In particular, this standard allows for error detection and mitigation by blocking a stream or a port to enforce error containment, so that an error will not propagate on the network. IEEE 802.1Qci can also apply ingress policing and filtering to improve security, blocking a traffic source when unforeseen or non-compliant traffic is detected.

4.4. Security

The TSN family of standards does not include a standard dealing with confidentiality, but there is a close cooperation between the IEEE 802.1 TSN Task Group and the IEEE 802.1 Security Task Group to investigate how to adopt the existing IEEE security mechanisms in TSN networks. Currently, the P802.1AEdk project, an amendment to the IEEE Std 802.1AE™—2018 standard, is running. The standard specifies a MAC Privacy protection encapsulating protocol and its use in conjunction with the MAC Security protocol (MACsec) to hide the source and destination MAC addresses of user data frames and to reduce any correlation between observable frame sizes and transmission timing. The MACsec protocol provides link-to-link encryption and protection to the data exchanged by ECUs within the car and adds Security TAG, Integrity Check Value, Packet number fields, and encryption. In MACsec, all communications, i.e., unicast, multicast, and broadcast messages of all protocols, are protected. MACsec makes it possible to maintain communications confidentiality and to take action against security breaches [42]. Moreover, used in combination with IEEE 802.1Qci, i.e., per-frame filtering and policing, MACsec limits Denial-of-Service (DoS) attacks. Recent presentations at the 2022 IEEE Standards Association Ethernet & IP @ Automotive Technology Day [43,44] evince a strong interest in leveraging MACsec and improving its startup performance to use it as the next state-of-the-art automotive network security solution. However, MACsec for automotive usage needs hardware support in controllers and switches, thus increasing the cost of the components.

4.5. Resource Management

IEEE 802.1Qcc [45] extends the SRP capabilities for resource management and network configuration purposes. In particular, IEEE 802.1Qcc describes protocols to provide support for Configurable Stream Reservation classes and streams. The IEEE 802.1Qcc standard defines three network configuration models, i.e., the fully distributed model, the centralized network/distributed user model, and the fully centralized model. In the fully distributed model, the end nodes (talker and listeners) of a stream communicate the user stream requirements directly through a protocol, and the entire network is configured in a distributed way. In the centralized network/distributed user model, the end nodes of a stream communicate the user stream requirements to a Centralized Network Configurator (CNC). The CNC calculates the configuration and propagates it to the bridges using a remote network management protocol. In the fully centralized model, one Centralized User Configuration (CUC) entity is in charge of discovering end nodes and application requirements to calculate the stream requirements that are in turn transmitted to the CNC. The latter is in charge of calculating and propagating the network configuration to the bridges. The fully centralized model is suitable for automotive applications, as the timing requirements of the flows depend on the physical environment under control.

In the following, an overview on the TSN standards supporting Automated Driving is provided.

4.6. TSN Support for Automated Driving

This section highlights the correspondence between the various Automated Driving requirements and the TSN standards that can be used to meet them.

4.6.1. Temporal Requirements

Automated Driving systems include a number of sensors that generate traffic with very diverse characteristics, e.g., regular periodic traffic and burst traffic with a periodic, sporadic, or aperiodic arrival pattern.

The TSN standards that enable meeting the temporal constraints imposed by the traffic classes mentioned above include:

• IEEE 802.1Qbv, which is able to provide deterministic behavior and low latency to closed-loop control (steering, braking) and inter-processor communication. The standard also fits highly regular periodic traffic well.
• IEEE 802.1Qbu, which in combination with the IEEE 802.3br standard [46,47] offers frame preemption ability to reduce the access delay time for urgent traffic (e.g., steering and braking actuation).
• IEEE 802.1Qcr, which can handle the traffic bursts generated by radars and LiDARs by applying token-bucket shaping on a per-flow basis.
• IEEE 802.1Qav, which implements the Credit-Based Shaper to effectively deal with burst traffic.

4.6.2. Time Synchronization

In Automated Driving systems, sensor fusion algorithms need sensor data with timestamps to relate data referring to the same time window. Sensors must therefore synchronize their time to a common time base. In addition, Level 4 and 5 systems also require redundancy, to allow the system to remain operational and reach a minimal risk condition even in the case of the failure of a link or of the grandmaster.

The TSN standards that enable achieving a common notion of time for sensor fusion are IEEE 802.1AS-2011 [33] and IEEE 802.1AS-2020 [4], with its recent revision that improves clock synchronization reliability providing replication mechanisms to be adopted in case of a switch (bridge in the IEEE terminology) fault or frame loss.

4.6.3. Redundancy

Automated Driving systems include delay-sensitive real-time applications (e.g., machine vision) that cannot tolerate delays introduced by the retransmissions of lost frames.

The TSN standard IEEE 802.1CB - Frame Replication and Elimination for Reliability improves on reliability by enabling the duplication and transmission of the frames over disjoint paths and the elimination of replicas at the MAC layer.

4.6.4. Error Detection and Mitigation

Automated Driving systems require the prompt detection of errors due to random hardware faults (e.g., traffic overload), systematic software faults, or cyber-security attacks. Measures to prevent error propagation over the network are also required.

The TSN standard IEEE 802.1Qci helps with per-stream metering and monitoring, error detection (e.g., babbling idiot), error mitigation, ingress policing, and filtering.

To summarize, the TSN family of standards offers many features that match the diverse requirements of the different types of Automated Driving applications (such as sensor fusion, control, and actuation) and allows for a “converged network” in which the different traffic types of Automated Driving applications coexist and manage their constraints [48].

5. Car Architecture Evolution and Relevant Challenges

Automotive Ethernet has the potential to be the main real-time high-bandwidth information highway interconnecting the major in-car subsystems to enable dynamic sharing of the full resource pool across a car. However, to achieve high performance, lower costs, and wiring harness reduction, the in-car network architecture needs to be revised [49,50].

In fact, although the domain-based architecture discussed in Section 2 has a cleaner design and entails less interdependence than the “flat” one, it is still not optimized for wiring, and this has an impact on cost and space. For this reason, a new architecture, called zonal architecture, was devised. Zonal architectures make a shift from the logical distribution of the functionalities typical of the domain-based architecture to their physical distribution [51,52,53].

An example of zonal architecture is shown in Figure 3. It can be seen that in zonal architecture, the wiring of the electronic components does not depend on their functions, but on their physical location in the car.

Several zonal gateway controllers handle communication with the sensors and actuators of one physical area, combining the network protocols required for each of the devices. Zonal gateways are connected with each other and with the central CPU (or high-performance computer) through an Ethernet backbone.

The benefits of e zonal architecture are manifold. First, it simplifies the layout of sensors, actuators, and cabling inside the car, with a significant weight reduction for the wiring harness. Second, as there are fewer ECUs, there is also a reduction in packaging space. Moreover, as the zonal controller is connected to the legacy in-car network, a large number of sensors and actuators can be flexibly added to the car without the need to be directly connected to the zonal controller. Finally, a reduction in labor cost for installing wires and maintenance is also expected. Zonal architectures pose new issues, however, as each zonal gateway needs to manage the multiple legacy network protocols used to interconnect sensors, actuators, and ECUs. To accomplish this, in each zone Ethernet gateways working at speeds of 10 Mbps, 100 Mbps, 1 Gbps, 5 Gbps, and up to 10 Gbps will be connected to traditional automotive networks [54] (such as LIN, CAN, CAN FD, and FlexRay) to run protocol conversion functions and fast control functions in the periphery of the car. The communications between zones will instead go through an ultra-high speed Ethernet backbone, operating at 10 Gbps to 25 Gbps.

The introduction of Automotive Ethernet and the TSN standards in the car networking architecture introduces several challenges. Some of them are discussed below.

5.1. Insights on Automotive Ethernet Testing

The introduction of Automotive Ethernet as the car backbone or as a replacement for some of the traditional in-car networks represents a major shift that also has an impact on system testing. In fact, with the increasing degree of system integration in the car, fewer ECUs perform more functions. On the one hand, this integration reduces costs and weight, on the other hand it causes a proportional increase in software complexity. As novel Automotive Ethernet protocols continue to be developed to meet the increasing software requirements, it is essential to also adapt the test methodology to the growing complexities in order to ensure the continued reliable functioning of systems interconnected via Automotive Ethernet.

Automotive testing has several benefits, as it checks the compliance with global regulations, allows the early discovery of faults (thus preventing costly recalls), and helps to ensure safety from the early stage of development. Automotive testing consists of different phases [23]. First, the Component test, which evaluates the functionality of an ECU as a standalone component. Second, the Network test, which is performed by connecting the ECUs and testing networking functions such as start-up, shut-down, sleep, restart, etc. Third, the System test, which evaluates the functionality of the integrated system against the requirement specifications. Finally, the last testing phase consists of the In-Vehicle acceptance test, when all required functions have to pass the final in-vehicle acceptance test with all ECUs integrated into the vehicle.

While the System-level tests and In-Vehicle tests are independent of the networking technology, and are therefore not affected, the introduction of Automotive Ethernet has an impact on the Component test, Network test, and on maintenance throughout the lifetime of the car [23]. In fact, in the Component test, as Ethernet is a point-to-point network, the device under test (DUT), i.e., the ECU, can only be connected to the testing device, while in a shared bus, e.g., CAN, multiple devices can be connected together as well as with the test tool on the same network. Moreover, for Automotive Ethernet, a media converter is needed to simulate the vehicle network traffic. In the Network test, the introduction of Automotive Ethernet, i.e., a point-to-point switched network, changes the way the test is performed compared to a shared bus network. In fact, the traffic flows on every link of the switch can be different, so it is not possible to simply connect a tool that will receive and transmit all network traffic. Instead, to track all communications, either a transparent logger (often called a TAP, i.e., Test Access Point) is inserted in each link or the switch has to provide an extra port for mirroring all communications to the data logger. The first solution, i.e., TAP, has the drawback that its insertion introduces some latency, while the mirroring port has a few more drawbacks, because the data logger attached to the mirroring port will not receive bad frames that are dropped by the switch. Moreover, the extra port raises the hardware cost of the switch. Multi-Active TAPs are also available and offer the ability to monitor and time-align frames from multiple ports of an Ethernet switch. Finally, the introduction of Automotive Ethernet has an impact on maintenance because, upon a reported malfunctioning, the in-vehicle network traffic in the customer’s cars should be accessible to the diagnostic tools, and therefore, such tools should be able to decode Ethernet traffic.

To support testing, a broad set of test specifications is made available by the OPEN Alliance [55], and several companies offer suitable tools that are available on the market.

5.2. Considerations on Verification and Functional Safety of Automotive TSN Networks

TSN-based automotive networks require time-consuming traffic planning and verification, which in turn require suitable methodologies and tools. For this reason, several studies have addressed suitable scheduling methodologies [56,57,58] and tools for the modeling, verification [59], and simulation [60,61,62,63] of TSN-based automotive networks. Moreover, when new devices that generate critical flows are added to an existing TSN-based in-vehicle network, the whole network configuration has to be reviewed, and part of it may need to be modified. After the reconfiguration, it is necessary to formally verify that all the requirements of the applications are satisfied.

Several modeling approaches for configuring and verifying TSN networks have been proposed. For example, the formal analysis methods presented in [64,65] verify the timing and latency performance of the TSN shapers. With reference to the IEEE 802.1Qbv amendment, the approach in [56] derives the required constraints for computing offline schedules that guarantee low and bounded jitter and deterministic end-to-end latency for critical communication flows. The work in [61] considers the effects of the mutual influence of critical requirements and uses Logical Programming and inference algorithms to reduce the complexity of application requirements verification.

Safety-relevant aspects in routing decisions designed to increase the reliability of the critical applications are addressed in [66,67], while the work in [68] presents four different dynamic scheduling and routing heuristics to support FRER functionality in TSN.

As far as functional safety is concerned, support for safety-critical applications on Ethernet TSN in-vehicle networks provides additional challenges. For example, after analyzing the safety requirements for communication and processing within a zonal controller, the work in [69] concludes that the design for functional safety goes far beyond a single product. Therefore, system solutions are recommended [69]. ISO 26262-6:2018 [70] is the most recent version of the standard for the development of software for safety-related systems installed in most road vehicles. The standard covers a broad spectrum of automotive applications and defines five different Automotive Safety Integrity Levels (ASILs) that correspond to different risk levels and safety requirements in the development, verification and validation process of the applications considered. For each ASIL, the ISO 26262 outlines requirements on the coverage of random hardware errors and systematic errors. In the context of random hardware errors, the work in [71] presents a lightweight formal analysis approach for the determination of the transmission reliability of messages in switched Ethernet networks under the influence of transient errors. The work in [72] proposes an ASIL-decomposition based technique that addresses systematic errors in safety-critical networked applications through the integration of automotive functional safety engineering with TSN routing and scheduling. In particular, the work proves that the ASIL decomposition can be integrated with routing and scheduling for TSN networks, with a significant improvement of the total cost.

A comprehensive survey on real-time Ethernet modeling from AVB to TSN that includes end-to-end delay analysis, real-time scheduling, reliability-aware design, and security-aware design is provided in [73]. Here, these topics are not addressed in detail, as the focus of this work is on the evolution of in-car networking protocols and, in particular, on Automotive Ethernet and the TSN standards.

6. Ongoing Developments

This section highlights some ongoing developments dealing with TSN in automotive communications. Two IEEE standardization projects in progress that deal with TSN profiles for automotive and cut-through bridges are described.

6.1. Time-Sensitive Networking Profile for Automotive In-Vehicle Ethernet Communications

The current lack of TSN profiles for automotive communications impairs interoperability and makes it difficult and costly for automotive manufacturers to define requirements and for suppliers to implement such requirements. To solve this issue, the ongoing project P802.1DG “Time-Sensitive Networking Profile for Automotive In-Vehicle Ethernet Communications” defines TSN profiles for automotive communications in order to provide interoperability and connectivity for automotive applications on converged networks.

The P802.1DG project is the answer to the need for standardizing the selection and use of the IEEE 802 standards and features to deploy secure and highly reliable automotive converged networks. The automotive profiles defined by the P802.1DG project will be used by car manufacturers and suppliers for designing and implementing deterministic IEEE 802.3 Ethernet networks able to support the entire range of in-car applications, including those requiring high availability and reliability, bounded latency, security, and maintainability. The P802.1DG profiles [74] will favor interoperability and deployment and will be very beneficial to automotive manufacturers, suppliers, and users of networking services and automotive Ethernet components.

6.2. Cut-through Forwarding

The ongoing IEEE P802.1DU project is a stand-alone document, separate from the IEEE 802.1Q, that defines Cut Through Forwarding (CTF) Bridges and CTF in Bridged Networks. The aim of the project is to provide connectivity in networks of mixed CTF and 802.1Q Bridges with CTF and Store-and-Forward (S&F) MACs.

In CTF operation, frame transmission on a switch starts before frame reception has been completed. This creates some problem, for instance, how to handle frames with inconsistent Frame Check Sequence (FCS) due to errors. As the existing S&F switches conformant to IEEE 802, 802.1AC, and 802.1Q standards could be non-conformant/incompatible with P802.1DU, ongoing work is addressing the support of the IEEE 802 and 802.3 standards to the CTF operation and the conformance/compatibility with switches working in the S&F way.

7. Concluding Remarks and Future Trends

The transition from hardware-defined cars to software-defined cars is in progress, and the TSN standards are unanimously indicated as the technology enablers for in-car networks to perform dynamic configuration according to context [75,76,77,78]. Software-Defined Networking (SDN) is a network architecture that decouples forwarding from network control to leave a freedom of choice in programming the forwarding logic [79], and its application to Ethernet switches has already proven to be quite effective [80,81]. In the upcoming “age of services”, as opposed to the current “age of functions”, the functions of the car relevant to automated driving, connectivity, and personalization will be implemented in software and activated according to the driver’s needs. Today, Software-Over-The-Air (SOTA) technologies already enable carmakers to perform remote maintenance and updates through software downloads from a cloud-based server throughout the entire life cycle of the car. In the future, software-defined cars will be able to manage operations, add functionalities, and enable new features through software updates.

Other developments that will leverage the TSN standards concern the increasing autonomy level of the automated driving services provided in mass production cars. Anticipated market trends show that, while low volumes of commercial vehicles are expected to implement fully autonomous driving (i.e., L5) and their usage will be mainly limited to delivery services, L3/L4 automated driving will be fostered in high volumes of consumer cars. In particular, such vehicles will implement the “autonomous driving on demand” paradigm, according to which the car will be able to switch to autonomous driving along driver-defined paths.

The introduction of high-performance computing platforms that perform on-board processing for automated driving applications progressively turns cars into “computers on wheels”. A rich set of computing platforms are expected to characterize the automotive market. Very high-end microcontrollers with embedded non-volatile memory will be used to support the hard real-time requirements of the powertrain, body, chassis, and safety functions. Automotive microcontrollers optimized for electric vehicle (EV) control applications will leverage TSN to address the needs of zonal vehicle electrical/electronic (E/E) architectures in the next-generation EVs. Mid or high-end microprocessors will serve zonal architecture, merging real-time processing, AI, and gateway functions. High-end computing platforms will be used to support ADAS and in-car infotainment, while very high-end vision processors and AI engines will serve the highest levels of autonomous driving.