Definición (Donald Gillies)
Un sistema de tiempo real (STR) es aquel en el cual los resultados son correctos, no sólo si la computación es correcta, sino también el tiempo en el cual se producen los resultados
Si no se verifican las restricciones de tiempo, se dice que se ha producido un fallo en el sistema
Otros han añadido:
Así pues, es fundamental garantizar las restricciones de tiempo, lo cual implica que el sistema sea predecible. Además, sería deseable que el grado de utilización del sistema sea alto a la vez que se mantienen estas restricciones
Ejemplo
Ejemplo: robot que debe coger un objeto que viaja por una cinta transportadora
Sistema de tiempo real no es sinónimo de sistema rápido ni de sistema interactivo (i.e. radiotelescopio)
Aunque las velocidades de proceso aumenten los STR seguirán existiendo
Mercado de los sistemas empotrados
Curiosidades:
Un teléfono móvil de última generación tiene más de 1 millón de líneas de código
Los costes de un avión relacionados con el SW supone un 50%
El 90% de las innovaciones en automóviles las proporcionan los sistemas electrónicos
Año 2001
Dónde se utilizan los STR
Sistemas de mando y control
Sistemas de control de procesos
Sistemas de control de vuelo
Sistemas de control de automóviles
Sistemas de defensa
Sistemas de vigilancia intensiva
Sistemas multimedia
Electrónica de consumo
Sistemas de telecomunicación, etc.
Clasificación de los STR
Críticos (hard real time systems): los plazos de respuesta deben respetarse en todas las circunstancias, una sola respuesta tardía a un suceso puede tener consecuencias fatales (sistemas de control de centrales nucleares o de aviones)
Acríticos (soft real time systems): se puede tolerar retrasos ocasionales en la respuesta a un suceso (el sistema de control de una lavadora)
¿Qué se entiende por criticidad?
En algunas ocasiones se habla de funciones de validez o de utilidad que definen la valía de los resultados en función de su tardanza
Otra clasificación
Sistemas activados por eventos
Las interrupciones determinan la evolución del sistema
Pueden fallar si la carga es alta
Sistemas activados por tiempo
Sólo interrumpe el reloj de tiempo real
Operan mejor con cargas altas (“pueden pensarse las cosas”)
También hay sistemas mixtos
Estructura de un STR
(Gp:) Sistema
de
control
(Gp:) Sistema
controlado
Indicadores
Salidas
externas
Medidas
Acciones
Entradas
externas
Consignas
Estructura de un STR
El sistema de control (STR) actúa sobre el sistema controlado para conseguir un comportamiento definido
Es muy común emplear un esquema realimentado
En función de las medidas opera un algoritmo de control
Ese algoritmo de control determina las acciones impuestas al sistema controlado
Ejemplos: controlador PID, controlador deadbeat o filtros de Kalman
Un aspecto de suma importancia son los tiempos en los que se lleva a cabo cada acción
Ejemplo: Control digital
Ley de control
rk
yk
A/D
A/D
uk
D/A
Sensor
r(t)
Planta
Actuador
y(t)
u(t)
Controlador
Referencia
Sistemas empotrados
Muchos STR son partes de otros sistemas en los que realizan operaciones de control
En estos casos hablamos de sistemas empotrados o “embedded systems”
Este tipo de sistemas suelen estar limitados en cuanto a recursos y no son visibles
Ejemplos:
Teléfonos móviles, radios, televisores, etc.
Sistemas de control en automóviles
Electrodomésticos
Características de los STR
Los Sistemas de Tiempo Real (STR) llevan asociadas una serie de características básicas como las siguientes:
Tamaño y complejidad
Fiabilidad y seguridad
Cálculos con números reales
Interacción con dispositivos físicos
Eficiencia
Dependencia del tiempo
Concurrencia
Tolerancia ante fallos
Tamaño y complejidad
Son dos aspectos ligados al software
Un factor muy importante es la necesidad de realizar cambios
Solución: descomponer el sistema en subsistemas pequeños
Fiabilidad y seguridad
Fiabilidad
Es la probabilidad de proporcionar el servicio especificado
Para una tasa de fallos de ? averías/hora la media de tiempo entre averías MTTF=1/ ?
Si MTTF > 109 hablamos de sistemas ultrafiables
Seguridad
Los sistemas críticos deben ser ultrafiables
Para ciertos proyectos es necesaria una certificación oficial
Los requisitos de fiabilidad y seguridad en los STR son mayores que en el resto
Según Hecht y Hecht (1986), los sistemas software complejos, por cada millón de líneas de código contienen una media de 20.000 errores
El 90% de esos errores pueden ser detectados con sistemas de comprobación
200 errores de los restantes se detectan durante el primer año. Los 1800 restantes permanecen sin detectar
¿De dónde provienen los errores?
Una especificación inadecuada
Errores de diseño de los componentes SW
Averías en los componentes de hardware
Interferencias transitorias o permanentes en los sistemas de comunicación
Los errores 3 y 4 tienen un comportamiento previsible con métodos estadísticos
El lenguaje de programación debe facilitar el desarrollo de sistemas seguros
Se hace necesario el empleo de técnicas de prevención y tolerancia ante fallos
Cálculos con números reales
Números asociados a magnitudes físicas asociadas al sistema controlado
Los datos crudos son filtrados y convertidos a datos de ingeniería
Se representan de forma aproximada en un ordenador
Tipos de representaciones: coma fija y coma flotante
Cuando algún dato toma valores incorrectos, se generan alarmas
Dependencia del tiempo
Tiempos en los cuales se deben llevar a cabo determinadas acciones
Tiempos de terminación de cada acción
Responder a situaciones transitorias en las que no se pueden garantizar todos los plazos
Realizar cambios dinámicos en el comportamiento temporal del sistema
El comportamiento del sistema debe ser DETERMINISTA
Aspectos temporales
Instante de activación
Límite (Deadline)
Inicio
Fin
Tiempo de respuesta
Plazo máximo de respuesta
El tiempo de respuesta puede variar (jitter)
Concurrencia
Se deben atender diversos tipos de eventos en paralelo
Puede ser suficiente con un sólo procesador
En ocasiones es necesario recurrir a sistemas multiprocesador
¿Cómo expresar la concurrencia desde el programa?
Con ejecutivos cíclicos
Con tareas independientes
Los ejecutivos cíclicos son sencillos, pero:
Complican la labor del programador
Los programas resultantes son oscuros y poco elegantes
Programas difíciles de corregir
Es más difícil la descomposición
Es difícil llevar el programa a un sistema multiprocesador
Colocar el código de manejo de fallos es problemático
Concurrencia
Con tareas independientes, las cuales pueden ser soportadas por:
El lenguaje: caso de Ada o Modula
El sistema operativo
Un SOTR debe proporcionar soporte básico para tareas de tiempo real, tolerancia a fallos, determinismo, etc.
Aspectos cruciales que deben considerarse:
El factor tiempo
Los protocolos de comunicación
La asignación de recursos
Características de los SOTR
Poseen un cambio de contexto rápido
Poseen un tamaño pequeño
Responden a las interrupciones externas de una forma rápida
Minimizan los tiempos con interrupciones deshabilitadas
Proporcionan esquemas de gestión de memoria que no afecten a la predictibilidad
y proporcionan archivos de acceso rápido
Elementos proporcionados
Con objeto de mantener las especificaciones de tiempo los SOTR:
Poseen un reloj de tiempo real
Proporcionan planificación basada en prioridades
Proporcionan alarmas y timeouts, y
Las tareas pueden activarse en intervalos de tiempo definidos
Lenguajes de programación
Básicamente cabe considerar tres alternativas:
Lenguajes ensambladores
Proporcionan la máxima flexibilidad pero los desarrollos son costosos y poco fiables
Lenguajes secuenciales (C, Pascal, FORTRAN, etc.)
Deben tener un SOTR por debajo
Lenguajes concurrentes (Ada, Modula, concurrent C, etc.)
El lenguaje proporciona la concurrencia y el tiempo real