Pitot-Static Blockage Unreliable Airspeed Case Study

This case study examines an unreliable airspeed event caused by a blocked pitot-static measurement path. The engineering question is not only why one cockpit indication was wrong. It is whether the aircraft system can detect the air-data inconsistency, reject the bad source, preserve flight-control margins, and provide usable evidence for release after maintenance.

The case is realistic rather than tied to one accident. It is useful because airspeed is not measured directly. It is inferred from pressure, density assumptions, calibration, sensor plumbing, heating, drains, static ports, electronics, and voting logic.

Engineering Boundary and Assumptions

This case studies the evidence logic for one unreliable airspeed event. It does not replace an aircraft type certificate, flight manual, minimum equipment list, maintenance manual or approved flight-test procedure.

The engineering boundary includes pitot pressure path, static pressure path, air-data transducer, air-data computer, display channel, flight-control data-validity monitor and maintenance release record. The boundary excludes pilot training evaluation except where the alerting and degraded-mode response must be verified.

The key assumption is that at least two independent air-data or aircraft-state sources remain available. If the event affects multiple common-mode sources, the voting logic and return-to-service decision must be more conservative.

Case Context

After maintenance on a regional aircraft, a post-maintenance flight shows an unreliable airspeed warning during climb. Air-data channel A indicates much lower airspeed than channels B and C. Inertial data, GPS groundspeed corrected for estimated wind, angle-of-attack trend, and engine setting are consistent with channels B and C.

The inspection later finds moisture and debris in one pitot pressure path. The blocked channel produced plausible but wrong airspeed values. The release review must decide whether maintenance action and built-in monitoring are sufficient before returning the aircraft to service.

Simplified Flight Data

Use one representative point during climb.

Quantity	Value
estimated air density	1.00\ \text{kg/m}^3
channel A indicated airspeed	72\ \text{m/s}
channel B indicated airspeed	91\ \text{m/s}
channel C indicated airspeed	93\ \text{m/s}
inertial/GPS wind-corrected speed estimate	90\ \text{m/s}
current-configuration stall speed	62\ \text{m/s}
required minimum operating margin	1.3V_S
air-data disagreement threshold	8\ \text{m/s} for 2\ \text{s}

The aircraft is in a normal climb attitude. There is no evidence of actual stall onset, abnormal acceleration, or thrust loss.

Data Quality Check

Before interpreting the numbers, verify that the sampled data are time-aligned. A delayed air-data channel can mimic disagreement during acceleration. The event record should include timestamp source, sample rate, filtering delay, pressure transducer status, heater status and maintenance configuration.

If the disagreement appears only during rapid acceleration or turbulence, the analysis should separate sensor blockage from lag, filtering, static-source error and wind-estimate error.

Step 1: Convert Airspeed to Dynamic Pressure

For a first-pass subsonic screen, dynamic pressure is:

For channel A:

For the median healthy airspeed, use:

Dynamic-pressure residual:

Normalized residual:

Engineering Comment

Channel A is not slightly noisy. It implies almost 39\% less dynamic pressure than the other evidence. A physically plausible aircraft state must reconcile airspeed, attitude, thrust, vertical acceleration, inertial speed, and angle of attack. Channel A does not.

Pressure-Path Interpretation

For a pitot-derived channel, a low indicated airspeed can mean the measured total pressure is too low, the static pressure is too high, the transducer calibration is wrong, or the data chain is corrupt. The physical inspection therefore should not stop at the pitot head. It should include tubing, drains, fittings, leaks, heater function, pressure transducer ports and maintenance disturbance points.

Step 2: Check Air-Data Disagreement

Compare channel A with the median of B and C:

The disagreement threshold is:

Therefore:

The air-data disagreement threshold is exceeded.

Engineering Comment

The monitoring logic should not wait until a flight-control upset occurs. The purpose of a disagreement monitor is to catch a bad data source while the aircraft still has flight-path and energy margin.

Persistence and Nuisance Trip Review

The 2\ \text{s} persistence requirement prevents one bad sample from driving a mode change. The verification record should show both the threshold crossing and the timer behavior. If the monitor trips too easily, crews may disregard it; if it trips too late, automation may use invalid data for too long.

Step 3: Check Stall-Margin Interpretation

The current-configuration stall speed is:

The required operating margin is:

Channel A indicates:

Channels B and C indicate approximately:

Engineering Comment

If an automation function trusted channel A, it could interpret the aircraft as near an unsafe low-speed condition and command inappropriate pitch or thrust behavior. If the failure had the opposite sign, it could hide a real low-speed condition. Air-data validity is therefore a flight-control and envelope-protection issue, not only a display issue.

Angle-of-Attack Consistency

A stall-margin cross-check should compare indicated speed with angle of attack and load factor. If channel A claims low speed but angle of attack, acceleration and flight path remain consistent with the healthy channels, the low-speed indication is suspect. If speed and angle of attack both move toward stall, the monitor must avoid dismissing a real aerodynamic condition as a sensor fault.

Step 4: Identify the Likely Failure Pattern

The evidence pattern is:

Evidence	Interpretation
one channel low	single-source fault more likely than true aircraft state
B, C, inertial/GPS estimate agree	independent evidence supports higher speed
no abnormal angle-of-attack trend	channel A low-speed indication is inconsistent
post-maintenance timing	maintenance-induced blockage or plumbing issue is plausible
debris/moisture found	physical evidence supports pitot-path blockage

The likely failure mode is a blocked or restricted pitot pressure path on channel A, not an actual loss of airspeed.

Static-Source Cross-Check

A static blockage can produce altitude, vertical-speed and airspeed errors with a different pattern from a pitot blockage. The maintenance investigation should compare altitude trends, vertical-speed response, static-port condition and leak-check results. A pitot blockage conclusion is incomplete if the static path was never tested.

If both pressure paths have been disturbed during maintenance, inspect them as one coupled physical measurement system. A correct pitot line paired with a restricted static path can still produce unsafe air-data logic.

Step 5: Assign Flight-Control Data Validity

A conservative data-validity rule is:

1. compare all air-data channels;
2. compare airspeed with inertial/GPS and wind estimate when available;
3. compare with angle of attack and acceleration consistency;
4. reject the outlier if two independent channels and aircraft-state evidence agree;
5. degrade automation mode if voting confidence is insufficient;
6. alert the crew and log the failed source.

For this event, channel A should be rejected. The aircraft may continue using validated alternate air-data sources only if the flight-control system and operating procedures are approved for that degraded state.

Automation Degradation Rule

The system should distinguish three states:

• normal operation, where all required air-data sources agree;
• degraded operation, where one source is rejected and the remaining evidence is valid;
• unreliable operation, where voting confidence is insufficient for automatic envelope protection or autopilot use.

The case should be released only if the event record proves that the actual system entered the correct state and did not continue using channel A as a trusted control input.

Failure Mode Analysis

Failure mode	Cause	Effect	Initial rating
erroneous low airspeed on one air-data channel	blocked pitot pressure path after maintenance	false low-speed state, nuisance warnings, possible inappropriate automation response	S=9,\ O=3,\ D=4

Initial risk priority number:

The severity is high because an air-data error can affect crew decision-making, protections, autopilot behavior, and performance interpretation.

Detection Evidence

The detection rating should be based on real evidence: disagreement alert timing, fault-code log, channel-voting state, crew message, recorded source selection and maintenance finding. A lower RPN is not justified merely because the failure was eventually found during inspection.

Corrective Actions

The maintenance and engineering response should require:

• pitot and static line inspection, drain verification, leak check, and contamination removal;
• pitot heat and water-ingress checks where applicable;
• independent air-data channel comparison after maintenance;
• review of air-data disagreement thresholds and alert timing;
• verification that flight-control laws reject invalid air-data sources correctly;
• crew procedure review for unreliable airspeed;
• flight-test or ground-test evidence showing no residual blockage;
• maintenance record linking the fault, corrective action, and release authorization.

After corrective action and successful validation:

Residual risk priority number:

Maintenance Proof Package

A defensible package includes pressure-path cleaning record, leak-test result, drain check, heater-function evidence, transducer status, channel-comparison run, fault-code clearance, independent inspection signoff and a reference to the maintenance step that was disturbed before the event.

If moisture or debris was found, the release should also ask why it entered or remained in the line. Otherwise the action only clears the symptom.

Release Decision

The aircraft should not be released based only on replacing or clearing the pitot tube. The release package must prove that the measurement path, monitoring logic, and operational response are valid.

The defensible engineering decision is:

Return to service only after the affected pitot-static path passes inspection and leak checks, channel comparison validates air-data agreement, the disagreement monitor is confirmed, and the maintenance release records the evidence.

If the event exposed a monitoring or flight-control voting weakness, the release should remain blocked until that weakness is dispositioned through engineering review.

Hold Triggers

Hold return to service if any of the following remain open:

• unresolved disagreement between air-data channels after maintenance;
• failed or undocumented pitot/static leak check;
• unexplained heater, drain or contamination finding;
• incomplete fault-log review;
• monitor did not reject the suspect channel in the recorded event;
• degraded-mode operation is not approved for the intended dispatch condition.

Transferable Lessons

Unreliable airspeed is a system problem. It can begin as moisture, debris, icing, mis-rigging, connector error, static-port blockage, calibration drift, or pressure-transducer fault, but the consequence is shaped by displays, alerts, control laws, procedures, and maintenance evidence.

A strong air-data review asks:

1. Are pressure paths clear, heated, drained, and leak-tested?
2. Do independent air-data channels agree within threshold?
3. Is airspeed consistent with inertial speed, wind estimate, angle of attack, thrust, and aircraft response?
4. Does automation reject or degrade safely when air data are unreliable?
5. Is the release decision supported by physical inspection, test data, and recorded configuration?

The engineering lesson is that airspeed is not a number to trust in isolation. It is an inferred state that must remain consistent with the aircraft, the sensors, the environment, and the control system.

The same reasoning applies to other derived flight states: altitude, Mach number, vertical speed, angle-of-attack validity and energy-state cues. Each value is useful only when the sensing path, data fusion logic and operational response remain consistent.