Beyond Hardware Faults: Traditional Safety Tools Don’t Get Software

Absence of Classical Failure Modes

Methods like FMEA rely on identifying specific and predictable component failure modes, such as “stuck open,” “short circuit,” or “loss of signal.” These failure modes are tangible and associated with physical components whose behaviours under failure conditions are well understood.

Software, however, does not fail in such obvious ways, exhibiting discrete failure modes. Instead, software errors are more like logic puzzles gone wrong and they may manifest as incorrect calculations or logical conditions, improper timing or sequencing, unexpected responses to certain inputs.

Since the complex logic and multiple interacting states dictate the software behavior, it is difficult to enumerate all possible “failure modes” in the same way as hardware components. It is almost like trying to predict all the ways a chess game might go wrong before the first move.

Lack of Meaningful Failure Probabilities

Besides qualitative approaches, safety assessment methods such as FTA also employ probabilities to quantify system reliability. This works well for hardware components, as they do typically have measurable failure rates (e.g., failures per flight hour) derived from historical data or reliability testing. You can measure, predict, and plan for them.

Software, on the other hand, does not have a meaningful probabilistic failure rate. If a software defect/bug exists, the problem will pop up deterministically, every time when the triggering condition is met. In other words, in terms of failure probabilities, software is digital by nature. If a bug exists, it will trigger under right conditions with probability 1; if no bug exists, it won’t ever trigger, so the probability is 0.

The Role of Development Assurance in Aviation

Because of all the discussed limitations, addressing software safety requires taking a different approach. Rather than looking into analysis with probabilistic quantities and failure modes, aviation safety standards are handling it through process assurance.

The primary standard governing airborne software development is RTCA‘s Software Considerations in Airborne Systems and Equipment Certifications, widely known as DO-178C. This rulebook provides a “recipe” of sorts for airborne software, that makes sure the code is produced with a level of confidence compliant to airworthiness requirements, and that it behaves exactly as it should, every single time.

To support safety, DO 178C employs rigorous processes, addressing:

• System aspects relating to software development

• Software lifecycle

• Software planning

• Software development – requirements, design, coding and integration

• Integral processes – software verification, configuration management, quality assurance, certification liaison.

The level of rigor applied depends on the assigned software level, or Item Design Assurance Level (IDAL), which is determined based on the severity of potential system hazards/failures, identified during system-level safety assessments. DAL A gets the most scrutiny and it is reserved for the hazards that could put lives at risk, like autopilot software. DAL E is for software that has no safety relevance at all, so the process is much simpler.

By Nataša Simanić John, Functional Safety Consultant