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 primer 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 ámbito de aplicación es uno en el que el control en tiempo real ofrece ventajas genuinas 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]
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 el plazo constituye un fallo del sistema). Algunos ejemplos de sistemas de tiempo real estricto son:
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 superpuesta, 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:
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:
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 presenta una salida más retrasada que la entrada, no es de 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 de 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 "nearly real-time" (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 .
Se han establecido límites de sincronización A/V adecuados y el rango que se considera aceptable para películas es de +/- 22 ms. El rango para video, según la ATSC, es de hasta 15 ms de tiempo de anticipación y aproximadamente 45 ms de tiempo de retraso.
[...] conjunto de notas que, con suerte, señalarán áreas problemáticas que se deben considerar en el diseño en tiempo real.