Page 1 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Chapter 14 Testing Reusable Software Components in Safety-Critical Real-Time Systems
Page 2 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Overview qIntroduction qReuse and Exhaustive Testing qReuse and Statistical Evidence q Component Reuse, Statistical Evidence and Failure Behavior
Page 3 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Introduction q How dynamic verification of real-time software relates to component reuse in safety-critical real-time systems. l Re-testing cannot be eliminated in general. l Ariane 5 l Therac 25 q Contract l Pre-conditions l Post-conditions l Invariants
Page 4 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Reuse and Exhaustive Testing q Provide evidence based on the component’s: l Contracts, l Experience accumulated, l That a component can be reused immediately, l That only parts can be reused or that it cannot be reused.
Page 5 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems First Use
Page 6 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems New Environment New Environment
Page 7 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Overlapping Input Domain
Page 8 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Pre- and Post-conditions Telephone A G...P Pre-condition ( (0 input1 1027) && (”G” input2 ”P”) ) // pre-condition statement 1;. statement n; Post-condition(345 output 640 ) // post-condition A component with Pre- and Post-conditions
Page 9 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Updated Pre- and Post-conditions Telephone B A...F Pre-condition ( (-17 input1 1027) && (”A” input2 ”P”) ) // pre-condition statement 1;. statement n; Post-condition (45 < output < 640 ) // post-condition A new environment would violate the pre- and post-conditions unless they are updated
Page 10 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Reliability and Confidence for a Input Domain R(c) C(c) I(c) A graph representing the reliability and the confidence for a input domain
Page 11 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Lower Reliability Requirements R(c) C(c) I(c) A component reused in a context with lower reliability requirements
Page 12 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Reaching Desired Reliability R(c) C(c) I(c) The component must be run for a longer time to reach the desired reliability
Page 13 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Previously Experienced Reliability R(c) C(c) I(c) Previously experienced reliability cannot be utilized if input domains are outside historical use of the component
Page 14 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Component Reuse, Statistical Evidence and Failure Behavior q Failure l The inability of a system or component to perform its intended function as defined by the specification. l A failure is a consequence of a fault, which has been executed. l When a fault in a computer program is executed an error arise. l Finally, if the error propagates and becomes externally visible for an observer of a system or component, a failure occurs.
Page 15 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Byzantine and Arbitrary Failures q This failure mode is characterized by a non-assumption: l Meaning that there is absolutely no restriction with respect to which effects the component user may perceive. l The failure mode has therefore been called malicious or fail-uncontrolled. l This failure mode includes two-faced behavior: a component can output “X is true” to one component user, and “X is false” to another component user.
Page 16 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Sequential Failure Behavior q Control failures: l Selecting the wrong branch in an if-then-else statement. q Value failures: l Assigning an incorrect value to a correct (intended) variable. q Addressing failures: l Assigning a correct (intended) value to an incorrect variable.
Page 17 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Sequential Failure Behavior q Termination failures: l A loop statement failing to complete because the termination condition is never satisfied. q Input failures: l Receiving an (undetected) erroneous value from a sensor.
Page 18 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Failure Behaviors R(c) C(c) Failure behaviorAddressing failure The confidence in the measured reliability is decreased when new failure behaviors can develop
Page 19 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Timing Failure Behavior q This failure mode yields a correct result (value), although the procurement of the result is time-wise incorrect. l For example, deadline violations, start of task too early, incorrect period time, too much jitter, too many interrupts.
Page 20 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Deadline Requirements q If we reuse a component with only a deadline requirement in a new environment in which the execution time is shorter, the component can be reused without re-testing.
Page 21 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Deadline Requirements R(c) C(c) Worst case execution time Newold The deadline requirement is still fulfilled since the new execution time is shorter
Page 22 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Response Time R(c) C(c) Response timeTol minTol Max The response time for the reused component is within the tolerance is within the tolerance