El software de aviónica es un software integrado con requisitos de seguridad y fiabilidad exigidos por ley que se utiliza en aviónica . La principal diferencia entre el software de aviónica y el software integrado convencional es que el proceso de desarrollo es obligatorio por ley y está optimizado para la seguridad. Se afirma que el proceso descrito a continuación es solo un poco más lento y costoso (quizás un 15 por ciento) que los procesos ad hoc normales que se utilizan para el software comercial . Dado que la mayoría del software falla debido a errores, eliminar los errores en el primer paso posible también es una forma relativamente económica y fiable de producir software. Sin embargo, en algunos proyectos, es posible que los errores en las especificaciones no se detecten hasta la implementación. En ese momento, puede resultar muy costoso solucionarlos.
La idea básica de cualquier modelo de desarrollo de software es que cada paso del proceso de diseño tiene resultados denominados "entregables". [1] Si se prueba la corrección de los entregables y se corrigen, los errores humanos normales no pueden convertirse fácilmente en problemas peligrosos o costosos. La mayoría de los fabricantes [2] siguen el modelo en cascada para coordinar el producto de diseño, [3] pero casi todos permiten explícitamente que se revise el trabajo anterior. El resultado suele ser más cercano a un modelo en espiral .
Para obtener una descripción general del software integrado, consulte Sistemas integrados y modelos de desarrollo de software . El resto de este artículo presupone que el usuario está familiarizado con esa información y analiza las diferencias entre los sistemas integrados comerciales y los modelos de desarrollo comerciales.
Dado que la mayoría de los fabricantes de aviónica ven el software como una forma de agregar valor sin agregar peso, la importancia del software integrado en los sistemas de aviónica está aumentando.
La mayoría de los aviones comerciales modernos con piloto automático utilizan ordenadores de vuelo y los llamados sistemas de gestión de vuelo (FMS) que pueden hacer volar el avión sin la intervención activa del piloto durante ciertas fases del vuelo. También se encuentran en desarrollo o en producción vehículos no tripulados: misiles y drones que pueden despegar, volar y aterrizar sin la intervención del piloto en el aire.
En muchos de estos sistemas, los fallos son inaceptables. La fiabilidad del software que se ejecuta en los vehículos aéreos (civiles o militares) queda demostrada por el hecho de que la mayoría de los accidentes aéreos se producen debido a errores manuales. Por desgracia, un software fiable no es necesariamente fácil de usar ni intuitivo; el diseño deficiente de la interfaz de usuario ha contribuido a muchos accidentes y muertes en la industria aeroespacial. [ cita requerida ]
Debido a los requisitos de seguridad, la mayoría de los países regulan la aviónica o al menos adoptan normas que ya utiliza un grupo de aliados o una unión aduanera. Las tres organizaciones reguladoras que más afectan al desarrollo de la aviación internacional son Estados Unidos, la UE y Rusia.
En los EE. UU. , los componentes de aviónica y otros componentes de aeronaves tienen estándares de seguridad y confiabilidad establecidos por las Regulaciones Federales de Aviación, Parte 25 para Aviones de Transporte, Parte 23 para Aviones Pequeños y Partes 27 y 29 para Giroaviones. Estos estándares son aplicados por "representantes de ingeniería designados" de la FAA, quienes generalmente son pagados por un fabricante y certificados por la FAA.
En la Unión Europea, la IEC describe los requisitos "recomendados" para los sistemas críticos para la seguridad, que los gobiernos suelen adoptar sin modificaciones. Un componente de aviónica seguro y fiable tiene una "marca CE". El sistema normativo es notablemente similar al de la seguridad contra incendios en los EE. UU. y Canadá. El gobierno certifica los laboratorios de pruebas, y los laboratorios certifican tanto los artículos fabricados como las organizaciones. Básicamente, la supervisión de la ingeniería se externaliza del gobierno y el fabricante al laboratorio de pruebas.
Para garantizar la seguridad y la fiabilidad, las autoridades reguladoras nacionales (por ejemplo, la FAA , la CAA o el DOD ) exigen estándares de desarrollo de software. Algunos estándares representativos incluyen MIL-STD-2167 para sistemas militares o RTCA DO-178B y su sucesor DO-178C para aeronaves civiles.
Los requisitos reglamentarios para este software pueden ser costosos en comparación con otros software, pero normalmente son los mínimos necesarios para producir la seguridad necesaria.
La principal diferencia entre el software de aviónica y otros sistemas integrados es que los estándares reales suelen ser mucho más detallados y rigurosos que los estándares comerciales, que suelen describirse en documentos de cientos de páginas. Suele ejecutarse en un sistema operativo en tiempo real.
Dado que el proceso es un requisito legal, la mayoría de los procesos cuentan con documentos o software para rastrear los requisitos desde los párrafos numerados en las especificaciones y los diseños hasta los fragmentos exactos de código, con pruebas exactas para cada uno y un recuadro en la lista de verificación de certificación final. Esto es específicamente para demostrar la conformidad con la norma exigida por ley.
Pueden ocurrir desviaciones de un proyecto específico con respecto a los procesos aquí descritos debido al uso de métodos alternativos o requisitos de bajo nivel de seguridad.
Casi todos los estándares de desarrollo de software describen cómo ejecutar y mejorar las especificaciones, los diseños, la codificación y las pruebas (consulte el modelo de desarrollo de software ). Sin embargo, los estándares de desarrollo de software de aviónica agregan algunos pasos al desarrollo para la seguridad y la certificación:
Los proyectos con interfaces humanas importantes suelen ser prototipos o simulaciones. La cinta de vídeo suele conservarse, pero el prototipo se retira inmediatamente después de la prueba, porque de lo contrario la dirección y los clientes pueden creer que el sistema está completo. Un objetivo importante es encontrar problemas en las interfaces humanas que puedan afectar a la seguridad y la facilidad de uso.
La aviónica crítica para la seguridad suele contar con un análisis de riesgos . En las primeras etapas del proyecto, ya se tiene al menos una idea vaga de las partes principales del proyecto. Luego, un ingeniero toma cada bloque de un diagrama de bloques y considera las cosas que podrían salir mal con ese bloque y cómo afectan al sistema en su conjunto. Posteriormente, se estima la gravedad y la probabilidad de los riesgos. Luego, los problemas se convierten en requisitos que se incorporan a las especificaciones del diseño.
Los proyectos que involucran seguridad criptográfica militar generalmente incluyen un análisis de seguridad, utilizando métodos muy similares al análisis de riesgos.
Una vez que se completa la especificación de ingeniería, se puede comenzar a redactar el manual de mantenimiento. Un manual de mantenimiento es esencial para las reparaciones y, por supuesto, si el sistema no se puede reparar, no será seguro.
La mayoría de los estándares tienen varios niveles. Un producto de baja seguridad, como una unidad de entretenimiento a bordo (un televisor volador), puede no tener más que un esquema y procedimientos de instalación y ajuste. Un sistema de navegación, un piloto automático o un motor pueden tener miles de páginas de procedimientos, inspecciones e instrucciones de montaje. En la actualidad (2003) los documentos se entregan de forma rutinaria en CD-ROM, en formatos estándar que incluyen texto e imágenes.
Uno de los requisitos de documentación más extraños es que la mayoría de los contratos comerciales exigen una garantía de que la documentación del sistema estará disponible indefinidamente. El método comercial normal para proporcionar esta garantía es formar y financiar una pequeña fundación o fideicomiso. El fideicomiso luego mantiene un buzón y deposita copias (generalmente en ultrafichas ) en un lugar seguro, como un espacio alquilado en la biblioteca de una universidad (administrado como una colección especial) o (ahora menos frecuente) enterrado en una cueva o en un lugar desértico. [4]
Por lo general, son muy similares a los de otros modelos de desarrollo de software . Una diferencia fundamental es que los requisitos suelen trazarse como se describió anteriormente. En proyectos grandes, la trazabilidad de los requisitos es una tarea tan costosa que requiere programas informáticos grandes y costosos para gestionarla.
El código se escribe y, por lo general, lo revisa un programador (o un grupo de programadores, generalmente de forma independiente) que no lo escribió originalmente (otro requisito legal). Las organizaciones especiales también suelen realizar revisiones de código con una lista de verificación de posibles errores. Cuando se encuentra un nuevo tipo de error, se agrega a la lista de verificación y se corrige en todo el código.
El código también suele examinarse mediante programas especiales que analizan la corrección ( análisis estático de código ), como SPARK Examiner para SPARK (un subconjunto del lenguaje de programación Ada) o lint para la familia C de lenguajes de programación (principalmente C, aunque principalmente). Los compiladores o programas de verificación especiales como "lint" verifican si los tipos de datos son compatibles con las operaciones sobre ellos; también se utilizan regularmente estas herramientas para hacer cumplir el uso estricto de subconjuntos válidos de lenguajes de programación y estilos de programación. Otro conjunto de programas mide las métricas del software , para buscar partes del código que probablemente tengan errores. Todos los problemas se solucionan, o al menos se comprenden y se verifican dos veces.
Algunos códigos, como los filtros digitales , las interfaces gráficas de usuario y los sistemas de navegación inercial , se entienden tan bien que se han desarrollado herramientas de software para escribir el software. En estos casos, se desarrollan especificaciones y se produce automáticamente un software confiable.
El código de "prueba unitaria" se escribe para ejecutar cada instrucción del código al menos una vez para obtener una cobertura del código del 100 % . A menudo se utiliza una herramienta de "cobertura" para verificar que se ejecute cada instrucción y, luego, también se documenta la cobertura de la prueba por razones legales.
Esta prueba es una de las más potentes. Obliga a revisar detalladamente la lógica del programa y detecta la mayoría de los errores de codificación, compilación y diseño. Algunas organizaciones escriben las pruebas unitarias antes de escribir el código, utilizando el diseño del software como especificación del módulo. Se ejecuta el código de la prueba unitaria y se solucionan todos los problemas.
A medida que los fragmentos de código están disponibles, se agregan a un esqueleto de código y se prueban en el lugar para asegurarse de que cada interfaz funcione. Por lo general, las pruebas integradas de los componentes electrónicos deben finalizarse primero, para comenzar con las pruebas de quemado y de emisiones de radio de los componentes electrónicos.
A continuación, se integran las características más valiosas del software. Es muy conveniente para los integradores tener una forma de ejecutar pequeños fragmentos de código seleccionados, tal vez desde un sistema de menú simple.
Algunos administradores de programas intentan organizar este proceso de integración de modo que, después de alcanzar un nivel mínimo de funciones, el sistema pueda entregarse en cualquier fecha posterior, con un número cada vez mayor de funciones a medida que pasa el tiempo.
Mientras tanto, los ingenieros de pruebas suelen comenzar a ensamblar un equipo de prueba y a publicar pruebas preliminares para que las utilicen los ingenieros de software. En algún momento, las pruebas cubren todas las funciones de la especificación de ingeniería. En este punto, comienzan las pruebas de toda la unidad aviónica. El objetivo de las pruebas de aceptación es demostrar que la unidad es segura y confiable en su funcionamiento.
La primera prueba del software, y una de las más difíciles de cumplir en un cronograma ajustado, es una prueba realista de las emisiones de radio de la unidad. Por lo general, esto debe comenzar al principio del proyecto para garantizar que haya tiempo para realizar los cambios necesarios en el diseño de la electrónica. El software también se somete a un análisis de cobertura estructural, donde se ejecutan pruebas y se recopila y analiza la cobertura del código.
Cada paso produce un resultado, ya sea un documento, un código o un informe de pruebas. Cuando el software pasa todas las pruebas (o las suficientes para venderse de forma segura), estas se unen en un informe de certificación, que puede tener literalmente miles de páginas. El representante de ingeniería designado, que ha estado esforzándose por completarlo, decide entonces si el resultado es aceptable. Si lo es, lo firma y el software de aviónica queda certificado.