Aerospace Functional Safety

No. Civil aviation runs on a separate legal and technical stack. The binding requirement lives in aviation regulation, notably the systems safety rule 25.1309 in 14 CFR Part 25 and the equivalent EASA Certification Specification, while the recognized methods live in industry standards such as ARP4754A and its newer revision for development assurance, ARP4761A for safety assessment, DO-178C for software, DO-254 for airborne electronic hardware and DO-160 for environmental qualification. ISO 26262 governs road vehicles and has no standing in an aircraft certification basis. This guide is written for automotive engineers precisely because the two stacks answer the same fear with different grammar.

It does not, and Chapter 12 is the page's definitive statement of why. A development assurance level is assigned from an aircraft-level failure condition class that has no exposure or controllability parameters, and it obligates a development process. An ASIL is assigned to a hazardous event and its safety goal from severity, exposure and controllability, and it carries an item-level metric set that aerospace never defined. The ladders are analogous, because both scale rigor with consequence, so an engineer fluent in one recognizes the logic of the other immediately. The levels are not convertible, and any artifact reuse between the domains has to be argued through the objectives actually met.

Because for the functions that keep an aircraft flying, cutting power is not a safe state, it is a handover. Some functions can fail passively or be shed when their loss is acceptable, but where a required capability must remain available until landing, availability itself becomes part of the safety property. That single constraint explains why the domain invests in voting, monitoring, dissimilarity and graceful degradation ladders instead of detect-and-shut-down. It is also why automated driving programs, which remove the driver who made the controlled stop cheap, keep rediscovering the same architecture vocabulary at automotive cost points.

No, and the mirror image is also true. Aerospace never defined item-level architectural metrics: each failure condition carries a probability objective, the preliminary assessment breaks that objective into allocations, and the system safety assessment closes it with a quantified fault tree whose basic events come from component failure rate data and service experience. ISO 26262 attaches no numeric probability target to a hazardous event and instead measures the item with SPFM, LFM and PMHF. Chapter 13 walks both sides, including the shared latent fault physics underneath, and flags the unit traps that make careless cross-domain comparisons look rigorous while meaning nothing.

Fifteen chapters. The first eleven build the aviation stack: why no safe state is reachable in flight, the authorities and standards, failure conditions and their probability targets, the safety assessment chain, development assurance and DALs, DO-178C software assurance, DO-254 and environmental qualification, common cause analysis, fly-by-wire architectures, integrated modular avionics and partitioning, and certification in practice with its in-service loop. Three comparison chapters then put aerospace and ISO 26262 side by side on risk models, on metrics and mechanisms, and on process and ecosystem. A closing chapter runs one illustrative function end to end and leaves you a reference card.

No. It is educational material built from public regulatory text, public standards overviews, published accident investigations and the open engineering literature, and it says so explicitly on the page. It explains and paraphrases in its own words rather than reproducing clause text, requirement wording or determination tables from purchased standards. Revisions and accepted means of compliance vary by project and jurisdiction, so it does not replace the standards themselves or agreement with the applicable certification authority.