1 J. García Martín 28/06/2015 - 1 SISTEMAS DE TIEMPO REAL Sistemas de Alta Integridad

2 J. García Martín 28/06/2015 - 2 INDICE INTRODUCCIÓN EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD ESTÁNDARES DE SEGURIDAD TÉCNICAS DE VERIFICACIÓN GUIA PARA EL USO DE ADA EN SISTEMAS DE ALTA INTEGRIDAD PERFIL DE RAVENSCAR

3 J. García Martín 28/06/2015 - 3 INTRODUCCIÓN ¿Qué es un sistema de Alta Integridad? Sistema cuyo fallo puede tener graves consecuencias en  vidas humanas  daños físicos  perdidas económicas insostenibles Objetivo: Desarrollar programas seguros (safe) Para ello: escribir programas predecibles y analizables Tendencias: métodos formales, simplicidad

4 J. García Martín 28/06/2015 - 4 INTRODUCCIÓN Definiciones  Disponibilidad (Availability) Probabilidad de que un sistema esté disponible para desarrollar la función que se le requiere en un instante dado.  Fiabilidad (Reliability) Probabilidad de que un sistema desarrolle correctamente (sin fallos) las funciones que se le requieren durante un intervalo de tiempo.  Contingencia (Hazard) Conjunto de condiciones de un sistema (estado) que junto con condiciones del entorno pueden conducir a un accidente.  Riesgo (Risk) Combinación de la frecuencia (probabilidad) y la gravedad de las consecuencias (severidad) ante la aparición de una contingencia.  Seguridad (Safety) Capacidad de un sistema para estar libre de niveles de riesgo inaceptables.

5 J. García Martín 28/06/2015 - 5 INTRODUCCIÓN Definiciones  Nivel de Integridad del Sw (Sw safety integrity level) Clasificación que determina las técnicas que tienen que ser aplicadas con el fin de reducir los fallos del sistema a un nivel apropiado  Nivel de Integridad del Sistema (System safety integrity level) Número que indica el grado de confianza que se requiere a un sistema para que cumpla las características de seguridad especificadas.  Traceabilidad (traceability) Capacidad para poder establecer relaciones entre dos o mas productos de un proceso de desarrollo  Validación (Validation) Actividad para demostrar, mediante análisis o test, que un producto cumple sus requisitos  Verificación (Verification) Actividad para determinar, mediante análisis o test, que una la salida de una fase del cdv cumple con los requisitos de la fase previa.

6 J. García Martín 28/06/2015 - 6 INTRODUCCIÓN Análisis de Riesgos Primer paso en el desarrollo de Sistemas de Alta Integridad Documento anterior/simultáneo a la especificación de requisitos Se actualiza continuamente durante el desarrollo del sistema Contenido:

7 J. García Martín 28/06/2015 - 7 INTRODUCCIÓN Formas de tratar una contingencia  Obviar  Educación del usuario  Alarma  Interbloqueos  Chequeos internos  Utilización de equipos de seguridad especiales  Restricciones en el acceso a contingencias potenciales  Etiquetado

8 J. García Martín 28/06/2015 - 8 INDICE INTRODUCCIÓN EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD ESTÁNDARES DE SEGURIDAD TÉCNICAS DE VERIFICACIÓN GUIA PARA EL USO DE ADA EN SISTEMAS DE ALTA INTEGRIDAD PERFIL DE RAVENSCAR

9 J. García Martín 28/06/2015 - 9 EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD Sistema de dosificación de insulina

10 J. García Martín 28/06/2015 - 10 EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD Análisis de posibles fallos del sistema

11 J. García Martín 28/06/2015 - 11 EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD Identificación de contingencias/Análisis de riesgos Intolerable: El sistema tiene que definir un medio para que la contingencia no aparezca, o si aparece, no cause un accidente. ALARP (As Low As Reasonably Practical): El sistema debe definir un medio para que la probabilidad de un accidente debido a la contingencia sea minimizada, excepto si resulta irrealizable o con un coste excesivo. Aceptable: Se pueden incluir medios para reducir la probabilidad de un accidente, pero no deben incrementar el coste, el tiempo u otros req. no funcionales.

12 J. García Martín 28/06/2015 - 12 EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD Requisitos de seguridad

13 J. García Martín 28/06/2015 - 13 INDICE INTRODUCCIÓN EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD ESTÁNDARES DE SEGURIDAD TÉCNICAS DE VERIFICACIÓN GUIA PARA EL USO DE ADA EN SISTEMAS DE ALTA INTEGRIDAD PERFIL DE RAVENSCAR

14 J. García Martín 28/06/2015 - 14 ESTÁNDARES DE SEGURIDAD Ejemplos de estándares de seguridad Por sectores:Medical Systems: IEC 601-4 Airbone Civil Avionics: DO178-B Nuclear Power Plants: IEC 880 Por regiones:UK Defense Standard: DS 00-55 UK automotive: MISRA Europea Rail: EN 50128 US Nuclear: NRC US Space: NASA US Medical: FDA Niveles de integridad del software: Definen el grado de cumplimiento del estándar que se requiere a una aplicación p.e DO178-B:DCBA Dada una aplicación hay que asignarle un grado

15 J. García Martín 28/06/2015 - 15 CENELEC EN50126 Fases Identificación de contingencias y riesgos Identificación de la reducción de riesgos que se necesita Definir unas especificaciones de requisitos de seguridad para reducir riesgos Elegir una arquitectura adecuada del sistema Planificar y controlar las técnicas y actividades para llevar a cabo las especif.

16 J. García Martín 28/06/2015 - 16 CENELEC EN50126 Niveles de Integridad

17 J. García Martín 28/06/2015 - 17 CENELEC EN50126 Elección del Nivel de Integridad

18 J. García Martín 28/06/2015 - 18 CENELEC EN50126 Independencia vs. Nivel de integridad

19 J. García Martín 28/06/2015 - 19 CENELEC EN50126 Criterios de selección de técnicas Para cada combinación Técnica/Nivel de Integridad: M = Mandatory HR = Highly Recommended R = Recommended - = No recomendation NR = Positively Not Recommended

20 J. García Martín 28/06/2015 - 20 CENELEC EN50126 Criterios de selección de técnicas ( tablas)

21 J. García Martín 28/06/2015 - 21 DOD-178-B Introducción Desarrollado por RTCA Dirigido para software crítico de vuelo en aviación comercial El objetivo es la seguridad (safety) Impone criterios y actividades para asegurar la seguridad del sistema No impone CdV o metodología concreta

22 J. García Martín 28/06/2015 - 22 Actividades Lista de actividades que se espera que desarrollen en cada parte del proceso:  Planificación  Estándares  Desarrollo  Verificación de requisitos software  Verificación de diseño software  Verificación de código  Verificación del proceso de integración  Verificación del proceso de verificación  Gestión de configuración  Asegurar la calidad del software  Verificación de las herramientas utilizadas DOD-178-B Cumple con los req. de bajo nivel Traceable los req. de bajo nivel Cumple con la arquitectura sw Traceable con la arquitectura sw Es correcto” y consistente Es verificable Conforme con estándares de sw

23 J. García Martín 28/06/2015 - 23 INDICE INTRODUCCIÓN EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD ESTÁNDARES DE SEGURIDAD TÉCNICAS DE VERIFICACIÓN GUIA PARA EL USO DE ADA EN SISTEMAS DE ALTA INTEGRIDAD PERFIL DE RAVENSCAR

24 J. García Martín 28/06/2015 - 24 TÉCNICAS DE VERIFICACIÓN Introducción Proceso por el que se asegura que la implementación satisface los requisitos (Validación: asegurar que los requisitos son correctos) Planteamiento para analizar un lenguaje de programación: Una facilidad del lenguaje se rechaza por dificultar la verificación. Técnica Verif Facilid. Lgje. (Grado de cumplimiento)

25 J. García Martín 28/06/2015 - 25 Introducción Los estándares requieren 4 procesos de verificación: 1. Traceability 2. Review 3. Analysis 4. Testing TÉCNICAS DE VERIFICACIÓN

26 J. García Martín 28/06/2015 - 26 Técnicas 1.- Traceability Comprobar que la implementación es completa Confrontación:  De req. bajo nivel a req. alto nivel  De procedimientos de test a requisitos, diseño e implementación  De código objeto a código fuente p.e. Algunas facilidades ==> código del compilador muy extenso, difícil de verificar p.e. Relación muchos-a-muchos en la descomposición de niveles ==> difícil verificar TÉCNICAS DE VERIFICACIÓN

27 J. García Martín 28/06/2015 - 27 Técnicas 2.- Review  Llevadas a cabo por personas  Más o menos formal  Personas independientes del equipo de desarrollo (obligatorio)  Sobre requisitos, diseño, código, procedimientos de test, informes etc. p.e. Algunas facilidades del lenguaje ==> dificultan la revisión del código TÉCNICAS DE VERIFICACIÓN

28 J. García Martín 28/06/2015 - 28 Técnicas 3.- Analysis (estático): Sobre requisitos, diseño y código Los estándares combinan 10 métodos de análisis 1.Código objetoOCA 2.Flujo de datos FA (Flow Analysis) 3.Flujo de controlFA 4.Flujo de la informaciónFA 5.Comprobación de rangosRC 6.Utilización de la memoria OMU 7.Utilización de la pilaStk 8.Cumplimientos temporalesTmg 9.Verificación formal del códigoFC (Functional Correctness) 10.Ejecución simbólicaFC TÉCNICAS DE VERIFICACIÓN

29 J. García Martín 28/06/2015 - 29 Técnicas 4.- Testing (dinámico)  Una comprobación absoluta es infactible  Se puede comprobar la presencia de errores, no la ausencia  Niveles de aplicación: Componentes sw; Integración sw; Integración hw-sw; Test del sistema Tipos: Basado en Requisitos (caja negra)  Clases de equivalenciaEC  Valores extremosBV Basado en la estructura (caja blanca)SC  Instrucciones cubiertas  Decisiones (saltos) cubiertas  Condiciones modificadas/Decisiones cubiertas p.e L.alto-nivel + L.ensamblador en un mismo módulo ==> dificultaría el test de la estructura TÉCNICAS DE VERIFICACIÓN

30 J. García Martín 28/06/2015 - 30 INDICE INTRODUCCIÓN EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD ESTÁNDARES DE SEGURIDAD TÉCNICAS DE VERIFICACIÓN GUIA PARA EL USO DE ADA EN SISTEMAS DE ALTA INTEGRIDAD PERFIL DE RAVENSCAR

31 J. García Martín 28/06/2015 - 31 GUÍA PARA EL USO DE ADA Introducción Aplicar las técnicas vistas para que el sistema tenga un comportamiento predecible ¿ Cuándo y cómo aplicamos las técnicas de análisis (estático y dinámico)? Aproximación Retrospectiva : Cuando el sistema ya ha sido desarrollado A veces demasiado tarde; Correcciones costosas Corrección por construcción : Mientras se desarrolla el código Ir validando los productos intermedios

32 J. García Martín 28/06/2015 - 32 GUÍA PARA EL USO DE ADA Selección de las facilidades del lenguaje Se va a seleccionar una parte del lenguaje Razones para necesitar/rechazar una facilidad del lenguaje  Conseguir ser predecible  Permitir la modelización  Consideraciones pragmáticas

33 J. García Martín 28/06/2015 - 33 GUÍA PARA EL USO DE ADA Selección de las facilidades del lenguaje 1.- Conseguir ser predecible (evitar ambigüedades) Efectos laterales p.e. Y = f(x) * g(x) Efectos de orden de elaboración de paquetes Efectos de mecanismos de paso de parámetros 2.- Permitir la modelización Análisis estático = construcción de modelo (grafo) para hacer comprobaciones Algunas facilidades complican la construcción de modelos p.e. Las excepciones complican la construcción de un grafo

34 J. García Martín 28/06/2015 - 34 GUÍA PARA EL USO DE ADA Selección de las facilidades del lenguaje 3.- Consideraciones pragmáticas Los métodos de análisis (estáticos y dinámicos) son efectivos si sw bien estructurado p.e Cada módulo (tarea) tiene 1 pto. de entrada y 1 pto. de salida Verificar = relacionar fragmentos de código con fragmentos de req. (depende de la simplicidad)

35 J. García Martín 28/06/2015 - 35 GUÍA PARA EL USO DE ADA Elección del lenguaje ADA tiene definición precisa => adecuado para sistemas de alta integridad El núcleo del lenguaje facilita la verificación (modelización, elimina ambigüedad) Hay que restringir el uso de algunas facilidades (excepciones, goto) Conduce a un buen estilo de programación (facilita revisiones) En esta guía se describen las propiedades de las facilidades No se define un subconjunto del lenguaje

36 J. García Martín 28/06/2015 - 36 GUÍA PARA EL USO DE ADA Selección de un subconjunto del lenguaje ADA Para cada facilidad/técnica verificación hay tres niveles de adecuación: ExcluidoTiempo/Coste prohibitivo PermitidoEsfuerzo extra IncluidoDisponible La selección de una facilidad va a depender de:  La propia aplicación  Las técnicas de verificación que se van a emplear (estándar a seguir y nivel de integridad)

37 J. García Martín 28/06/2015 - 37 GUÍA PARA EL USO DE ADA Selección de un subconjunto del lenguaje ADA Pasos a seguir: 1.- Determinar las técnicas de verificación requeridas para los estándar relevantes 2.- Utilizar las tablas para determinar para cada facilidad: Incluida/Permitida 3.- Confirmar que el subconjunto y las técnicas elegidas satisfacen los requisitos de programación y verificación

38 J. García Martín 28/06/2015 - 38 GUÍA PARA EL USO DE ADA Selección...- Instrucciones

39 J. García Martín 28/06/2015 - 39 GUÍA PARA EL USO DE ADA Selección... - Paquetes

40 J. García Martín 28/06/2015 - 40 GUÍA PARA EL USO DE ADA Selección... - Estructuras Dinámicas

41 J. García Martín 28/06/2015 - 41 GUÍA PARA EL USO DE ADA Selección... Excepciones

42 J. García Martín 28/06/2015 - 42 INDICE INTRODUCCIÓN EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD ESTÁNDARES DE SEGURIDAD TÉCNICAS DE VERIFICACIÓN GUIA PARA EL USO DE ADA EN SISTEMAS DE ALTA INTEGRIDAD PERFIL DE RAVENSCAR

43 J. García Martín 28/06/2015 - 43 PERFIL DE RAVENSCAR Introducción Para Ada95 Los Sistemas de Alta Integridad no utilizaban concurrencia del lenguaje Define un subconjunto de facilidades de Ada95 (Lenguaje Completo => Muy extenso) Motivos para definir un modelo restringido: Incrementa eficiencia, disminuye sobrecarga Reduce falta de determinismo Simplifica el run time Elimina facilidades que impiden análisis temporal

44 J. García Martín 28/06/2015 - 44 PERFIL DE RAVENSCAR Introducción Adecuado a: Aplicaciones Safety-Critical que requieren certificación Sistemas Alta Integridad que requieren determinismo funcional STR concurrentes que requieren determinismo temporal STR con restricciones de t. Ejecución que requieren altas prestaciones STR con restricciones de memoria que requieren utilización de memoria determinista

45 J. García Martín 28/06/2015 - 45 Definición del perfil (1) Tareas a nivel de librerías No tareas ni objetos protegidos dinámicos Objetos Protegidos a nivel de librería: Sin entradas (datos compartidos con exclusión mútua) Con una sola entrada (para enviar señales de activación) Barreras consisten en una variable simple (no hay efectos laterales) Sólo puedeestar 1 tarea en una entrada (fácil verificación) Tarea = bucle infinito con un punto de activación (delay o entry) No permite reencolado(fácil análisis funcional y temporal) No Abort ni ATC (sobrecarga el run-time) PERFIL DE RAVENSCAR

46 J. García Martín 28/06/2015 - 46 Definición del perfil (2) No instrucción Select(reduce determinismo funcional) No entradas a tareas(difícil análisis funcional y temporal) Delay until (No delay) Paquete Real_Time (No Calendar) No prioridades dinámicas Incluye FIFO Within Priority + Ceiling Locking Contempla planificación cooperativa PERFIL DE RAVENSCAR

47 J. García Martín 28/06/2015 - 47 Implementación Debe soportar planificación expulsora y no expulsora Run-time sencillo y con baja sobrecarga Los algoritmos del run-time deben: tener un WCET determinista tiempo medio de ejecución lo mas corto posible minimizar uso de memoria global no adquirir memoria dinámica ser conformes a estándares de seguridad ser conformes al propio perfil Ravenscar Comprobaciones en tiempo de compilación PERFIL DE RAVENSCAR

48 J. García Martín 28/06/2015 - 48 Herramientas adicionales AdaCover Detecta que se ha ejecutado todo el código (aplicación + run time) Sigue el estándar DO-178B PerfoRMAx Análisis de planificacbilidad El usr puede elegir entre varias teorías de planificabilidad Visión gráfica de la carga del procesador PERFIL DE RAVENSCAR

49 J. García Martín 28/06/2015 - 49