Aircraft Flight Control Law and Envelope Protection Validation Project

This project builds a validation and release package for an aircraft flight-control law with envelope protection. The goal is to decide whether a candidate software and hardware configuration can be accepted for a defined flight-test envelope, not to tune a controller in isolation.

The project connects flight dynamics, sensors, actuators, embedded timing, protection thresholds, degraded modes, fault injection and evidence traceability. A control law that looks acceptable in continuous-time simulation is not release-ready until the real aircraft constraints are tied to requirements, data, tests and a signed engineering decision.

Project Objective

Prepare a release package for a candidate normal-mode flight-control law. The final deliverable should answer:

1. Does the control law preserve load-factor, angle-of-attack and dynamic-pressure margins at the analysed flight point?
2. Do elevator position and rate limits remain outside saturation for the commanded manoeuvre?
3. Does implementation latency leave enough closed-loop phase margin?
4. Does air-data and inertial-sensor validity logic reject a bad source before envelope protection can use it incorrectly?
5. Are degraded modes, interlocks and pilot-facing effects defined?
6. Which analysis, bench, hardware-in-the-loop and flight-test evidence is required before release?
7. Should the configuration be accepted, accepted with restrictions, or rejected?

The deliverable should be a concise engineering decision package: requirement trace, calculation sheets, test matrix, pass/fail evidence, open actions and final release statement.

Baseline Scenario

Use the following simplified release scenario.

Item	Value
Aircraft configuration	clean, normal law
Flight point	medium altitude envelope-expansion point
Aircraft weight	54\ \text{kN}
Air density	1.05\ \text{kg/m}^3
True airspeed	78\ \text{m/s}
Wing reference area	16.2\ \text{m}^2
Estimated current angle of attack	9.5^\circ
Angle-of-attack protection threshold	13.0^\circ
Hard angle-of-attack limit	14.0^\circ
Normal-acceleration command for test point	2.30g
Structural normal-acceleration limit for this release	2.50g
Envelope-protection normal-acceleration threshold	2.35g
Elevator trim deflection	-3.0^\circ
Elevator manoeuvre demand	9.0^\circ
Elevator position limit	\pm18.0^\circ
Required elevator rate in simulation	55^\circ/\text{s}
Qualified elevator rate limit	70^\circ/\text{s}
Continuous-time phase margin	58^\circ
Crossover frequency	2.2\ \text{Hz}
Required implemented phase margin	25^\circ minimum
Air-data disagreement threshold	7\ \text{m/s} for 0.25\ \text{s}
Control task rate	50\ \text{Hz}

The numbers are deliberately simplified. Real release work must use approved aircraft requirements, validated aerodynamic data, configuration-controlled mass properties, qualified actuator data, sensor calibration, software version records, timing traces, hardware-in-the-loop results, safety assessment and approved flight-test procedures.

Step 1: Define the Release Boundary

This project accepts only one release boundary:

Normal-mode control-law build for the stated configuration, flight point and test manoeuvre, with envelope protection enabled and degraded-mode transition logic available.

The package must not claim clearance for other configurations, mass states, center-of-gravity positions, store fits, icing states, damage states, software builds or flight-test points. A narrow release boundary is not bureaucracy. It prevents a calculation that was valid at one point from being stretched into an untested aircraft condition.

The release package should include:

• software build identifier;
• actuator hardware and qualification reference;
• sensor set and calibration status;
• aerodynamic derivative source;
• mass and center-of-gravity state;
• control-law mode and protection thresholds;
• timing and scheduling evidence;
• analysed manoeuvre and flight envelope;
• validation evidence and open restrictions.

Step 2: Check Dynamic Pressure and Load-Factor Margin

Dynamic pressure is:

Substitute the baseline flight point:

The commanded load factor is:

The release limit is:

Load-factor margin is:

Therefore:

The envelope-protection threshold is:

so protection should intervene before the release limit:

Engineering Comment

The load-factor margin is positive but not large. This calculation should trigger checks of accelerometer calibration, filtering, structural-load conservatism, overshoot during protection intervention and pilot-command transients. A threshold below the limit is useful only if the system detects, computes and actuates quickly enough.

Step 3: Check Angle-of-Attack Protection Margin

Current estimated angle of attack is:

The protection threshold is:

The hard limit is:

Margin from the current state to protection is:

Margin between protection and hard limit is:

Engineering Comment

The aircraft has room before protection begins, but only a small gap between protection and the hard limit. That gap must absorb sensor delay, filtering, estimator error, actuator lag and transient overshoot. If angle-of-attack estimation is not valid in a degraded state, the protection function must either use another validated cue or move to a restricted mode.

Step 4: Check Elevator Position and Rate Limits

Use the combined trim and manoeuvre demand:

Position margin:

Rate margin:

Minimum time to move through the manoeuvre demand at the rate limit is:

Engineering Comment

The position margin is comfortable for this single point, but rate margin is tighter. If the software assumes a faster elevator than the qualified actuator can provide, simulation may overpredict damping and protection response. The release package should include actuator bench traces, not only a datasheet limit.

Step 5: Check Implementation Latency and Phase Margin

Estimate worst-case implementation latency from the timing budget.

Source	Worst-case contribution
sensor filtering group delay	12\ \text{ms}
data bus transfer and alignment	4\ \text{ms}
task scheduling and compute jitter	3\ \text{ms}
output hold to actuator command	10\ \text{ms}
actuator internal command processing	8\ \text{ms}

Total latency:

Delay phase lag at crossover frequency is:

Implemented phase margin:

The requirement is:

Therefore:

Engineering Comment

The implemented margin passes by only 3.7^\circ. That is not a broad robustness reserve. The package should include measured timing traces, worst-case task phasing, filter configuration, bus loading and actuator-command timestamping. A later software change that adds only a few milliseconds can consume the remaining margin.

Step 6: Check Air-Data Fault Rejection

Test a fault-injection case where one air-data channel is biased low.

Channel	Indicated airspeed
A	61\ \text{m/s}
B	78\ \text{m/s}
C	80\ \text{m/s}

Use the median of the three channels:

Channel A disagreement:

The threshold is:

Therefore:

If the disagreement persists longer than 0.25\ \text{s}, channel A must be rejected for envelope-protection input.

Engineering Comment

This is a release-critical check because a low biased airspeed can make protection logic believe that the aircraft is close to stall when it is not, while a high biased airspeed can hide a real low-speed condition. The validation should verify the actual timing: detection, voting, annunciation, control-law transition and any transient command generated during the transition.

Step 7: Build the Fault-Injection Validation Matrix

The project should include at least this validation matrix.

Test ID	Fault or condition	Required response	Evidence
FC-01	nominal manoeuvre at analysed flight point	track command without load-factor, angle-of-attack or actuator limit violation	simulation and hardware-in-the-loop trace
FC-02	elevator position saturation request	command limiter prevents further demand and anti-windup remains stable	actuator command and integrator trace
FC-03	elevator rate saturation request	rate limiter response remains stable and no hidden oscillation appears	actuator bench trace and closed-loop simulation
FC-04	air-data channel biased low	invalid channel rejected before protection uses it	injected sensor stream and validity-state log
FC-05	air-data channel biased high	overspeed or low-speed protection does not rely on the bad channel	injected sensor stream and protection-state log
FC-06	inertial-rate noise burst	filter rejects noise without unacceptable phase-margin loss	frequency-response and timing trace
FC-07	delayed control task	watchdog or degraded-mode logic responds within requirement	scheduler trace and fault log
FC-08	protection threshold crossing	intervention is smooth, bounded and reversible when safe	pilot-in-the-loop or HIL trace
FC-09	sensor disagreement during manoeuvre	mode transition does not produce an abrupt surface command	telemetry replay
FC-10	return from degraded mode	reversion is inhibited until validity and hysteresis criteria are satisfied	state-machine trace

Engineering Comment

Fault injection must be tied to pass/fail criteria. A test that merely shows an alarm appeared is not enough. The useful evidence is whether the aircraft state, command path, actuator response, mode logic and pilot-facing effects stayed within the release boundary.

Step 8: Define Required Evidence

The release package should contain:

• requirement trace from each protection and control requirement to analysis or test evidence;
• aerodynamic and mass-property data references;
• control-law model version and software build identifier;
• actuator qualification data and measured rate/position traces;
• sensor calibration and validity-monitor configuration;
• timing budget and measured worst-case latency;
• simulation cases covering nominal and degraded states;
• hardware-in-the-loop traces for command, sensor, bus and actuator paths;
• fault-injection logs with timestamps and mode-state changes;
• residual risk review and open restrictions;
• final release decision signed by the responsible engineering authority.

Evidence should be configuration-controlled. A screenshot without build identifier, aircraft state and data source is weak evidence even if the plot looks good.

Step 9: Make the Release Decision

For the baseline project, the nominal calculations show:

Check	Result	Status
load-factor margin	8.0\%	pass, narrow
angle-of-attack margin to protection	25.0\%	pass
protection-to-hard-limit margin	7.1\%	pass, narrow
elevator position margin	33.3\%	pass
elevator rate margin	21.4\%	pass
implemented phase margin	28.7^\circ	pass, narrow
bad air-data channel rejection	17>7\ \text{m/s}	pass if timing is verified

Recommended decision:

Accept with restrictions for the defined flight-test point only, provided measured timing traces, actuator bench traces and air-data fault-injection logs match the assumptions above. Do not expand to higher crossover frequency, higher load factor, different configuration or degraded air-data operation until the narrow margins are revalidated.

Engineering Comment

This is not a full aircraft certification result. It is a disciplined release decision for one configuration and one test boundary. The value of the project is the traceability: every accepted margin points to a requirement, a calculation, a test and a restriction.

Common Review Findings

Common findings in this kind of release package include:

• continuous-time margin quoted without digital delay and zero-order-hold effects;
• actuator rate limits present in hardware but absent from simulation;
• protection threshold accepted without transient overshoot review;
• sensor voting tested only in steady flight, not during manoeuvre;
• a degraded mode described in software but not validated with injected faults;
• watchdog timing measured on an unloaded processor only;
• data plots missing build identifier, aircraft state, units or time alignment;
• release statement broader than the evidence boundary.

Flight-control validation is aircraft-level engineering. The accepted result is not a controller gain, a clean simulation plot or a single successful test. It is a bounded release package showing that flight dynamics, sensors, actuators, embedded timing, protection logic, failure handling and evidence all agree.