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 (pinello@eecs.berkeley.edu), 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