Seguridad en sistemas digitales embarcados. Proprietary Information Concepto Certificación Aeronáutica Certificado de Tipo Funcionalidad, comportamiento,

Seguridad en sistemas digitales embarcados

Proprietary Information

Concepto Certificación Aeronáutica

• Certificado 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 25 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


Proceso de Certificación y de aeronavegabilidad continuada

• Solicitar 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


Ejemplos Sistemas Embarcados con SW

Algunos 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


Requisitos genéricos para certificación en sistemas embarcados

• Requisitos FAR 25 1309 +AC 1309 1A / CS 25 1309 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


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.


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.


Documentación de Certificación por cada sistema

• Documentació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


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


Análisis de Seguridad SAE ARP 4761

• Catalogo 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


Consideraciones sobre la asignacion del DAL

• El 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 5.4.1.2 a 5.4.1.5 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 BRTCA DO 254 / ED 80


Consideraciones sobre la asignacion del DAL

• Redundancia 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).


Consideraciones sobre la asignación de DAL

• Monitorizació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)


Normativa para SW RTCA 178 B / ED 12 B

• Define 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


RTCA 178 B / Interfaz con la autoridad de Certificación

• Exige 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)


RTCA 178 B / Interfaz con la autoridad de certificación

• Al 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


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)


Procesos RTCA DO 178 B

• Productos del Proceso de Planificación• Plan 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


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


Procesos RTCA 178 B

• Análisis de Requisitos SW• Extraer 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


Procesos RTCA 178 B

• Diseño SW• Definir 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


• Terminación

• Revisión con los criterios Anexo A



Procesos RTCA 178 B

• Codificación• Generar 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


• Terminación

• Revisión del código con los criterios Anexo A



Procesos RTCA 178 B

Trazabilidad• Se 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.


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


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


Procesos RTCA 178 B

Gestión de Configuración

• Actividades• Identificació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


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


Seguridad en sistemas digitales embarcados. Proprietary Information Concepto Certificación Aeronáutica Certificado de Tipo Funcionalidad, comportamiento,

Documents

proceso de anlisis

requisitos de procesos

seguridad conforme

proceso de validacin

dal asignado

procesos de gestin

implementacindel sistema

sae arp