1 / 24

Logical Reliability of Interacting Real-Time Tasks

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

ishana
Download Presentation

Logical Reliability of Interacting Real-Time Tasks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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. Hosts M A P P I N G Task Set h1 h2 hn t1 t2 Sensors tn s1 s2 sk Communicator Set Properties Constraints c1 c2 ck - Task WCET • Task release time and • dead line • Hosts and sensors • reliability • Reliability constraints Overview Specification Implementation Architecture M A P P I N G M A P P I N G

  3. input read output written { Logical running running { Physical release event Logical Execution Time (LET) termination event write c2 read c1 active LET for task t1 c2 c2 c2 c2 c2 release start preemption resume completion termination c1 c1 c1 c1 c1 c1 c1 0 1 2 3 4 5 6 7 8 9 10 11 12 Logical Execution Time (LET) Task Model LET Tasks and Communicators

  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 2 4 ● 2 3 1 5 4 6 4 8 4 3 4 ● 3 4 6 4 8 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 c1 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. t h h h 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 specification architecture1 architecture2 s a reliability = 0.8 SRG = .96 LRC = 1 LRC = 0.9 reliability = 0.95 SRG = 0.95

  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. t1 c2 c1 t1 c1 c4 c2 c3 t2 t2 LRC(c2) ≤ LRC(c1) If LRC(c1) is satisfied, then LRC(c2) will be satisfied Release(t1) ≥ Release(t2) Termination(t1) ≤ Termination(t2) If t1 is schedulable, then t2 is schedulable Refinement Timing* Reliability *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. s1 s2 P1 P2 T1 T2 T3 c32 c13 t1 u1 l1 e1 e3 e2 t2 u2 l2 0 100 200 500 300 400 estimate1 r1 l1 u1 read1 s1 l1 read2 s2 l2 estimate2 l2 u2 r1 Example

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

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

  15. Example : Reliability Analysis 1 Communicators SRGs Communicators LRCs Implementation is reliable

  16. Example : Reliability Analysis 2 Communicators SRGs Communicators LRCs Implementation is not reliable

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

  18. Example : Reliability Analysis 3 Communicators SRGs Communicators LRCs Implementation is reliable

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

  20. Example: Reliability Analysis 4 Communicators SRGs Communicators LRCs Implementation is reliable

  21. H1 t1 t2 H2 t1 h1 t2 h2 H3 read1 u1 read2 u2 estimate1 estimate2 Real Experiment http://htl.cs.uni-salzburg.at

  22. Comparison LET and WCET LRC and SRG • Separation of timing requirements (LETs) from performance guarantees (WCETs) • Release and termination times are application dependent “logical” information • WCETs are platform dependent “physical” data • Separation of reliability requirements (LRCs) from reliability guarantees (SRGs) • LRCs are application dependent “logical” information • SRGs are platform dependent “physical” data

  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!

More Related