ECU0
ECU1
ECU2
CH0
CH1
et(C) = (15, 10, 15, 15)
rt(C) = (15, inf, 15, 15)
WCT= 5, timeout = 10
ft(C) = (10, inf, 10, 10)
it(C_I0) = (10, inf, 10, 10)
et(S) = (10, 10, inf, 10)
rt(S) = (10, 10, inf, 10)
WCT = 10, timeout = 0
ft(S) = (0, 0, inf, 0)
No Inputs
et(C2) = (20, 20, 15, 15)
rt(C2) = (20, 20, 15, inf)
WCT = 5, timeout = 15
ft(C2) = (15, 15, 10, inf);
it(C2_I0) = (10, 10, 10, inf)
et(In)j = rt(In)j if rt(In)j != inf
et(In)j = max(et(s)j, timeout) if rt(In)j == inf
et(In) = (80, 80, inf, 80)
rt(In) = WCT + ft(In) = (80, 80, inf, 80)
WCT = 60, timeout = max( {ft(in)j} \ {inf}) = 20
ft(In) = max(et(S), firingrule(it(In_I0), it(In_I1), it(In_I2), timeout)) = (20, 20, inf, 20), [2/3 firing rule]
it(In_I0) = rt(C) = (15, inf, 15, 15),
it(In_I1) = rt(S) = (10, 10, inf, 10),
it(In_I2) = rt(C2) = (20, 20, 15, inf)
I n this example,fi ringrule(it(I n_ I 0), it(I n_ I 1), it(I n_ I 2), timeout) = min((20, 20, 15, 15), timeout) =(20, 20, 20, 20)
Sens
Sens
Sens
Input
Input
I nput with f an-in:it(I n_ I 0) = min(rt(C1), …, rt(Ck))
data is received as soon as one source produced it
IntroductionDesigning cost-sensitive real-time control systems for safety-critical applications requires a careful analysis of the cost/fault-coverage trade-offs. This further complicates the tasks of deploying the corresponding embedded SW on the execution platform, typically distributed around the plant. We propose a synthesis-based design methodology that relieves designers from specifying how to tolerate execution platform faults and involves them in the definition of the overall fault-tolerance strategy: how to address plant faults (adaptive control algorithms), selection of a cost-effective execution platform.Verification tools analyze the solution to extract timing and to check the fault behavior (replica determinism, coverage, etc.). Finally a run-time library is being developed for the deployment of the resulting distributed system.
Fault Tolerant Design of Distributed Automotive SystemsClaudio Pinello ([email protected]), Prof. Sangiovanni-Vincentelli, UC Berkeley
Motivation
Drive-by-Wire
applications
• Architecture faults (channels, ECUs)– hardware redundancy
– software replication
– redundancy management
• Plant Faults (plant, sensors, actuators)– estimation and control
algorithms
• Application faults: bugs– can be reduced by
disciplined coding– code generation from formal
models– simulation– formal verification
FineCTRL
CoarseCTRL
SensAct
InputArbiterBest
OutputSens
SensAct
Design space exploration
• Verification provides timing + coverage• If not satisfactory?
– change architecture•more/fewer components,•vary the mix of performance
– change algorithms •introduce pipelining,
reduce/increase granularity– change fault behavior
•degrade sooner/later– provide hints to the synthesis tool
•replicate some actors, mapping constraints, precedence constraints
Sp
ecif
icat
ion
Syn
thes
is
System Faults
Design flow
• Actors: have criticality, inputs may have fan-in from redundant sources (replicas)
• Execution is synchronous and periodic: at each period all tasks are executed (data driven or time triggered), satisfying precedence constraints
• Inputs and Arbiters have partial firing rules
Programming model: Fault-tolerant Dataflow
• Metropolis library to model FTDF netlists
• Support for simulation, fault injection and visualization
• Early assessment of closed loop behavior in degraded modes
• Proposed design flow enables– greater separation of concerns
•application, architecture, fault behavior
– formal specification and verification of fault tolerant systems
– design space exploration
C. Pinello, L. P. Carloni, and A. L. Sangiovanni-Vincentelli "Fault-Tolerant Deployment of Embedded Software for Cost-Sensitive Real-Time Feedback-Control Applications," Proc. Conf. Design, Automation and Test in Europe (DATE), February 2004
Conclusions
• Connectivity:– bipartite graph Arch
•ECUs (Electronic Control Units)
•channels• Actuator/Sensor location
ECU2ECU1ECU0
Sens
Act
Sens Sens
Act
• Performance:– matrix of actor/ECU execution times– matrix of data/channel transmission
times
Timing analysis: dynamic (shown) and time-triggered execution
ArchitectureFault Behavior
• Failure patterns Pi Arch
– subsets of Arch graph that may fail simultaneously (in a same iteration)
• For each Pi specify which functionalities must be guaranteed – typically functionality chosen based on criticality
• Sample fault behavior:– {}: all actors– {ECU0} or {ECU1} or {ECU2}: only critical actors
Parse.exe SynDEx
Merge.exe
Input ArbiterBest Output
FineCTRL
CoarseCTRLSens
Sens
Sens Act
Act
Input ArbiterBest Output
ECU0
ECU1
ECU2
CH0
CH1
CoarseCTRL
Schedule.exe
FineCTRL
CoarseCTRL
SensAct
InputArbiterBest
OutputSens
SensAct
FaultBehavior
ECU0
ECU1
ECU2
CH0
CH1
Sens
Sens
Sens
Input
Input
CoarseCTRL
CoarseCTRL
FineCTRL
ArbiterBest
ArbiterBest
Output
Output
Act
Act
TimingVerification
Map
pin
g
ECU2ECU1ECU0
SensAct
Sens SensAct
Case Studies: BMW, GMVehicle Level Data-Flow Architecture
0
0.2
0.4
0.6
0.8
1
1.2
Saf
e P
erio
d (
no
rmal
ized
)
Supervisory Control
Brake by wire
Power UnitCoordinator
Steer ByWireForces applied on Vehicle
Torque req/ack
Directional and Stability Signals
DriverInterface
VehicleDynamics
Sensor Input
ActuatorOutput
Steering Position
Vehicle Speed
Torque req/ack
