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.