Time-Sensitive Network (TSN) Experiment in Sensor-Based Integrated Environment for Autonomous Driving - MDPI
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
sensors
Article
Time-Sensitive Network (TSN) Experiment in
Sensor-Based Integrated Environment for
Autonomous Driving
Juho Lee and Sungkwon Park *
Both are with Department of Electronic and Computer Engineering, Hanyang University, Seoul 04763, Korea;
ljh0122@hanyang.ac.kr
* Correspondence: sp2996@hanyang.ac.kr; Tel.: +82-2-2294-0367
Received: 2 January 2019; Accepted: 27 February 2019; Published: 5 March 2019
Abstract: Recently, large amounts of data traffic from various sensors and image and navigation
systems within vehicles are generated for autonomous driving. Broadband communication networks
within vehicles have become necessary. New autonomous Ethernet networks are being considered
as alternatives. The Ethernet-based in-vehicle network has been standardized in the IEEE 802.1
time-sensitive network (TSN) group since 2006. The Ethernet TSN will be revised and integrated into
a subsequent version of IEEE 802.1Q-2018 published in 2018 when various new TSN-related standards
are being newly revised and published. A TSN integrated environment simulator is developed in this
paper to implement the main functions of the TSN standards that are being developed. This effort
would minimize the performance gaps that can occur when the functions of these standards operate in
an integrated environment. As part of this purpose, we analyzed the simulator to verify that the traffic
for autonomous driving satisfies the TSN transmission requirements in the in-vehicle network (IVN)
and the preemption (which is one of the main TSN functions) and reduces the overall End-to-End
delay. An optimal guard band size for the preemption was also found for autonomous vehicles in
our work. Finally, an IVN model for autonomous vehicles was designed and the performance test
was conducted by configuring the traffic to be used for various sensors and electronic control units
(ECUs).
Keywords: autonomous driving; vehicle sensors; time-sensitive network; in-vehicle network
1. Introduction
As autonomous vehicles are emerging, technologies including next-generation vehicle
communication, vehicle to everything (V2X), and the advanced driving assistant system (ADAS),
are also advancing. An autonomous vehicle communicates with traffic infrastructures, such as a nearby
vehicle or RSU (roadside unit). The long-term evolution (LTE) and 5G communication technologies
can be used as external communication technologies for autonomous vehicles. Dedicated short-range
communication (DSRC) protocols are also used as external communication means for providing
intelligent transport system (ITS) services. But, in order to exchange data between various sensors,
processors, and ECUs (electronic control unit) in real time within a vehicle, in-vehicle networks
(IVNs) also need proper broadband communications. Traditional IVNs include controller area network
(CAN), local interconnect network (LIN), media-oriented systems transport (MOST), and FlexRay [1–4].
Recently, as traffic for autonomous driving increases, the application of Ethernet communication
technology to vehicles is underway. This standardization work for autonomous vehicles has been
going on since 2006 in the IEEE 802.1 TSN (time-sensitive network) [5]. The Ethernet TSN is still in
the process of being developed. IEEE 802.1Q-2018 was completed in July 2018 [6]. A new version of
802.1Q will follow, and standard technologies for autonomous driving will continue to be reflected on.
Sensors 2019, 19, 1111; doi:10.3390/s19051111 www.mdpi.com/journal/sensorsSensors 2019, 19, 1111 2 of 11
IEEE 802.1Qbv and 802.1Qbu were published in 2015 and 2016, respectively. However,
new contributions have been steadily emerging due to functional interoperability with linked standards
and physical link scalability (IEEE P802.1ch Multi-Gig Automotive Ethernet PHY Task Force) when
integrated into the 802.1Q standard [7–9]. The functions of these standards should be considered in
the integrated environment to reconsider the parameters and requirements for the TSN environment
in IEEE 802.1Q. Several studies have been conducted on performance testing on the IEEE 802.1
TSN through simulations and theoretical studies [10–12]. These studies have been conducted in an
independent environment, which generally constitutes basic partial traffic in the TSN standards. Each
of the standards being developed is independently published, and only the interworking of some of
the most highly relevant standards are considered. Therefore, when integrating different standards
into a single standard such as IEEE 802.1Q, there may be a lack of interworking and scalability between
the main TSN functions in the standards. In some cases, some parameter values in the TSN standards
may need to be changed.
Our contribution in this paper is the development of a TSN integrated environment simulator
applying the main functions of the TSN standards such as IEEE 802.1AS, Qbv, Qcc, Qca, Qbu,
and 802.3br that are in the early stage of standardization. Considering the upcoming revision of 802.1Q,
in order to minimize the performance gaps that can occur when the functions of these standards
operate in an integrated environment, we analyzed whether the traffic for autonomous driving satisfies
the TSN transmission requirements in IVNs and whether the preemption function reduces the overall
E2E (End-to-End) delay or not. Moreover, since there are so many different standards involved,
as explained above, it is hard to predict whether a combined architecture with so many different
parameters and configurations satisfy the requirements underlying autonomous vehicles. Software
simulations enabled us to test many different possible scenarios with ease. This significantly saved
us time and cost. In addition, as part of our analysis process in simulations, we derived a parameter
for the preemption to work optimally. Finally, an IVN model to be used for autonomous vehicles was
designed, and the performance test was conducted by configuring the traffic to be used in various
sensors and ECUs. Actual data were provided by a major motor company in Korea.
The rest of the paper is structured as follows. Section 2 contains the overall trends in the
development of TSN standards and a description of the two standards that will be one of the
main focuses of this paper. Section 3 describes the TSN simulator in the developed integrated TSN
environment and the main functions that can be changed through parameters. Section 4 deals with the
traffic expected to be used in autonomous vehicles, and the simulation tests that were performed to
check if the traffic would satisfy the TSN transmission requirements. Lastly, we conclude the paper
and talk about future work in Section 5.
2. Background
The IEEE 802.1 TSN Task Group (TG) is part of the IEEE 802.1 Working Group (WG). The TSN TG
evolved from the former IEEE 802.1 Audio Video Bridging (AVB) TG. The original work on AVB was
completed in 2005. TSN standards have been newly published or revised based on the AVB standards
since 2006, and the development status of major standards are shown in Table 1.
There are two representative standards that redefine the queuing process for time-sensitive
traffic transmission. The first is IEEE 802.1Qbv-2015. The IEEE 802.1Qbv standard has extended the
time-based scheduler for time-sensitive traffic transmission and its queuing procedure over AVB traffic
transmission structure [7]. The transmission method of existing AVB streams was an event trigger.
However, in a TSN, a time-aware scheduler is applied in addition to the existing method to transmit
scheduled traffic (ST) by a time-trigger transmission method. ST is transmitted at regular intervals in
the vehicle as important data related to vehicle control and safety. If the transmission requirement of
the existing AVB stream is to deliver within the maximum 2 ms time delay when passing seven hops,
the transmission requirement of the ST is to deliver within 100 µs time when passing five hops. A hop
represents a switch. All nodes (switches, gateways, sensors, or ECUs) must be synchronized to theSensors 2019, 19, x FOR PEER REVIEW 3 of 11
Sensors 2019, 19, 1111 3 of 11
Standard Status Functionality
IEEE P802.1AS-Rev Ongoing Timing and Synchronization for Time-Sensitive Applications
same clock with almost no error in order to transmit the ST properly based on the transmission time.
IEEE P802.1Qcc Ongoing Stream Reservation Protocol (SRP) Enhancements and Performance Improvements
Therefore, a time-aware scheduler should be applied with the time synchronization function of the
IEEE P802.1AX-Rev Ongoing Link Aggregation
IEEE 802.1AS-rev standard [13]. In this paper, we refer to this standard and implement these functions
IEEE P802.1Qcr Ongoing Asynchronous Traffic Shaping
in the simulator.
There are two representative
Table 1. Development standards
status ofthat redefine the
time-sensitive queuing
network process
(TSN) for time-sensitive traffic
standards.
transmission. The first is IEEE 802.1Qbv-2015. The IEEE 802.1Qbv standard has extended the time-based
scheduler Standard Statustransmission and its queuing
for time-sensitive traffic Functionality
procedure over AVB traffic transmission
IEEE 802.1Qbv-2015
structure [7]. The transmission Published
method of existingEnhancements
AVB streamsfor was Scheduled
an eventTraffic
trigger. However, in a
IEEE 802.1Qca-2015 Published Path Control and
TSN, a time-aware scheduler is applied in addition to the existing method to transmit scheduledReservation
IEEE 802.1Qbu-2016 Published Frame Preemption
traffic (ST) by a time-trigger
IEEE 802.1Qch-2017
transmission method. ST
Published
is transmitted at regular intervals in the vehicle
Cyclic Queuing and Forwarding
as important data related to
IEEE 802.1Qci-2017 vehicle control and safety.
Published If the transmission
Per-Stream requirement of the existing
Filtering and Policing
AVB IEEEstream is to deliverPublished
802.1CB-2017 within the maximum 2 ms timeand
Frame Replication delay when passing
Elimination seven hops, the
for Reliability
IEEE 802.1CM-2018
transmission requirement Published
of the ST is to deliver Time-Sensitive
within 100 μs Networking
time when for passing
Front Haul five hops. A hop
IEEE P802.1AS-Rev Ongoing Timing and Synchronization for Time-Sensitive Applications
represents a switch. All nodes (switches, gateways, sensors, or ECUs) must be synchronized to the
Stream Reservation Protocol (SRP) Enhancements and
same clockIEEE with
P802.1Qcc
almost no Ongoing
error in order to transmit the ST properly based on the transmission time.
Performance Improvements
Therefore, a time-aware scheduler
IEEE P802.1AX-Rev Ongoing should be applied withLink theAggregation
time synchronization function of the
IEEE P802.1Qcr
IEEE 802.1AS-rev standard Ongoing
[13]. In this paper, weAsynchronous
refer to thisTraffic Shaping
standard and implement these
functions in the simulator.
Thesecond
The secondstandard
standardisisIEEE IEEE802.1Qbu-2016
802.1Qbu-2016[7]. [7].IEEE
IEEE802.1Qbu
802.1Qbuisisthe thestandard
standardthat thatdefines
definesthethe
preemptionmechanism.
preemption mechanism. In In the
the existing
existing transmission
transmissionpolicy, policy,ififthere
thereisisa aframe
frame being
being transmitted,
transmitted, the
frame is designed to wait until the ongoing transmission is finished, even
the frame is designed to wait until the ongoing transmission is finished, even if there is a frame thatif there is a frame that needs
to betotransmitted
needs be transmittedurgently.
urgently.However,
However,with thethe
with preemption
preemption technique,
technique, high-priority
high-priority frames
frames can
canbe
bepreferentially
preferentiallyprocessed.
processed.The Thepreemption
preemptionmay may interrupt
interrupt the transmission of
the transmission ofaalow-priority
low-priorityframe frame
(AVB) during transmission to preferentially process a time-sensitive frame
(AVB) during transmission to preferentially process a time-sensitive frame (ST). After processing the (ST). After processing the
high-priority frame, it resumes transmission of the low-priority frame and receives
high-priority frame, it resumes transmission of the low-priority frame and receives it in the full frame. it in the full frame.
Whenswitching
When switchinggatesgatesforfortransmission
transmissionbetween
betweenST STand
andAVB, AVB,a a“guard
“guardband”
band”isisset setfor
fora acertain
certaintime
time
window to prevent frame collision (see Figure 1). Low-priority frames can be divided into two or moreor
window to prevent frame collision (see Figure 1). Low-priority frames can be divided into two
more frames
frames as needed. as needed.
ST's transmission cycle
ST
Frame arrivals
AVB
Frame transmission
AVB ST
(Without preemption)
Frame transmission
Frag1 ST Frag2
(With preemption)
t
IFG
Guard band
Figure1.1.Example
Figure Exampleofofframe
frametransmission
transmissionwith
withpreemption.
preemption.
In order to transmit the ST at the reserved time, there is another method of blocking the frame
In order to transmit the ST at the reserved time, there is another method of blocking the frame
(1500 bytes of maximum frame size) from entering before the transmission cycle of the ST. However,
(1500 bytes of maximum frame size) from entering before the transmission cycle of the ST. However,
it is inefficient in utilizing network resources and also increases the delay time of non-ST frames.
it is inefficient in utilizing network resources and also increases the delay time of non-ST frames.
Therefore, the preemption is required to increase network efficiency and reduce overall delay time. The
Therefore, the preemption is required to increase network efficiency and reduce overall delay time.
standard technologies mentioned above have been consistently conducted with the standardization
The standard technologies mentioned above have been consistently conducted with the
work. In general, theoretical analysis of the time-aware scheduler of a TSN and experiments measuring
standardization work. In general, theoretical analysis of the time-aware scheduler of a TSN and
IVN performance through simulation are the main subjects. Recently, there have been studies analyzing
experiments measuring IVN performance through simulation are the main subjects. Recently, there
the performance of the preemption [14–18].
have been studies analyzing the performance of the preemption [14–18].Sensors 2019, 19, 1111 4 of 11
Sensors 2019, 19, x FOR PEER REVIEW 4 of 11
3.
3. TSN
TSN Simulator
Simulator Development
Development
In
In order
ordertotodevelop
developthetheintegrated
integratedIEEE 802.1Q
IEEE standard
802.1Q standardsimulation, we implemented
simulation, we implementedthe main
the
TSN
mainfunctions in the published
TSN functions standards
in the published such assuch
standards IEEEas802.1AS, Qbv, Qcc,
IEEE 802.1AS, Qca,
Qbv, Qbu,
Qcc, andQbu,
Qca, 802.3br.
and
Section
802.3br.3Section
introduces the time-aware
3 introduces schedulerscheduler
the time-aware functionsfunctions
of IEEE 802.1Qbv-2015 (which are(which
of IEEE 802.1Qbv-2015 the main
are
TSN functions
the main TSN of a TSN) of
functions and the implementation
a TSN) issues of the
and the implementation frame
issues ofpreemption of IEEE 802.1Qbu-
the frame preemption of IEEE
2016 and 802.3brand
802.1Qbu-2016 and802.3br
describesandthe configuration
describes of each variable
the configuration operation
of each parameter
variable operationrelated to it.
parameter
The simulator
related hassimulator
to it. The been developed
has been based on OMNET
developed based++ onversion
OMNET 5.0++
and inet-3.3.0,
version andinet-3.3.0,
5.0 and some related
and
studies that have
some related beenthat
studies conducted
have been canconducted
be found can
in References
be found in [10,11,14,19].
References [10,11,14,19].
3.1. Time-Aware
3.1. Time-Aware Scheduler
The time-aware
The time-aware scheduler
scheduler acts
acts as
as aa timetable
timetable for
for transmitting
transmitting data
data at
at fixed
fixed intervals
intervals without
without being
being
influenced by the transmission
influenced by the transmission of AVB of AVB or BE (best effort) traffic. To
effort) traffic. To achieve this, it is important to
it is important to set set aa
cyclefor
cycle foreach
eachstream
streamand andappropriately
appropriatelyplace place the
the STST within
within thethe cycle.
cycle. ForFor
thisthis purpose,
purpose, a parameter
a parameter for
for specifying
specifying a period
a period for each
for each stream
stream andand a parameter
a parameter for allocating
for allocating a transmission
a transmission startstart
timetime of each
of each ST
ST within the period were separately configured. Since this series of operations
within the period were separately configured. Since this series of operations was based on the was based on the
assumption that
assumption that all
all nodes
nodes in
in the
the vehicle
vehicle areare synchronized,
synchronized, aa periodic
periodic synchronization
synchronization was was performed
performed
by designating
by designatingaaspecific
specificnode
nodeas asaamaster,
master, which
which follows
follows the
the IEEE
IEEE 802.1AS-rev
802.1AS-rev operation.
operation. Each Each node
node
was
was designed to have eight queues—five for ST, two for AVB (Class A, B) traffic,
to have eight queues—five for ST, two for AVB (Class A, B) traffic, and one for BE and one for BE traffic
(see Figure
traffic 2).
(see Figure 2).
1
2 Time
Time-triggered Aware
3 Transmission cycle
Scheduled Traffic Scheduler
4
Clock Port 5 8 6 ... 5 7
5
Schedule
AVB
Class A 6 Time
AVB Dataflow
7 Aware
Class B
CBS Controlflow
Best-Effort 8
Figure 2.
Figure Time-aware scheduler
2. Time-aware scheduler and
and queuing
queuing structure
structure in
in the
the in-vehicle
in-vehicle network
network (IVN)
(IVN) nodes.
nodes.
3.2. Frame Preemption
3.2. Frame Preemption
The principles of the frame preemption and development issues in implementation are as follows.
The
In order toprinciples
start theoftransmission
the frame preemption
through the and development
time-aware issues inthe
scheduler, implementation are as follows.
ST stops transmission of the
In order
frame to was
that startbeing
the transmission
transmitted through
and splitsthe thetime-aware
frame up atscheduler, the ST stops
the transmission transmission
stop point to transmitof the
the
frame that
ST first. Whenwas the
being transmittedofand
transmission the splits the frame up
ST is completed, theatframe
the transmission
preemptionstop point to
functions to transmit
transmit
the
the ST first.that
frame When
the the transmission
ongoing of the ST
transmission is completed,
interrupted. Whenthetheframe preemption
transmission offunctions
the ST is to transmit
completed,
the frame that the ongoing transmission interrupted. When the transmission
the frame preemption successively transmits the interrupted frame and restores the original frame. of the ST is completed, the
frame preemption successively transmits the interrupted frame and restores
The key point of the frame preemption is to stop the non-ST frame in transit and to combine the whole the original frame. The
key point
of the of theframe.
divided frameThe preemption
guard band is toisstop the non-ST
the interval framethe
between in transit
non-STandframeto combine the wholeand
to be interrupted of
the divided frame. The guard band is the interval between the non-ST
the ST frame to be transmitted (see Figure 1). The guard band is processed in units of data size.frame to be interrupted and
the ST Inframe
ordertotobeapply
transmitted (see Figure
the frame preemption,1). Theframe
guarddivision
band is processed
and merging in units of data should
processes size. be
In order to
implemented by apply
referringthetoframe
IEEE preemption,
802.3br standards frame[20].
division and merging
The preemption processes
process shouldand
of dividing be
implemented by referring to IEEE 802.3br standards [20]. The preemption
merging the frames is performed in Layer 2 because the PHY (Physical) layer cannot recognize the process of dividing and
merging
operationthe frames
of the is performed
preemption. in Layer
Therefore, 2 because
logical the PHY (Physical)
layer processing is requiredlayer
in thecannot recognize
MAC (Media the
Access
operation of the preemption. Therefore, logical layer processing is required
Control) merge sublayer when going up to Layer 2 (see Figure 3). In Layer 2, MAC is divided into in the MAC (Media Access
Control) merge sublayerand
eMAC (expressMAC) whenpMACgoing up to Layer 2 (see Figure
(preemptableMAC) 3). InThe
logically. Layer
eMAC2, MAC is divided
processes intoframe
the ST eMAC at
(expressMAC) and pMAC (preemptableMAC) logically. The eMAC processes
high speed, and the pMAC stores the divided frames in the buffer, merges them into a complete frame, the ST frame at high
speed, and the pMAC stores the divided frames in the buffer, merges them into a complete frame,
and sends it up to the upper layer. The buffer is located in the receiving MAC merge sublayer, andthe fragmented frames are merged in the buffer and sent to the pMAC. If it is not a fragmented frame,
it is sent directly to the pMAC without buffer storage.
eMAC pMAC
Sensors 2019, 19, 1111 5 of 11
Sensors 2019, 19, x FOR PEER REVIEW 5 of 11
Buffer
1 (Merging
and sends it up to the upper MAC Merge
layer. The buffer is located in the receiving MAC merge sublayer, and the
fragmented
the fragmentedframes frames Sublayer
are merged in theinbuffer
are merged and sent
the buffer andto thetopMAC.
sent If frames)
the pMAC.it isIfnot
it isanot
fragmented frame,
a fragmented it is
frame,
sent
it isdirectly to thetopMAC
sent directly without
the pMAC bufferbuffer
without storage.
storage.
eMAC 2 fragmented
pMAC
AVB AVB
Frame Frame
Buffer
Figure 3. Receiver side MAC merge sublayer structure. 1
MAC Merge
(Merging
Sublayer frames)
When transmitting a frame to the pMAC, it is necessary to know whether the frame is a fragmented
frame, and how many frames are fragmented. This information, together with the frame preemption,
consists of additional formats provided by IEEE 802.1Qbu and IEEE802.1br (see Figure 4). The format
includes the beginning, end, and the sequence information 2 offragmented
identifier the fragmented frame (see
AVB AVB
Table 2). The frame is split according to this format, Frame and the fragmented Frame is restored to the
frame
original frame at the receiving node with reference to the identifier (see Figure 3). As the development
progresses, the frame may Figure Figure
be 3.3.Receiver
divided moreside
Receiver sideMAC
than MAC merge
mergesublayer
necessary. orderstructure.
sublayer
In structure.
to control this problem, another
parameter is configured to limit the maximum number of times that one frame can be divided.
When
Whentransmitting
transmittingaaframe
frametotothethepMAC,
pMAC,ititisisnecessary
necessarytotoknow knowwhether
whetherthe theframe
frameisisaafragmented
fragmented
frame, and how many frames
frame, and how many frames are are fragmented.
fragmented. This
This information,
information, together
together with
with the
the frame
frame preemption,
preemption,
Table 2. Fragmented frame identifier.
consists
consistsofofadditional
additionalformats
formatsprovided
providedby byIEEE
IEEE802.1Qbu
802.1Qbuand andIEEE802.1br
IEEE802.1br(see (seeFigure
Figure4).4).The
Theformat
format
includes
includes the beginning, end, and the sequence information identifier of the fragmented frame(see
the beginning, end, and
Identifiers the sequence information
Functions identifier of the fragmented frame (see
Table
Table2).
2).The
Theframe
frameisis split
splitaccording
SMD-Sx according totothis
Field to format,
check
this firstand
format, the
thefragmented
fragmented
and frame frame
fragmented frameisisrestored
restoredtotothethe
original frame at the receiving
SMD-Cx node with
Field reference
to check ifto the
the identifier
fragment is (see Figure
continuing
original frame at the receiving node with reference to the identifier (see Figure 3). As the development3). As the development
progresses,
progresses,the theframe
framemaymaybe
SMD-Fxbedivided more
dividedFieldmoreto than necessary.
check
than InInorder
last fragmented
necessary. totocontrol
orderframe controlthisthisproblem,
problem,another
another
parameter is configuredFragto limit
Count the maximum number
Fragmented of
frametimes that
sequence one
parameter is configured to limit the maximum number of times that one frame can be divided. frame can be divided.
Preamble 7 Fragmented 7frame identifier.
Preamble
Table 2.
SFD 1 SMD-Sx 1
MAC DA 6Identifiers MAC DA Functions
6 Preamble 6 Preamble 6
6
MAC SA SMD-Sx MACtoSA
Field check6first fragmented
SMD-Cxframe 1 SMD-Fx 1
SMD-Cx Ethertype
Field 2 fragment
to check if the Fr ag Count 1
is continuing Fr ag Count 1
Data SMD-Fx Field to check last fragmented frame
Data Data Data
Frag Count Fragmented frame sequence
FCS 4 FCS 4 FCS 4 FCS 4
Preamble 7 Preamble 7
(a) Normal frame 1
SFD format 1
SMD-Sx(b) Fragmented frame format
MAC DA 6 MAC DA 6 Preamble 6 Preamble 6
MAC SA 6 Figure IEEE
Figure4.4.IEEE
MAC 802.1Qbu
802.1Qbu 6frameformat.
SA frame format.
SMD-Cx 1 SMD-Fx 1
Ethertype 2 Fr ag Count
Table 2. Fragmented frame identifier. 1 Fr ag Count 1
4. Simulation Data
IdentifiersData Data Functions Data
4.1. IVN Model Design SMD-Sx Field to check first fragmented frame
FCS 4
SMD-Cx
FCS 4 FCS 4
Field to check if the fragment is continuing
FCS 4
An IVN model was designed
SMD-Fx
based on the traffic required for autonomous
Field to check last fragmented frame
driving vehicles (see
Figure (a) Normal
5). The basicframe format
IVN Frag
structure
Countand traffic information
(b)were
Fragmented
Fragmented
provided
frame
frame format
by a major
sequence motor company in
Korea, and we redesigned the IVN of each domain based on the traffic information. To illustrate the
Figure 4. IEEE 802.1Qbu frame format.
overall IVN structure, we configured a vehicle to four domains (Infotainment, Body, PT/Chassis, ADAS).
4. Simulation
4. Simulation
4.1. IVN Model Design
4.1. An
IVNIVN
Model Design
model was designed based on the traffic required for autonomous driving vehicles
(see Figure 5). The basic IVN structure
An IVN model was designed based and traffic
on the information
traffic required forwere provideddriving
autonomous by a major motor
vehicles (see
Figure 5). The basic IVN structure and traffic information were provided by a major motor company in
Korea, and we redesigned the IVN of each domain based on the traffic information. To illustrate the
overall IVN structure, we configured a vehicle to four domains (Infotainment, Body, PT/Chassis, ADAS).Sensors 2019, 19, 1111 6 of 11
company in Korea, and we redesigned the IVN of each domain based on the traffic information.
Sensors 2019, 19, x FOR PEER REVIEW 6 of 11
To illustrate the overall IVN structure, we configured a vehicle to four domains (Infotainment, Body,
PT/Chassis,
Each domain ADAS). had ECUs Each
anddomain
sensors,had andECUs and (GW)
a gateway sensors,
for and
eachapart
gateway
of the (GW) forGWs
vehicle. eachare part
usedof
the vehicle. GWs are used to interconnect other domains as necessary.
to interconnect other domains as necessary. In addition, the ADAS sensor fusion was designed as an In addition, the ADAS
sensor
ECU forfusion was designed
autonomous driving. asTheanADAS
ECU sensor
for autonomous
fusion ECUdriving. The
collects the ADAS sensor
information fromfusion ECU
the sensors,
collects
analyzesthe theinformation
information from
from the sensors,
adjacent analyzes
vehicles and the
the information from adjacent
road environment, vehicles
and extracts and the
information
road environment, and extracts information necessary for driving. This information
necessary for driving. This information leads to control commands necessary for autonomous driving. leads to control
commands
The IVN model necessary for autonomous
was configured driving.
so that the sensorsThe IVN model
required was configured
for autonomous drivingso thatcontinuously
were the sensors
required for autonomous driving were continuously generating data (see
generating data (see Table 3). The sensors included radio detection and ranging (RADARs) and Table 3). The sensors included
light
radio
detection and ranging (LIDARs). The RADAR was used to determine the distance, direction, was
detection and ranging (RADARs) and light detection and ranging (LIDARs). The RADAR and
used to determine
altitude of nearby the distance,
vehicles anddirection,
the LIDAR andwas altitude
usedoftonearby
identify vehicles and the LIDAR
the surrounding routeswas andused to
road
identify the surrounding routes and road conditions. The AVM (around view
conditions. The AVM (around view monitoring) is a vehicle camera information system that can see monitoring) is a vehicle
camera information
360 degrees outside thesystem thatincan
vehicle thesee 360 degrees
driver’s seat. Theoutside the vehicle
DSM (driver statusinmonitoring)
the driver’sisseat.
alsoThe DSM
a camera
(driver statussystem
information monitoring)
which iswasalso a camera
mounted information
inside system
the vehicle which was
to recognize themounted
pupil andinside thedrowsy
prevent vehicle
to recognize the pupil and prevent drowsy driving. In addition, ECUs for
driving. In addition, ECUs for infotainment of vehicles and ECUs for stream information coming infotainment of vehicles and
ECUs for stream
from outside the information comingsafety,
vehicle for control, from outside thearranged.
etc., were vehicle for control, safety, etc., were arranged.
Infortainment Body PT/Chassis ADAS
Domain Domain Domain Domain
RADAR
AMP Cluster ESC
x5
Integrated Head Up Ultrasonic
MDPS
Antenna Display wave
Mirrorless AVM CAM
Display
Display x4
Rear Seat Mirrorless CAM
Entertainment x3
Rear Left ADAS sensor fusion Forward CAM
Monitor
Rear Right
Laser scanner
Monitor
Ethernet DSM CAM
GW ECUs Sensors 100Mbps
1Gbps Infrared CAM
Figure 5. IVN model for autonomous driving vehicle.
Table 3. Background stream for advanced driving assistant system (ADAS) sensor fusion.
Table 3. Background stream for advanced driving assistant system (ADAS) sensor fusion.
Sensor Type Stream Size Number of Stream
Sensor Type Stream Size Number of Stream
RADAR
RADAR AVB
AVB 10 Mbps
10 Mbps 5 5
Ultrasonic wave AVB 15 kbps 1
Ultrasonic
AVM CAM
wave AVB
AVB
15 80
kbps
Mbps
1 4
AVM CAM
Mirrorless CAM AVB
AVB 80 Mbps
80 Mbps 4 3
Mirrorless
Forward CAMCAM AVB
AVB 80 Mbps
80 Mbps 3 1
Laser scanner
Forward CAM AVB
AVB 10 Mbps
80 Mbps 1 1
DSM CAM AVB 80 Mbps
Laser scanner AVB 10 Mbps 1 1
Infrared CAM AVB 80 Mbps 1
DSM CAM AVB 80 Mbps 1
Infrared CAM AVB 80 Mbps 1
4.2. Configuring Parameter Value
Prior to the overall simulation test, it was necessary to measure the change in end-to-end delay
according to the preemption guard band size, one of the variable parameters. As described above,Sensors 2019, 19, 1111 7 of 11
4.2. Configuring Parameter Value
Prior to the overall simulation test, it was necessary to measure the change in end-to-end delay
according to the preemption guard band size, one of the variable parameters. As described above,
using preemption reduces E2E delay and increases network efficiency. The most significant factor in
preemption is the size of the guard band that forms the time window between the ST and the non-ST.
Depending on the size of the guard band, more non-STs may be sent, so that the segmented traffic
is fully integrated and can reach the destination quickly. Therefore, we conducted experiments to
see how the delay changed according to the setting of the guard band size when transmitting ST
Sensors
and AVB2019, 19, x FORfor
streams PEER REVIEW
a simulation time of 5 s. We specified two streams (Stream 1, 2 in Table 5)7 and of 11
measured the preemption occurrence frequency and delay variation at the point where they intersected
using
(see preemption
Table reduces E2Eperiod
4). The transmission delay and increases
of the network
ST stream efficiency.
was set to 10 ms,Theandmost significant factor
the transmission period in
preemption is the size of the guard band that forms the time window between
of the AVB stream was set to 125 µs, which conforms to the transmission requirements of the SR Class the ST and the non-
ST.The
A. Depending
minimum onguard
the size of the
band guard
size was band,
set to more non-STs
80 bytes may be64sent,
(minimum bytesso of
that the segmented
frame processingtraffic
plus
is fully integrated and can reach the destination quickly. Therefore,
additional header information), and the maximum guard band size was set to 512 bytes. we conducted experiments to see
how the delay changed according to the setting of the guard band size when transmitting ST and AVB
streams for a simulationTable time4.ofE2E
5 s.delay
We specified two streams
variation according (Stream
to guard band1,size.
2 in Table 4) and measured
the preemption occurrence frequency and delay variation at the point where they intersected (see Table
5). The transmission periodPreemption
of the ST stream X was set to 10 ms, and theO transmission period of the AVB
stream was set to Guard
125 band size (byte)
μs, which conforms- to the transmission
80 128 requirements
256 of512
the SR Class A. The
minimum guardE2E band size
Delay was set
ST to 80 bytes
64.5 (minimum
64.5 64 bytes
64.5 of frame
64.5 processing
64.5 plus additional
header information), and the maximum guard band size was set to 512 bytes. 235
(µs) AVB 234 201 198 233
Experimental results
Experimental results show
show that if the
that if the guard
guard band
band becomes
becomes too
too large
large oror small,
small, the
thefrequency
frequency ofof
preemption decreases or increases, resulting in poor data transmission efficiency. Taken together,
preemption decreases or increases, resulting in poor data transmission efficiency. Taken together, it can it can
be concluded
be concluded that
that the
the optimal
optimal guard
guard band
bandsize
sizeisis128
128bytes
bytes(see
(seeFigure
Figure6).
6).Based
Basedon onthese
theseexperimental
experimental
results, the overall TSN performance test was conducted with the guard band size
results, the overall TSN performance test was conducted with the guard band size of 128 bytes. of 128 bytes.
300
233 235
250
201 198
200
142 135
150
103
100
45
50
0
80 128 256 512
Guard band size (byte)
E2E Delay (μs) Preemption occurrence numbers
Figure 6. E2E delay and preemption frequency variation according to guard band size.
Figure 6. E2E delay and preemption frequency variation according to guard band size.
4.3. Performance Test on TSN Integrated Environment
For the TSN performance experiment, the stream of each ECU and sensor was allocated after the
design of the IVN model. It was divided into a total of 16 streams, and periodic data transmission
was performed by specifying the source to the destination according to the ST and AVB transmission
formats defined in the TSN standard (see Table 3). Depending on the IVN domain, links exceeding
100 Mbps were replaced by 1 Gbps links. This is because relatively large video and voice data are
mixed in the domain of ADAS and Infotainment. The size of the guard band was set to 128 bytes,
which was derived as the optimal value.Sensors 2019, 19, 1111 8 of 11
Table 5. TSN streams for autonomous driving.
Bandwidth E2E Delay (µs)
Stream Info Type Source Destination Size (Byte) * Diff. (µs)
Allocation
Gen1 Gen2
(bps)
1 Navigation/AVM ST Infotainment ADAS 60 704 k 98.5 64.5 34
Navigation
2 AVB Infotainment HUD 2 80 M 334.5 198 136.5
data
3 Navigation/Audio AVB Infotainment Cluster 2 48 k 217.8 110 107.8
4 Audio AVB Infotainment AMP 11 125 k 200 98.5 101.5
5 Entertainment AVB Infotainment RSE 1250 125 k 120 120.9 −0.9
Rear Left
Entertainment AVB RSE 1250 80 M 212.9 212 0.9
6 Monitor
Rear Right
Entertainment AVB RSE 1250 80 M 212.9 212 0.9
Monitor
Integrated
7 GPS/V2X AVB Infotainment 16 1M 54.4 54.4 0
Antenna
8 Control data ST Body PT/Chassis 4 3k 101 50.9 50.1
PT/Chassis ADAS Sensor
9 ST PT/Chassis 230 184 k 100 50.2 49.8
info fusion
ADAS sensor ADAS Sensor
10 AVB Cluster 2 125 k 125 123.3 1.7
fusion fusion
ADAS sensor ADAS Sensor
11 AVB HUD 2 125 k 125 123.3 1.7
fusion fusion
Forward ADAS Sensor Integrated
12 AVB 250 80 M 315.4 345.6 −30.2
camera fusion Antenna
ADAS Sensor
13 Control data ST ESC 625 500 k 99.3 57.1 42.2
fusion
ADAS Sensor
14 Control data ST MDPS 625 500 k 99.3 57.1 42.2
fusion
ADAS Sensor
15 AVM image AVB Display 1250 80 M 210.7 209.8 0.9
fusion
Mirrorless ADAS Sensor Mirrorless
16 AVB 1250 80 M 205.7 199 6.7
image fusion Display
* Diff. = Difference of E2E delay.Sensors 2019, 19, 1111 9 of 11
4.3. Performance Test on TSN Integrated Environment
For the TSN performance experiment, the stream of each ECU and sensor was allocated after the
design of the IVN model. It was divided into a total of 16 streams, and periodic data transmission
was performed by specifying the source to the destination according to the ST and AVB transmission
formats defined in the TSN standard (see Table 3). Depending on the IVN domain, links exceeding
100 Mbps were replaced by 1 Gbps links. This is because relatively large video and voice data are
mixed in the domain of ADAS and Infotainment. The size of the guard band was set to 128 bytes,
which was derived as the optimal value.
Experimental results show that applying the TSN preemption in combination with ST transmission
was more efficient in terms of the E2E delay than using AVB only. It was shown that the delay was
reduced in most cases except for streams 5 and 12. Concerning the difference of E2E delay in Table 5,
the delay was not reduced due to the fact that the preemption occurred more frequently than necessary
under too much traffic by chance. Based on this result, it can be inferred that the proper spacing of the
ST, placement of the IVN link, and setting of the guard band size in the preemption are important for
IVN design for autonomous driving. As a result of comparing the E2E delays between an AVB and
TSNs through experiment, it was confirmed that TSNs satisfy the ST transmission requirements and
the frame preemption required to compensate for the delay time caused by AVB stream transmission
interruptions (see Table 5).
Through this experiment, it was found that the results can vary greatly depending on how the
traffic is arranged and the parameter values are configured in the environment where the functions of
TSN standards are integrated. In the future, it may be necessary to modify some of the requirements or
recommended parameters of existing standards. This is because the performance of TSNs may not be
as desirable when various standards, such as the queuing policies and the link speed configurations
of IEEE 802.3 with speeds of 10, 100 Mbps, or greater than 1 Gbps, are integrated into newly revised
802.1Q. We will proceed with further implementation and experimentation to address these issues.
5. Conclusions
In this paper, a simulator was developed by integrating the main TSN functions under
development. Based on the ST for streaming and control data from various sensors provided by a major
motor company in Korea, we constructed a TSN in a vehicle for autonomous driving. When testing
various standard functions in the integrated environment, it was found that the TSN time-division
transmission method was required to satisfy the requirements and that the preemption was required to
compensate for the AVB delay. Also, the optimal size of the guard band was found to be 128 bytes for
autonomous vehicles through analysis. We anticipate that various future standards for TSNs will be
published and that when these standards are applied to an integrated environment, the requirements
presented in the existing standards will need to be reconsidered.
In the future, we plan to integrate key features of the upcoming standards such as IEEE 802.1Qci,
802.1Qch, 802.3cg, 802.3ch, and so forth into the simulator developed. This next research topic would
include additional performance tests by collecting vehicle traffic data from vehicle original equipment
manufacturers (OEMs).
Author Contributions: Conceptualization, J.L. and S.P.; investigation, J.L.; software, J.L.; supervision, S.P.;
validation, J.L.; and writing, review, and editing, J.L. and S.P.
Funding: This work was funded by the National Research Foundation of Korea (NRF) grant funded by the Korea
government (MOE: Ministry of Education) (No. 2018R1D1A1A02048970).
Acknowledgments: This work was supported by the National Research Foundation of Korea (NRF) grant funded
by the Korea government (MOE: Ministry of Education) (No. 2018R1D1A1A02048970).
Conflicts of Interest: The authors declare no conflict of interest.Sensors 2019, 19, 1111 10 of 11
References
1. Cena, G.; Valenzano, A. FastCAN: A high-performance enhanced CAN-like network. IEEE Trans. Ind.
Electron. 2000, 47, 951–963. [CrossRef]
2. Paret, D. Multiplexed Networks for Embeded Systems: CAN LIN FlexRay Safe-by-Wire; Wiley: Chichester, UK,
2007.
3. Navet, N.; Song, Y.; Simonot-Lion, F.; Wilwert, C. Trends in Automotive Communication System. Proc. IEEE
2005, 93, 1024–1223. [CrossRef]
4. Makowitz, R.; Temple, C. FlexRay—A communication network for automotive control systems. In Proceedings
of the IEEE International Workshop on Factory Communication Systems, Torino, Italy, 28–30 June 2006;
pp. 207–212.
5. Time-Sensitive Networking Task Group. Available online: http://www.ieee802.org/1/pages/tsn.html
(accessed on 22 January 2019).
6. IEEE Standard for Local and Metropolitan Area Network—Bridges and Bridged Networks—IEEE Std
802.1Q-2018 (Revision of IEEE Std 802.1Q-2014). Available online: http://www.ieee802.org/1/pages/tsn.
html (accessed on 22 January 2019).
7. IEEE Standard for Local and Metropolitan Area Networks-Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks—Amendment: Enhancements for Scheduled Traffic—IEEE Std 802.1Qbv-2015
(Amendment to IEEE Std 802.1Q-2014). Available online: http://www.ieee802.org/1/pages/tsn.html
(accessed on 22 January 2019).
8. IEEE Standard for Local and Metropolitan Area Networks-Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks—Amendment: Frame Preemption—IEEE Std 802.1Qbu-2016 (Amendment
to IEEE Std 802.1Q-2014). Available online: http://www.ieee802.org/1/pages/tsn.html (accessed on 22
January 2019).
9. IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—Amendment
29: Cyclic Queuing and Forwarding—IEEE 802.1Qch-2017 (Amendment to IEEE Std 802.1Q-2014). Available
online: http://www.ieee802.org/1/pages/tsn.html (accessed on 22 January 2019).
10. Alderisi, G.; Patti, G.; Bello, L.L. Introducing support for scheduled traffic over IEEE audio video bridging
networks. In Proceedings of the 2013 IEEE 18th Conference on Emerging Technologies & Factory Automation
(ETFA), Cagliari, Italy, 10–13 September 2013; pp. 1–9.
11. Meyer, P.; Steinbach, T.; Korf, F.; Schmidt, T.C. Extending IEEE 802.1 AVB with time-triggered scheduling:
A simulation study of the coexistence of synchronous and asynchronous traffic. In Proceedings of the IEEE
Vehicular Networking Conference (VNC 2013), Boston, MA, USA, 16–18 December 2013; pp. 47–54.
12. Steiner, W.; Craciunas, S.S.; Oliver, R.S. Traffic Planning for Time-Sensitive Communication. IEEE Commun.
Stand. Mag. 2018, 2, 42–47. [CrossRef]
13. IEEE Standard for Local and Metropolitan Area Networks—Timing and Synchronization for Time-Sensitive
Applications—IEEE Std 802.1AS-Rev, Draft 7.0-2018. Available online: http://www.ieee802.org/1/pages/
tsn.html (accessed on 22 January 2019).
14. Ko, J.; Lee, J.H.; Park, C.; Park, S.K. Research on Optimal Bandwidth Allocation for the Scheduled Traffic
in IEEE 802.1 AVB. In Proceedings of the 2015 IEEE International Conference on Vehicular Electronics and
Safety (ICVES), Yokohama, Japan, 5–7 November 2015; pp. 31–35.
15. Lee, H.; Lee, J.; Park, C.; Park, S. Time-aware preemption to enhance the performance of Audio/Video
Bridging (AVB) in IEEE 802.1 TSN. In Proceedings of the IEEE International Conference on Computer
Communication and the Internet (ICCCI 2016), Wuhan, China, 13–15 October 2016; pp. 80–84.
16. Thiele, D.; Ernst, R. Formal worst-case performance analysis of time-sensitive Ethernet with frame
preemption. In Proceedings of the 2016 IEEE 21st International Conference on Emerging Technologies
and Factory Automation (ETFA), Berlin, Germany, 6–9 September 2016; pp. 1–9.
17. Zhou, Z.; Yan, Y.; Ruepp, S.; Berger, M. Analysis and implementation of packet preemption for Time Sensitive
Networks. In Proceedings of the 2017 IEEE 18th International Conference on High Performance Switching
and Routing (HPSR), Campinas, Brazil, 18–21 June 2017; pp. 1–6.
18. Simon, C.; Maliosz, M.; Mate, M. Design Aspects of Low-Latency Services with Time-Sensitive Networking.
IEEE Commun. Stand. Mag. 2018, 2, 48–54. [CrossRef]Sensors 2019, 19, 1111 11 of 11
19. Pop, P.; Raagaard, M.L.; Craciunas, S.S.; Steiner, W. Design optimisation of cyber-physical distributed systems
using IEEE time-sensitive networks. IET Cyber-Phys. Syst. Theory Appl. 2016, 1, 86–94. [CrossRef]
20. IEEE Standard for Ethernet Amendment 5: Specification and Management Parameters for Interspersing
Express Traffic–IEEE Std 802.3br-2016. Available online: http://www.ieee802.org/1/pages/tsn.html
(accessed on 22 January 2019).
© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access
article distributed under the terms and conditions of the Creative Commons Attribution
(CC BY) license (http://creativecommons.org/licenses/by/4.0/).You can also read
