Sistemas operativos en tiempo real
Con una utilización del 95 %, tres tareas pueden perder un plazo con prioridades fijas y cumplir todos con EDF. La diferencia no es la potencia del procesador sino el orden en que se atienden.
01Tiempo real no quiere decir rápido
Un sistema es de tiempo real cuando la corrección de un resultado depende también de cuándo se entrega. El control de un airbag que calcula perfecto pero 50 ms tarde falló. Lo que importa no es la velocidad promedio sino el peor caso: la garantía de que cada tarea termina antes de su plazo, siempre. Se distinguen sistemas duros, donde perder un plazo es una falla (frenos, marcapasos, control de vuelo), y blandos, donde solo degrada la calidad (audio, video).
Cuando un sistema embebido tiene muchas actividades con plazos distintos, el lazo principal con interrupciones se vuelve difícil de analizar. Un sistema operativo de tiempo real (RTOS) organiza el programa en tareas independientes y decide en cada momento cuál ejecutar con reglas predecibles. Los conceptos generales de procesos y planificación se vieron en sistemas operativos, de Informática II.
02Tareas, estados y cambio de contexto
Cada tarea es una función que corre como si tuviera el procesador para ella sola, con su propia pila. El núcleo guarda de cada una un bloque de control con su prioridad, su estado y el puntero a su pila. Una tarea está ejecutándose, lista esperando procesador, bloqueada esperando un evento o un tiempo, o suspendida. El cambio de contexto guarda los registros de la tarea que sale y carga los de la que entra; en un Cortex-M tarda alrededor de un microsegundo.
El planificador corre en cada tic del reloj del sistema (típicamente cada 1 ms) y cada vez que una tarea se bloquea o un evento desbloquea a otra. En un RTOS expropiativo, si se desbloquea una tarea de mayor prioridad que la que corre, le quita el procesador de inmediato.
03Planificación y análisis
Para tareas periódicas, con período \( T_i \), tiempo de ejecución en el peor caso \( C_i \) y plazo igual al período, hay dos políticas clásicas. La de prioridad monótona en frecuencia (RM) da prioridad fija mayor a la tarea de período más corto. La de primero el plazo más cercano (EDF) elige en cada momento la tarea cuyo plazo vence antes. Las dos tienen una prueba de planificabilidad por utilización:
Entre 0,78 y 1, RM puede cumplir o no. Lo decide el análisis del tiempo de respuesta, que calcula el peor tiempo de cada tarea sumando las interrupciones de las de mayor prioridad, y se resuelve iterando hasta que el valor no cambia:
Tres tareas de períodos 5, 8 y 20, con plazo igual al período, en un procesador. Elegís el tiempo de ejecución de cada una y el planificador. El diagrama muestra un hiperperíodo completo (40 unidades): las marcas indican las activaciones y la cruz roja, un plazo perdido.
04Sincronización y comunicación
| Mecanismo | Para qué |
|---|---|
| Semáforo binario | Que una interrupción despierte a una tarea: la interrupción da el semáforo y la tarea, bloqueada en él, hace el trabajo largo |
| Semáforo contador | Llevar la cuenta de recursos o eventos pendientes |
| Mutex | Exclusión mutua sobre un recurso compartido, con herencia de prioridad |
| Cola de mensajes | Pasar datos entre tareas sin compartir variables |
| Banderas de eventos | Esperar una combinación de condiciones |
La trampa clásica es la inversión de prioridad. Una tarea de baja prioridad toma un recurso; una de alta prioridad lo pide y se bloquea; y una de prioridad media, que no usa el recurso, expropia a la baja y la demora indefinidamente, con la alta esperando detrás. La solución es la herencia de prioridad: la tarea que tiene el mutex hereda la prioridad de la que lo espera. En 1997, la sonda Mars Pathfinder se reiniciaba una y otra vez en Marte por este problema, y se corrigió remotamente habilitando la herencia de prioridad en su sistema operativo.
05Sistemas operativos de tiempo real en uso
| RTOS | Características |
|---|---|
| FreeRTOS | El más difundido en microcontroladores; núcleo de pocos kilobytes, licencia MIT |
| Zephyr | Proyecto de la Linux Foundation con controladores y pilas de red integrados |
| ThreadX | Certificado para aplicaciones de seguridad; hoy de código abierto en la fundación Eclipse |
| VxWorks | Comercial, en aviónica, defensa y misiones espaciales |
| RTEMS | Libre, muy usado en satélites e instrumentos científicos |
06En el laboratorio
Crear tres tareas periódicas en un microcontrolador, cada una con un pin que sube al empezar y baja al terminar. Medir con un analizador lógico los tiempos de respuesta y compararlos con el análisis.
Atender un pulsador con una interrupción que solo da un semáforo, y procesar el evento en una tarea. Medir la latencia entre el flanco y el comienzo de la tarea.
Armar el escenario de tres tareas con un semáforo binario y observar la demora de la tarea de alta prioridad. Repetir con un mutex con herencia de prioridad.
07Errores frecuentes
- Medir el tiempo promedio en lugar del peor caso. El análisis usa \( C_i \) de peor caso, con cachés vacías y todas las ramas más largas.
- Usar un semáforo binario donde hace falta un mutex. Sin herencia de prioridad aparece la inversión.
- Pilas demasiado chicas. Cada tarea tiene la suya; un desborde corrompe la memoria de otra y falla de forma impredecible.
- Llamar a funciones bloqueantes desde una interrupción. Las interrupciones solo usan las versiones especiales del RTOS, que no bloquean.
08Autoevaluación
¿Cuánto vale la cota de Liu y Layland para dos tareas?
\( 2(\sqrt{2} - 1) \approx 0{,}83 \).
Tareas (C, T) = (1, 4) y (2, 6). ¿Cuál es el tiempo de respuesta de la segunda con RM?
\( R = 2 + \lceil R/4 \rceil \cdot 1 \): empezando en 2 da 3, y con 3 da 3. Responde en 3, antes de su período de 6.
Un conjunto tiene utilización de 0,95. ¿Es planificable con EDF? ¿Y con RM?
Con EDF sí, porque no supera 1. Con RM no se sabe por la cota: hay que hacer el análisis de tiempo de respuesta.
¿Qué es la herencia de prioridad?
Que la tarea que tiene un mutex tome temporalmente la prioridad de la tarea más prioritaria que lo espera, para que ninguna intermedia la demore.
09Para ampliar
- Giorgio C. Buttazzo. Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications. 3.ª ed., Springer, 2011. La referencia de planificación de tiempo real: RM, EDF, análisis de respuesta y protocolos de recursos.
- Jane W. S. Liu. Real-Time Systems. Prentice Hall, 2000. El tratamiento teórico completo de los sistemas de tiempo real.
- Richard Barry. Mastering the FreeRTOS Real Time Kernel. Real Time Engineers Ltd., 2016. La guía práctica del autor de FreeRTOS: tareas, colas, semáforos e interrupciones con ejemplos.