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; firstname.lastname@example.org * Correspondence: email@example.com; 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) . The Ethernet TSN is still in the process of being developed. IEEE 802.1Q-2018 was completed in July 2018 . 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/sensors
Sensors 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 . 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 the
Sensors 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 . 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 . 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 . 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. .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. division and merging The preemption processes process shouldand of dividing be implemented by referring to IEEE 802.3br standards . 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, and
the 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
NEXT SLIDES ... Cancel