Inspection of Safety-Critical Software Using Program- Function Tables

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?

Inspection of Safety-Critical Software Using Program- Function Tables