Fuselage, Wings and Stabilizing Surfaces — Page 41, Lesson 62

I want to walk you through the heart of the safety philosophy that governs every system we'll study in this course — CS 25.1309. This is the regulation that decides, in hard numbers, how safe an aircraft system has to be before it's allowed to fly. And right now we're looking at the Acceptable Means of Compliance, the AMC, which is the official guidance on how to prove you meet that requirement. Let me set the scene. CS-25 is the European certification specification for large aeroplanes, and 25.1309 is the paragraph that deals with equipment, systems, and installations. The AMC text we're reading is from Book 2, page 2-F-45, an annex to ED Decision 2007/010/R. That's just the legal trail — the point is this is the authoritative interpretation of the rule. The opening line is crucial. The design must prevent a single failure from "damaging or otherwise adversely affecting more than one redundant system channel or more than one system performing operationally similar functions." Let me unpack that. Redundancy means you have multiple independent channels doing the same job — say, two hydraulic systems or two flight control computers. The rule says one failure must not be able to take out two of those channels at once. And "operationally similar functions" means systems that do the same kind of job, even if they're not identical — the rule protects those too. This is the principle of failure independence, and it's the backbone of everything that follows. Now, paragraph (1), General. It says compliance with CS 25.1309(b) should be shown by analysis and, where necessary, by appropriate ground, flight, or simulator tests. So the primary method is analysis — you prove safety on paper — and you back it up with testing when the analysis isn't enough. The process is: Failure Conditions should be identified and their effects assessed. A Failure Condition is a defined, specific state where the system has failed in a particular way — not just "something broke," but a precise, named condition with known consequences. Then comes the key relationship. The maximum allowable probability of the occurrence of each Failure Condition is determined from the Failure Condition's effects. So the more severe the effect, the lower the allowed probability. That's the whole logic of the regulation — and it's exactly what the figure on page 42 shows, the relationship between probability and severity of failure condition. Now, when you assess those probabilities, the analysis must consider seven specific things. I want to walk through each one because this is the checklist you'll use in real certification work. First, possible Failure Conditions and their causes, modes of failure, and damage from sources external to the system. So you must identify every way the system can fail, what triggers it, how it fails, and — importantly — damage from outside the system itself, like a bird strike or a tire burst hitting a component. Second, the possibility of multiple failures and undetected failures. This is critical. A single failure is one thing, but you must also consider two failures happening together, and failures that happen silently — undetected — because those are the dangerous ones. A failure you don't know about can sit there and combine with a second failure later. Third, the possibility of requirement, design and implementation errors. This is about mistakes made by people during development — a wrong requirement written down, a design error, or an error when the design was actually built or coded. The regulation forces you to consider that the system might be wrong even before it's built. Fourth, the effect of reasonably anticipated crew errors after the occurrence of a failure or Failure Condition. So you must think about what the pilots will do — or do wrong — once something has already failed. The crew's reaction is part of the safety case. Fifth, the effect of reasonably anticipated errors when performing maintenance actions. Same idea, but on the ground — a mechanic making a mistake during maintenance must be considered in the analysis. Sixth, the crew alerting cues, corrective action required, and the capability of detecting faults. So the analysis must cover: what warning does the crew get, what action must they take, and can the fault actually be detected at all? And seventh, the resulting effects on the aeroplane and occupants, considering the stage of flight and operating and environmental conditions. So the same failure has different consequences depending on whether you're at 40,000 feet in cruise or on final approach in bad weather. The analysis must account for that. Then we move to paragraph (2), Planning. This AMC provides guidance on methods of accomplishing the safety objective. The detailed methodology needed to achieve this safety objective will depend on many factors, in particular the degree of systems complexity and integration. So the regulation doesn't dictate one rigid method — it gives you guidance, and the actual approach depends on how complex and how integrated your systems are. And the text ends by noting that for aeroplanes containing many complex or integrated systems — and that's exactly what modern airliners are — the methodology gets more involved. So the big picture I want you to take away: CS 25.1309 is the safety contract. You identify every Failure Condition, you assess its severity, you assign it a maximum allowable probability based on that severity, and you prove by analysis — backed by tests — that your design meets those probabilities. And in that analysis you must cover all seven areas: external damage, multiple and undetected failures, development errors, crew errors, maintenance errors, alerting and detection, and the effects in context of flight stage and environment. That's the foundation. Everything we study — hydraulics, flight controls, electrical — every system's redundancy and monitoring is designed to satisfy this one regulation.