Den här frågan handlar om krav på mänskliga faktorer vid utformningen av programvarukomponenter som visar instrument i en primärflygdisplay. (Det handlar inte om hur man implementerar programvaran.)
Låt oss ta en airspeed-indikator (ASI) som ett exempel. I en "ångmätare" ASI, lägger nålarna lite tröghet mot instrumentet, vilket begränsar den maximala förändringshastigheten som den kan visa. Detta är OK, eftersom den faktiska angivna flyghastigheten (IAS) har en mycket mindre maximal förändringshastighet i den verkliga världen.
I en "rörlig tejp" ASI på en primärflygdisplay (PFD) mottar en programkomponent uppdateringar av IAS och ändras visningen på lämpligt sätt. Instrumentets mänskliga läsbarhet beror på att förändringarna är gradvisa, så siffrorna gradvis "vindar runt" som ett fysiskt instrument: om siffrorna plötsligt hoppa, är det svårt för piloten att märka och förstå vad som har hänt.
Under normala omständigheter kan ett brått hopp i IAS (eller höjd, rubrik eller andra viktiga flygparametrar) inte uppstå, eftersom det finns fysiska gränser för förändringshastigheten. Men programkomponenten mottar bara en ström av värden, och det är möjligt att ett fel på annat håll i systemet kan orsaka ett brått hopp.
Är det vanligtvis ett krav på denna programkomponent att släta ut instrumentdisplayen eller hantera denna möjliga situation? Jag kan föreställa mig några möjliga sätt att hantera det:
Skärmkomponenten har en gräns som är inställd på förändringshastigheten (styrd av de fysiska begränsningarna och HF-gränsen för hur snabbt en förändring kan visas förståeligt) och den måste avvisa förändringar utan förändringar ( antagligen bunden till ett EFIS / ECAM-meddelande). När ändringarna ligger inom intervallet uppdateras displayen omedelbart utan interpolering.
Skärmkomponenten måste interpolera mellan mottagna värden genom att animera, så att även plötsliga ändringar tycks vara "vind" av instrumentet. Detta bevarar instrumentets läsbarhet men kommer att introducera viss latens i de visade värdena.
Skärmkomponenten har inget speciellt krav, och skyddet på andra ställen i systemet säkerställer att det aldrig behöver hantera unifysibla ändringar.
Jag förstår att krav per komponent sannolikt inte kommer att publiceras av någon leverantör, så jag är glad att ta ett unsourced svar om det stöds av personlig erfarenhet. Till och med information från en erfaren glas-cockpit pilot som har sett denna förstahandshandbok förstårs.
Generellt kommer PFD att jämna upp indikationen för de flesta angivna data.
Jag känner inte till några "lagliga" krav för det, men som du nämner kräver det grundläggande ergonomi det.
Jag har erfarenhet av första hand med Garmin G1000, så jag ska försöka förklara dess PFD-beteende som ett exempel. (Det är lite svårt att fånga och skicka en video).
De flesta (om inte alla) "grafiska" indikationer filtreras med frekvensen (karakteristisk frekvens) i överensstämmelse med den förväntade förändringshastigheten för den relevanta parametern: snabbt / snabbt (men fortfarande märkbart ca 0,3 s), lufthastigheten måttligt , motortemperatur långsamt (3-5 s). Digitala indikationer (t.ex. batterispänning) filtreras också, och dessutom är deras precision begränsad så att uppdateringarna inte hänt för ofta (t ex runt 0,5 V).
Filtret verkar vara ett andra-order lågpass i de flesta fall. För vissa parametrar, i synnerhet den angivna lufthastigheten, är den underdampad, vilket innebär att indikationen överskrids något för abrupta förändringar och brukar tenderar att oscillera fram och tillbaka för normala förändringar. Detta ger snabbare svar medan du fortfarande är smidig.
En abrupt, orealistisk förändring av parametrar i sig orsakar inte ett fel för PFD. Det filtreras bara som vanligt. Men betydligt out of range-värden misslyckas indikationen, men endast tillfälligt, tills förnuftiga värden återupptas. Det är i allmänhet jobbet hos perifera datorer (ADC, AHRS, etc.) samt integrationsenheten (GIA) för att upptäcka fel och förmedla dem i speciella meddelanden. PFD är ju bara en bildskärm.
Läs andra frågor om taggar aircraft-design avionics human-factors software glass-cockpit Kärlek och kompatibilitet Skor Gear 12 Stjärntecken Grunderna