Sistemas de informacion en tiempo real

Sistemas de Tiempo Real
(Real‐Time Systems)

Seminario de Electrónica: Sistemas Embebidos
1º cuatrimestre de 2010
Facultad de Ingeniería, UBA
1 de 32

Definiciones
Un sistema de tiempo real (STR o real-time system o
RTS) es aquel cuyo correcto funcionamiento depende
de que las salidas “lleguen a tiempo”
O sea que debe estar acotado el tiempo entre cada evento y la
respuesta queprovoca
• No necesariamente tiene que ser breve, pero sí acotado

Deadline (relativo), o sea, tiempo
máximo aceptable para la respuesta
Tiempo de procesamiento

Llega un
estímulo

Se empieza
a atender

Se termina
de atender

Deadline t
(absoluto)
2 de 32

Se distinguen dos tipos:
STR duro (hard RTS)
Es duro cuando el incumplimiento de un deadline implica un
funcionamientoincorrecto
•

Ejemplos:
– El sistema ABS (anti-lock breaking system) de un auto
– Un marcapasos

STR suave (soft RTS)
Es suave cuando el incumplimiento de un deadline no implica
funcionamiento incorrecto pero sí una degradación en la
calidad de servicio
•

Ejemplos:
– Procesamiento de video
» Porque es aceptable que se pierda algún que otro cuadro
– Un reproductor de DVD
– Interfacesal usuario en general

¿Pueden dar más ejemplos?
3 de 32

Requerimientos de un STR
Un STR está definido por una lista de:
Los eventos externos que puede atender
La respuesta lógica (o sea, salida) que debe producir cada
evento
Los requerimientos de temporización de esas respuestas
•

O sea, sus deadlines relativos

Para simplificar, los STR suaves frecuentemente se
diseñan como sifueran STR duros
O sea, como si sus deadlines fueran estrictos

Como siempre, para especificar y refinar los
requerimientos, podemos recurrir a:
Diagramas de secuencia
Statecharts
Otros modelos de computación y lenguajes de modelado
4 de 32

Ejemplo

Notas con requermientos
de temporización y de
calidad de servicio (quality
of service o QoS)

B.P.Douglass; “Capturing Real-TimeRequirements “


5 de 32

Requerimientos de temporización
A veces se recurre a métodos formales para verificar
el cumplimiento de los requerimientos de
temporización, pero es más frecuente testearlos
mediante simulaciones y pruebas en prototipos
Problemas:
• Ante cambios menores, hay que volver a testear todo
– Se aliviana automatizando esas pruebas, si se puede
• El testeo nunca dagarantías al 100%

Es muy valioso usar técnicas de programación que nos den
cierta seguridad sobre el cumplimiento que los requisitos de
temporización, para no depender mucho de la verificación.

Para cumplir esos requerimientos, a veces hay que
evitar usar técnicas que implican tiempos largos y/o
poco predecibles
Ejemplos:
• Programación orientada a objetos
• Garbage collecting (como elde Java)
• malloc() y free() comunes de C
6 de 32

Diseño de un STR
Como ven, un STR es un sistema reactivo con
requisitos (estrictos o no) en cuanto a sus tiempos de
respuesta
Esos requisitos se consideran desde la etapa de
elaboración de requerimientos y durante todo el
proceso de diseño
…a diferencia del diseño de un software transaccional común,
en los cuales lo típico, comomucho, es chequear la velocidad
una vez programadas sus unidades, para decidir si optimizarlas
o no

Recordar que reactivo significa que responde a
eventos externos, que no necesariamente tienen
orden o periodicidad
7 de 32

Diseño de un STR
Un STR puede diseñarse directamente en Assembly
sin librerías ni nada
Ejemplo:
• Un ciclo infinito donde se encuestan, una tras otra, las entradascorrespondientes a los eventos externos, y se las atiende
rápidamente
• El evento externo que no pueda esperar, que vaya colgado de una
interrupción, etc.

Sin embargo, en sistemas medianamente complejos,
suele ser difícil asegurar los requisitos de
temporización si se emplea ese enfoque
Recordar que valoramos las técnicas de programación que dan
cierta seguridad sobre el cumplimiento...