Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
Ingress Policing in Automotive Systems
Soheil Samii, General Motors R&DJohannes Specht, Univ. of Duisburg-Essen
Ethernet in Automotive Systems
Automotive Ethernet will grow – Advanced Driver AssistanceSystems (ADAS) is the major growth driver
IEEE-SA Ethernet & IP @ Automotive TechDay, October 2014Keynote by Ian Riches, Strategy Analytics
Fail-operational ADAS such as automated driving and activesafety applications require fault-tolerance mechanisms (maindriver: ISO 26262 “Road Vehicles – Functional Safety”). System-level solutions will have to include
P802.1CB Seamless Redundancy, andIngress Policing – let us revisit past discussions and makeprogress on this topic …
2
Agenda
Motivation and context for Ingress Policing
Revisit conclusions from Ingress Policing analysisat Dallas Plenary November 2013
Required properties and characteristics of ingresspolicing
Discussion on how to proceed with ingress policingin TSN
3
Example of Future ADAS Architecture
4
ECU ECU
Camera Radar
Radar Camera
Camera Radar
uC S
uC
uC
uC
S
uC
S
Switch Switch
BreakControlModule
SteeringControlModule
EngineControlModule
uC
uC
Powertrain andChassis domain
Active Safetydomain
DisplaymoduleuC S
Info
tain
men
tdo
mai
n
Ethernet Backbone(conceptual – will likelybe integrated in ECUs)
Seamless Redundancy in ADAS Architectures
5
ECU ECU
Camera Radar
Radar Camera
Camera Radar
uC S
uC
uC
uC
S
uC
S
Switch Switch
BreakControlModule
SteeringControlModule
EngineControlModule
uC
uC
Powertrain andChassis domain
Active Safetydomain
DisplaymoduleuC S
Info
tain
men
tdo
mai
n
Fail-operationalRing topology
802.1CB
Fail-operationalStar topology
802.1CB
Ethernet Backbone(conceptual – will likelybe integrated in ECUs)
Ingress Policing in ADAS Architectures
6
Camera Radar
Radar Camera
Camera Radar
uC S
uC
uC
uC
S
uC
S
Switch Switch
BreakControlModule
SteeringControlModule
EngineControlModule
uC
uC
DisplaymoduleS
Info
tain
men
tdo
mai
n
Powertrain andChassis domain
Active Safetydomain
Ethernet Backbone(conceptual – will likelybe integrated in ECUs)
ECU ECU
uC
Ingress Policing in ADAS Architectures
7
Camera Radar
Radar Camera
Camera Radar
uC S
uC
uC
uC
S
uC
S
Switch Switch
BreakControlModule
SteeringControlModule
EngineControlModule
uC
uC
DisplaymoduleS
Info
tain
men
tdo
mai
n
Powertrain andChassis domain
Active Safetydomain
Ethernet Backbone(conceptual – will likelybe integrated in ECUs)
ECU ECU
uC
Detection:• Monitoring and error detection by an independent
component (preferably the first bridge in the data path)Reaction:• Block stream, or entire port (i.e., don’t trust the talker)• Fault isolation (prevents error propagation and
potential blocking of non-faulty streams)• Fail silence (enables error detection for receivers)
Agenda
Motivation and context for Ingress Policing
Revisit conclusions from Ingress Policing analysisat Dallas Plenary November 2013
Required properties and characteristics of ingresspolicing
Discussion on how to proceed with ingress policingin TSN
8
Conclusions from Previous Meetings
The following two slides are taken fromMarkus Jochim’s presentation at IEEE 802Plenary in Dallas, November 2013:
9
http://www.ieee802.org/1/files/public/docs2013/tsn-jochim-ingress-policing-1113-v2.pdf
Per Stream(= Potentially higher number of filters per port)
Per Class(= Small number of filters per port)
ThresholdEnforcing
Blocking
• A faulty stream sent by a faulty talkeris not “silenced”.
• Other streams from faulty / fault freetalkers not affected.
• A faulty stream sent by faulty talker is“silenced”.
• Non-faulty streams sent by faultytalker are not necessarily silenced.
• If a talkerexceeds it’sconfiguredbandwidth limit, the faulty talker is “silenced”.
• In presence of a moderate babbler, a fault freestream sent by a fault free talker can becomefaulty. (Fault propagation. Fault not contained).
• Faulty streams sent by a faulty talker are notnecessarily silenced.
• A faulty stream sent by afaulty talker is not “silenced”.
• Non-faulty streams sent by faultytalkers can become faulty.
• A fault free stream sent by a faultfree talker becomes faulty. (Faultpropagation. Fault not contained)
ModerateBabbler
Per Stream(= Potentially higher number of filters per port)
Per Class(= Small number of filters per port)
ThresholdEnforcing
Blocking
• A faulty stream sent by a faulty talkeris not “silenced”.
• Other streams from faulty / fault freetalkers not affected.
• A faulty stream sent by faulty talker is“silenced”.
• Non-faulty streams sent by faultytalker are not necessarily silenced.
• If a talkerexceeds it’sconfiguredbandwidth limit, the faulty talker is “silenced”.
• In presence of a moderate babbler, a fault freestream sent by a fault free talker can becomefaulty. (Fault propagation. Fault not contained).
• Faulty streams sent by a faulty talker are notnecessarily silenced.
• A faulty stream sent by afaulty talker is not “silenced”.
• Non-faulty streams sent by faultytalkers can become faulty.
• A fault free stream sent by a faultfree talker becomes faulty. (Faultpropagation. Fault not contained)
ModerateBabbler
Agenda
Motivation and context for Ingress Policing
Revisit conclusions from Ingress Policing analysisat Dallas Plenary November 2013
Required properties and characteristics of ingresspolicing
Discussion on how to proceed with ingress policingin TSN
12
Ingress Policing = Error Detection + Error HandlingError detection – desired properties [1]:
RELIABLE: If stream is exceeding its allocated bandwidth or violatingother properties as part of the traffic contract in its traffic class, then theerror detection mechanism shall detect it. If the stream is staying withinits allocated bandwidth and not violating the traffic contract, the errordetection shall not signal an error (i.e., no false positives). (Note:Tolerance of bandwidth monitor is tied to this property.)
FAST: The error detection shall with very low latency detect whenstreams exceed their bandwidth or violate traffic contracts
LITTLE DISRUPTION: The error detector shall cause little disruption to thenetwork
No/little influence on the normal operation of a bridge or network(e.g., CPU resources, delays in forwarding process, …)No/bounded influence of faulty streams on non-faulty streams in thenetwork
13
[1] Error detection properties in distributed systems: Leners et al., “Detecting failures in distributed systemswith the FALCON spy network,” Proc. of the 23rd ACM Symposium on Operating Systems Principles, 2011.
Ingress Policing = Error Detection + Error handling
Error handling (reaction):
Configurable among the following alternatives:
Block stream only (e.g., isolate only the faulty sensor but stillprovide the remaining data of the sensor network to theapplication, enabling controlled transition to safe state)
Block entire ingress port (e.g., the faulty behavior of a sensor maymake a set of sensor data obsolete, thus blocking an entire port;another argument is that for some critical sensors we cannotcontinue to trust the device in case one of its streams is faulty)
Enforce threshold for the faulty stream (there may be cases wherethe data is still useful to the application; there may be timeintervals where blocking is not an option).
14
Detection and ReactionImmediate Reactions
Fine grained (per stream) withoutdelays:
Threshold Enforcing(delaying/blocking individualframes)
Permanently assures QoS for faultfree streams in presence of faultystreams.
Detection RequirementsRequires fast detection at least on aper packet granularity level (trafficclass dependent) to assureimmediate reaction
15
Isolation Reactions• Coarse grained reactions:
– Stream blocking– Port blocking
• Isolates faulty components (e.g., toavoid single-point failure)
• May be complemented byreconfiguration/mode changes.
Detection Requirements• Requires unambiguous identification
of faulty component/must avoid falsepositive isolation decisions
• Identification and detection by firstbridge in the data path (i.e., at thefirst hop)
Precision of Stream-Based Detection
The bandwidth threshold to be monitored shall be ofsimilar granularity of the stream reservations
If not: We need to make larger per-stream bandwidthreservations only due to limited error-detectioncapabilities – this is not an issue for functional safety butreduces significantly the available bandwidth for regulardata communication.
16
Ingress Policing in AVB?
We currently implement stream-based ingresspolicing with blocking:1. software on an external microcontroller2. proprietary non-standardized capabilities in our AVB
Ethernet switches
This will only work for a specific use case and is notacceptable in the long run for ADAS, especiallyconsidering that the demand of fail-operationalADAS applications is growingWe need standardized solutions
17
Ingress Policing in AVB?
We currently implement stream-based ingresspolicing with blocking:1. software on an external microcontroller2. proprietary non-standardized capabilities in our
Ethernet switches
This will only work for a specific use case and is notacceptable in the long run for ADAS, especiallyconsidering that the demand of fail-operationalADAS applications is growingWe need standardized solutions
18
Agenda
Motivation and context for Ingress Policing
Revisit conclusions from Ingress Policing analysisat Dallas Plenary November 2013
Required properties and characteristics of ingresspolicing
Discussion on how to proceed with ingress policingin TSN
19
ConclusionIngress Policing has been discussed for a long time in the TSNgroup and is asked for by at least two industriesThe success of Ethernet in Automated Driving, Active Safety, andbroadly in ADAS depends on mechanisms like SeamlessRedundancy and Ingress Policing becoming available
Ingress policing capabilities:Error detection: Per-stream monitoring and error detection is amust in future fail-operational ADAS applications. Monitoring shallbe precise, same order as stream reservations.Reaction: Multiple alternatives must be available: Block individualstreams, block entire port, and enforce threshold.
Discussion: How do we proceed with standardizing appropriateingress policing capability?
20