Esta pregunta trata sobre los requisitos de factores humanos en el diseño de componentes de software que muestran instrumentos en una pantalla de vuelo principal. (No se trata de cómo implementar el software).
Tomemos un indicador de velocidad aerodinámica (ASI) como ejemplo. En un ASI de "medidor de vapor", las agujas agregan algo de inercia al instrumento, lo que limita la tasa máxima de cambio que puede mostrar. Esto está bien, porque la velocidad aerodinámica indicada real (IAS) tiene una tasa máxima de cambio mucho menor en el mundo real.
En un ASI de "cinta móvil" en una pantalla de vuelo principal (PFD), un componente de software recibe actualizaciones de IAS y cambia la pantalla de manera apropiada. La legibilidad humana del instrumento depende de que los cambios sean graduales, por lo que los números se "enrollan" gradualmente como un instrumento físico: si los números saltan abruptamente, es difícil que el piloto se dé cuenta y comprenda lo que ha sucedido.
En circunstancias normales, no puede ocurrir un salto abrupto en IAS (o altitud, rumbo u otros parámetros de vuelo importantes), porque existen límites físicos en la tasa de cambio. Pero el componente de software solo recibe un flujo de valores, y es posible que un error en otra parte del sistema pueda causar un salto abrupto.
¿Existe típicamente un requisito en este componente de software para suavizar la visualización del instrumento o manejar esta posible situación? Puedo imaginar algunas formas posibles de tratarlo:
El componente de visualización tiene un límite establecido en la tasa de cambio (guiado por las limitaciones físicas y el límite de HF sobre qué tan rápido se puede mostrar un cambio de manera comprensible), y tiene que rechazar los cambios fuera de rango (presumiblemente vinculado a un EFIS/ mensaje ECAM). Cuando los cambios están dentro del rango, la pantalla se actualiza inmediatamente sin interpolación.
El componente de visualización tiene que interpolar entre los valores recibidos mediante la animación, de modo que incluso los cambios abruptos parezcan "dar cuerda" al instrumento. Esto preserva la legibilidad del instrumento pero introducirá cierta latencia en los valores mostrados.
El componente de visualización no tiene requisitos especiales, y las protecciones en otras partes del sistema aseguran que nunca tenga que lidiar con cambios bruscos no físicos.
Entiendo que es poco probable que ningún proveedor publique los requisitos por componente, por lo que me complace aceptar una respuesta sin fuente si está respaldada por experiencia personal. Incluso se agradecería la información de un piloto con experiencia en cabina de vidrio que haya visto este estado de error de primera mano.
Generalmente, PFD suavizará la indicación para la mayoría de los datos indicados.
No conozco ningún requisito 'legal' para ello, pero como mencionas, la ergonomía básica lo requiere.
Tengo experiencia de primera mano con Garmin G1000, así que intentaré explicar su comportamiento PFD a modo de ejemplo. (Es un poco difícil capturar y publicar un video).
La mayoría (si no todas) las indicaciones 'gráficas' se filtran con la tasa (frecuencia característica) consistente con la tasa de cambio esperada del parámetro relevante: cabeceo/alabeo rápido (pero aún notablemente, alrededor de 0,3 s), velocidad aerodinámica moderada, temperatura del motor lentamente (3-5 s). Las indicaciones solo digitales (por ejemplo, el voltaje de la batería) también se filtran y, además, su precisión está limitada de modo que las actualizaciones no ocurren con demasiada frecuencia (por ejemplo, alrededor de 0,5 V).
El filtro parece ser un paso bajo de segundo orden en la mayoría de los casos. Para algunos parámetros, en particular la velocidad aerodinámica indicada, está subamortiguada, lo que significa que la indicación se sobrepasa ligeramente para cambios abruptos y, en general, tiende a oscilar de un lado a otro para cambios normales. Esto proporciona una respuesta más rápida sin dejar de ser suave.
Un cambio de parámetros abrupto y poco realista per se no causa una falla para PFD. Simplemente se filtra como de costumbre. Sin embargo, los valores significativamente fuera de rango fallarán en la indicación, pero solo temporalmente, hasta que se reanuden los valores sensibles. Generalmente, es trabajo de las computadoras periféricas (ADC, AHRS, etc.), así como de la unidad de integración (GIA), detectar fallas y transmitirlas en mensajes especiales. PFD es, después de todo, solo una pantalla.
Capitán Reynolds
Pondlife
selectstriker2
selectstriker2
dan hulme
Vikki