Part 1: In-­‐Car Networking PROTOCOLS: FLEXRAY AND MOST [C2X] Summer 2014 Protocols: FlexRay and MOST 1 FlexRay ²
MoGvaGon ª
ª
Drive/Brake/Steer-­‐by-­‐Wire CAN bus is prone to failures §  Line topology §  No redundant links ª
ª
ª
CAN bus is slow Need for short bus lines ⇨ deployment expensive, complicated Non-­‐determinism for all but one message class §  Worst case delay unacceptably high ª
Early soluGons by OEMs proprietary §  TTCAN, TTP/TTA, Byteflight, ... ª
FoundaGon of consorGum to develop new bus: FlexRay §  BMW, VW, Daimler, GM, Bosch, NXP, Freescale ª
First series deployment at end of 2006 (BMW X5) [C2X] Summer 2014 Protocols: FlexRay and MOST 2 FlexRay ²
Bus topology ª
ª
ª
Line, Star with bus terminaGon Max. distance per line: 24m OpGonal use of second channel §  Higher redundancy or(!) higher speed §  Up to 10 MBit/s for single channel, 20 MBit/s for dual channel ECU
24m
ECU
ECU
24m
ECU
24m
S
ECU
[C2X] Summer 2014 S
ECU
Protocols: FlexRay and MOST ECU
ECU
3 FlexRay ²
Bit transmission Need synchronized clocks in sender and receiver ª  Thus, need addiGonal bits for synchronizing signal sampling at receiver (done with each 1⇨0 flank) ª  Don’t use bit stuffing otherwise: message length becomes non-­‐determinisGc (cf. CAN) ª  New concept: frame each transmission, each frame, each Byte ª
§  Bus idle (1) §  Transmission Start Signal (0) •  Frame Start Signal (1) »  Byte Start Signal (1) »  Byte Start Signal (0) »  8 Bit Payload (…) •  Frame End Signal (0) §  Transmission End Signal (1) [C2X] Summer 2014 Protocols: FlexRay and MOST 4 FlexRay ²
Bus access ª
Bus cycle (ca. 1 μs .. 7 μs) §
§
§
§
ª
²
StaGc Segment Dynamic Segment (opt.) Symbol Window (opt.) Network Idle Time Global Cycle Counter keeps track of bus cycles passed StaGc Segment Slots of fixed length (2 .. 1023) ª  One Message per Slot ª  StaGc assignment (of slot and channel) to ECUs (i.e., TDMA) ⇨ bus access is collision free, determinisGc ª
[C2X] Summer 2014 Protocols: FlexRay and MOST 5 FlexRay ²
Dynamic Segment Split into minislots (also staGcally assigned to ECUs) ª  Messages (usually) take up more than one minislot ª  Slot counter pauses while message is being transmijed (thus, slot counters of channels A and B soon desynchronize) ª  Lower priority messages have higher slot number (thus sent later, or not at all) ª
²
Example: Static Segment
Dynamic Segment
Sym
Net Idle
(mini)slots
Channel A
1
2
3
Channel B
1
2
3
[C2X] Summer 2014 4
5
4
Protocols: FlexRay and MOST 6
7
5
8
6
9
7
6 FlexRay ²
Message format ª
Control Bits §  Bit 0: Reserved •  Unused, always 0 §  Bit 1: Payload Preamble Indicator •  In staGc segment: first 0 .. 12 Byte payload for management informaGon •  In dynamic segment: first 2 Byte payload contains Message ID (cf. UDP Port) 5 Bit
11 Bit
7 Bit
11 Bit
6 Bit
Control Bits
Frame ID
Length
Header
CRC
Cycle
Counter
[C2X] Summer 2014 Protocols: FlexRay and MOST 24 Bit
Payload
CRC
7 FlexRay ²
Message format ª
Control Bits §  Bit 2: Null Frame Indicator •  Indicates frame without payload •  Allows sending “no message” also in staGc segment (fixed slot lengths!) §  Bit 3: Sync Frame Indicator •  Indicates frame may be used for synchronizing clock •  To be sent by 2 .. 15 “reliable” ECUs §  Bit 4: Startup Frame Indicator •  Used for synchronizaGon during bootstrap •  Sent by cold start node (⇨ later slides) 5 Bit
11 Bit
7 Bit
11 Bit
6 Bit
Control Bits
Frame ID
Length
Header
CRC
Cycle
Counter
[C2X] Summer 2014 Protocols: FlexRay and MOST 24 Bit
Payload
CRC
8 FlexRay ²
Message format ª
Frame ID §  IdenGfies message (≜ slot number) ª
Length §  Length of payload (in 16 Bit words) ª
ª
Header CRC Cycle Counter §  Global counter of passed bus cycles ª
Payload §  0 .. 127 16 Bit words (≜ 0 .. 254 Byte of payload) ª
CRC 5 Bit
11 Bit
7 Bit
11 Bit
6 Bit
Control Bits
Frame ID
Length
Header
CRC
Cycle
Counter
[C2X] Summer 2014 Protocols: FlexRay and MOST 24 Bit
Payload
CRC
9 FlexRay ²
Time synchronizaGon ª
Need synchronized bit clock + synchronized slot counter Want no dedicated Gme master ⇨ Distributed synchronizaGon Configure (typically) three nodes as “cold start nodes” ª
Cold start procedure (followed by all cold start nodes): ª
ª
§  Check if bus idle •  if bus not idle ⇨ abort (cold start already proceeding or unneeded) §  Transmit wakeup (WUP) pajern •  if collision occurs ⇨ abort •  if no collisions occurred ⇨ this is the leading cold start node ª
Cold start procedure (leading cold start node): §  Send Collision Avoidance Symbol (CAS) §  Start regular operaGons (cycle counter starts at 0) •  Set Bits: Startup Frame Indicator ⊕ Sync Frame Indicator [C2X] Summer 2014 Protocols: FlexRay and MOST 10 FlexRay ²
Time synchronizaGon ª
Cold start procedure (other cold start nodes) §  Wait for 4 Frames of leading cold start node §  Start regular operaGons •  Set Bits: Startup Frame Indicator ⊕ Sync Frame Indicator ª
Cold start procedure (regular ECUs) §  Wait for 2 Frames of 2 cold start nodes §  Start regular operaGons *1*
WUP
WUP
*2*
WUP
↯
*3*
↯
4
5
6
7
8
...
4
5
6
7
8
...
4
5
6
7
8
...
4
6
7
8
...
5
6
7
8
...
[C2X] Summer 2014 CAS
0
1
2
Protocols: FlexRay and MOST 3
11 FlexRay ²
Example configuraGon of Gming Use fixed payload length of 16 Byte (with header and trailer: 24 Bytes; with FSS, BSS, FES: ca. 250 Bits) ª  10 Mbps data rate ⇨ 25 µs message duraGon ª  Add 5 µs guard to care for propagaGon delay and clock driq ⇨ 35 µs slot length in staGc segment ª  One macro Gck: 1 µs (can use 1 .. 6 µs) ª  One minislot: 5 macro Gcks: 5 µs ª  Tbit = 100 ns, sample rate of bus = Tbit/8 = 12.5 ns ª
static slot length = Tstatic,slot = 35 macro ticks = 35 µs
FlexRay frame with 16 Byte payload
Slot
Starts
[C2X] Summer 2014 Action Point
Offset TAP,Offset
frame duration TF ≈ 25 µs
Protocols: FlexRay and MOST Channel
Idle
Slot
Ends
12 FlexRay ²
Example configuraGon of Gming (contd.) Use 64 disGnct communicaGon cycles ª  CommunicaGon cycle duraGon: 5 ms ª  Use 3 ms for staGc segment ª  Remaining 2 ms used for dynamic segment, symbol window, network idle Gme ª
²
Message repeGGon interval fully customizable, e.g.: §
§
§
§
[C2X] Summer 2014 2.5 ms (one slot each at start and end of staGc segment) 5 ms (one slot each in every communicaGon cycle) 10 ms (one slot in every second communicaGon cycle) … Protocols: FlexRay and MOST 13 FlexRay ²
Example configuraGon of Gming (contd.) Static
Segment
Cycle 00
10ms
Cycle 01
20ms
Cycle 02
10ms
Cycle 03
40ms
Cycle 04
10ms
Cycle 05
20ms
0.5ms
...
Dynamic
Segment
0.5ms
...
SYM
+NIT
...
...
Cycle 63
2.5ms
Slots
Every…
...
Every…
5ms Cycle
2.5ms
Slots Multiplexing Slots Slots
2.5ms
1,9ms
3ms
100
µs
2ms
5ms
[C2X] Summer 2014 Protocols: FlexRay and MOST 14 FlexRay ²
Error prevenGon Integrate bus guard ª  Implement separately from communicaGon controller ª  Follows protocol steps in communicaGon controller ª  Can only enable bus driver when allowed to communicate, or permanently disable in case of errors (babbling idiot problem) Application
Logic
Comm
Controller
Enable
[C2X] Summer 2014 Bus
Driver
Bus Guard
Protocols: FlexRay and MOST FlexRay Bus
ª
Enable
15 FlexRay ²
Error handling ª
MulGple measures for error detecGon §
§
§
§
§
ª
Check cycle counter value Check slot counter value Check slot Gming Check header CRC Check CRC ReacGon to Gming errors §  Do not automaGcally repeat messages (⇨ non-­‐determinism) §  Switch to passive state instead •  Stop transmisng messages •  Keep receiving messages (might allow re-­‐synchronizaGon to bus) ª
ReacGon to severe, non-­‐recoverable errors §  Completely switch off bus driver [C2X] Summer 2014 Protocols: FlexRay and MOST 16 FlexRay ²
AUTOSAR TP ª
ª
ª
ª
Transport protocol of FlexRay Upwards compaGble to ISO 15765-­‐2 (ISO TP for CAN) Adjusted and extended for FlexRay Difference in addressing §  In CAN: CAN message ID assigned arbitrarily §  In FlexRay: Frame ID ≜ Slot Number (i.e., not arbitrary) ⇨ cannot use source/desGnaGon addresses as IDs in lower layer §  Address encoded only (and completely) in TP header ª
Also: §  New message types 1 .. 2 Byte
1 .. 2 Byte
1 .. 5 Byte
Target Address
Source Address
PCI
[C2X] Summer 2014 Protocols: FlexRay and MOST Payload
17 FlexRay ²
AUTOSAR TP ª
ª
Frame types: Single Frame Extended / First Frame Extended Larger data length (DL) field allows for longer payload §  Four kinds of first frames can indicate payloads of up to 4 GiB PCI Byte 0
PCI Byte 1
Single Frame
0
DL
Single Frame Extended*
5
0
First Frame
1
First Frame Extended*
4
1
“
4
2
“
4
3
“
4
4
[C2X] Summer 2014 PCI Byte 2
PCI Byte 3
PCI Byte 4
DL
DL
DL
Protocols: FlexRay and MOST DL
DL
DL
18 FlexRay ²
AUTOSAR TP ª
Extended flow control §  FS values allow triggering abort of ongoing transmission •
•
•
•
FS=2: Overflow FS=5: Cancel, Data Outdated FS=6: Cancel, No Buffer FS=7: Cancel, Other §  ST split into two ranges to allow shorter separaGon Gmes •  0x00 .. 0x7F SeparaGon Time in ms •  0xF1 .. 0xF9 SeparaGon Time in μs (new!) PCI Byte 0
PCI Byte 1
PCI Byte 2
Consecutive Frame
2
SN
Consecutive Frame 2*
6
SN
Flow Control Frame
3
FS
BS
ST
Acknowledge Frame*
7
FS
BS
ST
[C2X] Summer 2014 Protocols: FlexRay and MOST PCI Byte 3
ACK
PCI Byte 4
SN
19 FlexRay ²
AUTOSAR TP ª
Extended flow control §  CAN: Acknowledgement by transmisng dominant bit in ACK field §  FlexRay: New Acknowledge Frame (AF) §  Use aqer single frame or aqer all consecuGve frames (as ACK) or immediately (as NACK) §  FuncGons idenGcal to Flow Control Frame, but adds ACK and SN nibbles •  ACK is 1 or 0; SN indicates slot number of first defecGve frame §  Sender may repeat failed transmissions at earliest convenience (alternately uses CF and CF2 frames) PCI Byte 0
PCI Byte 1
PCI Byte 2
Consecutive Frame
2
SN
Consecutive Frame 2*
6
SN
Flow Control Frame
3
FS
BS
ST
Acknowledge Frame*
7
FS
BS
ST
[C2X] Summer 2014 Protocols: FlexRay and MOST PCI Byte 3
ACK
PCI Byte 4
SN
20 MOST ²
Media Oriented Systems Transport specifies ISO layers 1 through 7 ª  Does not focus on sensor/actor tasks (e.g., delay, fault tolerance), but on infotainment (e.g., jijer, data rate) ª
²
History DomesGc Data Bus (D2B, later: DomesGc Digital Bus) developed by Philips, later standardized as IEC 61030 (sGll in the 90s) ª  Lijle adopGon in vehicles, thus SMSC soon develops a successor ª  1998: MOST CooperaGon standardizes MOST bus (Harman/Becker, BMW, DaimlerChrysler, SMSC) ª  December 2009: MOST 3.0E1 published ª  Today: MOST cooperaGon numbers 60 OEMs, 15 vehicle manufacturers ª
[C2X] Summer 2014 Protocols: FlexRay and MOST 21 MOST ²
Medium PlasGc OpGc Fiber (POF) alternaGve (copper) variant specified, but lijle used ª  Data rates specified from 25 (MOST25) to 150 MBit/s (MOST150) ª  Manchester coded bit transmission ª  Dedicated Gming master ECU (slaves adopt bit Gming) ª  Logical bus topology: ring of up to 64 ECUs ª  Physical bus topology can differ ª
ECU
POF
Master
ECU
ECU
ECU
[C2X] Summer 2014 Protocols: FlexRay and MOST ECU
22 MOST ²
Link Layer ª
ª
ª
Synchronous bit stream; all clocks synchronized to Gming master Stream divided into blocks; each block traverses ring exactly once Blocks divided into 16 Frames §  Frame size: 64 Byte (MOST25) to 384 Byte (MOST150) §  Frame rate staGc but configurable; recommended: 48 kHz (DVD) ª
Frame divided into §  Header (with boundary descriptor) and Trailer §  Data: Synchronous Channel, Asynchronous Channel, Control Channel 1 Frame = 64 Byte
22,67µs
Header
1 Byte
Data Field 60 Byte
Synchronous
Asynchronous
Control Data
2 Byte
Trailer
1 Byte
Boundary Descriptor
[C2X] Summer 2014 Protocols: FlexRay and MOST 23 MOST ²
Link Layer ª
Synchronous Channel §  Use case: audio or video §  TDMA divides frame into streaming channels ⇨ determinisGc §  Reserved by messages on control channel §  Thus, no addressing required §  Maximum number of streaming channels limited by frame size Streaming Channel 1
Streaming Channel 2
Streaming Channel 3
CD-Audio, Device A
DVD-Video, Device B
...
[C2X] Summer 2014 Protocols: FlexRay and MOST unused
24 MOST ²
Link Layer ª
Asynchronous Channel §  Use case: TCP/IP §  Random access with arbitraGon (based on message priority) ⇨ non-­‐determinisGc §
§
§
§
Single message may take more than one frame Short addiGonal header contains source/desGnaGon address, length Short addiGonal trailer contains CRC No acknowledgement, no automaGc repeat on errors 1 Byte
2 Byte
1 Byte
2 Byte
Arbitration
Target Address
Len
Source Address
[C2X] Summer 2014 Protocols: FlexRay and MOST 4 Byte
...
CRC
25 MOST ²
Link Layer ª
Control Channel §  Management and control data §  Random access with arbitraGon (based on message priority) §  Message length 32 Byte •  MOST25 control channel uses 2 Bytes per frame ⇨ each message takes 16 Frames = 1 Block §  Message recepGon is acknowledged by recipient §  Failed transmissions are automaGcally repeated 1 Byte
2 Byte
2 Byte
1 Byte
17 Byte
2 Byte
1 Byte
Arbitration
Target
Address
Source
Address
Type
Data
CRC
Trailer
[C2X] Summer 2014 Protocols: FlexRay and MOST 26 MOST ²
Link Layer ª
Control Channel messages §  Resource AllocaGon, Resource De-­‐allocaGon: •  manage streaming channels in synchronous segment §  Remote Read, Remote Write •  accesses registers and configuraGon of ECUs §  Remote Get Source •  query owner of streaming channels in synchronous segment §  … •  Other message types are transparently passed to upper layers [C2X] Summer 2014 Protocols: FlexRay and MOST 27 MOST ²
Link Layer ª
Addressing §  16 Bit addresses §  physical address •
•
•
•
According to relaGve posiGon in ring Master gets 0x400 First slave gets 0x401 etc. §  logical address •  Assigned by master •  Typically upwards of 0x100 (Master) §  groupcast •  Typically 0x300 + ID of funcGon block §  broadcast •  Typically 0x3C8 [C2X] Summer 2014 Protocols: FlexRay and MOST 28 MOST ²
Ring disrupGon ª
Causes §  ECU stops working §  PlasGc opGc fiber gets damaged ª
Symptoms §  Messages either not transmijed to recipient, or not back to sender thus: total failure of bus ª
Diagnosis §  Ring disrupGon easily detected §  Reason and affected ECUs impossible to determine ª
Workarounds §  Vendor dependent, proprietary §  oqen: use addiGonal single-­‐wire bus for further diagnosis [C2X] Summer 2014 Protocols: FlexRay and MOST 29 MOST ²
Higher layers: the Logical Device Model MOST Device
Function
Block
Function
Block
Function
Block
NetBlock
Application
1
Application
2
Network Service
MOST Network Interface Controller
Physical Interface
Source: MOST Specification 3.0E1
[C2X] Summer 2014 Protocols: FlexRay and MOST 30 MOST ²
Higher layers: Object oriented MOST Network Services ª
FuncGon block (= class) §  e.g. audio signal processing (0x21), audio amplifier (0x22), ... §  MulGple classes per device, mulGple devices per class §  Every device implements funcGon block 0x01 (MOST Netw. Services) ª
Instance §  Uniquely idenGfies single device implemenGng certain funcGon block ª
Property/Method §  Property (get/set value) §  Method (execute acGon) ª
OperaGon §  Set/Get/... (Property), Start/Abort/... (Method) ª
22.00.400.0 (20) ⇨ amplifier number 0: volume set to 20 [C2X] Summer 2014 Protocols: FlexRay and MOST 31 MOST ²
Higher layers: System boot and restart Master node announces reset of global state (all devices change status to Not-­‐OK and cease operaGons) ª  Master node iniGates system scan ª
§  IteraGvely polls all physical addresses for present funcGon blocks §  Devices answer with logical address, list of funcGon blocks, and instance numbers Master can detect ambiguous combinaGons of funcGon blocks and instance numbers ⇨ will then assign new instance numbers ª  Master keeps table of all device’s operaGon characterisGcs ª  Master reports to all devices: status OK ª  MOST Bus is now operaGonal ª
[C2X] Summer 2014 Protocols: FlexRay and MOST 32 MOST ²
Higher layers – MAMAC and DTCP ª
Trend towards all-­‐IP in consumer electronics addressed in MOST by introducing MAMAC (MOST Asynchronous Media Access Control) §  Encapsulates Ethernet and TCP/IP for transmission on MOST bus §  but: not supported by MOST services; needs to be implemented in soqware ª
Concerns of music/film industry wrt. digital transmission addressed in MOST by introducing DTCP (Digital Transmission Content ProtecGon) §  As known from IEEE 1394 (FireWire) §  BidirecGonal authenGcaGon and key exchange of sender/receiver §  Encrypted data transmission [C2X] Summer 2014 Protocols: FlexRay and MOST 33 In-­‐Car Ethernet ²
²
²
IEEE 802.3 Bob Metcalfe, David R. Boggs 1973, Parc CSMA/CD Ethernet ª
²
²
3 Mbit/s, 256 nodes, 1 km coax cable 1980-­‐ revised to become IEEE Std 802.3 Next big thing? ª
“AutomoGve. Cars will have three networks. (1) Within the car. (2) From the car up to the Internet. And (3) among cars. IEEE 802 is ramping up for these standards now, I hope.” -­‐-­‐/u/BobMetcalfe on hjp://redd.it/1x3fiq [C2X] Summer 2014 Protocols: FlexRay and MOST 34 In-­‐Car Ethernet ²
Why? ª
Old concept: §  Strictly separated domains §  Each served by specialized bus §  Minimal data interchange ª
Current trend: §  Advanced Driver Assistance Systems (ADAS) §  Sensor data fusion •  (in-­‐car, between cars) §  Ex: CooperaGve AdapGve Cruise Control (CACC) ª
Move from domain specific buses ⇨ general-­‐purpose bus [C2X] Summer 2014 Protocols: FlexRay and MOST 35 Ethernet ²
Physical layers ª
10BASE5 (aka Thicknet, aka IEEE Std 802.3-­‐1985) §  Manchester coded signal, typ. 2 V rise §  10 Mbit/s over 500m coax cable §  Nodes tap into core (“vampire tap”) ª
10BASE2 §  10 Mbit/s over “almost” 200m coax cable §  BNC connectors, T-­‐shaped connectors ²
Medium access: CSMA/CD ª
ª
Carrier sensed ⇨ medium busy Collision ⇨ jam signal, binary exponenGal backoff (up to 16 Gmes) [C2X] Summer 2014 Protocols: FlexRay and MOST 36 Ethernet ²
Physical layers ª
1000BASE-­‐T §  1 Gbit/s over 100m §  Cat 5e cable with 8P8C connectors, 4 twisted pairs of wires, mulG-­‐level signal (-­‐2, -­‐1, 0, +1, +2), scrambling, … §  Medium access §  No longer shared bus, but point to point §  Auto-­‐negoGated (Gming) master/slave ª
100GBASE-­‐ER4 §  100 Gbit/s over 40 km §  PlasGc OpGc Fiber (POF) ª
… [C2X] Summer 2014 Protocols: FlexRay and MOST 37 Ethernet ²
Link layer ª
Lightweight frame type OpGonal extensions, e.g., IEEE 802.1Q (idenGfier 0x8100) Directly encapsulates higher layer protocols, e.g., IPv6 (0x86DD) …or IEEE 802.2 Logical Link Control (LLC) frame (idenGfier is len) ª
Error-­‐checked, but only best effort delivery of data ª
ª
ª
(in Byte)
0
7
8
15
Preamble (1010..11)
Source MAC
Destination MAC
(opt) 802.1Q tag
Type/len
Payload (commonly 42-1500 Byte, max 1982 Byte)
Checksum
[C2X] Summer 2014 (Idle time)
Protocols: FlexRay and MOST 38 In-­‐Car Ethernet ²
In-­‐car Ethernet? ª
Almost all “in-­‐car” qualiGes absent §
§
§
§
§
§
§
ª
Heavy, bulky cabling Huge connectors SensiGve to interference Needs external power No delay/jijer/… guarantees No synchronizaGon Etc… But: §  …can be easily extended: §  New physical layers §  Tailored higher-­‐layer protocols [C2X] Summer 2014 Protocols: FlexRay and MOST 39 In-­‐Car Ethernet ²
One-­‐Pair Ether-­‐Net (OPEN) alliance SIG Founded: BMW, Broadcom, Freescale, Harman, Hyundai, NXP ª  2014: approx. 150 members ª  100 Mbit/s on single twisted pair, unshielded cable ª  Power over Ethernet (IEEE 802.3at) ª  Manufactured by Broadcom, marketed as BroadR-­‐Reach ª
²
Reduced Twisted Pair Gigabit Ethernet (RTPGE) task force Working on IEEE 802.3bp ª  1 Gbit/s over up to 15m single twisted pair cable ª
Source: Rosenberger Hochfrequenztechnik GmbH & Co. KG
[C2X] Summer 2014 Protocols: FlexRay and MOST 40 In-­‐Car Ethernet ²
Upper layers: TSN Many soluGons (e.g., SAE AS6802 “Time Triggered Ethernet”) ª  Current: IEEE 802.1 Time SensiGve Networking (TSN) task group (aka Audio/Video Bridging AVB task group, up unGl 2012) ª  Promoted by AVnu Alliance SIG (cf. IEEE 802.11 / Wi-­‐Fi Alliance) ª
²
Concept ª
ª
ª
ª
Needs TSN-­‐enabled switches / end devices Tight global Gme synchronizaGon Dynamic resource reservaGon on streams through network IEEE 802.1AS… extensions §  Layer 2 service ª
IEEE 802.1Q… extensions §  Frame tagging standard [C2X] Summer 2014 Protocols: FlexRay and MOST 41 In-­‐Car Ethernet ²
IEEE 802.1AS Time Synchronizing Service Subset of IEEE 1588 Precision Time Protocol (PTP) ª  Syncs clock value/frequency of all nodes ª  ElecGon of “master” Gme master (grandmaster clock), disseminates sync informaGon along spanning tree ª
²
IEEE 802.1Qat Stream ReservaGon Protocol (SRP) Talker adverGses stream (along with parameters) ª  AdverGsement is disseminated through network ª  Intermediate nodes check, block available resources, update adverGsement with, e.g., newly computed worst case latency ª  Listeners check (annotated) adverGsement, send registraGon message back to Talker ª  Intermediate nodes reserve resources, update mulGcast tree ª
[C2X] Summer 2014 Protocols: FlexRay and MOST 42 In-­‐Car Ethernet ²
IEEE 802.1Qav etc. Traffic Shaping ª
ª
ª
²
PrioriGze frames according to tags Avoid starvaGon, bursts, … e.g., Token bucket, with many more proposed IEEE 802.1Qbu Frame PreempGon ª
Can cancel ongoing transmissions (if higher priority frame arrives) ²
IEEE 802.1Qcb Media Redundancy ²
… [C2X] Summer 2014 Protocols: FlexRay and MOST 43 Main Takeaways ²
FlexRay ª
ª
ª
ª
²
MOST ª
ª
ª
ª
²
MoGvaGon Single or dual channel operaGon Distributed operaGon StaGc and dynamic segment MoGvaGon Topology and implicaGons Centralized operaGon Synchronous and asynchronous channel Ethernet ª
ª
ª
ª
Concept Drawbacks of classic standards New PHY layers New upper layers (TSN) [C2X] Summer 2014 Protocols: FlexRay and MOST 44