¿Preparado para la certificación? Aplicando requisitos de seguridad para tu UAS
La certificación de un UAS es un proceso de garantía de calidad aplicado por un tercero -la autoridad certificadora- que demuestra que el sistema de tu aeronave cumple con las especificaciones de certificación. La mayoría de estas especificaciones y requisitos se centran en la seguridad. Especialmente hablando de sistemas y equipos. En esta publicación, abordaré los diferentes puntos a tener en cuenta para saber cómo llevar a cabo el proceso de certificación de la manera más eficiente.
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.
AUTHOR
