¿Cuáles son los desafíos actuales en la ingeniería de software para aviónica? [cerrado]

Como otros han mencionado, hay muchos aspectos específicos de la aviación en el proceso de desarrollo de software de aviónica. La mayoría de estos se dividen en dos categorías principales; funcional y certificación.

Funcionalmente, tiene que realizar su función prevista de forma fiable y segura. Para hacerlo, debe desarrollarse a un nivel de garantía de diseño (DAL) acorde con la criticidad de la función del software. Existen estándares de procesos que todas las empresas siguen al crear sus procesos internos.

Los estándares clave son:

• DO-178C, Consideraciones de software en la certificación de equipos y sistemas aerotransportados
• ARP4754A, Directrices para el desarrollo de aeronaves y sistemas civiles
• ARP4761, Directrices y métodos para llevar a cabo el proceso de evaluación de la seguridad en sistemas y equipos aerotransportados civiles

Y está la función real del software y las realidades del mercado de la aviación. La mayor parte del software es código incrustado en tiempo real y tiene interfaces únicas para varios hardware. Y luego está el hecho de que la vida útil promedio de un avión es de 20 años o más y requiere soporte continuo.

La segunda parte, la certificación, se reduce a demostrarle a la autoridad de certificación que su software cumple con todos los requisitos y es seguro. Eso se reduce principalmente a requisitos de trazabilidad, pruebas y documentación.

Todo eso es un trabajo desafiante, pero si bien ha evolucionado a lo largo de los años, el proceso realmente no ha cambiado mucho en los últimos 25 a 30 años. Las empresas de aviónica saben cómo hacer esto y los nuevos empleados aprenden el proceso cuando se incorporan. Lo que ha cambiado son las herramientas y las plataformas de hardware y las expectativas de los fabricantes de aeronaves.

Uno de los mayores desafíos es lidiar con la obsolescencia del hardware. El ciclo de vida de muchos procesadores es de unos pocos años en el mejor de los casos. Y a medida que se han vuelto más complejos, surgen preguntas sobre el DAL del hardware que dieron como resultado RTCA DO-254 / EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware., el equivalente en hardware de DO-178C. El problema es que la mayoría de los fabricantes de procesadores no tienen interés en nada de esto, ya que la aviación es un porcentaje trivial de su mercado. Por lo tanto, los diseñadores de aviónica recurren a múltiples procesadores diferentes con verificación cruzada, lo que agrega más gastos generales y complejidad al software. Algunos han comenzado a diseñar sus propios procesadores para abordar el DAL, pero incluso eso no resuelve el problema del ciclo de vida, ya que generalmente dependen de una fábrica de chips externa y los cambios tecnológicos hacen que la fábrica declare el proceso obsoleto.

Entonces, ¿cuáles son los verdaderos desafíos actuales? Los fabricantes de aeronaves quieren menor SWaP-C: tamaño, peso, potencia y costo. Los tres primeros son hardware. Eso se está abordando mediante una mayor integración y aviónica modular integrada (IMA). Eso, a su vez, afecta el software ya que ahora su software tiene que ejecutar hardware que usted no controla. Puede desarrollarlo en una plataforma de desarrollo y luego integrarlo en la aeronave. Ref: DO-297, Guía de desarrollo y consideraciones de certificación de aviónica modular integrada (IMA) . Y si desea venderlo a más de un fabricante, es posible que deba ejecutarse en un hardware diferente. La clave para la mayoría de estos es el sistema operativo de la plataforma IMA que permite que el software funcional sea (en su mayoría) independiente del hardware.

Durante los últimos 5 años, el mayor desafío para el software de aviónica ha sido reducir costos. No solo el costo de desarrollo, sino también el costo de integración y el costo de cambiar el software en el futuro. Cuando el fabricante solicita una nueva característica y usted la agrega al software, debe seguir ese proceso nuevamente. Eso puede volverse costoso muy rápido. Para reducir los costos, se necesita una arquitectura de software bien diseñada que permita un diseño modular y capacidades de prueba en los límites del módulo para limitar el impacto del cambio.

No tengo experiencia en aviónica, pero tengo algo de experiencia en medicina y los principios son similares.

En mi no muy humilde opinión, los principales desafíos son el papeleo, papeleo y más papeleo y tener que vivir con una tecnología que tiene 30 años o el horror total de la usabilidad, porque no es objetivamente más seguro, pero pasa que tiene el papeleo hecho. .

Para los sistemas críticos de seguridad, de cualquier tipo, no solo de software, se requiere que se realice un análisis de riesgos y que el sistema se diseñe e implemente de modo que la estimación calificada del tiempo medio entre fallas críticas (= fallas que resultan en un accidente) sea menor que algún valor. Para los sistemas que pueden matar a varias personas, el requisito suele ser de 10⁹ horas.

Esa estimación involucra todo tipo de fallas, tanto de software como de hardware, y en todas las partes del sistema. Los componentes (tanto software como hardware) se prueban para obtener cierta confiabilidad básica para ellos, y luego se deben proporcionar controles y copias de seguridad para que cualquier tipo de falla en particular, que casi siempre es más probable que una vez cada 10⁹ horas, no ocurra. resultar en un accidente, y la probabilidad combinada de suficientes fallas para causar una a la vez está por debajo del umbral deseado.

Ahora, para el software, eso significa que debe probarse exhaustivamente, lo cual está bien. Pero también se requiere que las herramientas involucradas en su construcción estén “validadas”. El propósito declarado es que sepa cuál es el riesgo de falla en la herramienta que crea una falla no detectada en el producto, lo cual es necesario para el análisis de riesgo general. Sin embargo:

• La forma en que lo he visto hacer en la práctica generalmente no entendió el punto por completo. Se crearon algunos requisitos y luego se probó la herramienta para demostrar que los cumple. Esto fue mucho trabajo, pero los requisitos que definen lo que se supone que debe hacer la herramienta, por ejemplo, para compilar la especificación del lenguaje, en realidad no dijeron nada sobre el riesgo de que la herramienta introduzca un error, por ejemplo, el compilador produce funciones diferentes. código en modo de depuración y lanzamiento, ni el riesgo de que se vuelva crítico, si prueba lo que vuela y vuela lo que prueba, no crea ninguna compilación diferente que pueda tener una diferencia.

• Debido a la cantidad de trabajo involucrado, significa que a menudo se queda atrapado con un compilador especial que solo es compatible con el estándar antiguo (como C89), tiene muchas limitaciones conocidas y viene con su propio IDE feo y terrible, solo porque el proveedor hizo la validación. mientras que a las herramientas generales les guste gcco clangno lo tengan. Ahora, tenga en cuenta que la validación solo tiene sentido en el contexto del proyecto específico, por lo que es posible que todo ese papeleo no mejore realmente la confiabilidad del producto, solo sirve como un importante escudo de responsabilidad para la empresa.

Afortunadamente, el código en sí tiende a ser bastante simple. Cualquier cosa que debería ser en tiempo real, es decir, tener un tiempo de respuesta garantizado, que es el caso de la mayoría de la aviónica, no puede ser demasiado complejo, porque no se puede verificar que no tenga los peores casos lentos.

Entonces, específicamente para la ingeniería de software, diría que el desafío actual es que los procesos circundantes brindan rendimientos decrecientes en confiabilidad mientras aumentan la barrera para la innovación.

El desarrollo de software para aviónica se considera un campo especializado con respecto al requisito de conocimiento de las habilidades de los sistemas integrados, el manejo de protocolos de comunicación entre sistemas de aviónica y el cumplimiento de los estándares industriales apropiados. Ninguna de estas cosas es particularmente difícil, pero las habilidades y el conocimiento generalmente se acumulan durante un período de tiempo en la carrera de uno.

Comprender el desarrollo de sistemas integrados es fundamental porque, si un dispositivo puede estar utilizando un sistema operativo, algún hardware de aviónica está programado como una "máquina desnuda". En este sentido, no obtiene ayuda de los controladores de dispositivos, sistemas de archivos u otros servicios de tipo OS. Por otro lado, es probable que existan bibliotecas de códigos que se pueden usar para acceder a ciertas partes del sistema integrado, por lo que solo necesita comprender la API.

Comprender las comunicaciones entre dispositivos es importante porque diferentes dispositivos intercambian información utilizando varios tipos de protocolos. El ejército en particular usa MIL-STD-1553 o ARINC 429 como estándares. Algunos de estos se traducen en equipos comerciales.

Finalmente, si está desarrollando software para la industria comercial, TODO el software debe adherirse y cumplir con el estándar DO-178B . Cuando la FAA certifica una pieza de equipo, la prueba es muy exhaustiva e incluye revisiones de las certificaciones DO-178B para la organización.

Los elementos clave que diferencian el software del sistema de vuelo de otros tipos de software menos especializados son: seguridad funcional, tiempo real, determinismo, SOTIF (seguridad de la función prevista). De estos se derivan: arquitecturas de seguridad funcional, programación concurrente, metodologías de análisis y diseño, metodologías de desarrollo, estándares de codificación, metodologías de prueba, etc. sistemas, controladores, middleware, servicios del sistema y programas de vuelo, interfaces de usuario, etc. En cada uno de los cuales uno podría pasar toda su carrera. Además, a medida que uno avanza en la cadena de software desde, en algunos casos, probador, codificador, desarrollador, diseñador , arquitecto, ingeniero de sistemas, arquitecto de sistemas, responsable de seguridad funcional, arquitecto jefe... las consideraciones cambian drásticamente. Un programador sigue un proceso prescrito, estándares de codificación prescritos, metodologías de prueba prescritas, etc., y puede no estar al tanto del razonamiento detrás de algunas de las decisiones de diseño que toman los arquitectos e ingenieros de sistemas.
A mi modo de ver, el área donde la innovación podría tener el mayor impacto es en los enfoques adoptados para satisfacer la seguridad funcional y SOTIF. Este es el mayor factor de costo, ya que genera la necesidad de certificar el hardware y los sistemas operativos, así como un aumento significativo en el costo por línea de código, los costos de FMEA, FMEDA o los multiplicadores de costos del programa, como arquitecturas triplemente redundantes con programación de versión N. .

Recomiendo encarecidamente un título en Seguridad Funcional. Esto puede llevarte lejos no solo en aviación, sino también en automoción, robótica industrial, etc. ¡
Y la paga tampoco está mal!