En las industrias más críticas se produce la paradoja de la innovación, es decir, que los avances tecnológicos se encuentran, a menudo, reñidos con la seguridad de los sistemas.
Así, por ejemplo, la importancia concedida a la seguridad de los pasajeros en el desarrollo de software embarcado (que viaja en los aviones) comporta grandes diferencias con respecto a otros desarrollos más usuales.
Pese a que pudiera parecer que se trata de empresas tecnológicamente punteras, los riesgos de un desarrollo en falso obligan a retrasar la introducción de novedades, pues son elementos que aún no han probado un histórico de funcionamiento estable y sin fallos.

Estándares de seguridad

La normativa civil que se aplica en el desarrollo es la DO-178, que actualmente va por la versión “C”.
Se trata de un documento escrito por la industria aeronáutica que provee de una serie de buenas prácticas para desarrollar software.
Según la criticidad de los sistemas, se encuentran sujetos a normas más o menos estrictas. No es lo mismo la unidad de control del motor de una turbina, de la que depende que el avión vuele, que la pantalla en la que se ven las películas. Los dos sistemas están contemplados en la normativa, pero no tienen la misma jerarquía.

¿Qué es un riesgo aceptable?

La certificación establece cinco niveles según el riesgo que sería asumible por cada tipo de sistema. Los sistemas más críticos, como el motor o el control de vuelo, no pueden fallar nunca (la tasa de fallos aceptable es de uno cada mil años si todos los aviones volasen constantemente). Pero también hay ciertos sistemas cuyos errores no suponen un riesgo para la vida, sino solo más trabajo para la tripulación.
Un fallo en el nivel “A” tendría consecuencias catastróficas y pondría en riesgo la vida de la tripulación y los pasajeros. Sistemas que entran en esta categoría son los controles de vuelo o del motor.
En el nivel “B”, pero principalmente habría heridos. Como ejemplo, cabe destacar las radios para comunicarse con el aeropuerto.
El nivel “C” comportaría más trabajo para la tripulación y heridos leves en caso de ocurrir alguna incidencia. Engloba sistemas redundantes, comunicaciones no necesarias, etc.
Los sistemas comprendidos en el nivel “D” no afectan a la seguridad (simplemente acarrearían una incomodidad para los pasajeros). Un ejemplo son las pantallas para ver películas.
Por último, los sistemas del nivel “E” no necesitan ser certificados, pues sus fallos no supondrían impacto alguno.

Las pruebas no pretenden mejorar el software, sino validarlo

La mayor dificultad de la certificación estriba en las pruebas, que no se llevan a cabo para mejorar los productos, sino para verificar que se han construido correctamente. En un desarrollo normal de software es normal realizar pruebas con usuario, de aceptación, etc. Sin embargo, aquí, en ciertos niveles se exige incluso analizar todas las líneas del código fuente.
El mayor riesgo es encontrar un defecto en pruebas que se haya producido al programar, porque supondría rehacer mucha documentación.
Así, el coste de la fase de pruebas puede llegar a ser cuatro o cinco veces el de desarrollo.
Además, es mucho más difícil aplicar metodologías ágiles pues se siguen modelos en cascada y por fases.

Tecnologías antiguas y seguras

De este modo, no es de extrañar que se usen procesadores antiguos, como PowerPC, debido a un histórico sin fallos.
También se usan buses de comunicaciones especiales (MilBus, EFABus, ARINC 429, AFDX, Ethernet, señales discretas, etc.).
En lugar de sistemas operativos como Windows, se hace uso de VxWorks e Integrity, que además están certificados.
En cuanto a los lenguajes de programación, suele usarse Ada, aunque cuesta mucho encontrar profesionales que lo conozcan y sepan usarlo. Se trata de un lenguaje encargado por Estados Unidos para el desarrollo de estos softwares críticos.

¿Te gustaría recibir nuestros próximos artículos?