Chapter 14 Testing Reusable Software Components in Safety-Critical Real-Time Systems

Building Reliable Component-based Systems

Chapter 14 - Testing Reusable Software Components in Safety-Critical Real-Time Systems

Chapter 14Chapter 14

Testing Reusable Software Components Testing Reusable Software Components in Safety-Critical Real-Time Systemsin Safety-Critical Real-Time Systems



OverviewOverview

Introduction Reuse and Exhaustive Testing Reuse and Statistical Evidence Component Reuse, Statistical Evidence and Failure

Behavior



IntroductionIntroduction

How dynamic verification of real-time software relates to component reuse in safety-critical real-time systems.

Re-testing cannot be eliminated in general. Ariane 5 Therac 25

Contract Pre-conditions Post-conditions Invariants



Reuse and Exhaustive TestingReuse and Exhaustive Testing

Provide evidence based on the component’s: Contracts, Experience accumulated, That a component can be reused immediately, That only parts can be reused or that it cannot be

reused.



First UseFirst Use

Dual band

1. 0...10

G...P

345…640

Necessary tests

0…1027

G…P



New Environment New Environment

Dual band

1. -17...

A...P

45…723

Necessary tests

-27…-1

A…P



Overlapping Input DomainOverlapping Input Domain

Dual band

1. -3...9

B...N

95…700

Necessary tests

-3…913

B…N



Pre- and Post-conditions 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



Updated Pre- and Post-conditionsUpdated 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



Reliability and Confidence for a Input DomainReliability and Confidence for a Input Domain

R(c)

C(c)

I(c)0 1027

A graph representing the reliability and the confidence for a input domain



Lower Reliability Requirements Lower Reliability Requirements

R(c)

C(c)

I(c)0 1027

A component reused in a context with lower reliability requirements



Reaching Desired Reliability Reaching Desired Reliability

R(c)

C(c)

I(c)0 1027

The component must be run for a longer time to reach the desired reliability



Previously Experienced ReliabilityPreviously Experienced Reliability

R(c)

C(c)

I(c)0 1027

Previously experienced reliability cannot be utilized ifinput domains are outside historical use of the component



Component Reuse, Statistical Evidence and Failure BehaviorComponent Reuse, Statistical Evidence and Failure Behavior

Failure The inability of a system or component to perform its

intended function as defined by the specification. A failure is a consequence of a fault, which has been

executed. When a fault in a computer program is executed an error

arise. Finally, if the error propagates and becomes externally

visible for an observer of a system or component, a failure occurs.



Byzantine and Arbitrary FailuresByzantine and Arbitrary Failures

This failure mode is characterized by a non-assumption: Meaning that there is absolutely no restriction with

respect to which effects the component user may perceive.

The failure mode has therefore been called malicious or fail-uncontrolled.

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.



Sequential Failure BehaviorSequential Failure Behavior

Control failures: Selecting the wrong branch in an if-then-else statement.

Value failures: Assigning an incorrect value to a correct (intended)

variable. Addressing failures:

Assigning a correct (intended) value to an incorrect variable.



Sequential Failure BehaviorSequential Failure Behavior

Termination failures: A loop statement failing to complete because the

termination condition is never satisfied. Input failures:

Receiving an (undetected) erroneous value from a sensor.



Failure BehaviorsFailure Behaviors

R(c)

C(c)

Failure behaviorAddressing failure

The confidence in the measured reliability is decreased when new failure behaviors can develop



Timing Failure BehaviorTiming Failure Behavior

This failure mode yields a correct result (value), although the procurement of the result is time-wise incorrect.

For example, deadline violations, start of task too early, incorrect period time, too much jitter, too many interrupts.



Deadline RequirementsDeadline Requirements

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.



Deadline RequirementsDeadline Requirements

R(c)

C(c)

Worst case execution timeNew old

The deadline requirement is still fulfilledsince the new execution time is shorter



Response TimeResponse Time

R(c)

C(c)

Response timeTol min Tol Max

The response time for the reused componentThe response time for the reused component is within the toleranceis within the tolerance

Chapter 14 Testing Reusable Software Components in Safety-Critical Real-Time Systems

Documents

Transcript of Chapter 14 Testing Reusable Software Components in Safety-Critical Real-Time Systems