Post on 31-Aug-2020
Eindhoven University of Technology
MASTER
Investigation of time-synchronization over Ethernet In-Vehicle Networks for automotiveapplications
Sridharan, K.
Award date:2015
Link to publication
DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.
General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
Department of Mathematics and Computer Science
Masters in Embedded Systems
Master Thesis
Investigation of Time-Synchronization over Ethernet
In-Vehicle Networks for automotive applications
Author:
Karthik Sridharan
(Student ID: 0869748)
Supervisors:
TU/e:
prof. dr. K.G.W.(Kees) Goossens
NXP:
dr. Nicola Concer
dr. H.G.H.(Bart) Vermeulen
26th October 2015
Public
This page is intentionally left blank.
Preface
This thesis is submitted in partial fulfilment of the requirements for the Master’s Degree in
embedded systems at Eindhoven university of technology, Eindhoven, The Netherlands. The
project was conducted at NXP Semiconductors, Eindhoven and was jointly supervised by prof.
dr. K.G.W.(Kees) Goossens (Eindhoven University of Technology), dr. Nicola Concer (NXP)
and dr. Bart Vermeulen (NXP). It contains work done from 1st March to 30th September 2015.
The thesis has been made solely by myself, with inputs from the supervisors and is based on the
IEEE 802.1AS standard for time synchronization over Ethernet. The research work and papers
of others working on similar topics was used as reference and I have done my best to provide
these references where applicable.
The Eindhoven University of Technology (TU/e) is one of the leading universities in the Nether-
lands. TU/e intends to be a research-driven, design-oriented university of technology, with the
primary objective of providing young people with an academic education within the engineering
science and technology domain.
NXP Semiconductors is a Dutch semiconductor manufacturer. It is one of the worldwide top
20 semiconductor sales leaders. NXP Semiconductors creates a variety of solutions for the
Connected Car, Cyber Security, Portable and Wearable and the Internet of Things etc. NXP
Semiconductors has a number of research and development facilities across the globe.
This page is intentionally left blank.
Acknowledgement
It would not have been possible to complete this thesis without the help and support of the
people around me.
First, I would like to express my gratitude to prof. dr. K.G.W.(Kees) Goossens my university
supervisor for recommending me to this project at NXP. His inputs and guidance guidance
helped me in all the time of research and writing of this thesis
I would like to thank dr. Nicola Concer, dr. Bart Vermeulen and Ms. Clara Otero Perez
for giving me an opportunity to do my master thesis at NXP, Eindhoven.
I would like to express my sincere thanks and appreciation to dr. Nicola Concer for super-
vising my day to day activities and providing invaluable guidance during the project. His
technical inputs and support were extremely helpful during the project.
I would like to thank dr. Bart Vermeulen for his support, feedback and inputs during the
project. His inputs were crucial and helped me explore various dimensions in the project.
I am grateful for the technical help provided by Mr. Han Raaijmakers. I would also like
to express my sincere thanks and appreciation to the Ethernet team at NXP Semiconductors,
Hamburg and NXP Semiconductors, Nijmegen for their technical support.
Finally, I would like to thank my parents. Without their efforts and support this degree would
not have been possible.
This page is intentionally left blank.
Abstract
The challenges faced by the automotive network engineers in multimedia networking like band-
width, Quality of Service (QoS), cost, licensing, scalability etc., has led the automotive indus-
try into considering Ethernet as an In-Vehicle Networking (IVN) standard. Some of the these
multimedia applications include reverse parking assistance, infotainment, night-vision camera
systems etc. Though in the earlier days Ethernet was not used as an IVN standard because
of its non-deterministic nature, recent developments like the Audio Video Bridging (AVB) and
Audio Video Transport Protocol (AVTP) standards developed by the AVnu Alliance (AVnu)
task groups has improved the QoS and reliability of Ethernet.
This thesis presents an analysis of the time synchronization protocol which is a part of the
AVB set of standards. Time synchronization in a distributed network is achieved by exchang-
ing messages. Time synchronization plays a key role in delivering a good QoS. The IEEE
802.1AS standard specifies the protocol and procedures used to establish the synchronization
among distributed nodes in a network. The thesis also summarizes some of the current and
relevant work under progress.
Given AVB (automotive) over Ethernet as the scope, we study the impact of the Synchroniza-
tion parameters like Synchronization interval, delay mechanism, delay measurement interval,
announce interval, time-stamping mechanism, Network parameters like Traffic class, packet size,
message frequency and End node parameters like Processor load, application priority etc., on
the quality of synchronization. We then reason about how and why a parameter affects the
synchronization through relevant measurements, tests and plots.
The thesis describes the set-up of a Ethernet network, the selection of end nodes (hardware
and software) and the design of a software for the Ethernet switch (NXP SJA1105). Parame-
ters that could potentially affect the protocol were selected and experiments were performed on
the network to analyse their impact on the time synchronization protocol.
A synchronization in-accuracy of ±108ns in a 2 hop network, ±141ns in a 3 hop and ±168ns
in a 4 hop network was achieved. Reducing the frequency of the Sync messages improves the
synchronization by a factor of 0.27. The experiments also establish the importance of having
hardware time-stamping and an averaging mechanism for calculating the path delay between
different network entities. The AVB and Best effort (BE) traffic though do not have an impact
on the quality of synchronization, significantly affect other parameters related to synchroniza-
tion. The bandwidth utilized by the protocol is very less of the order of 0.0411% for a low Sync
message interval of 31.25ms. Based on the challenges faced during development of the software
for the switch and the experimental analysis, recommendations were made for the improvement
of the switch. The learnings of the experiments would serve as valuable pointers during the
development of the application.
Key words: Ethernet, IVN,AVB, time synchronization, IEEE 802.1AS, clocks, hardware
time-stamping, switch.
7 Investigation of Time-Synchronization
This page is intentionally left blank.
Contents
Preface 2
Acknowledgement 4
Abstract 7
Glossary 14
Acronyms 17
1 Introduction 21
1.1 Current networking solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3 Motivation - Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.5 Goals and Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.6 Thesis overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2 Related work and Background 33
2.1 Audio Video Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.2 Stream Reservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.1.3 Forwarding and Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.1.4 Audio Video Transport Protocol . . . . . . . . . . . . . . . . . . . . . . . 39
2.1.5 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.1.6 Other related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3 Time Synchronization 42
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2 Synchronization terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3 IEEE 1588 and IEEE 802.1AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9
CONTENTS
3.3.2 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.3 Comparison of IEEE 1588 and 802.1AS . . . . . . . . . . . . . . . . . . . 47
3.4 Working principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4.1 Best Master Clock Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.2 Time-Stamping Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.3 Synchronization Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.4 Delay Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.5 Rate Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.6 Working scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5 Other related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4 Experimental setup 59
4.1 End node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.1 Hardware selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2 Software selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.3 Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.4 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4 Software tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5 Experimental Methodology 64
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Test Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6 Experiments, Results and Analysis 69
7 Conclusion 70
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2 Recommendations for the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A Current Solutions 73
A.1 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.2 Local Interconnect Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.3 Media Oriented Systems Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.4 FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B Message formats 77
C gPTP configuration 79
10 Investigation of Time-Synchronization
List of Figures
1.1 Point to point networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2 Diagnostics and Error handling over CAN [1] . . . . . . . . . . . . . . . . . . . . 23
1.3 Evolution of automotive networking technologies [2] . . . . . . . . . . . . . . . . 23
1.4 Advanced Driver Assistance System [3] . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5 Example Layout of an Infotainment System[4] . . . . . . . . . . . . . . . . . . . . 25
1.6 Packet switching and simultaneous exchange [2] . . . . . . . . . . . . . . . . . . . 26
1.7 Ethernet as a Backbone network [5] . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.8 Scalability of Ethernet networks by adding Switches [2] . . . . . . . . . . . . . . 27
1.9 BroadRreach technology of NXP PHY TJA1100 [5] . . . . . . . . . . . . . . . . . 28
1.10 Cost Vs Bandwidth for various networking technologies [5] . . . . . . . . . . . . . 28
2.1 Audio Video Bridging Stack [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2 AVB application in Aeronautics [7] . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 Ethernet AVB in cars [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Stream Reservation Protocol [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5 Working of Credit Based Shaper [9] . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6 Credit Based Shapers [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.7 IEEE 1722 AVTP frame [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.8 Co-existence of AVB, TTE and BE traffic [10] . . . . . . . . . . . . . . . . . . . . 41
3.1 Idea of Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Synchronization Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Transparent clock [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Boundary clock [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5 BMCA spanning tree with Master-port Slave-port Disabled-port Passive-port [12] 49
3.6 Software and Hardware time-stamping . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7 Two-step synchronization mechanism [13] . . . . . . . . . . . . . . . . . . . . . . 52
3.8 One-step synchronization mechanism [13] . . . . . . . . . . . . . . . . . . . . . . 53
3.9 Peer delay mechanism [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.10 Rate ratio calculation[14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.11 Working Scenario of the IEEE 802.1AS protocol . . . . . . . . . . . . . . . . . . 57
3.12 Effect of Sync interval [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.13 Effect of traffic on Synchronization [12] . . . . . . . . . . . . . . . . . . . . . . . . 58
11
LIST OF FIGURES
4.1 Kontron Board [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 RIoTboard [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Linuxptp working [17] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Network Topology with 1 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5 Network Topology with 2 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 Test procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.1 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.2 Local Interconnect Network [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.3 Media Oriented Systems Transport [2] . . . . . . . . . . . . . . . . . . . . . . . . 75
A.4 FlexRay - Bus topology [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.5 FlexRay - Star topology [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.6 FlexRay - Hybrid topology [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.1 Announce Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.2 Sync Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.3 Follow Up Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.4 PDelay Req Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
B.5 PDelay Resp and Pdelay Resp Follow Up Message . . . . . . . . . . . . . . . . . 78
12 Investigation of Time-Synchronization
List of Tables
1.1 Comparison of different In-Vehicle wired networks Source:[2] . . . . . . . . . . . 29
2.1 Stream reservation classes [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Comparison of different synchronization protocols[20] . . . . . . . . . . . . . . . . 43
3.2 Comparison of E2E and P2P transparent clocks . . . . . . . . . . . . . . . . . . . 47
3.3 Comparison of message usage in IEEE 1588, IEEE 802.1AS and IEEE 802.1AS
(automotive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Comparison of IEEE 1588, IEEE 802.1AS and IEEE 802.1AS (automotive) . . . 48
3.5 Comparison of time-stamping methods . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6 Comparison of One-step and Two-step synchronization . . . . . . . . . . . . . . . 54
3.7 Comparison between End to End (E2E) and Peer to Peer (P2P) delay mechanisms 54
13
LIST OF TABLES
14 Investigation of Time-Synchronization
Glossary
Correction field It is a field in the Follow Up message that contains the path delay experi-
enced by the message. It is 8 bytes in size and has a nanosecond and sub-nanosecond
field.
Disabled-port It is the port that is not IEEE 802.1AS capable[12].
End-Node It is the end point in the Ethernet network. It can either be a grand-master or a
slave.
Ergonomics It is the practice of designing products, systems or processes to take proper
account of the interaction between them and the people who use them.
Ethernet Switch It is a computer networking device that connects devices together on a
computer network, by using packet switching to receive, process and forward data to the
destination device.
Grand-Master This clock is the source of time for all other nodes in the network. It has an
accurate time reference.
Infotainment It is a collection of hardware devices installed into automobiles, or other forms
of road transportation, to provide audio or video entertainment, as well as automotive
navigation systems.
Master-port It is the port closest to the Grand-Master and is the relative source of the Sync
messages [12].
MaxIntervalFrames It is the number of frames in an interval of time.
Passive-port It is a port that is neither master nor slave[12]..
peerDelay It is the path delay between two entities in a network.
preciseOriginTimestamp It is the time of departure of the Sync message from the Grand-
Master. It is inserted in the Follow Up message.
residenceTime It is the amount of time the Sync message spends in the switch.
15
Glossary
Slave-port It is the port that is connected to the Master-port and receives the Sync mes-
sages[12].
StreamID It is the unique identifier for a stream to distinguish from different streams.
Time Synchronization It is the synchronization of internal clocks of several control units to
a reference clock over a network..
Time-stamp It is the time of departure of the Sync message from the Grand-Master.
16 Investigation of Time-Synchronization
Glossary
17 Investigation of Time-Synchronization
Acronyms
ABS Anti-lock Braking System.
ADAS Advanced Driver Assistance System.
AVB Audio Video Bridging.
AVnu AVnu Alliance.
AVTP Audio Video Transport Protocol.
BC Boundary Clock.
BE Best effort.
BMCA Best Master Clock Algorithm.
CAN Controller Area Network.
CBS Credit Based Shaper.
E-AVB Ethernet Audio Video Bridging.
E2E End to End.
ECU Electronic Control Unit.
EMS Engine Management System.
FSM Finite State Machine.
GPS Global positioning system.
gPTP Generalized Precision Timing Protocol.
IC Instrument Cluster.
IEEE Institute of Electrical and Electronics Engineers.
IVN In-Vehicle Networking.
LIN Local Interconnect Network.
18
Acronyms
MAC Medium Access Control.
MFS Maximum Payload Size.
MIF Max Interval Frames.
MIL Malfunction Indication Lamp.
MOST Media Oriented Systems Transport.
NTP Network Time Protocol.
NXP NXP Semiconductors.
OEM Original Equipment Manufacturers.
OH Overhead.
Open Alliance OPEN Alliance SIG.
OS Operating System.
P2P Peer to Peer.
PCP Priority Code Point.
PHC PTP Hardware Clock.
PHY Physical layer.
PTP Precision Timing Protocol.
QoS Quality of Service.
SMSC Standard Microsystems Corporation.
SPS Strict Priority Scheduling.
SR Stream Reservation.
SRP Stream Reservation Protocol.
TC Transparent Clock.
TSN Time Sensitive Networking.
TTE Time Triggered Ethernet.
TTTech TTTech Computertechnik AG.
TU/e Eindhoven University of Technology.
UTP Unshielded Twisted Pair.
VLAN Virtual Local Area Network.
19 Investigation of Time-Synchronization
This page is intentionally left blank.
Chapter 1
Introduction
Automobiles have evolved from just mechanical devices to a combination of electrical, elec-
tronic and mechanical devices. Today’s auto-mobiles contain a number of different electrical
and electronic components which together are responsible for monitoring and controlling the
vehicle. Many components, from the Brake system (Anti-lock braking) to the Instrument Clus-
ter (IC) and the Engine Management System (EMS) can communicate with each other and
other neighbouring systems. Modern automobiles have more than 50 Electronic Control Unit
(ECU)s connected together.
The automotive industry has been revolutionized by the introduction of electronics. The in-
dustry has seen an exponential increase in the number of electronic systems since the mid 20th
century. The developments in the field of electronics have enabled the automotive engineers to
deliver high performant, safe and reliable products to their customers. The constant growth
and improvements in the performance and reliability of hardware, coupled with the flexibility
provided by the software have improved the quality of the vehicles to a great extent.
The main aim of these electronic systems has been to aid the driver and passengers to have a
safe and comfortable ride and to ease the process of controlling numerous devices in the vehicle.
For example the introduction of Anti-lock Braking System (ABS), Airbags etc., have improved
the safety and comfort of the driver and passengers. We also see that many devices in the vehi-
cle like the wipers, headlights, indicators are controlled by electronics. Networking has enabled
the designers to reduce the cabling significantly and place the switches in ergonomic locations.
The ECU was introduced in the car to control a system of sensors and actuators. This consisted
of a micro controller capable of controlling and monitoring these devices. However this proved
to be insufficient due to the introduction of more ECUs into the vehicle and many functions
needed to be distributed across several ECUs. For example the EMS had access to the vehicle
speed sensor typically mounted on the differential of the vehicle and this value calculated by the
EMS is required by the ABS to perform its functionality. If this had to be done independently
by both the systems each ECU should have access to its own sensor. This would prove to be
costly and thus the concept of networking was introduced. This would enable the ECUs to
CHAPTER 1. INTRODUCTION
Communication Channel
Figure 1.1: Point to point networking
share information and distribute information processing across different control units.
Until the beginning of the 90s, the exchange of data between ECUs happened in a point-to-point
fashion as shown in Figure 1.1. However this resulted in complicated systems as each ECU had
to be connected to every other ECU thus making this an inefficient way of sharing data. This
also increased the weight, cost and complexity. Further diagnosing problems in the vehicle was
difficult. These issues resulted in the development of networks where the communications are
multiplexed over a medium shared by all ECUs. This had led to many networking standards
like the K-line, Controller Area Network (CAN), Local Interconnect Network (LIN), FlexRay,
Ethernet etc. The development networks were aided by the advancements made in the field of
software.
The software developed for these ECUs have evolved tremendously and has enabled precise
control of the actuators like the fuel injector and have improved the performance of the vehicles
to a great extent. These software are becoming more and more structured, reliable and are gov-
erned by a number of standards. These developments in software and networking have enabled
effective diagnosis of faults in the vehicles at the service centres. The intelligence has been built
into these ECU, sensors and actuators to detect faults if any and report to the driver so that
the necessary actions can be taken. For example a fault in the fuel injector is detected by the
Engine Management System (EMS) and is communicated over the network to the Instrument
Cluster (IC) and is indicated by illuminating a Malfunction Indication Lamp (MIL) (Figure
1.2). As another example, in case of a crash the air-bag ECU sends a message over to the EMS
ECU to stop to prevent further movement of the car.
22 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
PC for diagnostics
Engine Management System
Service Engineer
CAN bus
Error in Sensor
MIL illuminated in cluster
Figure 1.2: Diagnostics and Error handling over CAN [1]
The overall safety of the vehicle depends on communication between these various ECUs.
While communicating with each other, ECUs are responsible for a variety of activities like
predicting crashes, detecting errors, controlling the engine, entertainment and climate control
in car etc. Future automotive applications require higher performance and reliable computing
resources. Both the processing and networking technologies are driven by the market which
redefines the way automotive systems are designed. The different performance requirements
throughout a vehicle, as well as the competition among companies, have led to the design of a
variety of communication networks.
1.1 Current networking solutions
An IVN is a specialized internal communication network that interconnects components inside
a vehicle. Some of the popular networks are listed below. The IVNs have evolved over a period
of time (figure 1.3) . Some of the most common IVN standards include CAN, LIN, FlexRay,
Media Oriented Systems Transport (MOST), k-line with CAN being the most popular among
the networks due to its low cost and simplicity.
Figure 1.3: Evolution of automotive networking technologies [2]
23 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
Different applications requires different networking solutions. All functions and systems in
the car need different QoS. Hence the requirements expected from the networks vary based on
the domain its used in. In-car embedded systems is divided into several domains based on their
common goals and performance requirements. For example the Powertrain domain consists
of ECUs that typically control the engine and transmission, chassis domain ECUs control the
dynamics of the vehicle like the suspension and the infotainment domain ECUs handle the
multimedia applications in the vehicle.
Now when we consider the domains, Powertrain domain requires a reliable communication
which can be achieved by CAN. However some applications like controlling doors, windows
etc., do not require the extensive features and advantages provided by CAN. Thus low cost
and bandwidth networking solution like LIN is used. For time critical applications FlexRay is
used. However multimedia applications require more bandwidth and has led to the develop-
ment of networking solutions like MOST and Ethernet. Some of these networks are explained
in Appendix A.
1.2 Ethernet
Consumer and automotive electronics have always been separate worlds due to the differences
in requirements and focus. However recent developments and growing requirements in both
industries have enabled them to converge and reap the benefits of each other.
One of the major challenges faced by network design engineers was the bandwidth provided
by CAN and other networks. These limitations can be overcome by the introduction of Ether-
net as an in-vehicle networking standard. This is necessary for the multimedia applications in
the car. Ethernet standard has proven itself to deliver in the past and has been established for
quite sometime. Ethernet a technology of the past is now becoming the future of automotive
networks with some modifications to it. It is this ability of Ethernet to adapt, evolve and change
to meet the changing bandwidth requirements [2].
The development of Ethernet as an in-vehicle network for today’s cars is broadly being discussed
by many companies and scientific communities. There are many studies being conducted to ex-
plore the capabilities of Ethernet-based automotive networks that can handle mixed-critical
(hard/soft real-time, best-effort) traffic. The in-car infotainment is one of the developing fields
and some of the currently available solutions are costly and are mostly proprietary. Many au-
tomotive manufacturers concentrate on the in-car infotainment as this is one of the factors that
affects the customer perception and adds value to the product. Further with the increasing
competition in the recent times features like navigation, music, video and radio have become a
standard and necessary part of the infotainment package.
24 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
1.2.1 Applications
Ethernet can also be used to establish hard real-time audio/video communication between the
ECUs. AVB is a set of communication standards designed for transforming a network into a
real-time streaming capable system. Some of the applications which require high bandwidth
include reverse parking assistance, night vision cameras, blind spot detection, navigation, music
and video systems etc. The Advanced Driver Assistance System (ADAS) typically improves the
safety, risk of damage and connectivity on the move. Figure 1.4 gives an overview of the ADAS.
ADAS is an important feature which would play a key role in the development of autonomous
cars.
Figure 1.4: Advanced Driver Assistance System [3]
Over the period of time entities like Global positioning system (GPS) navigation, multimedia
speakers etc., which were considered a luxury has become a necessity. This has led to the
development of the infotainment domain. infotainment combines entertainment and information
delivered to the customers. This requires a high bandwidth because of its streaming application.
Figure 1.5 shows a typical layout of the in-vehicle infotainment system.
Figure 1.5: Example Layout of an Infotainment System[4]
25 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
1.2.2 Benefits
One of the key reasons behind the development of Ethernet as an automotive network is be-
cause of its low cost and the maturity of the technology (as this has evolved over a long period).
However in order to adapt this technology for automotive applications it has to undergo some
restructuring for satisfying the QoS requirements. AVnu is a consortium of professional, au-
tomotive and consumer electronics companies working together to establish and certify the
interoperability of the AVB standards.
Ethernet is currently under development for handling non-critical data. To extend Ethernet
to handle time-critical data a deterministic real-time scheduled Ethernet communication called
Time Triggered Ethernet is under development. This is being actively developed by the Time
Sensitive Networking (TSN) group of AVnu. This is now being actively promoted by TTTech
Computertechnik AG (TTTech) for safely critical applications.
Ethernet is a packet switching network that enables the messages to be broken down into
packets and enable simultaneous transmission of multiple packets. These messages are han-
dled by the Ethernet Switch and are forwarded to the right destinations [2]. For example let
us consider an example as shown in Figure 1.6. If we consider this network messages can be
transferred at 100Mbps in both directions of the links highlighted. Even though the links have
a maximum speed of 100Mbps theoretically an aggregate throughput of 400Mbps is possible.
With the switched network structure the networks are more scalable (Figure 1.8) and make
them a good candidate to be used as an automotive backbone network as shown in Figure 1.7.
A backbone network is one that connects all the ECU domains in a vehicle.
Figure 1.6: Packet switching and simultaneous exchange [2]
26 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
Figure 1.7: Ethernet as a Backbone network [5]
Figure 1.8: Scalability of Ethernet networks by adding Switches [2]
BroadR-Reach is an Ethernet physical layer standard designed for automotive Ethernet. It
is developed and maintained by the OPEN Alliance SIG (Open Alliance) consortium. This
standard realizes simultaneous transmit and receive operations on a single unshielded twisted
pair cable. The advantage of BroadR-Reach is that it is low cost, weight, better power saving
modes and robust to all environmental conditions. Figure 1.9 gives the main components of an
automotive BroadR-Reach link.
27 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
Figure 1.9: BroadRreach technology of NXP PHY TJA1100 [5]
The OPEN Alliance SIG consortium was formed between Broadcom, NXP, and Harman
and many companies to promote automotive Ethernet. Almost all major Original Equipment
Manufacturers (OEM)s have plans to migrate to Ethernet. Thus Ethernet is becoming the
future of automotive networks.
1.2.3 Comparison
Each of the above mentioned networking technologies have their own advantages and disadvan-
tages. Some of these are restricted by the type of application, performance etc., eg. MOST
is primarily used for media applications and FlexRay is use for time critical applications. To
summarize the Table 1.1 gives a comparison between the above discussed networks based on
different parameters. Further Figure 1.10 summarizes the comparison of the discussed networks
with respect to bandwidth and cost.
Figure 1.10: Cost Vs Bandwidth for various networking technologies [5]
28 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
Table 1.1: Comparison of different In-Vehicle wired networks Source:[2]
No Parameter Ethernet CAN FlexRay MOST LIN
1 Max Band-
width
(Mb/s)
100 per link, full-
duplex
1 20 150 0.02
2 Maxi Num-
ber of nodes
Limited by the
number of switch
ports
30 22 64 16
3 Network
Length
15m / link 40 m 24 m 1280 m 40 m
4 MAC Full-duplex Arbitration,
re-
transmission
Time-
Triggered
Time-Triggered Time-
Triggered
5 Cost Relatively high Low Low High Very Low
6 Topologies Star, tree, daisy
chain
Bus Bus, star,
hybrid
Ring Bus
7 Sleep
modes
Yes Yes Yes Yes Yes
8 Standards Open Alliance ISO 11898 FlexRay
consortium
Originally propri-
etary,MOST Co-
operation
ISO 17987
9 Safety criti-
cality
No. Should be
possible with
TTEthernet
Yes Yes No No
10 Availability Multiple vendors Many Few One Many
11 SoC Many Many Many Many Many
12 Cabling UTP UTP UTP Optical 1-wire
13 Error detec-
tion
Strong Strong Strong Strong Weak
14 Applications Infotainment,
backbone,
TTEtherent
in future for
safety critical
General use Safety criti-
cal, drive by
wire
Infotainment Switches,
doors etc
1.3 Motivation - Time Synchronization
The automotive applications require higher performance and reliable computing resources. Mod-
ern cars nowadays have sophisticated multimedia devices for assisting and improving the ride
quality. These include the drivers assistance systems like reverse parking assistance, night vision
cameras and infotainment systems which include navigation, music systems etc. The increasing
bandwidth requirements has led to the introduction of Ethernet as an in-vehicle networking
solution.
29 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
As part of the migration to Ethernet IVN, AVB a set of standards developed for media stream-
ing applications has been adopted. One key element of AVB is Time Synchronization among
the distributed control units. This is necessary to ensure a good QoS for media streaming.
For example when we consider the reverse parking assistance system it uses a combination of
cameras to detect rear collisions. In order to display the camera streams in real-time the display
has to be synchronized with the cameras so that it can display simultaneous frames captured
by the cameras.
It is therefore very important to study the time synchronization mechanism, its behaviour and
performance. The importance of studying synchronization can be attributed to the following
reasons:
• To establish a common time reference and alignment of time between distributed nodes.
• Critical for real-time applications, control and measurement systems, and lip sync in voice
and video over network etc.
• Execute coordinated actions, co-ordinate measurement instants, reference events, deter-
mine the age of data items, track security breaches
1.4 Problem Statement
From the above discussion we deduce the problem statement:
Problem Statement
Given AVB (automotive) over Ethernet as scope we study the impact of
• Synchronization parameters (Synchronization interval, delay mechanism,
delay measurement interval, announce interval, time-stamping mechanism
etc.)
• Network parameters (Traffic class, packet size, message frequency etc.)
• End node parameters (Processor load, application priority)
on the quality of synchronization to reason about how and why a parameter
affects the synchronization through relevant measurements, tests and plots.
1.5 Goals and Research questions
We evaluate the problem statement by breaking it down into the following four research ques-
tions / goals:
Question 1: How do the configuration parameters of the synchronization affect the
quality of synchronization?
• How do the various identified synchronization configuration parameters such as synchro-
nization, peer delay interval, delay mechanism etc., affect the quality of synchronization?
30 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
• How and what are the inaccuracies affecting the synchronization?
• Why do these parameters affect the quality of synchronization?
• What is the achievable quality of synchronization with automotive AVB specific synchro-
nization configurations?
Question 2: How does the system parameters affect the synchronization process?
• How do network parameters like network traffic, type of network traffic, message priority,
packet size, message frequency etc., affect the synchronization?
• What is the effect of load on the micro-controller running the synchronization protocol?
• What are the system load conditions that cause the synchronization quality to drop?
Question 3: How does the synchronization protocol affect the system?
• What is the effect of the synchronization protocol on the network (Bandwidth utilization,
switch residence time etc.,?
• What is the effect of the synchronization protocol on the micro-controller (end nodes and
switch) running the protocol?
• What is the impact of AVB and automotive AVB specific synchronization configurations
on the system (end nodes and Switches)?
Question 4: What are the potential benefits and bottlenecks of using IEEE 802.1AS
protocol in an automotive environment (if any)?
• What are the potential bottlenecks of the setup used?
• How and why does the implementation of synchronization support on the switch impact
the synchronization between two end nodes?
• How does the loss of synchronization affect the application using synchronization?
1.6 Thesis overview
The thesis is organized as follows:
• Chapter 1: Introduction presents a brief introduction and compares the various in-
vehicle networking solutions currently available.
• Chapter 2: Related work and Background presents the structure and the function-
ality of the AVB stack.
• Chapter 3: Time synchronization explains the time synchronization protocol in detail
along with the related work.
• Chapter 4: Experimental setup presents the hardware and software selection, switch
software implementation and the setup of the complete network.
31 Investigation of Time-Synchronization
CHAPTER 1. INTRODUCTION
• Chapter 5: Experimental Methodology explains the experimental methodology and
the steps followed during the experiments.
• Chapter 6: Experiments, Results and Analysis discusses the various experiments,
the results and the analysis of the results.
• Chapter 7: Conclusion summarizes the findings and presents the future work.
• Appendix A gives an account of some of the current networking solutions.
• Appendix B provides the formats of the messages used in the Generalized Precision
Timing Protocol (gPTP) protocol.
• Appendix C contains the gPTP configuration used for linuxptp.
• Appendix D explains in brief how various types of graphs and plots used in the thesis
have to be interpreted.
32 Investigation of Time-Synchronization
Chapter 2
Related work and Background
This section gives a brief description about Audio Video Bridging (AVB), its components,
applications and related work.
2.1 Audio Video Bridging
AVB is an emerging standard that extends Ethernet to support multimedia streaming. The
Ethernet Audio Video Bridging standard adds QoS features like time-synchronized low latency
streaming services and bandwidth reservation to make it possible to carry audio and video sig-
nals on a standard Ethernet line.
In 2005 a task group was created in the IEEE 802.1 working group called the Audio video
bridging task group. To introduce the high - bandwidth and established networking solution
like Ethernet into a car the task group has established a number of working specifications [21].
Figure 2.1 gives an overview of these protocol specifications and their usage in the stack. The
various layers of the AVB stack are as follows:
• IEEE 802.3: Ethernet physical layer specifications.
• IEEE 802.1BA: Audio Video Bridging (AVB) Systems.
• IEEE 802.1AS: Generalized Precision Timing Protocol (gPTP).
• IEEE 802.1Qat: Stream Reservation Protocol (SRP).
• IEEE 802.1Qav: Forwarding and Queuing for Time-Sensitive Streams.
• IEEE 1722: Audio Video Transport Protocol (AVTP).
• Application: Streaming media application.
The primary objective of the AVB implementation is to :
a. Provide a common and precise clock reference to the network.
b. Reduce network delays.
c. Avoid interference from non time sensitive traffic.
CHAPTER 2. RELATED WORK AND BACKGROUND
Application
BMCA
Ethernet IEEE 802.3
Time Synchronization
IEEE 1588 / 802.1AS
Stream Reservation
ProtocolIEEE 802.1Qat
TCP/IP
Layer2: Transport
protocol IEEE 1722
Forwarding and queuing
IEEE 802.1Qav
Figure 2.1: Audio Video Bridging Stack [6]
These standards together address the drawbacks in the existing systems such as synchro-
nization of different streams of audio and video, buffering delay because of the network, and
resource reservation. AVB addresses the shortcomings and provides a highly flexible and af-
fordable Ethernet-based solution. In the following section we will discuss the different layers of
the AVB in detail.
2.1.1 Applications
AVB is used for many application like Aeronautic Ethernet networks (Figure 2.2) for passenger
addressing, crew telephones, cabin video monitoring system etc., [7].
Figure 2.2: AVB application in Aeronautics [7]
Some of the other applications of AVB include the home entertainment system, stadium
entertainment system, studios etc. The focus of this thesis is towards the application of AVB to
34 Investigation of Time-Synchronization
CHAPTER 2. RELATED WORK AND BACKGROUND
automotive Ethernet networks especially for infotainment and ADAS [8] purposes. In order to
use AVB for this purpose it must be possible to synchronize multiple streams so that they are
rendered correctly in time, the network delays experienced by the streams must be minimal and
deterministic and the network resources are available as and when the application requires it [22]
[23]. Figure 2.3 shows a typical Ethernet network layout in a car that is used for infotainment
and driver assistance.
Figure 2.3: Ethernet AVB in cars [8]
2.1.2 Stream Reservation
The Stream Reservation Protocol (SRP) [IEE 802.1Qat] is one of the core functionality of the
AVB stack. It allows the talkers to advertise their content to the listeners. The SRP establishes
a path from the talkers to the listeners through a bridge. It also is used to allocate and release
bandwidth in an AVB network. The SRP allows two stream reservation classes(items 1 and 2
Table 2.1 ). The current Ethernet Audio Video Bridging (E-AVB) supports only two intervals
and these intervals place a constrain on the uncompressed audio streams that result in odd data
block sizes [24]. With this limitation in mind the automotive AVB introduces two additional
classes (items 3 and 4 of Table 2.1).
Table 2.1: Stream reservation classes [19]
S.No Class Network delay (max) Interval
1 Class A 2ms 125µs
2 Class B 10ms 250µs
3 64 Sample, 48kHz 15ms 1333 µs
4 64 Sample, 44.1kHz 15ms 1451 µs
The maximum bandwidth that can be allocated to the Stream Reservation (SR) classes is
75%. So in a 100 Mbits/s network the maximum bandwidth that can be allocated to the SR
class is 75 Mbits/s. The stream reservation protocol according to IEEE 802.1 Qat functions is
shown in Figure 2.4.
1. The talker first generates an advertise frame with a StreamID, MaxFrameSize and Max-
35 Investigation of Time-Synchronization
CHAPTER 2. RELATED WORK AND BACKGROUND
Figure 2.4: Stream Reservation Protocol [9]
IntervalFrames. The frame is multi-cast onto an AVB network. The stream bandwidth
(streamBW ) is calculated [9] as:
streamBW = (MFS +OH) ∗MIF/IntervalT ime (2.1)
Where,
• Maximum Payload Size (MFS)
• Max Interval Frames (MIF)
• Overhead (OH)
The interval time is dependent on the AVB streaming class which is determined by the
priority value of the Virtual Local Area Network (VLAN).
2. Once the streamBW is calculated and the output port of the switch has resources, the
frame is forwarded through the port and if sufficient resources are not available the frame
is modified to a talker failed frame state and forwarded to listeners along with the failure
information.
3. Once the listener has received the advertise frame from the talker without any error, it
can register to it. The listeners to subscribe to the specific stream transmit a listener
ready frame and allocate the required bandwidth along the path. In case of a resource
shortage or a problem in the bridge the listener ready frame is modified to listener asking
frame. It is then sent to the talker along with the error information.
4. A stream being sent by a talker can be stopped by sending a de-register stream frame
with the streamID to the listeners. This tells the listeners that the stream will no longer
be available and the bandwidth reservations are released.
5. Similarly a listener can de-register from a stream by sending a de-register attach frame to
the talker and release the network bandwidth reservations.
36 Investigation of Time-Synchronization
CHAPTER 2. RELATED WORK AND BACKGROUND
2.1.3 Forwarding and Queuing
Traffic shaping is a key technique in ensuring a good QoS. A priority based system would work
fine in a network where the high priority traffic is significantly less because the chances of col-
lision between the higher and lower priority traffic is less. This type of technique does not suit
a system where audio/video traffic is predominant and occupies a significant amount of the
bandwidth [21]. Earlier buffer sizes were increased to handle this. This is ok as long as the
application does not require a low latency. However current situations demand low latency for
both audio and video streams. This latency of the network also plays a significant role as it
decides the memory requirements of the bridges. The primary goal of AVB is to have a delay
less than 2ms over 7 hops for a SR Class A traffic and less than 50ms over 7 hops for SR Class
B traffic. In order to achieve these goals the Credit Based Shaper (CBS) was developed [IEEE
802.1Qav].
The CBS algorithm is used to select AVB frames for transmission. The algorithm defines
credits associated to each of the SR classes (Class-A, Class-B). A transmission is only allowed
when the credits are greater or equal than zero and no other frames are transmitted at the
same time. An AVB frame is dequeued and transmitted with the credits decreased at a rate
equal to the value of the sendSlope. The credits are increased at a rate equal to the value of
the idleSlope when a frame from the SR-Class is not transmitted. The algorithm limits the
maximum and minimum number of credits that can be accumulated by using the parameters
hiCredit and loCredit. Figure 2.5 gives an example [9] of the working of the CBS.
37 Investigation of Time-Synchronization
CHAPTER 2. RELATED WORK AND BACKGROUND
Figure 2.5: Working of Credit Based Shaper [9]
1. An AVB frame (Frame-A) arrives and is queued due to conflicting frames. The credits
are increased as per the idleSlope.
2. As soon as the transmission of the current frame is finished. Frame-A is selected for
transmission. The credits are reduced as per the sendSlope parameter.
3. Credits are set to 0 when there are no frames for transmission and the credits are positive.
4. Frame-B arrives and is transmitted immediately as there are no conflicting frames and
the credit value is greater than or equal to 0. The credits are decreased according to the
sendSlope parameter.
5. On the completion of transmission the credits are increased according to the idleSlope
parameter.
38 Investigation of Time-Synchronization
CHAPTER 2. RELATED WORK AND BACKGROUND
Figure 2.6: Credit Based Shapers [10]
Figure 2.6 gives an overview of the transmission selection scheme according to IEEE 802.1Qav.
The AVB traffic has the highest priority and can be transmitted only when its available credits
is greater than or equal to 0. The best-effort traffic has a priority based selection process [10].
2.1.4 Audio Video Transport Protocol
The Institute of Electrical and Electronics Engineers (IEEE) 1722 is a Layer-2 transport pro-
tocol that allows a type of encapsulation of audio and video frames. This enables the system
to improve the QoS. The protocol time-stamps the frames as a pointer to the receiver node so
that it can play the audio/video at a particular time. IEEE 1722 ensures that different listeners
are synchronized in addition to the IEEE 802.1AS. Figure 2.7 [9] shows the IEEE 1722 Audio
Video Transport Protocol (AVTP)frame.
The IEEE 1722 frame payload maximum frame size is limited to 1476bytes. The Ethernet
frame in addition to the payload also has other information such as the Header, StreamID,
AVTP Time-stamp, GatewayInfo and PacketInfo. The StreamID is used to identify and to
distinguish a stream. The AVTP Timestamp gives information about the presentation time
of a frame. It represents the time-stamp when the media sample was generated at the Talker
plus a constant time, Max Transit Time, to compensate for network latency. The Max Transit
Time represents the worst case network latency. The task group specifies two main and two
additional SR classes based on the transit(Table 2.1).
Figure 2.7: IEEE 1722 AVTP frame [9]
39 Investigation of Time-Synchronization
CHAPTER 2. RELATED WORK AND BACKGROUND
2.1.5 Time Synchronization
Time is a very important and critical physical quantity. This is so because the impact of time
is significant on the human perception of audio and video and this perception is expected to be
pleasant. Traditional systems render audio/video as a single device. With the advancements
in technologies there arose a need to stream this over a network. To achieve a good quality of
streaming a time synchronization was a key necessity. As a result it led to the development of
the IEEE 1588 - Precision Timing Protocol (PTP) [13]. Time synchronization is the key focus
of this thesis so this will be explained dedicatedly in Chapter 3.
2.1.6 Other related work
AVB traffic analysis
The paper [9] presents and evaluates AVB network by using simulation. The observations made
were as follows:
• The Payload size of AVB frames impacts the performance. The latency is improved by
reducing the frame size. The latency of both classes of AVB remains the same except for
the fact that the jitter is improved for class A.
• The application requirements are achievable for AVB streaming even over 7 hops and
network traffic.
• Control data injected as a non-AVB frame is not significantly influenced by the network
traffic.
Extending AVB with Time Triggered Ethernet (TTE)
Efforts are being made to enable the co-existence of AVB and TTE. This would enable the
critical and non-critical traffic to co-exits. The introduction of TTE would serve as a replacement
for the FlexRay network which are designed for time critical applications [10][25]. As per the
papers [10] [25] the main challenge in achieving this type of system is arriving at an optimal and
compact schedule (one without gaps). The experimental analysis [10] shows that scheduling of
TTE frames has a significant impact on AVB frames especially in case of a compact schedule
with consecutive TTE frames. However by reducing the Maximum transmission unit (bytes) and
optimizing the schedule by changing the gap size, the performance of AVB and BE traffic can be
improved. Additionally [25] describes a software architecture and analysis for the co-existence
of AVB and TTE traffic.
40 Investigation of Time-Synchronization
CHAPTER 2. RELATED WORK AND BACKGROUND
Figure 2.8: Co-existence of AVB, TTE and BE traffic [10]
41 Investigation of Time-Synchronization
Chapter 3
Time Synchronization
3.1 Introduction
This section gives a brief description about the time-synchronization, its need, the IEEE 1588
and IEEE 802.1AS standard, the working principle and related work.
The need for time-synchronization depends on the application being developed. For exam-
ple a person during airport transit has to have a close eye on the time displayed in the airport
clock so that he does not miss his flight. Many systems require a precise sense of time. In a
manufacturing plant which is completely automated a common notion of time is very essential
for the effective functioning of the plant. With the emergence of distributed processing there
has been more emphasis on time-synchronization.
To give an intuitive idea, consider a bunch of computers with their own clock as shown in
Figure 3.1. The computers are inter-connected by a network. In order to synchronize these
clock they need to exchange time through messages. IEEE 802.1AS (gPTP) is nothing but a
specific way of doing this. gPTP is a specification of messages and the mechanism of exchang-
ing these messages to accurately pass on the time of a reference clock to all the entities in the
network. The synchronization process does not end with just exchanging this information once.
These clocks experience drift and hence this has to be done frequently. The analysis of the
gPTP is the key focus of this thesis. We will discuss this in detail in the following sections.
42
CHAPTER 3. TIME SYNCHRONIZATION
Clock1
Clock2
Network
Clock1
Clock2 Clock 4
Network
Clock3
Synchronization
Clock3
Clock4
Figure 3.1: Idea of Time Synchronization
There are many ways of achieving time-synchronization which include the Network Time
Protocol (NTP), the Precision Timing Protocol (PTP), the pulse per second input from Global
positioning system (GPS) receiver etc. Table 3.1 shows the comparison between different syn-
chronization methods.
Table 3.1: Comparison of different synchronization protocols[20]
S.No Parameter NTP PTP GPS
1 Network size Large area Few subnets Large area
2 Cost Low Low High
3 Accuracy millisecond sub-microsecond sub-microsecond
4 Time source Internet Network (Grand-Master) Satellites
5 Computation requirement Low Moderate Moderate
3.2 Synchronization terminology
We consider a network with two nodes and connected by a switch. Figure 3.2 gives a graphical
representation of the various and frequently used terminology related to the synchronization
protocol.
43 Investigation of Time-Synchronization
Sync
Node aPort_in
Switch bPort_out
Node c
Sync
Time at Node a
Time at Node C
Ingress
Egress
(a) Slave Offset
(c) Residence Time
Sync
Sync
Egress
Ingress(b) Slave
Peer Delay
Egress
Ingress(b) Switch Peer Delay
(d) Sync Interval
(e) Peer Delay interval
Pdelay_Req
Pdelay_Req Pdelay_Req
Pdelay_Req
Figure 3.2: Synchronization Terminology
a. Slave offset: The Slave offset is the calculated time offset of the slave with respect to
the Grand-Master. This calculated value is used to correct the clock. The slave offset is
calculated in nanoseconds.
b. Peer delay: It is the measured propagation delay on the link between two clocks at both
ends of the link. It is measured in nanoseconds. The slave peer delay is the propagation
delay between the switch and the slave. The switch peer delay is the propagation delay
between the switch and the Grand-Master. It is calculated by exchanging peer delay
messages.
c. Residence time: It is the measured time spent by the Sync message on the switch. In
case of a network with more than one switch this is calculated by each switch on the path.
This is measured in nanoseconds.
d. Sync interval: It is the interval between successive Sync messages.
e. Peer delay interval: It is the interval between successive PDelay Req messages (mea-
surement period of peer delay).
3.3 IEEE 1588 and IEEE 802.1AS
IEEE 1588 is a synchronization protocol which is used to establish a common time reference
between different nodes in a network. This defines a master-slave architecture for clock distri-
CHAPTER 3. TIME SYNCHRONIZATION
bution among different clocks in the network. The IEEE 802.1AS which is part of the AVB
standards is a profile of the IEEE 1588. The IEEE 802.1AS is further simplified for use in
automotive E-AVB networks.
3.3.1 Messages
The following messages are defined as part of the IEEE 1588 / IEEE 802.1AS standard. Event
messages:
1. Sync : Message that is used as a reference for passing the reference time from the Grand-
Master to all the slave nodes.
2. Delay Req : Message that is sent by the slave node to the Grand-Master during the
calculation of the path delay using the End-to-End delay mechanism.
3. Pdelay Req : Message that is exchanged between peers to calculate the path delay using
Peer delay mechanism.
4. Pdelay Resp : Message that is exchanged between peers to calculate the path delay using
the Peer delay mechanism. This message contains the arrival time of the Pdelay Req
message.
General messages:
1. Announce : Message used to exchange clock properties with other nodes in the network
as part of the Best Master Clock Algorithm (BMCA).
2. Follow Up : Message that contains the Time-stamp of the Sync message.
3. Delay Resp : Message that is sent by the Grand-Master during the calculation of the path
delay using End-to-End delay mechanism. It contains the arrival time of the Delay Req
message.
4. Pdelay Resp Follow Up : Message that is exchanged between peers to calculate the path
delay using the Peer delay mechanism. This message contains the departure time of the
Pdelay Resp message.
5. Management : Management messages are used to access attributes and to generate certain
events.
6. Signaling : It is a message used to adjust the rate of reception of messages.
3.3.2 Clocks
The different types of clocks associated with the time-synchronization protocol can be broadly
classified into:
a. Ordinary clock.
b. Transparent clock.
c. Boundary clock.
45 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
Ordinary clock
The ordinary clock can be one of the following three types:
• Slave only This type of clock can act only as a slave as the name suggests which adjusts
its time based on the master.
• Master / Slave clock This type of clock can behave either as a master or slave. This type
of clock acts as a slave when there are other clocks in the network which have better clock
properties than itself. It acts as a master when there are no other clocks capable of being
a master.
• Grand-master clock This type of clock acts only as a master and never assumes the role
of a slave. It has a good clock quality and has an accurate source of time like GPS etc.
Transparent clock
This clock performs the time-stamping operation whenever a Sync message arrives or departs.
A Sync message enters the transparent clock device and a hardware time-stamp is generated.
It then enters the core switching element and departs through a different network port. While
in the core switching element it may be queued due to a busy port. The departure and arrival
timestamps are used to update the correction field in the Follow Up message in case of a two-
step synchronization. If the transparent clock is a one-step clock, it has to update the Sync
message, which also has a correction field, on the fly.
Figure 3.3: Transparent clock [11]
The Transparent Clock (TC) comes in two flavours, E2E and P2P. Each of these has its
own advantages or disadvantages. Table 3.2 gives a comparison between the E2E and P2P.
46 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
Table 3.2: Comparison of E2E and P2P transparent clocks
S.no Parameter E2E-Transparent Clock
(TC)
P2P-TC
1 Visibility Master sees all slaves Hierarchical
2 Scalability Linear Linear
3 Calculation Calculates residenceTime Calculates residenceTime and
peerDelay for every connected
port
4 Architecture limitations None One:One connection on each
link
5 Delay calculation New calculation on master
change
All peerDelays are computed
beforehand so Grand-Master
change does not affect much.
Boundary clock
A boundary clock has one port which is in a slave state and gets time from a master clock.
All other ports are in a master state which spread time to downstream slaves. So instead of
tracking Sync messages and updating correction fields it absorbs Sync messages in the slave
port, sets its clock, and then generates new Sync messages through all the master ports.
Figure 3.4: Boundary clock [11]
3.3.3 Comparison of IEEE 1588 and 802.1AS
The IEEE 802.1AS (gPTP) is a profile of the IEEE 1588 (PTP) protocol and hence it is
important to understand how the IEEE 802.1AS protocol differs from the IEEE 1588 protocol.
The IEEE 802.1AS has been adopted for automotive applications with some modifications.
47 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
Table 3.3 gives comparison of the availability of the messages in IEEE 1588, IEEE 802.1AS
and IEEE 802.1AS (automotive) respectively. Table 3.4 gives a brief comparison between the
features of IEEE 1588, IEEE 802.1AS and IEEE 802.1AS (automotive) respectively.
Table 3.3: Comparison of message usage in IEEE 1588, IEEE 802.1AS and IEEE 802.1AS
(automotive)
S.No Message IEEE 1588 IEEE 802.1AS IEEE 802.1AS (auto)
1 Announce X X 7
2 Sync X X X
3 Follow up X X X
4 Delay Req X 7 7
5 Delay Resp X 7 7
6 Pdelay Req X X X
7 Pdelay Resp X X X
8 Pdelay Resp Follow Up X X X
9 Signaling X X X
Table 3.4: Comparison of IEEE 1588, IEEE 802.1AS and IEEE 802.1AS (automotive)
S.No Parameter IEEE1588 IEEE802.1AS IEEE802.1AS (auto)
1 Sync message 1-Step, 2-Step 2-Step 2-Step
2 Delay mechanism E2E,P2P P2P P2P
3 Best Master
Clock Algorithm
(BMCA)
Yes Yes (Different
from IEEE 1588)
No
4 Sync Interval Not-specified 125ms 31.25ms, 125ms, 1s
5 Delay interval Not-specified 1s 1s - 8s
6 Path trace Not-specified Yes Yes
7 End node Clocks Slave only,
TC,BC, ordinary
TC, BC, ordinary TC, Slave only, Grand-
Master
8 Peer delay calcu-
lation
Not-specified done on all port of
TC
Sufficient to calculate
port connected to
Grand-Master
3.4 Working principle
The IEEE 802.1AS (gPTP) protocol has many mechanisms to achieve the synchronization
among the nodes in the the network. In the following section these mechanisms are explained
in brief.
48 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
3.4.1 Best Master Clock Algorithm
The synchronization hierarchy is created from the available nodes using the BMCA. The BMCA
algorithm determines a spanning tree for the synchronization and sets the Grand-Master as its
root [9]. The algorithm involves the exchange of Announce messages and results in the selection
of a Grand-Master which would then serve as the reference for all other clocks in the network.
The Announce messages contain information about the respective properties of the clock that
enable all other nodes to compare these properties and select a Grand-Master.
Figure 3.5: BMCA spanning tree with Master-port Slave-port Disabled-port Passive-port [12]
The IEEE 802.1AS (gPTP) BMCA differs from the IEEE 1588 (PTP) BMCA in the follow-
ing ways [26]:
• In gPTP a time-aware system cannot be a slave only clock where as this is possible in PTP
and hence all time-aware systems are required to participate in best master selection.
• In gPTP there is no foreign master configuration as in PTP.
• In gPTP there is no pre-master state of a port determined as a master as in PTP.
3.4.2 Time-Stamping Mechanism
Time-stamping is an important aspect of the time synchronization. This is one of the properties
that decides the quality of synchronization. All the messages that are sent over the Ethernet
are time-stamped. Figure 3.6 shows the various levels of the stack where time-stamping can be
performed. The Time-stamping accuracy depends on how close the Time-stamp is acquired to
49 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
PHY
MAC
Drivers
IP gPTP
UDP
gPTP
MII
Software – lowaccuracy
Hardware assisted – High accuracy
Hardware –Highest accuracy
Inaccuracy
High
Low
Least
Figure 3.6: Software and Hardware time-stamping
the physical layer. The closer the source of Time-stamp to the physical layer and the lesser is
the jitter [27].
Software Time-stamping solutions take the Time-stamp at either the application or driver
level. The inaccuracy associated with this is very non-deterministic. This is primarily due to the
jitter associated with the software stack. This jitter depends on various factors like operating
system, other applications running along with gPTP, other applications using the network stack,
external interrupts etc. However Time-stamping at the driver level would significantly reduce
the jitter this requires the drivers to be changed.
Hardware-Assisted Time-stamping solutions take the Time-stamp from the link between
the Medium Access Control (MAC) and the physical layer. The MAC is combined with a time-
stamping module to support precise time-stamping of incoming and outgoing gPTP frames.
It has a very low inaccuracy compared to the Software Time-stamping. In order to read the
Time-stamps the gPTP application would require an interface to the Time-stamping unit. In
case of Linux this provided by the SO TIMESTAMPING socket option of the kernel.
The paper [28] presents the performance analysis of the IEEE 802.1AS using hardware-assisted
Time-stamping. The average offset achieved was 5µs. This is not sufficient for automotive
networks. The standard also requires the in-accuracy to be maximum 1µs.
Hardware Time-stamping solutions Time-stamps the messages in the physical layer external
to the micro-controller. This is the most accurate Time-stamping solution as the jitter associ-
ated is the least with respect to the software and hardware assisted time-stamping solutions and
the time-stamp acquired in the Physical layer (PHY) is the actual time of egress of the message.
50 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
The DP83640 from Texas instruments is a device that supports this. Since the Time-stamping
is done outside the micro-controller it reduces the cost of the micro-controller. In that case a
simple micro-controller without any dedicated hardware for time-stamping can be used. Table
3.5 shows the comparison of the different Time-stamping methods discussed above.
However the accuracy of the time-stamp generated in the PHY also depends on the frequency
of the clock of the PHY. From the above discussed time-stamping solutions I would expect the
Hardware-Assisted time-stamping to have more accuracy than the other solutions as the clock
used is within the micro-controller which would typically have a higher frequency of operation
than the PHY.
Table 3.5: Comparison of time-stamping methods
S.No Parameter Software Hardware-assisted Hardware
1 Jitter High Low Least
2 Platform Independent Dependent Dependent
3 Resources None Software routine to read
time-stamps
Software rou-
tine to read
time-stamps
4 Implementation Simple Complex Complex
5 Sources of Error applications,
OS,interrupts etc.
Incoming and outgoing
network traffic
Incoming and
outgoing network
traffic
6 Complexity Simple relatively complex complex
7 Slave offset µs to ms ns ns
8 Cost Less High relatively low
3.4.3 Synchronization Mechanism
Two Step
A Sync message is frequently sent from the master to the network to announce its time. In case
of the two step mechanism (Figure 3.7) the Sync is sent and the Time-stamp of its egress time
is recorded, fetched and sent to the slave through the Follow Up message. Once the Sync is
received by the slave it initiates the E2E delay mechanism to find the path delay with respect
to the Grand-Master. The Follow Up message contains [26]
• The preciseOriginTimestamp of the Sync message.
• The Cumulative rate Ratio.
• The Correction field.
51 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
The offset is calculated as per the Equation 3.1 and the path delay is calculated as per the
Equation 3.2 [13].
Offset =t2 + t3 − t1 − t4
2(3.1)
Delay =t2 + t4 − t1 − t3
2(3.2)
t1 current = preciseOriginT imestamp+ Correctionfield+ peerDelay (3.3)
Where
• t1 and t2 are the egress and ingress times of the Sync respectively.
• t3 and t4 are the egress and ingress times of Delay Req and Delay Resp messages respec-
tively.
Note: The current time of the Grand-Master clock calculated by the slave is as mentioned in
Equation 3.3.
t2
t3
t4
Sync
Delay_Request
Delay_Response
t1
Master Slave
t1
t4
Follow_Up
Figure 3.7: Two-step synchronization mechanism [13]
52 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
One Step
The one-step synchronization (Figure 3.8) is similar to the two-step mechanism but the difference
is that an accurate time-stamp is placed in the Sync message on the fly. Even though one-step
synchronization is economical it is expected to be less precise than the two-step synchronization
as the time-stamping will not be accurate as it has to be inserted into the message while it is
leaving. Further the One-step implementation requires the PHY to support Time-stamping.
Table 3.6 gives a comparison between one and two step mechanisms.
t2
t3
t4
Sync
Delay_Request
Delay_Response
t1
Master Slave
Time stamp
inserted
t1
t4
Figure 3.8: One-step synchronization mechanism [13]
3.4.4 Delay Mechanism
The selection of a delay measurement mechanism is based on the application and gPTP ca-
pability of the devices. The Peer-to-peer delay measurement mechanism is best in a network,
where all switches are PTP capable, i.e. they are either transparent clocks or boundary clocks.
If there are going to be any non-PTP aware switches, then we may want the end-to-end delay
measurement [29].
53 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
Table 3.6: Comparison of One-step and Two-step synchronization
S.No Parameter One-step Two-step
1 Time-stamp Accuracy Less accurate More accurate
2 Time-stamping PHY Software, MAC, PHY
3 Time-criticality Correction field update is time
critical - done on the fly.
Correction field update is not
time critical -done in Fol-
low Up.
4 Messages per interval 3 4 (with E2E) - 5 (with P2P)
In Figure 3.7 we can see the E2E delay measurement mechanism. Once the Sync and Fol-
low Up messages are received the slave clock initiates a Delay Req which reaches the master
and is time-stamped. The master then sends a Delay Resp with the arrival time of the De-
lay Req message. There is however a catch to this, The link is assumed to be symmetric i.e.
the forward delay is equal to the reverse delay.
Figure 3.9 shows the Peer to Peer (P2P) delay measurement mechanism. In this type of mea-
surement a clock sends a Pdelay Req message and the departure time is noted. The clock that
receives the Pdelay Request message responds with a PDelay Resp message with the arrival time
of the PDelay Req message and a PDelay Resp Follow up message with the departure time of
PDelay Response message. With the available time stamps the delay is calculated as per Equa-
tion 3.4. Note: A one-step version of P2P is also possible with the time-stamps incorporated in
the message [30].
peerDelay =t2 − t1 + t4 − t3
2(3.4)
Where
• t1 and t2 are the egress and ingress time-stamps of the PDelay Req message respectively.
• t3 and t4 are the egress and ingress time-stamps of the PDelay Resp message respectively.
Table 3.7 gives a comparison between the E2E and P2P delay mechanisms.
Table 3.7: Comparison between E2E and P2P delay mechanisms
S.No Parameter E2E P2P
1 Number of messages 2 3
2 Dependence Arrival of Sync message Independent of Sync Message
3 Connection type One to many One to one
4 Slave Visibility All slaves visible to master Master does not see all the
slaves
5 Standard IEEE 1588 IEEE 1588 and IEEE 802.1AS
6 Synchronization traffic Relatively high at the link
connected to master
Less
54 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
t3
t1
PDelay_Req
PDelay_Resp
Clock1 Clock2
Timestamp
PDelay_Resp_Follow_up
t2
t4
Timestamp
t3
t2
Figure 3.9: Peer delay mechanism [13]
3.4.5 Rate Ratio
The neighborRateRatio is ”the measured ratio of the frequency of the Local Clock entity of the
time-aware system at the other end of the link attached to this port, to the frequency of the Local
Clock entity of this time-aware system”[14]. The cumulative rateRatio is the ratio of frequency
of the Grand-Master to the local entity of the time-aware system[14]. It is the product of the
most recently received rateRatio multiplied by the neighborRateRatio. This will enable us to
do all calculations with reference to the Grand-Master time base.
The neighborRateRatio is calculated by using the departure and arrival times of a frequently
received message as per Equation 3.5. Figure 3.10 shows how rate ratio is calculated. The Sync
or the PDelay Resp message can be used as a reference for calculating the rate ratio as both
are frequently arriving messages.
neighborRateRatio =(t1n − t1)
(t2n − t2)(3.5)
Where
• t1n and t1 are the previous and current egress times of the message.
• t2n and t2 are the previous and current ingress times of the message.
55 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
t2
t1
Clock 1 Clock 2
t2_n
t1_n
Figure 3.10: Rate ratio calculation[14]
3.4.6 Working scenario
Figure 3.11 gives a brief overview of the working scenario of the time synchronization in a
system.
56 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
Sync
Node a
Switch
Controller
t1
Phy / MAC
Port_in
Switch b
PTP
Application
Follow_up (t1,Ca,Ro)
Ti
me
st
am
p
Port_out
Node c
t1_a
t1_b
t1_a
t1_b
Cb = Ca + (t3 –
t2)*rR + Pd * rR
Follow_up (t1,Cb,Ro’)
Sync
Ti
me
st
am
p
Ti
me
st
am
p
Phy / MAC
Ti
me
st
am
p
Ti
me
st
am
p
t2
PDelay_Request
PDelay_Response
PDelay_Response
_Follow_up
t1_p
t2_p
t3_p
t4_p
t3_p
Ti
me
st
am
p
Ti
me
st
am
p
Ti
me
st
am
p
PTP
Application
PDelay_Request
PDelay_Response
PDelay_Response
_Follow_up
t1_p
t2_p
t3_p
t4_p
t3_p
Ti
me
st
am
p
Ti
me
st
am
pT
im
es
ta
mp
Ti
me
st
am
p
Pd = (t2_p -
t1_p + t4_p -
t3_p) /2
Figure 3.11: Working Scenario of the IEEE 802.1AS protocol
• The Master node sends the Sync message. The Switch receives the Sync message and
forwards it on all its ports.
• The ingress and egress times are recorded by the switch for each of the ports and the
residence time of the Sync is calculated.
• The Correction field is calculated for each port using the residenceTime, peerDelay and
the rateRatio.
57 Investigation of Time-Synchronization
CHAPTER 3. TIME SYNCHRONIZATION
• The correction field on the Follow Up message is updated and forwarded to all the respec-
tive ports.
• The peerDelay of the link connected to the master is calculated by the switch as mentioned
in Section 3.4.4. Similarly the peerDelay of link connecting the switch and the slave is
calculated by the slave. In this all network delays are accounted.
• With the information from the Sync and the Follow Up message information the slave
calculates the offset with respect to the master and corrects its time.
3.5 Other related work
Paper [12] presents the results of the IEEE 802.1AS simulation model. The evaluation gives the
following information:
• The Synchronization process is not influenced by high network load (refer figure 3.13).
• The Grand-Master synchronization interval has a significant influence on the performance
(Figure 3.12).
• An averaging filter for propagation delay improves the synchronization performance.
Figure 3.12: Effect of Sync interval [12]
Figure 3.13: Effect of traffic on Synchronization [12]
58 Investigation of Time-Synchronization
Chapter 4
Experimental setup
This chapter describes the selection of hardware and software for the end-nodes, the software
development for the switch and the topology of the network.
4.1 End node
4.1.1 Hardware selection
The first step in setting up a network was the selection of the End-Nodes. The development
boards (end-nodes) selected for the implementation use a Freescale i.MX6Solo processor. The
i.MX6 based device was selected because the i.MX6 has a MAC combined with a time-stamping
module to support precise time-stamping of incoming and outgoing frames [31]. The Kon-
tron board (Figure 4.1) was selected initially but lacked the support for a kernel that had the
SO TIMESTAMPING socket implementation which was required for hardware assisted Time-
stamping.
We then selected the RIoTboard (Figure 4.2) which also uses a i.MX6Solo processor. Fur-
ther this had Yocto support with Linux kernel that supports hardware time-stamping. The
Yocto Project [32] is an open source collaboration project that provides templates, tools and
methods to create custom Linux-based systems for embedded products. The following are the
key features of the RIoTboard:
1. Freescale iMX6 solo processor (ARM Cortex A9 MPCore 1GHz).
2. Yocto Linux (kernel 3.10) with hardware time-stamping support.
3. HDMI, Audio out, Camera support etc.
4. 10M/100M/Gb Ethernet Interface
5. IEEE 1588 compliant MAC.
4.1.2 Software selection
The next step was the selection of the PTP application that would run on the RIoTboards
to establish synchronization between them. A number of open-source solutions were available
CHAPTER 4. EXPERIMENTAL SETUP
Figure 4.1: Kontron Board
[15]Figure 4.2: RIoTboard [16]
which included ptpd, ptpd2 [33], linuxptp [34], openptp [35] etc.
Linuxptp was selected because of its support for both one and two step synchronization. The
linuxptp application uses the SO TIMESTAMPING socket to retrieve the time-stamps gener-
ated by the MAC. SO TIMESTAMPING is an interface that generates timestamps on reception,
transmission or both and supports multiple time-stamp sources, including hardware [36].
Figure 4.3 gives an overview of the functioning of linuxptp. The linuxptp application ptp4l
on the Grand-Master sends the Sync and Follow Up messages through the network. The slave
on receiving these messages time-stamps them and the ptp4l application running on the slave
calculates the offset and corrects the PTP Hardware Clock (PHC). The phc2sys application is
then used to update the Linux system time using a servo mechanism [37]. We consider the PHC
as our reference.
Figure 4.3: Linuxptp working [17]
4.1.3 Installation and Configuration
After the selection process the next step was to get the Yocto image with the Linuxptp (V1.5)
and hardware Time-stamping enabled running on the RIoTboards. A Linux (Ubuntu) environ-
ment was used for the compilation. The images generated were mounted onto an SD card with
the RIoTboards configured to boot from the connected SD card.
Once the two boards were flashed a IEEE 802.1AS (gPTP) configuration had to be created. The
gPTP configuration was available as part of the Linuxptp source which needed modifications in
order to get the boards up and running.
60 Investigation of Time-Synchronization
CHAPTER 4. EXPERIMENTAL SETUP
4.1.4 Challenges
Installing the Linuxptp (V1.5) was a small challenge as a new recipe had to be created for Linux-
ptp and the image was re-compiled [38]. The pre-compiled image available from the RIoTboard
community had linuxptp (V1.3). This version was prone to bugs and hence a migration to V1.5
was necessary. Moreover V1.5 had many additional configurable features and was verified for
gPTP functionality.
A sanity check was performed by connecting the two nodes back to back and running the
synchronization software. During this phase initially when the application was started the
nodes did not start the synchronization process. On analysis it was found that the two nodes
were exchanging only the peer delay messages. A gPTP node would start synchronization only
if it is connected to another gPTP capable port. A port is marked as gPTP capable only if
the peer delay is less than the neighbor propagation delay threshold. This parameter was then
identified and increased to a larger value and synchronization was established.
4.2 Switch
Removed due to confidentiality.
4.3 Topology
The topology of the setup is a simple star topology as seen in figure 4.4. The two nodes (Grand-
Master and slave) are connected to two ports (ports 1 and 3). The grandmaster clock is the
primary time source, the switch acts as a TC and enables the slave clock to synchronize with the
Grand-Master clock. Port 4 is configured to be the host port and is connected to the on-board
micro controller.
61 Investigation of Time-Synchronization
CHAPTER 4. EXPERIMENTAL SETUP
Port 1 Port 2 Port 3
Port 0
SJA1105
Port 4
LPC 1788
Ethernet
End Node 2End Node1
PC (Logging)
Serial
Port
Serial port access
Figure 4.4: Network Topology with 1 Switch
Figure 4.4 shows a star topology with two switches cascaded together with the Grand-Master
connected to one switch and the slave connected to the other. This is another topology that
was explored to see the impact of network scaling on the synchronization. Further a 2 bridge/3
hop would be typical for automotive networks [24].
62 Investigation of Time-Synchronization
CHAPTER 4. EXPERIMENTAL SETUP
Switch1
Slave1
Slave2
Ethernet
Ethernet
Slave3
Ethernet
GMEthernet
Switch2
Slave4
Ethernet
Slave5
Ethernet
Figure 4.5: Network Topology with 2 Switches
4.4 Software tools
The following software tools were used for the set-up and experiments.
• TeraTerm for communicating with the end nodes and reading switch serial output.
• VmWare for running Ubuntu 12.04 (Compiling images for RIoTboard)
• Python for post-processing.
• Win32Diskimager for mounting the image on SD card
• Matlab for post-processing.
• Keil µVision for switch software development.
• Ostinato an open source traffic generator was used to generate the traffic for the experi-
ments.
63 Investigation of Time-Synchronization
Chapter 5
Experimental Methodology
5.1 Introduction
To study the performance of the synchronization protocol we basically try to understand the
following:
a. Effect of Synchronization parameters on the Quality of synchronization.
b. Effect of System and network parameters on Quality of synchronization.
c. Effect of Synchronization parameters on the System and network.
To study the above mentioned effects and properties of the synchronization protocol we first
identify the parameters that would affect the synchronization process, define experiments and
perform them. The following are the identified key parameters:
Sync Interval: It is the interval between successive Sync messages. The Sync interval plays
a key role in the performance of the synchronization protocol. Varying the Sync interval would
affect the frequency of the offset calculation. This would affect offset of the slave with respect
to the master.
Peer delay interval: Similar to the Sync interval the Peer delay interval also plays a signifi-
cant role as the calculated peer delay is used in the offset calculation. Further an accurate peer
delay calculation would increase the accuracy of the offset calculation.
Time-stamping: The time-stamping mechanism affects the offset calculation to a great ex-
tent. This is an interesting parameter to study as the egress time-stamp of the Sync message
depends on the time-stamping mechanism and in-accuracies in this could tamper the synchro-
nization process.
Number of switches: Varying the number of switches would significantly increase the net-
work delay and jitter associated with it thus affecting the offset calculation.
CHAPTER 5. EXPERIMENTAL METHODOLOGY
Traffic: The traffic on the network should however not impact the synchronization but would
affect the synchronization message queuing at the switch. Further in real world applications
the synchronization traffic co-exists with the AVB traffic and hence it would be interesting to
study the impact of network traffic.
Processor Load: The effect of processor load is important as this is close to the real world
applications also this will will also affect the generation of the Sync messages at the master and
the calculation of the offset at the slave.
5.2 Metrics
The following are the performance metrics selected for the analysis of the synchronization:
Slave offset
The slave offset is the best measure to study the quality of synchronization. The slave offset
can be characterized by the following metrics:
• Deviation range: It is the maximum difference in time of the slave clock from the reference
clock (Grand-Master). It is calculated at the slave and expressed in nanoseconds. It is
expressed as a combination of positive and negative peak values of the offset.
• Standard deviation: The standard deviation of the offset gives information on how much
the slave’s time deviates from the mean offset value. It is expressed in nanoseconds.
• Offset distribution: It is a distribution plot (histogram) of the slave offset. This gives us
information about the level of spread of the offsets.
The calculation of the slave offset is affected by three main parameters :
1. The Residence time.
2. The Slave and Switch peer delays.
3. The egress timestamps of the Sync message.
Peer delay
The peer delay is calculated by the slave with respect to the switch and by the switch with
respect to the master. This is an important factor as in-accuracies in this calculation can affect
the accuracy of the offset calculation at the slave. It is expressed in nanoseconds.
Residence time
Residence time is the amount of time spent by the Sync message on the switch. It is an
important parameter which also affects the offset calculation at the slave. It is expressed in
nanoseconds.
65 Investigation of Time-Synchronization
CHAPTER 5. EXPERIMENTAL METHODOLOGY
Synchronization time
It is the time taken from the start of the synchronization to the point after which the slave
offset value remains within a the deviation range. It is expressed in in seconds.
BMCA time
It is the time taken to elect a master among a number of Grand-Master capable end-nodes in
a network. It is expressed in seconds.
Note: This parameter is not applicable for the automotive E-AVB because the
automotive E-AVB does not have the BMCA functionality.
Time-stamping inaccuracy
The time-stamping is one of the key factors that affect the offset calculation as this is used to
calculate the current time of the master at the slave. It is calculated as the difference between
successive timestamps of the Sync message with respect to the Sync interval. This parameter
is purely dependent on the stack and not the time-stamping mechanism.
Bandwidth utilization
This is the bandwidth utilized by the synchronization protocol in the network.
5.3 Test Procedure
This section defines the step by step testing process that will be followed to see the impact of
various parameters on the quality of synchronization. The Figure shows the various steps of the
process that will be followed during the testing. The various steps are tagged to the respective
sections below.
A. Network and Power Connections
End Nodes: The end nodes are connected the switch via the twisted pair Ethernet cables.
The end nodes are connected to a PC via RPI cables and are powered up through a 5V adapter.
Switch: The switch is powered up using a 12V supply.
B. Basic Configuration
End Nodes The IP is set in the Linux environment using the following command
ifconfig eth0 169.254.2.11x netmask 255.255.0.0
The IP can also be set statically in the /etc/network/interfaces file as follows:
iface eth0 inet static
66 Investigation of Time-Synchronization
CHAPTER 5. EXPERIMENTAL METHODOLOGY
address 192.168.1.10
netmask 255.255.255.0
Switch: The switch software contains the configurations necessary for the switch to function.
C. Test Configuration file
The configuration file is divided into sections. Each section starts with a line containing its
name enclosed in brackets and it follows with the settings. Each setting is placed on a separate
line, it contains the name of the option and the value separated by white space characters.
Empty lines and lines starting with # are ignored.
The global section (indicated as [global]) sets the program options, clock options and default
port options. Other sections are port specific sections and they override the default port options.
The name of the section is the name of the configured port (e.g. [eth0]). Ports specified in the
configuration file don’t need to be specified by the -i option. An empty port section can be used
to replace the command line option. The configuration file used is given in the Appendix C.
D. Logging
End Nodes: The inbuilt logging function of Teraterm will be used to log data displayed in the
terminal. On stopping the log the log file is saved by default on the Desktop folder of the PC.
Further Wireshark will be used to log the network traffic and to access the timestamps/data
in the Follow Up messages. Using Wireshark we can see individual packets and their contents.
The ptp4l application displays the Offset with respect to master in ns and Path delay with
respect to the switch in ns.
Switch: The residence time, rate ratio and peer delay measured by the switch are made available
through the serial interface. This is logged using Teraterm.
E. Test
After configuring the desired parameters the ptp4l application is started on all the end nodes
using the command:
ptp4l -f gPTP.cfg
F. Termination
The applications are terminated after a desired period or on completion of the test.
67 Investigation of Time-Synchronization
CHAPTER 5. EXPERIMENTAL METHODOLOGY
Network and
Power
Connections
Start
Nodes power
up
Basic
Configuration
Test
Configura
tion file
Application
Launch
Logging-start
End
Stop process
Logging-stop
Test
Completed
No
(A)
(B)
(C)
(D)
(E)
(F)
Figure 5.1: Test procedure
68 Investigation of Time-Synchronization
Chapter 6
Experiments, Results and Analysis
Removed due to confidentiality.
69
Chapter 7
Conclusion
7.1 Overview
The study was set out to explore the performance of the synchronization protocol, a part of
the E-AVB stack. The synchronization protocol has been standardized by the IEEE 802.1AS
standard and adopted with modifications for automotive applications. To achieve our goal of
understanding the synchronization protocol we framed research questions. The answers to these
questions have improved our understanding of the synchronization protocol. The current re-
search work associated with the synchronization protocol are mainly simulation based and this
analysis of the synchronization protocol provided a much clearer picture of the same.
To study the synchronization protocol a gPTP capable network was assembled and the missing
pieces were built. End nodes with good time-stamping capabilities and an open source gPTP
application were selected. The network was in-complete without a switch/bridge. A transpar-
ent switch serves the purpose of handling the network delays differentiating it from traditional
Ethernet switches, thereby improving the accuracy of the synchronization over Ethernet based
in-vehicle networks. In order to realize the transparent switch the gPTP software was developed
for the NXP SJA1105 switch. This switch being developed at NXP will take a critical place in
their product catalog for automotive solutions. Once assembled the network was verified and a
variety of tests were performed.
All the experiments were conducted in a lab and the key findings are summarized:
• The synchronization quality achieved with a normal switch between two nodes under no-
traffic conditions was within acceptable limits of the standard but the network cannot be
scaled beyond two nodes. Further with additional traffic the synchronization fails. Thus
a need for a special switch capable of handling the messages was established.
• The addition of a gPTP transparent switch between two nodes actually reduces the syn-
chronization accuracy by a factor of 4 with respect to the two nodes connected directly.
This has to be accepted for scaling the network. However on further scaling the network
by adding another switch the synchronization accuracy is deteriorated by a factor of 0.27.
70
An offset in-accuracy of ±141ns was achieved for a three hop network (which would be
the typical size of automotive networks [24]).
• Varying the sync interval has a significant impact on the synchronization process. With
low sync intervals of 31.25ms a better in-accuracy and reduced initial time synchronize
was achieved. Further a sync interval of 1s was able to maintain the synchronization
within the bounds required by the standard but with reduced performance (factor of 0.27
less). A similar behaviour was observed in the paper [12]. However the time to achieve
the Sync interval was more. Thus from an application developer point of view it would
be efficient to start the synchronization at an interval of 31.25ms and later maintain it at
a 1s Sync interval.
• The impact of the peer delay interval though not significant improves the synchronization
performance at higher intervals. Thus maintaining the peer delay interval at 8s would
yield a better performance. Further adding a moving average filter to calculate the peer
delay as mentioned in [12] improves the synchronization performance.
• Considering both the cases the bandwidth consumed with lower intervals of Sync and
peer delay intervals is high. Though utilized bandwidth is very low in comparison with
the available bandwidth increasing the Sync interval reduces the gPTP processing to be
done on the switch. Thus making the high intervals of Sync and peer delay intervals
apt choices when the network is fully operational. Further the AVnu specifications also
provides initial and operational ranges for these message intervals.
• Traffic in the network does not affect the synchronization. This was established through
our experiments. Though it affects the time-stamping in-accuracy and the residence time.
The accurate time-stamping ensures that these additional delays are properly accounted
for in the offset calculation. This establishes the findings of the paper [12].
• The Time-stamping mechanism plays a key role achieving a desired quality of synchro-
nization. This is the major source of in-accuracy for the calculation of offset as the offset
calculation is purely based on time-stamps. The hardware time-stamping is more accurate
and achieves the best quality of synchronization. However the software application can
be used for applications that do not require higher QoS. Further from our experiment we
have established that different time-stamping mechanisms can co-exist in a network with
deteriorated quality of synchronization. This would be a cost effective solution for the
initial migration from traditional system to the Ethernet networks.
• The priority of the gPTP traffic also plays a significant role. Lower and same priority
with respect to other traffic causes the synchronization to break and hence the priority of
the gPTP messages should be the highest in the network.
7.2 Recommendations for the Switch
Removed due to confidentiality.
CHAPTER 7. CONCLUSION
7.3 Future work
Removed due to confidentiality.
72 Investigation of Time-Synchronization
Appendix A
Current Solutions
This chapter describes some of the networking solutions currently in use in the automotive
industry.
A.1 Controller Area Network
The most popular automotive network is CAN. This is one of the commonly found networks
in today’s cars. It was developed by BOSCH GmbH and is governed by a number of standards
(ISO 11898). The Physical medium is a twisted pair copper wires. The most common network
speeds used in a CAN network are 250 or 500 Kbps. The access to the network is by arbitration
based on the CAN data identifiers which are either 11 or 29 bits in length. The CAN uses
a non-zero-return bit representation. Bit ”0” is the dominant bit and bit ”1” is the recessive
bit. Thus message with the lowest identifier has the highest priority. The CAN bus uses a
differential voltage mechanism for distinguishing between the dominant and recessive bits.
120Ω 120Ω
CAN H
CAN L
Figure A.1: Controller Area Network
What is typical about CAN is that it is based on the multi-master concept that allows all
the nodes to transmit their messages. It is robust, low cost and communication delays are
bounded. The CAN network has only two layers with respect to the OSI model: the physical
layer and the data link layer thus making it simple from implementation point of view. Further
CAN is a well established standard that has been in the automotive world for over 30 years.
One of the greatest benefits of CAN is the flexibility it provides. It enables the network design
73
APPENDIX A. CURRENT SOLUTIONS
engineers to introduce new ECUs in the network without much changes. The growing bandwidth
limitations are one of the limitations of CAN as it can support up to 1Mbps. Further there is
also a limitation on the length of the network. Further the bus architecture limits the ECUs
from simultaneous transmission. The bus architecture provides flexible wiring options but with
the disadvantage of having a termination in the bus and without this termination the network
does not function.
A.2 Local Interconnect Network
LIN is a serial communication protocol. It is cheap as well as slower than CAN. It was intended
to complement the CAN networks in cars to establish a hierarchical network. The LIN network
is used where the bandwidth requirements are less. A LIN cluster consists of a master and many
slave nodes connected to a common bus. For achieving a low-cost implementation, the physical
layer is defined as a single wire with a data rate limited to 20Kbit/s. In LIN networks similar to
CAN the logical 0 is dominant and a logical 1 is recessive. The LIN is a shared medium where
only one message can be transmitted at a time. Its disadvantages include a low bandwidth,
basic diagnostic capabilities, the master-slave architecture. Some of the typical applications
include controlling switches, windows etc.
LIN bus
Figure A.2: Local Interconnect Network [2]
A.3 Media Oriented Systems Transport
MOST is primarily used for infotainment in a car. It is a proprietary product of Standard
Microsystems Corporation (SMSC). It is one of few networks that enables audio video network
streaming. It has a ring network which fails to function even if one of the links is down. This
solution is costly, proprietary and non-deterministic. This led to the emergence of Ethernet as
a network for automotive application.
74 Investigation of Time-Synchronization
APPENDIX A. CURRENT SOLUTIONS
Figure A.3: Media Oriented Systems Transport [2]
A.4 FlexRay
FlexRay is one of the effective and accurate networking solutions. It can have data rates up to
10Mbits/s. The bus is based on a flexible time division multiplexing. There are two parts to the
time cycle: static and dynamic. The static segment offers real-time guarantee by providing a
fixed schedule where as the dynamic segment is more event based. The static segment consists
of slots which are assigned to the nodes in which it can transmit without any contention. The
static and dynamic structure of slots gives more flexibility.
The FlexRay network is very flexible with respect to topology (Figures A.4,A.5,A.6) and trans-
mission support redundancy and was designed with safety critical applications in mind. It also
has dual redundant channels (possible in Ethernet but not others). It can be configured as a
bus, a star or a multi-star network. With respect to CAN it is more deterministic, composable,
fault tolerant, flexible and it has a higher baud rate. It has some disadvantages like lower
operating voltage levels and asymmetry of the edges, which leads to problems in extending
the network length, cost and less bandwidth availability for less critical streaming media ap-
plications (maximum bandwidth of FlexRay is 10Mbps). Despite the advantages FlexRay was
more complicated to implement than CAN [2]. Ethernet will replace FlexRay for bandwidth
intensive, non-safety critical applications.
75 Investigation of Time-Synchronization
APPENDIX A. CURRENT SOLUTIONS
Channel A
Channel B
Figure A.4: FlexRay - Bus topology [18]
Channel A Channel A
Channel BChannel A
Channel B Channel B
Figure A.5: FlexRay - Star topology
[18]
Channel A
Channel A
Channel B
Channel A
Channel B
Channel B
Channel A
Channel B
Figure A.6: FlexRay - Hybrid topology [18]
76 Investigation of Time-Synchronization
Appendix B
Message formats
The following figures show the message formats as per [13]:
Figure B.1: Announce Message
Figure B.2: Sync Message
Figure B.3: Follow Up Message
77
APPENDIX B. MESSAGE FORMATS
Figure B.4: PDelay Req Message
Figure B.5: PDelay Resp and Pdelay Resp Follow Up Message
78 Investigation of Time-Synchronization
Appendix C
gPTP configuration
[global]
#
# Default Data Set
#
twoStepFlag 1
gmCapable 1
priority1 248
priority2 248
domainNumber 0
clockClass 248
clockAccuracy 0xFE
offsetScaledLogVariance 0xFFFF
free_running 0
freq_est_interval 1
#
# Port Data Set
#
logAnnounceInterval 1
logSyncInterval -3
logMinPdelayReqInterval 0
announceReceiptTimeout 3
syncReceiptTimeout 3
delayAsymmetry 0
fault_reset_interval 4
neighborPropDelayThresh 20000000
min_neighbor_prop_delay -20000000
#
# Run time options
#
assume_two_step 1
79
APPENDIX C. GPTP CONFIGURATION
logging_level 6
path_trace_enabled 1
follow_up_info 1
tx_timestamp_timeout 1
use_syslog 1
verbose 0
summary_interval 0
kernel_leap 1
check_fup_sync 0
#
# Servo options
#
pi_proportional_const 0.0
pi_integral_const 0.0
pi_proportional_scale 0.0
pi_proportional_exponent -0.3
pi_proportional_norm_max 0.7
pi_integral_scale 0.0
pi_integral_exponent 0.4
pi_integral_norm_max 0.3
step_threshold 0.0
first_step_threshold 0.00002
max_frequency 900000000
clock_servo pi
sanity_freq_limit 200000000
ntpshm_segment 0
#
# Transport options
#
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
p2p_dst_mac 01:80:C2:00:00:0E
uds_address /var/run/ptp4l
#
# Default interface options
#
network_transport L2
delay_mechanism P2P
time_stamping hardware
delay_filter moving_median
delay_filter_length 10
80 Investigation of Time-Synchronization
APPENDIX C. GPTP CONFIGURATION
egressLatency 0
ingressLatency 0
boundary_clock_jbod 0
[eth0]
81 Investigation of Time-Synchronization
Bibliography
[1] “Beautiful gauges.” http://forums.thecarlounge.com/showthread.php?6983059-Beautiful-
Gauges/page4, 2015.
[2] C. M. Kozierok, C. Correa, R. B. Boatright, and J. Quesnelle, “Automotive Ethernet: The
definitive guide,” 2005.
[3] “Advanced Driver Assistance System.” http://millionstartups.com/index.php/2015/06/26/asia-
pacific-advanced-driver-assistance-system-market-is-expected-to-reach-15-5-billion-by-
2020/, 2015.
[4] W. Saleem, “1394 automotive network enables powerful, cost-
efficient in-vehicle networks for infotainment, navigation, cameras.”
http://m.eet.com/media/1052951/infotainment.jpg, 2015.
[5] P. Hank, T. Suermann, and S. Muller, “Automotive Ethernet, a holistic approach for next
generation in-vehicle networking standard.” http://itersnews.com/?p=10541, 2015.
[6] D. Olsen, “Audio video transport protocol AVTP,” http://avnu.org/wp-
content/uploads/2014/05/AVnu-AAA2C Audio-Video-Transport-Protocol-AVTP Dave-
Olsen.pdf, 2015.
[7] E. Heidinger, F. Geyer, S. Schneele, and M. Paulitsch, “A performance study of Audio
Video Bridging in aeronautic Ethernet networks,” in Industrial Embedded Systems (SIES),
2012 7th IEEE International Symposium on, pp. 67–75, June 2012.
[8] L. Bello, “Novel trends in automotive networks: A perspective on ethernet and the IEEE
Audio Video Bridging,” in Emerging Technology and Factory Automation (ETFA), 2014
IEEE, pp. 1–8, Sept 2014.
[9] H.-T. Lim, D. Herrscher, M. J. Waltl, and F. Chaari, “Performance analysis of the IEEE
802.1 Ethernet Audio/Video Bridging Standard,” in Proceedings of the 5th International
ICST Conference on Simulation Tools and Techniques, SIMUTOOLS ’12, (ICST, Brussels,
Belgium, Belgium), pp. 27–36, ICST (Institute for Computer Sciences, Social-Informatics
and Telecommunications Engineering), 2012.
[10] P. Meyer, T. Steinbach, F. Korf, and T. Schmidt, “Extending IEEE 802.1 AVB with
time-triggered scheduling: A simulation study of the coexistence of synchronous and asyn-
chronous traffic,” in Vehicular Networking Conference (VNC), 2013 IEEE, pp. 47–54, Dec
2013.
82
BIBLIOGRAPHY
[11] D. Arnold, “What Are All of These IEEE 1588 Clock Types?.”
http://blog.meinbergglobal.com/2013/10/21/ieee-1588-clock-types/, 2015.
[12] H. T. Lim, D. Herrscher, L. Volker, and M. Waltl, “IEEE 802.1AS time synchronization in
a switched Ethernet based in-car network,” in Vehicular Networking Conference (VNC),
2011 IEEE, pp. 147–154, Nov 2011.
[13] “IEEE standard for a precision clock synchronization protocol for networked measurement
and control systems,” IEEE Std 1588-2008 (Revision of IEEE Std 1588-2002), pp. 1–269,
July 2008.
[14] “IEEE standard for local and metropolitan area networks - timing and synchronization
for time-sensitive applications in bridged local area networks,” IEEE Std 802.1AS-2011,
pp. 1–292, March 2011.
[15] “Kontron smarc-samx6i.” http://www.kontron.com/products/boards-and-standard-form-
factors/smarc/smarc-samx6i.html, 2015.
[16] “Riotboard.” http://riotboard.org/, 2015.
[17] K. Ichikawa, “Precision time protocol on Linux Introduction to linuxptp,” 2014.
[18] N. I. Corporation, “Flexray automotive communication bus overview,” 2015.
[19] G. Bechtel, B. Gale, M. Kicherer, and D. Olsen, “Automotive E-AVB profile,”
http://standards.ieee.org/events/automotive/2014/17 Automotive E-AVB Profile.pdf,
2015.
[20] C. Gordon, “White paper introduction to IEEE 1588 transparent clocks,” 2009.
[21] M. Johas Teener, A. Fredette, C. Boiger, P. Klein, C. Gunther, D. Olsen, and K. Stanton,
“Heterogeneous networks for Audio and Video: Using IEEE 802.1 Audio Video Bridging,”
Proceedings of the IEEE, vol. 101, pp. 2339–2354, Nov 2013.
[22] A. Gothard, R. Kreifeldt, and C. Turner, “AVB for automotive use,” AVnu Alliance White
Paper, 2014.
[23] M. J. Teener, “No - excuses Audio/Video networking: the technology behind AVnu,” AVnu
Alliance White Paper, 2009.
[24] G. Bechtel, B. Gale, M. Kicherer, and D. Olsen, “Automotive Ethernet AVB Functional
and Interoperability Specification, Revision 1.4,” 2015.
[25] S. Rumpf, T. Steinbach, F. Korf, and T. Schmidt, “Software stacks for mixed-critical ap-
plications: Consolidating IEEE 802.1 AVB and time-triggered ethernet in next-generation
automotive electronics,” in Consumer Electronics ??? Berlin (ICCE-Berlin), 2014 IEEE
Fourth International Conference on, pp. 14–18, Sept 2014.
83 Investigation of Time-Synchronization
BIBLIOGRAPHY
[26] G. Garner and H. Ryu, “Synchronization of audio/video bridging networks using IEEE
802.1AS,” Communications Magazine, IEEE, vol. 49, pp. 140–147, February 2011.
[27] A. Dopplinger and B. Seitz, “Who doesn’t need Ethernet timestamps?.”
http://www.embedded.com/design/mcus-processors-and-socs/4008245/Who-doesn-t-
need-Ethernet-timestamps-, 2015.
[28] Y. J. Kim, J. H. Kim, B. M. Cheon, Y. S. Lee, and J. W. Jeon, “Performance of IEEE
802.1AS for automotive system using hardware timestamp,” in Consumer Electronics
(ISCE 2014), The 18th IEEE International Symposium on, pp. 1–2, June 2014.
[29] D. Arnold., “End-to-End versus Peer-to-Peer.” http://blog.meinbergglobal.com/2013/09/19/end-
end-versus-peer-peer/, 2015.
[30] D. Arnold., “One-step or Two-step?.” http://blog.meinbergglobal.com/2013/10/28/one-
step-two-step/, 2015.
[31] F. Semiconductors, “i.mx 6solo/6duallite applications processor reference manual,”
[32] Y. project. https://www.yoctoproject.org/, 2015.
[33] PTPdaemon. http://ptpd.sourceforge.net/, 2015.
[34] R. Cochran, “Linuxptp.” http://linuxptp.sourceforge.net/, 2015.
[35] Openptp. http://sourceforge.net/projects/openptp/, 2015.
[36] “Linux kernel archives Timestamping Control Interfaces,” 2015.
[37] R. Cochran, C. Marinescu, and C. Riesch, “Synchronizing the Linux system time to a
PTP hardware clock,” in Precision Clock Synchronization for Measurement Control and
Communication (ISPCS), 2011 International IEEE Symposium on, pp. 87–92, Sept 2011.
[38] T. Panda, “Riotboard Yocto: Part1: Environment setup and initial build,” 2015.
***********End of Document***********
84 Investigation of Time-Synchronization