In-Vehicle Networking, focus Automotive Ethernet
The main concern back in September 2011 was that transmitting Ethernet packets at 100 Mbps over a single Unshielded Twisted Pair (UTP) cable would not be possible under harsh automotive electromagnetic conditions. At this period in time, it was still BroadR-Reach and neither was published in the OPEN Alliance or by IEEE. At this period in time, BMW was the only one seriously interested in Ethernet. BMW had been in production with 100BASE-TX (shielded cabling) for diagnostics and flash updates for three years and had decided to go into production in 2013 with what is now called 100BASE-T1 in its new surround view system.
Key drivers and advantages identified with Automotive Ethernet are the very high bandwidth compared to existing technologies and worldwide adopted technology. The non-proprietary technology (ISO/OSI model) provides availability to second-sources, worldwide IP-based know-how of developers and tools.
"Ethernet has been around for 50 years,
what took the automotive world so long?"
Bob Metcalfe, founder of Ethernet
Ethernet resides within the OSI model. The OSI model is a conceptual model that standardizes the communication functions of a computing system without regard to its underlying internal structure and technology. The model partitions a communication system into abstraction layers.
Ethernet was commercially introduced in 1980 and first standardized in 1983 as IEEE 802.3 and has since retained a good deal of backward compatibility and been refined to support higher bit rates. Systems communicating over Ethernet divide a stream of data into shorter pieces called frames. Each frame contains the source and destination addresses, and error-checking data so that damaged frames can be detected and discarded. Most often, higher-layer protocols trigger retransmission of lost frames. As per the OSI model, Ethernet provides services up to and including the data link layer (OSI layer 2).
The basic principles of how electronic units communicate inside vehicles are shown in these explanatory videos (found on our Youtube channel):
TThe BroadR-Reach technology (from Broadcom) allows the usage of unshielded twisted-pair cable and makes Ethernet cost-competitive for automotive applications.
The lack of interest of the automotive industry in Ethernet as a next-generation networking standard was partly caused by the lack of a physical layer suitable for usage in vehicles.
Examples of commonly used connectors in Automotive are for example from vendors Tyco (MATenet, NanoMQS), Rosenberger (H-MTD), Aptiv (AMEC, H-MTD (2nd source)), Molex (Mini50), and JAE (MX77).
Tyco, Rosenberger, and Aptiv are examples of vendors having connectors for both 100BASE-T1 and 1000BASE-T1 and also having support for both unshielded and shielded cables. Molex and JAE have to our knowledge only support for unshielded 100BASE-T1.
All vendors above have a connector called HSD (originally from Rosenberger) that supports from 100 Mbits and up to 10 Gbits.
The data link layer provides the functional and procedural means to transfer data between network entities and might provide the means to detect and possibly correct errors that may occur in the physical layer.
The data link layer is concerned with the local delivery of frames between nodes on the same level of the network. Data-link frames, as these protocol data units are called, do not cross the boundaries of a local area network.
Inter-network routing and global addressing are higher-layer functions, allowing data-link protocols to focus on local delivery, addressing, and media arbitration.
In this way, the data link layer is analogous to a neighborhood traffic cop. It endeavors to arbitrate between parties contending for access to a medium, without concern for their ultimate destination.
Ethernet, IEEE 802.3 defines the frame formats or frame structures that are developed within the MAC layer of the protocol stack.
Basic Ethernet frame
The basic Ethernet frame in use today is referred to as the Ethernet type II frame. This is the frame format developed by the layer 2 elements of the stack, and this is then passed to the layer 1 physical layer to put it into the format for sending.
Essentially the same frame structure is used for the different variants of Ethernet, although there are some changes to the frame structure to extend the performance of the system should this be needed.
With the high speeds and variety of media used, this basic format sometimes needs to be adapted to meet the individual requirements of the transmission system, but this is still specified within the amendment/update for that given Ethernet variant.
A general summary of the Ethernet, IEEE 802.3, data frame format or structure, and how Ethernet data frames are sent can be found in this article.
A new device in the Automotive IVN is a switch. Switches provide a separate connection for each node in the network. Essentially, a switch creates a series of instant networks that contain only the two devices communicating with each other at that particular moment.
First, some short explanations of abbreviations you probably come across:
Network Interface Card (NIC) - Most devices are connected to a network through a NIC, often plugged into a slot on the computer’s motherboard
Media Access Control (MAC) address - This is the physical address of any device — such as the NIC — on the network. The MAC address, which is made up of two equal parts, is 6 bytes long. The first 3 bytes identify the company that made the NIC. The second 3 bytes are the serial number of the NIC itself
Unicast - A unicast is a transmission from one node addressed specifically to another node
Multicast - In multicast, a node sends a packet addressed to a special group address. Devices that are interested in this group register to receive packets addressed to the group
Broadcast - In a broadcast, a node sends out a packet that is intended for transmission to all other nodes on the network.
Switching allows a network to maintain full-duplex Ethernet. Before switching, Ethernet was half-duplex, which means that data could be transmitted in only one direction at a time. In a fully switched network, each node communicates only with the switch, not directly with other nodes. Information can travel from node to switch and from switch to node simultaneously. In other words, traffic flowing in each direction has a traffic lane to itself. This allows nodes to transmit to the switch as the switch transmits to them — it’s a collision-free environment. Possible congestion however may occur in the switch itself competing on the very same resources, i.e. outbound links.
Automotive has mostly chosen to go for Layer 2 switching (compared to Layer 3 routing). A Layer 2 switch is primarily responsible for transporting data on a physical layer and performing error checking on each transmitted and received frame. A Layer 2 switch requires the MAC address of the NIC on each network node to transmit data. They learn the MAC addresses automatically by copying the MAC address of each frame received, or listening to devices on the network and maintaining their MAC address in a forwarding table. This also enables a Layer 2 switch to send frames quickly to destination nodes. However, like layer 3 and 4 switches, a Layer 2 switch cannot transmit the packet on IP addresses and doesn’t have any mechanism to prioritize packets based on sending/receiving application.
A VLAN (Virtual Local Area Network) is a logical segmentation of a physical network into separate broadcast domains. This technique allows the creation of isolated network segments, even when devices share the same physical infrastructure (switches, cabling). VLANs enhance network security, reduce broadcast traffic, and simplify network management through flexible device grouping.
Key Benefits:
Enhanced security: Sensitive data and network resources can be isolated within VLANs, limiting the spread of potential threats.
Improved performance: By containing broadcast traffic within specific VLANs, overall network congestion is reduced.
Simplified management: VLANs enable changes to network groups without the need for physical reconfiguration, based on factors like job roles or projects.
VLANs use tags to identify and manage the traffic belonging to different virtual networks within the same physical network. These tags are added to the frame header of Ethernet packets. Depending on the network configuration, two primary approaches are used: single tagging and double tagging.
Single Tagging:
Simple and efficient: This method adds a single tag (usually 12 bits) to the frame header, identifying the VLAN membership of the packet. This is the most common approach in basic VLAN deployments within a single network domain.
Limited scalability: When multiple independent networks share the same physical infrastructure, single tagging becomes insufficient. It can’t differentiate between traffic originating from different domains, potentially causing security and management challenges.
Double Tagging (also known as Q-in-Q or VLAN Stacking):
Enhanced scalability: This technique utilizes two tags:
Outer Tag (S-Tag): Identifies the VLAN membership within the «provider» network (typically the service provider’s infrastructure).
Inner Tag (C-Tag): Carries the original VLAN information related to the customer’s network.
Increased complexity: Requires special configuration on switches with support for double tagging and understanding of both S-Tag and C-Tag information.
Here’s an analogy:
Think of VLANs as separate apartments in a building (physical network). Single tagging is like assigning a unique apartment number to each tenant. However, if multiple buildings share the same entrance (physical infrastructure), single tags become ambiguous. Double tagging introduces an additional layer, like a building code before the apartment number, allowing clear identification of both the building and the specific apartment within it.
In summary:
Single tagging: Simple and efficient for basic VLAN deployments within a single network domain.
Double tagging: Offers increased scalability and isolation for multi-tenant environments where multiple independent networks share the same physical infrastructure.
Choosing the appropriate tagging method depends on the specific network architecture and requirements.
Layer 3 is responsible for all packet forwarding between intermediate routers, as opposed to Layer 2 (the data link layer), which is responsible for media access control and flow control, as well as error checking of Layer 1 processes.
Layer 3 provides the network’s routing and switching technologies that create logical paths known as Virtual Circuits (VC), which are used for the transmission of data between network nodes. The main functions of Layer 3 include routing and forwarding, as well as internetworking, addressing, packet sequencing, congestion control, and further error handling.
There are several protocols used in Layer 3 that Automotive mainly are interested in:
Internet Protocols IPv4/IPv6 -
The first major version of IP, Internet Protocol Version 4 (IPv4), is the dominant protocol of the Internet. Its successor, Internet Protocol Version 6 (IPv6), has been growing in adoption, reaching almost 25% of all Internet traffic as of October 2018
Address Resolution Protocol (ARP) - RFC826 - Ethernet Address Resolution Protocol
ARP is a low-level network protocol for translating network layer addresses into link-layer addresses. ARP lies between layers 2 and 3 of the OSI model, although ARP was not included in the OSI framework and allows computers to introduce each other across a network before communication.
Before two NICs communicate, each must know the other’s relative IP or MAC addresses. If NIC A only has NIC B’s MAC address, NIC A can reveal its IP address by sending an ARP request to NIC B. NIC B may then reply by attaching its IP address with ARP to NIC A. This simple address translation and exchange process is the primary role of ARP.
ARP tables can be stored to increase transmission rates by keeping track of addresses known to the network and transmitting any MAC or IP address changes via ARP.
There is no authentication required at this level, so spoofing of IP and MAC addresses is possible. Additional software may be required to police the ARP tables and prevent malicious user attacks.
Known as the Transport layer, provides the transparent transmission or transfer of data between end systems or hosts and is responsible for end-to-end error recovery, as well as flow control. The transport layer ensures complete data transfers.
Layer 4 contains the creation of data packets from raw data and the addition of source and destination specifics like port numbers. Working together with destination IP addresses, these ports form a network socket or simply the identification address of the process-to-process communication (used in Layer 5).
There are several protocols on Layer 4 that Automotive is interested in:
The most common protocol is UDP uses a simple connectionless communication model with a minimum of protocol mechanisms. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram. It has no handshaking dialogues, and thus exposes the user’s program to any unreliability of the underlying network; there is no guarantee of delivery, ordering, or duplicate protection
TCP is one of the most used protocols in digital network communications and is part of the Internet Protocol Suite, commonly known as the TCP/IP suite. Primarily, TCP ensures end-to-end delivery of data between distinct nodes. TCP works in collaboration with Internet Protocol (IP), which defines the logical location of the remote node, whereas TCP transports and ensures that the data is delivered to the correct destination. Before transmitting data, TCP creates a connection between the source and destination node and keeps it alive until the communication is active. TCP breaks large data into smaller packets and also ensures that the data integrity is intact once it is reassembled at the destination node.
ICMP provides troubleshooting, control, and error message services. ICMP transmits error messages found in IP datagrams. These errors are reported to the originating datagram’s source IP address. An ICMP message is encapsulated directly within a single datagram and reports errors in the processing of datagrams.
The Session layer manages a session by initiating the opening and closing of sessions between end-user application processes. This layer also controls single or multiple connections for each end-user application and directly communicates with both the presentation and the transport layers. The services offered by the session layer are generally implemented in application environments using remote procedure calls (RPCs).
The Presentation layer is responsible for the following:
Data encryption/decryption
Character/string conversion
Data compression
Graphic handling
The Application Layer is the topmost layer in the OSI model and serves as the direct interface between end-user applications and the network. It enables users and software applications to interact with the network by providing access to services such as email, file transfer, and web browsing. This layer is responsible for presenting data in a human-recognizable format and supports functions such as identity authentication, privacy, and data integrity.
While both the OSI and TCP/IP models refer to their highest layer as the "Application Layer," their definitions differ significantly:
The TCP/IP model takes a broader view. Its Application Layer encompasses the functions of OSI's application, presentation, and session layers. It focuses on process-to-process communication, defining protocols such as HTTP, FTP, DNS, and SMTP, but does not mandate user interface behavior or strict modular separations.
The TCP/IP Application Layer relies on underlying transport protocols (like TCP or UDP) to manage host-to-host communication. Although it doesn’t enforce strict data format rules, its design is guided by the Robustness Principle, as outlined in RFC 1123:
“Be liberal in what you accept, and conservative in what you send.”
In the OSI model, the Application Layer has a narrower and more defined scope, focused on delivering data to end-user interfaces. It works closely with two distinct layers below it:
Presentation Layer (Layer 6) – handles data translation, encryption, and compression.
Session Layer (Layer 5) – manages connections and sessions between devices.
Real-World Example: DHCP in Automotive Ethernet
DHCP (Dynamic Host Configuration Protocol) is an Application Layer protocol that automates the assignment of IP addresses, subnet masks, gateways, and DNS settings within a network.
In in-vehicle Ethernet networks, DHCP can be used for dynamic IP address assignment, though its use depends on the vehicle’s architecture and specific requirements. For example, real-time systems may prefer static addressing to ensure deterministic behavior, while less time-sensitive modules may use DHCP for flexibility and ease of configuration.
Less frequent: In older vehicle networks with decentralized architectures, each ECU (Electronic Control Unit) often had its own dedicated IP address configured manually. DHCP was rarely used due to the smaller number of nodes and simpler communication needs.
More frequent: In newer vehicles with centralized architectures, DHCP becomes more common for dynamic IP address assignment, especially for nodes like gateways and switches that might change over time. This simplifies network management and allows for easier reconfiguration or replacement of components.
Diagnostic tools:
Software updates:
DHCP can be used by diagnostic tools or temporary test equipment to automatically obtain an IP address and access the vehicle network for troubleshooting purposes.
In some cases, DHCP can be used to assign temporary IP addresses to ECUs during software updates, ensuring efficient and reliable distribution of new firmware.
Overall:
Not ubiquitous: While DHCP is increasingly being used in modern in-vehicle Ethernet networks, it’s not as pervasive as in traditional IT networks due to specific requirements and constraints of automotive systems.
Hybrid approaches: Combining manual configuration for critical ECUs with DHCP for dynamic components is a common approach for balancing flexibility and security in modern automotive networks.
Please note that this is a general overview, and the specific usage of DHCP may vary depending on the specific vehicle manufacturer and network implementation.
SOME/IP (Scalable service-Oriented MiddlewarE over IP) is an automotive middleware solution that can be used for control messages. It was designed from the beginning to fit devices of different sizes and different operating systems perfectly.
This includes small devices like cameras, AUTOSAR devices, and infotainment head units or telematics devices. It was also made sure that SOME/IP supports features of the Infotainment domain as well as that of other domains in the vehicle, allowing SOME/IP to be used for MOST replacement scenarios as well as more traditional CAN scenarios.
Standard SOME/IP header format including all required fields [AUT21e]
This is a 32-bit identifier that specifies the used RPC or to specify a certain event. It contains either a Service/Method ID or an Event ID depending on whether an RPC call or an event is specified. This ID should be unique for the entire system.
This field specifies the length of the SOME/IP message starting from the Request ID to the end of the message.
The Request ID is used to uniquely identify a provider/subscriber pair to handle multiple parallel accesses. This is important when multiple subscribers want to access the same method or event at the same time. A provider will copy the Request ID in his response to the Subscriber and add it to the response. For a client, the Request ID is the unique Client ID assigned to it. The Session ID is meant to help differentiate between multiple messages from the same client. The Session ID is also a unique identifier and is generally incremented after each call. Session handling can be deactivated in which case the Session ID will be set to 0x00 in every message.
This field specifies the version of the SOME/IP protocol and what kind of header format is used.
The interface version field specifies what major version of the Service Interface is used.
Specifies what kind of message is being sent. This can either be a request, a response, a notification, an error, or the Transport Protocol (TP) version of these messages. The TP message types are only used when the SOME/IP-TP protocol is used to send large messages over the User Datagram Protocol (UDP). If the message is a TP message it signifies that the packet is a segment.
The return code shows whether an RPC has been completed successfully. For messages that are not response messages or error messages, this field is always 0x00.
This field carries a serialized set of parameters supplied for a remote procedure call.
These messages are generally used for remote procedure calls and are widely used. A request message indicates that it expects a response after the request has been processed.
This type of message works like a request message but does not expect a response.
Notifications can be used in a publish/subscriber context where every subscriber receives the notification message from the related publisher. The basic SOME/IP protocol does not support the publish/subscribe concept itself and can only be used to transport the actual message. The publish/subscribe functionality is instead implemented in the SOME/IP Service Discovery (SOME/IP-SD) protocol.
Error messages are used to return errors in the case of a failed request. Instead of sending a response message with an error code, an error message containing the exception and error information is sent instead. Having a designated error message format allows for greater flexibility when handling errors.
SOME/IP Service Discovery (SD) - dynamically finding and functionality and configuring its access.
SOME/IP Transport Protocol (SOME/IP-TP) - segment larger SOME/IP messages on UDP.
DoIP (Diagnostic over IP) - is the automotive diagnostics protocol based on IP. Defined by ISO 13400-2 standard, DoIP facilitates diagnostics-related communication between external test equipment and automotive ECU using IP, TCP, and UDP. DoIP also supports communication between on-board and off-board diagnostic systems of a vehicle.
Because DoIP enables access to the vehicle’s electronic components (a.k.a Automotive ECU) through the Internet, it becomes possible to fetch diagnostic data from the vehicle remotely, without requiring physical access to the vehicle. In simple words, the DoIP stack serves as a gateway.
Till now you may have worked mostly on UDS (Unified Diagnostic Services ) but now when there is an IVN concept emerging and more usage of the TAP devices for data recording happening there are various other protocols from ASAM that are used for the measurement and calibration of ECUs.
CCP (CAN Calibration Protocol) and XCP (Universal Measurement and Calibration Protocol) are standardized protocols for communicating with Electronic Control Units (ECUs). CCP was the original protocol, primarily used over the CAN bus, while XCP is its successor, offering enhanced features and flexibility.
CCP/XCP enables read/write access to ECU data, facilitating tasks like calibration, data logging, and parameter adjustment. By providing a standardized interface, these protocols streamline development and testing processes across different ECU manufacturers.
XCP offers improved performance and flexibility through features like stimulation, dynamic DAQ lists, and synchronous DAQ modes.
XCP enables more precise data acquisition with features like ECU auto-detection and timestamp measurement.
XCP introduces a new «stimulation» (STIM) mode for bypassing ECU calculations
The A2L file format is essential for describing ECU parameters and data structures to the calibration tool.
Beyond calibration and data logging, CCP/XCP is used for ECU diagnostics, software flashing, and parameter optimization.
From the original protocol PLP (Probe Logging Protocol), from BMW, Technica Engineering developed TECMP (Technically Enhanced Capture Modules Protocol) for transporting captured Ethernet frames and status messages over standard Ethernet networks between probes and data sinks. It is used by Technica’s Capture Module products, which are devices that can be used to capture and record Ethernet traffic.
TECMP is well established and proven, so going towards ASAM CMP (Capture Module Protocol) might be interesting. It is an open standard that defines the communication between capture modules (probes) and data sinks to monitor in-vehicle bus communication and sensor data.
Both TECMP and ASAM CMP provide a standardized way to capture and record all of this data, regardless of the underlying communication protocol. TECMP or ASAM CMP are both transported over Ethernet, and it defines the mapping rules for vehicle bus communication and sensor data.
The ASAM supported protocol CMP makes it possible to use a variety of different capture modules and data sinks from different vendors, as long as they all support the ASAM CMP standard.
Scalability: It can be used to scale from small systems with a few capture modules to large systems with hundreds of capture modules.
Flexibility: It supports a wide variety of vehicle bus communication protocols and sensor data formats.
Interoperability: ASAM CMP is an open standard, so capture modules and data sinks from different vendors can be used together.
As a summary, think of ASAM CMP as a common language for capture modules and data sinks, allowing them to exchange data efficiently and seamlessly, regardless of their specific vendor or technology. This simplifies the process of collecting and analyzing in-vehicle data for various applications, including diagnostics, development, and testing of new automotive features.
In the table below are the description of the various TECMP and CMP fields.
Each Capture Module can be configured with a unique ID. This ID can be used to identify different Modules if they are used in the same network
The counter is incremented for each CMP/TECMP frame sent from a Capture Module. The CM ID field is the same for all interfaces in this case
The used version of the CMP/TECMP protocol
Description of the payload function, whether status, configuration, or bus data
Description of the Type of Source Data (e.g., CAN, LIN, FlexRay, Ethernet, Undefined, Voltage, Current, …). These types are preconfigured and fixed
Pre-filled with 0x0000
This represents the Start of the Segment and the End of the Segment
ID that uniquely identifies the log data/bus/link on the IVN
The timestamp is the time in the past 1ns since
Length of Source Data
The Data Flags refer to the messages transmitted on the IVN (100Base-T1, 1000Base-T1, FlexRay, CAN, CAN-FD, LIN)
Data transferred from the vehicle IVN (source data)
AUTOSAR R4.0 was a significant milestone in introducing comprehensive Ethernet support for the automotive industry. This version laid the groundwork for Ethernet communication within the vehicle, providing essential components and interfaces.
While subsequent versions, such as R4.2 and R4.4, have refined and expanded Ethernet capabilities, R4.0 is generally considered the foundational release for Ethernet in AUTOSAR.
It’s important to note that the evolution of Ethernet in AUTOSAR has been continuous, with each new version bringing improvements and adaptations to meet the growing demands of automotive networking.
Introduced refinements to Ethernet communication management, addressing issues related to network topology and error handling.
Expanded support for different Ethernet PHYs (Physical Layer) to accommodate various network requirements.
Further developed Ethernet communication management, focusing on improved performance and reliability.
Introduced support for additional Ethernet-based protocols and services, such as Time-Sensitive Networking (TSN) for deterministic communication.
Leverages Ethernet extensively for high-speed communication between ECUs and with external systems.
Supports advanced Ethernet features like Publish-Subscribe communication patterns and Quality of Service (QoS) guarantees.
Integration of Ethernet with other communication protocols: Ensuring seamless interoperability between Ethernet and CAN, FlexRay, etc.
Functional Safety: Meeting stringent safety requirements for Ethernet-based systems.
Security: Addressing cybersecurity challenges in Ethernet-based automotive networks.
Deterministic Ethernet: Supporting real-time applications through technologies like TSN.
In addition that a vehicle will be a node in a V2X network and that Ethernet is a fairly new communication technology within the vehicle, cybersecurity is very important to address in the design of the IVN. It is advisable to keep in mind that whatever protection you choose has to be updated regularly, generally within a maximum of 4 years.
Find the basics at https://en.wikipedia.org/wiki/Automotive_security
Some applications running on your network are sensitive to packet loss or delay. These applications commonly use the UDP protocol as opposed to the TCP protocol. The key difference between TCP and UDP as it relates to time sensitivity is that TCP will retransmit packets that are lost in transit while UDP does not.
If your network has plenty of bandwidth and no traffic that bursts above what it can handle, you won’t have a problem with packet loss, delay, or jitter. But in many networks, there will be times when links become overly congested to the point where routers and switches start dropping packets because they are coming in/out faster than what can be processed. If that’s the case, your streaming applications are going to suffer. This is where Quality of Service (QoS) comes in.
QoS helps manage packet loss, delay, and jitter on your network infrastructure. Since we’re working with a finite amount of bandwidth, our first order of business is to identify what applications would benefit from managing these three things.
There are various protocols to handle timing and QoS in Ethernet. There are several ways to identify or mark the traffic that needs priority. Class of Service (CoS) will mark a data stream in the layer 2 frame header. Various applications can be marked differently, which allows the network equipment to be able to categorize data into different groups.
The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP typically runs over UDP. RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. RTP/RTCP on UDP is not deterministic and is rather old and it is recommended to consider Ethernet AVB (Audio-Video Bridging).
The Time-Sensitive Networking (TSN) standards define mechanisms for the time-sensitive transmission of data over Ethernet networks. TSN is a set of different standards under development by the Time-Sensitive Networking task group of the IEEE 802.1 working group, formed in 2012 by renaming the existing Audio Video Bridging Task Group.
IEEE Time-Sensitive Networking (TSN) standards encompass a set of protocols and mechanisms designed to enable deterministic and low-latency communication over Ethernet networks. These standards aim to address the evolving needs of various industries, including industrial automation, automotive, telecommunications, and audio/video streaming, by providing precise timing and synchronization capabilities. Here’s a breakdown of key aspects of IEEE TSN standards:
TSN introduces mechanisms to guarantee timely delivery of data packets, even in congested network conditions. This deterministic behavior is crucial for applications requiring real-time responses and predictable latency, such as industrial control systems and automotive networks.
IEEE 802.1AS defines protocols for clock synchronization across networked devices with high accuracy. This synchronization is essential for coordinating actions among distributed systems and ensuring that time-critical tasks are executed synchronously
TSN enables precise control over the timing and transmission of data packets through mechanisms like time-aware scheduling and shaping. This allows for the prioritization of critical traffic and the reservation of network bandwidth for specific applications or traffic classes
TSN supports the interruption of lower-priority traffic by higher-priority traffic to ensure timely delivery of critical data. This feature helps reduce latency for time-sensitive applications without compromising the integrity of non-time-critical traffic
IEEE TSN standards provide a common framework for implementing deterministic networking solutions, promoting interoperability among devices from different vendors. This standardization facilitates the integration of TSN-enabled components into existing Ethernet networks and encourages the development of compatible products and solutions.
Overall, IEEE Time-Sensitive Networking standards offer a comprehensive suite of protocols and mechanisms tailored to meet the stringent timing and reliability requirements of diverse industries. By leveraging TSN, organizations can build robust and predictable network infrastructures capable of supporting a wide range of time-critical applications and emerging technologies.
The TSN standards (IEEE 802.1 Qbv, Qcc, Qbv, etc.) build upon the existing Ethernet infrastructure, making them readily deployable in existing networks
TSN is still evolving, but its standards are gaining traction rapidly and are being adopted by major industry players.
While IEEE 1588 itself provides a foundation for time synchronization, specific profiles tailor the protocol to different application needs. Here are the most common PTP profiles used in automotive applications:
This profile 802.1AS-Rev (Timing and Synchronization for Time-Sensitive Applications Revision) is based on IEEE 1588-2008. It is widely adopted in automotive applications. It prioritizes low latency and determinism, crucial for safety-critical systems like powertrain control. Features include limited master functionality, message compression, and specific boundary clock settings. This profile is developed by the IEEE 802.1 Time-Sensitive Networking (TSN) Task Group.
IEEE 1588-2019 was published in November 2019, is informally known as PTPv2.1 and includes backward-compatible improvements to the 2008 publication. This is the latest version of the standard, including features like improved time accuracy and support for diverse network topologies. While gaining traction, it is still less widely adopted in automotive applications compared to the profile mentioned above.
Automotive Ethernet, 2nd Edition, 2017, by Kirsten Matheus, BMW, and Thomas Königseder, Technica Engineering
Automotive Ethernet - The Definitive Guide - 2nd Edition, 2022, by Intrepid Control Systems
Automotive Software Architectures: An Introduction, 2017, by Miroslaw Staron
State of VLAN in the Automotive Domain, 2018, by Patrik Thunström, TCN
What is Time-Sensitive Networking, 2018, a Belden Blog Post.
