De Wikipedia, la enciclopedia libre
  (Redirigido desde el control en tiempo real )
Saltar a navegación Saltar a búsqueda

La computación en tiempo real ( RTC ) o computación reactiva 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 limitaciones de tiempo especificadas, a menudo denominadas "fechas límite". [2]

A menudo se entiende que las respuestas en tiempo real son del orden de milisegundos y, a veces, microsegundos. Un sistema que no esté especificado como operativo en tiempo real no puede generalmente garantizar una respuesta dentro de ningún período 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; los plazos siempre deben cumplirse, independientemente de la carga del sistema .

Se ha descrito un sistema en tiempo real como aquel que "controla un entorno al recibir datos, procesarlos y devolver los resultados con la suficiente rapidez como para afectar el entorno en ese momento". [3] El término "en tiempo real" también se usa en simulación para significar que el reloj de la simulación funciona a la misma velocidad que un reloj real, y en los sistemas de control de procesos y empresariales para significar "sin demora significativa".

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 y redes en tiempo real, cada uno de los cuales proporciona marcos esenciales sobre los que construir una aplicación de software en tiempo real.

Los sistemas utilizados para muchas aplicaciones de misión crítica deben ser en tiempo real, como para el control de aeronaves fly-by-wire o frenos antibloqueo , los cuales exigen una respuesta mecánica inmediata y precisa. [4]

Historia [ editar ]

El término en tiempo real se deriva de su uso en la simulación inicial , en la que un proceso del mundo real se simula 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 en tiempo real, una situación que podría ser tan peligrosa como una simulación lenta si no se reconociera y contabilizara también.

Las minicomputadoras, particularmente a partir de la década de 1970 en adelante, cuando se integraron en sistemas integrados dedicados como los escáneres DOG ( gráficos digitales en pantalla ), aumentaron la necesidad de respuestas impulsadas por prioridades de baja latencia para interacciones importantes con datos entrantes y, por lo tanto, sistemas operativos como Data general 's RDOS (real-Time disco del sistema operativo) y RTOS con fondo plano y programación , así como digital Equipment Corporation ' s RT-11fecha de esta época. La programación en segundo plano y en primer plano permitía que las tareas de baja prioridad dedicaran tiempo de CPU cuando no era necesario ejecutar ninguna tarea en primer plano, y daba prioridad absoluta en el 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 al algoritmo de programación para hacerlo más apropiado para las personas que interactúan a través de terminales tontas .

Una vez, cuando la tecnología MOS 6502 (utilizada en Commodore 64 y Apple II ), y más tarde, cuando la Motorola 68000 (utilizada en Macintosh , Atari ST y Commodore Amiga ) fueron populares, cualquiera podía usar la computadora de su casa como una computadora en tiempo real. sistema. La posibilidad de desactivar otras interrupciones permitió bucles codificados con temporización definida, 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 menor que el hilo en tiempo real. En comparación con estos, el controlador de interrupciones programablede 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 se haga cargo de la CPU por completo y use su propio programador , sin usar una máquina nativa idioma y superando así todo el código de Windows que interrumpe. 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 reales en términos de rendimiento y seguridad del proceso. [cita requerida ]

Criterios para la computación en tiempo real [ editar ]

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 el 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]

  • Difícil  : perder una fecha límite es una falla total del sistema.
  • Firme  : los incumplimientos de plazos infrecuentes 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 fecha límite, lo que degrada la calidad de servicio del sistema.

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 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 el número de plazos cumplidos, minimizar el retraso de las tareas y maximizar el número de tareas de alta prioridad que cumplen sus plazos.

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 sólidas 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:

  • El sistema de control del motor de un automóvil es un sistema difícil en tiempo real porque una señal retrasada puede causar fallas o daños en el motor.
  • Sistemas médicos como marcapasos cardíacos . Aunque la tarea de un marcapasos es simple, debido al riesgo potencial para la vida humana, los sistemas médicos como estos generalmente deben someterse a pruebas y certificaciones exhaustivas, lo que a su vez requiere una computación en tiempo real para ofrecer garantías comprobables de que una falla 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 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 llevarían a la parada 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 de producción o podría causar daños en etapas posteriores de la producción.
  • Los sistemas duros en tiempo real se encuentran normalmente interactuando a un nivel bajo con hardware físico, en sistemas embebidos . Los primeros sistemas de videojuegos, como los gráficos vectoriales Atari 2600 y Cinematronics, tenían requisitos estrictos en tiempo real debido a la naturaleza de los gráficos y el hardware de sincronización.
  • Softmodems reemplaza un módem de hardware con 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 emitirán. Si esos datos se retrasan, el módem receptor perderá la sincronización, lo que provocará una interrupción prolongada a medida que se restablezca la sincronización o 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 adecuado a medida que el rayo escanea a través de la página). tambor giratorio), matriz de puntos y varios tipos de impresoras de línea (el mecanismo de impacto debe activarse en el momento adecuado a medida que el mecanismo de impresión se alinea con la salida deseada). Una falla en cualquiera de estos podría causar una salida faltante o una salida desalineada.

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 duro en tiempo real (por ejemplo, si el conjunto de tareas y sus prioridades se conocen de antemano). Hay otros programadores duros en tiempo real, como el 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 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 ignora la sobrecarga del cambio de contexto, es suficiente para cargas del sistema inferiores al 100%. [7] Los nuevos sistemas de programación de superposición, como un programador de partición adaptable, 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 están definidos de manera 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 la línea de montaje descrita anteriormente como tiempo real difícil podría considerarse en cambio tiempo real firme . Una fecha límite incumplida aún causa un error que debe tratarse: puede haber maquinaria para marcar una pieza como defectuosa o expulsarla de la línea de ensamblaje, o la línea de ensamblaje podría detenerse para que un operador pueda corregir el problema. Sin embargo, siempre que estos errores sean poco frecuentes, pueden tolerarse.

Los sistemas blandos en tiempo real se utilizan normalmente para resolver problemas de acceso concurrente 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 aviones comerciales . Los planes de vuelo deben mantenerse razonablemente actualizados, pero pueden operar con una latencia de unos segundos.
  • Los sistemas de audio y video en vivo también suelen ser suaves en tiempo real. Un cuadro de audio que se reproduce tarde puede causar un breve error de audio (y puede hacer que todo el audio posterior se retrase en consecuencia, provocando la 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 reproducir silencio, estática, un fotograma de audio anterior o datos estimados. Un fotograma 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 reconfiguración y predicción de la carga de trabajo. [8]
  • Del mismo modo, los videojuegos suelen ser suaves en tiempo real, especialmente cuando intentan alcanzar una velocidad de fotogramas objetivo . Como la siguiente imagen no se puede calcular de antemano, ya que depende de las entradas del reproductor, solo se dispone de un corto tiempo para realizar todos los cálculos necesarios para generar un fotograma de vídeo antes de que se deba mostrar ese fotograma. Si no se cumple la fecha límite, el juego puede continuar a una velocidad de fotogramas más baja; dependiendo del juego, esto solo puede afectar sus gráficos (mientras 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 ).

Procesamiento de señales digitales en tiempo real [ editar ]

En un proceso de procesamiento de señales digitales en tiempo real (DSP), las muestras analizadas (de entrada) y generadas (de salida) se pueden procesar (o generar) continuamente en el tiempo que se tarda en ingresar y emitir el mismo conjunto de muestras independientemente del procesamiento. demora. [9] Significa que el retraso de procesamiento debe estar acotado 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 frecuencia 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 toma 1,99 segundos, es o puede convertirse en un proceso DSP en tiempo real.

Una analogía de la vida común es hacer cola o hacer 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 emitidos tan rápidamente, en promedio, como se ingresan, entonces ese proceso es en tiempo real. El tendero puede quebrar o al menos perder el negocio 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 con la salida cayendo cada vez más por detrás de la entrada, no es en tiempo real. Pero si el retraso de la salida (relativo a la entrada) está limitado con respecto a un proceso que opera durante un tiempo ilimitado, entonces ese algoritmo de procesamiento de señal es en tiempo real, incluso si el retraso de rendimiento puede ser muy largo.

En vivo frente a tiempo real [ editar ]

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 lo 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 retraso del rendimiento para que sea tolerable para los artistas que usan monitores de escenario o monitores internos y no se percibe como un error de sincronización de labios por parte del público que también mira directamente a los artistas. Los límites tolerables de latencia para el procesamiento en tiempo real en vivo es un tema de investigación y debate, pero se estima que está entre 6 y 20 milisegundos. [10]

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

En tiempo real y de alto rendimiento [ editar ]

La computación en tiempo real a veces se malinterpreta como computación de alto rendimiento , pero esta no es una clasificación precisa. [11] Por ejemplo, una supercomputadora masivaLa ejecución de 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 siquiera útiles las mejoras en 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) aún 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 (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 salida constante, no un alto rendimiento.

Algunos tipos de software, como muchos programas de ajedrez., puede caer en cualquier categoría. Por ejemplo, un programa de ajedrez diseñado para jugar en un torneo con reloj necesitará decidir una jugada 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 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 torneo de ajedrez 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á hacerlo. moverse. Este ejemplo también ilustra la diferencia esencial entre los cálculos en tiempo real y otros cálculos: si el programa de ajedrez del torneo no toma una decisión sobre su próximo movimiento en el tiempo asignado, pierde el juego, es decir, falla como un cálculo en tiempo real. mientras que en el otro escenario,Se supone que no es necesario cumplir con el plazo. El alto rendimiento es indicativo de la cantidad de procesamiento que se realiza en una cantidad de tiempo determinada, mientras que el tiempo real es la capacidad de terminar con el procesamiento para producir una salida útil en el tiempo disponible.

Casi en tiempo real [ editar ]

El término "casi en tiempo 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, como con fines de visualización o retroalimentación y control. Por ejemplo, una pantalla casi en tiempo real muestra un evento o situación tal como existía en el momento actual menos el tiempo de procesamiento, casi como el tiempo 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 en cuestión. El término implica que no hay retrasos importantes. [12] 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 retrasada en tiempo real de voz y video. Permite reproducir imágenes de video, aproximadamente en tiempo real, sin tener que esperar a que se descargue todo un archivo de video grande. 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í.

La distinción entre "tiempo casi real" y "tiempo real" varía, y el retraso depende del tipo y la velocidad de la transmisión. El retraso en tiempo casi real suele estar en un rango de 1 a 10 segundos. [ cita requerida ]

Métodos de diseño [ editar ]

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 .

Ver también [ editar ]

  • Operación periférica autónoma
  • DSOS
  • Modos de procesamiento
  • Proyecto Ptolomeo
  • Datos en tiempo real
  • Gráficos por computadora en tiempo real
  • Pruebas en tiempo real
  • Programación de análisis de sistemas en tiempo real
  • Lenguaje de programación sincrónico
  • Función de utilidad de tiempo
  • Tiempo de ejecución en el peor de los casos

Referencias [ editar ]

  1. ^ "FreeRTOS - Kernel RTOS de código abierto para pequeños sistemas integrados - ¿Qué son las preguntas frecuentes de FreeRTOS?" . FreeRTOS . Consultado el 8 de marzo de 2021 .
  2. ^ Ben-Ari, Mordejai ; "Principios de programación concurrente y distribuida", cap. 16, Prentice Hall, 1990, ISBN 0-13-711821-X , página 164 
  3. ^ Martin, James (1965). Programación de sistemas informáticos en tiempo real . Englewood Cliffs, Nueva Jersey: Prentice-Hall Inc. p. 4 . ISBN 978-0-13-730507-0.
  4. ^ Kant, Krishna (mayo de 2010). Control industrial basado en computadora . Aprendizaje de PHI. pag. 356. ISBN 9788120339880. Consultado el 17 de enero de 2015 .
  5. ^ Shin, Kang G .; Ramanathan, Parameswaran (enero de 1994). "Computación en tiempo real: una nueva disciplina de la informática y la ingeniería" (PDF) . Actas del IEEE . 82 (1): 6–24. CiteSeerX 10.1.1.252.3947 . doi : 10.1109 / 5.259423 . ISSN 0018-9219 .   
  6. ^ Kopetz, Hermann; Sistemas en tiempo real: principios de diseño para aplicaciones integradas distribuidas , Kluwer Academic Publishers, 1997
  7. ^ Liu, Chang L .; y Layland, James W .; "Algoritmos de programación para la multiprogramación en un entorno difícil en tiempo real", Journal of the ACM , 20 (1): 46-61, enero de 1973, http://citeseer.ist.psu.edu/liu73scheduling.html
  8. ^ Menychtas, Andreas; Kyriazis, Dimosthenis; Tserpes, Konstantinos (julio de 2009). "Reconfiguración en tiempo real para garantizar niveles de aprovisionamiento QoS en entornos Grid". Sistemas informáticos de futura generación . 25 (7): 779–784. doi : 10.1016 / j.future.2008.11.001 .
  9. ^ Kuo, Sen M .; Lee, Bob H .; y Tian, ​​Wenshun; "Procesamiento de señales digitales en tiempo real: implementaciones y aplicaciones", Wiley, 2006, ISBN 0-470-01495-4 , Sección 1.3.4: Restricciones en tiempo real . 
  10. ^ Kudrle, Sara; Proulx, Michel; Carrieres, Pascal; López, Marco; et al. (Julio de 2011). "Toma de huellas dactilares para resolver problemas de sincronización de A / V en entornos de transmisión". Diario de imágenes en movimiento SMPTE . 120 (5): 36–46. doi : 10.5594 / j18059XY . Se han establecido límites de sincronización A / V apropiados y el rango que se considera aceptable para la película es +/- 22 ms. El rango para video, según el ATSC, es de hasta 15 ms de tiempo de espera y de aproximadamente 45 ms de tiempo de retraso.
  11. ^ Stankovic, John (1988), "Conceptos erróneos sobre la informática en tiempo real: un problema grave para los sistemas de próxima generación", Computadora , IEEE Computer Society, 21 (10), p. 11, doi : 10.1109 / 2.7053 , S2CID 13884580 
  12. ^ a b "Estándar federal 1037C: Glosario de términos de telecomunicaciones" . Its.bldrdoc.gov . Consultado el 26 de abril de 2014 .

Lectura adicional [ editar ]

  • Burns, Alan; Wellings, Andy (2009), Sistemas en tiempo real y lenguajes de programación (4a ed.), Addison-Wesley, ISBN 978-0-321-41745-9
  • Buttazzo, Giorgio (2011), Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications , Nueva York, NY: Springer, ISBN 9781461406761.
  • Liu, Jane WS (2000), Sistemas en tiempo real , Upper Saddle River, Nueva Jersey: Prentice Hall.
  • The International Journal of Time-Critical Computing Systems

Enlaces externos [ editar ]

  • Comité técnico de IEEE sobre sistemas en tiempo real
  • Comité Técnico de Euromicro sobre Sistemas en Tiempo Real
  • El qué, dónde y por qué de la simulación en tiempo real
  • "DISEÑO DE UN SISTEMA DE PROGRAMACIÓN EN TIEMPO REAL" . Informática y Automatización . XII (9): 26–34. Septiembre de 1963. [...] conjunto de notas que, con suerte, señalarán áreas problemáticas que deberían ser consideradas en el diseño en tiempo real.