Most of us have heard an aircraft safety demonstration – a short pitch that reminds us to fasten seatbelts, locate emergency exits and set personal electronic devices to airplane mode. Although all these safety measures are important, the cumbersome task of turning off electronics is perhaps one of the most critical because it protects against aircraft technology interference or equipment malfunction.

Setting our tablets to airplane mode is relatively simple, but raises an interesting question; if a simple cellphone can cause interference, can vital aircraft technology easily malfunction? After all, seeing a blue screen on our laptops may disrupt our workday, but a pilot’s computer freezing or display blacking-out mid-flight is a scary proposition.

This is precisely the reason why electronics running crucial aircraft applications, like auto-pilot, flight navigation and ground communications, must prove airworthiness. Unlike cellphones, which can be put into airplane mode with a simple swipe of a finger, these electronics undergo an extensive safety certification process that proves they meet the highest levels of reliability.

Design Assurance Level (DAL) Classification  

A safety-critical system is one whose failure can cause death, serious injury, property damage or mission degradation. Each system is assigned a design assurance level (DAL) based on the impact it can have if it fails. For example, a computer that lowers landing gear may be classified DAL-A because its failure will result in a crash, but a computer that displays secondary symbology could be DAL-C.

Each DAL corresponds to the likelihood of an error in a system – for DAL-A, the likelihood of any system design error is one in a billion.

Determinism and Information Assurance

Safety-critical systems are deterministic – they must repeatedly function correctly under multiple operating conditions and display no unpredicted anomalies.

One of the ways design engineers achieve this is by architecting hardware in a simplistic but highly available manner so application interactions that occur via shared system memory, I/O and other resources are minimized. Such interactions can cause interference paths that delay critical aircraft functions, resulting in non-deterministic, unsafe behavior.

For example, a computer controlling DAL-A aircraft landing and DAL-C communications must allocate independent computing resources to each function and have redundant paths so that landing gear will be lowered deterministically–correctly and on time–even if communications are malfunctioning or functioning at maximum capacity.

Technology Collaboration to Build Artifacts

To achieve certification, system developers need to present detailed documentation, or “artifacts,” that assure the system and its individual components have no design errors. Thus, artifacts for a safety-critical mission computer must characterize the performance, behavior and mitigation of silicon components such as the FPGA and CPU against all potential failure conditions.

When a developer builds a safety-critical subsystem with commercial silicon, they face difficulties collecting necessary design information because silicon vendors may deem it proprietary. For example, processor manufacturers may withhold details on how a multicore processor's share cache works, even though cache operation significantly impacts application performance.

Table 1: Undesired processor mechanisms affecting temporal determinism**

Therefore, it is necessary that system developers work with commercial off-the-shelf (COTS) silicon engineers to understand processor behaviors and mechanisms affecting determinism. This technology relationship facilitates the creation of comprehensive artifacts that assure successful certification and speed time to market. After all, it was through close collaboration with Intel and leading real-time operating system (RTOS) partners that Mercury launched the first certifiable Intel® Core™ i7 single board computer with the latest-generation processor.

“Airplane-Mode” Electronics

The Radio Technical Commission for Aeronautics (RTCA) defines the processes required to create DO-254 (hardware) and DO-178C (software) artifacts. Because certification takes place at the platform level, system integrators turn to board and subsystem developers who provide DO-254 and DO-178C artifacts with their solutions and support integrators through the certification process.

If questions and concerns arise during certification, integrators may need to append artifacts and look to developers and their technology partners to provide additional insights, input and guidance. In conclusion, meticulous design engineers, safety experts and technology partners prepare flight electronics for “airplane mode” and certification guarantees them for take-off.

Learn More:

• Whitepaper: Evaluating Safety-Certifiable Computing for Tomorrow’s Avionics
• Vodcast: Intel and Mercury talk DAL-Certifiable Computing for Future Avionics
• On-Demand Webinar: Multi-Core Certifiable Computing for Tomorrow’s Avionics

Credits

*Definition pulled from NIST glossary

** Table from Intel Solutions Brief: “Airworthiness of Systems Using Intel Multi-Core processors”