EN 
DE Balancing act in embedded avionics software development
Author: Dr. Ludger Janauschek, Airbus Defence and Space GmbH
Contribution – Embedded Software Engineering Congress 2015
When developing software for embedded systems in aviation, a wide variety of standards must be considered. One of the best-known civil standards is DO-178C. The entire development process must comply with the specifications of these standards, which particularly includes tools and methods from the field of Software Development Engineering (SDE). Tools, hardware, and methods in the SDE field are constantly evolving. To achieve modern and efficient software development, it is essential to stay up-to-date. This often creates a conflict with maintaining certification, as certification typically relies on the use of proven and approved tools and methods, thus "freezing" the state of SDE. Project durations of more than 20 years further complicate this situation. This presentation will explore the reasons for this balancing act between staying current and remaining frozen, as well as methods—and in some cases, opportunities—for overcoming this challenge, while also highlighting the limitations.
The service life of aircraft types regularly exceeds 40 years. Some avionics systems remain operational in these aircraft types for their entire service life; most for at least 20 years. In addition to the service life, the planning and development phase must also be considered. This is when the decisions regarding the technology (target hardware, target software, host hardware, host software/tools) are made and finalized.
However, throughout its entire service life, avionics software in particular undergoes adjustments to meet evolving requirements. A functioning software environment engineer (SDE) is essential for this. To leverage technological advancements in software development, a modern SDE is highly desirable.
With such long lifecycles, obsolescence is a constant risk factor. Obsolescence affects both target hardware and host hardware and software. The core topic of this presentation is Software Development Environment (SDE), which is why the following discussion will focus on host aspects. SDE here encompasses: host hardware, host operating system with detailed patch level information, cross-compiler for target hardware including debugger, compiler for host simulation including debugger, IDE and/or editors, version control system, and test tools.
The framework for hardware, software, and tool selection is defined by aviation standards. In aviation, aircraft type certifications continue to be maintained according to the respective type certification standard; that is, for a 40-year-old aircraft type, the 40-year-old standard is relevant [1]. This generally applies to modifications. However, for major changes or new installations, current standards are regularly applied. This leads to a situation where, for an older aircraft type, many standards from different eras have accumulated for various components. An overview of standards is provided in the bibliography. It is not uncommon to have to consider standards from 1980 to the present day simultaneously.
This is a key reason for the long service life of avionics computers. Replacing them requires not only a new certification comparable in scope to that of the old device, but also one that adheres to the generally stricter current standards. The current standard for system development (an avionics computer is a system consisting of at least the "items" hardware and software) is ARP4754A, and for software development, the standard DO-178C; here, the framework for the software development process is defined by "objectives" and "activities." If development steps are automated by tools, the tool's output must be verified or the tool itself qualified. Tool qualification is separated from DO-178C [13] and described in the "technical supplement" DO-330 [14]. Analogous to the "software levels" A to E of avionics software according to DO-178C, DO-330 defines "tool qualification levels" TQL-1 to TQL-5, which are selected based on the tool criteria. The development process for tools is essentially the same as for avionics software according to DO-178C, adapted by DO-330.
The use of the tools and the operation of an SDE are regulated, for example, for a specific environment in LTR 7030 [5]. The associated guideline [6] addresses the topic of software obsolescence. According to this guideline, software obsolescence occurs due to technical obsolescence, changes in legal requirements, or economic decisions (e.g., discontinuation). The guideline states that software obsolescence occurs when necessary hardware and/or software no longer function or when necessary modifications (e.g., to fix errors, adapt to the operating environment, or further develop the tool) can no longer be carried out. In addition to hardware obsolescence, the following are cited as causes of software obsolescence: missing/incomplete documentation, lack of usage rights, and lack of personnel.
Regarding personnel, regulations are also found in the following standards: DO-178C [13], AQAP 2210 [8], EN9100 [2]. These essentially require that personnel be instructed or trained for their respective tasks and that this be documented.
In summary, the long-term operation of a SDE requires the maintenance of both hardware and software and the presence of trained personnel. Possible causes of obsolescence in these three areas are:
- HW: no spare parts delivery, no support, dependence on HW configuration state
- SW: Dependence on software configuration state (operating system, patches), hardware dependency, no support, dependency on a programming language
- Personnel: Turnover, retirement, training provider for specialized know-how, avionics software and operation of the special SDE disappears from the market
In most cases, dependency chains also exist, such as tool – operating system – hardware. This means that a frozen tool (e.g., after the support contract expires) can only run with an old operating system configuration (version, patch status), and this old operating system version in turn has limitations on the host hardware.
Possible solutions for obsolescence include:
- Virtualization, i.e., operating system images including tools are frozen and run on compatible host hardware (operating system virtualization) or with an intermediate layer on different host hardware (hardware virtualization).
- Warehousing, i.e., the necessary hardware condition is stored in sufficient quantity.
- Trained personnel through ensuring training/instruction – for example, for 20-year-old tools and methods – through an external training provider or by acquiring these skills in-house.
- Focus on minimal SDE
The availability of support from hardware and software manufacturers is usually severely limited or nonexistent because support contracts require a current patch level for the hardware, operating system, and application software. This is not possible with a frozen SDE (Software Development Environment). The resulting lack of support must regularly be covered by in-house expertise. This poses a significant risk.
The aforementioned solutions also have their drawbacks. Operating virtual images depends on the availability of modern hardware capable of running these older images. The associated storage requirements translate into high costs and significant space demands. Furthermore, hardware and storage media age over time. Therefore, it is advisable to prevent SDEs from becoming too outdated and instead to keep pace with current developments. This necessitates the requalification of tools according to DO-330 and the recertification of avionics software according to DO-178C.
When converting/modernizing methods and processes, e.g., Structured Analysis (SA/RT) to UML and object-oriented design, it should also be noted that this necessitates taking into account the „technical supplements“ DO-331 [15] and DO-332 [16] for model-based methods and object-oriented technology.
Summary
Avionics software development places some specific demands and challenges on the SDE (Software Development Equipment) and its long-term operation. Several solutions have been presented, but limitations have also been identified. The aim of this conference presentation is also to engage in dialogue with other stakeholders in this field in order to develop and find further solutions.
List of abbreviations
| AC | Advisory Circular |
| AQAP | Allied Quality Assurance Publications |
| ARP | Aerospace Recommended Practice |
| HW | Hardware |
| IDE | Integrated development environment |
| RTCA | Radio Technical Commission for Aeronautics |
| SA/RT | Structured Analysis with Real-Time Extensions |
| SDE | Software development environment |
| SW | software |
| UML | Unified Modeling Language |
Bibliography and list of sources
[1] AC 20-115C, Advisory Circular: Airborne Software Assurance, US Department of Transportation, Federal Aviation Administration, 2013
[2] DIN EN 9100:2009, Quality management systems – Requirements for aviation, space and defence organisations, Berlin, 2009
[3] Flühr H., Avionics and Air Traffic Control Technology: Introduction to Communication Technology, Navigation, Surveillance, Springer Vieweg Verlag, 2013
[4] Hinsch M., Industrial Aviation Management: Technology and Organization of Aviation Engineering Companies, Springer Vieweg Verlag, 2012
[5] LTR 7030-001, Aviation Suitability Guideline Software, Federal Office of Defense Technology and Procurement, Edition 3, Oct. 2001
[6] LTR 7030 Guideline, Guideline on the Aviation Suitability Directive Software, Federal Office of Defense Technology and Procurement, Version 2, Aug. 2005
[7] NATO AQAP 2110, NATO Quality Assurance Requirements for Design, Development and Production, 2009
[8] NATO AQAP 2210, NATO Supplementary Software Quality Assurance Requirements to AQAP 2110, 2006
[9] Rierson L., Developing Safety-Critical Software, CRC Press, Boca Raton, 2013
[10] RTCA DO-178, Software Considerations in Airborne Systems and Equipment Certification, Washington, DC, RTCA, Inc., 1982
[11] RTCA DO-178A, Software Considerations in Airborne Systems and Equipment Certification, Washington, DC, RTCA, Inc., 1985
[12] RTCA DO-178B, Software Considerations in Airborne Systems and Equipment Certification, Washington, DC, RTCA, Inc., 1992
[13] RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification, Washington, DC, RTCA, Inc., 2011
[14] RTCA DO-330, Software Tool Qualification Considerations, Washington, DC, RTCA, Inc., 2011
[15] RTCA DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A, Washington, DC, RTCA, Inc., 2011
[16] RTCA DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, Washington, DC, RTCA, Inc., 2011
[17] SAE ARP4754A, Guidelines for Development of Civil Aircraft and Systems, Warrendale, SAE Aerospace, 2010
Our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.
Training & coaching on the other topics in our portfolio can be found here. here.
Quality, Safety & Security – Expertise
Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
