{"id":8969,"date":"2026-03-16T23:02:05","date_gmt":"2026-03-16T22:02:05","guid":{"rendered":"https:\/\/lorit-consultancy.com\/en\/?p=8969"},"modified":"2026-03-16T23:20:25","modified_gmt":"2026-03-16T22:20:25","slug":"development-assurance-in-aviation","status":"publish","type":"post","link":"https:\/\/lorit-consultancy.com\/en\/2026\/03\/development-assurance-in-aviation\/","title":{"rendered":"Beyond Hardware Faults: Traditional Safety Tools Don\u2019t Get Software"},"content":{"rendered":"

In safety, what worked for wires and circuits doesn\u2019t always work for lines of code – analyzing software is a whole different challenge compared to hardware or physical systems. Traditional methods like Functional Hazard Assessment (FHA), Failure Modes and Effects Analysis (FMEA), and Fault Tree Analysis (FTA) (for aviation purposes described and prescribed by ARP 4761<\/a>) have proven successful for spotting physical component failures. But when it comes to software, it\u2019s<\/span><\/span> like trying to fix a broken code with a wrench- not the right fit for decoding the quirks and complexities of software behaviour.<\/p>\n

Hardware vs Software Failure Characteristics<\/strong><\/h2>\n

Hardware tends to misbehave for the classic reasons: due to component degradation, environmental stress, manufacturing defects or just plain bad luck. Examples include a<\/span><\/span> sensor that stops sending signals, a chip that overheats, or a wire that frays. Such failures are typically random in nature, but can be predicted with statistics \u2013 like reading the future through failure rates.<\/p>\n

Software, on the other hand, does not experience physical degradation. It executes exactly as specified by its code, which is both its strength and its weakness. When software \u201cfails,\u201d it\u2019s not random,<\/span><\/span> it\u2019s because of systematic faults<\/strong>, such as incorrect or incomplete requirements, design mistakes or implementation bugs, unexpected interactions between software components.<\/p>\n

Note that systematic faults are not exclusive to software; hardware can also suffer from design or manufacturing defects. In software, however, faults are inherently systematic.<\/p>\n

\"\"
Source: Adobe Stock<\/figcaption><\/figure>\n

State Space Complexity<\/strong><\/h2>\n

Quite a tricky part of software safety is just how many things software can do, or think it should do. The challenge arises from the potentially large state space<\/strong> of software systems. Its behavior depends on multiple factors, such as input data values, internal system states, execution timing, or interactions with other system components.<\/p>\n

Pulling all of this together leads to a combinatorial explosion of possible execution paths. As a result, applying methods such as FMEA or FTA directly to software becomes a dizzying task. It might be technically possible, but it is overwhelmingly complicated and difficult to manage due to the huge number of potential conditions that must be considered.<\/p>\n

<\/div><\/div><\/div>

\"Nata\u0161a<\/picture>\n\n\n<\/svg><\/div>

Nata\u0161a Simani\u0107 John, Functional Safety Consultant<\/p>\n<\/div><\/div>

Working on safety-critical software systems? Contact our experts<\/a> to learn how to apply effective safety and development assurance practices in your projects.<\/p>\nLearn more<\/span><\/a><\/div><\/div><\/div><\/div>

<\/p>\n

Absence of Classical Failure Modes<\/strong><\/h2>\n

Methods like FMEA rely on identifying specific and predictable component failure modes<\/strong>, such as \u201cstuck open,\u201d \u201cshort circuit,\u201d or \u201closs of signal.\u201d These failure modes are tangible and associated with physical components whose behaviours under failure conditions are well understood.<\/p>\n

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.<\/p>\n

Since the complex logic and multiple interacting states dictate the software behavior, it is difficult to enumerate all possible \u201cfailure modes\u201d 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.<\/p>\n

\"\"
Source: Adobe Stock<\/figcaption><\/figure>\n

Lack of Meaningful Failure Probabilities<\/strong><\/h2>\n

Besides qualitative approaches,<\/span> safety assessment methods such as FTA also employ probabilities to quantify system reliability. <\/span>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.<\/p>\n

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<\/strong>, every time when the triggering condition is met. In other words, in terms of failure probabilities, software is digital by nature. If <\/span><\/span>a bug exists, it will trigger under right conditions with probability 1; if no bug exists, it won\u2019t ever trigger, so the probability is 0.<\/p>\n

The Role of Development Assurance in Aviation<\/strong><\/h2>\n

Because of all the discussed limitations, addressing software safety requires taking a different approach. R<\/span><\/span>ather than looking into analysis with probabilistic quantities and failure modes, aviation safety standards are handling it through process assurance<\/strong>.<\/p>\n

The primary standard governing airborne software development is RTCA\u2018s Software Considerations in Airborne Systems and Equipment Certifications<\/em>, widely known as DO-178C. <\/span><\/span><\/strong>This<\/span><\/span> rulebook provides<\/span><\/span> a \u201crecipe\u201d 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.<\/p>\n

To support safety, DO 178C employs rigorous processes, addressing:<\/p>\n