Computación en tiempo real

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 de evento a respuesta del sistema. Los programas en tiempo real deben garantizar la respuesta dentro de los límites de tiempo especificados, a menudo denominados "plazos".

A menudo se entiende que las respuestas en tiempo real son del orden de milisegundos y, a veces, de microsegundos. Un sistema que no está especificado como operativo en tiempo real normalmente no puede garantizar una respuesta dentro de ningún marco de tiempo, aunque se pueden dar tiempos de respuesta típicos o esperados. El procesamiento en tiempo real falla si no se completa dentro de un plazo específico relativo a un evento; siempre se deben cumplir los plazos, independientemente de la carga del sistema.

Un sistema en tiempo real se ha descrito como uno que "controla un entorno al recibir datos, procesarlos y devolver los resultados lo suficientemente rápido como para afectar el entorno en ese momento". El término "en 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, y en control de procesos y sistemas empresariales para indicar 'sin retrasos significativos'.

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

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

Historia

El término tiempo real se deriva de su uso en la simulación temprana, en la que se simula un proceso del mundo real a una velocidad que coincidía con la del proceso real (ahora llamado simulación en tiempo real para evitar la ambigüedad). 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 se reconociera y tuviera 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 de prioridad de baja latencia para interacciones importantes con los datos entrantes y, por lo tanto, los sistemas operativos. como el 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 permitió el tiempo de CPU de las tareas de baja prioridad cuando no se necesitaba ejecutar ninguna tarea en primer plano, y otorgó prioridad absoluta dentro del primer plano a los subprocesos/tareas con la prioridad más alta. 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 plano o en segundo plano de RDOS e introduciría elementos adicionales en el algoritmo de programación para hacerlo más apropiado para las personas que interactúan a través de terminales tontas.

Una vez que la tecnología MOS 6502 (usada en el Commodore 64 y Apple II) y más tarde cuando el Motorola 68000 (usado en Macintosh, Atari ST y Commodore Amiga) eran populares, cualquiera podía usar su computadora personal como un sistema en tiempo real. La posibilidad de desactivar otras interrupciones permitió bucles codificados con tiempo definido, 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 las unidades de disco una prioridad más baja que el hilo en tiempo real. En comparación con estos, el controlador de interrupción 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 haga cargo de la CPU por completo y use su programador propio, sin utilizar lenguaje máquina nativo y superando así todo código de interrupción 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 una en la que el control en tiempo real ofrece ventajas genuinas en términos de rendimiento y seguridad del proceso.

Criterios para computación en tiempo real

Se dice que un sistema es en 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. Los sistemas de tiempo real, así como sus plazos, se clasifican según la consecuencia de no cumplir un plazo:

• Duro– perder un plazo es una falla total del sistema.
• Firma– las faltas de plazo son tolerables, pero pueden degradar la calidad del servicio del sistema. La utilidad de un resultado es cero después de su fecha límite.
• Suave– la utilidad de un resultado se degrada después de su plazo, degradando así la calidad de servicio del sistema.

Por lo tanto, el objetivo de un sistema de tiempo real estricto es garantizar que se cumplan todos los plazos, pero para los sistemas de tiempo real flexibles el objetivo se convierte en cumplir con un determinado 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 fechas límite cumplidas, minimizar la demora de las tareas y maximizar la cantidad de tareas de alta prioridad que cumplen sus fechas límite.

Los sistemas duros en tiempo real se utilizan cuando es imperativo que se reaccione a un evento dentro de un plazo estricto. Se requieren garantías tan fuertes de los sistemas para los cuales no reaccionar en un cierto intervalo de tiempo causaría una gran pérdida 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 la fecha límite constituye una falla del sistema). Algunos ejemplos de sistemas duros en tiempo real:

• Un sistema de control del motor del coche es un sistema duro en tiempo real porque una señal retardada puede causar fallo del motor o daño.
• Sistemas médicos como marcapasos cardíacos. A pesar de que la tarea de un marcapasos es simple, debido al riesgo potencial para la vida humana, los sistemas médicos como estos suelen ser necesarios para someterse a pruebas y certificación exhaustivas, lo que a su vez requiere un cálculo duro en tiempo real para ofrecer garantías provables de que un fracaso es improbable o imposible.
• 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 más allá del alcance de la máquina (dejando el producto sin tocar), o la máquina o el producto podría ser dañado activando el robot en el momento equivocado. Si se detecta el fallo, ambos casos conducirían a la parada de la línea de montaje, que frena la producción. Si no se detecta el fallo, un producto con defecto podría hacerlo a través de la producción, o podría causar daño en pasos posteriores de producción.
• Los sistemas duros en tiempo real suelen encontrarse interactuando a bajo nivel con hardware físico, en sistemas integrados. Los primeros sistemas de videojuegos como los gráficos vectoriales Atari 2600 y Cinematronics tenían requisitos difíciles en tiempo real debido a la naturaleza de los gráficos y el hardware de tiempo.
• Softmodems reemplaza un módem de hardware con software que funciona en la CPU de un ordenador. El software debe ejecutar cada pocos milisegundos para generar los próximos datos de audio para ser la salida. Si esos datos llegan tarde, el módem receptor perderá la sincronización, causando una larga interrupción, ya que se restablece la sincronización o causando que la conexión se pierda por completo.
• Muchos tipos de impresoras tienen requisitos difíciles en tiempo real, tales como inyección de tinta (la tinta debe ser depositada en el momento correcto ya que el cabezal de impresión cruza la página), impresoras láser (el láser debe ser activado en el momento adecuado, ya que el rayo escanea a través del tambor giratorio), y matriz de puntos y varios tipos de impresoras de línea (el mecanismo de impacto debe ser activado en el momento adecuado, ya que el mecanismo de impresión se alinea con la salida deseada). Un fracaso en cualquiera de estos causaría falta de producción o mal alineado.

En el contexto de los sistemas multitarea, la política de programación normalmente se basa en prioridades (programadores preventivos). En algunas situaciones, estos pueden garantizar un rendimiento en tiempo real estricto (por ejemplo, si se conoce de antemano el conjunto de tareas y sus prioridades). Hay otros programadores duros en tiempo real, como rate-monotonic, que no es común en los sistemas de uso general, ya que requiere información adicional para programar una tarea: a saber, una estimación limitada o en el peor de los casos de cuánto tiempo debe ejecutarse la tarea.. Existen algoritmos específicos para programar tareas tan 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 de menos del 100 %. Los nuevos sistemas de programación de superposición, como un programador de partición adaptativo, ayudan a administrar sistemas grandes con una combinación de aplicaciones en tiempo real y no en tiempo real.

Los sistemas de tiempo real firmes se definen de forma más nebulosa y algunas clasificaciones no los incluyen, distinguiendo solo los sistemas de tiempo real duros y blandos. Algunos ejemplos de sistemas firmes en tiempo real:

• La máquina de línea de montaje descrita anteriormente duro en cambio, en tiempo real podría considerarse Firma en tiempo real. Un plazo perdido todavía causa un error que debe tratarse: puede haber maquinaria para marcar una parte tan mala o expulsarla de la línea de montaje, o la línea de montaje podría ser detenida para que un operador pueda corregir el problema. Sin embargo, siempre y cuando estos errores sean poco frecuentes, pueden tolerarse.

Los sistemas suaves en tiempo real generalmente se usan para resolver problemas de acceso simultáneo y la necesidad de mantener actualizados varios sistemas conectados a través de situaciones cambiantes. Algunos ejemplos de sistemas blandos en tiempo real:

• Software que mantiene y actualiza los planes de vuelo para aerolíneas comerciales. Los planes de vuelo deben mantenerse razonablemente actualizados, pero pueden funcionar con la latencia de unos segundos.
• Los sistemas de audio-vídeo en vivo también son generalmente suaves en tiempo real. Un marco de audio que se reproduce tarde puede causar un breve fallo de audio (y puede causar que todo el audio posterior sea retrasado correspondientemente, causando una percepción de que el audio se está reproduciendo más lento de lo normal), pero esto puede ser mejor que las alternativas de continuar jugando silencio, estática, un marco de audio previo, o datos estimados. Un marco de vídeo que se retrasa generalmente causa menos perturbación para los espectadores. El sistema puede seguir funcionando y recuperarse en el futuro utilizando metodologías de predicción y reconfiguración del volumen de trabajo.
• Del mismo modo, los videojuegos son a menudo blandos en tiempo real, especialmente cuando tratan de cumplir con una tasa de marco objetivo. Como la siguiente imagen no puede ser calculada de antemano, ya que depende de las entradas del jugador, sólo hay un corto tiempo disponible para realizar todo el cálculo necesario para generar un marco de vídeo antes de que ese marco se muestre. Si se pierde el plazo, el juego puede continuar a una velocidad de marco más baja; dependiendo del juego, esto sólo puede afectar sus gráficos (mientras el juego continúa a velocidad normal), o el juego en sí mismo puede ser desacelerado (que era común en las consolas de tercera y cuarta generación más viejas).

Tiempo real en procesamiento de señales digitales

En un proceso de procesamiento de señal digital (DSP) en tiempo real, las muestras analizadas (entrada) y generadas (salida) pueden procesarse (o generarse) continuamente en el tiempo que se tarda en ingresar y generar el mismo conjunto de muestras independiente del retraso en el procesamiento. Significa que la demora en el procesamiento debe estar limitada 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 de si las muestras se agrupan en grandes segmentos y se procesan como bloques o se procesan individualmente y si hay búferes de entrada y salida 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 de la vida común es estar parado en una línea o en una cola esperando la caja en una tienda de comestibles. Si la línea crece asintóticamente más y más sin límite, el proceso de pago no es en tiempo real. Si la longitud de la línea está limitada, los clientes están siendo "procesados" y la salida tan rápido, en promedio, como se están ingresando entonces ese proceso es en tiempo real. El tendero podría cerrar o al menos perder negocios si no puede realizar su proceso de pago 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 mantenerse al día con el flujo de datos de entrada y que la salida se retrasa cada vez más con respecto a 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 de rendimiento puede ser muy largo.

En vivo versus en tiempo real

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 la señal digital de audio en vivo requiere una operación en tiempo real y un límite suficiente para el retardo de rendimiento para que sea tolerable para los artistas que usan monitores de escenario o monitores internos y no se nota como un error de sincronización de labios por parte de 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 estiman entre 6 y 20 milisegundos.

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

En tiempo real y de alto rendimiento

La informática en tiempo real a veces se malinterpreta como informática de alto rendimiento, pero esta no es una clasificación precisa. 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 para un sistema de frenos antibloqueo se han diseñado para cumplir con los plazos requeridos, no es obligatorio ni útil aumentar más el rendimiento. Además, si un servidor de red está muy cargado con el tráfico de red, su tiempo de respuesta puede ser más lento, pero (en la mayoría de los casos) tendrá éxito antes de que se agote el tiempo de espera (llegue a su fecha límite). 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 (limitadas en efecto) 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 el contexto de su aplicación. El requisito más importante de un sistema en tiempo real es una salida constante, no un alto rendimiento.

Algunos tipos de software, como muchos programas para jugar al ajedrez, pueden entrar en cualquiera de las dos 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á el juego y, por lo tanto, es un cálculo en tiempo real, pero un programa de ajedrez que puede ejecutarse indefinidamente. antes de mudarse 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á moverse. Este ejemplo también ilustra la diferencia esencial entre los cálculos en tiempo real y otros cálculos: si el programa de torneo de ajedrez no toma una decisión sobre su próximo movimiento en el tiempo asignado, pierde el juego, 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 terminar el procesamiento para generar un resultado útil en el tiempo disponible.

Casi en tiempo real

El término "casi en tiempo real" o "casi en tiempo real" (NRT), en telecomunicaciones e informática, se refiere a la demora de tiempo introducida, 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, como para fines de visualización o retroalimentación y control. Por ejemplo, una pantalla en tiempo casi real representa un evento o situación tal como existía en el momento actual menos el tiempo de procesamiento, casi como el momento del evento en vivo.

La distinción entre los términos "tiempo casi real" y "en tiempo real" es algo nebuloso y debe definirse para la situación actual. El término implica que no hay retrasos significativos. En muchos casos, el procesamiento descrito como "en tiempo real" se describiría con mayor precisión como "casi en tiempo real".

Casi en tiempo real también se refiere a la transmisión diferida de voz y video en tiempo real. Permite reproducir imágenes de video, aproximadamente en tiempo real, sin tener que esperar a que se descargue un archivo de video 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" juntos.

La distinción entre "casi en tiempo real" y "en tiempo real" varía, y el retraso depende del tipo y la velocidad de la transmisión. El retraso casi en tiempo real suele oscilar entre 1 y 10 segundos.

Métodos de diseño

Existen varios métodos para ayudar en el 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.