Date post: | 24-Jan-2016 |
Category: |
Documents |
Upload: | maria-del-pilar-aranda-padilla |
View: | 216 times |
Download: | 0 times |
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
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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.
Proprietary Information
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.
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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).
Proprietary Information
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)
Proprietary Information
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
Proprietary Information
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)
Proprietary Information
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
Proprietary Information
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)
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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
• Tablas de Trazabilidad
• Terminación
• Revisión con los criterios Anexo A
• Evidencias registradas por QA
Proprietary Information
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
• Tablas de Trazabilidad
• Terminación
• Revisión del código con los criterios Anexo A
• Evidencias registradas por QA
Proprietary Information
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.
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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
Proprietary Information
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
Proprietary Information