SISTEMAS DE TIEMPO REAL
Sistemas de Alta Integridad
J. García Martín
03/10/2015
-1
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
03/10/2015
-2
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
03/10/2015
-3
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
03/10/2015
-4
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
03/10/2015
-5
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:
H azard
L evel o f Toleran ce
risk
tim e
F au lt
L ik elih ood
D etection
tim e
H ypov entilation
S evere
Vent fails
R are
30 sec.
E sophageal
intubation
U ser
m isattaches
breathin g
circuit
M edium
30 sec.
N ever
N /A
O ver
pressuritation
J. García Martín
S erver
03/10/2015
5 m in.
0.25 sec.
R ealeas
R are
valve failure
0.1 sec.
R eaction ,
C on trol
m ean
Ind ependente
pressure
alarm
C O 2 sensor
alarm
D ifferent
m echanical
fasteners for
intake vs.
O utput
S econdary
valve opens
E xp osu re
tim e
35 sec.
40 sec.
N /A
0.1 sec.
-6
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
03/10/2015
-7
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
03/10/2015
-8
EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD
Sistema de dosificación de insulina
R eserva de insulina
E nsam blaje
A guja
S um inistrador
R eloj
S ensor
C ontrolador
A larm a
D isplay 1
D isplay 2
F uente alim entación
J. García Martín
03/10/2015
-9
EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD
A dm inistrada
dosis incorrecta
de insulina
Análisis de posibles fallos del sistema
or
M edida
incorrecta de
nivel de azúcar
S um inistro
correcto en
instante erróneo
F allo en el
sistem a de
sum inistro
or
F allo
sensor
or
E rror cálculo
de azúcar
F allo de
tiem pos
C álculo
incorrecto de
insulina
or
E rror
algorítm ico
J. García Martín
S eñales
incorrectas en
bom ba
or
E rror
aritm ético
03/10/2015
E rror
algorítm ico
E rror
aritm ético
- 10
EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD
Identificación de contingencias/Análisis de riesgos
Id entificación
C ontingencia
P robabilidad
C ontingencia
S everidad
C ontingencia
R iesgo
estim ado
A ceptación
1.
2.
3.
4.
5.
6.
7.
8.
M edia
M edia
A lta
A lta
B aja
M edia
B aja
B aja
A lta
B aja
B aja
A lta
A lta
M edia
A lta
B aja
A lto
B ajo
B ajo
A lto
M edio
M edio
M edio
B ajo
Intolerable
A ceptable
A ceptable
Intolerable
A LARP
A LARP
A LARP
A ceptable
S obredosis insulina
In fradosis insulina
F allo de alim entación
M áquina ajustada incorrectam .
F ractura d e m áquina en p aciente
In fección causada por m áquina
Interferen cia eléctrica
R eacción alérgica
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.
J. García Martín
03/10/2015
- 11
EJEMPLO DE SISTEMA DE ALTA INTEGRIDAD
Requisitos de seguridad
SR1
SR2
SR3
S r4
SR5
J. García Martín
E jem p lo s d e req u isito s d e seg u rid ad
E l siste m a n o d eb e su m in istrar u n a d o sis in d iv id u al d e in su lin a q u e sea
m ayo r q u e u n m áx im o esp ecificad o p ara u n u su ario d el siste m a.
E l siste m a n o d eb e su m in istrar u n a d o sis acu m u lad a al d ía m ayo r q u e u n
m áx im o esp ecificad o p ara u n u su ario d el sistem a.
E l siste m a d eb e in clu ir u n a facilid ad d e d iag n o stico d el h ard w are q u e se
ejecu tará al m en o s 4 v eces p o r h o ra.
E l siste m a d eb e in clu ir u n m an ejo d e ex cep cio n es p ara las ex cep cio n es
in d icad as en la tab la 3 .
L a alarm a d eb e so n ar cu an d o se d etecte u n fu n cio n am ien to an o rm al d el
h ard w are. S e d eb erá m o strar en el d isp lay u n m en saje d e d iag n ó stico
co m o se m u estra en la tab la 4 .
03/10/2015
- 12
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
03/10/2015
- 13
ESTÁNDARES DE SEGURIDAD
Ejemplos de estándares de seguridad
Por sectores:
Por regiones:
Medical Systems: IEC 601-4
Airbone Civil Avionics: DO178-B
Nuclear Power Plants: IEC 880
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
A
Dada una aplicación hay que asignarle un grado
J. García Martín
03/10/2015
- 14
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
03/10/2015
- 15
CENELEC EN50126
Niveles de Integridad
J. García Martín
03/10/2015
S oftw are
safety integrity
level
D escription of sw.
S afety integrity
4
3
2
1
0
Very H igh
H igh
M edium
L ow
N on safety-related
- 16
CENELEC EN50126
Elección del Nivel de Integridad
F recuencia
aparición de
contingen cia
N ivel de
R iesgo
C onsecuencias
aparición de
contingen cia
J. García Martín
03/10/2015
N ecesidad
reducción
R iesgo
S istem safety
integrity level
4
3
2
1
0
S oftw are safety
integrity level
4
3
2
1
0
- 17
CENELEC EN50126
Independencia vs. Nivel de integridad
L ev el 0
L ev el 1 & 2
D I, V E R , VA L
DI
A S S ´R
V E R , VA L
A S S ´R
PRJ M GR
L ev el 3 & 4
A S S ´R
DI
V E R , VA L
PRJ M GR
L ev el 3 & 4
A S S ´R
DI
VER
VA L
D I = d iseñad o r/Im p le m .; V E R = Verificad o r; VA L = Valid ad o r; A S S ´R = A seso r; P R J M G R = Jefe P ro y.
J. García Martín
03/10/2015
- 18
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
03/10/2015
- 19
CENELEC EN50126
Criterios de selección de técnicas
( tablas)
J. García Martín
03/10/2015
- 20
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
03/10/2015
- 21
DOD-178-B
Actividades
Lista de actividades que se espera que desarrollen en cada parte del proceso:
 Planificación
 Estándares
Cumple con los req. de bajo nivel
 Desarrollo
Traceable los req. de bajo nivel
Cumple con la arquitectura sw
 Verificación de requisitos software
Traceable con la arquitectura sw
Es correcto” y consistente
 Verificación de diseño software
Es verificable
 Verificación de código
Conforme con estándares de sw
 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
J. García Martín
03/10/2015
- 22
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
03/10/2015
- 23
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:
Técnica Verif
Facilid. Lgje.
(Grado de
cumplimiento)
Una facilidad del lenguaje se rechaza por dificultar la verificación.
J. García Martín
03/10/2015
- 24
TÉCNICAS DE VERIFICACIÓN
Introducción
Los estándares requieren 4 procesos de verificación:
1. Traceability
2. Review
3. Analysis
4. Testing
J. García Martín
03/10/2015
- 25
TÉCNICAS DE VERIFICACIÓN
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
J. García Martín
03/10/2015
- 26
TÉCNICAS DE VERIFICACIÓN
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
J. García Martín
03/10/2015
- 27
TÉCNICAS DE VERIFICACIÓN
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
J. García Martín
03/10/2015
- 28
TÉCNICAS DE VERIFICACIÓN
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 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
J. García Martín
03/10/2015
- 29
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
03/10/2015
- 30
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
03/10/2015
- 31
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
03/10/2015
- 32
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
03/10/2015
- 33
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
03/10/2015
- 34
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
03/10/2015
- 35
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
03/10/2015
- 36
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
03/10/2015
- 37
GUÍA PARA EL USO DE ADA
Selección ...- Instrucciones
J. García Martín
03/10/2015
- 38
GUÍA PARA EL USO DE ADA
Selección ... - Paquetes
J. García Martín
03/10/2015
- 39
GUÍA PARA EL USO DE ADA
Selección ... - Estructuras Dinámicas
J. García Martín
03/10/2015
- 40
GUÍA PARA EL USO DE ADA
Selección ... Excepciones
J. García Martín
03/10/2015
- 41
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
03/10/2015
- 42
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
03/10/2015
- 43
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
03/10/2015
- 44
PERFIL DE RAVENSCAR
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)
J. García Martín
03/10/2015
- 45
PERFIL DE RAVENSCAR
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
J. García Martín
03/10/2015
- 46
PERFIL DE RAVENSCAR
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
J. García Martín
03/10/2015
- 47
PERFIL DE RAVENSCAR
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
J. García Martín
03/10/2015
- 48
J. García Martín
03/10/2015
- 49
Descargar

Sistemas Distribuidos