Inspection of Safety-Critical Software Using Program-Function Tables

Jeffrey Smith, Richard Bruno, Vince Fumo

Question – Is there a more accurate photograph of Dr. Parnas?

D.L. Parnas circa 1970.

Outline

Three Approaches Darlington Nuclear Plant Software Inspection Examples Darlington Inspection Questions

Three Approaches

The authors outline three general approaches of assuring correct operation of safety-critical software:– Reliability– Rigour– Hazard Analysis

Reliability Approach

To increase safety one must increase system dependability. Inspection requires estimating system reliability. To subdivisions:

Reliability analysis – techniques for predicting system dependability.

Redundant design – techniques for increasing dependability by providing multiple system to accomplish the same task.

Rigorous Approach

Correctness can be achieved with highly formal methods.

Rigorous Construction – Methods for deriving programs from precise specification.

Verification – methods for showing that a program satisfies its specification.

Hazard Analysis

One must identify possible unsafe conditions. The authors outline two fundamental methods:

Analysis should be performed on code itself Analysis should be performed on

abstractions derived from the code.

Complimentary?

The common view is that designers must choose one of the approaches over the other two.

The author believes the three are complementary.

Darlington Nuclear Power Plant

Three independent software based shutdown systems.

The system can not perform any function not required in the shutdown plant.

If one system initiates shutdown, the other two systems can not interrupt the shutdown.

Difficulties in Software Inspection AECB had no confidence in its ability to detect

safety-relevant flaws. AECB not software experts and had difficulty

analyzing the complex software. Long-programs must be decomposed into smaller

pieces to be convinced of:– Each part in the decomposition implements its assigned

function.

– If each part of the decomposition implements its assigned function then the entire program is correct.

Conventional approach

Frequently find provisional assumptions that were not what the programmer intended.

Revise initial division/functional description and try again.

Continue this process iteratively until run out of time or give up.

This approach is not good enough for safety-critical software.

Functional Documentation

Define requirements in terms of mathematical relations.

Each document contains representation of certain relations, otherwise if is incomplete.

Additional information makes the document faulty --> information not directly related should go elsewhere.

Documents

System Requirements document System design document Software requirements document Software behavior specification Module interface specification Module internal design document

More functional documentation

Need precise notation for relations. Conventional notation is too complex. Multi-dimensional notation is the author’s

choice. Author feels tables have a practical

advantage.

Darlington Inspection

Uses two documents:– Software requirement document contains description of

actions that must be taken on a single pass through the periodic loop (the shutdown system is designed as a periodic loop).

– Program function descriptions describe effects of the execution of the loop body.

Goal:– Both documents describe the same functions.

– Confidence they are the right functions.

Example

Mathematical relations. Conventional notation.

Example Description

Search an array B, to find an element whose value is that of variable x.

Determines the value of j and present. j is an integer recording the index of the

element of B whose value is x. present is a boolean value, indicating

whether or not the value was found in B.

Example Code Consider this C++ code which solves the problem outlined on the

previous slide:

int j;boolean present;int B[N];

for (int k=1; k<N; k++) {if (B[k] == x) {

present = true;j = k;

}}

Binary Search Tree Example

If x is a node in a binary tree and y is a node to the left of x then value[y] <= value[x]. If y is a node to the right of x then value[y] >= value[x].

Our example finds the maximum value in the tree by starting at the root node and traversing the right most child until the right most child is NULL. When this node is found, its value is the maximal value.

Binary Search Tree Below is pseudocode to search for the maximum value in a binary search tree:

TREE MAX(x) {while (right[x] != NULL) {

do x right[x];}return(x)

}

Inspection Process

Designed around the following ideas:– Inspectors need quiet time to “think.”– Inspection results must be scrutinized carefully.– Lengthy inspections must be done is smaller

sessions (ie. multiple days)– Inspections must focus on small sections of the

program at one time.– All cases must be considered.– All parts of the programs must be inspected.

AECB Inspection Teams Requirements team – produces tabular

representation of the requirements. Code inspection team – produces program-

function tables from the code. Comparison team – finds equivalence between

requirements tables & program-function tables by showing step-by-step transformations from one to the other.

Audit team – checks the work of the other three teams on a “random” basis.

The inspection process

Requirements team comprised of nuclear safety experts not programmers. They constructed tables based on formal mathematical notation.

Code inspection team was comprised of software consultants not part of the nuclear industry. They were programming experts.

The inspection process cont.

The comparison team were people trained to understand program-function tables. They worked from the program-function tables and the requirements tables. This team was charges with showing a step-by-step transformation of the tables resulting in both tables showing the same information.

The inspection process cont.

The audit team was comprised of software experts.

When an error is found, the second team is asked to check the work again.

If error is still found it is reported to the safety experts for evaluations.

Evaluation

Usually the error fell into one of these categories:– Requirements tables were wrong.– Programmer added something extra in an effort

to improve things.– Coding error, not effecting safety – it was left

in the system!– Coding error, which did effect safety – this was

corrected.

Questions?