Capacidades de tiempo real

Nora Blet

Informática III

Capacidades de Tiempo Real

Objetivo Comprender el papel del tiempo en el diseño e

implementación de sistemas de tiempo real Contenido:

Sistemas de referencia de tiempo Relojes, retardos y límites temporales (time-outs) Requisitos temporales Ámbitos temporales Tolerancia a fallos

Necesidades

Acceso al tiempo real leer el paso del tiempo en relojes retrasar la ejecución de los procesos durante un tiempo definir límites temporales para la ocurrencia de un suceso

(timeouts) Representación de los requisitos temporales

períodos de activación plazos de ejecución

Análisis del cumplimiento de los requisitos temporales Lo veremos en el próximo tema

Medida del tiempo

Objetivo: Comprender la importancia de la medida del tiempo con precisión en el desarrollo de sistemas de tiempo real

Contenido: Sistemas de referencia de tiempo Relojes y retardos

Acceso a un reloj Si un programa ha de cumplir con determinados

requisitos temporales debe tener alguna forma de medir el paso del tiempo Accediendo al marco temporal del entorno (Ej.: GPS,

Internet utilizan una señal de tiempo internacional que se emite por radiofrecuencia o por via satelital (UTC))

Mediante un reloj hardware interno que de una aproximación adecuada del paso del tiempo del entorno

Desde la perspectiva del programador: Mediante una primitiva del reloj del lenguaje Programando un controlador (driver) de un reloj del

sistema asociado al procesador (reloj interno) o, un reloj externo o un radioreceptor sintonizado con una señal de tiempo internacional

Tiempo Universal

TU0 o UT0 (Tiempo Universal) Tiempo solar medio en el meridiano 0. Definido

en 1884 (GMT) 1s = 1/86.400 de un día solar medio Definición válida hasta 1955 Relativamente impreciso y variable

Día solar variante por acción de las mareas y otros fenómenos

Tiempo de efemérides

Año trópico Tiempo transcurrido por dos pasos de la tierra por un punto

definido 1s=1/31 566 925, 9747 del año trópico de 1990 Definición oficial entre 1955 y 1967

Correcciones de UT0: UT1: UT0 Corregido por el movimiento de los polos

(astrónomos) UT2: UT1 Corregido por variaciones de la rotación de la

tierra

Tiempo atómico Los relojes atómicos presentan una medida del

tiempo precisa y estable. 1s= 1/9 192 631 770 periodos de la radiación

correspondiente a la transición entre los dos niveles hiperfinos del estado fundamental del átomo de cesio 133 en reposo a una temperatura de 0º K.

Definición oficial (SI) desde 1967 Precisión del orden de 10-13 (1s en 300.000 años)

TAI (tiempo atómico internacional) definido en 1970

mantenido por una red coordinada por el BIMP (Bureau International de Mésures et Poids)

Tiempo universal coordinado

El TAI se aparta lentamente del UT La duración del día solar medio va en aumento En 2001, la diferencia es aprox. de 32 s

UTC (Universal Time Coordinated) Definido en 1972 UTC = TAI + H

H se elige de forma que |UT2 - UTC| ≤ 0,5 s

Relojes en Java

Reloj de hora del día (“reloj de pared”) java.lang.System.currentTimeMillis() da el

número de milisegundos transcurridos desde UTC 1970-01-01:00:00

java.util.Date usa este valor para dar la fecha y hora del día

Tipos de datos de alta resolución (RT Java) representación del tiempo con resolución de 1 ns

Índice

Medida del tiempo y relojes Retardos Límites temporales (time-outs) Requisitos temporales Tolerancia de fallos

Retardos

Un retardo suspende la ejecución de una tarea durante un cierto tiempo

Hay dos tipos Retardo relativo: la ejecución se suspende

durante un intervalo de tiempo relativo al instante actual

Retardo absoluto: la ejecución se suspende hasta que se llegue a un instante determinado de tiempo absoluto

Ejecución de un retardo

Índice

Medida del tiempo y relojes Retardos Límites temporales (time-outs) Requisitos temporales Tolerancia de fallos

Limitación del tiempo de espera A menudo conviene limitar el tiempo durante el cual se espera

que ocurra un suceso Ejemplos:

Acceso a una sección crítica: La espera está limitada por la duración de la sección crítica

Sincronización condicional Ahora el bloqueo asociado no está limitado. Problema del buffer

acotado. Un proceso productor con un buffer lleno debe esperar un tiempo indefinido a que un consumidor retire un ítem del buffer. Es necesaria una primitiva de sincronización condicional con plazo. En Java, puede utilizarse el método wait con un tiempo límite de espera, ya sea con una granularidad de milisegundos o de nanosegundos.

Cita entre dos tareas Ejecución de una acción

Paso de mensajes y tiempo límitede esperatask Controller is

entry Call(T : Temperature);

end Controller;

task body Controller is

-- declarations, including

New_Temp : Temperature;

begin

loop

accept Call(T : Temperature) do

New_Temp := T;

end Call;

-- other actions

end loop;

end Controller;

Problema: Modificar el controlador a fin de actuar cuando no se recibe

una entrega de temperatura rebasado un plazo.

Aceptación temporizada

Se puede especificar una acción alternativa en caso de que la llamada no se reciba (espera en la recepción de un mensaje) dentro de un cierto intervalo mediante una aceptación temporizada

Aceptación temporizadatask Controller is entry Call(T : Temperature);end Controller;

task body Controller is -- declarationsbegin loop select accept Call(T : Temperature) do New_Temp := T; end Call; or delay 10.0; -- action for timeout end select; -- other actions end loop;end Controller;

Llamada temporizada (en la tarea invocante) Se puede limitar el

tiempo que tarda en aceptarse la llamada (espera en el envio de un mensaje) mediante una llamada temporizada

El driver del sensor está leyendo temperaturas continuamente y no tendría sentido enviarle al controlador una lectura caduca, cuando podría pasarle a este un valor más nuevo

Llamada temporizadaloop -- get new temperature T Controller.Call(T);end loop;

loop -- get new temperature T select Controller.Call(T); or delay 0.5; null; end select;end loop;

Llamada condicional

Se usa cuando quiere ejecutarse una acción alternativa si la llamada no se acepta inmediatamente (en lugar de hacer una invocación temporizada con tiempo 0)

Acciones temporizadas

Se puede usar una transferencia asíncrona de control (ATC) para limitar el tiempo de ejecución de una acción:

Es útil para detectar y recuperar fallos

Aplicación al cómputo impreciso Se trata de ejecutar

rápidamente un parte obligatoria de un cálculo, y de iterar sobre una parte opcional que mejora el resultado si le sobra tiempo

Aplicación al cómputo imprecisodeclare

Precise_Result : Boolean;begin

Completion_Time := ...-- compulsory partResults.Write(...); -- call to procedure in

-- external protected objectselectdelay until Completion_Time;Precise_Result := False;

then abortwhile Can_Be_Improved loop-- improve resultResults.Write(...);

end loop;Precise_Result := True;

end select;end;

Índice

Medida del tiempo y relojes Retardos Límites temporales (time-outs) Requisitos temporales Tolerancia de fallos

Requisitos temporalesHay dos formas de enfocar este tema: Métodos formales:

Especificar las propiedades temporales con un modelo formal

Validar la especificación Comprobar que la implementación satisface las

propiedades temporales Métodos analíticos:

Analizar las propiedades temporales desde el punto de vista de la planificación de las tareas

Seguiremos en detalle este último enfoque

Atributos temporales

Los atributos temporales de una secuencia de instrucciones definen un marco temporal para su ejecución

Parámetros temporales Parámetros

D Plazo de respuesta (R ≤ D)

L Tiempo límite (tf ≤ L)

Jmin Latencia mínima

Jmax Latencia máximaC Tiempo de cómputo

máximo Activación

Periódica T Período

Aperiódica Irregular, a ráfagas, estocástica Esporádica T Separación mínima

Parámetros temporales Latencia mínima Jmin: tiempo mínimo que debe transcurrir desde que

se produce el evento de activación hasta que ejecuta el Marco Temporal

Latencia máxima Jmax: tiempo máximo que debe transcurrir desde que se produce el evento de activación hasta que ejecuta el Marco Temporal

Plazo de respuesta D: máximo tiempo en que la ejecución del Marco Temporal debe haber finalizado, medido desde el evento de activación del mismo

Tiempo de respuesta R: tiempo transcurrido desde que se produce el evento de activación hasta que acaba la ejecución del Marco Temporal

Tiempo de cómputo C: tiempo de utilización del procesador del Marco Temporal

Tiempo límite L: Máximo tiempo en que la ejecución del Marco Temporal debe haber finalizado, medido desde el comienzo de su ejecución

Requisitos temporales de tareas Los marcos temporales suelen ir asociados a tareas

o procesos La mayoría de los atributos temporales pueden

satisfacerse al: Ejecutar tareas periódicas Ejecutar tareas esporádicas cuando ocurren los sucesos

correspondientes Completar la ejecución de todas las tareas dentro de su

plazo de respuesta La desviación del cumplimiento de un atributo

temporal se llama fluctuación o jitter

Criticidad

Una tarea de tiempo real puede ser Crítica (hard): No se puede admitir que se

sobrepase el plazo de respuesta especificado ni una sola vez

Acrítica o flexible (soft): Es admisible que se sobrepase el plazo ocasionalmente

Firme (firm): El plazo no es crítico, pero una respuesta tardía no sirve para nada

Interactiva: No se especifican plazos de respuesta, sino tiempos de respuesta medios o adecuados

Índice

Medida del tiempo y relojes Retardos Límites temporales (time-outs) Requisitos temporales Tolerancia a fallos

Fallos temporales

Una tarea (en un sistema “probado”) puede incumplir su plazo por varias razones, por ejemplo:

El tiempo de cómputo no está bien calculado El análisis de tiempos de respuesta no es realista Las herramientas de análisis contienen errores No se cumplen las hipótesis de diseño (por

ejemplo, separación mínima entre eventos)

En estos casos hay que detectar los fallos

Si el sistema es crítico, debe recuperarse

Tolerancia a fallos de temporización Para ser considerado tolerante a fallos de

temporización el sistema tiene que poder detectar: El desbordamiento de un tiempo límite El desbordamiento del tiempo de ejecución en el peor caso Eventos esporádicos que ocurran más a menudo de lo

previsto Tiempos límites de espera en comunicaciones

Reconfiguración basada en eventos A menudo, las consecuencias de un error de temporización en

un proceso/hilo responsable de un tiempo límite, son: Otros procesos deben alterar sus límites temporales, o incluso

terminar lo que están haciendo Hay que arrancar nuevos procesos Si los cálculos importantes requieren más tiempo del procesador

del asignado, para tener tiempo extra, otros procesos menos importantes pueden tener que ser “suspendidos”

Los procesos tienen que ser “interrumpidos”, normalmente para emprender una de las siguientes acciones: Se debe devolver inmediatamente el mejor de los resultados

obtenidos Cambiar a un algoritmo más rápido Pasar a estar disponible para recibir nuevas instrucciones

Fuente de las transparencias http://polaris.dit.upm.es/~jpuente/strl05/transparencias/Ti

empo.pdf http://gsd.unex.es/~jdiaz/asig/str/transp/tiempore/TranspT

R_v0.pdf libro de Alan Burns y Andy Wellings cuya versión en

castellano es: Sistemas de Tiempo Real y Lenguajes de Programación (3ª Edición). Autor: Alan BURNS y Andy WELLINGS. Editorial:ADDISON-WESLEY Iberoamericana España, Pgs: 824 ISBN: 8478290583