Qué es el tiempo real

01 · Punto de partida

Lo correcto y a tiempo

En el taller anterior construiste un firmware que parpadea un LED con una espera ocupada. Tiene un defecto que ya notaste: mientras espera, no hace otra cosa. Si un evento llega durante la espera, se atiende cuando termina, quizá medio segundo después. Para un LED no importa. Ahora pensá en un controlador de motor que debe actualizar su salida cada 100 µs, o en un sistema de frenado que debe reaccionar a una señal de rueda en pocos milisegundos: ahí llegar tarde es fallar.

Los programas de una computadora común están pensados para el mejor rendimiento promedio: si una operación tarda un poco más a veces, no pasa nada. Un sistema de tiempo real se juzga por otro criterio: por lo que ocurre en el peor caso. Un promedio excelente no sirve si de vez en cuando se pierde un plazo crítico.

El vocabulario de este tema reaparece en cada uno de los siguientes: interrupciones, temporizadores, planificación y sistemas operativos de tiempo real son, todos, herramientas para cumplir plazos.

02 · La definición

Qué es (y qué no es) el tiempo real

Un sistema de tiempo real es aquel cuya corrección depende no solo del resultado lógico de sus cálculos, sino también del instante en que se producen. La especificación incluye frases como «al detectar el pulso, la salida debe cambiar en menos de 200 µs» o «cada 10 ms, tomar una muestra». Si el sistema produce el valor correcto después, se considera que falló.

De esa definición salen varias aclaraciones que desarman mitos comunes:

• No es lo mismo que rápido. Un sistema lentísimo puede ser de tiempo real si su plazo es de un minuto y lo cumple siempre. Un sistema veloz no lo es si a veces tarda más de lo que su plazo permite.
• Lo importante es la previsibilidad (o determinismo): poder afirmar con seguridad cuánto como máximo puede tardar una respuesta.
• El plazo lo fija el entorno físico, no el programador: la velocidad de un motor, la frecuencia de una señal, el tiempo de reacción de una máquina.
• No depende de usar o no un RTOS. Un superloop bien hecho puede cumplir plazos exigentes; un RTOS mal usado puede perderlos. Un RTOS es una herramienta para razonar sobre los plazos, no una garantía.

Un ejemplo de cada lado: reproducir una canción de MP3 en un teléfono es una tarea con plazos (cada fragmento de audio debe estar listo antes de que se acabe el anterior), pero un fallo ocasional solo produce un chasquido. El control de inyección de un motor tiene plazos de microsegundos, y un fallo ocasional puede dañar el motor. Ambos son «de tiempo real», en grados muy distintos.

03 · Vocabulario básico

Plazos y tipos de tareas

Una tarea de tiempo real es una unidad de trabajo que debe ejecutarse en respuesta a algo: el paso del tiempo o un evento externo. Se caracteriza por tres números:

• El plazo (deadline, D): el tiempo máximo permitido entre el evento y la finalización de la respuesta.
• El tiempo de ejecución (C): cuánto procesador necesita la tarea para completar su trabajo.
• El período (T) para las tareas que se repiten: el intervalo entre activaciones sucesivas. Muchas veces el plazo coincide con el período («terminar antes de la próxima activación»).

Las esporádicas son las más interesantes para el diseño: se conoce el peor caso (tantas activaciones por segundo como máximo) y por eso se puede razonar. Las aperiódicas puras no tienen cota y solo se pueden tratar con un criterio de mejor esfuerzo. Por eso, cuando una especificación dice «puede llegar un mensaje en cualquier momento», lo primero que hay que preguntar es: ¿cuál es la mayor frecuencia posible?

El esquema contiene todo el vocabulario del bloque. Entre el evento y el plazo hay un tramo de tiempo disponible. Parte se consume antes de que la tarea siquiera empiece (la latencia), parte en ejecutarse, y lo que sobra es el margen. Un diseño sano mantiene el margen positivo incluso en el peor caso.

04 · El tiempo que no ves

Latencia y tiempo de respuesta

La latencia es el tiempo que transcurre entre el instante en que ocurre un evento y el instante en que el software empieza a responder. El tiempo de respuesta agrega, además, lo que tarda la ejecución. Para un programador, la latencia es la parte más escurridiza porque no se ve en el código: depende de lo que ocurre alrededor.

Las contribuciones a la latencia son siempre las mismas:

Un ejemplo ayuda a ver cómo se suman. Una tarea necesita 1,2 ms para completarse. Su ISR puede tardar en arrancar 0,1 ms en el peor caso (hardware más una interrupción de mayor prioridad que justo se ejecuta). Además, otra interrupción de alta prioridad, que se dispara cada tanto, puede consumir 0,4 ms. El peor tiempo de respuesta es 0,1 + 1,2 + 0,4 = 1,7 ms. Con un plazo de 2 ms queda un margen de 0,3 ms: cumple, pero ajustado (el 15 % del plazo). Con un plazo de 1,5 ms, no cumple, aunque el promedio sea muchísimo menor.

Esa suma pesimista, tomando cada componente en su peor valor, es la actitud mental del tiempo real. No importa cuán probable sea que todo coincida: importa si puede coincidir.

05 · La variación

El jitter

Si la latencia siempre fuera la misma, bastaría con restarla. El problema es que varía. El jitter es esa variación: la diferencia entre el valor máximo y el mínimo (o la desviación típica) del tiempo de una respuesta, de la latencia o de un período que debería ser constante. Una tarea que debería ejecutarse cada 10 ms y lo hace unas veces a los 9,95 y otras a los 10,08 ms tiene un jitter de 130 µs.

El jitter importa por dos motivos distintos:

• Plazos. Es la parte de la latencia que no se puede predecir. El peor caso incluye el jitter máximo.
• Calidad de la señal. Cuando algo debe ocurrir a intervalos regulares (muestrear una señal, generar una forma de onda, mover un motor paso a paso), el jitter se convierte directamente en error.

El efecto sobre el muestreo tiene una fórmula conocida. Si una señal senoidal de frecuencia f y amplitud A se muestrea con un error de tiempo Δt, el error de amplitud máximo es:

Con una señal de 1 kHz y un jitter de 10 µs, el error llega a 2π × 1000 × 10 × 10⁻⁶ ≈ 0,063, es decir el 6,3 % de la amplitud. Un conversor de 12 bits tiene una resolución de 1/4096 ≈ 0,024 %: el jitter degrada la medida unas 260 veces más que la cuantización. Expresado como relación señal a ruido, un jitter eficaz σ produce SNR = −20·log₁₀(2π·f·σ): para 5 µs a 1 kHz, 30 dB, que equivalen a unos 4,7 bits efectivos de los 12 del conversor.

Por eso los diseñadores serios no disparan las conversiones desde el software. Un temporizador de hardware inicia cada conversión sin intervención del procesador, con un jitter de nanosegundos, y recién después el software recoge el resultado. Delegar la temporización al hardware es la herramienta más potente contra el jitter (tema 17).

06 · Cuánto duele llegar tarde

Tiempo real duro, firme y blando

No todos los plazos tienen la misma gravedad. La clasificación clásica depende de qué ocurre si uno se pierde:

Un mismo producto mezcla clases. Un cargador de baterías tiene un lazo de protección contra sobrecorriente de tiempo real duro (microsegundos), un control de carga de tiempo real firme (milisegundos) y una pantalla y un registro de eventos de tiempo real blando (cientos de milisegundos). Ahí está la clave de la arquitectura: dar el mejor tratamiento solo a lo que lo necesita y dejar el resto en un nivel de esfuerzo menor. Cuando todo se trata como si fuera duro, el diseño se vuelve caro y frágil; cuando todo se trata como blando, falla lo crítico.

Y esa clasificación orienta el método de verificación. Para el tiempo real duro hace falta un análisis del peor caso. Para el blando alcanza con medir bajo carga y mirar los percentiles (por ejemplo, que el 99,9 % de las respuestas llegue antes del plazo). Confundir los dos métodos es la fuente de los fallos más caros, como muestra el laboratorio de este tema.

07 · Conocer los números

El peor caso y cómo medirlo

El tiempo de ejecución en el peor caso (WCET, worst-case execution time) de una tarea es el máximo que podría llegar a tardar en cualquier circunstancia. Conocerlo es el primer dato para cualquier análisis. Hay dos formas de obtenerlo:

• Por análisis. Estudiar el código y el hardware para calcular una cota superior segura: recorrer el camino más largo del programa, sumar los ciclos de cada instrucción, considerar los estados de espera de la memoria. Es lo que exige el tiempo real duro, y hay herramientas específicas, pero también es costoso.
• Por medición. Ejecutar el código muchas veces, bajo carga, con datos variados, y quedarse con el máximo observado. Es práctico, pero da solo una cota inferior del WCET: el verdadero peor caso puede no haber aparecido.

Las dos herramientas de medición más usadas en un microcontrolador:

Un pin y un analizador lógico

Se pone un pin de pruebas en alto al entrar a la tarea y en bajo al salir. Con un analizador lógico se ve la duración del pulso, y también el jitter si se superponen muchas capturas. Si se conecta además la señal de entrada que dispara la tarea, la distancia entre el flanco de entrada y el comienzo del pulso es la latencia. Es una medición casi sin costo para el programa (un par de instrucciones) y la más honesta, porque mide lo que ocurre en el exterior.

El contador de ciclos del núcleo

Los Cortex-M3, M4 y M7 incluyen un contador de ciclos de reloj (DWT, Data Watchpoint and Trace) que se puede leer como un registro. No existe en el Cortex-M0 ni en el M0+.

#define DEMCR       (*(volatile uint32_t *)0xE000EDFC)
#define DWT_CTRL    (*(volatile uint32_t *)0xE0001000)
#define DWT_CYCCNT  (*(volatile uint32_t *)0xE0001004)

void ciclos_iniciar(void) {
    DEMCR    |= (1u << 24);        /* TRCENA: habilita el bloque de seguimiento */
    DWT_CYCCNT = 0;
    DWT_CTRL |= 1u;                /* CYCCNTENA: empieza a contar */
}

static inline uint32_t ciclos(void) { return DWT_CYCCNT; }

uint32_t peor_ciclos = 0;

void medir_tarea(void) {
    uint32_t t0 = ciclos();
    tarea_a_medir();
    uint32_t dt = ciclos() - t0;   /* la resta sin signo es correcta aunque el contador dé la vuelta */
    if (dt > peor_ciclos) peor_ciclos = dt;
}

Con el reloj de 72 MHz, cada ciclo es 13,9 ns. Si peor_ciclos vale 86.400, la tarea tardó como máximo 1,2 ms en lo observado. Dos advertencias sobre esta técnica. La medición está en ciclos, así que hay que dividir por la frecuencia real (tema 12). Y el máximo observado depende del ensayo: si durante la prueba nunca coincidió una interrupción con la tarea, la medición subestima.

Por qué un ensayo largo sin fallas no alcanza

Imaginá una perturbación que ocurre una de cada mil activaciones (una sección crítica larga, una escritura en flash que bloquea la lectura). Si ensayás 100 activaciones, la probabilidad de verla es de apenas el 9,5 %; con 1000, del 63 %; con 10.000, prácticamente del 100 %. Un sistema que pasa un ensayo de 100 activaciones sin ningún incumplimiento no está demostrando nada sobre un evento que ocurre una vez cada mil. Ese es precisamente el tipo de falla que aparece en el campo, después de semanas de funcionamiento perfecto, y que nadie logra reproducir en el laboratorio. El laboratorio de este tema lo muestra con números.

08 · Principios

Diseñar para el tiempo real

Cumplir plazos se logra desde el diseño, no se agrega al final. Un conjunto de principios que se aplican en todo el bloque siguiente:

• Acotar todo. Cada bucle debe tener un máximo de iteraciones conocido; cada espera, un límite de tiempo; cada buffer, un tamaño fijo. Un while sin cota es un plazo sin garantía.
• Evitar lo impredecible en los caminos críticos. malloc y free (tiempo variable por la fragmentación), printf (lento y de duración dependiente de los datos), la aritmética de punto flotante por software (cientos de ciclos que varían) y los accesos a memorias lentas (tema 28).
• Mantener cortas las secciones críticas. Cada microsegundo con interrupciones deshabilitadas se suma al peor caso de todas las respuestas.
• Asignar prioridades por urgencia. Lo que tiene el plazo más corto debe poder interrumpir a todo lo demás (temas 15 y 20).
• Delegar al hardware. Temporizadores, DMA y periféricos con búferes hacen trabajo sin que el software interfiera con su tiempo (temas 17 y 21).
• Dejar margen. Una utilización del procesador por encima del 70 % u 80 % hace que cualquier variación empuje las respuestas fuera de plazo. La utilización de un conjunto de tareas periódicas es U = Σ Cᵢ / Tᵢ; con tres tareas de 2/10, 1/20 y 5/50 ms es 0,2 + 0,05 + 0,1 = 35 %.
• Vigilar los plazos en ejecución. Detectar cuando una tarea se pasó de su tiempo (con un contador, con el watchdog) y decidir qué hacer: no suponer que nunca ocurre (tema 38).

Estas reglas no hacen que el sistema sea rápido; hacen que sea predecible. Un sistema predecible puede analizarse, y uno analizable puede garantizarse.

09 · Analogía con programación

Un ensayo de tiempos, en Python

Este programa simula una tarea que se ejecuta muchas veces. En cada activación hay una latencia pequeña con algo de jitter, un tiempo de ejecución que varía un ±20 % alrededor de 1 ms y, en una de cada mil activaciones, una perturbación de 6 ms (una interrupción larga o una operación de flash, por ejemplo). El plazo es de 3 ms. Se corre el ensayo con 100, 1000 y 10.000 activaciones y se informa qué se observó. El generador de números es reproducible, así que cada ensayo más largo contiene al anterior.

SEMILLA = 2025
LAT_MIN, LAT_VAR = 0.02, 0.08       # ms: latencia entre 0,02 y 0,10 ms
EJECUCION = 1.0                     # ms (±20 %)
PERTURBACION = 6.0                  # ms, con probabilidad 1/1000 por activación
PLAZO = 3.0                         # ms


def azar():
    x = SEMILLA
    while True:
        x = (x * 1664525 + 1013904223) & 0xFFFFFFFF
        yield x / 4294967296


def ensayo(n):
    g = azar()
    respuestas, perdidos, vistas = [], 0, 0
    for _ in range(n):
        r1, r2, r3 = next(g), next(g), next(g)
        latencia = LAT_MIN + LAT_VAR * r1
        ejecucion = EJECUCION * (0.8 + 0.4 * r2)
        perturbacion = PERTURBACION if r3 < 0.001 else 0.0
        vistas += perturbacion > 0
        respuesta = latencia + ejecucion + perturbacion
        respuestas.append(respuesta)
        perdidos += respuesta > PLAZO
    return respuestas, perdidos, vistas


peor_teorico = LAT_MIN + LAT_VAR + EJECUCION * 1.2 + PERTURBACION
print(f"Peor caso teórico: {peor_teorico:.2f} ms (plazo {PLAZO:.1f} ms)\n")
for n in (100, 1000, 10000):
    resp, perdidos, vistas = ensayo(n)
    media = sum(resp) / n
    print(f"{n:6d} activaciones: media {media:.2f} ms, máx {max(resp):.2f} ms, "
          f"jitter {max(resp) - min(resp):.2f} ms, perturbaciones vistas {vistas}, plazos perdidos {perdidos}")

Resultado: el peor caso teórico es 7,30 ms, muy por encima del plazo de 3 ms. Con 100 y con 1000 activaciones, el ensayo no ve ninguna perturbación: la respuesta máxima es de 1,27 y 1,30 ms, no se pierde ningún plazo y todo parece perfecto. Con 10.000 activaciones aparecen 9 perturbaciones, la respuesta máxima sube a 7,20 ms, el jitter pasa de unos 0,45 ms a 6,4 ms y se pierden 9 plazos. El sistema era el mismo en los tres casos; cambió solo la longitud del ensayo. Probá PLAZO = 8.0: ahora el peor caso (7,3 ms) cabe en el plazo, y el sistema cumple de verdad. Probá también EJECUCION = 3.0.

La conclusión es la central del tema: medir da un mínimo, no un máximo. Para afirmar que un sistema de tiempo real duro cumple, hay que conocer el peor caso por análisis; las pruebas solo lo complementan.

10 · Exploración interactiva

¿Cumple el plazo?

El laboratorio ejecuta el mismo ensayo del apartado anterior. Elegí el tiempo de ejecución medio de la tarea, el plazo exigido, la perturbación ocasional y la cantidad de activaciones del ensayo. Verás las estadísticas medidas, el histograma de tiempos de respuesta y, lo más importante, el peor caso teórico, que no depende del ensayo. El veredicto distingue «cumple y está garantizado» de «cumplió en el ensayo, sin garantía».

—

Recorrido guiado

1. Con los valores iniciales (1 ms, plazo de 3 ms, perturbación de 6 ms una vez cada mil, 100 activaciones) el resultado es «Cumplió en el ensayo, sin garantía»: ningún plazo perdido, respuesta máxima de 1,27 ms, pero un peor caso teórico de 7,30 ms. El ensayo ni siquiera vio una perturbación.
2. Subí a 1.000 activaciones: el resultado es el mismo. Con una perturbación por cada mil activaciones, mil no alcanzan para verla (la probabilidad de verla es del 63 %, no del 100 %).
3. Subí a 10.000: aparecen 9 perturbaciones, se pierden 9 plazos y la respuesta máxima llega a 7,2 ms. El histograma ahora muestra una «cola» aislada, lejos del grueso. El sistema siempre fue el mismo.
4. Con perturbación frecuente (0,3 ms cada 50): se ve desde el primer ensayo, el jitter crece y aun así cumple, con un peor caso de 1,6 ms. Un efecto frecuente es fácil de encontrar; uno raro no.
5. Subí el plazo a 8 ms con la perturbación de 6 ms y 10.000 activaciones: ahora «Cumple, y está garantizado», porque el peor caso teórico (7,3 ms) cabe. Esa es la diferencia entre una prueba superada y una garantía.
6. Poné la ejecución en 3 ms con plazo de 2 ms: pierde plazos en todas las activaciones. Cuando el trabajo es mayor que el plazo, ninguna perturbación hace falta.

11 · Método de trabajo

Método para analizar un requisito de tiempo

1. Escribí cada requisito como un plazo medible: evento de entrada, respuesta de salida y tiempo máximo. «Responder rápido» no es un requisito (tema 2).
2. Clasificalo como duro, firme o blando según la consecuencia de incumplirlo, y preguntá cuál es la frecuencia máxima del evento.
3. Estimá el tiempo de ejecución en el peor caso de la tarea, por análisis del código o por medición con un contador de ciclos o un pin, con datos variados y bajo carga.
4. Listá todo lo que puede retrasar la respuesta: latencia del hardware, interrupciones de mayor prioridad, secciones críticas, bloqueos, esperas de memoria.
5. Sumá el peor caso de cada componente y compará con el plazo. Calculá el margen.
6. Calculá la utilización de todas las tareas periódicas y asegurate de no pasar de un 70 u 80 %.
7. Medí en el hardware con un analizador lógico: latencia de punta a punta, duración y jitter, durante un tiempo largo y bajo la carga máxima prevista.
8. Documentá el análisis junto con las mediciones, y repetilo cada vez que se agrega una función que toca los caminos críticos.

El orden refleja la jerarquía de confianza: primero se razona (análisis), después se comprueba (medición). Un diseño que solo tiene mediciones es una apuesta; uno que solo tiene análisis, una hipótesis; los dos juntos son ingeniería.

12 · Comprensión

Confusiones frecuentes

13 · Práctica guiada

Predecí antes de comprobar

1. Clasificar

Clasificá como tiempo real duro, firme o blando: (a) el control de un freno regenerativo; (b) mostrar la temperatura en una pantalla; (c) un decodificador de video que descarta cuadros que llegan tarde; (d) la protección contra cortocircuito de una fuente; (e) el envío de datos a un servidor en la nube.

2. Sumar el peor caso

Una tarea tarda como máximo 0,9 ms. Su latencia de arranque es de hasta 0,05 ms, una interrupción de mayor prioridad puede ocupar 0,3 ms durante su ejecución, y una sección crítica del resto del programa puede retrasarla 0,15 ms. Si el plazo es de 1,5 ms, ¿cumple? ¿Qué margen queda?

3. Jitter y muestreo

Se muestrea una señal de 2 kHz con un jitter eficaz de 2 µs. ¿Qué relación señal a ruido impone el jitter y cuántos bits efectivos de un conversor significa?

4. Latencia de interrupción

La latencia de entrada a una interrupción en un Cortex-M3 es de 12 ciclos. ¿Cuánto es a 72 MHz y a 8 MHz?

5. Utilización

Tres tareas periódicas: A (C = 2 ms, T = 10 ms), B (C = 1 ms, T = 20 ms) y C (C = 5 ms, T = 50 ms). ¿Cuál es la utilización? Si se agrega una tarea D con C = 3 ms y T = 5 ms, ¿qué pasa?

6. Cuántas veces ensayar

Una perturbación ocurre con probabilidad 1/1000 por activación. ¿Qué probabilidad hay de verla al menos una vez en 100, 1000 y 10.000 activaciones?

14 · Síntesis

Ideas para recordar

¿Listo para el tema 14?

Antes de avanzar, definí con tus palabras plazo, latencia y jitter; explicá por qué el promedio no sirve para juzgar un sistema de tiempo real duro; y decí cómo medirías la latencia entre una señal de entrada y la respuesta de tu firmware. Si podés justificar las tres respuestas, tenés el vocabulario del bloque.

En el próximo tema volvemos al superloop y el polling, la arquitectura del taller, y la miramos con estos conceptos: ¿qué latencia tiene el peor caso de un bucle principal, y cuándo es suficiente?