La Administración Federal de Aviación (FAA) estadounidense y la Agencia Europea de Seguridad Aérea (EASA) ofrecen orientación por medio de estándares, como ARP-4754 para los sistemas de aeronaves y DO-178B para el software de vuelo.
Estos estándares a menudo se emplean fuera del sector de la aviación civil, para aplicaciones de todo tipo, tales como vehículos militares aéreos y terrestres. La adopción de programas de UAV (vehículos aéreos no tripulados) está experimentando un rápido crecimiento debido a que la FAA ha decidido exigir las certificaciones UAS y OPA por medio de su orden 8130.34A. Los sistemas de UAV son heterogéneos y no se restringen únicamente al software de vuelo. Así pues, se emplean otros estándares, como DO-254 para el hardware y DO-278 para el software terrestre y espacial.
Sin embargo, estos estándares tienen más de una década de antigüedad y se están quedando obsoletos. Por ejemplo, carecen de orientación con respecto a prácticas modernas de desarrollo y verificación, como el diseño basado en modelos, las tecnologías orientadas a objetos y los métodos formales (al menos hasta que se desarrolló el incipiente estándar DO-178C). Por este motivo, la FAA y la EASA han trabajado con fabricantes aeronáuticos, proveedores y diseñadores de herramientas, incluído MathWorks, para actualizar los estándares utilizando tecnologías modernas. En lugar de modificar de forma significativa los estándares, han creado documentos suplementarios de tecnología.
El impacto de los nuevos estándares en los desarrolladores de UAVs que se sirven del diseño basado en modelos es especialmente importante. Con el diseño basado en modelos, los ingenieros de UAVs desarrollan y simulan modelos de sistemas que incluyen hardware y software empleando diagramas de bloques y diagramas de estado, como se muestra en las figuras 1 y 2. A continuación generan, implementan y comprueban automáticamente el código en sus sistemas embebidos. Con lenguajes de cálculo textual y herramientas de modelado de diagrama de bloques se puede generar código en los lenguajes C, C++, Verilog y VHDL, lo que hace posible la implementación en hardware MCU, DSP, FPGA y ASIC. Esto permite que los ingenieros de sistemas, software y hardware colaboren entre sí utilizando las mismas herramientas e idéntico entorno a fin de desarrollar, implementar y comprobar los sistemas.
La realización de pruebas de los sistemas reales de UAVs mediante pruebas de vuelo controlado desde tierra tiene unos costes elevados. Es mejor realizar pruebas anticipadas en el proceso de diseño mediante simulación por ordenador y bancos de pruebas en laboratorio. Con el diseño basado en modelos, la verificación da comienzo en cuanto se crean los modelos y se simulan por primera vez. Un flujo de trabajo de verificación habitual es reutilizar las pruebas de simulación a través del diseño basado en modelos como las transiciones de modelos (del modelo de sistema al modelo de software, al código fuente y, finalmente, al código objeto ejecutable) sirviéndose de generadores de código y compiladores cruzados.
Un enfoque de pruebas basadas en requisitos con reutilización de pruebas para los modelos y el código aparece explícitamente descrito en ARP-4754A, DO-178C y DO-331, el suplemento del diseño basado en modelos. ARP-4754A detalla todo el ciclo de desarrollo de aeronaves, desde los requisitos hasta la integración, pasando por la verificación, para tres niveles de abstracción: aeronave, sistemas y elementos (que pueden ser hardware o software).
El hecho de que ARP-4754A detalle la asignación de los requisitos del sistema para los componentes de hardware y software es muy importante para los desarrolladores de UAV, especialmente para los proveedores. Algunos proveedores pueden haber señalado que el desarrollo de subsistemas de UAV estaba fuera del ámbito del ARP-4754 original, incluso en el caso de subsistemas complejos que incluyen hardware y software, pero ya no es el caso. Dado el elevado nivel de acoplamiento entre sistemas, hardware y software para los vehículos UAV, resulta útil que los estándares que rigen el sector clarifiquen ahora las relaciones entre los sistemas y los subsistemas de hardware y software.
No es de extrañar que uno de los primeros cambios introducidos en DO-178C sea una mención explícita de ARP-4754A en la Sección 2: Aspectos del sistema relacionados con el desarrollo de software, para alinear aún más los estándares. Dejando a un lado las actualizaciones aclaratorias, DO-178C no se diferencia notablemente de DO-178B, al menos a primera vista. En otras palabras, los grandes cambios del estándar aparecen recogidos en los documentos suplementarios, como RTCA DO-331, Suplemento de desarrollo y verificación basados en modelos para DO-178C y DO-278A.
ARP-4754A recomienda el uso del modelado y la simulación para varias actividades integrales de los procesos en las que participan la captura y la validación de requisitos. ARP-4754A proporciona información más detallada y especifica que un modelo de entorno representativo, como el modelo de planta que se muestra en la figura 1, es una parte esencial de un modelo de sistema.
En ARP-4754A también se especifica que se puede utilizar una representación gráfica o un modelo para capturar los requisitos del sistema. El estándar ahora indica que se puede reutilizar un modelo para el diseño de software y hardware. Si se utilizan modelos para capturar los requisitos, ARP-4754A recomienda tener en cuenta lo siguiente:
– Identificar el uso tanto de los modelos como del modelado
– Identificar las herramientas previstas y su uso durante el desarrollo
– Definir los estándares y las librerías de modelado.
Con el diseño basado en modelos, son posibles funciones de verificación adicionales más allá de las pruebas de simulación. Entre ellas se cuentan el seguimiento de los requisitos para eliminar las revisiones del código fuente, la comprobación de los estándares de modelos, la comprobación automatizada de la equivalencia estructural de modelo a código, las pruebas PIL (processor-in-the-loop) y el análisis de robustez mediante métodos formales.
Un problema que viene de lejos con el estándar DO-178B para los profesionales del diseño basado en modelos es la incertidumbre que existe en la asignación de los objetivos de DO-178B a los artefactos del diseño basado en modelos. Resolver esta asignación fue una de las metas principales del subgrupo DO-178C (SG-4), centrado en el diseño basado en modelos. Una sola asignación no fue suficiente, así que se incluyeron varias asignaciones en DO-331. Algunas aportan el concepto de un modelo de especificación, que es un modelo distinto del que se utiliza para el diseño y la generación de código. Otras aportan el concepto de un modelo de diseño, que sirve como los requisitos detallados que se utilizan para generar el código.
La esencia de un modelo de diseño es la siguiente: Un modelo se puede usar para el diseño (del sistema y del software) y se debe desarrollar empleando requisitos externos al modelo (es decir, una base de datos textual de documentos o requisitos).
El código fuente se puede generar directamente a partir del modelo de diseño (forma manual o automática).
DO-331 tiene mucho más que ofrecer aparte de lo descrito anteriormente. Un enfoque que se especifica en este estándar es que un modelo usado inicialmente para el diseño de sistemas se puede elaborar y reutilizar para el diseño de software y la generación de código. Esto vincula los estándares ARP-4754 y DO-178C de un modo muy satisfactorio para los desarrolladores de sistemas y software de UAV que se sirven del diseño basado en modelos.
Aunque no se hayan recomendado para ninguna asignación concreta, la utilización y reutilización de los modelos para el diseño de sistemas y software, así como para la generación de código, han proporcionado unos procesos agilizados desde hace tiempo a los desarrolladores de sistemas de UAV que usan productos de MathWorks. Es agradable ver que este mismo enfoque se reconoce ahora claramente como un medio aceptable para la certificación por parte de los estándares que rigen el sector. MathWorks proporciona kits de calificación de herramientas de verificación, así como orientación de flujo de trabajo, con respecto al uso del diseño basado en modelos para los estándares DO-178C y DO-331.
*Tom Erkkinen, director de Certificaciones y Aplicaciones Embebidas de MathWorks.