La colaboración entre Abionica y Hionos logra dar soporte a sus clientes en todo el ciclo de vida de los proyectos de UAS y cubre las necesidades específicas de desarrollo de sistemas críticos para la seguridad, tanto a alto como bajo nivel, respectivamente. Estos servicios ofrecen al cliente una propuesta de valor único que garantiza la optimización de recursos y tiempos, la fiabilidad de las soluciones propuestas y el éxito del proyecto.

Abionica Solutions es una empresa de ingeniería con experiencia probada en ingeniería de sistemas, aviónica y certificación de UAS en la industria de UAVs. Abionica tiene una visión internacional y ha trabajado en proyectos a gran escala, como TARGUS OPV, el dron más grande en obtener la Certificación de Aeronavegabilidad en España. Debido a su experiencia y know-how, la empresa española brindará servicios durante las fases de definición y diseño de sistemas, y soporte de certificación para sus clientes de UAS.

Hionos es una empresa francesa que reúne a ingenieros de software crítico para seguridad con sólida experiencia en el desarrollo de software DO-178C, para la industria de aviónica y drones. Hionos desarrolla soluciones de software altamente confiables para drones. En este contexto, Hionos trabajará con el cliente durante las fases de creación de prototipos; y mientras el proyecto lo requiera, compartirán su marco de Pulsar Factory con Abionica para integrarlo en el proceso de desarrollo de UAS. Pulsar Factory es una solución que permite al fabricante personalizar el piloto automático certificado Hionos (Pulsar) para integrar fácilmente modelos específicos, como las leyes de control y mando del dron dedicado, para realizar prototipos rápidos y pruebas de vuelo.

Abionica e Hionos unen fuerzas para trabajar juntos en los siguientes segmentos: aviónica de aviación general, conversiones tripuladas a no tripuladas, vehículos aéreos no tripulados de categoría certificada y taxis aéreos en el contexto de la movilidad aérea urbana. Ambas empresas comparten capacidades para participar en el desarrollo de sistemas de aviónica críticos para los sectores de la aviación no tripulada.

Esta es la primera publicación de una serie centrada en abordar los requisitos de seguridad en el desarrollo del proyecto de UAS, desde la perspectiva de la planificación, la organización del diseño y el producto.

El plan de certificación y la comprensión de los requisitos de seguridad

El proceso de certificación de una aeronave tripulada es la mayoría de las veces un proceso comúnmente conocido por las autoridades de aviación y las especificaciones normalmente son claras; dado que la aplicación de una aeronave tripulada ya es bien conocida. Sin embargo, ¿qué sucede cuando nos adentramos en el elegante mundo de los aviones no tripulados? Bueno, las cosas cambian drásticamente, cada concepto de operación es diferente del resto, las especificaciones de la plataforma son extremadamente específicas y podemos encontrar muchas configuraciones innovadoras de aeronaves, desde VTOL hasta eléctricas e híbridas.

En mi opinión, la mejor forma de reducir la cantidad de sistemas complejos y redundantes que habrá que instalar en la plataforma es a través de un buen plan de certificación aprobado. En el plan de certificación se establecen y justifican las especificaciones que el sistema deberá cumplir. Por lo tanto, si somos capaces de simplificar el nivel de complejidad y las demandas en el plan de certificación, el desarrollo del proyecto será de menor coste y nuestro producto más competitivo.

Siempre hay una sección en las especificaciones de certificación sobre la confiabilidad de los sistemas. En la aviación tripulada se encuentra comúnmente en la sección 1309. Puede consultar el documento JARUS como referencia (JARUS AMC 1309). En esta sección, cada fallo funcional de su UAV está relacionada con cierta «criticidad» y probabilidad de evento. Por ejemplo, se solicita que ocurran eventos catastróficos con una probabilidad extremadamente baja, dado su impacto. Cuanto mayor sea la criticidad del evento, menor será la probabilidad requerida.

Esto asigna a cada uno de los sistemas involucrados en el fallo de esa función una probabilidad de fallo, un nivel de garantía de desarrollo y, a veces, la necesidad de evitar fallo simple. En resumen, se tendrá un conjunto de requisitos de confiabilidad para la mayoría de los sistemas y equipos del UAS.

En los UAS de Categoría Certificada, la especificación de certificación asigna el nivel de garantía de desarrollo y los requisitos de arquitectura adicionales además de la probabilidad de fallo. El nivel de garantía de desarrollo o DAL se entiende como la aplicación de ciertos procesos y procedimientos al proceso de desarrollo, y la generación de documentación que demuestre que dicho nivel se ha alcanzado y que el artículo cumple con los requisitos del nivel sistema.

El estudio de seguridad

Una vez que tengamos los requisitos de seguridad del sistema, se tendrá que prever cómo el sistema y la arquitectura del sistema cumplirán con ellos. Para hacer ello, en el contexto aeroespacial normalmente se recomienda en el AMC / GM de las Especificaciones de Certificación el ARP4761 como la referencia principal a seguir, porque reúne el proceso completo y es ampliamente utilizado en la industria aeroespacial. Sin embargo, requiere un alto nivel de comprensión y experiencia de los diferentes estudios y métodos incluidos en el proceso para generar resultados valiosos.

Diseñar una arquitectura de sistema en el sector aeroespacial es mucho más que cubrir requisitos funcionales puros. Se trata de cumplir con las funciones, la disponibilidad y la seguridad. Cada uno de los elementos de su arquitectura es al menos parte de una función. En caso de que este elemento falle, y dependiendo de cómo falle, la función se perdería. Ahí es donde la criticidad de la función indica cómo es de necesario realizar mejoras de integridad adicionales a nivel del sistema.

Algunas de las herramientas utilizadas son el Functional Hazard Analysis y el Fault Tree Analysis. Ambas herramientas permiten identificar qué funciones tienen mayor criticidad en el sistema, por lo que su realización a nivel de elementos y componentes debe cumplir con los requisitos de seguridad. Luego se construye una arquitectura posible para el sistema y se asignan esas funciones a elementos y unidades. En esa etapa, se puede verificar si la arquitectura del sistema cumple con los requisitos de seguridad o no. Este es un proceso iterativo que requiere una comprensión profunda de las herramientas y las posibles arquitecturas del sistema, hasta alcanzar el nivel de seguridad deseado.

Después de compartir las implicaciones de la arquitectura del sistema en los requisitos de seguridad, se entiende lo importante que es tratar esta parte del desarrollo del proyecto con mucho cuidado. Estas actividades y decisiones tienen un gran impacto en los costos del sistema y el tiempo de desarrollo.

Gestión de requisitos y cumplimiento de seguridad

El proceso de gestión de requisitos es un proceso iterativo que va desde la identificación de requisitos de alto nivel hasta el nivel de elemento. Se utiliza el enfoque del modelo de desarrollo en V para realizar este proceso junto con la verificación y validación. Por lo tanto, ningún requisito queda sin cubrir.

He visto a muchas compañías trabajar centradas en los requisitos de seguridad, implementar las medidas requeridas y justificar su cumplimiento solo para las necesidades de seguridad, sin prestar especial atención a los requisitos funcionales. Eso puede permitirles demostrar que su sistema cumple con las especificaciones de certificación, pero la mayoría de las veces se convierte en un producto inseguro e inútil.

La razón de estas consecuencias es la siguiente: Cuando se cubre solo una parte de los requisitos del sistema en el proceso, muchas otras características dejan de ser relevantes y eso puede llevar a omitir la identificación de otros requisitos importantes. Es decir, capacidades adicionales que el producto debe tener para ser utilizable. Por ejemplo, una compañía que tenía como único objetivo la certificación de sus UAS de 70 kg no especifica la autonomía requerida de su avión. Terminan teniendo 20 minutos máximos de vuelo porque no podían transportar más de medio litro de gasolina.

En otros casos, se omiten los requisitos funcionales y, por lo tanto, no se revisa la integridad. Ocurre por ejemplo que en algunas maniobras que se requieren en la operación se omiten debido al foco sólo en la seguridad. De esta manera, se decide que el piloto realizará todas estas maniobras en una fase avanzada del proyecto debido a que los sistemas de abordo no pueda realizarlas automáticamente. Al final, esas maniobras resultan ser más críticas de lo esperado especialmente cuando se requieren tras casos de fallo, como la pérdida del enlace de comunicación. El resultado es que no se cumplieron con los requisitos de seguridad porque no se prestó atención a cubrir todas las capacidades requeridas de la aeronave de forma adecuada.

Garantía de calidad

Seguir el modelo en V es mucho más que ejecutar un proceso pesado de ingeniería de sistemas, es un proceso de garantía de calidad. ARP4754A establece las bases para realizar el proceso de garantía de diseño que hay detrás de los requisitos de seguridad y sus evidencias, pero no es nada sin un sistema de calidad.

He estado trabajando para organizaciones con procesos y planes de ingeniería de sistemas muy pesados ​​y basados ​​en documentación en papel. Sus proyectos involucran a cientos de ingenieros, adminstradores, pilotos y técnicos. Fueron certificados bajo ISO9001 e ISO9100, pero al final su sistema de calidad no se implementó adecuadamente, o sus recursos trabajando en calidad no fueron suficientes. Tenían las reglas y conocían los procesos, pero no los seguían. Siempre se implementaban cambios de manera incontrolada, o no se identificaban y registraban las no conformidades. Las consecuencias fuero que los recursos del proyecto se fueron agotando y el cronograma del proyecto se fue retrasando continuamente. Sin embargo, el principal problema que surgió es que les era imposible cumplir con sus especificaciones de certificación y requisitos de seguridad, por lo que tuvieron problemas a nivel producto que nunca llegaron a resolver.

Cumplir con las especificaciones de seguridad no difícil. El gran desafío es tener la organización adecuada para controlarlos.

Las herramientas adecuadas para los procesos

Las máquinas de escribir y los procedimientos en papel ya han pasado a la historia. Si deseas alcanzar el nivel de seguridad para tu UAS y los procesos de garantía de calidad en tu organización, es posible que tengas que pensar en alternativas para reducir los costos. Un enfoque tradicional basado en papel desperdiciaría muchos recursos en actividades burocráticas y repetitivas, contar con las herramientas adecuadas te ayudará a ahorrar mucho tiempo y dinero.

Existen herramientas de software con mayor o menor nivel de complejidad y capacidades. Pueden ayudarnos a administrar los requisitos del producto, la configuración del sistema o incluso a modelar el sistema antes de producirlo. No obstante, no pienses que definirán el proceso y procedimientos de desarrollo por ti. Una herramienta es una herramienta. Puede implementar el proceso o parte de él, pero el proceso debe haberse definido antes de configurar la herramienta.

En algunas organizaciones se deciden comprar costosas herramientas de gestión de requisitos sin definir el proceso para el control de configuración del proyecto. Los resultados son catastróficos: requisitos incontrolados y redundados, no validados o no derivados adecuadamente.

Por lo tanto, si deseamos implementar procesos que proporcionen el nivel de garantía de calidad requerido en las fases de diseño, primero hay que definir los procesos y luego elegir las herramientas que más nos convengan. Sin embargo, tratar de implementar esos procesos pesados ​​a la antigua usanza o con las herramientas equivocadas definitivamente reducirá el ritmo de trabajo.

Profesionales experimentados

La mayoría de los fabricantes de UAS que apuntan a aplicaciones industriales y civiles, y que ahora estarían bajo una categoría específica, han seguido un enfoque de UAS de aficionado o de consumo. Ese enfoque es excelente si desea desarrollar un demostrador a corto plazo. En cambio, los UAS certificados necesitan una estrategia a largo plazo con objetivos claros, incluso si desea aplicar filosofías ágiles o lean. Ahora, la nueva regulación ha cambiado las reglas, y en consecuencia estos fabricantes se encuentran lejos de lo que se requiere para un UAS en condiciones de aeronavegabilidad. Desafortunadamente, la brecha entre uno y otro es tan grande que la mayoría de las veces requiere una cultura y una mentalidad completamente diferentes.

Otro punto relevante es que los proyectos innovadores están llenos de decisiones y riesgos imprevistos. Ya sea que el problema venga de elegir una tecnología u otra, o implementar adecuadamente ciertos requisitos del sistema. El principal problema radica en el hecho de que un proyecto de desarrollo UAS certificado es algo por lo que muchas personas no han pasado antes. No importa si tu empresa está acostumbrada a la industria aeroespacial o si es tu primer UAS certificado.

Por tanto, si encuentra muchas incertidumbres a lo largo del proceso de desarrollo o sientes que la organización necesita cambios, involucrar a profesionales con experiencia en UAS certificados siempre es la mejor opción. Especialmente aquellos con una amplia visión del proyecto de desarrollo. Establecer el camino correcto para el desarrollo de tu producto asegurará el éxito en su certificación UAS y ahorrará esfuerzo.

En Abionica Solutions, llevamos más de una década trabajando en sistemas no tripulados. Proporcionamos soporte y servicios en la gestión de proyectos y supervisión de ingeniería de sistemas para apoyar a la organización de nuestros clientes en el diseño y certificación de sus productos.

• Abionica Solutions e Hionos empiezan a trabajar juntos en Certificación de UAV
• ¿Preparado para la certificación? Aplicando requisitos de seguridad para tu UAS
• Autopilotos certificables para UAVs, 5 cosas que deberías saber

Esta publicación se centra en resaltar todo aquello que debes conocer si tu UAV se califica como categoría especifica o certificada. Hasta ahora nadie se preocupaba por la certificación, principalmente porque no se habían publicado los estándares de certificación, y con realizar algunas pruebas funcionales era suficiente para la mayoría de autoridades nacionales y clientes. Las agencias de seguridad aérea nacionales e internaciones han dedicado mucho tiempo a elaborar protocolos razonables específicamente adaptados a este nuevo segmento. Mientras, ha habido regulaciones heterogéneas y varios niveles de permisos diferentes en todo el mundo. La mayoría de los fabricantes de UAVs de tamaño medio, utilizando equipos no safety-critical, han encontrado algunas pocas regiones en las que poder vender sus plataformas pilotadas. Pero finalmente, podemos ver la luz al final del túnel. Ahora conocemos las nuevas normativas y estándares que marcan el diseño, desarrollo, mantenimiento y operación de los UAS. Además, las autoridades nacionales las están estableciendo poco a poco.

Esto es lo que debes saber para seleccionar e integrar un Flight Control Sistema en tu UAS de categoría específica o certificada.

Primero, saber qué es lo que realmente necesitas

Aquí es donde principalmente han surgido muchas confusiones. Por ejemplo, he escuchado muchas veces que el «Autopiloto» debe de cumplir con las DO178C/DO254/DO160, y puede ser así, pero no es suficiente. Ello depende principalmente de la aplicación y del contexto de la operación. Por lo que la primera duda a resolver sería «¿qué es lo que realmente necesito?”. Para responder a esta pregunta debemos trabajar de antemano otras cuestiones, como el plan de certificación, los conceptos de la operación, la evaluación de riesgos de operación y la evaluación de seguridad del sistema. Solo teniendo esta información puedes conocer la arquitectura que necesitas, los requisitos de fiabilidad de las unidades involucradas y el Development Assurance Level de cada una de esas unidades, además de un conjunto de requisitos y funciones que se deben implementar en cada unidad. Solo una vez que tengamos esa información podemos identificar qué buscamos en un “Autopiloto”, al igual que en las otras unidades que pertenecen al Sistema de Control de Vuelo,

Encontrar al proveedor correcto de Autopilotos

Durante más de una década, los UAV han estado utilizando una computadora integrada que implementaba todas las funciones del sistema de control de vuelo, aparte de la fusión sensorial, las comunicaciones y la gestión de vehículos aéreos. Además, el SW de control de vuelo implementado no ha seguido ningún proceso de calidad que demostrara que es libre de errores, confiable y estable. De la noche a la mañana, algunos fabricantes ya afirman que están cumpliendo con los estándares de aviación que todo el mundo necesita. Averigüemos cuánta verdad hay en sus palabras:

1. ¿Tienen un sistema de calidad? Cabe esperar que los proveedores de sistemas de aviónica cumplan con al menos la ISO9001 o la ISO9100, dependiendo de quién fabrica su HW. De hecho, no necesitan ser certificados, pero la ISO9001 es mucho más barata de obtener que una DO178C DAL C y facilitaría la implementación de la DO178C.
2. ¿Tienen los procesos? El desarrollo de unidades electrónicas safety-critical en aviación requieren un mínimo de procedimientos, procesos y funciones, como son el control de configuración, la gestión de cambios, la gestión de requisitos, el plan de desarrollo de HW, el plan de desarrollo de SW… alineados con los estándares de aviación (ARP4754A) o similares. Esto no es simplemente para tener la certeza de la calidad del producto, sino también porque el Autopiloto debe estar personalizado para cada avión (siempre) y deben de seguirse todos esos procesos y documentarse. Debes revisarlos y auditarlos antes de comenzar a trabajar con ellos.
3. ¿Realmente tienen los data-pack de HW/SW? La calificación de SW y HW genera un conjunto de entregables que prueban el cumplimiento de los estándares y deben demostrarse ante las autoridades. Por lo tanto, se aconseja revisar los artefactos asociados de primera mano o pedirle a un especialista externo que revise si cumplen.
4. ¿Tienen el equipo? La calificación de HW y SW requiere un gran equipo dependiendo del Development Assurance Level implementado en la unidad. Algunos fabricantes prometen equipos certificables, mientras que ni siquiera tienen la base y el equipo necesario para justificar los mínimos.
5. Obsolescencia. Se debe conocer y garantizar la obsolescencia prevista para el equipo que se está comprando, ya que lo que se debería esperar es una durabilidad de al menos una década. Además, en el acuerdo, se debe garantizar el respaldo del sistema de por vida. Se debería de poder proporcionar al cliente un reemplazo cuando sea necesario.
6. Nunca se ajustan las leyes de control de vuelo directamente durante el vuelo. Si el proveedor promete ajustar las ganancias de su plataforma en vuelo, algo va mal. Si realmente cumplen con los procesos estándar, se debe garantizar la verificación de las leyes de control de vuelo que se van a implementar en su aeronave siempre antes de comenzar a volar. No es necesario proporcionarle al cliente los algoritmos o SW, sino generar la evidencia que demuestre el cumplimiento de los requisitos de calidad de vuelo. Obviamente, siempre se puede comenzar con un proyecto demostrador para diferentes propósitos, pero pensar en la certificación requiere un enfoque diferente.
7. ¿El autopiloto gestiona la carga útil y la misión? Las funciones que no son críticas para la seguridad, como codificar vídeo y cambiar el apuntamiento de la carga útil, no son funciones safety-critical. Si tienen estas funciones dentro de la misma caja, deberían poder explicar muy bien por qué un error en esa sección SW/HW no afectaría directamente a la parte safety-critical. Calificar esa sección de SW/HW es una pérdida de tiempo y dinero, y si la parte safety-critical y la parte no safety-critical están conectadas de alguna manera, es porque no se ha realizado una evaluación de seguridad adecuada del sistema.
8. ¿Puedes configurar el Autopiloto por tu cuenta? Si el proveedor te permite configurar las ganancias de control, los límites de la envolvente de vuelo o las limitaciones de operación, y escribir sus propios conductores… También debe de informarte de que la unidad y las calificaciones de SW se perderían a menos que tengas los procesos adecuados (DO178C) y generes los artefactos adicionales y cualifiques ese código por tu cuenta o ejecutes las pruebas de verificación y validación como complemento de la fase de verificación.
9. Cualificación ambiental. Los estándares MIL-STD-810G o DO160 se aplican ampliamente en aviación. Debes verificar si las condiciones ambientales cumplen con las condiciones requeridas para tu aeronave y si las pruebas de cualificación se han realizado realmente. Una cosa es lo que se dice y otra lo que realmente se ha probado.
10. Pruebas, pruebas y pruebas. El sistema que se está construyendo sufre varias etapas de verificación mientras se integra: prueba a nivel unidad, prueba a nivel de sistema, prueba a nivel de UAS… El plan de ensayos a nivel unidad (ATP/FAT) es parte de la información inicial que se debe solicitar evaluar el producto de tu proveedor. Debe observarse que el plan de prueba puede personalizarse para los requisitos de la aeronave y sistema, pero si están «cualificados» es porque ya han pasado por ese proceso para otro tipo de aeronave. Puedes solicitar esa documentación o parte de ella para una auditoría.
11. Ensayos ambientales iniciales o Environmental Stress Screening. Todas las unidades electrónicas pasan por ciertas pruebas específicas de ciclos de vibración y temperatura para descartar los problemas de fabricación y montaje que pueden reducir su probabilidad de fallo inicial por debajo de los niveles requeridos. También puede solicitarse para una revisión.

Aunque hayas podido sentirte identificado con situaciones en las que un potencial proveedor de autopilotos no haya sido totalmente honesto contigo, debes de saber que hay otros proveedores que están trabajando muy duro para proporcionar soluciones que serán certificables en el momento en que se publiquen las nuevas regulaciones.

Un Autopiloto no es un COTS y nunca debe de ser plug&play

Un Autopiloto es una solución personalizada para tu aeronave y las unidades que forman parte de ella. Nunca es una solución plug & play o COTS (Commercial Off The Shelf). Por lo que, si alguien te dice que funcionará de inmediato, no está siendo completamente honesto contigo. Además, la personalización implica identificar nuevos requisitos, realizar nuevas pruebas modificando código (como mínimo), y debe seguir los procesos para mantener el cumplimiento de DO178C.

A pesar de eso, hay proveedores que ofrecen una gran variedad de opciones de personalización, lo que reduce mucho el proceso, al final cada solución de control de vuelo es única (HW/SW) para cada diseño de aeronave.

Un Flight Control System certificable no es barato

En caso de que desee comprar su solución de control de vuelo y personalizarla, y luego integrarla, debe conocer cuáles son los costes de mercado. Debería de esperar que le den una cifra de 6 ceros para la categoría certificada y 5 ceros para una categoría específica. Hay detalles que pueden cambiar la cantidad total, pero al menos puedes identificar lo que se adecuaría a tus expectativas.

Dicho esto, seguir el enfoque correcto reducirá el coste general de desarrollo y evitará riesgos no deseados. Actualmente existen soluciones potenciales que pueden reducir mucho los costes de personalización e integración, pero esta vez desde un nivel de arquitectura. Entonces, si realmente desea mitigar el riesgo y el coste, puede buscar un ciclo de vida de proyecto iterativo-incremental mientras diseña su sistema de control de vuelo siguiendo un enfoque desde “arriba hacia abajo” en lugar de “de abajo hacia arriba”.

Integración, verificación y validación

Tendrás que lidiar con la integración, verificación y validación. Cuando se adquieren las diferentes unidades, el proceso de integración y verificación debe ejecutarse de forma controlada, realizando simulaciones de hardware in the loop para fines de verificación a nivel de sistema. Además, se deben realizar actividades de prueba en tierra y en vuelo para verificar y validar que el sistema se comporta correctamente. Especialmente en condiciones de fallo, modos degradados y contingencias. Todos estos procesos y capacidades responden al “Systems Engineering Master Plan» y al «Test and Evaluation Master Plan» que deben cumplir con los requisitos del estándar aeronáutico. Tú, el integrador de aeronaves, debe tener todos estos planes y procedimientos implementados antes de acercarse a las etapas finales de integración. Mientras tanto, si no eres DOA (Design Organization Approval), debes implementarlo en paralelo a tu proceso de certificación de UAV.

Como puedes ver, el punto de adquirir un «Autopiloto» certificable para un UAV no es tan sencillo como comprar algo que cumpla con DO178C y DO254, instalarlo y comenzar a volar. Es mucho más que eso, y no tener una visión global ciertamente te llevará a comprar piezas electrónicas costosas, que pese a todo no te permitirán certificar tu UAS. Puede que ni siquiera lo haga más seguro o confiable.

En Abionica Solutions, llevamos más de una década trabajando en soluciones de control de vuelo para UAVs pequeños y grandes. Brindamos soporte de diseño de ingeniería de sistemas, modelado y simulación, y leyes de control de vuelo para sistemas no tripulados, y ayudamos a nuestros clientes a encontrar los proveedores que más se ajustan a sus necesidades; especificando la personalización requerida; apoyando la integración y la verificación, y ayudando en el difícil camino hacia la certificación.

• Abionica Solutions e Hionos empiezan a trabajar juntos en Certificación de UAV
• ¿Preparado para la certificación? Aplicando requisitos de seguridad para tu UAS
• Autopilotos certificables para UAVs, 5 cosas que deberías saber