Sistemas de tiempo real. Especificación JRTS

Principios generales de los sistemas de tiempo real

Es un sistema cuyo funcionamiento correcto depende de los resultados lógicos producidos, y también del instante de tiempo en que se producen esos resultados.

El plazo del tiempo dentro del cuál los resultados deben producirse para ser considerados válidos se denominan ligadura temporal. El incumplimiento de esta conlleva aparejado un fallo del sistema.

Objetivo: dar respuesta a eventos procedentes del mundo real antes de un límite temporal establecido (deadline)

Predictibilidad:

• Se cumplen los deadlines con independencia de
  • Carga de trabajo
  • Número de procesadores
  • Hilos y prioridades
  • Algoritmos de planificación
• Determinismo
  • Funcionalidad
  • Rendimiento
  • Tiempo de respuesta

Ejemplos: sistemas de radares, armas de fuego, detección de misiles, etc.

Elementos

En general, incluye sensores (antena radar), sistema de control (hardware, software o combinación de ambos) que lee información procedente de los sensores y efectúa un cálculo con ellos (dentro de la ligadura temporal).

El ciclo habitual del funcionamiento de un STR sigue de forma cíclica las etapas:

lectura de sensores → computación → control de actuadores → actualización del sistema controlado

Propiedades

Reactividad: el sistema interacciona con su entorno, y responde correctamente dentro de su ligadura temporal a los estímulos que los sensores le proporcionan.

Predictibilidad: la ejecución del sistema es determinista, lo cuál implica responder en el plazo adecuado, conocer los componentes software y hardware que se utilizan, y definir marcos temporales acotados cuando no se dispone de un conocimiento temporal exacto.

Fiabilidad: grado de confianza en el sistema, depende de:

• Disponibilidad, capacidad de proporcionar servicios cuando se solicitan
• Tolerancia a fallos, capacidad de operar en situaciones excepcionales sin causar fallos
• Fiabilidad, capacidad de responder siempre igual a la misma situación
• Seguridad, capacidad de protegarse frente a ataques o fallos accidentales o deliberados

Tipos

Modelo de tareas de RT

Un sistema de TR se estructura en tareas que acceden a los recursos del sistema.

• Tarea, conjunto de acciones que describe el comportamiento del sistema o parte ejecutando código secuencial (proceso o hebra).

  • Las tareas satisfacen necesidades funcionales concretas
  • Tienen definida una ligadura temporal mediante atributos temporales

• Recurso, elementos disponibles para la ejecución de tareas.

  • Activos: procesador, core, red
  • Pasivos: datos, memoria, dispositivos E/S

Atributos temporales de tareas RT

Tiempo de ejecución (C): tiempo necesario para ejecutar la tarea íntegramente.

Tiempo de respuesta (R): tiempo que la tarea ha necesitado para ejecutarse íntegramente.

Ligadura temporal (deadline) (D): máximo tiempo de respuesta posible.

Periodo (T): intervalo temporal entre activaciones sucesivas de tareas periódica.

Planificación de tareas RT

La planificiación de tareas se encarga de asignar las tareas a los recursos activos de un sistema RT (en especial el procesador o los cores de ejecución), garantizando la ejecución de todas las tareas de acuerdo a las restricciones establecidas. En sistemas RT, estas restricciones aparecen principalmente en forma de ligaduras temporales.

Diseño de la planificación de tareas RT

Para esto debemos:

• Determinar los procesadores o cores disponibles a los que podemos asociar tareas
• Determinar las relaciones de dependencia entre tareas:
  • Relaciones de precedencia entre tareas
  • Determinar los recursos comunes a que distintas tareas acceden
• Determinar el orden de ejecución de las tareas para garantizar el cumplimiento de las restricciones

Esquema de la planificación de tareas RT

Determinar la planificabilidad de un conjunto de tareas requiere de un esquema (método) de planificación que incluya los siguientes elementos:

• Un algorimto de planificación, que define una política de planificación para determinar el orden de acceso de las tareas a los procesadores
• Un método de análisis (test de planificabilidad) para predecir el comportamiento temporal del sistema, y determina si la planificabilidad es posible bajo las condiciones o restricciones presentes
• Una comprobación factible de que las ligaduras temporales se cumplen en todos los casos posibles

En general, se estudia el peor caso posible o WCET (worst case execution tiempo)

Determinación del WCET

Construir un test de planificabilidad para un conjunto de tareas exige conocer el WCET (C) para cada una de ellas. Es posible determinar este parámetro de dos formas diferentes:

• Medimos el tiempo de ejecución en el peor de los casos sobre la plataforma hardware en varias ocasiones y se construye una estadística
• Se efectúa un análisis del código ejecutable
  • Descomponiendo el código en un grafo de bloques secuenciales
  • Calculando el tiempo de ejecución de cada bloque
  • Buscando el camino más largo en el grafo

Esquemas de planificación (sistema monoprocesador)

Planificación estática off line sin prioridades, planificación cíclica (ejecutivo cíclico)

Planificación basada en prioridades

• Prioridades estáticas
  • Prioridad al más frecuente (RMS, rate monotonic scheduling)
  • Prioridad al más urgente (DMS, deadline monotonic scheduling)
• Prioridades dinámicas
  • Proximidad del plazo de respuesta (EDF, earliest deadline first)
  • Prioridad al de menor olgura (LLF, least laxity first)

Ejemplo de planificación cíclica

Construye una planificación explícita y fuera de línea de las tareas que especifica el entrelazado de las mismas forma que su ejecución cíclica garantiza que se cumplen las ligaduras temporales.

La estructura de cntrol se denomida ejecutivo cíclico. El entrelazado de tareas es fijo, y conocido antes de poner en marcha el sistema.

La duración del ciclo principal es igual al hiperperiodo $T_M = mcm(T_1, T_2, ..., T_m)$, se suponen tiempo entero, y el comportamiento temporal del sistema se repite cada ciclo principal.

Propiedades de la planificación cíclica

NO hay concurrencia en la ejecución, cada ciclo secundario en una secuencia de llamadas a método. No se necesita un núcleo de ejecución multitarea.

Las tareas pueden compartir datos, sin tener que llevar control de exclusión mutua. No necesitamos analizar el comportamiento temporal.

Inconvenientes de la planificación cíclica

Dificultad para incorporar tareas con periodos largos, las tareas esporádicas dificultan el tratamiento.

El plan del ciclo es difícil de construir, poco flexible y de difícil mantenimiento.

Planificación con prioridades

La prioridad es un atributo de las tareas que mide su importancia relativa respecto a las demás, se codifica con números enteros cecientes según la importancia de la tarea (o al revés). La prioridad de una tarea determina sus necesidades temporales.

Idealmente, las tareas se despachan para ejecución según su prioridad

Prioridades RMS

Método de planificación estático online con asignación de prioridades a las tareas más frecuentes.

Cada tarea recibe una prioridad única basada en su periodo; cuanto menor sea el periodo (mayor frecuencia), mayor prioridad. $\forall i,j: T_i < T_j → P_i < P_j$.

Aquí asignamos prioridades decrecientes para procesos más frecuentes.

Prioridades EDF

Da mayor prioridad a la tarea más próxima a su ligadura temporal (deadline). En caso de igualdad, se hace una elección no determinista.

Es un algoritmo de planificación dinámico, donde las prioridades de las tareas cambian en el tiempo. No necesita que las tareas sean periódicas.

Límites de Java estándar en RT

• Gestión de memoria
  • gc, recolector de basura, es impredecible. Se activa cuando quiere
  • Fragmenta la memoria (memoria no planificable)
• Planificación de Threads
  • Impredecible
  • No permite especificar cuándo un hilo ha de ejecutarse
  • Inversiones de prioridad
• Sincronización
  • Duración de secciones críticas impredecible
  • Un hilo no sabe cuántas otras tareas compiten por un recurso ni su prioridad
• Gestión asíncrona de eventos (no definida)
• Acceso a memoria física
  • Una tarea no sabe cuánta hay ni cuánta necesita

La especificación Java-RT (RTJS)

Cambia la JVM para que soporte RT, no modifica el lenguaje Java; lo engloba.

Incorpora:

• Tipos nuevos de hilos
• Tipos nuevos de memoria
• Gestión asíncrona de eventos
• Predictibilidad (fente a rendimiento)

Conservando:

• Compatibilidad hacia atrás
• El lenguaje y el bytecode

Gestión de memoria: API

RTJS provee áreas de memoria no afectadas por gc, al existir fuera del heap. El gc puede ser expulsado por un hilo RT.

Se utiliza la clase abstracta MemoryArea y sus subclases:

HeapMemory, InmortalMemory, ScopedMemory; VTMemory, LTMemory

Planificación en Java, limitaciones

Java no garantiza que los hilos de alta prioridad se ejecuten antes, debido a el mapping hilos_java-hilos_sistema y el uso de planificación no expulsiva.

El esquema de diez prioridades java cambia durante el mapping a prioridades de sistema, con superposiciones dependientes del sistema.

El concepto de planificación por prioridad es tan débil que lo hace completamente inadecuado para su uso en entornos RT. Por tanto, los hilos de mayor prioridad, eventualmente se ejecutarán antes, pero NO hay garantías de que ello ocurra así.

Planificación en Java-RT: Gold standard

Planificación por prioridades fijas, preemtive (expulsivo) y con 28 niveles de prioridad.

• Fijas, porque los objetos planificables no cambian su prioridad (salvo si hay inversión de prioridad → herencia de prioridad)
• Expulsiva, porque el sistema puede sacar, por diferentes motivos, al objeto en ejecución

Objetos planificables, Schedulable

RTJS generaliza el concepto de entidades ejecutables desde el conocido thread a los objetos planificables schedulable objects.

Un objeto planificable implementa la interfaz Schedulable y puede ser:

• Hilos RT (clase RealTimeThread y NoHeapRealTimeThread)
• Gestores de eventos asíncronos (clase AsyncEventHandles)

Cada objeto planificable debe especificar sus requerimientos temporales, indicando requerimientos de:

• Lanzamiento (release)
• Memoria (memory)
• Planificación (schedulng)

Parámetros de lanzamiento (release)

Tipos de lanzamiento:

• Periódico, activación por intervalos regulares
• Aperiódico, activación aleatoria
• Esporádico, activación irregular con un tiempo mínimo entre dos activaciones

Todos los tipos de lanzamiento tienen un coste y un deadline relativo:

• El coste es el tiempo de CPU requerido para cada activación
• El deadline es el límite de tiempo dentro del cual la actiación actual debe haber finalizado

Lanzamiento de un hilo RT:

RealtimeThread htr = new RealTimeThread();
RelativeTime miliseg = new RelativeTime(1,0);
ReleaseParameters relpar = new Periodic Parameters(miliseg);
htr.setReleaseParameters(relpar);

Parámetros de planificación (scheduling)

Son utilizados por el planificador para escoger qué objeto planificable ha de ejecutarse. Se utiliza la clase abstracta SchedulingParameters como la raíz de una jerarquía que permite múltiples parámetros de planificación.

RTJS utiliza como criterio de planificación único la prioridad, de acuerdo al gold standard

Clases: PriorityParameters, ImportanceParameters

Ajuste de prioridad de un hilo RT:

RealtimeThread htr = new RealTimeThread();
int maxPri = PriorityScheduler.instance().getMaxPriority();
PriorityParameters pri = new PriorityParameters(maxPri);
htr.setSchedulingParameters(pri);

Planificadores (schedulers)

Son los algoritmos responsables de planificar para ejecución los objetos planificables. RTJS soporta planificación expulsiva por prioridades de 28 niveles mediante el PriorityScheduler

Scheduler es una clase abstracta (una instancia única por JVM y PriorityScheduler es una subclase).

Este esquema permite el diseño de planificadores propios mejorados.

Cumplimiento de deadlines

Un sistema de tiempo real bien diseñado debe predecir si los objetos de aplicación cumplirán sus deadlines y evitar la pérdida de deadlines y sobrecargas de ejecución.

Algunos sistemas pueden ser verificados offline, otros requieren un análisis online. RTJS provee herramientas para el análisis online.

Threads Real-Time: Generalidades

Son objetos schedulable y heredan de la clase Thread, mucho más que una simple extensión de la clase, existe además una versión no-heap independiente del recolector de basura y que no usa memoria del heap.

Gestión de eventos asíncronos: Generalidades

Threads estándares o RT modelan bien tareas concurrentes con un ciclo de vida bien definido. Se requiere modelar eventos que ocurren asíncronamente durante la actividad de un hilo, procedentes del entorno o generados por la lógica del programa.

Podríamos tener hilos en espera (p.e: en un pool) para tratarlos, pero sería ineficiente.

Desde un enfoque RT, estos eventos requieren gestores que respondan bajo un deadline, RTJS generaliza los gestores de eventos a objetos schedulable.

Hilos RT y manejadores de eventos

En la práctica, la JVM-RT liga dinámicamene un gestor de eventos con un hilo-rt. Es posible, ligar un gestor de eventos a un hilo-rt de forma permanente.

Cada instancia de AsyncEvent puede tener más de un gestor de eventos. Cuando el evento se produce, su gestor de eventos es activado para ejecución según sus parámetros de planificación.

Control de la sincronización

Los objetos planificables (incluidos hilos-rt) deben poderse comunicar y sincronizar. Sabemos que Java proporciona control de acceso tipo monitos a objetos para control de la E.M. Sin embargo, todas las técnicas de sincronización basadas en la E.M. sufren inversión de prioridades.

Java-RT lo soluciona mediante la técnica de herencia de prioridad