Computación en tiempo real

La computación en tiempo real ( RTC ) es el término informático para los sistemas de hardware y software sujetos a una "restricción de tiempo real", por ejemplo, desde el evento hasta la respuesta del sistema . ^{[ 1 ]} Los programas en tiempo real deben garantizar la respuesta dentro de las restricciones de tiempo especificadas, a menudo denominadas "plazos". ^{[ 2 ]}

El término "tiempo real" también se utiliza en simulación para indicar que el reloj de la simulación funciona a la misma velocidad que un reloj real.

Las respuestas en tiempo real suelen entenderse en el orden de los milisegundos, y a veces de los microsegundos. Un sistema que no se especifica como operativo en tiempo real no puede garantizar una respuesta dentro de un plazo determinado, aunque se pueden proporcionar tiempos de respuesta típicos o esperados . El procesamiento en tiempo real falla si no se completa dentro de un plazo específico en relación con un evento; los plazos deben cumplirse siempre, independientemente de la carga del sistema .

Un sistema en tiempo real se ha descrito como aquel que "controla un entorno al recibir datos, procesarlos y devolver los resultados con la suficiente rapidez como para afectar al entorno en ese momento". ^{[ 3 ]} El término "tiempo real" se utiliza en el control de procesos y en los sistemas empresariales para significar "sin retraso significativo".

El software en tiempo real puede utilizar uno o más de los siguientes elementos: lenguajes de programación síncronos , sistemas operativos en tiempo real (RTOS) y redes en tiempo real. Cada uno de ellos proporciona marcos esenciales sobre los que construir una aplicación de software en tiempo real.

Los sistemas utilizados para muchas aplicaciones críticas de seguridad deben ser en tiempo real, como por ejemplo para el control de aeronaves fly-by-wire o frenos antibloqueo , los cuales exigen una respuesta mecánica inmediata y precisa. ^{[ 4 ]}

El término "tiempo real" deriva de su uso en las primeras simulaciones , donde un proceso del mundo real se simulaba a una velocidad que coincidía con la del proceso real (ahora llamada simulación en tiempo real para evitar ambigüedades). Las computadoras analógicas , por lo general, eran capaces de simular a un ritmo mucho más rápido que el tiempo real, una situación que podía ser tan peligrosa como una simulación lenta si no se reconocía y se tenía en cuenta.

Los miniordenadores, especialmente a partir de la década de 1970, cuando se integraban en sistemas embebidos específicos como los escáneres DOG ( gráficos digitales en pantalla ), aumentaron la necesidad de respuestas de baja latencia y basadas en prioridades para interacciones importantes con los datos entrantes. Los sistemas operativos como RDOS (Real-Time Disk Operating System) de Data General y RTOS con planificación en segundo plano y primer plano , así como RT-11 de Digital Equipment Corporation, datan de esta época. La planificación en segundo plano y primer plano permitía que las tareas de baja prioridad utilizaran tiempo de CPU cuando no era necesario ejecutar ninguna tarea en primer plano, y otorgaba prioridad absoluta en primer plano a los hilos/tareas con la máxima prioridad. Los sistemas operativos en tiempo real también se utilizaban para tareas multiusuario de tiempo compartido . Por ejemplo, Data General Business Basic podía ejecutarse en primer plano o en segundo plano de RDOS e introducía elementos adicionales en el algoritmo de planificación para hacerlo más adecuado para personas que interactuaban a través de terminales tontas .

Los primeros ordenadores personales se utilizaban a veces para la computación en tiempo real. La posibilidad de desactivar otras interrupciones permitía la creación de bucles con temporización definida, y la baja latencia de las interrupciones posibilitaba la implementación de un sistema operativo en tiempo real, dando menor prioridad a la interfaz de usuario y a las unidades de disco que al hilo de ejecución en tiempo real. En comparación, el controlador de interrupciones programable de la familia de procesadores Intel x86 genera una latencia muy elevada, y el sistema operativo Windows no es ni un sistema operativo en tiempo real ni permite que un programa tome el control total de la CPU y utilice su propio planificador , sin usar lenguaje máquina nativo y, por lo tanto, evitando todo el código de Windows que genera interrupciones. Sin embargo, existen varias bibliotecas de programación que ofrecen capacidades en tiempo real en un lenguaje de alto nivel para diversos sistemas operativos, como por ejemplo, Real-time Java . Microprocesadores posteriores, como el Motorola 68000 y sus sucesores (68010, 68020, ColdFire , etc.), también se popularizaron entre los fabricantes de sistemas de control industrial. Este ámbito de aplicación es uno en el que el control en tiempo real ofrece ventajas reales en términos de rendimiento y seguridad del proceso.

Se dice que un sistema es de tiempo real si la corrección total de una operación depende no solo de su corrección lógica, sino también del tiempo en que se realiza. ^{[ 5 ]} Los sistemas de tiempo real, así como sus plazos, se clasifican según la consecuencia de no cumplir con un plazo: ^{[ 6 ]}

• Difícil : no cumplir con un plazo es un fallo total del sistema. 
• Firme : se toleran los retrasos ocasionales en los plazos de entrega, pero pueden afectar la calidad del servicio del sistema. La utilidad de un resultado es nula después de su fecha límite. 
• Suave : la utilidad de un resultado disminuye después de su fecha límite, lo que degrada la calidad del servicio del sistema. 

Así, el objetivo de un sistema de tiempo real estricto es garantizar el cumplimiento de todos los plazos, mientras que en los sistemas de tiempo real flexible el objetivo es cumplir con un subconjunto específico de plazos para optimizar ciertos criterios propios de la aplicación. Los criterios optimizados dependen de la aplicación, pero algunos ejemplos típicos incluyen maximizar el número de plazos cumplidos, minimizar el retraso de las tareas y maximizar el número de tareas de alta prioridad que cumplen con sus plazos.

Los sistemas de tiempo real estricto se utilizan cuando es imperativo reaccionar ante un evento dentro de un plazo estricto. Estas garantías rigurosas son necesarias para sistemas en los que no reaccionar en un intervalo de tiempo determinado causaría grandes pérdidas, especialmente daños físicos al entorno o amenazas a la vida humana (aunque la definición estricta simplemente establece que no cumplir con el plazo constituye una falla del sistema). Algunos ejemplos de sistemas de tiempo real estricto:

• El sistema de control del motor de un automóvil es un sistema de tiempo real estricto, ya que una señal retardada puede provocar fallos o daños en el motor.
• Sistemas médicos como los marcapasos cardíacos . Aunque la función de un marcapasos es sencilla, debido al riesgo potencial para la vida humana, estos sistemas médicos suelen someterse a pruebas y certificaciones exhaustivas, lo que a su vez requiere computación en tiempo real para ofrecer garantías demostrables de que un fallo es improbable o imposible.
• Los controladores de procesos industriales, como una máquina en una línea de montaje , pueden sufrir daños. Si la máquina se retrasa, el artículo podría quedar fuera de su alcance (sin ser procesado), o bien, la máquina o el producto podrían resultar dañados al activarse el robot en el momento incorrecto. Si se detecta el fallo, ambos casos provocarían la detención de la línea de montaje, lo que ralentizaría la producción. Si no se detecta el fallo, un producto defectuoso podría continuar la producción o causar daños en etapas posteriores.
• Los sistemas de tiempo real estricto suelen interactuar a bajo nivel con el hardware físico, en sistemas embebidos . Los primeros sistemas de videojuegos, como el Atari 2600 y los gráficos vectoriales de Cinematronics , tenían requisitos de tiempo real estricto debido a la naturaleza del hardware gráfico y de temporización.
• Los softmodems reemplazan un módem de hardware con un software que se ejecuta en la CPU de la computadora . Este software debe ejecutarse cada pocos milisegundos para generar los siguientes datos de audio que se emitirán. Si estos datos se retrasan, el módem receptor perderá la sincronización, lo que provocará una larga interrupción mientras se restablece la sincronización o, incluso, la pérdida total de la conexión.
• Muchos tipos de impresoras tienen requisitos estrictos de tiempo real, como las de inyección de tinta (la tinta debe depositarse en el momento preciso cuando el cabezal de impresión recorre la página), las impresoras láser (el láser debe activarse en el momento exacto cuando el haz recorre el tambor giratorio) y las impresoras matriciales y de línea (el mecanismo de impacto debe activarse en el momento preciso cuando el mecanismo de impresión se alinea con la salida deseada). Un fallo en cualquiera de estos mecanismos provocaría la ausencia de impresión o una impresión desalineada.

En el contexto de los sistemas multitarea , la política de planificación normalmente se basa en prioridades ( planificadores con prioridad ). En algunas situaciones, estos pueden garantizar un rendimiento en tiempo real estricto (por ejemplo, si el conjunto de tareas y sus prioridades se conocen de antemano). Hay otros planificadores en tiempo real estricto, como rate-monotonic , que no es común en sistemas de propósito general, ya que requiere información adicional para planificar una tarea: a saber, una estimación límite o del peor caso para cuánto tiempo debe ejecutarse la tarea. Existen algoritmos específicos para planificar dichas tareas en tiempo real estricto, como earliest deadline first , que, ignorando la sobrecarga del cambio de contexto , es suficiente para cargas del sistema inferiores al 100%. ^{[ 7 ]} Los nuevos sistemas de planificación superpuestos, como un planificador de partición adaptativo, ayudan a gestionar grandes sistemas con una mezcla de aplicaciones en tiempo real estricto y no en tiempo real.

Los sistemas firmes en tiempo real tienen una definición más imprecisa, y algunas clasificaciones no los incluyen, distinguiendo únicamente entre sistemas en tiempo real estrictos y flexibles. Algunos ejemplos de sistemas firmes en tiempo real:

• La máquina de la línea de montaje descrita anteriormente como de tiempo real estricto podría considerarse, en cambio, de tiempo real firme . Un plazo incumplido sigue generando un error que debe corregirse: podría haber maquinaria para marcar una pieza como defectuosa o expulsarla de la línea de montaje, o bien, se podría detener la línea para que un operario corrija el problema. Sin embargo, siempre que estos errores sean poco frecuentes, pueden tolerarse.

Los sistemas de tiempo real flexible se utilizan normalmente para resolver problemas de acceso concurrente y la necesidad de mantener actualizados varios sistemas conectados ante situaciones cambiantes. Algunos ejemplos de sistemas de tiempo real flexible:

• Software que mantiene y actualiza los planes de vuelo de los aviones comerciales . Los planes de vuelo deben mantenerse razonablemente actualizados, pero pueden funcionar con una latencia de pocos segundos.
• Los sistemas de audio y vídeo en directo también suelen ser de tiempo real flexible. Un fotograma de audio que se reproduce con retraso puede provocar una breve interrupción (y, en consecuencia, retrasar todo el audio posterior, dando la impresión de que se reproduce más lento de lo normal), pero esto puede ser preferible a las alternativas de seguir reproduciendo silencio, estática, un fotograma de audio anterior o datos estimados. Un fotograma de vídeo retrasado suele causar aún menos molestias a los espectadores. El sistema puede seguir funcionando y recuperarse en el futuro mediante metodologías de predicción y reconfiguración de la carga de trabajo. ^{[ 8 ]}
• De forma similar, los videojuegos suelen ser de tiempo real flexible, especialmente cuando intentan alcanzar una velocidad de fotogramas objetivo . Como la siguiente imagen no se puede calcular con antelación, puesto que depende de las acciones del jugador, solo se dispone de un breve lapso de tiempo para realizar todos los cálculos necesarios para generar un fotograma de vídeo antes de que este deba mostrarse. Si no se cumple el plazo, el juego puede continuar a una velocidad de fotogramas inferior; según el juego, esto puede afectar únicamente a los gráficos (mientras que la jugabilidad continúa a velocidad normal), o bien la propia jugabilidad puede ralentizarse (algo común en las consolas antiguas de tercera y cuarta generación ).

A veces se confunde la computación en tiempo real con la computación de alto rendimiento , pero esta clasificación no es precisa. ^{[ 11 ]} Por ejemplo, una supercomputadora masiva que ejecuta una simulación científica puede ofrecer un rendimiento impresionante, pero no está ejecutando una computación en tiempo real. Por el contrario, una vez que el hardware y el software de un sistema de frenos antibloqueo se han diseñado para cumplir con sus plazos requeridos, no se requieren ni son útiles más mejoras de rendimiento. Además, si un servidor de red está muy cargado de tráfico de red, su tiempo de respuesta puede ser más lento, pero (en la mayoría de los casos) aún tendrá éxito antes de que se agote el tiempo de espera (alcance su plazo). Por lo tanto, dicho servidor de red no se consideraría un sistema en tiempo real: las fallas temporales (retrasos, tiempos de espera, etc.) suelen ser pequeñas y compartimentadas (de efecto limitado), pero no son fallas catastróficas . En un sistema en tiempo real, como el índice FTSE 100 , una ralentización que supere los límites a menudo se consideraría catastrófica en su contexto de aplicación. El requisito más importante de un sistema en tiempo real es la consistencia en la salida, no un alto rendimiento.

Algunos tipos de software, como muchos programas de ajedrez , pueden pertenecer a cualquiera de las dos categorías. Por ejemplo, un programa de ajedrez diseñado para jugar en un torneo con reloj deberá decidir su jugada antes de un plazo determinado o perderá la partida, por lo que se trata de un cálculo en tiempo real. En cambio, un programa de ajedrez que puede ejecutarse indefinidamente antes de mover no lo es. En ambos casos, sin embargo, se busca un alto rendimiento: cuanto más trabajo pueda realizar un programa de ajedrez de torneo en el tiempo asignado, mejores serán sus jugadas, y cuanto más rápido se ejecute un programa de ajedrez sin restricciones, antes podrá mover. Este ejemplo también ilustra la diferencia esencial entre los cálculos en tiempo real y otros cálculos: si el programa de ajedrez de torneo no decide su siguiente jugada en el tiempo asignado, pierde la partida (es decir, falla como cálculo en tiempo real), mientras que en el otro caso, no se considera necesario cumplir con el plazo. El alto rendimiento indica la cantidad de procesamiento que se realiza en un tiempo determinado, mientras que el tiempo real es la capacidad de completar el procesamiento para obtener un resultado útil en el tiempo disponible.

El término "tiempo casi real" o "tiempo casi real" (NRT, por sus siglas en inglés), en telecomunicaciones e informática , se refiere al retardo temporal introducido, por el procesamiento automatizado de datos o la transmisión de red , entre la ocurrencia de un evento y el uso de los datos procesados, por ejemplo, para fines de visualización, retroalimentación y control. Por ejemplo, una pantalla en tiempo casi real muestra un evento o situación tal como existía en el momento actual menos el tiempo de procesamiento, como si fuera prácticamente el tiempo del evento en vivo. ^{[ 12 ]}

La distinción entre los términos "tiempo casi real" y "tiempo real" es algo ambigua y debe definirse según la situación en cuestión. El término implica que no hay retrasos significativos. ^{[ 12 ]} En muchos casos, el procesamiento descrito como "tiempo real" se describiría con mayor precisión como "tiempo casi real".

El término "en tiempo casi real" también se refiere a la transmisión de voz y video con retardo. Permite reproducir imágenes de video prácticamente en tiempo real, sin tener que esperar a que se descargue un archivo de video grande completo. Las bases de datos incompatibles pueden exportar e importar a archivos planos comunes que la otra base de datos puede importar y exportar de forma programada, de modo que puedan sincronizar y compartir datos comunes en "tiempo casi real".

Existen varios métodos para facilitar el diseño de sistemas en tiempo real, como MASCOT , un método antiguo pero muy eficaz que representa la estructura concurrente del sistema. Otros ejemplos son HOOD , Real-Time UML , AADL , el perfil Ravenscar y Real-time Java .

• Burns, Alan; Wellings, Andy (2009), Sistemas en tiempo real y lenguajes de programación (4.ª  ed.), Addison-Wesley, ISBN 978-0-321-41745-9
• Buttazzo, Giorgio (2011), Sistemas informáticos de tiempo real estricto: algoritmos de planificación predecibles y aplicaciones , Nueva York, Nueva York: Springer, ISBN 9781461406761– vía Google Libros.
• Liu, Jane WS (2000), Sistemas en tiempo real , Upper Saddle River, Nueva Jersey: Prentice Hall.
• Revista Internacional de Sistemas Informáticos Críticos en el Tiempo

• Comité Técnico de Sistemas en Tiempo Real del IEEE
• Comité Técnico de Euromicro sobre Sistemas en Tiempo Real
• Qué es, dónde está y por qué de la simulación en tiempo real.
• Johnstone, RL "RTOS: Ampliando OS/360 para el control de vuelos espaciales en tiempo real" (PDF) . Bitsavers . Consultado el 24 de febrero de 2023 .
• Coyle, RJ; Stewart, JK (septiembre de 1963). "Diseño de un sistema de programación en tiempo real" . Computers and Automation . XII (9). Silver Spring, Maryland: Datatrol Corporation: 26–34 . [...] conjunto de notas que, con suerte, señalarán áreas problemáticas que deben considerarse en el diseño en tiempo real.