Ethernet Time-Sensitive Networking for Automotive ADAS Applications

By John Swanson, Sr. Product Marketing Manager, Synopsys 

The new age of automotive electronic systems has decreased accidents and fatalities. Improving Advanced Driver Assistance Systems (ADAS) for safety-critical automotive applications is the next wave and requires a huge amount of data transmission and subsequent processing. Systems are becoming more sophisticated as they combine ADAS applications from emergency braking, collision avoidance, lane departure warning to fully autonomous driving, making predictable latency and guaranteed bandwidth critical. For example, high-definition cameras capture high-quality images with more details to help detect and react to different situations; high-performance radars and LIDARs determine the range and angle of the surrounding objects. These applications require a high volume of data from different parts of the car for processing and decision making. Due to the high volume of data, enabling high-performance networked connectivity has become a challenge that automotive SoC designers are overcoming with Ethernet. But these systems require more than performance, they require predictable latency and guaranteed bandwidth.

The Time Sensitive Networking (TSN) IEEE working group has released a set of TSN standards and continues to define new specifications to meet the needs for Ethernet in active ADAS applications that require real time networking. An active ADAS application takes control of the car to react to a situation such as avoiding a collision with a pedestrian, object, or another car. This article describes the Ethernet TSN standards for automotive SoCs and briefly explains how designers can enable TSN with automotive-certified Ethernet IP. 

The Evolution of Time-Sensitive Networking

As real-time networking becomes necessary, especially for safety-critical applications such as ADAS, Ethernet with TSN becomes an ideal networking of choice. To enable ADAS, multiple systems must often synchronize, requiring a lot of data to be deployed over the network. For example, the emergency braking system must account for the brake distance and human reaction time. When an obstacle is detected, the collision avoidance system notifies the driver and the braking system activates. Communication between the detection and braking system is critical and delays in applying the brake could be catastrophic.

The evolution of TSN started with the introduction of Audio Video Bridging (AVB). AVB was intended for audio video applications including automotive infotainment and in-vehicle networking systems. In an AVB network, audio from the radio, video from the infotainment system, data from the car’s command center, and file transfers from running diagnostics is streamed and bridged across a common network. The latency for such networking does not have a critical time constraint that data does for safety-critical ADAS application like an automatic braking system. Moreover, the amount of data needed for an ADAS application can be much greater. Because of these reasons, the IEEE committee expanded the capabilities and features originally defined as AVB and renamed the working group to TSN. The IEEE working group has created multiple TSN standards seen in Table 1. 

Table 1: The TSN working group has introduced multiple standards

Time-Aware Shaper

Automotive networks are designed to have predictable guaranteed latency; this type of network is known as an engineered network. The time-aware shaper is used in an engineered network and allows scheduling so a critical traffic queue is not blocked. This is done with a time gate that allows the time-critical data to stream and proceed unimpeded while blocking the non-time critical data; shown in Figure 1. The IEEE 802.1Qbv scheduler’s logic determines the time intervals that the gates must open and close. Time-aware shaper is implemented in the Ethernet MAC. 

Figure 1: Time-aware shaper allows scheduling

Figure 1: Time-aware shaper allows scheduling 

Preemption

Preemption can also be used to reduce the latency of time-critical data streams. On an Ethernet network, preemption allows a time-critical data frame to interrupt the transmission of a non-time critical data frame. Once the time-critical data frame reaches its destination, the non-time critical data frame resumes its transmission. Any fragmented data frame must be reassembled before they can continue their transmission. See Figure 2.

Figure 2: Preemption reduces latency of time-critical data streams

Figure 2: Preemption reduces latency of time-critical data streams

Let’s use the emergency braking system as an example. Two Ethernet MACs transmit the time-critical data frame (green) and non-time critical data frame (orange). The preemptable MAC lets the green frame travel through ahead of the orange frame to get to its destination in real time. The system then applies the brake, also in real time, regardless of the other data frames on the network. The time-critical data frame preempts the non-time critical data frame providing a significant latency improvement, but more importantly, it provides a predictable latency.

Cyclic Queuing and Forwarding

Cyclic queuing and forwarding supports known latencies regardless of the network topology. Its main role is to make the network latencies more consistent across the bridges. See Figure 3. According to the IEEE P802.1Qch standard, the cyclic queuing and forwarding amendment, “specifies a transmission selection algorithm that allows deterministic delays through a bridged network to be easily calculated regardless of network topology. This is an improvement of the existing techniques that provides much simpler determination of network delays, reduces delivery jitter, and simplifies provision of deterministic services across a bridged LAN.”

Figure 3: Cyclic queuing and forwarding supports known latencies regardless of the network topology

Figure 3: Cyclic queuing and forwarding supports known latencies regardless of the network topology

Per Stream Filtering and Policing

Per stream filtering and policing enables a bridge, or endpoint component to detect whether components in the network are conforming to the agreed upon rules. For example, a node gets allocated a certain amount of bandwidth and when this bandwidth is exceeded due to a component failure, or malicious act, action can be taken to protect the network. This standard includes procedures to perform frame counting, filtering, policing, etc. Policing and filtering functions are especially valuable and can be used for the detection and subsequent elimination of disruptive transmissions, thus improving the robustness and security of the network.

Frame Replication and Elimination

Frame replication and elimination supports seamless data redundancy. It detects and mitigates issues caused by cyclical redundancy check (CRC) errors, broken wires, and loose connections. The time-critical data frame is expanded to include a sequence number and is replicated where each frame follows a separate path in the network. At any bridge or merge point in the network, when the separate paths join again, duplicate frames are eliminated from the stream, allowing applications to receive frames out of order. See Figure 4. 

Figure 4: Frame replication and elimination detects and mitigates issues caused by CRC errors, broken wires, and loose connections

Figure 4: Frame replication and elimination detects and mitigates issues caused by CRC errors, broken wires, and loose connections 

For example, when the adaptive cruise control sends a signal to the control system to maintain a certain speed and distance from the car ahead, separate paths are created across the network to allow this signal and signals from other applications to seamlessly travel. Once the signals merge together, duplicate frames are eliminated to allow uninterrupted signal transmission. The IEEE defines three implementations of frame replication and elimination where the talker sends the signal and listener receives the signal:

  • Talker replicates, listener removes duplicates
  • Bridge replicates, listener removes duplicates
  • Bridge replicates, bridge removes duplicates 

Enhanced Generic Precise Timing Protocol

Enhanced generic precise timing protocol supports clock redundancy by synchronizing clocks across the network, in two ways: with a single primary time source or multiple primary time sources. The system has a primary that synchronizes the clock and a primary time source that references the root timing across the network. In a single primary time source model, the clock time information is transmitted to the listener on one segment of the network, and then communicated to the other segment on the same network. Only the primary time source knows the accurate clock time. In a multiple primary time source model, the clock time is transmitted throughout the network at different directions so in case of an interruption, the accurate clock time is still known throughout the network. 

Figure 5a: Single grand master transmitting 2 copies using separate paths

Figure 5a: Single primary time source transmitting 2 copies using separate paths

Figure 5b: multiple grand masters transmitting 2 copies using separate paths

Figure 5b: multiple primary time sources transmitting 2 copies using separate paths

The above TSN specifications, along with others like IEEE P802.1Qcc and P802.1Qcr, have evolved to meet automotive designers’ continuous need for real-time networking for ADAS applications. Ethernet was first used for diagnostics and software update while audio video bridging was introduced for automotive infotainment systems and high-end consumer audio video systems. Today, TSN has become essential for high-end ADAS SoCs, creating new requirements on the components that go into the SoC, including the integrated IP. 

Conclusion

The evolution of safety-critical technologies from the air bag, electronic stability, active cruise control to ADAS requires both bandwidth and predictable latency. This evolution is driving the use of high-performance automotive semiconductors to enable ADAS applications. While there are many available options to connect these systems, Ethernet has emerged as the wired connectivity technology of choice for automotive SoCs. This is due to Ethernet’s ability to support the required range of data rates, proven reliability and interoperability, and addition of TSN. TSN is essential for applications with critical time constraints and Ethernet with TSN has evolved to meet the growing automotive demand for predictable latency and guaranteed bandwidth. The IEEE TSN working group has defined new TSN specifications to extend its capabilities from the previous audio video bridging specification including: multiple time-aware shapers, preemption, cyclic queuing and forwarding, per stream filtering and policing, frame replication and elimination, and an enhanced generic precise timing protocol.

Unlike consumer electronics, automotive electronics and their SoC and IP components must meet a stringent set of automotive standards: ISO 26262 functional safety, AEC-Q100 reliability, and quality management. The ISO 26262 certification defines and documents all processes, development efforts, standards, and safety plans for the target Automotive Safety Integrity Levels (ASILs). The four different ASILs – A, B, C, and D – determine the lowest (A) and highest level (D) of functional safety. The SoC and IP must be tested to meet very low defect densities which is measured by defects parts per million (dppm).

To enable TSN and accelerate SoC-level ISO 26262 certification, designers can integrate automotive-certified IP such as Synopsys’ DesignWare Ethernet Quality-of-Service (QoS) IP. The ASIL B Ready ISO 26262 certified IP with automotive safety package supports Ethernet speeds up to 2.5G, real-time networking, the original IEEE audio video bridging specification, and now TSN.