Software for Safety-Critical Systems
Programming Languages
Software for Safety Critical Systems
Lecture 13 - 1 of 1
Your Notes
Notes It is recommended that a well-established language be used at all times in the development of Safety-Critical Software. Problems are discovered and eradicated as language usage and experience increases but this typically takes many years.
Software for Safety Critical Systems
Lecture 13 - 2 of 2
General Considerations
• Widely used languages or their subsets are preferred to special purpose languages as problems and limitations are more likely to be known.
• The language should be user or problem oriented rather than machine oriented.
• The language should be completely and unambiguously defined, and in this context a formal definition of the syntax and semantics of the language should exist.
• Aspects of languages which cause problems, and are often deemed unsafe, tend to relate to undefined features:- Ambiguity. - Language features comprehend.
that
are
unclear
or
difficult
to
- Features that give rise to different effects depending on the implementation or even the environment.
• The possibility of run-time errors is a major source of concern. The occurrence of these and the handling of them are related.
Software for Safety Critical Systems
Lecture 13 - 3 of 3
Your Notes
Notes High-level languages remain one of the most direct ways in which to constrain and structure the source code of software. Structuring software systems using a modular approach limits the complexity of the system, making construction, maintenance and understanding much easier.
Software for Safety Critical Systems
Lecture 13 - 4 of 4
Program Structure • Typical requirements are for:- Block structured language.
- Strongly typed.
- Good structuring mechanisms (eg. information hiding).
- Safe constructs - no surprises.
• The language should encourage:- The use of small and manageable modules.
- Restriction of access to data in defined modules.
- Definition of variable sub-ranges.
- Any other type of error limiting constructs.
Software for Safety Critical Systems
Lecture 13 - 5 of 5
Your Notes
Notes Compiler support will include such things as flagging uninitialised variables, dangerous use of pointers, improper use of variables (eg. by the cast function in C) and other anomaly detection.
Software for Safety Critical Systems
Lecture 13 - 6 of 6
Language Mechanisms
The language should provide for:-
• Mechanisms to support fault tolerance.
• Mechanisms (such as exceptions, range constraints) to overcome the need for defensive programming etc.
• Translation time checking.
• Run time type and array bound checking.
• Parameter checking.
• Assertions, if possible.
• Generally maximum amount of support from compilers.
Software for Safety Critical Systems
Lecture 13 - 7 of 7
Your Notes
Notes The correctness of any program within a Safety-Critical System should be verifiable and hence the program should be able to be shown to be safe. In the language C, for example, the unrestricted use of pointers means that only the simplest forms of access and assignment can be shown not to present the possibility of overwriting memory. Recursion and dynamic constructs such as pointers and heaps can cause the size of programs to vary considerably, and without verifiable bounds.
Software for Safety Critical Systems
Lecture 13 - 8 of 8
Verification Considerations
Features which make verification difficult should be avoided:-
• Unconditional and conditional jumps excluding subroutine calls (eg. GOTO).
• Recursion.
• Pointers, heaps or any type of dynamic variables or objects.
• Interrupt handling at source code level.
• Multiple entries of exits of loops, blocks or subprograms
• Implicit variable initialisation or declaration.
• Variant records and equivalence.
Software for Safety Critical Systems
Lecture 13 - 9 of 9
Your Notes
Notes Certain features of languages may be deemed unsafe, be difficult to analyse, be considered bad programming practice or involve complex structures which may result in implementation errors. SPADE (Southampton Program Analysis Development Environment) is an example of a development environment for enforcing a language subset. Tools are used to check that programs conform to a defined subset. SPADE was first applied to Pascal and later to Ada under the auspices of SPARK (SPADE Ada Kernel) which is discussed later.
References [Pyl91]
Pyle, I. C.: “Developing Safety Systems - A Guide Using Ada”, Prentice Hall, 1991
Software for Safety Critical Systems
Lecture 13 - 10 of 10
Language Subsets
• A language Subset is an implementation of a language with undesirable features removed. The intention is that safer programs will be produced.
• The subset is usually enforced by a coding standard which details the features to be avoided by programmers. Subsets should be chosen so that this is possible.
• A semantic checker can then be used to ensure adherence to, and proper use of, the subset.
• One way to guarantee Logical safety (and this is what SPADE and SPARK do) is to eliminate all input/output features from a language. Thus any program cannot affect or read from an external device.
• However, at the systems level of course, the software must control external devices in order to achieve Physical safety.
Software for Safety Critical Systems
Lecture 13 - 11 of 11
Your Notes
Notes SPARK is a ‘safe’ subset of the programming language Ada. It defines thirtyfive rules for the development of Ada programs. As well as the subset rules, SPARK mandates that Annotations are added to programs in order to formally document dependencies between modules and input-output relationships. Annotations can also be used to specify proof rules relating to a piece of code. Code written in SPARK is thus designed to be susceptible to formal analysis. Annotations are described in more detail in the lecture on Formal Verification.
References [CJ88]
Carré, B. A. and Jennings, T. J.: “SPARK - The SPADE Ada Kernel”, Department of Electronics and Computer Science, University of Southampton, 1988
Software for Safety Critical Systems
Lecture 13 - 12 of 12
Illustration of Subset SPARK: examples of features omitted from full Ada
• No renaming declarations.
• No USE clause in declarative part.
• No GOTO statement.
• No definition of operators.
• No access types.
• No default values of subprogram parameters.
• No automatic type conversion in subprogram parameters.
• No dynamic range (must be static).
Software for Safety Critical Systems
Lecture 13 - 13 of 13
Your Notes
Notes
Software for Safety Critical Systems
Lecture 13 - 14 of 14
Coding Standards (IEC 1508)
D.1 Design and Coding Standards Referenced by Clause 7.4 TECHNIQUE/MEASURE
Ref
SIL1
SIL2
SIL3
SIL4
1. Use of Coding Standard
B.16
HR
HR
HR
HR
2. No Dynamic Objects
B.16
R
HR
HR
HR
3. No Dynamic Variables
B.16
--
R
HR
HR
4. Limited Use of Interrupts
B.16
R
R
HR
HR
5. Limited Use of Pointers
B.16
--
R
HR
HR
6. Limited Use of Recursion
B.16
--
R
HR
HR
7. No Unconditional Jumps
B.16
R
HR
HR
HR
• Standards and rules to be used in development should be agreed by the project team at the outset of the project.
• Possibilities include stipulating development methods, module sizes, comment conventions, avoidance of certain language constructs and design principles.
• Such rules are intended to allow for ease of development, verification, assessment and maintenance.
Software for Safety Critical Systems
Lecture 13 - 15 of 15
Your Notes
Notes At the time of the study described here, a properly defined subset for Ada did not exist and the language was not widely used owing to its relative youth. The assessment of Ada with a subset is thus hypothetical. Several subsets have since been developed, SPARK being one example.
References [CGW91] Cullyer, W. J., Goodenough, S. J. and Wichmann, B. A.: “The Choice of Programming Languages for use in Safety-Critical Systems”, Software Engineering Journal, March 1991
Software for Safety Critical Systems
Lecture 13 - 16 of 16
Choice of Programming Language Provision for safety feature
ISO Pascal
SPADE Pascal
Protection against wild jumps
?
*
Protection against memory overwrites
?
*
Well-defined semantics
?
*
Rigorous model of maths
*
*
Checks for operational arithmetic
?
*
Strong data typing
?
*
Provision of exception handling
X
X
Safe subset
X
*
Prevention of exhaustion of memory
?
*
Provision for separate compilation
?
?
Language is well understood
*
*
Provision for safety feature
Ada
Ada subset
Protection against wild jumps
*
*
Protection against memory overwrites
?
*
Well-defined semantics
?
?
Rigorous model of maths
?
*
Checks for operational arithmetic
?
*
Strong data typing
*
*
Provision of exception handling
*
*
Safe subset
X
?
Prevention of exhaustion of memory
X
?
Provision for separate compilation
*
*
Language is well understood
?
*
X - The facility is not provided and this may result in equipment that is unsafe. ? - The language provides some protection, but there remains a risk of malfunction. * - Sound protection is provided, and good design and verification should minimise the risk of serious incident.
Software for Safety Critical Systems
Lecture 13 - 17 of 17
Your Notes
Notes Low level languages, in particular assembly languages, present problems due to their machine oriented nature. These may be used exceptionally and should always be used in a structured manner. Assembly language is often still employed in Safety-Critical Systems, particularly for time-critical parts of code. It is not clear yet as to whether object oriented languages are to be preferred to conventional ones. VISTA is a structured assembly language. It has a more rigourous basis than other structured assmbly languages.
Software for Safety Critical Systems
Lecture 13 - 18 of 18
Choice of Programming Language
Provision for safety feature
Structured Assembler
RSRE VISTA
Protection against wild jumps
*
*
Protection against memory overwrites
?
?
Well-defined semantics
?
?
Rigorous model of maths
?
*
Checks for operational arithmetic
?
*
Strong data typing
?
?
Provision of exception handling
X
?
Safe subset
?
*
Prevention of exhaustion of memory
*
*
Provision for separate compilation
X
X
Language is well understood
*
*
Provision for safety feature
C
Protection against wild jumps
?
Protection against memory overwrites
X
Well-defined semantics
X
Rigorous model of maths
X
Checks for operational arithmetic
X
Strong data typing
X
Provision of exception handling
?
Safe subset
X
Prevention of exhaustion of memory
?
Provision for separate compilation
X
Language is well understood
?
Software for Safety Critical Systems
Lecture 13 - 19 of 19
Your Notes
Notes
References [MoD91] Ministry of Defence: “INT DEF STAN 00-55: The Procurement of Safety Critical Software in Defence Equipment - Issue 1”, MoD, April 1991
Software for Safety Critical Systems
Lecture 13 - 20 of 20
INT DEF STAN 00-55 - Languages
Characteristics of source language used shall include:-
• A formally-defined syntax.
• A means of enforcing the use of any subset employed.
• A well understood semantics and a formal means of relating code to the formal design.
• Block structured.
• Strongly typed.
Software for Safety Critical Systems
Lecture 13 - 21 of 21
Your Notes
Notes
References [IEC95]
IEC/TC65: “Draft IEC1508: Functional Safety: Safety Related Systems”, IEC, 1995
Software for Safety Critical Systems
Lecture 13 - 22 of 22
Language Recommendations (IEC 1508) Clause 7.4.4: Design and Development - Development Tools and Programming Language TECHNIQUE/MEASURE
Ref
SIL1
SIL2
SIL3
SIL4
1a. Programming Language
D.5
HR
HR
HR
HR
1b. Strongly Typed Programming Language
B.57
HR
HR
HR
HR
1c. Language Subset
B.38
--
--
HR
HR
2a. Certificated Tools
B.7
R
HR
HR
HR
2b. Tools proven in use
B.65
HR
HR
HR
HR
3a. Certificated Translator
B.7
R
HR
HR
HR
3b. Translator proven in use
B.65
HR
HR
HR
HR
4. Library of Trusted/Verified Modules and Components
B.40
R
HR
HR
HR
• The selection of development tools will depend on the software development process and the software architecture.
• It is important to realise that the nature of any software used in the development of Safety-Critical software is itself highly critical.
• For example, faults in the compilation process can compromise the safety of an otherwise correct program.
Software for Safety Critical Systems
Lecture 13 - 23 of 23
Your Notes
Notes
Software for Safety Critical Systems
Lecture 13 - 24 of 24
Language Recommendations (IEC 1508) D.5 Programming Languages - Referenced by Clause 7.4 TECHNIQUE/MEASURE
Ref
SIL1
SIL2
SIL3
SIL4
1. Ada
B.62
HR
HR
R
R
2. Ada with subset
B.62
HR
HR
HR
HR
3. MODULA-2
B.62
HR
HR
R
R
4. MODULA-2 with subset
B.62
HR
HR
HR
HR
5. PASCAL
B.62
HR
HR
R
R
6. PASCAL with subset
B.62
HR
HR
HR
HR
7. FORTRAN 77
B.62
R
R
R
R
8. FORTRAN 77 with subset
B.62
HR
HR
HR
HR
9. “C”
B.62
R
--
NR
NR
10. “C” with subset and coding standard
B.62
HR
R
--
--
11. PL/M
B.62
R
R
NR
NR
12. PL/M with subset and coding standard
B.62
HR
R
R
R
13. Assembler
B.62
R
R
--
--
14. Assembler with subset and coding standard
B.62
R
R
R
R
15. Ladder Diagrams
B.62
R
R
R
R
16. Ladder Diagram with defined subset of language
B.62
HR
HR
HR
HR
17. Functional Blocks
B.62
R
R
R
R
18. Functional Block Diagram with defined subset of language
B.62
HR
HR
HR
HR
19. Structured Text
B.62
R
R
R
R
20. Structured Text with defined subset of language
B.62
HR
HR
HR
HR
21. Sequential Function Chart
B.62
R
R
R
R
22. Sequential Function Chart with defined subset of language
B.62
HR
HR
HR
HR
23. Statement List
B.62
R
--
NR
NR
24. Statement List with defined subset of language
B.62
HR
R
R
R
25. BASIC
B.62
--
NR
NR
NR
26. BASIC with subset
B.62
R
--
NR
NR
Software for Safety Critical Systems
Lecture 13 - 25 of 25
Your Notes
Notes CASE (Computer Aided Software Engineering) tools are designed to automate parts of the development process, supporting development and removing mundane and error-prone tasks usually carried out by software engineers. The real power of such tools is harnessed if they can communicate information in a compatible manner. An Integrated Project Support Environment (IPSE) consists of a number of software tools integrated to provide an automated environment in which development can take place. IPSEs may also perform such activities as automatic collection of metrics to improve process and product.
Software for Safety Critical Systems
Lecture 13 - 26 of 26
Programming Environments • There are various possibilities for tools to support the programming activity:- Editors and debuggers - Translators, loaders and compilers - Libraries of pre-existing modules - Simulators - Static analysis tools - Verification tools, etc.
• These should be integrated into an environment that provides support for all phases of the software lifecycle.
• Such integration will enable, for example, consistency checking between products of different phases.
• “Umbrella” activities that apply to the entire process, such as configuration management, must also be integrated.
Software for Safety Critical Systems
Lecture 13 - 27 of 27
Your Notes
Notes A certified tool is one which has been determined to be of a particular quality. The certification of a tool will generally be carried out by an independent, often national, body, against criteria typically specified in national or international standards.
Software for Safety Critical Systems
Lecture 13 - 28 of 28
Certification of Tools
• All tools used for the design, development and maintenance of safety related systems need to be certified, tested and generally quality approved in some sense.
• Various possibilities exist, usually related to certification:-
- Wide use, with error reporting.
- Extensive testing, perhaps related to the grammar but this syntax.
- Verification - this requires a formal specification of the language (its syntax and semantics) and of the underlying machine and then prove that one is a true implementation of the other.
• Of these, the latter is beyond the state of the art for current languages.
Software for Safety Critical Systems
Lecture 13 - 29 of 29
Your Notes
Notes Compiler Validation involves rigorous testing against a standard suite of tests designed to uncover numerous problems that can occur in compiler design, as well as more general functionality. However, some faults may remain.
Software for Safety Critical Systems
Lecture 13 - 30 of 30
INT DEF STAN 00-55 - Tools
Regarding tools and software support -
• All compilers shall be validated with an approved international or national validation certificate.
• All tools and software approved shall have sufficient safety integrity to ensure they do not jeopardise safety integrity of the safety critical system.
• Selection of these should consider costs, benefits, performance, maturity, usability, interoperability, and maintenance.
Software for Safety Critical Systems
Lecture 13 - 31 of 31
Exercises 1. From the programming languages with which you are familiar, identify dangerous programming constructs. eg. GOTO Statement Dynamic memory allocation Weak typing Recursion Global Variables
Software for Safety Critical Systems
Lecture 13 - 32 of 32
