01

There are many different time-critical Ethernet applica-tions in the automobile. They include advanced driver assis-tance systems (ADAS) with cameras and (radar) sensors, real-time audio and video streams, and backbones for syn-chronizing various physical domains (Figure 1). Another use case is on-board data logging. Moreover, devices networked via Ethernet must naturally also be synchronized with other physical systems such as CAN and FlexRay.Originating from the computer networking and office envi-ronment, Ethernet lacks the real-time capability necessary for technical applications. Although switched Ethernet topologies reduce unwanted collisions during network access, a fully deterministic behavior cannot be realized by this alone. In particular, the sensitive task of time synchro-nization requires complete information along the transmis-sion path on the run times and latencies that are inherent in switches and gateways.

Anyone wanting to control processes in connection with Ethernet is confronted with these challenges. This explains why various standards development organizations are working in parallel to add real-time capability to Ethernet, including mechanisms for time synchronization. The princi-pal methods for time synchronization in the automotive industry are currently based on AUTOSAR 4.2.2, IEEE 802.1AS, and the revised IEEE 802.1AS-ref, which was developed by the Audio/Video Bridging Task Group, which is now known as the TSN (Time Sensitive Networking) Task Group.

The Global AUTOSAR Time ConceptThe concept of AUTOSAR 4.2.2 provides a statically defined Global Time Master (GTM). This ECU, distributes the time in the global time domain with maximum precision for the entire network. Subdomains derived from this can extend

Time Synchronization in Automotive Ethernet NetworksBalancing Act Between AUTOSAR, IEEE, and TSNNumerous system functions in the automobile require high-precision synchronization of the underlying time bases in the ECUs. The entry of Ethernet into the automobile requires that developers and system architects have to deal with this issue because existing methods cannot simply be transferred to Ethernet. Coming from different directions, specialists are working in committees on making Ethernet capable for demanding time-critical tasks. This article presents an over-view of time synchronization methods relevant to the automotive industry, points out the current limits of Ethernet networking, and outlines future solutions and improvements.

02

Technical Article / August 2016

tive bus-specific time base generator (Bus Provider Mod-ule) for FlexRay, CAN, and Ethernet to the run-time envi-ronment and makes the “Presentation Time” available for the application. The individual protocols for the respective physical bus are implemented in the Bus Providers, whereby the Ethernet Bus Provider uses the “generalized Precision Time Protocol” (gPTP) based on IEEE 802.1 (Figure 3). To harmonize this with typical use cases in the automobile, various modifications, additions, and in some cases restric-tions were needed within the scope of AUTOSAR.To point out how Ethernet differs from CAN and FlexRay, we will start by summarizing the essential properties of CAN and FlexRay synchronization: Both have 16 synchro-nized time bases and optionally up to 16 statically con- nected offset time bases. The time information is transmit-ted with two messages in CAN. The first message contains the seconds information and the second message contains the nanoseconds information. For this reason, the second message contains an overflow detection in order to inter-cept possible overflows in the nanosecond range. A “Time Gateway Synchronization Status“ is used by the applica-tion to detect whether it is operating synchronously with the subdomain or the Global Time Master. There is also a Sequence Counter and a Cyclic Redundancy Check (CRC).

beyond various physical media. Time Gateways are passing on the time starting from one slave port through one or more master ports to the end points (Time Slaves) or other Time Gateways (Figure 2). The synchronized time must be corrected by the amount of the Residence Time in the gate-ways. Alternatively, AUTOSAR also allows the establish-ment of separate independent time bases that are ‘filled’ with the current time via the respective gateway.The type of network determines the details of the synchro-nization process. For example, with CAN and Ethernet, the Time Slave corrects the received global time base by com-paring the time stamp from the transmitter side with its own receive time stamp. With FlexRay, the synchronization is simpler because FlexRay is a deterministic system with fixed cycle times that acts in a strictly predefined time pat-tern. The time is thus implicitly provided by the FlexRay clock. While the time stamp is always calculated by soft-ware in CAN, Ethernet allows it to be calculated by either software or hardware. In addition, up to 16 time domains can be implemented for CAN and FlexRay. Instead, Ether-net works with only one single time domain, the “Global Time Domain”.

Basis for Synchronization of Ethernet ECUs: IEEE 802.1ASSince AUTOSAR 4.2.1, the “Synchronized Time Base Manag-er” (StbM) has been available, which abstracts the respec-

Figure 1: Ethernet use cases in the vehicle

03

Technical Article / August 2016

descriptions and optimized communication matrices. Other deviations can be found in the time stamp support in software or hardware, the (lack of) payload data, and the need to equip vehicles with VLANs for security reasons.

Expanded Switch Drivers Supply Port InformationA serious obstacle to precise time synchronization via Ethernet remains – as of AUTOSAR version 4.2.2 – the lim-ited switch functionality of Automotive Ethernet. The switch drivers cannot forward the port number of the cur-rently received message to the overlying layer. This affects the port-specific sending of Sync and Follow_Up messages and practically disables the Pdelay mechanism for switches. Because an outgoing Pdelay request triggers multiple responses here (Pdelay_Resp/Pdelay_Resp_Follow_Up), these can no longer be assigned to the individual communi-cation ports. The Pdelay therefore does not supply any use-ful information. In addition, switches in the current specifi-cation do not allow any (separate) port-specific time stamping. The delays in the switches cannot be determined and a precise time correction is therefore not made. AUTO-SAR 4.3 will improve this situation and provide more sup-port for IEEE-802.1AS functions. In particular, port-specific

Automobile-specific gPTP ImplementationThe standard method for time synchronization in a switched Ethernet network is described in IEEE 802.1AS and comprises the following three core procedures: Distri-bution of the synchronized time (Sync/Follow_Up), mea-surement of the message run time (Pdelay), and Best Mas-ter Clock Algorithm (BMCA). A two-step procedure con-sisting of a Sync message and a Follow_Up message is responsible for the actual synchronization. Pdelay is a spe-cial protocol for measuring the message run time between two ports. In addition, with the help of Pdelay, ECUs can detect whether they are part of a “Time Aware System”, a network with time synchronization capability. By means of the Best Master Clock Algorithm, network nodes, prefera-bly in dynamically structured networks, determine the ECU that supplies the best system time and elevates it to the Grand Master.Implementation in the automobile, however, deviates from the IEEE standard in quite a few aspects. While the IEEE standard permits various dynamic configurations, for example with regard to the network topology or the BMCA (Grand Master selection), a lot is statically predefined in the automobile. This is necessary to achieve unique system

Figure 2: The global time concept in AUTOSAR is specified for CAN, FlexRay, and Ethernet.

04

Technical Article / August 2016

domain number in the gPTP message header must be enabled for values greater than zero. According to IEEE 802.1AS, only “0” is currently allowed as the domain num-ber and all other numbers are ignored by the nodes. As an addition to IEEE 802.1AS, at least one other time domain is included in the current TSN specification (IEE 802.1AS-ref), but this will not be sufficient for the requirement in the automobile. As a solution, AUTOSAR offers the possibility to define additional time domains.

Backup Master To Ensure Fail-Proof SynchronizationSafety and security considerations are increasingly taking center stage in future vehicle architectures and AUTOSAR versions. This quickly raises the issue of a backup master or generally of redundancy concepts if the sole, statically defined time generator (Global Time Master) fails (Figure 4). For this reason, at least a second time generator is needed that runs continuously as a backup master. The Best Master Clock Algorithm in its current form does not appear to be a solution for this. It is relatively slow and operates on the basis of timeout detection so that ECUs may already enter the synchronization timeout state that is actually meant to be avoided. Rather, the masters would have to substitute for each other before a synchronization

switch information will be consistently supported – from the switch driver and the Ethernet driver to the basic soft-ware components – so that the urgently needed input and output stamps will then be available.

Payload Data: The Essential IngredientWhen IEEE 802.1AS is used in the automobile, action is still needed in a few other places. This involves issues such as (OEM-specific) “payload data”, the support of multiple time domains, and redundancy and backup strategies. Pay-load data is understood as additional information in the Follow_Up messages that the standard does not cover but is essential for a specific application or functionality. Exam-ples are debugging information and expanded status infor-mation. The solution is to place additional information in an AUTOSAR-specific Type Length Value (TLV) field in the gPTP messages. The Time Slaves would then evaluate this field or not, depending on their configuration.

Time Domains in Short Supply in the IEEE-StandardWhile IEEE 802.1AS currently provides only one time domain, automotive applications require many more time domains for things like the UTC time, GPS time and evalu-ation of sensor-specific signals. Therefore the existing

Figure 3: Simplified representation of the AUTOSAR software architecture for the global time concept

Figure 4: Increase of robustness for safety and security applications through redundancy and backup concepts for the Global Time Master

05

Technical Article / August 2016

timeout takes place. These and many other issues will con-tinue to ensure ample discussion material in the standards development committees.

ConclusionThe IEEE 802.1AS is a good reference for time synchroniza-tion for Ethernet and, with corresponding implementation, opens up the possibility to use the gPTP protocol according to the IEEE standard in the infotainment area. The coming TSN standard will take into account appreciably more automotive requirements. However, it is still not apparent how comprehensive that will be. In any case, IEEE and AUTOSAR are complementary and are moving toward each other. Due to different release cycles, however, that will still take some time.It is important that system architects, developers, and sup-pliers are able to advance their Ethernet projects efficiently and economically. A valuable aid for this are development tools, such as the CANoe test tool and the AUTOSAR basic software MICROSAR of Vector Informatik, which is avail-able – amongst others – for specific Ethernet hardware. The products support either time synchronization with gPTP according to AUTOSAR or gPTP according to IEEE. In addition, functions and software solutions are available that use the synchronized time for audio/video streaming, for example.

Translation of a German publication in Automobil Elektronik, issue July/August 2016

Image rights:Image 0, 1, 3 and 4: Vector Informatik GmbHImage 2: Original version “AUTOSAR Specification of Syn-chronized Time-Base Manager, Release 4.2.1” (Section 2.2.7 on page 11), edited version: Vector Informatik GmbH

Author Dipl. Ing. (FH) Bernd Jesse is Senior Product Manager of Embed-ded Software at Vector Informatik GmbH for the Ethernet AVB/TSN solution and is actively working on the global time concept in AUTOSAR.