Logical Reliability of Interacting Logical Reliability of Interacting Real-Time TasksReal-Time Tasks

Krishnendu Chatterjee, UC BerkeleyArkadeb Ghosal, UC BerkeleyThomas A. Henzinger, EPFL

Daniel Iercan, ”Politehnica” U. of TimisoaraChristoph M. Kirsch, University of SalzburgClaudio Pinello, Cadence Research Labs

Alberto Sangiovanni-Vincentelli, UC Berkeley

2

Implementation

OverviewOverview

Specification Architecture

Hosts

Sensors

s1 s2 sk

h1 h2 hn

Properties

- Task WCET

- Hosts and sensors reliability

Task Set

t1

t2

tn

Communicator Set

c1 c2 ck

Constraints

- Task release time and dead line- Reliability constraints

MAPPING

MAPPING

MAPPING

3

Logical Execution Time (LET) Task ModelLogical Execution Time (LET) Task Model

{release event termination event

active

Logical Execution Time (LET)

Logical

release terminationstart preemptionresume completion

running running{Physical

input read

output written

0 1 2 3 4 5 6 7 8 9 10

11

12

c1 c1 c1c1c1 c1c1

LET Tasks and Communicators

LET for task t1

c2 c2 c2c2 c2

read c1 write c2

4

TimingTiming

• Separation of requirements from guarantees– Timing requirements through LETs

– Performance guarantees through WCETs

• Separation of application from architecture– Release and termination times are application dependent “logical”

information

– WCETs are architecture dependent “physical” data

5

ReliabilityReliability

• Separation of reliability requirements from performance guarantee

• Separation of application dependent “logical” reliability from architecture dependent “physical” data

6

Logical (long-term) Reliability Constraint (LRC)Logical (long-term) Reliability Constraint (LRC)

• Each communicator has an LRC, a real number between 0 and 1

• LRC = 0.9 means in the long run, at least 0.9 fraction of all periodic

writes to the communicator are required to be valid

• A requirement on the specification– Similar to the concept of release times and termination times in LET

c1c1 c1c1 c1c1 c1c1 c1c1 c1c1 c1c1 c1c1 c1c1 c1c1

2 4 ● 2 64 ●3 1 845 34 34 64 84

1 + 1 + 0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 0 + 1 + 1 + 1 + 1 + 1 = 18/20 = 0.9

7

Singular (short-term) Reliability Guarantee (SRG)Singular (short-term) Reliability Guarantee (SRG)

• Guarantee of updating a communicator with valid value in one step

• A real number between 0 and 1– SRG = 0.95 means that the probability that a communicator gets a reliable

value at write instance is at least 0.95

– Similar to the concept of WCET in schedulability analysis

ts a

LRC = 1 LRC = 0.9

specification architecture1

reliability = 0.8 SRG = .96

reliability = 0.95 SRG = 0.95

architecture2

8

Assumptions on Architecture and InputsAssumptions on Architecture and Inputs

• Hosts are fail-silent– A host either works correctly or stops functioning (becomes silent)

• Hosts are connected over a reliable broadcast network

• Tasks algorithms are “correct”– If a task executes reliably, the output is correct

• Unreliability of inputs can be accounted for three models– If an input is unreliable, the task uses a pre-defined value– If any one of the inputs fails, the task fails to execute– If all inputs are unreliable, the task fails to execute; if a subset of the inputs

fail then the task may execute

9

Schedulability Analysis vs. Reliability AnalysisSchedulability Analysis vs. Reliability Analysis

• For all tasks, time safety is ensured – All replications of a task complete execution and transmission within

task LET

• For all communicators, long-run average of the number of reliable values observed at access points is at least LRC of the communicator– For race-free, memory-free specification, SRG of a communicator

should be no less than the corresponding LRC

10

RefinementRefinement

Timing* Reliability

t1

t2

c1

c2

LRC(c2) ≤ LRC(c1)

If LRC(c1) is satisfied, then LRC(c2) will be satisfied

t1

t2

c2

c4

c1

c3

Release(t1) ≥ Release(t2)Termination(t1) ≤ Termination(t2)

If t1 is schedulable, then t2 is schedulable

*A Hierarchical Coordination Language for Interacting Real-Time TasksA. Ghosal, T.A. Henzinger, D. Iercan, C.M. Kirsch, A.L. Sangiovanni-Vincentelli.2006, EMSOFT, Seoul, Korea.

11

Schedulability Analysis vs. Reliability AnalysisSchedulability Analysis vs. Reliability Analysis

• Refinement constraints ensure that if a specification is schedulable then refinement is schedulable for the matching implementation

• Refinement constraints ensure that if a specification is reliable then refinement is reliable for the matching implementation

12

ExampleExample

0

r1

r1

100 200 300 400 500

t1

t2

u1

u2

l1

l2

estimate1

estimate2

read1

read2

u1 l1

u2 l2

l1

l2

s1

s2

c13 c32T1 T3 T2

e1 e3 e2

P1 P2s1 s2

13

Example : Architecture 1Example : Architecture 1

H1 (0.999) H2 (0.999) H3 (0.999)

s1(0.999) s2(0.999)

14

Example : Implementation 1Example : Implementation 1

H1 (0.999) H2 (0.999) H3 (0.999)

s1(0.999) s2(0.999)

t1 t2

read1read2

estimate1estimate2

15

Example : Reliability Analysis 1Example : Reliability Analysis 1

Communicator LRC

u1 0.99

u2 0.99

Communicators LRCs Communicators SRGs

Communicator SRG

l1 0.998

u1 0.997

l2 0.998

u2 0.997

Implementation is reliable

16

Example : Reliability Analysis 2Example : Reliability Analysis 2

Communicator LRC

u1 0.9975

u2 0.9975

Communicators LRCs Communicators SRGs

Communicator SRG

l1 0.998

u1 0.997

l2 0.998

u2 0.997

Implementation is not reliable

17

Example : Implementation 2Example : Implementation 2

H1 (0.999) H2 (0.999) H3 (0.999)

s1(0.999) s2(0.999)

t1t2

read1read2

estimate1estimate2

t1t2

18

Example : Reliability Analysis 3Example : Reliability Analysis 3

Communicator LRC

u1 0.9975

u2 0.9975

Communicators LRCs Communicators SRGs

Communicator SRG

l1 0.998

u1 0.997999

l2 0.998

u2 0.997999

Implementation is reliable

19

Example: Architecture 2 and Implementation 1Example: Architecture 2 and Implementation 1

H1 (0.999) H2 (0.999) H3 (0.999)

s11(0.999) s21(0.999)

t1 t2

read1read2

estimate1estimate2

s12(0.999) s22(0.999)

20

Example: Reliability Analysis 4Example: Reliability Analysis 4

Communicator LRC

u1 0.9975

u2 0.9975

Communicators LRCs Communicators SRGs

Communicator SRG

l1 0.998999

u1 0.998

l2 0.998999

u2 0.998

Implementation is reliable

21

Real ExperimentReal Experiment

H1

H2

H3

t1

t2

read1

read2

estimate1

estimate2

t1

t2

h1h2

u1

u2

http://htl.cs.uni-salzburg.at

22

ComparisonComparison

• Separation of reliability requirements (LRCs) from reliability guarantees (SRGs)

• LRCs are application dependent “logical” information

• SRGs are platform dependent “physical” data

• Separation of timing requirements (LETs) from performance guarantees (WCETs)

• Release and termination times are application dependent “logical” information

• WCETs are platform dependent “physical” data

LET and WCET LRC and SRG

23

ConclusionConclusion

• Separation-of-concerns approach for the joint schedulability and reliability analysis of safety-critical real-time embedded applications

• Separation of reliability requirements in a specification, from the reliability guarantees offered by hosts and communication links

• The implementation must ensure that all timing and reliability requirements of the specification are met.

24

Thank you!