Systems engineering for aircraft

An aircraft is a flying collection of systems. The wing, fuselage and engines that earlier courses analysed carry the load, but almost everything the crew touches, and almost everything that keeps the passengers alive, is a system: electrical power, hydraulics, fuel, cabin air, ice protection, landing gear, the sensors that measure speed and attitude, the radios and navigation receivers, the displays and the software that ties them together. On a modern business jet these systems account for a large part of the empty weight, most of the wiring, a large part of the purchase price and most of the maintenance hours. This course works through them one by one, using the two aircraft that Borealis Aerospace has been developing in Winnipeg: the Tern Block 2 hybrid-electric utility aircraft and the Swift 900 business jet study.

Élise Fournier, the chief engineer, opens the course for the new systems hires the same way every year. She puts a single slide on the screen with the Tern's failure conditions and says that the systems engineer's real job is to make sure that every one of them is either impossible enough or survivable enough. The rest of this lesson explains what she means: how aircraft systems are developed, how their safety is assessed, and how the rules of Transport Canada connect the two.

Systems engineering and the development process

Systems engineering is the discipline of turning what an aircraft must do into equipment that does it, and of proving that the equipment does it. Aircraft programmes follow a recognisable pattern, often drawn as a V. On the left side, requirements flow downward: aircraft-level functions, such as provide propulsive power or provide attitude information, are allocated to systems, then to items such as a generator, a software application or a circuit board. At the bottom of the V the items are built. On the right side, integration and verification flow upward: each item is tested against its requirements, the system against its requirements, and finally the aircraft against its functions in ground and flight test.

The industry guidance for this process is SAE ARP4754, Guidelines for Development of Civil Aircraft and Systems, now in revision B, published at the end of 2023. A companion document, ARP4761, describes the safety assessment methods; it too was revised in 2023 as ARP4761A. Regulators accept these documents as one acceptable way to show that a complex system meets the airworthiness rules, and in practice almost every new aircraft programme in Canada and the United States uses them. They do not tell engineers how to design a generator; they tell them how to organise requirements, how to trace each requirement to its verification, how to manage changes and how to assign the level of rigour each part of the system needs.

Three ideas from ARP4754B appear again and again in this course. The first is traceability: every requirement has a parent above it and a verification below it, so that when a test fails, or when a requirement changes, engineers can see everything that is affected. The second is independence: the people who check a safety-critical design should not be the people who wrote it, and the most critical functions should not depend on a single piece of equipment or a single design team's assumptions. The third is development assurance: since nobody can test every possible combination of inputs to a complex system, the confidence that it has no design errors comes from the rigour of the process used to build it, and that rigour is scaled to how much harm an error could do.

Failure conditions and their classification

The safety assessment begins with a functional hazard assessment, usually shortened to FHA. The team lists the aircraft's functions and asks, for each one, what happens if it is lost, or if it works wrongly without anyone noticing. Each of these failure conditions is classified by its worst credible effect on the aircraft, the crew and the occupants. The usual five classes are catastrophic, hazardous, major, minor and no safety effect.

The probabilities in the table are averages per flight hour over the fleet's life, and they make an important point: the more severe the effect, the less likely it must be. A failure condition that could kill everyone on board must be so improbable that it is not expected to happen in the whole life of all the aircraft of the type. A minor inconvenience can be allowed to happen now and then. The rule that sets this relationship in law is the system safety standard in section 525.1309 of Transport Canada's Airworthiness Manual (523.2510 for normal category aeroplanes such as the Tern). For smaller aeroplanes the accepted targets are less demanding and depend on the class of aeroplane, but for the Tern's novel hybrid propulsion Élise has set the company's own target at the transport-category value of 10⁻⁹ per flight hour for total loss of propulsive power, and Transport Canada has accepted that approach in its special conditions.

Two further rules sit beside the numbers. A catastrophic failure condition must not result from any single failure, however unlikely that failure appears, so a single cable, a single bolt or a single software error cannot be allowed to bring the aircraft down. And the crew must be told about failures that need their action, and must have the information and the time to act. Many of the systems decisions in this course come from those two rules rather than from any arithmetic.

From the FHA to the system design

Once the FHA is complete, the team carries out a preliminary system safety assessment, the PSSA, on the proposed architecture. It asks whether the planned design can meet the targets and what each piece must contribute. Fault trees are the main tool. A fault tree starts with a failure condition at the top and works downward through logic gates. An OR gate means that any one of the events below it causes the event above; an AND gate means that all of them must happen. Failure rates are assigned to the basic events at the bottom, and the probability of the top event is calculated.

For independent events, the probability through an OR gate is approximately the sum of the input probabilities when they are small, and the probability through an AND gate is their product. Exposure time matters for AND gates: two independent failures must happen in the same flight, or one must remain undetected until the other occurs. A latent failure, one that nobody knows about until it is needed, is the systems engineer's quiet enemy, because its exposure time is not one flight but the interval between the checks that would find it.

Arjun Mehta, working his first systems assignment, builds the Tern's fault tree for loss of all propulsive power. In the Block 2 design, the turboshaft-driven generator and the battery both feed a single high-voltage power distribution unit, which supplies the two propeller motors. Each motor is fed from both sources, so the loss of one motor is only a major failure condition: the Tern can climb and land on one. But if both energy sources fail in the same flight, or if the distribution unit fails, both propellers stop.

# Functional hazard assessment for three Tern Block 2 functions, with design assurance level
# allocation and a simple fault tree check of the "loss of all propulsive power" failure condition.
# Probabilities and failure rates are illustrative teaching values.
classes = {  # severity: (largest allowed average probability per flight hour, development assurance level)
    'catastrophic': (1e-9, 'A'), 'hazardous': (1e-7, 'B'), 'major': (1e-5, 'C'),
    'minor': (1e-3, 'D'), 'no safety effect': (None, 'E')}
fha = [
    ('Loss of all propulsive power in flight', 'catastrophic'),
    ('Loss of one propeller motor', 'major'),
    ('Erroneous battery state of charge shown to the crew', 'hazardous'),
    ('Loss of cabin reading lights', 'no safety effect'),
    ('Loss of the turboshaft generator, battery available', 'major'),
]
print(f"{'failure condition':52s} {'class':17s} {'limit /fh':>9s}  DAL")
for name, cls in fha:
    lim, dal = classes[cls]
    print(f"{name:52s} {cls:17s} {('%.0e' % lim) if lim else '   -':>9s}   {dal}")

# Fault tree: all propulsive power is lost only if BOTH energy sources fail (AND gate) or the
# single power distribution unit fails (OR gate above it).
lam_gen = 2.0e-4      # turboshaft + generator loss rate per flight hour
lam_batt = 5.0e-5     # battery system loss rate per flight hour
lam_pdu = 2.0e-10     # power distribution unit, designed with internal redundancy
t = 1.5               # average flight time in hours; exposure for the AND gate
p_and = (lam_gen * t) * (lam_batt * t) / t   # both fail in the same flight, per flight hour
p_top = p_and + lam_pdu
print(f"\nboth sources lost in one flight: {p_and:.1e} per flight hour")
print(f"top event incl. distribution unit: {p_top:.1e} per flight hour; limit 1e-09 -> "
      + ('meets' if p_top <= 1e-9 else 'does NOT meet'))
for t2 in (1.5, 3.0, 6.0):
    p = (lam_gen * t2) * (lam_batt * t2) / t2 + lam_pdu
    print(f"   with {t2:3.1f} h flights: {p:.1e}")

# Design change: split the battery into two independent strings, each able to land the aircraft.
p_strings = (lam_batt * t) ** 2                     # both strings lost in the same flight
p_and2 = (lam_gen * t) * p_strings / t
print(f"\nwith two battery strings: {p_and2 + lam_pdu:.1e} per flight hour -> "
      + ('meets' if p_and2 + lam_pdu <= 1e-9 else 'does NOT meet'))

failure condition                                    class             limit /fh  DAL
Loss of all propulsive power in flight               catastrophic          1e-09   A
Loss of one propeller motor                          major                 1e-05   C
Erroneous battery state of charge shown to the crew  hazardous             1e-07   B
Loss of cabin reading lights                         no safety effect          -   E
Loss of the turboshaft generator, battery available  major                 1e-05   C

both sources lost in one flight: 1.5e-08 per flight hour
top event incl. distribution unit: 1.5e-08 per flight hour; limit 1e-09 -> does NOT meet
   with 1.5 h flights: 1.5e-08
   with 3.0 h flights: 3.0e-08
   with 6.0 h flights: 6.0e-08

with two battery strings: 2.0e-10 per flight hour -> meets

The first result does not meet the target. With the generator chain failing at 2 × 10⁻⁴ per flight hour and the battery system at 5 × 10⁻⁵, losing both in the same 1.5 hour flight has an average probability of about 1.5 × 10⁻⁸ per flight hour, fifteen times the target, and longer flights make it worse because the exposure grows. Arjun's first instinct is to ask for more reliable equipment, but Élise points out that improving each component tenfold is expensive and hard to prove. The design change that is easy to prove is architectural: split the battery into two independent strings, with separate contactors and separate cooling, each able to supply enough power to land. Now the battery side of the AND gate is itself an AND of two independent strings, and the top event falls to about 2 × 10⁻¹⁰ per flight hour, dominated by the distribution unit, which has its own internal redundancy.

Two cautions come with this result. First, the AND gates only work if the failures really are independent. A fire in the battery bay, a single coolant pump shared by both strings, a software error common to both battery management units or a lightning strike that couples into both harnesses would defeat them. The common cause analysis, which ARP4761A divides into a zonal safety analysis, a particular risks analysis and a common mode analysis, looks for exactly these threats. Second, a failure rate on a slide is only as good as the evidence behind it, and for new equipment such as high-voltage battery packs the evidence is thin. The team therefore keeps generous margins and plans to update the analysis with service data.

Development assurance levels

Quantitative probability works well for hardware that fails at random, such as a bearing or a capacitor. It does not work for design errors, which are systematic: the same software bug is present in every unit, and it either appears under a given set of conditions or it does not. For such errors the industry uses development assurance levels, or DALs, labelled A to E. A function whose failure could be catastrophic is assigned level A, and the software and complex hardware that implement it must be developed with the most rigorous process; at level E no particular process is needed. Lesson 12 explains how DO-178C and DO-254 turn these levels into specific objectives for software and electronic hardware.

ARP4754B allows a function's level to be reduced when it is implemented by independent members. If two dissimilar channels, developed by different teams with different tools, each perform a level A function, the guidance allows the channels to be assigned lower levels, provided the independence is real and demonstrated. The Tern's two battery management units are an example: rather than buy two identical units, the team is considering one in-house design and one from a supplier, which would make a common software error far less credible. The decision will be made on cost and schedule as well as safety, and the analysis will record why.

Systems integration and the aircraft

The systems are not independent of each other. The electrical system powers the fuel pumps, which feed the turboshaft, which drives the generator; the hydraulic system on the Swift 900 depends on engine-driven pumps and electric pumps; the flight control computers depend on air data and inertial sensors; and almost everything depends on cooling. A mature programme therefore keeps an interface control document for every connection between systems and runs integration rigs, sometimes called iron birds, where real equipment is connected and exercised together long before first flight. Borealis Aerospace has a Tern systems rig in its Winnipeg hangar with the real battery, distribution unit and motors driving propeller load simulators, and a smaller rig for the Swift 900 flight control computers.

Environmental qualification is the other half of integration. Equipment must keep working in the cold soak of a northern ramp, the heat of a summer tarmac, vibration, humidity, lightning-induced transients and the radio fields of the airport. RTCA DO-160, Environmental Conditions and Test Procedures for Airborne Equipment, now in revision G, gives the standard test categories, and most equipment purchase specifications name the DO-160 categories the supplier must meet. The Tern's high-voltage equipment adds tests that few small aircraft have needed before, including partial discharge testing at altitude pressure, which Lesson 2 explains.

Certification basis and special conditions

Every type certificate starts with a certification basis: the list of airworthiness rules, at a particular amendment, that the design must meet. For a conventional aircraft the basis is simply the current standards for its category. For an aircraft with features the rules did not anticipate, such as the Tern's high-voltage hybrid propulsion or the Swift 900's fly-by-wire pitch law, the regulator adds special conditions, extra requirements written for that design. Transport Canada has issued special conditions for the Tern covering battery thermal runaway containment, high-voltage electrical safety, the crew's indications of available energy and the protection of the propulsion system against lightning. Many of them follow conditions already used for other electric and hybrid aircraft, which saves time for everyone.

Means of compliance are agreed early. For each requirement, the applicant proposes how it will show compliance: by analysis, by ground test, by flight test, by inspection or by similarity to a previously certified design. The plan is written in a certification plan and the regulator decides how deeply to be involved. Borealis Aerospace's Design Approval Representatives, engineers authorised to act on the regulator's behalf for some findings, carry much of the routine work, but the novel parts of the Tern remain under direct regulatory review.

The systems engineer's documents form a chain from the top down: the aircraft functions list, the FHA, the system requirements, the PSSA and fault trees, the common cause analyses, the item requirements, the test plans and reports, and finally the system safety assessment, the SSA, which shows that the design as built meets the targets. Élise's slide with the Tern's failure conditions is the top of that chain; the rest of this course fills in the links.