High-Integrity Software System Development

The domain of high-integrity software development is too wide for a full treatment in this literature survey. We are particularly interested in the development of software systems for use in civil aerospace applications, as this is the area of the author’s expertise, and is the target domain for the systems used as a case study in this thesis. We therefore concentrate on the current and forthcoming regulatory requirements for the development and approval of software in civil avionics systems, and any associated literature in this domain.

2.4.1 DO-178B/ED-12B

Civil avionics is a typical example of a high-integrity regulated domain, in which software is developed to a set of industry guidelines and is subject to audit and approval by a regulatory authority or body (sometimes multiple authorities/bodies). Regulatory authorities are typically a governmental body who must approve products prior to their public use to ensure safety or security is not compromised. Prior to entry into service, civil avionics software is required to be approved by an airworthiness authority, a process more commonly known as “certification”. This approval process typically takes the form of a set of audits designed to demonstrate the software has been developed in accordance with the guidance of DO-178B/ED-12B “Software Considerations in Airborne Systems and Equipment Certification” [4].

DO-178B/ED-12B provides guidance for software development in airborne systems and takes the form of a set of software development process objectives. In this context, a process objective describes some facet or attribute of the software development for which demonstrable compliance evidence needs to be supplied to support the approval of the software. The guidance recognizes five development assurance levels (DAL levels A to E), Level A being the most stringent. The software requirements and design process objectives remain relatively constant across the development assurance levels; however, the

53 Trusted Product Lines – PhD Thesis S G Hutchesson

verification process objectives increase both in number and in the level of independence required as the development assurance levels become more stringent. An example of one of the software coding objectives is that “Source Code compiles with the Low Level Requirements” (Objective 1 Table A-5), an objective that needs to be demonstrated with independence for development assurance level A.

A number of the DO-178B/ED-12B objectives concern the use of tools within the software development process. Wherever a tool is used to automate part of the software development activity, and its output is not separately verified, then that tool requires

qualification. Tool qualification provides evidence that a tool is operating as

expected/required when used in support of DO-178B/ED-12B objectives. The requirements for tool qualification vary dependent upon whether the tool is a verification or development tool. Verification tools cannot introduce an error into the software product; they can only fail to detect an error. Therefore, the qualification requirements for verification tools are relatively straightforward, and take the form of a simple acceptance test of the tool against a set of operational requirements plus strict revision control. Development tools, however, produce output that forms part of the software product and therefore are capable of introducing an error into the product (for example automatic code generators producing source code). Development tools whose output is not separately verified are required to be developed to the same assurance level as the software product they are used to develop.

TABLE 1OBJECTIVES VS LEVELS IN DO-178B/ED-12B

Level Failure condition Objectives With Independence

A Catastrophic 66 25

B Hazardous 65 14

C Major 57 2

D Minor 28 2

E 0 0

This causes significant problems for organisations wishing to develop and/or use qualified development tools, particularly for Level A projects. As DO-178B/ED-12B provides objectives for the software development process to follow, it is almost impossible to retrospectively provide qualification evidence for an existing tool. In addition, the safety critical software development tools market is so small that it is hardly ever commercially viable to develop a tool compliant with DO-178B/ED-12B Level A objectives. Currently the only commercially available development tool that is qualifiable to DO-178B Level A is the SCADE “pictures-to-code” environment produced by Esterel [59]; this is discussed later in this chapter.

54 Trusted Product Lines – PhD Thesis S G Hutchesson

2.4.2 DO-178C/ED-12C

DO-178B/ED-12B has been used in the approval of civil aerospace systems since it was ratified in 1992 (A Frequently Asked Questions/Clarifications document DO-248/ED-94 was released in 2001). In 2005, RTCA and EUROCAE (the industry bodies that publish the guidance material) decided to instigate a working group to revise the guidance in light of emerging technologies increasingly being used in the development of aerospace systems and to which the guidance was not being consistently applied. SC(Special Committee)- 205/WG(Working Group)-71 was instigated with the terms of reference to produce a suite of guidance documents that included the following :

 DO-178C/ED-12C “Software Considerations in Airborne Systems and Equipment Certification” [60]

 DO-278A/ED-109A “Guidelines for Communications, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance” [61]

 DO-248C/ED-94C “Supporting Information for DO-178C and DO-278A” [62]

 Technology supplements covering the following : o DO-330/ED-215 Tool Qualification [63]

o DO-331/ED-218 Model-Based Development and Verification [64]

o DO-332/ED-217 Object-Oriented Technologies and Associated Techniques [65]

o DO-333/ED-216 Formal Methods [66]

The terms of reference for the updates of the core documents were not to undertake a radical revision, but to include the errata that had been identified over the years and to reduce the need for FAQs and discussion papers. A key requirement was to preserve the 66 objectives from the previous guidance; however, some so called “hidden objectives” in DO-178B/ED-12B were clarified and made visible in the annexe tables that define how the objectives vary by DAL. The purpose of the technology supplements was to provide an agreed interpretation of the guidance for the development and approval of systems employing the technologies identified. This could include the definition of additional or alternate objectives if appropriate.

TABLE 2OBJECTIVES VS LEVELS IN DO-178C/ED-12C

Level Failure condition Objectives With Independence

A Catastrophic 71 33

B Hazardous 69 21

C Major 62 8

D Minor 26 5

55 Trusted Product Lines – PhD Thesis S G Hutchesson

Figure 28 is taken from DO-333/ED-216, the Formal Methods supplement to DO-178C/ED- 12C [66] – it illustrates the required verification processes for Level A software and the relationship of these to the design data required for DO-178C/ED-12C compliance. It provides a very useful overview of the set of verification objectives that should be met when approving a system as part of an aircraft or engine certification programme.

FIGURE 28DO-178C/ED-12CLEVEL ASOFTWARE VERIFICATION PROCESSES [66]

The various verification objectives and methods (review, analysis, test) and their relationship to the development processes can be seen clearly in Figure 28. In the context of Trusted Product Lines, it must be borne in mind that this set of verification objectives needs to be satisfied for an instantiated product. We will take this as a framework against which to assess the effectiveness of the trusted product lines approach later in the thesis.

56 Trusted Product Lines – PhD Thesis S G Hutchesson