This question is about human factors requirements in the design of software components displaying instruments in a primary flight display. (It's not about how to implement the software.)

Let's take an airspeed indicator (ASI) as an example. In a "steam gauge" ASI, the needles add some inertia to the instrument, limiting the maximum rate of change it can display. This is OK, because the actual indicated airspeed (IAS) has a much smaller maximum rate of change in the real world.

In a "moving tape" ASI on a primary flight display (PFD), a software component receives updates of IAS and changes the display appropriately. The human readability of the instrument depends on the changes being gradual, so the numbers gradually "wind around" like a physical instrument: if the numbers abruptly jump, it's hard for the pilot to notice and understand what has happened.

In normal circumstances, an abrupt jump in IAS (or altitude, heading, or other important flight parameters) cannot occur, because there are physical limits on the rate of change. But the software component just receives a stream of values, and it's possible that an error elsewhere in the system could cause an abrupt jump.

Is there typically a requirement on this software component to smooth the instrument display or handle this possible situation? I can imagine some possible ways of dealing it:

  1. The display component has a limit set on rate of change (guided by the physical limitations and the HF limit on how fast a change can be displayed understandably), and it has to reject out-of-range changes (presumably tied to an EFIS/ECAM message). When the changes are in range, the display is updated immediately without interpolation.

  2. The display component has to interpolate between received values by animating, so that even abrupt changes appear to "wind" the instrument. This preserves the readability of the instrument but will introduce some latency in the displayed values.

  3. The display component has no special requirement, and protections elsewhere in the system ensure that it never has to deal with unphysically abrupt changes.

I understand that per-component requirements are unlikely to be published by any vendor, so I'm happy to take an unsourced answer if it's backed by personal experience. Even information from an experienced glass-cockpit pilot who has seen this error state first-hand would be appreciated.

  • $\begingroup$ I believe somewhere in the system there’s a low-pass filter of sorts before the display... not sure where though (that’s probably type specific, anyway). $\endgroup$ Commented Mar 6, 2018 at 16:55
  • 2
    $\begingroup$ Are you asking about a case where the airspeed data (for example) changes too quickly to be physically possible? If so, why would you expect the PFD to do anything other than report a failure? The G1000 will fail an 'instrument' display if the data is "invalid" according to the manual, but Garmin doesn't say exactly what that means, at least not in the manual. I guess it's similar for other systems. $\endgroup$
    – Pondlife
    Commented Mar 6, 2018 at 17:00
  • 1
    $\begingroup$ In my experience, some level of filtering occurs, say from an incoming ARINC 429 data stream or from a sensor input. Most tape displays I have seen are of a rolling type, in that it doesn't just jump to the new value, but rather "rolls" there from the current value. The point is to emulate the behavior of an analog display if possible. $\endgroup$ Commented Mar 6, 2018 at 22:13
  • $\begingroup$ I did find this in SAE 6296 - Smoothing The indication of airspeed shall be smooth and free from irregular motion (jitter, jerkiness, or ratcheting effects) as the differential pressure or its electrical equivalent is increased and decreased smoothly. $\endgroup$ Commented Mar 6, 2018 at 22:18
  • $\begingroup$ @selectstriker2 That's very interesting, but it's specifically about not adding jerkiness when the input is smooth. $\endgroup$
    – Dan Hulme
    Commented Mar 7, 2018 at 9:29

1 Answer 1


Generally, PFD will smoothen the indication for most of the indicated data.

I don't know any 'legal' requirements for it, but as you mention, basic ergonomics require it.

I have first hand experience with Garmin G1000, so I'll try to explain its PFD behaviour as an example. (It's a bit hard to capture and post a video).

Most (if not all) 'graphical' indications are filtered with the rate (characteristic frequency) consistent with the expected rate of change of the relevant parameter: pitch/roll quickly (but still noticeably, about 0.3 s), airspeed moderately, engine temperature slowly (3-5 s). Digital only indications (say, battery voltage) are also filtered, and in addition their precision is limited such that the updates didn't happen too frequently (e.g. round 0.5 V).

The filter seems to be a second-order low-pass in most cases. For some parameters, notably the indicated airspeed, it is underdamped, which means the indication overshoots slightly for abrupt changes, and generally tends to oscillate to and fro for normal changes. This provides faster response while still being smooth.

An abrupt, unrealistic change of parameters per se doesn't cause a fault for PFD. It's just filtered as usual. However, significantly out-of-range values will fail the indication, but only temporarily, until sensible values resume. Generally, it's the job of the peripheral computers (ADC, AHRS, etc.), as well as of the integration unit (GIA), to detect faults and convey them in special messages. PFD is, after all, just a display.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .