Ada in Safety Critical Applications

A. Welz, LITEF GmbH, L6rracher Str. 18, 7800 Freiburg, FRG

1 INTRODUCTION
This paper reviews a LITEF internal study about the use of Ada in safety
critical real time avionic systems. The study is part of the development of
the Inertial Measurement Unit (IMU), a flight control subsystem of the
European Fighter Aircraft (EFA). The study's goal was to establish
programming rules and examinate support tools and methods for the
development of safe Ada programs for flight critical systems.

The study was divided into following parts:

1: Definition of safety related to Ada.
2: Derivation of Ada programming rules with the above definition and
adjustment with already existing rules.
3: Classification of the Ada programming rules found in 2.
4: Examination of appropriate Ada test programs with the above Ada
programming rules and confirmation of the rules.
5: Exa~nation of tools and methods for safe Ada.

2 MOTIVATION
For the EFA project the Ada language is mandatorily required for the
software implementation of all operational aircraft software. Currently
assembly language is used most for such systems and typical assertions
against the Ada language in safety critical applications are:
Ada is unsafe because the language is too complex.
Ada tasking is unsafe because Ada tasking is too complex.
Ada tasking is not deterministic and therefore unsafe.
In Ada there is an unsafe kind of "erroneous execution".
The Ada exception mechanism is unsafe.
The language Ada is extremely inefficient and Ada compilers have lots
of bugs.

Therefore the EFA Joint Team ordered a study (called "Safe Ada Study"
[1]) to investigate ways to apply Ada avoiding features of the language that
are considered to be potentially "unsafe".
 194

3 DEFINITION "ADA SAFETY~

A translation of the avionic term "safety" into the Ada terminology, in
accordance with the current implementation practice of safety critical
software, is ([1] Appendix A):
1: The program's memory requirements are known before runtime.
2: The program contains no action that has an unpredictable overhead in
execution time.
3: The program and all its components have a deterministic behavior for
every possible input of data. All branches in the program are explicit.
The program is verifiable so that no error can occur at run time - no
matter whether it is detectable or not.
4: The program is source level transparent. That means it is written in a
consistent and readable way. The program does not make use of
different features to express the same thing. All actions are visible.

4 ADA PROGRAMMING RULES

With the aid of the above-mentioned requirements, it is possible to extract
Ada programming rules by identification of all "safety contradictions" in the
ALRM. This method results in a lot of rules, which adapt the Ada
syntax/semantics to the safety requirements. For example the following EFA
rule 1:
Access types shall not be used.
results from the static memory requirement.

During the LITEF study it was found that some of the EFA rules can be
slightly modified without injuring any safety requirement. For example the
following EFA rule 8:
Actions shall not raise a predefined exception.
was changed to:
All possible exceptions shall be handled with defined effects on
the program execution.
This rule was modified, because it results in a very inefficient programming
style with explicit range testing. Also the Ada tasking and machine code
insertion restrictions where modified. The whole description of EFA rules
and LITEF changes is beyond the scope of this paper ([1] Appendix A,[2]).
 195

5 CLASSIFICATION ADA PROGRAMMING RULES

The resulting rules could be split into two classes:
(1) Rules which describe the sequential execution of the program
('sequence of statements' in the sense of Ada).
(2) Rules which describe the parallel execution of the program ('tasking'
in the sense of Ada).

6 TEST PROGRAMS
The second step in defining and verifying Ada programming rules uses
relevant parts of a typical Ada avionics program. The assembler output of
this program is examined for implicit contradictions to the safety
requirements which leads to a confirmation or to a modification of the
above rules. It is natural that this method is only applicable if a stable
version of the project Ada compiler has been defined.

A further improvement of this method is a more or less complete set of test

programs with all possible Ada language elements. This was the method
used in the LITEF study [2]. Only this method is able to find all possible
safety risks of a specific project Ada compiler. The method has also the
advantage that it delivers code-tables (Ada --> Assembler) which can be
used in a later verification process. With an optimizing Ada compiler,
however these tables should be handled with great care.

Another very useful outcome from analyzing these tables are rules for
efficient Ada programs. In the LITEF study, it was found that these rules
are, in part, the same as the safety rules (which is on the other hand a proof
that safety need not be contradictory to efficiency).

7 TOOLS AND METHODS FOR SAFE ADA

Critical for the real safety of the developed software is the strict supervision
of the adherence to the Ada programming rules. As mentioned above there
are two classes of rules for supervision:
- Sequential rules
- Parallel rules

It is clear that each of these classes of rules needs to be applied differently:

 196

7.1 Tools for Sequential Rules

This type of rules could be further subdivided into two groups:
(1.1) Rules which describe the static behavior of the program (like a
rule "All constraints shall be static").
(1.2) Rules which describe the dynamic behavior of the program (like
a rule "All program paths should be covered").

The first type of rule can easily be checked with a special Ada parser. This
had already been developed by LITEF for a related project.

Also on the commercial market there are some tools for such sequential
testing. For EFA the SPARK tool [4] has been selected. The disadvantage
of this tools is that it only supports a very small subset of Ada. This kind of
tool relies on formal test methods, which only works with a 'PASCAL' like
subset of Ada, and needs additional special Ada comments (so called
annotations) to help the tool in understanding the semantics of Ada.

The second type of rule needs dynamic testing, which means that the
program is tested during execution. There are two major problems with this
test method:
Test input pattern and/or test strategies for the program must be
generated.
- The program flow must be controlled by additional Ada control code
or with the aid of a special trigger state analyzer.

There are some tools on the market which perform these functions but all
tools are based on additional Ada control code which will destroy the real
time behavior of the original program [5].

For this reason, LITEF has developed special trigger state hardware which
can control an avionic target even during flight conditions. Studies for
special pre- and postprocessing tools are currently under development.

7.2 Tools for Parallel Rules

Rules of this type are very difficult to control. The general case is
investigated in the information studies ([6],[7],[8]).
 197

Nevertheless, for "simple" avionic applications purposes, there are already

sufficient methods to verify or control the above-mentioned rules. A typical
avionic application consists of different tasks which are controlled by a
scheduler mechanism. This scheduler can easily be implemented with the
aid of an Ada rendezvous [3]. For this special kind of Ada tasking system
the following methods where investigated:
A method which uses a equivalence representation of Ada rendezvous
and petri nets. This method has the advantage that a lot of commercial
tools for petri nets already exist and the only problem is the conversion
of Ada code to the appropriate net representation.
- A method which uses parallel-prolog which is a extension of prolog
with parallel communication. With this language the above-mentioned
scheduler mechanism can be verified without an extensive stochastic
simulation as needed with the petri nets.

8 CONCLUSION
The language Ada is no less safe than other languages. Because of its strong
typing, the predefined exception mechanism and the standardized tasking
features, it has an even greater advantage compared to other languages.
There are reasonable alternatives to restricting Ada to a 'PASCAL subset'
as required in the EFA Safe Ada Study. With some precise rules, Ada
fulfills all requirements of safety critical avionic applications. The adherence
to these safety rules can be controlled with appropriate tools and methods.

9 REFERENCED DOCUMENTS
[1] Flight Control System Safety Critical Software Study / EFJ-STY-EFA-
020-0005 / Issue 1 / 30 October 87
[2] Safe Ada & Compiler Study for EFA IMU / A. Welz / Internal
LITEF Report / Revision 1.00-04.
[3] Study LITEF Executive in Ada (LEA) / Phase 1-3 / A. Welz /
Internal LITEF Report / 16.2.89.
[4] SPARK - The SPADE Ada Kernel / Carre et al / July 1989 / HMSO
London / Second Edition
[5] LDRA TESTBED ADA / User Documentation & Technical Descrip-
tion / Liverpool Data Research Associates Ltd. / 1985
 198

[6] Verifying General Safety Properties of Ada Tasking Programs / Laura

K. Dillon / IEEE Transactions on Software Engineering / Vol 16. No.
1 / January 1990
[7] Critical Races in Ada Programs / Gerald M. Karam et al / IEEE
Transactions on Software Engineering / Vol. 15 No. 11 / November
1989
[8] Starvation and Critical Race Analyzer for Ada / Gerald M. Karam et
al / IEEE Transactions on Software Engineering / Vol. 16 No. 8 /
August 1990