J. García Martín 04/21/23 - 1
SISTEMAS DE TIEMPO REAL
Sistemas de Alta Integridad
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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.
J. García Martín 04/21/23 - 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.
J. García Martín 04/21/23 - 6
INTRODUCCIÓN
Análisis de RiesgosPrimer 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:Hazard Level of
riskTolerancetime
Fault Likelihood Detectiontime
Reaction,Controlmean
Exposuretime
Hypoventi-lation
Severe 5 min. Vent fails Rare 30 sec. Independentepressurealarm
35 sec.
Esophagealintubation
Medium 30 sec. CO2 sensoralarm
40 sec.
Usermisattachesbreathingcircuit
Never N/A Differentmechanicalfasteners forintake vs.Output
N/A
Overpressuritation
Server 0.25 sec. Realeasvalve failure
Rare 0.1 sec. Secondaryvalve opens
0.1 sec.
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 9
EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD
Sistema de dosificación de insulina
EnsamblajeAguja
Suministrador
Sensor
Reserva de insulina
Reloj
Controlador
Display 1
Alarma
Display 2
Fuente alimentación
J. García Martín 04/21/23 - 10
EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD
Análisis de posibles fallos del sistema
Medidaincorrecta de
nivel de azúcar
Erroralgorítmico
Erroraritmético
Erroralgorítmico
Erroraritmético
Fallosensor
Error cálculode azúcar
Fallo detiempos
Cálculoincorrecto de
insulina
Señalesincorrectas en
bomba
Suministrocorrecto en
instante erróneo
Fallo en elsistema desuministro
Administradadosis incorrecta
de insulina
or
or or
or
or
J. García Martín 04/21/23 - 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.
IdentificaciónContingencia
ProbabilidadContingencia
SeveridadContingencia
Riesgoestimado
Aceptación
1. Sobredosis insulina Media Alta Alto Intolerable2. Infradosis insulina Media Baja Bajo Aceptable3. Fallo de alimentación Alta Baja Bajo Aceptable4. Máquina ajustada incorrectam. Alta Alta Alto Intolerable5. Fractura de máquina en paciente Baja Alta Medio ALARP6. Infección causada por máquina Media Media Medio ALARP7. Interferencia eléctrica Baja Alta Medio ALARP8. Reacción alérgica Baja Baja Bajo Aceptable
J. García Martín 04/21/23 - 12
EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD
Requisitos de seguridad
Ejemplos de requisitos de seguridadSR1 El sistema no debe suministrar una dosis individual de insulina que sea
mayor que un máximo especificado para un usuario del sistema.SR2 El sistema no debe suministrar una dosis acumulada al día mayor que un
máximo especificado para un usuario del sistema.SR3 El sistema debe incluir una facilidad de diagnostico del hardware que se
ejecutará al menos 4 veces por hora.Sr4 El sistema debe incluir un manejo de excepciones para las excepciones
indicadas en la tabla 3.SR5 La alarma debe sonar cuando se detecte un funcionamiento anormal del
hardware. Se deberá mostrar en el display un mensaje de diagnósticocomo se muestra en la tabla 4.
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 14
ESTÁNDARES DE SEGURIDAD
Ejemplos de estándares de seguridad
Por sectores: Medical Systems: IEC 601-4
Airbone Civil Avionics: DO178-BNuclear 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: D C B ADada una aplicación hay que asignarle un grado
J. García Martín 04/21/23 - 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.
J. García Martín 04/21/23 - 16
CENELEC EN50126
Niveles de Integridad
Softwaresafety integritylevel
Description of sw.Safety integrity
4 Very High3 High2 Medium1 Low0 Non safety-related
J. García Martín 04/21/23 - 17
CENELEC EN50126
Elección del Nivel de Integridad
Frecuenciaaparición decontingencia
Consecuenciasaparición decontingencia
Nivel deRiesgo
NecesidadreducciónRiesgo
Sistem safetyintegrity level
Software safetyintegrity level
4 43 32 21 10 0
J. García Martín 04/21/23 - 18
CENELEC EN50126
Independencia vs. Nivel de integridad
Level 0 DI, VER, VAL
Level 1 & 2
Level 3 & 4
Level 3 & 4
ASS´R
DI VER, VAL
VER, VALDI
ASS´R
PRJ MGR
ASS´R
VERDI
PRJ MGR
ASS´RVAL
DI = diseñador/Implem.; VER=Verificador; VAL=Validador; ASS´R=Asesor; PRJ MGR=Jefe Proy.
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 20
CENELEC EN50126
Criterios de selección de técnicas
( tablas)
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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 nivelTraceable los req. de bajo nivelCumple con la arquitectura swTraceable con la arquitectura swEs correcto” y consistenteEs verificableConforme con estándares de sw
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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)
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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 objeto OCA
2. Flujo de datos FA (Flow Analysis)
3. Flujo de control FA
4. Flujo de la información FA
5. Comprobación de rangos RC
6. Utilización de la memoria OMU
7. Utilización de la pila Stk
8. Cumplimientos temporales Tmg
9. Verificación formal del código FC (Functional Correctness)
10.Ejecución simbólica FC
TÉCNICAS DE VERIFICACIÓN
J. García Martín 04/21/23 - 29
Técnicas4.- 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 equivalencia EC Valores extremos BV
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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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)
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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:
Excluido Tiempo/Coste prohibitivo
Permitido Esfuerzo extra
Incluido Disponible
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)
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 38
GUÍA PARA EL USO DE ADA
Selección ...- Instrucciones
J. García Martín 04/21/23 - 39
GUÍA PARA EL USO DE ADA
Selección ... - Paquetes
J. García Martín 04/21/23 - 40
GUÍA PARA EL USO DE ADA
Selección ... - Estructuras Dinámicas
J. García Martín 04/21/23 - 41
GUÍA PARA EL USO DE ADA
Selección ... Excepciones
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 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
J. García Martín 04/21/23 - 49