Computación en tiempo real

Este artículo incluye una lista de referencias generales , pero carece de suficientes citas en línea correspondientes . Por favor, ayude a mejorar este artículo introduciendo citas más precisas. ( Abril de 2014 ) ( Aprenda cómo y cuándo eliminar este mensaje )

La computación en tiempo real ( RTC ) es el término informático que se utiliza para los sistemas de hardware y software sujetos a una "restricción de tiempo real", por ejemplo, desde un evento hasta la respuesta del sistema . ^[1] Los programas en tiempo real deben garantizar una respuesta dentro de límites de tiempo específicos, a menudo denominados "plazos". ^[2]

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

Las respuestas en tiempo real suelen ser del orden de milisegundos y, a veces, de microsegundos. Un sistema que no se especifica que funciona en tiempo real normalmente no puede garantizar una respuesta en ningún plazo, aunque se puedan indicar tiempos de respuesta típicos o esperados . El procesamiento en tiempo real falla si no se completa dentro de un plazo especificado en relación con un evento; los plazos siempre deben cumplirse, independientemente de la carga del sistema .

Un sistema en tiempo real se ha descrito como uno que "controla un entorno recibiendo datos, procesándolos y devolviendo 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 sistemas empresariales para significar "sin retrasos significativos".

El software en tiempo real puede utilizar uno o más de los siguientes: lenguajes de programación sincrónica , sistemas operativos en tiempo real (RTOS) y redes en tiempo real, cada uno de los cuales proporciona marcos esenciales sobre los cuales construir una aplicación de software en tiempo real.

Los sistemas utilizados para muchas aplicaciones críticas para la seguridad deben ser en tiempo real, como por ejemplo para el control de aeronaves con control electrónico o frenos antibloqueo , los cuales exigen una respuesta mecánica inmediata y precisa. ^[4]

El término tiempo real deriva de su uso en la simulación temprana , en la que se simula un proceso del mundo real a una velocidad que coincide con la del proceso real (ahora llamada simulación en tiempo real para evitar ambigüedades). Las computadoras analógicas , en la mayoría de los casos, 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.

Las minicomputadoras, particularmente a partir de los años 1970, cuando se integraron en sistemas integrados dedicados como los escáneres DOG ( gráficos digitales en pantalla ), aumentaron la necesidad de respuestas de baja latencia impulsadas por prioridades para interacciones importantes con datos entrantes, por lo que los sistemas operativos como RDOS (sistema operativo de disco en tiempo real) de Data General y RTOS con programación en segundo plano y en primer plano, así como el RT-11 de Digital Equipment Corporation, datan de esta era. La programación en segundo plano y en primer plano permitía que las tareas de baja prioridad ocuparan tiempo de CPU cuando no era necesario ejecutar ninguna tarea en primer plano, y daba prioridad absoluta dentro del primer plano a los subprocesos/tareas con la máxima prioridad. Los sistemas operativos en tiempo real también se usarían para tareas multiusuario de tiempo compartido . Por ejemplo, Data General Business Basic podría ejecutarse en primer plano o en segundo plano de RDOS e introduciría elementos adicionales al algoritmo de programación para hacerlo más apropiado para las personas que interactúan 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 bucles codificados de forma rígida con tiempos definidos, y la baja latencia de las interrupciones permitía la implementación de un sistema operativo en tiempo real, dando a la interfaz de usuario y a las unidades de disco una prioridad menor que al hilo de tiempo real. En comparación con estos, el controlador de interrupciones programable de las CPU de Intel (8086..80586) genera una latencia muy grande y el sistema operativo Windows no es un sistema operativo en tiempo real ni permite que un programa tome el control de la CPU por completo y utilice su propio planificador , sin utilizar el lenguaje de máquina nativo y, por lo tanto, evitando todo el código de interrupción de Windows. Sin embargo, existen varias bibliotecas de codificación que ofrecen capacidades de tiempo real en un lenguaje de alto nivel en una variedad de sistemas operativos, por ejemplo, Java Real Time . Los microprocesadores posteriores, como el Motorola 68000 y los miembros de la familia posteriores (68010, 68020, ColdFire , etc.) también se hicieron populares entre los fabricantes de sistemas de control industrial. Este es un ámbito de aplicación en el que el control en tiempo real ofrece ventajas reales en términos de rendimiento y seguridad del proceso. ^{[ cita requerida ]}

Se dice que un sistema es de tiempo real si la corrección total de una operación depende no sólo 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 un plazo: ^[6]

• Difícil  : no cumplir con un plazo supone un fallo total del sistema.
• Firme  : los incumplimientos poco frecuentes de los plazos son tolerables, pero pueden degradar 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 se degrada después de su fecha límite, degradando así la calidad del servicio del sistema.

Por lo tanto, el objetivo de un sistema de tiempo real estricto es garantizar que se cumplan todos los plazos, pero en el caso de los sistemas de tiempo real flexible, el objetivo es cumplir un determinado subconjunto de plazos para optimizar algunos criterios específicos de la aplicación. Los criterios concretos optimizados dependen de la aplicación, pero algunos ejemplos típicos incluyen maximizar el número de plazos cumplidos, minimizar la demora de las tareas y maximizar el número de tareas de alta prioridad que cumplen 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 sólidas son necesarias para sistemas en los que no reaccionar en un intervalo de tiempo determinado causaría grandes pérdidas de algún tipo, especialmente daños físicos al entorno o amenazas a la vida humana (aunque la definición estricta es simplemente que no cumplir con el plazo constituye un fallo del sistema). Algunos ejemplos de sistemas de tiempo real estricto son:

• Un sistema de control del motor de un automóvil es un sistema de tiempo real estricto porque una señal retrasada puede provocar fallas o daños en el motor.
• Sistemas médicos como marcapasos . Aunque la tarea de un marcapasos es sencilla, debido al riesgo potencial para la vida humana, los sistemas médicos como estos suelen tener que pasar por pruebas y certificaciones exhaustivas, lo que a su vez requiere cálculos en tiempo real para ofrecer garantías demostrables de que es poco probable o imposible que se produzca un fallo.
• Controladores de procesos industriales, como una máquina en una línea de montaje . Si la máquina se retrasa, el artículo en la línea de montaje podría pasar fuera del alcance de la máquina (dejando el producto intacto), o la máquina o el producto podrían dañarse al activar el robot en el momento equivocado. Si se detecta la falla, ambos casos provocarían la detención de la línea de montaje, lo que ralentiza la producción. Si no se detecta la falla, un producto con un defecto podría pasar por la producción o podría causar daños en pasos posteriores de la producción.
• Los sistemas de tiempo real estricto suelen interactuar a bajo nivel con el hardware físico, en sistemas integrados . Los primeros sistemas de videojuegos, como el Atari 2600 y los gráficos vectoriales Cinematronics, tenían requisitos estrictos de tiempo real debido a la naturaleza del hardware de gráficos y sincronización.
• Los módems de software reemplazan un módem de hardware por un software que se ejecuta en la CPU de una computadora . El software debe ejecutarse cada pocos milisegundos para generar los siguientes datos de audio que se enviarán. Si esos datos se demoran, el módem receptor perderá la sincronización, lo que provocará una interrupción prolongada mientras se restablece la sincronización o hará que la conexión se pierda por completo.
• Muchos tipos de impresoras tienen requisitos estrictos en tiempo real, como las impresoras de inyección de tinta (la tinta debe depositarse en el momento correcto cuando el cabezal de impresión cruza la página), las impresoras láser (el láser debe activarse en el momento correcto cuando el haz recorre el tambor giratorio) y las impresoras matriciales y de línea (el mecanismo de impacto debe activarse en el momento correcto cuando el mecanismo de impresión se alinea con la salida deseada). Una falla en cualquiera de ellas provocaría la falta de salida o una salida desalineada.

En el contexto de los sistemas multitarea , la política de programación normalmente está impulsada por prioridades ( programadores preemptivos ). 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 programadores de tiempo real estrictos, como el monotónico de velocidad , que no es común en sistemas de propósito general, ya que requiere información adicional para programar una tarea: es decir, una estimación límite o del peor caso de cuánto tiempo debe ejecutarse la tarea. Existen algoritmos específicos para programar tales tareas de 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 programación superpuestos, como un programador de partición adaptativo, ayudan a administrar sistemas grandes con una mezcla de aplicaciones de tiempo real estricto y no tiempo real.

Los sistemas de tiempo real firmes están definidos de forma más imprecisa y algunas clasificaciones no los incluyen, y sólo distinguen entre sistemas de tiempo real duros y blandos. Algunos ejemplos de sistemas de tiempo real firmes:

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

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

• 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 unos pocos segundos.
• Los sistemas de audio y video en vivo también suelen ser de tiempo real suave. Un cuadro de audio que se reproduce tarde puede causar una falla breve de audio (y puede hacer que todo el audio posterior se retrase correspondientemente, lo que genera una percepción de que el audio se reproduce más lento de lo normal), pero esto puede ser mejor que las alternativas de continuar reproduciendo silencio, estática, un cuadro de audio anterior o datos estimados. Un cuadro de video que se retrasa generalmente causa incluso menos interrupciones para los espectadores. El sistema puede continuar funcionando y también recuperarse en el futuro utilizando metodologías de predicción y reconfiguración de la carga de trabajo. ^[8]
• De manera similar, los videojuegos suelen ser de tiempo real suave, en particular porque intentan cumplir con una velocidad de cuadros objetivo . Como la siguiente imagen no se puede calcular de antemano, ya que depende de las entradas del jugador, solo se dispone de un breve tiempo para realizar todos los cálculos necesarios para generar un fotograma de video antes de que deba mostrarse ese fotograma. Si se pierde la fecha límite, el juego puede continuar a una velocidad de cuadros más baja; dependiendo del juego, esto solo puede afectar a sus gráficos (mientras que el juego continúa a velocidad normal), o el juego en sí puede ralentizarse (lo que era común en las consolas antiguas de tercera y cuarta generación ).

En un proceso de procesamiento de señales digitales (DSP) en tiempo real , las muestras analizadas (entrada) y generadas (salida) se pueden procesar (o generar) de forma continua en el tiempo que lleva introducir y sacar el mismo conjunto de muestras independientemente del retraso de procesamiento. ^[9] Esto significa que el retraso de procesamiento debe estar limitado incluso si el procesamiento continúa durante un tiempo ilimitado. Eso significa que el tiempo medio de procesamiento por muestra, incluida la sobrecarga , no es mayor que el período de muestreo, que es el recíproco de la frecuencia de muestreo . Este es el criterio si las muestras se agrupan en segmentos grandes y se procesan como bloques o se procesan individualmente y si hay búferes de entrada y salida largos, cortos o inexistentes .

Consideremos un ejemplo de DSP de audio : si un proceso requiere 2,01 segundos para analizar , sintetizar o procesar 2,00 segundos de sonido, no es en tiempo real. Sin embargo, si tarda 1,99 segundos, es o puede convertirse en un proceso DSP en tiempo real.

Una analogía común en la vida es la de estar en una cola esperando a que pase la caja en un supermercado. Si la cola se hace cada vez más larga asintóticamente sin límite, el proceso de pago no es en tiempo real. Si la longitud de la cola es limitada, los clientes están siendo "procesados" y saliendo tan rápido, en promedio, como están siendo ingresados, entonces ese proceso es en tiempo real. El supermercado podría quebrar o al menos perder negocios si no puede hacer que su proceso de pago sea en tiempo real; por lo tanto, es fundamentalmente importante que este proceso sea en tiempo real.

Un algoritmo de procesamiento de señales que no puede seguir el ritmo del flujo de datos de entrada y que cada vez tiene menos datos de salida que los de entrada no es en tiempo real. Pero si el retraso de la salida (en relación con la entrada) está limitado en relación con un proceso que funciona durante un tiempo ilimitado, entonces ese algoritmo de procesamiento de señales es en tiempo real, incluso si el retraso en el rendimiento puede ser muy largo.

El procesamiento de señales en tiempo real es necesario, pero no suficiente por sí mismo, para el procesamiento de señales en vivo, como el que se requiere para el soporte de eventos en vivo . El procesamiento de señales digitales de audio en vivo requiere tanto un funcionamiento en tiempo real como un límite suficiente para el retraso de rendimiento, de modo que sea tolerable para los artistas que usan monitores de escenario o monitores intraauriculares y no sea perceptible como un error de sincronización de labios para la audiencia que también mira directamente a los artistas. Los límites tolerables de latencia para el procesamiento en vivo y en tiempo real son un tema de investigación y debate, pero se estima que están entre 6 y 20 milisegundos. ^[10]

Los retrasos en las telecomunicaciones bidireccionales en tiempo real de menos de 300 ms ("ida y vuelta" o el doble del retraso unidireccional) se consideran "aceptables" para evitar "interferencias" no deseadas en la conversación.

A veces se confunde la computación en tiempo real con computación de alto rendimiento , pero esta no es una clasificación precisa. ^[11] Por ejemplo, una supercomputadora masiva que ejecuta una simulación científica puede ofrecer un rendimiento impresionante, pero no está ejecutando un cálculo 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 los plazos requeridos, no son obligatorias ni ú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 (llegue a su fecha límite). Por lo tanto, un servidor de red de este tipo no se consideraría un sistema de tiempo real: las fallas temporales (demoras, tiempos de espera, etc.) suelen ser pequeñas y compartimentadas (de efecto limitado), pero no son fallas catastróficas . En un sistema de tiempo real, como el índice FTSE 100 , una desaceleración más allá de 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 una salida consistente, no un alto rendimiento.

Algunos tipos de software, como muchos programas de ajedrez , pueden caer en ambas categorías. Por ejemplo, un programa de ajedrez diseñado para jugar en un torneo con un reloj necesitará decidir un movimiento antes de una fecha límite determinada o perderá la partida, y por lo tanto es un cálculo en tiempo real, pero un programa de ajedrez al que se le permite ejecutarse indefinidamente antes de mover no lo es. En ambos casos, sin embargo, es deseable un alto rendimiento: cuanto más trabajo pueda hacer un programa de ajedrez de torneo en el tiempo asignado, mejores serán sus movimientos, 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 toma una decisión sobre su siguiente movimiento en su tiempo asignado, pierde la partida (es decir, falla como cálculo en tiempo real), mientras que en el otro escenario, se supone que no es necesario cumplir con la fecha límite. El alto rendimiento es un indicador de la cantidad de procesamiento que se realiza en un período de tiempo determinado, mientras que el tiempo real es la capacidad de realizar el procesamiento para producir un resultado útil en el tiempo disponible.

El término "tiempo casi real" o "casi en tiempo real" (NRT), en telecomunicaciones e informática , se refiere al retraso temporal introducido, por el procesamiento automático de datos o la transmisión en red , entre la ocurrencia de un evento y el uso de los datos procesados, como para fines de visualización o retroalimentación y control. Por ejemplo, una visualización en tiempo casi real representa un evento o situación tal como existía en el momento actual menos el tiempo de procesamiento, como casi el tiempo del evento en vivo. ^[12]

La distinción entre los términos "tiempo casi real" y "tiempo real" es un tanto nebulosa y debe definirse para la situación en cuestión. El término implica que no hay demoras significativas. ^[12] En muchos casos, el procesamiento descrito como "tiempo real" se describiría con mayor precisión como "tiempo casi real".

El término "casi en tiempo real" también hace referencia a la transmisión de voz y vídeo en tiempo real con retraso. Permite reproducir imágenes de vídeo, aproximadamente en tiempo real, sin tener que esperar a que se descargue un archivo de vídeo completo de gran tamaño. Las bases de datos incompatibles pueden exportar o importar archivos planos comunes que la otra base de datos puede importar o exportar de forma programada para poder sincronizar o compartir datos comunes "casi en tiempo real" entre sí.

Existen varios métodos para ayudar al diseño de sistemas en tiempo real, un ejemplo de los cuales es MASCOT , un método antiguo pero muy exitoso 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 y aplicaciones de programación predecibles, Nueva York, Nueva York: Springer, ISBN 9781461406761– a través de Google Books.
• Liu, Jane WS (2000), Sistemas en tiempo real , Upper Saddle River, Nueva Jersey: Prentice Hall.
• Revista internacional de sistemas informáticos de tiempo crítico

• Comité Técnico IEEE sobre Sistemas en Tiempo Real
• Comité Técnico de Sistemas en Tiempo Real de Euromicro
• Qué, dónde y por qué de la simulación en tiempo real
• Johnstone, RL "RTOS: ampliación de 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". Computadoras y automatización . XII (9). Silver Spring, Maryland: Datatrol Corporation: 26–34. [...] conjunto de notas que, con suerte, señalarán áreas problemáticas que se deben considerar en el diseño en tiempo real.