Transcript Software and Safety: A Software Engineer's Perspective

Practical Experiences of Safety-Critical Ada
Technologies
Roderick Chapman and Peter Amey
Praxis Critical Systems
Copyright © 2001 Praxis Critical Systems Limited

Programme
• Introduction
• What is High Integrity Software?
• Reliable Programming in Standard Languages
– Coffee
• Standards Overview
• DO178B and the Lockheed C130J
– Lunch
• Def Stan 00-55 and SHOLIS
• ITSEC, Common Criteria and Mondex
– Tea
• Compiler and Run-time Issues
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Programme
• Introduction
• What is High Integrity Software?
• Reliable Programming in Standard Languages
– Coffee
• Standards Overview
• DO178B and the Lockheed C130J
– Lunch
• Def Stan 00-55 and SHOLIS
• ITSEC, Common Criteria and Mondex
– Tea
• Compiler and Run-time Issues
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Safety-critical Software
• Safety is a system property
– A system is safe if it will:
• not endanger life
• not cause a major environmental problem
• etc.
• Where the system relies on the operation of
software to achieve safe behaviour the software
is safety-critical
• Not all software in safety-related systems is
safety-critical
Copyright © 2001 Praxis Critical Systems Limited

Why Have Safety-critical Software?
• Advantages of software
– Complexity
• Disadvantages of software
– Complexity!
Copyright © 2001 Praxis Critical Systems Limited

Programme
• Introduction
• What is High Integrity Software?
• Reliable Programming in Standard Languages
– Coffee
• Standards Overview
• DO178B and the Lockheed C130J
– Lunch
• Def Stan 00-55 and SHOLIS
• ITSEC, Common Criteria and Mondex
– Tea
• Compiler and Run-time Issues
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

High-integrity Software
• Code where reliability is more important
than
– Efficiency
– Cost
– Time to market
– Functionality
• Clearly safety-critical software should be highintegrity (but reverse is not always true)
Copyright © 2001 Praxis Critical Systems Limited

Examples of High-integrity (but not S-C)
• Security systems
• Systems where direct financial loss could be
large
• Avoidance of “down-time”
• Avoiding product recall or loss of customer
confidence
• Loss of costly one-off mission capability (e.g.
Mars lander)
Copyright © 2001 Praxis Critical Systems Limited

Copyright © 2001 Praxis Critical Systems Limited

Unique Characteristic of High-integrity Software
• The need to be able to show, before there is any
service experience, that a system will meet
requirements
– Qualitatively different problem from “normal” software
– Standards required may be very high
• 109 hours > 114,000 years
• Meeting this challenge is not the same as
certification
• Not enough just to be “more careful”
Copyright © 2001 Praxis Critical Systems Limited

Copyright © 2001 Praxis Critical Systems Limited

Some Definitions
• Verification is the process of determining that a
system (or component) meets its specification
• Validation is the process of determining that a
system is appropriate for its purpose
• Certification is persuading an external regulatory
body that a set of specific requirements have been
met or processes followed
Copyright © 2001 Praxis Critical Systems Limited

A Single-sentence Standard
The fitness for purpose of a
software program shall be
established by logical reasoning
Copyright © 2001 Praxis Critical Systems Limited

V&V Techniques
• Inspections and reviews
– e.g.
• Requirements reviews
• Code inspections
• Test
– e.g.
• Requirements-based
• White box
• Analysis
– e.g.
• Flow analysis
• Model checking
• Proof
Copyright © 2001 Praxis Critical Systems Limited

Inspection and Reviews
• Advantages
– Very flexible, we can review an entity for internal consistency,
compare different artefacts for equivalence etc.
– No special tools needed
– Can be done early
• Disadvantages
– Informal process; may spot errors but cannot guarantee absence
– What is feasible limited by:
• Semantic precision of artefact being inspected
• Semantic gap between artefacts being compared
Copyright © 2001 Praxis Critical Systems Limited

Advantages of Dynamic Testing
• Spans the entire development process
– Potentially able to identify:
• Requirements errors
• Specification errors
• Coding errors
• Compiler bugs
• Hardware problems
Copyright © 2001 Praxis Critical Systems Limited

Disadvantages of Dynamic Testing
• Theoretical limitations
– Exhaustive testing almost invariably impossible
– High levels of confidence require infeasible amounts of
testing
• Practical disadvantages
–
–
–
–
–
Can only take place towards the end of development
Can be hard to diagnose unexpected behaviour
Frequently a bottleneck (e.g. Shared use of test rig)
Very expensive
Significant source of project risk
Copyright © 2001 Praxis Critical Systems Limited

A Note on Theoretical Limitations of
Testing
• Ultra-high reliability region (<10-7 failures per hour)
• Bayesian mathematics clearly limits what we can
claim from testing alone
• Reliability growth models cannot provide necessary
assurance
• See:
– The infeasibility of quantifying the reliability of life-critical realtime software. Butler & Finelli. NASA Langley Research Center
– Validation of Ultrahigh Dependability for Software-based Systems.
Littlewood & Strigini. CACM Nov 1993
Copyright © 2001 Praxis Critical Systems Limited

Advantages and Disadvantages of Analysis
• Advantages
– Can be used early in the development process
– Can establish properties that cannot be demonstrated in any
other way. e.g.
• Proof of absence of run-time errors
• Freedom from timing deadlocks
• Disadvantages
– Can only compare artefacts (e.g. Code against specification)
– What can be achieved is limited by precision of descriptions
and notations used
Copyright © 2001 Praxis Critical Systems Limited

A Balanced Approach
• Showing “correctness” is harder than building
correct systems
• Use a variety of complementary verification
techniques
• Bug detection and correction is expensive so:
– Focus on bug prevention
– Use techniques that find bugs early
– Regard final testing as demonstration of correct behaviour
rather than method of finding bugs
Copyright © 2001 Praxis Critical Systems Limited

Resources
• Littlewood, Bev; and Strigini, Lorenzo: Validation of Ultrahigh
Dependability for Software-based Systems. CACM 36(11): 69-80
(1993)
• Butler, Ricky W.; And Finelli, George B.: The Infeasibility of
Quantifying the Reliability of Life-critical Real-time Software.
IEEE Transactions on Software Engineering, vol. 19, no. 1,
Jan. 1993, pp 3-12
• Littlewood, B: Limits to Evaluation of Software Dependability.
In Software Reliability and Metrics (Procedings of Seventh
Annual CSR Conference, Garmisch-Partenkirchen). N. Fenton
and B. Littlewood. Eds. Elsevier, London, pp. 81-110
Copyright © 2001 Praxis Critical Systems Limited

Programme
• Introduction
• What is High Integrity Software?
• Reliable Programming in Standard Languages
– Coffee
• Standards Overview
• DO178B and the Lockheed C130J
– Lunch
• Def Stan 00-55 and SHOLIS
• ITSEC, Common Criteria and Mondex
– Tea
• Compiler and Run-time Issues
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Languages Affect the Way We Think
• Less likely to think of abstractions in machine
code or assembler
• Think more in machine terms in C
• Unlikely to think in object-terms in FORTRAN or
in functional terms in Smalltalk
• For larger systems, language support for
abstraction and encapsulation is vital
Copyright © 2001 Praxis Critical Systems Limited

When to Get Formal?
• Object (machine) code is formal
– The execution machine provides operational semantics for it
• Typically we cannot reason about machine code
we can only observe its behaviour
• Reliance on dynamic testing loads the lifecycle
towards the back (expensive) end
• Early reasoning saves money and reduces risk
but is hampered by lack of formality of
programming languages
Copyright © 2001 Praxis Critical Systems Limited

Causes of Uncertainty
• Deficiencies in language definitions
– Semantics of C integer division
– Pascal named vs. Structural type equivalence
• Implementation freedoms
– Execution order
– Parameter passing mechanisms
Copyright © 2001 Praxis Critical Systems Limited

Consequences of Uncertainty
• Leads to either:
– Ambiguity; programs whose behaviour cannot be predicted
from the source code; or
– Insecurity; violations of language rules that cannot be
detected
Copyright © 2001 Praxis Critical Systems Limited

Example of an Ambiguity
y = f(x) + g(x);
Suppose function f modifies x as a side-effect of its operation.
In this case the meaning of the expression depends on whether
f or g is evaluated first.
A rule stating “functions are not permitted to have side
effects” simply turns the ambiguity into an insecurity
Copyright © 2001 Praxis Critical Systems Limited

A Simple C Ambiguity
i = v[i++];
Page 46 of the C++ Annotated Reference Manual states that
this leads to the value of i being undefined.
Incidentally, this is a violation of MISRA-C Rule 46
Copyright © 2001 Praxis Critical Systems Limited

A Tiny Ada Ambiguity
procedure Init2(X, Y : out integer)
is
begin
X := 1;
Y := 2;
end Init2;
What is the meaning of:
Init2(A, A);
Copyright © 2001 Praxis Critical Systems Limited
Incidentally, this call is
not legal SPARK

Resolution
• Ambiguities are resolved .... by compiler authors
• Insecurities are left for the user to discover
• Possible solutions
– Invent new languages without these problems
– Work with dialects associated with compilers
– Use logically coherent language subsets to overcome ambiguities
and insecurities
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-c
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Special-purpose Languages
• Inventing new languages is fun! e.g.
– Gypsy,
– Newspeak
• But very small user base leads to:
– Poor or non-existent tools
– Staff shortages
– Lack of training support
Copyright © 2001 Praxis Critical Systems Limited

The VIPER Analogy
• VIPER was a “formally verified” microprocessor
– Commercial failure
– Users preferred “defective” processors with wide support
• Abandoning the wider user-base is a high-risk
strategy
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Using Language Dialects
• Find out what your compiler does
• Document it
• Include it in:
– Coding standards
– Review checklists
Copyright © 2001 Praxis Critical Systems Limited

Problems With Dialects
• What is the compiler’s behaviour?
– Is it consistent?
– Does it change with new releases?
– Is it the same on host and target?
• Knowing when it matters—to know the dialect
meaning of Init(A, A); we must both:
– recognise that implementation dependent behaviour is
present; and
– know what the compiler’s behaviour is in this case
Copyright © 2001 Praxis Critical Systems Limited

Dialect Observations
• Having a working knowledge of the compiler is
always useful, but
• You cannot expect to avoid all anomalous
behaviour by this method
• The approach may be valuable in special cases.
e.g. small, specialized processors where one
company provides processor, compiler and
analysis tools
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Language Properties Required
• Simple
Produced by independent
specialists on behalf of
UK MoD.
• Application oriented
• Predictable
• Formally verifiable
• Sound supporting
tools
Copyright © 2001 Praxis Critical Systems Limited

• No currently standardised language
could be recommended without
reservation for the most critical
applications without subsetting”
Requirements for Programming Languages, Computer Standards
and Interfaces 1992 BAWichmann, National Physical Laboratory
Copyright © 2001 Praxis Critical Systems Limited

Safe Subsets
• Potentially give us the best of both worlds:
– Logical soundness and predictability
– Access to standard compilers, tools, training, staff
But
• Level of integrity achievable depends on
foundation language chosen
• Subsetting alone may not be enough for the
highest integrity levels
Copyright © 2001 Praxis Critical Systems Limited

Constructing a Safe Subset
• Selection of base language
• Removal of the most troublesome language
features
• Limitations on the way remaining features may
be used
• Introduction of annotations to provide extra
information
Copyright © 2001 Praxis Critical Systems Limited

The Subset Spectrum
• We can construct subsets that vary on 4 axes:
–
–
–
–
Precision (security and lack of ambiguity)
Expressive power
Depth of analysis possible
Efficiency of analysis process
• Trade-offs quite complex; we are trying to avoid
surprise: unexpected behaviour which we don’t
find until test
– Removing problematic features may reduce this risk
– Increased precision may require reduction in expressive
power but improves depth of analysis
– We may be able to combine expressiveness with depth of
analysis but at the cost of efficiency of analysis
Copyright © 2001 Praxis Critical Systems Limited

The Subset Spectrum (Contd.)
• Fundamental trade-off is between discipline we
accept to reduce bug insertion and the effort we
are prepared to make in bug detection
• For example:
– Unrestricted C provides little or protection from bug
insertion
– Ada requires extra discipline (e.g. strong typing) which
reduces bug insertion rate
• A qualitative shift in what is possible only
occurs when precision becomes exact
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

MISRA-c
• C subset defined by UK motor industry research
association (MIRA) and associated software
reliability association (MISRA)
(www.misra.org.uk)
• Comprises 127 “rules” presented in the form of
a coding standard
• The language designers regard it as suitable for
“SIL 3” systems; they recommend Ada or
Modula-2 if available
Copyright © 2001 Praxis Critical Systems Limited

Constructing a Safe Subset - MISRA-C
• Selection of base language
–
• Removal of the most troublesome language
features
–
• Limitations on the way remaining features may
be used
–
• Introduction of annotations to provide extra
information
–
Copyright © 2001 Praxis Critical Systems Limited

Constructing a Safe Subset - MISRA-C
• Selection of base language
– ISO/IEC 9899:1990 + technical corrigendum 1995
• Removal of the most troublesome language
features
– e.g. pointer arithmetic
• Limitations on the way remaining features may
be used
– e.g all switch statements should have final default
• Introduction of annotations to provide extra
information
– not provided
Copyright © 2001 Praxis Critical Systems Limited

Language Issues Revisited
• ...
• Possible solutions
– Invent new languages without these problems
– Work with dialects associated with compilers
– Use logically coherent language subsets to overcome ambiguities
and insecurities
Copyright © 2001 Praxis Critical Systems Limited

Language Issues Revisited
• ...
• Possible solutions
– Invent new languages without these problems
– Work with dialects associated with compilers
– Use logically coherent languages subsets to overcome ambiguities
and insecurities.
Rule 41: The implementation of integer division in the
chosen compiler should be determined, documented and
taken into account.
Copyright © 2001 Praxis Critical Systems Limited

MISRA-C Overview
• MISRA-C concentrates on the “remove most
troublesome language features” approach
• There is no attempt to make the subset logically
coherent and free from ambiguity and insecurity
• Machine checkability well short of 100%
– Some rules cannot be machine-checked at all
• Rule 4. Provision should be made for appropriate runtime checking
– Some rules are unclear
• Nevertheless, the rules should prevent many
common C errors
Copyright © 2001 Praxis Critical Systems Limited

Some Examples
• Taken from “A Software Fault Prevention
Approach in Coding and Root Cause Analysis”
by Weider D. Yu
• Obtained from analysis of several million lines
of code in the Lucent 5ESS switching system
• Nearly 50% of the errors found were this kind of
low-level coding error
Copyright © 2001 Praxis Critical Systems Limited

Operator Precedence
if (blkptr->rpthead.fltdesc &
HMFLTCLAS == HWMATEFLT)
This is be
Should
a violation
corrected
of to:
MISRA-C Rule 47
if ((blkptr->rpthead.fltdesc &
“No dependence should be placed on C’s operator
HMFLTCLAS)
== HWMATEFLT)
precedence
rules in expressions”
Copyright © 2001 Praxis Critical Systems Limited

For Loop Control
for (idx = 0; idx < 40;
dispstring[idx] = COTsuccess[idx++]);
This is be
Should
a violation
corrected
of to:
MISRA-C Rule 66
for (idx = 0; idx < 40; idx++) {
“Only expressions concerned with loop control should
dispstring[idx]
= COTsuccess[idx]
appear
within a for statement”
};
Copyright © 2001 Praxis Critical Systems Limited

Flow Control Statements
if (condition == TRUE)
flag = DBYES;
This is be
Should
a violation
corrected
of to:
MISRA-C Rule 59
if (condition == TRUE) {
“The statements forming the body of an if, else if, else,
flag
= DBYES;
while,
do…while
or for statement shall always be
enclosed
in braces”
};
Copyright © 2001 Praxis Critical Systems Limited

Flow Control Statements
if (condition == TRUE) {
flag = DBYES;
ASfunction();
};
Copyright © 2001 Praxis Critical Systems Limited

Logic Faults on Lucent 5ESS Project
• Use of uninitialized variables
• Misuse of break and continue
statements
• Operator precedence
• Loop boundaries
• Indexing outside arrays
• Truncation of values
• Misuse of pointers
• Incorrect AND and OR tests
• Assignment/equality
Copyright © 2001 Praxis Critical Systems Limited
• Bit fields not unsigned or enum
• Incorrect logical AND and mask
operators
• Preprocessor conditional errors
• Comment delimiters
• Unsigned variables and
comparisons
• Misuse of type casting

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

The Ada HRG
• ISO committee under WG9 to investigate highintegrity Ada issues:
– Interpretation and development of Annex H of the LRM
– Focus for developing Ada in the high-integrity field
• Members from:
–
–
–
–
Tool vendors
Users
Government (e.g. UK MoD)
Academia
Copyright © 2001 Praxis Critical Systems Limited

HRG Report
ISO/IEC JTC1/SC22/WG9
Programming Languages Guide for the Use of the Ada
Programming Language in High
Integrity Systems
• Does not define a subset but identifies the basis
on which a subset might be selected
Copyright © 2001 Praxis Critical Systems Limited

General Approach
• Identifies verification techniques
• Compares each technique with Ada language
features
– Included - the feature and technique are fully compatible
– Excluded - use of the feature prevents cost-effective use of
the technique
– Allowed
• Use of the feature makes the technique difficult
• The difficulty can be circumvented
• Tables have explanatory notes for excluded and
allowed items
Copyright © 2001 Praxis Critical Systems Limited

Techniques (Methods) and Groups
Type of Method
Group Name
Flow Analysis (FA)
Symbolic Analysis (SA)
Analysis
Range Checking (RC)
Stack Usage (SU)
Timing Analysis (TA)
Other Memory Usage (OMU)
Object Code Analysis (OCA)
Requirements-based Testing (RT)
Testing
Structure-based Testing (ST)
Copyright © 2001 Praxis Critical Systems Limited
Method Name
Control Flow
Data Flow
Information Flow
Symbolic Execution
Formal Code Verification
Range Checking
Stack Usage
Timing
Other Memory Usage
Object Code Analysis
Equivalence Class
Boundary Value
Modified Condition/Decision Coverage
Branch Coverage
Statement Coverage

Example Table: Subprograms
Feature
Procedures10
Functions10
Default
Expression
Indefinite
Formal
Parameters
Indefinite
Return types
Inline
Expansion
Return in
Procedures
Aliasing
Access
Parameters
FA
Inc
Inc
Inc
SA
Inc
Inc1
Alld2
RC
Inc
Inc
Inc
SU
Inc
Inc
Inc
TA
Inc
Inc
Inc
OMU
Inc
Inc
Inc
OCA
Inc
Inc
Alld2
RT
Inc
Inc
Inc
ST
Inc
Inc
Inc
Inc
Inc
Inc
Alld3
Alld3
Alld3
Inc
Inc
Inc
Inc
Inc
Inc
Exc4
Exc4
Exc4
Inc
Inc
Inc
Inc
Inc
Inc
Inc
Inc
Inc
Alld5
Inc
Alld5
Alld6
Alld6
Inc
Inc
Inc
Inc
Alld6
Inc
Inc
Exc7
Exc8
Exc7
Exc8
Inc
Inc
Inc
Exc9
Inc
Inc
Inc
Exc9
Inc
Inc
Inc
Inc
Alld7
Inc
Copyright © 2001 Praxis Critical Systems Limited

Points of Interest
• Exceptions
– HRG clearly had to reconcile two views of exceptions:
• They are an essential aspect of the language for highintegrity applications
• They must be avoided because of the difficulties they
cause for flow and symbolic analysis
– Propagation is clearly a key issue
• Tasking
– HRG report defines the “Ravenscar Profile”
– (More on this later)
Copyright © 2001 Praxis Critical Systems Limited

Exclusions Summary
Feature
Discriminated records
Class-wide operations
Aliased objects : complex
Renaming: complex/dynamic
Goto
Complex return types
Access parameters
Unchecked access
Streams
Full access types
Controlled types
Indefinite objects
Non-Ravenscar tasking
Remote-call interface
Partition communications
FA
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Alld
Exc
Exc
Exc
Copyright © 2001 Praxis Critical Systems Limited
SA
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Alld
Exc
Exc
Exc
RC
SU
TA
OMU
Exc
Alld
Exc
Exc
Exc
Exc
Alld
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Alld
Exc
Exc
Exc
Exc
Exc
Exc
OCA
Alld
Alld
Exc
Exc
RT
ST
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Alld
Exc
Alld
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc
Exc

General Language Issues
• There are four justifiable reasons for restricting
the use of language features:
–
–
–
–
To avoid features that are unpredictable
To avoid features that cannot be modelled
To avoid features that cannot be tested
To avoid features that make verification ineffective
• Any set of restrictions on Ada creates another
“Ada-like” language - that language should be
coherent and consistent
Copyright © 2001 Praxis Critical Systems Limited

Using the Guide
• “Determine the verification techniques required
from ... standards or guidelines”
• “Identify and understand the objectives to be
satisfied by each of the ... techniques”
• “Using the tables in section 5, determine the
actual rating of the language features”
• “Confirm that the choice of subset ... can satisfy
the requirements. This step should take into
account available tools”
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

What Is SPARK?
• A sub-language of Ada with particular properties
that make it ideally suited to the most critical of
applications:
–
–
–
–
–
Completely unambiguous
Free from implementation dependencies
All rule violations are detectable
Formally defined
Tool supported
• SPARK subsets of both Ada 83 and Ada 95 are
defined
• Language definition is open and widely available
Copyright © 2001 Praxis Critical Systems Limited

SPARK Design Considerations
•
•
•
•
•
•
•
•
•
Logical soundness
Simplicity of formal language definition
Expressive power
Security
Verifiability
Bounded space and time requirements
Correspondence with ... Ada?
Verifiability of compiled code
Minimal run-time system requirements
Copyright © 2001 Praxis Critical Systems Limited

Constructing a Safe Subset - SPARK
• Selection of base language
–
• Removal of the most troublesome language
features
–
• Limitations on the way remaining features may
be used
–
• Introduction of annotations to provide extra
information
–
Copyright © 2001 Praxis Critical Systems Limited

Constructing a Safe Subset - SPARK
• Selection of base language
– ANSI/MIL-STD-1815A-1983 & ISO-8652:1995
• Removal of the most troublesome language
features
– e.g. tasking
• Limitations on the way remaining features may
be used
– e.g. limitations on placement of exit and return
• Introduction of annotations to provide extra
information
– core (e.g. Global) and proof (e.g. Post) annotations
Copyright © 2001 Praxis Critical Systems Limited

Core Annotations
• Global definitions declaring use of global variables by
subprograms
• Dependency relations of procedures, specifying
information flow between their imports and exports
• Inherit clauses to restrict penetration of packages
• Own variable clauses to control access to package
variables, and to define refinement
• Initialisation specifications to indicate initialisations by
packages of their “own” variables
These annotations are related to executable code by staticsemantic rules, which are checked mechanically
Copyright © 2001 Praxis Critical Systems Limited

Static Analysis - the SPARK Examiner
• Language subset compliance
• System-wide data flow analysis
• Information flow analysis
}
“free”
• Demonstration, prior to execution, that a
program is “exception free”
• Formal verification including proof of safety
properties
Copyright © 2001 Praxis Critical Systems Limited

SPARK
• Amplifies the strengths of Ada
• Gives program source text a precise meaning
• Guarantees freedom from certain classes of error
• Simplifies early detection of other errors
• Captures important design information in the code
• Is compatible with HRG guidance and compiler-
defined high-integrity subsets
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Other Ada Subsets
• Tend to fall into two groups:
– Informal coding standards involving fairly arbitrary
exclusion language features
• Systeam “Safe Ada”
– Subsets generated by compiler back-end and run-time
library considerations
• GNORT
more on these later
• C-Smart
• Raven
• Can be evaluated against HRG criteria
• Tool support for first group is important issue
Copyright © 2001 Praxis Critical Systems Limited

Outline
•
•
•
•
Language issues
Special purpose languages
Dialects
Subsets
–
–
–
–
MISRA-C
Ada HRG report
SPARK
Other Ada subsets
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited

Conclusions
• Language subsets are useful ways of helping
reduce risk and cost
• Ada subsets are the best defined and best
supported
• There is a variety of subsets each with a distinct
mix of: precision, expressive power, depth of
analysis possible, efficiency of analysis
• A qualitative shift in what is possible requires a
subset 100% precise semantics
• Tool support is vital
Copyright © 2001 Praxis Critical Systems Limited

“… one could communicate with these machines in any
language provided it was an exact language …”
“… the system should resemble normal mathematical
procedure closely, but at the same time should be as
unambiguous as possible.”
Alan Turing, 1948
Copyright © 2001 Praxis Critical Systems Limited

Tool Issues
• Without tools all rules are insecurities
• Tool capability depends on the precision of the
language chosen
– Simple lexical and syntactic checking
– Heuristic approaches
– Precision (only possible with “exact” subsets)
• Inability to check rules leads to insecurity; but,
excessive false alarm rates can overwhelm with
detail
Copyright © 2001 Praxis Critical Systems Limited

Resources
•
•
•
•
•
•
•
•
•
Cook, David. Evolution of Programming Languages and Why a Language Is Not Enough to
Solve Our Problems. Crosstalk Dec 99. pp 7-12
Carré, Bernard: Reliable Programming in Standard Languages. In High-integrity Software.
RSRE Malvern, Chris Sennett (ed). ISBN 0-273-03158-9, 1989
Finnie, Gavin et al: SPARK - The SPADE Ada Kernel. Edition 3.3, 1997, Praxis Critical
Systems
Finnie, Gavin et al: SPARK 95 - The SPADE Ada 95 kernel. 1999, Praxis Critical Systems
Barnes, John: High Integrity Ada - the SPARK Approach. Addison Wesley Longman, ISBN
0-201-17517-7
I.F. Currie: Newspeak - a Reliable Programming Language. In high-Integrity Software.
RSRE Malvern, Chris Sennett (ed). ISBN 0-273-03158-9, 1989
Motor Industry Research Association: Guidance for the Use of the C Language in Vehicle
Based Software. April 1998. www.misra.org.uk
Yu, Weider D: A Software Fault Prevention Approach in Coding and Root Cause Analysis.
Bell Labs Technical Journal April-Jun 1998
ISO/IEC JTC1/SC22/WG9. Programming Languages - Guide for the Use of the Ada
Programming Language in High Integrity Systems.
www.dkuug.dk/jtc1/sc22/wg9/n359.pdf
Copyright © 2001 Praxis Critical Systems Limited

Programme
• Introduction
• What is High Integrity Software?
• Reliable Programming in Standard Languages
– Coffee
• Standards Overview
• DO178B and the Lockheed C130J
– Lunch
• Def Stan 00-55 and SHOLIS
• ITSEC, Common Criteria and Mondex
– Tea
• Compiler and Run-time Issues
• Conclusions
Copyright © 2001 Praxis Critical Systems Limited
