miniaturadeimagen|Sistema de tiempo real Un sistema de tiempo real es un sistema informático que interacciona con su entorno físico y responde a los estímulos del entorno dentro de un plazo de tiempo determinado.

Los sistemas en tiempo real son aquellos que proporcionan la infraestructura necesaria para satisfacer la demanda de procesamiento de datos en tiempo real, en este tipo de sistemas se requiere dar una respuesta garantizada dentro de un límite de tiempo específico y predecible, usualmente en microsegundos. Esto se debe a que la lectura (input) del sistema, usualmente corresponde a algún movimiento o respuesta en el mundo real (output).

De acuerdo con Intel, algunos conceptos fundamentales en los sistemas de tiempo real son:

Latencia Es la medida de tiempo entre dos eventos; O bien, de acuerdo con el diccionario de Oxford, la latencia es “el tiempo que tarda un paquete en viajar por una red desde el emisor hasta el receptor.”

Jitter Se refiere a la diferencia en latencia entre las iteraciones del mismo evento. O bien de acuerdo con el diccionario de Oxford, el Jitter se refiere a la: “Variación aleatoria o irregular en la forma o la cadencia de un pulso que se repite regularmente.”

Precisión Es la medida de la variación de tiempo para completar tareas a través de múltiples componentes.

Los sistemas en tiempo real se diseñan utilizando técnicas y algoritmos específicos que garantizan que los requisitos de tiempo se cumplan. Estos algoritmos incluyen planificación de tareas en tiempo real, manejo de interrupciones, sincronización de procesos y control de tiempo.

Existen sistemas de tiempo real crítico (tiempo real duro), en los que los plazos de respuesta deben respetarse siempre estrictamente y una sola respuesta tardía a un suceso externo puede tener consecuencias fatales; y sistemas de tiempo real acrítico (tiempo real suave), en los que se pueden tolerar retrasos ocasionales en la respuesta a un suceso.

Un ejemplo general para los sistemas de tiempo real es el de un robot que necesita tomar una pieza de una banda sinfín. Si el robot llega tarde, la pieza ya no estará donde debía recogerla, por tanto, el trabajo se llevó a cabo incorrectamente, aunque el robot haya llegado al lugar adecuado. Si el robot llega antes de que la pieza llegue, la pieza aún no estará ahí y el robot puede bloquear su paso.

Para un sistema de tiempo real crítico (tiempo real duro), se tiene como ejemplo el caso del sistema de refrigeración de una central nuclear, el cual debe de tener respuestas en la menor cantidad de tiempo posible (preferiblemente de inmediato) y no acepta ningún retraso ni error en su proceso, pues esto llevaría a una catástrofe nuclear.

Ejemplo Imaginemos una intersección de calles muy transitada en una ciudad. Para gestionar eficientemente el flujo de tráfico en este punto crítico, se implementa un sistema de control de semáforos basado en tiempo real para ello realizaremos lo siguiente.

Censado de tráfico: Sensores estratégicamente ubicados en la intersección detectan la presencia de vehículos y peatones en cada dirección. Estos datos son continuamente recopilados y enviados al sistema de control central. Procesamiento en tiempo real: En el centro de control, un sistema informático dedicado procesa los datos de los sensores en tiempo real. Utilizando algoritmos avanzados, analiza la información para determinar la cantidad de vehículos y peatones en espera en cada dirección, así como la duración óptima de los ciclos del semáforo. Toma de decisiones: Basado en los datos procesados y en un algoritmo de optimización predefinido, el sistema toma decisiones precisas sobre la duración de cada fase del semáforo. Como decidir dar más tiempo de verde a la dirección con mayor congestión para aliviar el tráfico. Control de actuadores: Una vez que se toman las decisiones, el sistema activa los actuadores que controlan las luces del semáforo en tiempo real. Esto implica cambiar las luces de manera precisa y coordinada, asegurando una transición fluida entre las fases del semáforo. Optimización continua: El sistema monitorea constantemente el tráfico y realiza ajustes dinámicos en tiempo real para adaptarse a las condiciones cambiantes de la carretera. Como ajustar la duración de los ciclos del semáforo según el flujo de vehículos en tiempo real.

La Inversión de Prioridades (Priority Inversion) Este es un fenómeno crítico en sistemas en tiempo real (famoso por casi hacer fracasar la misión Mars Pathfinder de la NASA). Inversión de Prioridades y Herencia de Prioridad

En un sistema de tiempo real con planificación expulsiva (preemptive), puede ocurrir un fallo conocido como inversión de prioridades. Esto sucede cuando una tarea de alta prioridad ($T_{alta}$) se ve obligada a esperar indefinidamente por una tarea de baja prioridad ($T_{baja}$) porque esta última ha bloqueado un recurso compartido (como un semáforo o un mutex).

El escenario crítico se agrava si existe una tarea de prioridad media ($T_{media}$). Si $T_{media}$ interrumpe a $T_{baja}$ mientras esta tiene el recurso bloqueado, $T_{baja}$ no puede liberar el recurso. Como resultado, $T_{alta}$ queda bloqueada indirectamente por $T_{media}$, una tarea de menor importancia, violando las garantías de tiempo real del sistema.

Solución: Protocolo de Herencia de Prioridad

Para mitigar este riesgo, se implementa el protocolo de herencia de prioridad (Priority Inheritance Protocol). Bajo este esquema, si $T_{alta}$ es bloqueada por $T_{baja}$, el planificador eleva temporalmente la prioridad de $T_{baja}$ al nivel de $T_{alta}$.

Esto evita que tareas de prioridad media $T_{media}$ interrumpan a $T_{baja}$, permitiendo que esta termine su sección crítica y libere el recurso lo antes posible. Una vez liberado el recurso, $T_{baja}$ recupera su prioridad original y $T_{alta}$ puede continuar su ejecución.

Breve historia de los Sistemas en Tiempo Real El origen del tiempo real proviene de la historia reciente del control de procesos utilizando plataformas de computación digital. De hecho, un texto temprano y definitivo sobre el concepto fue publicado en 1965. El concepto de tiempo real también tiene sus raíces en la simulación por computadora, donde se dice que una simulación que se ejecuta al menos tan rápido como el proceso físico del mundo real que modela se ejecuta en tiempo real. Muchas simulaciones deben hacer un compromiso entre ejecutarse a la misma velocidad o más rápido que el tiempo real, con una fidelidad del modelo menor o mayor. Lo mismo ocurre con las interfaces gráficas de usuario (GUI) en tiempo real, como las proporcionadas por los motores de juegos de computadora. No mucho después del texto de Martin sobre sistemas en tiempo real en 1965, se publicó un artículo definitivo que estableció los fundamentos de una definición matemática de tiempo real estricto: "Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment" [Liu73]. Liu y Layland también definieron el concepto de tiempo real flexible en 1973; sin embargo, todavía no hay una definición formal universalmente aceptada de tiempo real flexible. Se han realizado numerosos trabajos e investigaciones para definir sistemas de calidad de servicio (QoS) donde los sistemas tienen permitido ocasionalmente no cumplir con los plazos o utilizan estrategias donde se utiliza la latencia de inicio y el almacenamiento en búfer para permitir la elasticidad en los sistemas en tiempo real.

El concepto de sistemas en tiempo real estricto se comprendió mejor a partir de la experiencia y los problemas observados en los sistemas implementados. Uno de los ejemplos más famosos en sus primeras etapas fue la sobrecarga de guía del módulo lunar del Apolo 11. El sistema del Apolo 11 sufrió una sobrecarga de recursos de la CPU que amenazaba con hacer que los servicios de guía de descenso no cumplieran con los plazos y casi resulta en la cancelación del primer alunizaje en la Luna. Durante el descenso del módulo lunar y el uso del sistema de radar, el astronauta Buzz Aldrin nota una alarma del sistema de guía por computadora. Según se relata en el libro "Failure Is Not an Option" [Kranz00], Buzz transmite por radio: "Alarma del programa. Es un 1202". Eugene Kranz, el director de operaciones de la misión Apolo 11, continúa explicando: "La alarma nos dice que la computadora está atrasada en su trabajo. Si las alarmas continúan, las actualizaciones de guía, navegación y visualización de la tripulación se volverán poco confiables. Si las alarmas persisten, la computadora podría detenerse por completo, abortando posiblemente la misión". En última instancia, basándose en la experiencia adquirida con esta condición de sobrecarga en simulación, se decidió continuar y hacer caso omiso de la alarma, como todos sabemos, el módulo Eagle aterrizó y Neil Armstrong luego puso pie de manera segura en la Luna. En general, ¿cómo se sabe que un sistema está sobrecargado en cuanto a los recursos de la CPU, memoria o E/S?

Claramente, es beneficioso mantener un margen de recursos cuando el costo del fallo es demasiado alto para ser aceptable (como fue el caso del módulo lunar), pero ¿cuánto margen es suficiente? ¿Cuándo es seguro continuar con la operación a pesar de la escasez de recursos? En algunos casos, la escasez de recursos puede ser simplemente una sobrecarga temporal de la cual el sistema puede recuperarse y seguir brindando servicios que cumplan con los requisitos de diseño. La alarma 1202 puede no haber sido la causa raíz de la sobrecarga, de hecho, algunos informes apuntan a la alarma 1201 como la causa, pero lo importante es que la sobrecarga del procesador indicada por el 1202 fue el resultado de un mayor cómputo del que se podía manejar dentro de los plazos requeridos cuando se agregó el procesamiento de la alarma a la carga de trabajo normal. Peter Adler proporciona un relato más detallado para aquellos lectores interesados en los relatos históricos precisos según lo indicado por los ingenieros que estuvieron directamente involucrados [Adler 98].

Desde el Apolo 11, se han observado problemas en tiempo real aún más interesantes en el campo, lo que ha demostrado que el diseño de sistemas en tiempo real es aún más complicado que simplemente garantizar márgenes. Por ejemplo, la nave espacial Mars Pathfinder estuvo a punto de perderse debido a un problema de procesamiento en tiempo real. El problema no fue debido a una sobrecarga, sino a una inversión de prioridades que causó que se perdiera un plazo a pesar de tener un margen razonable de la CPU. Si bien se requiere un acceso seguro para la corrección funcional, cumplir con los plazos de respuesta también es un requisito para los sistemas en tiempo real. Un sistema en tiempo real debe producir respuestas funcionalmente correctas a tiempo, antes de los plazos para la corrección general del sistema. Con cierta experiencia en el desarrollo de sistemas, la mayoría de los ingenieros están familiarizados con cómo diseñar y probar un sistema para que funcione correctamente. Además, la mayoría de los ingenieros de hardware conocen métodos para diseñar la sincronización de la lógica digital y verificar su corrección. Cuando el hardware, el firmware y el software se combinan en un sistema integrado en tiempo real, es necesario diseñar y probar el tiempo de respuesta para asegurarse de que el sistema integrado cumpla con los requisitos de los plazos. Esto requiere un diseño y prueba a nivel de sistema que vayan más allá de los métodos de hardware o software típicamente utilizados.

Como ha demostrado la historia, incluso los sistemas que fueron ampliamente probados no lograron proporcionar respuestas dentro de los plazos requeridos. ¿Cómo ocurren las sobrecargas o inversiones inesperadas? Para responder a estas preguntas, primero se debe entender la teoría fundamental del tiempo real estricto.

Beneficios