How does a PFD handle unphysically abrupt changes in the parameters it's displaying? 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:


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.
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.
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.
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.