3.1 Software is utilised extensively in modern aircraft to implement a range of functionality, some of which may be safety critical. Software that controls safety critical functions may introduce risks that must be evaluated and treated during the development program through a robust software management system that incorporates the disciplines of software safety and software assurance. The application of these software engineering principles and practices, as defined within contemporary standards, is required to establish and maintain the functional integrity and safe behaviour of software installed on aviation platforms.
3.2 The term aviation software defines software that is designed for installation within a part or appliance of an aeronautical product. The implementation of a robust and effective software management approach to Defence aviation software design is prescribed by the Authority. This chapter defines the airworthiness design requirements for robust applications of aviation software. It then identifies common approaches to the management of aviation software that meet the Authority’s prescribed design requirements. This chapter also includes some brief guidance on considerations for development assurance of Airborne Electronic Hardware (AEH). Due to its close relationship to software development assurance, the AEH guidance is temporarily included in the Additional Aviation Software Guidance below pending specific AEH content publication in this Manual.
3.3 This chapter presents the Authority prescribed airworthiness design requirements for aviation software.
3.4 The design of aviation software that performs safety critical functions requires the application of two key software engineering principles that support the production of safe software:
Software safety, which is integrated with system safety, where software hazards are identified, analysed and treated within the context of systems engineering principles.
Software assurance, which defines the engineering rigour applied commensurate to the criticality of the functions performed by the Software.
3.5 Authority prescribed software design requirements that support the achievement of this outcome are defined in the following paragraphs.
Software Safety – Identifying Software Related Hazards
3.6 A software specification error, design flaw, or the lack of initial safety requirements can contribute to or cause a system failure or erroneous operator behaviour. Software safety is used to address software’s contribution to aircraft hazards. It is an element of the aircraft’s system safety and software development program and cannot be undertaken independently of the total effort.
3.7 Design Requirement (Essential). Software safety must be applied as part of the system safety program to identify any derived requirements and determine the worst credible failure condition for aviation software.
3.8 The Defence aviation approach to system safety and associated Authority prescribed requirements are detailed in Section 2, Chapter 2 and involves the identification of system level hazards. Software safety identifies the software contribution to those hazards, the development of derived requirements to mitigate the hazards and identifies the commensurate software assurance level to adequately mitigate the hazards.
3.9 Software safety brings together elements of traditional system safety approaches in conjunction with approaches used to address the unique properties of software. A major distinction of software safety assessments against the aircraft level system safety aspects is the absence of likelihood (probabilities) for each consequence; i.e. while the consequences of software failures can be clearly identified, software risks cannot be characterised in terms of likelihood. Software failures will consistently occur given the same inputs or conditions. Instead, the worst credible failure conditions are assessed utilising methods such as Functional Hazard Assessment (FHA) and Hazard and Operability Study (HAZOP) to identify software related hazards, the consequences related to realisation of these hazards and potential mitigation actions. The worst credible failure condition of aviation software is dependent on how it influences functional hazards at the system level; i.e. software safety links the software architecture to hazards and their failure pathways through to the system level.
3.10 Software safety, when properly implemented, enables the proper identification and tracing of requirements, not only those applied from the system level, but also those requirements that are derived from design decisions. These derived requirements are used to incorporate design criteria and may be generic; e.g. performance and timing criteria or mandating the use of partitioning.
3.11 Since software safety is a subset of system safety, it must be an integral component of the formal system safety program discussed at Section 2, Chapter 2. The following documents present robust frameworks for identifying the relevant tasks, processes, activities, and guidance for inclusion in the system safety program:
IEEE-STD-1228-1994 Standard for Software Safety Plans
U.S. Department of Defense Joint Software Systems Safety Engineering Handbook, Version 1.0.
3.12 A Development Assurance Level (DAL), commensurate with the worst credible failure condition identified, is utilised to establish the required software assurance safety objectives. The assignment of DALs is equally applicable to complex electronic hardware (CEH) hazards. DALs are obtained through proper application of ARP 4754A Guidelines for Development of Civil Aircraft and Systems. The Authority is to be consulted on the use of other system or software safety standards as they may require tailoring to satisfy software safety objectives.
3.13 Software assurance is closely coupled to software safety. As previously discussed, the DAL for a given system is obtained through application of system safety and software safety. The assigned DAL determines the processes applied to establish confidence that system development has sufficient rigour to limit the likelihood of development errors that could impact aircraft safety.
3.14 Design Requirement (Essential). Aviation software must satisfy the prescribed objectives required for the Development Assurance Level commensurate with its worst credible failure condition.
3.15 Software assurance is an activity that includes a range of certification objectives (or certification activities) to be satisfied in all phases of the development. The applicability of these certification objectives is dependent on the DAL of the software, with higher assurance levels requiring an increased scope of certification objectives, thus providing a greater level of confidence in the software. The scope of certification objectives can cover the planning, requirements, development and verification phases of the program, as well as configuration management, quality assurance and certification liaison activities.
3.16 Software assurance is achieved through proper application of RTCA DO-178C Software Considerations in Airborne Systems and Equipment Certification. Specific CEH design/assurance considerations are described in EASA CM SWCEH-001 Development Assurance of Airborne Electronic Hardware and RTCA DO-254 Design Assurance Guidance for Airborne Electronic Hardware. While other Software Assurance standards exist, as discussed later, tailoring of those standards to the satisfaction of the Authority may be required to satisfy an appropriate level of software assurance.
3.17 Aviation software has a life cycle that must be managed during development and in-service. Effective software life cycle management is an inherent part of the software safety and software assurance approaches. Software assurance objectives exist for assessment of the lifecycle processes and products, the rigour of which is based on the system DALs.
3.18 Effective management of the software life cycle ensures that compliance with the aviation software design requirements is considered at the planning stage, throughout development, and in-service operation. Software life cycle considerations can include supportability, documentation, tools, intellectual property, personnel expertise, interface control, problem reporting and tracking systems, language selection, and hardware requirements. In managing the aviation software life cycle, the authority preferred approach is presented in ISO/IEC/IEEE 12207:2017(E) Systems and software engineering – Software life cycle processes.
3.19 Section 1 Chapter 3 describes the Authority approach to recognition of Airworthiness Codes, which represent prescribed airworthiness requirements from a recognised civil or military Airworthiness Authority. The Airworthiness Codes do not specify a single standard or method to manage the integrity of aviation software, but each describes and implies an ecosystem of activities that must be undertaken. This section describes common NAA and MAA applications of aviation software safety and assurance and how they meet the Authority’s design requirements.
3.20 NAAs such as the Federal Aviation Administration (FAA), the European Aviation Safety Agency (EASA) and the Civil Aviation Safety Authority (CASA) adopt the SAE ARP 4761 and 4754 standards for the application of system safety and software safety.
3.21 RTCA DO-178C Software Considerations in Airborne Systems and Equipment Certification, alternatively known as EUROCAE ED-12C, is recognised by these NAAs as acceptable means of compliance for aviation software assurance. This standard satisfies the associated NAA’s Airworthiness Requirements (generally Federal Aviation Regulation (FAR) or Certification Specification (CS) 2x.1301 and 2x.1309).
3.22 RTCA DO-178C is not intended to be implemented in isolation, and acceptability is based on integration with other requirements of the relevant Airworthiness Code. Consequently, civil authorities undertake software safety and software assurance within an ecosystem of design requirements, standards and associated guidance material. A visual example of the ecosystem defined by civil authorities, in this case for FAR 25, is provided in Annex A. Intelligent application of the ecosystem as utilised by the NAA/MAA will meet the airworthiness design requirements detailed in this chapter.
3.23 For legacy aircraft undergoing design changes related to software, the guidance material listed below provides the conditions for the continued use of older versions of the standard:
EASA AMC 20-115D – "Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178"
FAA AC 20-115D – "Airborne Software Development Assurance Using EUROCAE ED-12 and RTCA DO-178" and FAA AC 00-69 – "Best Practices for Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178()".
3.24 MIL-HDBK-516 Airworthiness Certification Criteria defines the US DoD aviation software requirements for military systems within Sections 14 and 15 and references various specifications, standards and handbooks as means of compliance. This provides the freedom to utilise military standards such as NATO AOP-52 and the Joint Software Systems Safety Engineering Handbook (JSSSEH) as well as the above civilian standards. This approach facilitates civilian-military interfaces such as the application of MIL-STD-882E for system safety and DO-178C for software assurance.
3.25 The UK MoD term for aviation software is ‘Safety Related Programmable Elements’ as detailed within DEF STAN 00-970 PART 13 Issue 13. The software safety and software assurance approach to ‘Safety Related Programmable Elements’ is further detailed within DEF STAN 00-55 Requirements for the Safety of Programmable Elements in Defence Systems, which is the source for software related airworthiness requirements. While DEF STAN 00-970 adopts the civilian standards as a means of compliance for both system safety and software assurance, it allows legacy platforms to retain compliance against DEF STAN 00-55 Issue 2. Note also that the underlying UK MoD system safety requirements do not fully align with Defence requirements, and can require considerable tailoring prior to application, as detailed in Section 2, Chapter 2.
3.26 The application of the preceding military approaches requires tailoring and prior agreement with the Authority. Software standards such as JSSSEH and DEF STAN 00-55 are largely guidance material and, without intelligent application, may result in incomplete objective evidence that can be used to demonstrate that appropriate software safety and software assurance has been achieved.
3.27 Development assurance of AEH requires similar considerations to aviation software. The assignment of a DAL is equally applicable to specific AEH hazards, hence a DAL, commensurate with the worst credible failure condition identified, is utilised to establish the required AEH development assurance safety objectives. Until further guidance can be provided within this Manual, designers are to refer to EUROCAE ED-80/RTCA DO-254 Design Assurance Guidance for Airborne Electronic Hardware as an acceptable means of compliance for development assurance of AEH. Additional guidance is available within EASA CM–SWCEH-001 Issue 01 Revision 02 Development Assurance of Airborne Electronic Hardware issued 08 January 2018 and FAA Order 8110.105A Simple and Complex Electronic Hardware Approval Guidance issued 05 April 2017.
3.28 Further guidance on implementing the aviation software requirements prescribed in this chapter and addressing AEH design assurance can be provided by the chapter sponsor.
A. Ecosystem of FAA/EASA activities for production of safe aviation software