Inspection of Safety-Critical Software Using Program- Function Tables Jeffrey Smith, Richard Bruno, Vince Fumo
Jan 21, 2016
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?