Computación en tiempo real ( RTC ) es el término informático para sistemas de hardware y software sujetos a una "restricción de tiempo real", por ejemplo, desde un evento hasta una respuesta del sistema . [1] Los programas en tiempo real deben garantizar la 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.
A menudo se entiende que las respuestas en tiempo real son del orden de milisegundos y, a veces, microsegundos. Un sistema no especificado como operativo en tiempo real generalmente no puede garantizar una respuesta dentro de ningún plazo, 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 siempre deben cumplirse, independientemente de la carga del sistema .
Un sistema en tiempo real ha sido descrito como aquel que "controla un entorno recibiendo datos, procesándolos y devolviendo los resultados con la suficiente rapidez como para afectar el entorno en ese momento". [3] El término "en tiempo real" se utiliza en el control de procesos y en los sistemas empresariales para significar "sin demoras significativas".
El software en tiempo real puede utilizar uno o más de los siguientes: lenguajes de programación síncronos , 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 para el control de aviones 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 , en las que un proceso del mundo real se simula 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 , en la mayoría de los casos, eran capaces de simular a un ritmo mucho más rápido que en tiempo real, una situación que podría ser tan peligrosa como una simulación lenta si no fuera también reconocida y tenida en cuenta.
Las minicomputadoras, particularmente a partir de la década de 1970, cuando se integraron en sistemas integrados dedicados como los escáneres DOG ( gráficos digitales en pantalla ), aumentaron la necesidad de respuestas prioritarias de baja latencia a interacciones importantes con los datos entrantes y, por lo tanto, con los sistemas operativos como Data. El RDOS (sistema operativo de disco en tiempo real) y el RTOS de General con programación en segundo plano y en primer plano, así como el RT-11 de Digital Equipment Corporation, datan de esta época. La programación en segundo plano permitía tiempo de CPU para tareas de baja prioridad cuando no era necesario ejecutar ninguna tarea en primer plano, y daba prioridad absoluta en primer plano a los subprocesos/tareas con la mayor prioridad. Los sistemas operativos en tiempo real también se utilizarían para tareas multiusuario de tiempo compartido . Por ejemplo, Data General Business Basic podría ejecutarse en primer o 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 tontos .
Una vez, cuando la tecnología MOS 6502 (usada en Commodore 64 y Apple II ), y más tarde, cuando el Motorola 68000 (usado en Macintosh , Atari ST y Amiga ) eran populares, cualquiera podía usar la computadora de su hogar como un sistema en tiempo real. . La posibilidad de desactivar otras interrupciones permitió bucles codificados con tiempos definidos, y la baja latencia de interrupción permitió 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 el hilo en tiempo real. En comparación con estos, el controlador de interrupciones programable de las CPU 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 se apodere completamente de la CPU y utilice su propio programador , sin utilizar lenguaje de máquina nativo y superando así todas las interrupciones del código de Windows. Sin embargo, existen varias bibliotecas de codificación que ofrecen capacidades en tiempo real en un lenguaje de alto nivel en una variedad de sistemas operativos, por ejemplo Java Real Time . El Motorola 68000 y los miembros posteriores de la familia (68010, 68020, etc.) también se hicieron populares entre los fabricantes de sistemas de control industrial. Esta área de aplicación es aquella en la que el control en tiempo real ofrece verdaderas ventajas en términos de rendimiento y seguridad del proceso. [ cita necesaria ]
Se dice que un sistema es en 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 en tiempo real, así como sus plazos, se clasifican según la consecuencia del incumplimiento de un plazo: [6]
Por lo tanto, el objetivo de un sistema estricto en tiempo real es garantizar que se cumplan todos los plazos, pero para los sistemas blandos en tiempo real el objetivo es cumplir con un cierto subconjunto de plazos para optimizar algunos criterios específicos de la aplicación. Los criterios particulares optimizados dependen de la aplicación, pero algunos ejemplos típicos incluyen maximizar la cantidad de plazos cumplidos, minimizar el retraso de las tareas y maximizar la cantidad de tareas de alta prioridad que cumplen con sus plazos.
Los sistemas estrictos en tiempo real se utilizan cuando es imperativo reaccionar ante un evento dentro de un plazo estricto. Se requieren garantías tan fuertes de sistemas para los cuales no reaccionar en un determinado intervalo de tiempo causaría grandes pérdidas de alguna manera, especialmente dañando físicamente el entorno o amenazando vidas humanas (aunque la definición estricta es simplemente que no cumplir con el plazo constituye una falla del sistema). ). Algunos ejemplos de sistemas duros en tiempo real:
En el contexto de los sistemas multitarea , la política de programación normalmente está impulsada por prioridades ( programadores preventivos ). En algunas situaciones, esto puede garantizar un rendimiento estricto en tiempo real (por ejemplo, si se conoce de antemano el conjunto de tareas y sus prioridades). Existen otros programadores estrictos en tiempo real, como rate-monotonic , que no es común en los sistemas de propósito general, ya que requiere información adicional para programar una tarea: es decir, una estimación limitada o del peor de los casos de cuánto tiempo debe ejecutarse la tarea. . Existen algoritmos específicos para programar tareas difíciles en tiempo real, como la fecha límite más temprana primero , 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 particiones adaptativo, ayudan a administrar sistemas grandes con una combinación de aplicaciones en tiempo real y no en tiempo real.
Los sistemas firmes en tiempo real están definidos de manera más nebulosa y algunas clasificaciones no los incluyen, distinguiendo solo sistemas de tiempo real duros y blandos. Algunos ejemplos de sistemas firmes en tiempo real:
Los sistemas blandos en tiempo real se utilizan normalmente para resolver problemas de acceso simultáneo y la necesidad de mantener actualizados varios sistemas conectados en situaciones cambiantes. Algunos ejemplos de sistemas blandos en tiempo real:
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) continuamente en el tiempo que lleva ingresar y emitir el mismo conjunto de muestras independientemente del procesamiento. demora. [9] Significa que el retraso en el procesamiento debe ser limitado incluso si el procesamiento continúa por un tiempo ilimitado. Eso significa que el tiempo medio de procesamiento por muestra, incluidos los gastos generales , no es mayor que el período de muestreo, que es el recíproco de la tasa de muestreo . Este es el criterio para determinar si las muestras se agrupan en segmentos grandes y se procesan como bloques o se procesan individualmente y si los buffers de entrada y salida son largos, cortos o inexistentes .
Considere 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 hacer cola esperando la caja en una tienda de comestibles. Si la línea asintóticamente se hace más y más larga sin límites, el proceso de pago no es en tiempo real. Si la longitud de la línea está limitada, los clientes se "procesan" y se generan tan rápidamente, en promedio, como se ingresan, entonces ese proceso es en tiempo real. El tendero podría cerrar el negocio o al menos perderlo si no puede realizar el proceso de pago en tiempo real; por lo tanto, es de fundamental importancia 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 con la salida cada vez más por detrás de la entrada, no es en tiempo real. Pero si el retraso de la salida (en relación con la entrada) está limitado con respecto a un proceso que opera 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 en sí mismo, para el procesamiento de señales en vivo, como el que se requiere en el soporte de eventos en vivo . El procesamiento de señales digitales de audio en vivo requiere operación en tiempo real y un límite suficiente de retardo de rendimiento para que sea tolerable para los artistas que usan monitores de escenario o monitores internos y que el público que también mira directamente a los artistas no lo note como un error de sincronización de labios . 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 retardos de las telecomunicaciones bidireccionales en tiempo real inferiores a 300 ms ("ida y vuelta" o el doble del retardo unidireccional) se consideran "aceptables" para evitar "conversaciones" no deseadas en la conversación.
A veces se malinterpreta la computación en tiempo real como 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 ejecuta 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 es obligatorio ni siquiera útil mejorar más el 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) seguirá teniendo éxito antes de que expire el tiempo de espera (llegue a la fecha límite). Por lo tanto, un servidor de red de este tipo 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 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 producción consistente, no un alto rendimiento.
Algunos tipos de software, como muchos programas de ajedrez , pueden caer en cualquiera de las dos categorías. Por ejemplo, un programa de ajedrez diseñado para jugar un torneo con un reloj necesitará decidir una jugada antes de una determinada fecha límite o perderá la partida y, por lo tanto, es un cálculo en tiempo real, pero es un programa de ajedrez que puede ejecutarse indefinidamente. antes de moverse 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á realizar 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 el 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 el plazo. El alto rendimiento es indicativo 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 generar 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 de tiempo introducido, por el procesamiento automatizado de datos o la transmisión de red , entre la ocurrencia de un evento y el uso del datos procesados, por ejemplo con fines de visualización o retroalimentación y control. Por ejemplo, una visualización casi en tiempo real representa un evento o situación tal como existía en el momento actual menos el tiempo de procesamiento, como casi la hora del evento en vivo. [12]
La distinción entre los términos "tiempo casi real" y "tiempo real" es algo confusa y debe definirse para la situación que nos ocupa. El término implica que no hay retrasos significativos. [12] En muchos casos, el procesamiento descrito como "en tiempo real" se describiría más exactamente como "casi en tiempo real".
El tiempo casi real también se refiere a la transmisión retrasada de voz y vídeo en tiempo real. Permite reproducir imágenes de vídeo, aproximadamente en tiempo real, sin tener que esperar a que se descargue un archivo de vídeo grande completo. Las bases de datos incompatibles pueden exportar/importar a archivos planos comunes que la otra base de datos puede importar/exportar de forma programada para que puedan sincronizar/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 , UML en tiempo real, AADL , el perfil Ravenscar y Java en tiempo real .
Se han establecido límites de sincronización A/V apropiados y el rango que se considera aceptable para películas es +/- 22 ms. El rango de vídeo, según el ATSC, es de hasta 15 ms de tiempo de adelanto y de unos 45 ms de retraso.
[...] conjunto de notas que, con suerte, señalarán áreas problemáticas que deberían considerarse en el diseño en tiempo real.