Software Engineering for Safety-Critical Systems

Posts

Showing posts from June, 2026

Hierarchical Requirements: The Most Underrated Tool in DO-178C Compliance

In conversations about DO-178C compliance, certain topics dominate almost immediately—traceability matrices, coverage metrics, independence, verification rigor. These are critical, no doubt. Yet, one of the most powerful tools for achieving all of them is often treated as administrative overhead rather than an engineering discipline. That tool is hierarchical requirements . In my experience working with airborne software teams, especially in safety-critical aerospace programs, most DO-178C issues do not originate in code or testing. They originate much earlier—when requirements are poorly structured, ambiguously decomposed, or inconsistently linked across levels. Hierarchical requirements, when done correctly, quietly eliminate entire classes of compliance problems before they ever surface.

Why Requirements Fail in Safety-Critical Systems — And How to Fix Them

In safety-critical systems, requirements are not just a planning artifact—they are the foundation of safety, certification, and trust. Yet across aerospace programs, I’ve seen highly capable teams struggle with requirements that technically exist, are fully traced, and are formally approved—yet still fail to prevent unsafe behavior. When incidents, certification findings, or late rework occur, the root cause is often attributed to implementation or verification. In reality, the failure usually begins much earlier. Requirements fail not because teams don’t write enough of them, but because they are written without sufficient clarity, intent, or system context. Understanding why requirements fail is the first step toward building ones that actually work.

Making Safe Use of AI in Safety-Critical Systems

Over the past few years, I’ve had a front-row seat to the growing excitement—and justified concern—around using artificial intelligence in safety-critical systems. Nowhere is this tension more visible than in aerospace, where the cost of failure is measured not just in money or mission delay, but in human lives. AI offers enormous potential, but in environments governed by strict certification, redundancy, and safety margins, “moving fast” is simply not an option.

Architecting Software for Failure — The Art of Designing for the Unexpected

Modern software systems are marvels of engineering complexity. They operate across distributed networks, integrate with countless dependencies, and often support mission-critical operations. Yet, despite our best efforts, software will fail. Hardware degrades, networks partition, assumptions break, and humans make mistakes. The question is not if failure will occur, but how well our systems respond when it does . Architecting software for failure is not a pessimistic mindset—it is a disciplined, realistic approach to building resilient systems. In my experience working in the aerospace industry, this mindset is not optional; it is foundational. When failure can jeopardize safety, cost millions, or ground an entire fleet, resilience becomes a design requirement, not an afterthought.

Safety-Critical Software Standards: What Really Matters and Why

When you spend enough time around safety-critical systems, you stop thinking of standards as external obligations and start seeing them as accumulated experience—often written in response to hard lessons. In aerospace, software standards are inseparable from safety culture. They shape how we think, how we document decisions, and how we prove to ourselves and others that a system can be trusted.