1 Seguridad en sistemas digitales embarcados
2 Concepto Certificación AeronáuticaCertificado de Tipo Funcionalidad, comportamiento, seguridad conforme a una Normativa Normativa de Certificación “casi común” CE / USA FAR 25 AC+Orders+ Special Condition CS AMC+GM+CRI Autoridad de Certificación FAA o EASA Certificación de organizaciones de diseño DOA / DOM Certificación de organizaciones de producción Certificación de organizaciones de mantenimiento
3 Proceso de Certificación y de aeronavegabilidad continuadaSolicitar iniciar un proceso de certificación de un nuevo tipo Acordar bases de Certificación Acordar un Plan de Certificación Generar evidencias (análisis, pruebas) Aprobación interna de las evidencias y manuales de operación y mantenimiento por los SCE / CVE Revisión por la autoridad de Certificación Emisión del certificado de tipo Certificado Suplementario para versiones Seguimiento incidentes / mejoras de diseño Boletines de Servicio Mantenimiento Programado
4 Ejemplos Sistemas Embarcados con SWAlgunos ejemplos de sistemas embarcados Sistemas de Control “Tail Boom” Reabastecimiento en Vuelo DAL A Sistema de Gestión de Misión A 400 Lanzamiento de Cargas DAL C
5 Requisitos genéricos para certificación en sistemas embarcadosRequisitos FAR AC A / CS características de seguridad comunes a todos los sistemas Conceptos Fallo Función / Efecto del Fallo Catalogación Efectos de Fallo en 4 niveles Catastrófico,Peligroso,Importante,Menor Protección contra fallo simple Objetivos Cuantitativos de Fiabilidad Medios de Cumplimiento aceptados Para sistemas basados en HW/SW: SAE ARP 4754 Establece el concepto DAL (Development Assurance Level) sistema Define requisitos de procesos en función DAL Requiere un proceso de análisis de seguridad : SAE ARP 4761 Invoca RTCA DO 178 B y RTCA DO 254 para HW y SW
6 Estructura ARP 4754 Cap 3 Define las características mas significativas de los sistemas integrados / complejos e introduce el concepto de DAL “development assurance level” Cap 4 Resume la organización y coordinación del proceso de certificación e identifica la documentación a generar para soportar la certificación. Cap 5 Describe el proceso para la identificación y clasificación de requisitos y para la asignación de los DAL a los elementos HW y SW del sistema en paralelo con el proceso de análisis de seguridad.
7 Estructura ARP 4754 Cap 6 Describe el proceso de análisis de seguridad que analiza los modos de fallo del sistema en función de la arquitectura y establece objetivos de seguridad cualitativos y cuantitativos para los elementos del sistema Cap 7 Describe el proceso de validación para garantizar la corrección y completitud de los requisitos y la adecuación de la implementación Del sistema al uso previsto Cap 8 Describe el procesos de Verificación que demuestra la correcta implementación de los requisitos en todos los productos intermedios Cap 9 Describe el procesos de gestión de configuración que define la identificación y el control de cambios al sistema y sus elementos. Cap 10 “Process Assurance” Describe la adecuación de los procesos anteriores al DAL asignado al sistema. Es equivalente a una función QA especializada en procesos ARP 4754.
8 Documentación de Certificación por cada sistemaDocumentación entregable Plan de Certificacion (4.4.1) Requisitos Arquitectura Planes de todos los procesos de “development assurance” Indice de Configuracion (4.4.2) FHA PSSA / SSA CCA Documentación de verificación Documentación de Validación Resumen de Certificacion Evidencias de “Process Assurance” Evidencias de Gestión de Configuración No hay requisitos de formato o de soporte. Es aceptable soporte electrónico
9 Plan de Certificacion 4.4.1 Descripción funcional operativa del sistema, arquitectura HW y SW, interfaces con el resto de sistemas y avión Resumen del FHA para las funciones relacionadas Resumen del PSSA , objetivos de seguridad de los elementos y DAL Nuevas tecnologías usadas Resumen de actividades de “process assurance” a realizar Documentación a generar / entregar Planificación de actividades en relación con certificación Personas de coordinación No hay requisitos de formato o de soporte. Es aceptable soporte electrónico
10 Análisis de Seguridad SAE ARP 4761Catalogo Funciones avión (ie control longitudinal) Análisis de Fallos función (HA) en distintos escenarios Catalogo de Fallos y Efectos (condiciones de Fallo) Catalogación condiciones de Fallo (catastrófico, peligroso, Importante, Menor) Asociación condiciones de Fallo función / sistemas contribuyentes Para cada condición de Fallo / Sistema contribuyente se desarrolla un árbol de fallos (FT) Asignación de objetivos de fiabilidad de componentes(subsistemas/equipos) del sistema. El SW no se considera en los análisis cuantitativos Realimentación con el diseño de arquitectura ; consideraciones de redundancia, monitorización, disimilaridad para eliminar el fallo simple y ajustar los objetivos cuantitativos de fiabilidad. Asignación del DAL a los componentes del sistema
11 Consideraciones sobre la asignacion del DALEl DAL del sistema junto con una serie de consideraciones en funcion de la arquitectura del sistema (redundancia, monitorizacion...) van a determinar el “DAL” de los elementos HW y SW. La asignación del DAL al sistema y a los elementos HW y SW se realiza durante la preparación del PSSA realizado de acuerdo a la ARP 4761. Los mecanismos de redundancia, monitorización... de acuerdo a los criterios de la tabla 5.2 y los párrafos a puede rebajar el DAL de un item.Esta “rebaja” debe estar justificado en el PSSA El DAL tiene un efecto importante en las actividades a realizar en función del DAL en los desarrollos HW (FPGA´s,PLD´s) y SW y que vienen reglamentadas por : RTCA DO 178 B / ED 12 B RTCA DO 254 / ED 80
12 Consideraciones sobre la asignacion del DALRedundancia de un elemento HW/SW Requerida para implementar el principio “fail safe” si la no disponibilidad de una función que implementa o a la que contribuye el elemento tiene una severidad catastrófica La redundancia puede implementarse como activo / activo , o activo /stand by . Requiere mecanismos de detección / conmutación Hay que garantizar que no hay causas comunes de fallo Pej alimentación eléctrica, vulnerabilidad por efectos zonales, Los elementos redundantes pueden ser disimilares o no Disimilaridad de elementos HW/SW Medio para evitar causas comunes de fallo por errores de diseño. Puede ser disimilaridad de diseño (requisitos comunes) o diseño disimilar independiente ( requisitos y diseño).
13 Consideraciones sobre la asignación de DALMonitorización Requerida para implementar el principio “fail safe” si la no integridad de una función que implementa o a la que contribuye el elemento tiene una severidad catastrófica Particionado (Segregación) de componentes HW/SW dentro de un elemento Pej Sistema Operativo ARINC 653 con particiones Segregación de componentes HW/SW que garantiza la no propagación de un fallo Permite asignar distinto DAL a los componentes segregadas No debe haber causas comunes de fallo (independencia)
14 Normativa para SW RTCA 178 B / ED 12 BDefine requisitos para los procesos en funcion del Nivel (DAL) asignado al elemento SW Planificación (ciclo,métodos,herramientas,.. Desarrollo Análisis de requisitos Diseño Programación Integración Verificación Gestión de Configuración Garantía de Calidad Enlace con autoridad de certificación Para cada subproceso de desarrollo productos y condiciones de terminación relacionadas con Verificación, GC y QA
15 RTCA 178 B / Interfaz con la autoridad de CertificaciónExige la entrega de una documentación mínima antes del comienzo y al finalizar Antes de comenzar el desarrollo la autoridad de certificación debe aprobar el Plan de de Certificación SW PSAC . Justificación del nivel (Ref. PSSA) , describe el tratamiento de algunos aspectos considerados (reutilización, carga, disimilaridad,) resume el cumplimiento de los objetivos e identifica los planes asociados desarrollo, verificación, gestión de configuración , garantía de calidad. La autoridad de certificación puede exigir información complementaria o/y auditar (típicamente cuatro veces en un desarrollo)
16 RTCA 178 B / Interfaz con la autoridad de certificaciónAl finalizar el desarrollo y como parte de las evidencias para certificación SAS (Software Accomplishement Summary) Declaración Formal del cumplimiento planes Justificación de desviaciones Problemas que afecten seguridad CI (Configuration Index) Identificación de todos los componentes fuente Identificación de todos los documentos Instrucciones de regenerar un ejecutable Esta documentación debe ser preparada por cada versión que se utiliza en vuelo
17 RTCA 178 B / Restricciones SW “COTS”RTCA 178 B / Restricciones SW “COTS” Sistemas Operativos,Librerías graficas,Bases de Datos..) Tanto el SW de Aplicación como el SW de base tienen que haber sido desarrollados bajo RTCA 178 B. Esto elimina para cualquier aplicación con involucraciones de seguridad por encima de DAL C (Fallo con efecto peligroso) cualquier producto comercial convencional y sw “libre” y en particular sistemas operativos. Hay productos comerciales especialmente desarrollados bajo RTCA 178 B como Sistemas Operativos (VxWorks, Integrity,LINX-OS.. Librerías Open GL, pilas de protocolos de red Normalmente desarrollados en colaboración con el fabricante de los computadores (adaptación al HW)
18 Procesos RTCA DO 178 B Productos del Proceso de PlanificaciónPlan de Desarrollo Debe identificar el ciclo (incremental, espiral, convencional..) y los “standard” de requisitos, diseño, programación. Plan de Verificación Criterios revisión, análisis a realizar, herramientas pruebas, infraestructura, (bancos) organización (independencia) Plan de Gestión de configuración Identificación, baselines,Cambios, Problemas,Copia y distribución Plan de Garantía de Calidad Organización, registros, auditoria producto Terminación Planes revisados y sometidos a CC
19 Procesos RTCA 178 B Proceso de Desarrollo Considera cuatro subprocesos pero no impone un modelo secuencial Análisis de Requisitos sw Diseño SW Codificación Integración En el proceso de desarrollo cada subproceso se da por terminado cuando se han generado los productos correspondientes, se ha realizado el análisis de trazabilidad y se han realizado las actividades de verificación, gestión de configuración y QA
20 Procesos RTCA 178 B Análisis de Requisitos SWExtraer de los requisitos sistema (funcionales, perfomance, interface) los requisitos sw. “High Level Requirements. Identificar los requisitos adicionales con trazables a los requisitos sistema (consecuencia de la implementacion sw) y realimentarlos al análisis de seguridad Producto Documento / Base de Datos de Requisitos SW Conforme al standard de análisis de requisitos identificado en el Plan Tablas de Trazabilidad Terminación Revisión con los criterios Anexo A Evidencias registradas por QA
21 Procesos RTCA 178 B Diseño SWDefinir una arquitectura sw donde se identifiquen los flujos de datos y de control entre los componentes sw Definir los requisitos (LLR) que permiten la codificación componentes Utilización frecuente de modelos como parte del diseño Productos Documento Descripción arquitectura Documento / Modelos requisitos bajo nivel Conforme al standard de diseño identificado en el Plan Tablas de Trazabilidad Terminación Revisión con los criterios Anexo A Evidencias registradas por QA
22 Procesos RTCA 178 B CodificaciónGenerar el código fuente siguiendo el standard identificado en el Plan y utilizando un compilador cualificado generar código objeto. SI se utilizan modelos en el diseño se puede generar código desde el modelo. Consideraciones sobre la calificación de compiladores y generadores de código desde modelos. Productos Código Fuente y Objeto Tablas de Trazabilidad Terminación Revisión del código con los criterios Anexo A Evidencias registradas por QA
23 Procesos RTCA 178 B TrazabilidadSe incluye dentro del macroproceso de desarrollo y su comprobación dentro del proceso de verificación El requisito es variable en función del nivel de criticalidad Para nivel A y B debe haber trazabilidad desde requisitos sistema hasta código fuente Para nivel C trazabilidad desde requisitos sistema hasta requisitos componentes sw (LLR) Para nivel D entre requisitos sistema y requisitos sw.
24 Procesos RTCA 178 B Verificación (1)Tres tipos de actividades de Revisión, Análisis, Pruebas. Los objetivos de las actividades de verificación están definidas en las tablas del Anexo A La independencia en la realización de la verificación depende del nivel Revisión de : Planes Requisitos Arquitectura y Diseño Código Casos de Prueba Resultados de Pruebas Análisis Peor caso para tiempos de ejecución Análisis de cobertura de pruebas frente a requisitos (HLR y LLR) Análisis de cobertura estructural de las pruebas
25 Procesos RTCA 178 B Verificación (2) Tres tipos de prueba: HW/SW Integration Testing (que asociamos a ensayos de calificación contra requisitos sw corriendo en el target). Integración (que asociamos a integración entre componentes para validar la arquitectura) Low Level (unitarias y de componentes) Dos criterios de definición de casos prueba : Cobertura de requisitos (high y low) Cobertura estructural Los requisitos de cobertura estructural dependen del nivel de criticalidad del sw. Nivel C cobertura de sentencias Nivel B cobertura de decisiones Nivel A MCDC
26 Procesos RTCA 178 B Gestión de Configuración ActividadesIdentificación Baselining Control de Cambio (Trazabilidad, Identificación,informe) Archivo protegido de cambios, Recuperación de archivo (Retrieval), Autorización (Release) Retención (Conservación durante un tiempo) Gestión de Problemas generados durante el proceso de Verificación o durante la operación. La gestión de problemas esta conectada con el Control de Cambios. Control de Configuración del Entorno de Desarrollo. Control de la Carga
27 Procesos RTCA 178 B Garantía de Calidad Audita la realización de los procesos de acuerdo a los Planes. Comprueba las condiciones de terminación de cada subproceso de desarrollo Comprueba la realización de las actividades de verificación previstas en el Plan Comprueba la realización de las actividades de gestión de configuración previstas en el Plan Realiza un auditoria “SW Conformity Review” previa a por cada entrega de una versión de vuelo Paso previo a la emisión de SAS y de CI
28