j. garcía martín 28/06/2015 - 1 sistemas de tiempo real sistemas de alta integridad

J. García Martín 04/21/23 - 1

SISTEMAS DE TIEMPO REAL

Sistemas de Alta Integridad


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


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


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.


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.


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.


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


INDICE

• INTRODUCCIÓN







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



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



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



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.


INDICE

• INTRODUCCIÓN







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


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.


CENELEC EN50126

Niveles de Integridad

Softwaresafety integritylevel

Description of sw.Safety integrity

4 Very High3 High2 Medium1 Low0 Non safety-related


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


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.


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


CENELEC EN50126

Criterios de selección de técnicas

( tablas)


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


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


INDICE

• INTRODUCCIÓN







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)


Introducción

Los estándares requieren 4 procesos de verificación:

1.Traceability

2.Review

3.Analysis

4.Testing



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 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 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é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



INDICE

• INTRODUCCIÓN







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



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




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




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)



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



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)



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



Selección ...- Instrucciones



Selección ... - Paquetes



Selección ... - Estructuras Dinámicas



Selección ... Excepciones


INDICE

• INTRODUCCIÓN







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


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


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


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


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


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 28/06/2015 - 1 sistemas de tiempo real sistemas de alta integridad

Documents