Inspection of Safety-Critical Software Using Program- Function Tables

1
Inspection of Safety-Critical Software Using
Program-Function Tables

• Jeffrey Smith, Richard Bruno, Vince Fumo

2
Question Is there a more accurate photograph of
Dr. Parnas?
3
D.L. Parnas circa 1970.
4
Outline

• Three Approaches
• Darlington Nuclear Plant
• Software Inspection
• Examples
• Darlington Inspection
• Questions

5
Three Approaches

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

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

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

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

9
Complimentary?

• The common view is that designers must choose one
  of the approaches over the other two.
• The author believes the three are complementary.

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

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

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

13
This approach is not good enough for
safety-critical software.
14
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
  --gt information not directly related should go
  elsewhere.

15
Documents

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

16
More functional documentation

• Need precise notation for relations.
• Conventional notation is too complex.
• Multi-dimensional notation is the authors
  choice.
• Author feels tables have a practical advantage.

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

18
Example

• Mathematical relations.
• Conventional notation.

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

20
Example Code

• Consider this C code which solves the problem
  outlined on the previous slide
• int jboolean presentint BNfor (int k1
  kltN k) if (Bk x) present
  true j k

21
Binary Search Tree Example

• If x is a node in a binary tree and y is a node
  to the left of x then valuey lt valuex. If y
  is a node to the right of x then valuey gt
  valuex.
• 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.

22
Binary Search Tree

• Below is pseudocode to search for the maximum
  value in a binary search tree
• TREE MAX(x) while (rightx ! NULL) do
  x ? rightx return(x)

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

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

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

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

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

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

29
Questions?