Logical Reliability of Interacting Real-Time Tasks Krishnendu Chatterjee, UC Berkeley Arkadeb Ghosal, UC Berkeley Thomas A. Henzinger, EPFL Daniel Iercan, ”Politehnica” U. of Timisoara Christoph M. Kirsch, University of Salzburg Claudio Pinello, Cadence Research Labs Alberto Sangiovanni-Vincentelli, UC Berkeley

2 Implementation Overview Specification Architecture Hosts Sensors s1s1 s2s2 sksk h1h1 h2h2 hnhn Properties - Task WCET - Hosts and sensors reliability Task Set t1t1 t2t2 tntn Communicator Set c1c1 c2c2 ckck Constraints - Task release time and dead line - Reliability constraints MAPPINGMAPPING MAPPINGMAPPING MAPPINGMAPPING

3 Logical Execution Time (LET) Task Model { release eventtermination event active Logical Execution Time (LET) Logical releaseterminationstartpreemptionresumecompletion running { Physical input read output written c1 LET Tasks and Communicators LET for task t1 c2 read c1 write c2

4 Timing 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 Reliability 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) 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 c1 24 ● 264 ● = 18/20 = 0.9

7 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 t sa LRC = 1LRC = 0.9 h specificationarchitecture1 h reliability = 0.8SRG =.96 reliability = 0.95SRG = 0.95 h architecture2

8 Assumptions 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 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 Refinement 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 Tasks A. Ghosal, T.A. Henzinger, D. Iercan, C.M. Kirsch, A.L. Sangiovanni-Vincentelli. 2006, EMSOFT, Seoul, Korea.

11 Schedulability 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 Example 0 r t1 t2 u1 u2 l1 l2 estimate1 estimate2 read1 read2 u1 l1 u2 l2 l1 l2 s1 s2 c13 c32 T1 T3 T2 e1e3e2 P1P2 s1s2

13 Example : Architecture 1 H1 (0.999)H2 (0.999)H3 (0.999) s1(0.999)s2(0.999)

14 Example : Implementation 1 H1 (0.999)H2 (0.999)H3 (0.999) s1(0.999)s2(0.999) t1t2 read1 read2 estimate1 estimate2

15 Example : Reliability Analysis 1 CommunicatorLRC u10.99 u20.99 Communicators LRCs Communicators SRGs CommunicatorSRG l u l u Implementation is reliable

16 Example : Reliability Analysis 2 CommunicatorLRC u u Communicators LRCs Communicators SRGs CommunicatorSRG l u l u Implementation is not reliable

17 Example : Implementation 2 H1 (0.999)H2 (0.999)H3 (0.999) s1(0.999)s2(0.999) t1 t2 read1 read2 estimate1 estimate2 t1 t2

18 Example : Reliability Analysis 3 CommunicatorLRC u u Communicators LRCs Communicators SRGs CommunicatorSRG l u l u Implementation is reliable

19 Example: Architecture 2 and Implementation 1 H1 (0.999)H2 (0.999)H3 (0.999) s11(0.999)s21(0.999) t1t2 read1 read2 estimate1 estimate2 s12(0.999)s22(0.999)

20 Example: Reliability Analysis 4 CommunicatorLRC u u Communicators LRCs Communicators SRGs CommunicatorSRG l u l u Implementation is reliable

21 Real Experiment H1 H2 H3 t1 t2 read1 read2 estimate1 estimate2 t1 t2 h1 h2 u1 u2

22 Comparison 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 Conclusion 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!