1. 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

2. 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

3. 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

4. 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.

5. Page 5 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems First Use

6. Page 6 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems New Environment New Environment

7. Page 7 Building Reliable Component-based Systems Chapter 14 - Testing Reusable Software Components in Safety- Critical Real-Time Systems Overlapping Input Domain

8. 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 0...1027 G...P 345...640 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

9. 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 -17...778 A...F 5...123 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

10. 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) 01027 A graph representing the reliability and the confidence for a input domain

11. 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) 01027 A component reused in a context with lower reliability requirements

12. 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) 01027 The component must be run for a longer time to reach the desired reliability

13. 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) 01027 Previously experienced reliability cannot be utilized if input domains are outside historical use of the component

14. 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.

15. 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.

16. 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.

17. 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.

18. 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

19. 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.

20. 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.

21. 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

22. 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