International Defense Security & Technology Your trusted Source for News, Research and Analysis
Related Articles
Contemporary aircraft, both civilian and military, are equipped with various radio–electronic onboard devices, which support a pilot in executing complex air missions. The rapid development of digital electronics and IT, increasingly distinct over the recent years, requires a pilot of a modern aircraft to have the in-flight support of onboard equipment, which, in fact, are already “smart” computers with sophisticated and comprehensive avionics software. Such computerization of a modern aircraft should ensure its required operating reliability and the safety of both the crew and the passengers.
The process of producing digital onboard devices and systems enables their reliable operation under all flight conditions that are critical to them, among others, due to changes in the pressure and temperature of ambient air and the occurrence of linear overloads, e.g., during a maneuvering flight. It is quite easy to imagine the consequences of, e.g., ILS landing-system software failure during an aircraft’s approach to an airport in difficult weather conditions or damage to a helmet-mounted weaponry control system when indicating a target, selecting weapon type, or using it in the course of a combat flight.
There are a lot of aviation-specific aspects to the avionics software development process. The majority of these fall into two main categories; functional and certification. Functionally, it has to perform its intended function reliably and safely. To do that it has to be developed to a Design Assurance Level (DAL) commensurate with the criticality of the software function. Process standards exist that all companies follow when creating their internal processes.
Safety-Critical Software
Safety-critical systems are systems where a failure could lead to loss of life or significant damage to property or the environment. The main feature of this type of system is security, more than any other feature that may be usual in other types of software such as speed, usability, etc.
The development of this type of software is complex as it’s necessary to take into account all possible failures that could occur and take steps to avoid them, which in complex systems, with a multitude of variables, sensors and actuators, is an arduous task.
For example, if we use the SIL (Safety Integrity Level, widely used in the railway industry), the probability of a dangerous failure at SIL level 4 (the most demanding) must be less than 10-8 per hour of continuous operation, which means less than one failure per 11,400 years.
It is necessary to develop the product very thoroughly from the outset in order to minimize the costs associated with changes and modifications. Failure to get through certification processes entails delays and cost overruns, which in many cases are unaffordable. It’s therefore preferable to succeed in the first instance, but this means investing in resources.
In high assurance avionics systems, such as systems for flight guidance, air traffic control, and
collision avoidance, compelling evidence is required that the system behavior satisfies certain
critical properties. Some critical properties are functional properties, properties of the services that the system delivers. For example, when another aircraft flies too close, a collision-avoidance system must advise the pilot to move the aircraft up or down to avoid a collision.
Besides functional properties, four other classes of critical system properties may be identified: security, safety, real-time, and fault-tolerance. In most cases, an avionics system must satisfy properties in more than a single class. For example, a collision-avoidance system must satisfy not only functional properties, but real-time constraints, fault-tolerance properties, and safety properties.
For safety critical systems, of any kind, not just software, it is required that risk analysis is done and the system must be designed and implemented so that qualified estimate of mean time between critical failures (= failures that result in an accident) is lower than some value. For systems that can kill multiple people the requirement is usually 10⁹ hours.
That estimate involves all kinds of failures, both software and hardware, and across all parts of the system. The components (both software and hardware) are tested to get some basic reliability for them, and then checks and backups have to be provided so that any particular type of fault, which is almost always more likely than once per 10⁹ hours, won’t result in an accident, and the combined probability of enough faults to cause one at once is below the desired threshold.
Now for software that means that it has to be comprehensively tested, which is fine. But it is also required that the tools involved in building it are “validated”. The stated purpose is that you know what is the risk of fault in the tool creating an undetected fault in the product, which is needed for the overall risk analysis.
And then there’s the fact that the average life of an aircraft is 20 years or more and it requires ongoing support. One of the biggest challenges is dealing with hardware obsolescence. The lifecycle of many processors is a few years at best.
The last 5 years or so, the major challenge to avionics software has been to reduce cost. Not just the cost of development, but the cost of integration and the cost of changing the software in the future. When the manufacturer askes for a new feature and you add it to the software, you have to flow through that process all over again. That can get expensive real quick. To reduce cost it takes a well designed software architecture that allows for modular design and testing capabilities at the module boundaries to limit the impact of change.
In order to satisfy the stringent reliability-related requirements within the process of developing electronic air equipment and their dedicated avionics software, specialists have drawn up relevant standards, such as standard DO-178C, containing software requirements, and standard DO-254, containing hardware requirements, supported by additional standardizing documents, including ARP 4761 and ARP 4754A
Software Planning
Software planning involves processes associated with planning and standards, after which software development will follow. At this stage, standard DO-178C defines five major plans and three software standards. It also distinguishes other documents that are required for the certification of any developed software.
The major avionics software plans are as follows:
Plan for Software Aspects of Certification (PSAC): a kind of “contract” between the contractor and the certification body.
Software Development Plan (SDP): contains the requirements concerning software planning, coding, and integration stages. The SDP was written for software developers and is, a kind of a guide on how to develop the software in order for it to satisfy the adopted requirements.
Software Verification Plan (SVP): contains aspects associated with verifying software functionality and is intended for software testers. The SVP is associated with the SDP because the assumptions that were thought out at the software development stage are verified at this stage.
Software Configuration Management Plan (SCMP): defines procedures, tools, and methods aimed at achieving the objectives associated with managing the requirements throughout the entire software lifecycle. It covers the procedures in terms of defining the baseline version and identifying software versions, reporting issues, controlling and reviewing modifications, archiving, controlling software loading and recovery.
Software Quality Assurance Plan (SQAP): defines the procedures and methods to be applied in order to satisfy the quality requirements associated with standard DO-178C. It determines the procedures in terms of quality management, audit execution, actions associated with issue reporting, and corrective action methodology.
The major software development standards are as follows:
-
Software Requirements Standards (SRS), which define principles, methods, and tools to be applied for developing high-level requirements. They include methods used for software development, notations for requirement implementation (algorithms, flow diagrams), and project tool limitations, which will be used for software development, as well as criteria related to the requirements.
-
Software Design Standards (SDSs): They define methods, tools, and limitations within the software design process. They include low-level requirements and software architecture. They are intended for a software development team and explain how to implement a design effectively. They cover, among other things, nomenclature methods, design tool limitations, and software complexity (e.g., procedure length).
-
Software Coding Standards (SCSs); They define methods, tools, and limitations within the software coding process. They include, among other things, coding standards, programming languages used, code presentation standards, nomenclature standards, compilator limitations, and restrictions arising from programming standards.
Avionics Software Development Process
-
The software requirement process, which leads to the development of high-level requirements (HLRs);
-
The software design process, which develops low-level requirements (LLRs) and software architecture based on HLRs;
-
The coding process, which leads to the creation of a source code and a nonintegrated object code;
-
The software integration process, which involves consolidating the software into the form of executable programs and its integration with external devices
Software development processes determine one or many system requirement levels. High-level requirements are determined based directly on system architecture and system requirements. They are developed within the software design process, thus creating inter-related low-level requirements. However, when a source code is generated based directly on high-level requirements, it also corresponds to low-level requirements and is subject to recommendations on low-level requirements. Software requirement processes utilize software lifecycle process outputs to create high-level requirements. The basic result of this process is software requirement data.
Software requirement data define high-level requirements, including the requirements provided by the ordering party. The data should include a description of the software system requirement allocation, taking into account the safety requirements and potential error conditions, functional and operational requirements for each operating mode, performance criteria (e.g., precision and accuracy), time-related requirements and limitations, memory size limitations, hardware and software interfaces (e.g., protocols, formats, input/output frequency), error detection, safety monitoring, as well as the requirements of software partitioning (how separated software components cooperate) and software levels for each component.
The input into the avionics software design process includes software requirements, a software development plan, and software design standards. If the planned transition criteria are met, the high-level requirements are used within the manufacturing process for creating software architecture and low-level requirements. They may include one or more requirement levels.
The basic output in these processes is the design description, which contains software architecture and low-level requirements. The data should include a detailed description of how the software satisfies high-level requirements, including algorithms and data structure, and how the software requirements correspond to the processes and tasks. It should also provide the software architecture description defining software structure, with implemented requirements, input/output descriptions (e.g., data dictionary, data and control flow within the design), resource limitations, a management strategy for resources and their limitations, and margins as well as methods for measuring these margins (e.g., time and memory, sequencing procedures).
The description should include intraprocessors and intratask communication mechanisms, including fixed interruption time sequences, design methods, and details on their implementation (e.g., software loading). An important element of the description is user-modified software, partitioning methods, and measures to prevent partition breach as well a description of software components (regardless of whether they are new or previously manufactured) and a reference to the baseline version from which they were downloaded. This description should also include derivative requirements arising from the software design process. If a system contains an inactive code, a description of security measures for the activation of the code on the target computer and a justification of design decisions are directly included in the system requirements associated with its security.
The software design process is complete when its objectives and the goals of the associated integration processes are achieved. Within the software coding process, the source code is implemented based on software architecture and low-level requirements. Coding process inputs are low-level requirements and software architecture from the software design processes, the software development plan, and software coding standards. The software coding process can be commenced when planned transition criteria are met. The source code is developed in the course of this process and is based on system architecture and low-level requirements. The target computer and the source code from software coding processes are used in order to compile, combine, and load data within the integration process; this is aimed at integrating an avionics system or its equipment constituents.
Avionics Software Integration Process
-
Communication within software certification;
-
Requirement management within software certification;
-
Verification within software certification;
-
Quality assessment within software certification.
Software Architecture
Design in DO-178C is the combination of architecture and low-level requirements. As you’re designing the architecture of your software, it’s important to define low-level requirements in order to form a system capable of meeting the high-level requirements you’ve already set.
Software architecture defines the components that software will have, including the functionality that each component will achieve, and the relationships between components, specifically data flows and control flows. Your architectural decisions can have a significant impact on your project life cycle, not only for implementation but also for verification, particularly considering data coupling and control coupling. Decisions you make in your software architecture will impact the verification effort needed for DO-178C compliance.
One way in which your design decisions impact verification is in the data coupling and control coupling of the interfaces that you plan to include in your implementation. To comply with DO-178C guidance at DALs C and above, you need to verify that you have exercised the data coupling and control coupling interfaces in the implementation, and your design decisions will affect the ease of this verification.
A couple things to consider e this analysis easier, you may want to:
Limit the number of data and control couples in your design.
Clearly define how each of the data and control couples in your design should operate, including specifying mode information.
Process for Specifying Requirements: the four-step process
As described by R. Bharadwaj and C. Heitmeyer of NRL
The first step creates the System Requirements Specification (SRS), which describes the required external behavior of the system in terms of monitored and controlled quantities in the system environment.
The behavior is described by the SRS as the “ideal” system behavior because it omits any mention of I/O devices and hardware failures. The environmental quantities relevant to the system are identified, and each quantity is represented by a mathematical variable. These
quantities consist of both controlled quantities, environmental quantities that the system controls, and monitored quantities, environmental quantities that can influence system behavior.
The desired system behavior is documented in the SRS by describing two relations, NAT and
REQ, on the monitored and controlled quantities. The relation NAT describes the constraints imposed on the environmental quantities by physical laws and the system environment. REQ
describes the relation between the monitored and controlled quantities that the system must enforce to produce the required behavior.
In developing the SRS, we initially specify REQ in terms of the ideal behavior of the system; that is, we assume that the system can obtain perfect values of the monitored quantities and compute perfect values of the controlled quantities. Later, for each controlled variable, we specify timing constraints (and possibly tolerances).
The remaining steps refine and extend the SRS.
Step 2 creates the System Design Specification (SDS), which identifies the system’s input and output devices (e.g., sensors and actuators).
The SDS identifies and documents the characteristics of the resources that are available to
estimate values of the monitored quantities and to set values of the controlled quantities. These values are usually read from or written to hardware devices, such as sensors and actuators. The values in the system’s hardware/software interfaces are denoted by variables. These variables are
partitioned into input variables, values read by input devices, and output variables, values are written to output devices. The product of this step is a description of the input and output devices and of the relationship between the input and output variables and the monitored and controlled
variables.
Step 3 creates the Software Requirements Specification (SoRS), which refines the SRS by adding modules which use values read from input devices to calculate values of the monitored quantities and which use the computed values of controlled quantities to drive output devices.
The SRS and the SDS are the foundation for the SoRS, which describes how the input variables
are to be used to estimate values of the monitored variables, and how estimates of the controlled
variables are to be used to control the output devices using the output variables. The SoRS is decomposed into three modules: two device-dependent modules called the input device interface module and the output device interface module, and a single device-independent module called the function driver module.
The required behavior of the function driver module is already defined by the REQ relation,
specified as part of the SRS during Step 1 of our process. What remains is to document the required behavior of the device-dependent modules, i.e., D_IN and D_OUT. To satisfy the information hiding principle, the input device interface module only uses values of input variables to estimate values of the monitored variables, and the output device interface module only uses values of controlled variables to compute the values of the output variables. The benefit of this approach is that it makes the specification easy to change. For example, to replace an input or output device with a new device or to modify or add a system function, usually only a small part of a single module will change.
Step 4 extends the SRS by adding behavior that reports hardware malfunctions, e.g., sensor failures.
In practical systems, hardware devices, such as sensors, will fail, and the system will need to provide external notification of such failures. R ˜ E Q extends the required behavior described by REQ by describing how notification of hardware malfunctions is presented to system users.
Embedded Systems
Avionics software is embedded software with legally mandated safety and reliability concerns used in avionics. This software are highly used in the aviation industry, where there is high need of accuracy and safety, any mishandling can lead to huge destructive effects.
Most of the software is real-time embedded code and has unique interfaces to various hardware. The aircraft manufacturers want lower SWaP-C — Size, Weight, and Power, and Cost. The first three are hardware. That’s being addressed by increased integration and Integrated Modular Avionics (IMA). That, in turn, affects the software as now your software has to run hardware that you don’t control. You get to develop it on a development platform and then integrate it onto the aircraft.
The key elements that differentiate flight system software from other less-specialized types of software are: Functional Safety, real-time, determinism, SOTIF (Safety of the Intended Function). Derived from these are: functional safety architectures, concurrent programming, analysis and design methodologies, development methodologies, coding standards, testing methodologies, etc. And the broad umbrella of “avionics software” covers everything from boot-loaders, hypervisors, OS abstraction, Operating systems, drivers, middleware, System Services, and flight programs, User interfaces etc.
A programmer follows a prescribed process, prescribed coding standards, prescribed testing methodologies etc, and may be unaware of the reasoning behind some of the design decisions being made by the architects and systems engineers.
Developing software for avionics is considered a specialized field with respect to requiring knowledge of embedded systems skills, handling communications protocols between avionics systems, and adhering to the appropriate industry standards. Low-level programming knowledge of programming (writing driver code, interacting with devices , etc.) and software are very useful for learning avionics software.
Understanding embedded systems development is critical because, which a device might be using an operating system, some avionics hardware is programmed as a “bare machine.” In this regard, you get no help from device drivers, file systems, or other OS-type services. On the other hand, there are likely code libraries that may be used to access certain parts of the embedded system, so you just need to understand the API.
Understanding inter-device communications is important because different devices exchange information using various types of protocols. The military in particular uses MIL-STD-1553 or ARINC 429 as standards. Some of these are translated into commercial equipment.
In avionics software actual standards are often far more detailed and they are even more rigorous than commercial standards and other embedded systems, usually described with hundreds of pages in documents. It mainly runs on a real time operating system.
Enabling Linux in Safety Applications (ELISA)
The Linux foundation in 2019 launched the Enabling Linux in Safety Applications (ELISA) open-source project to help companies “build and certify Linux-based safety-critical applications and systems whose failure could result in loss of human life, significant property damage or environmental damage.”
Right now, an open-source operating system cannot be used, uncontrolled and incrementally, within a mission-critical project. However, this does not mean that OSS cannot be used at all. The project has several dedicated working groups that focus on providing resources for System integrators to apply and use to analyze qualitatively and quantitatively on their systems.
Certification Requirements
Engineering in the avionics domain is driven by various legally mandated regulations, dedicated to safety and reliability. Prior to the first official flight in a commercial aircraft, a national certification authority has to inspect the airworthiness of all components, including airborne computers and software. This process is called avionics qualification. The acceptance is
strictly related to compliance with international aerospace standards, such as DO-178: Software Considerations in Airborne Systems and Equipment Certification.
The second part, certification boils down to demonstrating to the certification authority that your software meets all the requirements and is safe. That boils down to primarily requirements traceability, testing, and documentation.
For reliability assurance in missionand safety-critical avionics software, there must be a proof
that program execution and resource consumption are entirely deterministic and predictable. Depending on the system criticality, heavy non-functional requirements prevail.
Some representative examples of coding constraints, referring to mission-critical code, qualified at Design Assurance Level C:
• Dynamic programming mechanisms, such as late binding or dynamic dispatch are prohibited.
• To predict the memory footprint at compile time and to guarantee faultless resource consumption, memory must be allocated statically.
• Source code that is never executed in any configuration has to be completely removed.
• Each line of source code must traceably correspond to a low-level system requirement.
