Logical Reliability of Interacting Real-Time Tasks Krishnendu Chatterjee, UC Berkeley Arkadeb...
-
Upload
jaden-linscomb -
Category
Documents
-
view
220 -
download
0
Transcript of Logical Reliability of Interacting Real-Time Tasks Krishnendu Chatterjee, UC Berkeley Arkadeb...
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!