Procesos de certificación para

software aeroespacial para la

seguridad crítica y de misión crítica

Oscar Daniel Bautista Quirós

Cesar Uribe Alcantar
Introducción

 La seguridad es una propiedad de un sistema/hardware, lo que quiere decir que no pondrá en peligro la vida
humana ni el medio ambiente
 Seguridad critica significa que la falla o el error podría causar un riesgo para la vida humana.
 Misión critica significa la perdida de capacidad que conduce a una posible reducción en la eficacia de la
misión.
Documentación necesaria

 Descripción del sistema/hardware

 Evidencia de competencia del personal involucrado en el desarrollo del software critico para la seguridad de cualquier actividad
 Especificación de los requisitos de seguridad
 Resultados del análisis de peligros y riesgos
 Detalles de las técnicas de reducción de riesgos empleadas
 Resultados del análisis de diseño que muestran que el diseño sel sistema cumple con todos los objetivos de seguridad
requeridos
 Estrategia de verificación y validación
 Resultados de todas las actividades de verificación y validación
 Registros de revisiones de seguridad
 Registros de las incidencias que se producen a lo largo de la vida del sistema
 Registros de todos los cambios en el sistema y justificación de su seguridad continua
ESTÁNDARES PARA SOFTWARE
AEROESPACIAL PARA LA SEGURIDAD
CRÍTICA

Los estándares no son más que la acumulación de lecciones aprendidas de proyectos anteriores, por lo que el
proceso de desarrollo de software mejora continuamente y los desarrolladores no cometen los mismos errores
una y otra vez. En un esfuerzo por producir software aeroespacial seguro, de calidad, más rápido y más barato,
se han escrito estándares que contienen las lecciones aprendidas en los proyectos de software aeroespacial.
 Hay 3 categorías en las que se dividen los estándares de seguridad crítica
1. Estándares de la NASA que incluyen estándares específicos del centro como las Políticas del Centro de Investigación
de Vuelo Dryden
2. RTCA DO-178B: utilizado por la FAA para regular el software aeroespacial comercial
3. MIL-STD 498: estándares militares
Estándares de la NASA

 Guía de la NASA para software crítico para la seguridad, NASA-GB-1740.13-96

 Estándar de uso de prueba para procesos de ciclo de vida de software de tecnología de la información -
Desarrollo de software, J-STD-016-1995
 Dryden Handbook Code X - Revisión de aeronavegabilidad y seguridad de vuelo, revisión independiente,
revisión de éxito de la misión, resumen técnico y lineamientos del mini resumen técnico DHB-X-001
Revisión D
 Política del Dryden Flight Research Center: revisión de preparación operativa de vuelo (ORR) y panel de
revisión de preparación operativa (ORRP), DCP-X-020 Revisión A
 Estándar de seguridad de software de la NASA NASA STD 8719.13ª
 NASA-GB-1740.13-96, Guía de la NASA para software crítico para la seguridad •
Estándares de la RTCA DO-178B

"Consideraciones de software en la certificación de sistemas y equipos aerotransportados" contiene una guía

para determinar que los aspectos de software de los sistemas y equipos aerotransportados cumplen con los
requisitos de certificación de aeronavegabilidad.
 Esta norma fue escrita en 1980, revisada en el 85 y nuevamente en el 92. Durante la revision del 92 se
comparo con los estándares de la ISA 9003 la cual se basa en las “Directrices para la Aplicación de ISO 9001
al Desarrollo, Suministro y Mantenimiento de Software”
Misión critica vs seguridad critica

 NASA Dryden denota el software como misión critica clase B y el de seguridad critica como clase A.
 La falla del software de Clase B podría resultar en la incapacidad de recopilar datos para un proyecto de
investigación, pero el piloto podría volar y aterrizar la aeronave de manera segura. La certificación sigue
siendo importante debido al alto costo de repetir las misiones en caso de que el software falle.
 La falla del software crítico para la seguridad de Clase A pondría en peligro a la aeronave y al piloto. Por lo
tanto, las pruebas involucradas en la certificación del software Clase A son más estrictas
Proceso de certificación de seguridad critica

 El solicitante se reúne con la autoridad de certificación para establecer la base o los criterios de certificación para la
aeronave o el motor
 El solicitante desarrolla un Plan para los Aspectos de Certificación de Software (PSAC) para cumplir con la base de
certificación. El PSAC incluye:
 Descripción general del sistema
 Funciones del sistema y su asignación a la arquitectura de HW y SW
 Procesadores
 Interfaces de HW y SW
 Funciones de seguridad
 Descripción general del software que describe las funciones del SW con énfasis en los conceptos de seguridad y partición propuestos.
 Consideraciones de certificación
 Medios de cumplimiento
 Nivel de Software (AE)
 Resumen de la justificación proporcionada por el proceso de evaluación de la seguridad del sistema
 Sección del ciclo de vida del software que contiene una descripción del software en referencia a los respectivos planes
de software detallados y un resumen que explica como se cumplirán los objetivos de cada proceso
 Los datos mínimos del ciclo de vida del software que se pueden presetar a la autoridad de certificación son:
 PSAC
 Indice de configuración de software(SCI)
 Resumen de logros de SW(SAS)
 Casos y procedimientos de verificación de SW
 Sección de datos del ciclo de vida del software que incluye una descripción de cualquier dato que el SW produzca y
controle junto con la forma en los datos se relacionan entre si
 Calendario
 Consideraciones adicionales como calificación de herramientas, SW desarrollado previamente, SW COTS, etc.
 La autoridad de certificación evalua la integridad y consistencia del PSAC comparándolo con la base de
certificación
 La autoridad de certificación se asegura de que el nivel de SW propuesto es apropiado
 LA autoridad de certificación determina si la aeronave o el motor cumple con la base de certificación al
revisar el SAS y la evidencia de cumplimiento
Métodos alternativos

 Métodos formales implica el uso de lógica formal, matemáticas discretas y lenguaje legible por computadora
 Pruebas de entrada exhaustivas para situaciones en las que las entradas y salidas del software pueden
limitarse y probarse exhaustivamente
 Modelos de confiabilidad del software incluyendo métodos para estmiar las probabilidades posteriores a la
verificación de errores de SW.
 Historial de servicio del producto demostrar que el software tiene un historial de seguridad

 Nota: No se puede considerar un método alternativo aislado de los procesos de desarrollo de software. El
solicitante debe demostrar que el método alternativo satisface los objetivos de DO-178B.
Índice de configuración de software (SCI)

 El SCI identifica la configuración del software y debe identificar lo siguiente

 Producto de software
 Código objeto ejecutable
 Componentes del código fuente
 Software desarrollado previamente
 Datos de ciclo de vida del software
 Archivar y publicar medios
 Instrucciones para construir el código objeto ejecutable
 Referencia al índice de configuración del entorno del ciclo de vida del software: identifica el entorno en el que se
ejecutara el software
 Comprobaciones de integraciones de datos, si se utilizan
Otras
consideraciones para
la certificación de la
FAA
Proceso de
aprobación de
la FAA
Un proceso exitoso de la FAA
 1. Plan for Software Aspects of Certification (PSAC)
 2. Software Development Plan (SDP)
 3. Software Verification Plan (SVP)
 4. Software Configuration Management Plan (SCMP)
 5. Software Quality Assurance Plan (SQAP)
 6. Software Requirements Standards (SRS)
 7. Software Design Standards (SDS)
 8. Software Code Standards
 9. Software Requirements Data
 10. Design Description (SDD)
 11. Source Code
 12. Executable Object Code
 13. Software Verification Cases and Procedures
 14. Software Verification Results
 15. Software Life Cycle Environment Configuration Index
 16. Software Configuration Index (SCI)
 17. Problem Reports
 18. Software Configuration Management Records
 19. Software Quality Assurance Records
 20. Software Accomplishment Summary (SAS)
PROCESO DE
CERTIFICACIÓN
DEL CENTRO DE
INVESTIGACIÓN
DE VUELO DE
DRYDEN
PROCESO DE CERTIFICACIÓN DEL
CENTRO DE INVESTIGACIÓN DE VUELO
DE DRYDEN

El Presidente de la AFSRB puede tomar una de cuatro acciones posibles:

 Después de una revisión cuidadosa, si el Presidente considera que el software está en condiciones de volar,
puede certificarlo sin más revisión por parte de la Junta.
 El presidente puede convocar a un pequeño grupo de expertos de Dryden, independientes del proyecto, para
que lo ayuden a determinar si el proyecto propuesto está autorizado para el vuelo.
 El Presidente puede solicitar que los planes y la realización propuesta del proyecto se presenten a todo el
AFSR para su revisión.}
 El Presidente puede solicitar que los planes y la realización propuesta del proyecto sean presentados a la
ASFRB por la Revisión Independiente de DFRC (DIR).
Después de una cuidadosa revisión y consideración, la AFSRB toma una decisión de "continuar" o "no
continuar". Si el software recibe un "aceptar", entonces se certifica y se carga en la aeronave. Si el software
carece de algún aspecto y recibe una decisión de "no continuar", entonces vuelve al desarrollo para seguir
trabajando y el proceso de certificación comienza de nuevo.
PROCESO DE APROBACIÓN DEL
LABORATORIO DE PROPULSIÓN A JET

Jet Propulsion Lab está autorizado para desarrollar sistemas y software de misión crítica. En este momento, JPL
no desarrolla software crítico para la seguridad.
Procesos para evaluar y aprobar sistemas y software en cuatro niveles:
 Nivel A: se aplica a sistemas y software donde la falla podría resultar en la "pérdida de misión" definida
como la incapacidad para cumplir con los objetivos de la misión
 Nivel B: se aplica a los sistemas y software que respaldan el procesamiento de datos científicos, por ejemplo,
software de vuelo de naturaleza secundaria que está aislado donde la falla no produce efectos secundarios en
los sistemas de Nivel A.
 Niveles C y D: se aplica a otros tipos de sistemas y software donde las fallas se aíslan aún más y no
producen efectos secundarios en los sistemas de Nivel A o B
PROCESO DE
APROBACIÓN
DEL
LABORATORI
O DE
PROPULSIÓN
A JET