Sistema en tiempo real

Cuando los sistemas en tiempo real ( inglés real-time systems ) son "sistemas para el control y la gestión de procesos designados de inmediato ", se les pide que se cumplan los requisitos cuantitativos en tiempo real . Estos se utilizan en diversos campos de la tecnología, por ejemplo, en la tecnología de control de procesos , en los controles de motores , en la tecnología de sistemas de satélite, en los sistemas de señalización y control de interruptores , en robótica y en otras áreas.

A menudo, el requisito es que se garantice que un resultado se calculará dentro de un intervalo de tiempo predefinido, es decir, que esté disponible antes de un cierto límite de tiempo. El tamaño del intervalo de tiempo es irrelevante: mientras que para algunas tareas (por ejemplo, en el control del motor) un segundo puede ser demasiado largo, horas o incluso días son suficientes para otros problemas. Por lo tanto, un sistema en tiempo real no solo debe entregar un resultado de medición o cálculo con el valor correcto, sino que también debe entregar el mismo a tiempo . De lo contrario, el sistema ha fallado.

En la práctica, no siempre se puede implementar un límite de tiempo arbitrariamente pequeño debido a la falta de hardware lo suficientemente rápido. Por eso se habla de "en tiempo real " cuando los programas funcionan sin un retraso notable. Sin embargo, esta definición es muy imprecisa. Es fundamentalmente incorrecto ver "sistema en tiempo real" como sinónimo de "particularmente rápido". Por el contrario, los sistemas en tiempo real deben planificar los tiempos de inactividad adecuados para cumplir con sus requisitos en tiempo real, incluso en situaciones particularmente exigentes.

Tiempo real duro, suave y firme

definición

En función de las consecuencias, una distinción se hace a veces entre los de tiempo real , en tiempo real suave y en tiempo real firme . Se aplican diferentes requisitos de tiempo real para esto.

• duras exigencias de tiempo real: Supera el tiempo de respuesta se considera un fracaso. Después de un registro de tiempo exacto de la aplicación a proporcionar, son necesarios los cálculos de acuerdo con la teoría de los sistemas de tiempo real. Los sistemas en tiempo real siempre brindan el resultado correcto dentro de los límites de tiempo especificados. Puede confiar en esta propiedad cuando utilice un sistema estricto en tiempo real.

• Requisitos suaves en tiempo real: estos sistemas generalmente procesan todas las entradas entrantes con la suficiente rapidez . El tiempo de respuesta alcanza, por ejemplo, un valor medio aceptable u otro criterio estadístico . Los requisitos de tiempo deben considerarse aquí como pautas. Exceder el requisito de tiempo no tiene por qué considerarse un fracaso. Por un lado, el tiempo a menudo se puede exceder siempre que se encuentre dentro de un rango de tolerancia. Por otro lado, rara vez se puede superar de manera significativa.

• Fijos requisitos de tiempo real: con requisitos de tiempo real fijos, no hay riesgo de daño inmediato. Sin embargo, una vez vencidos los requisitos de tiempo, el resultado del cálculo es inútil y se puede descartar.

Dependiendo del problema y la perspectiva, también se utiliza la siguiente definición:

• Requisitos suaves en tiempo real: el sistema debe reaccionar en el período de tiempo especificado, pero no entregar el resultado completo. Si no hay respuesta, se considera que el proceso ha fallado y se cancela. Alternativamente, los sistemas blandos en tiempo real a veces pueden entregar el resultado correctamente, pero demasiado tarde.
• Requisitos estrictos en tiempo real: el sistema debe presentar el resultado completo en la ventana de tiempo definida.

Dentro de los sistemas blandos en tiempo real, a veces hay más clasificaciones que diferencian más finamente cuando se exceden los tiempos de respuesta. Los criterios comunes son:

• El resultado ya no tiene ningún valor; el cálculo se cancela y se descarta.
• La utilidad del resultado disminuye a partir del final del tiempo de respuesta.
• Se acepta exceder el tiempo de respuesta y se acepta el resultado si está disponible.

Incluso la definición de sistemas blandos en tiempo real es de naturaleza bastante coloquial, por lo que una subdivisión más fina es aún más difícil de dar.

La norma DIN 44300 define bajo operación en tiempo real (llamada allí operación en tiempo real) la operación de un sistema informático en el que los programas para procesar datos acumulados están siempre listos para operar, de tal manera que los resultados del procesamiento están disponibles dentro de un período de tiempo especificado. Este estándar de términos no ha podido establecerse en la práctica como la única definición aceptada, dominan los términos del área de habla inglesa.

Ejemplos

• Los sistemas de videoconferencia tienen que grabar, preprocesar, enviar y mostrar imágenes y sonido en milisegundos. Si esto no funciona para algunas imágenes, la pantalla se "sacudirá" un poco, pero puede seguir trabajando sin consecuencias negativas. El sistema solo tiene que cumplir con requisitos suaves en tiempo real.
• Un programa que va a grabar secuencias de video (más largas), por otro lado, tiene que cumplir con estrictos requisitos de tiempo real. Si no es posible guardar los datos de video en el soporte de datos con la suficiente rapidez, las imágenes se perderán y el video no podrá utilizarse para muchas aplicaciones.
• El control electrónico del motor en un automóvil debe cumplir con estrictos requisitos en tiempo real; de lo contrario, el motor tartamudeará o el automóvil se detendrá. La avería o un tiempo real duro que no se mantenga correctamente puede provocar daños mecánicos o, en el peor de los casos, un accidente.

implementación

El tiempo real describe el comportamiento temporal de entrada y salida de un sistema, pero no dice nada sobre su implementación. Un sistema en tiempo real puede ser una computadora con el software adecuado o una solución pura de hardware. Los sistemas EDP estándar se utilizan a menudo para requisitos con los llamados límites suaves . Se utilizan arquitecturas especiales (hardware y software) para requisitos con límites estrictos, p. Ej. B. Soluciones basadas en microcontroladores , FPGA o DSP .

Activación periódica fija

Un enfoque para cumplir con el tiempo de respuesta requerido para aplicaciones específicas es utilizar una unidad funcional separada que solo cumpla esta tarea con una frecuencia fija , derivada del tiempo de respuesta . Un ejemplo de implementación de hardware es la digitalización con un ADC como unidad funcional y un reloj de cristal , p. B. digitalizar sonidos para un CD de audio con una frecuencia requerida de 44,1 kHz (corresponde a un tiempo de respuesta ≤ 22,7 microsegundos). Esta solución cumple de forma fiable el estricto criterio del tiempo real, ya que fue diseñada específicamente para realizar una única tarea. Sin embargo, una tarea compleja en tiempo real desglosada de acuerdo con este principio (como un control con muchos parámetros de entrada con alta dinámica en los tiempos de respuesta requeridos) puede resultar costosa y compleja debido a la asincronía y las partes redundantes del sistema a resolver . ${\ displaystyle f = {\ frac {1} {\ text {Tiempo de respuesta}}}}$

Enfoques sincrónicos

Un enfoque generalizado para varias tareas es el uso de una plataforma de solución única, igualmente sincronizada (síncrona), generalmente implementada con microcontroladores , DSP , CPU o FPGA . Los tiempos de reacción requeridos para la condición en tiempo real se intentan en este concepto de solución procesando todas las tareas secuencialmente lo más rápido posible. La condición de tiempo real se cumple definitivamente si el menor tiempo de reacción requerido entre las tareas es el doble del tiempo de ejecución máximo para una ejecución total de todas las tareas.

Un ejemplo sería un control en tiempo real con un microcontrolador que recibe varios parámetros de entrada, calcula una reacción y la devuelve. Suponga que una respuesta al exceso de temperatura con un tiempo de reacción de ≤ 1 sy una velocidad de menos de ≤ 1 ms es para establecer una señal de apagado . Una solución técnicamente simple en un microprocesador con una frecuencia de reloj de 2 MHz sería un simple bucle de programa sin fin (ejemplo en el código de pseudoensamblador de sintaxis Intel , el punto y coma es un carácter de comentario): ${\ Displaystyle t}$${\ Displaystyle d}$${\ Displaystyle O = 1}$

  mov a, 10000 ; Grenzwert der Drehzahl
  mov b, 30    ; Grenzwert der Temperatur
  mov O,1      ; Abschaltsignal

:loop          ; Markierung im Programmfluss (keine Instruktion, wird vom Assembler für Sprungadressen verwendet)
  in d,PORT1   ; einlesen der aktuellen drehzahl-Werte
  in t,PORT2   ; einlesen der aktuellen temp-Werte

:drehcheck
  cmp d,a      ; prüfe die Drehzahl
  jg  tempcheck; wenn Grenzwert nicht erreicht, springe zu :tempcheck
  out PORT3,O  ; Grenzwert erreicht! setze Abschaltsignal

:tempcheck
  cmp t,b      ; prüfe die Temperatur
  jg  loop     ; wenn Grenzwert nicht erreicht, springe zu :loop
  out PORT3,O  ; Grenzwert erreicht! setze Abschaltsignal

  jmp loop     ;unbedingter Sprung zur Marke :loop (Endlosschleife)

Suponiendo que cada instrucción en este procesador (cada línea de código) cuesta un ciclo de reloj en el tiempo, se realiza una ejecución de prueba en 6 ciclos de reloj, con un tiempo de reacción en el peor de los casos de 12 ciclos de reloj para la temperatura ( ) y 11 para la velocidad ( ) . Los estrictos requisitos de tiempo real se cumplen con este control, pero órdenes de magnitud más rápido de lo que realmente sería necesario ( ineficaz ). Una extensión del control en tiempo real z. B. probar una impresión es posible a través de este sobredimensionamiento del sistema. Sin embargo, el tiempo de respuesta logrado para cada una de las subtareas aumenta con el tiempo de vencimiento total . El límite de este diseño se ha alcanzado cuando, en el peor de los casos, el doble del tiempo de vencimiento total supera el tiempo de respuesta para una tarea parcial. ${\ Displaystyle t _ {\ text {loop}}}$${\ displaystyle {\ frac {12} {2000000}} = 0 {,} 006 \, {\ text {ms}}}$${\ displaystyle {\ frac {11} {2000000}} = 0 {,} 0055 \, {\ text {ms}}}$${\ Displaystyle p}$${\ displaystyle t_ {loop}}$${\ displaystyle t_ {loop}}$

Este concepto es el paradigma común en la computadora en aplicaciones multimedia como video , demos y juegos . Normalmente, solo se cumple el criterio de condición de tiempo real suave , ya que no se puede determinar el tiempo de procesamiento / tiempo de respuesta en el peor de los casos (o, como en el ejemplo anterior, no se puede contar) y / o no es determinista debido a la complejidad del sistema . En aplicaciones multimedia, este no determinismo se expresa, p. Ej. B. sobre la variación de FPS o tiempos de respuesta para las entradas. Las razones de este no determinismo son la existencia de varias rutas de código con diferentes tiempos de ejecución, la espera de ejecución de entradas o salidas o simplemente tareas con complejidad variable (por ejemplo, complejidad variable del escenario en juegos de computadora ).

Enfoques basados ​​en procesos

En sistemas complejos en tiempo real (como un PLC o una computadora que actúa como un sistema en tiempo real), varios procesos generalmente se ejecutan simultáneamente y con diferentes prioridades, controlados por un sistema operativo en tiempo real . El tiempo mínimo de respuesta se define por el tiempo requerido para un cambio completo de un proceso de menor prioridad a un proceso de mayor prioridad. Este cambio se inicia cuando ocurre un evento definido, p. Ej. B. generado por un disparador externo ( interrupción en tecnología informática ) o temporizador interno. El procesamiento real del proceso llamado solo comienza después de que se ha llevado a cabo el cambio de proceso. Esto hace cumplir la dura criterio en tiempo real de una tarea de mayor prioridad interrumpiendo la ejecución de una tarea de menor prioridad ( multitarea preferente ).

En principio, una PC también es capaz de trabajar en tiempo real, pero no, o solo de forma limitada, si se opera con sistemas operativos multitarea clásicos , ya que muchos procesos asíncronos se ejecutan de manera no determinista. Los sistemas operativos en tiempo real a menudo también son capaces de realizar múltiples tareas, pero tienen un programador diferente al de los sistemas convencionales. También hay soluciones en las que un sistema operativo estándar existente se convierte en capaz en tiempo real mediante la adición de software especial. Esto tiene la ventaja de que solo los procesos realmente críticos en el tiempo deben ejecutarse en el sistema en tiempo real y las API normales (incluidos los compiladores o GUI ) del sistema operativo subyacente se pueden usar para el resto .

Los sistemas operativos en tiempo real también se utilizan en controladores lógicos programables (PLC) y sistemas de control de procesos (PCS), pero el usuario no puede acceder directamente a ellos.

En el caso de un software que se supone que cumple con las condiciones de tiempo real, el tiempo de ejecución máximo debe ser determinable y no debe estar sujeto a ningún factor que no pueda ser influenciado o que solo pueda ser influenciado de manera limitada, es decir, debe ser determinista . Esto será u. a. influenciado por las siguientes propiedades del sistema o software:

• Un problema son las E / S complejas, p. Ej. B. Discos duros con caché y modo de suspensión automático o comunicación de red con temporización no determinista (por ejemplo, IP ).
• También se debe tener en cuenta el tiempo de ejecución del sistema operativo y las llamadas a la biblioteca.
• Debe conocerse la necesidad de recursos, especialmente la necesidad de almacenamiento . El entorno de ejecución y el hardware deben poder cumplir con los requisitos de recursos.
• Con la recursividad la profundidad máxima de recursividad, con los bucles el número máximo de iteraciones debe ser fijo.
• Gestión de la memoria: por lo tanto, debe asegurarse de que los módulos en tiempo real no se vean afectados por la gestión de la memoria virtual del sistema operativo y nunca se intercambien (esta es la razón por la que los sistemas en tiempo real normalmente no utilizan ninguna gestión de memoria virtual).
• El uso de un recolector de basura automático , por ejemplo, también es particularmente problemático , cuyo tiempo de ejecución debe estimarse de manera muy pesimista.
• El comportamiento en caso de un tiempo de espera inminente debe estar definido y ser predecible.

Ejemplos de sistemas en tiempo real

Los ordenadores para controlar equipos técnicos o procesos como máquinas, sistemas de ingeniería de procesos o medios de transporte son prácticamente siempre sistemas en tiempo real. Un sistema en tiempo real reacciona a todos los eventos a tiempo y procesa los datos "siguiendo el ritmo" del proceso técnico. Por así decirlo, no depende del proceso técnico, ni en casos normales ni en situaciones críticas.

• La temperatura de un aparato en una planta de proceso generalmente solo cambia en minutos. Por lo tanto, un controlador que reacciona a las desviaciones en varios segundos puede considerarse capaz de funcionar en tiempo real. El tiempo de reacción está en el rango de segundos.
• Las aplicaciones gráficas en la computadora , como juegos o demostraciones, requieren tiempos de reacción de ≤ 63 ms (≥ 14–16  imágenes por segundo ) al actualizar la visualización de la pantalla para que se perciban como un proceso fluido.
• Los programas informáticos cuyos tiempos de respuesta a la entrada del usuario con dispositivos de entrada ( teclado , ratón , etc.) son inferiores a 10 ms se perciben subjetivamente como inmediatos (ver usabilidad ).

• El control del airbag en el automóvil tiene que procesar los valores medidos de los sensores de forma continua y en muy poco tiempo y decidir si se activa el airbag y con qué fuerza; el tiempo de respuesta está en el rango de 1 ms.
• Un sistema de frenos antibloqueo en un automóvil generalmente tiene una frecuencia de control de ≥100 Hz, es decir, H. el tiempo de respuesta es inferior a 10 ms.
• En las máquinas herramienta , la posición mutua de la pieza de trabajo y la herramienta cambia. Los controles CNC actuales tienen una resolución de tiempo del control de movimiento de 125 µs.
• En un automóvil, el sistema electrónico de gestión del motor tiene que entregar sus resultados (cantidad de combustible a inyectar, punto de encendido) en determinados momentos. Los resultados que llegan más tarde son inútiles. El tiempo de respuesta depende directamente de la velocidad y desciende a 1 ms para motores típicos a altas velocidades con muchos cilindros.
• Para la deflexión precisa de haces de electrones, p. Ej. B. en la soldadura por haz de electrones , los campos magnéticos con frecuencias de 100 kHz a 1 MHz deben regularse. El tiempo de respuesta está comprendido entre 1 µs y 10 µs.

Paradigmas de diseño

Hay dos diseño paradigmas de aplicación: evento impulsado y controlado por tiempo .

Con el control de eventos, se reacciona a un evento externo (generalmente mediante una interrupción ) lo más rápido posible, es decir, H. Se inició el procesamiento. Si es necesario, se interrumpe el procesamiento que se está ejecutando actualmente. El control de eventos tiene la ventaja de que reacciona al evento con muy poca pérdida de tiempo. Debido a que es intuitivo, también se usa ampliamente. La principal desventaja es que no se puede evitar que puedan ocurrir varios eventos en un corto período de tiempo, lo que puede llevar a una sobrecarga del sistema de tiempo real (con pérdida de eventos y / o superación de los límites de tiempo). Para evitar este problema, es necesario definir claramente qué eventos pueden ocurrir con qué frecuencia máxima. Normalmente, las prioridades se utilizan para determinar el orden en el que se procesarán los eventos que ocurren simultáneamente. En un entorno de tiempo real difícil, se debe garantizar que incluso en el peor de los casos (número y frecuencia máximos de todos los eventos posibles), incluso el proceso con la prioridad más baja todavía puede entregar su resultado dentro de los límites de tiempo, es decir, H. todavía tiene suficiente tiempo de cálculo para completar su tarea.

En el control de tiempo, los procesamientos se inician en base a un horario predeterminado. A cada proceso se le asigna un intervalo de tiempo definido con precisión en el programador (por ejemplo, exactamente 10 ms cada 100 ms). La ventaja es que generalmente se pueden descartar sobrecargas (siempre que el proceso nunca exceda el tiempo asignado). El comportamiento de la aplicación es predecible en todo momento, lo que hace que el control de tiempo sea adecuado para aplicaciones críticas para la seguridad. La desventaja del control del tiempo es el mayor esfuerzo de planificación (la asignación de tiempo debe conocerse con precisión durante la implementación de los procesos) y el uso asociado de herramientas. Otra ventaja es que con el control de tiempo los recursos disponibles (tiempo de CPU, memoria) se pueden utilizar al 100 por ciento, mientras que con el control de eventos esto no es posible debido a su asincronía . Con el control de eventos, siempre se debe planificar una reserva para los recursos de modo que el sistema pueda "ponerse al día" con el tiempo cuando la carga es alta.

Ver también

• simulación

literatura

• Dieter Zöbel: Sistemas en tiempo real: conceptos básicos de planificación . Springer Vieweg, 2020, ISBN 978-3-662-60421-2 .
• Sascha Roeck: Simulación en tiempo real de plantas de producción con sistemas de control reales . Jost-Jetter Verlag, 2007, ISBN 3-939890-24-3 .
• Hermann Kopetz : Sistemas en tiempo real. Principios de diseño para aplicaciones integradas distribuidas (= Serie internacional de Kluwer en ingeniería y ciencias de la computación. Vol. 395). Editores Académicos Kluwer, Boston MA a. a. 1997, ISBN 0-7923-9894-7 .
• H. Zedan (Ed.): Sistemas en tiempo real. Teoría y Aplicaciones. Actas de la conferencia, organizada por la British Computer Society, York, 28-29 de septiembre de 1989. North-Holland et al. a., Amsterdam a. a. 1990, ISBN 0-444-88625-7 .

enlaces web

• Comp.realtime: Preguntas más frecuentes (FAQ) :

  regularmente en el grupo de noticias comp.realtime publicado

  • en formato HTML
  • a través de FTP anónimo

• faqs.org
• dedicados-sistemas.com
• dedicados-sistemas.com
• Preguntas frecuentes sobre Linux en tiempo real

Evidencia individual

1. ↑ Ciencias de la computación: un léxico especializado para el estudio y la práctica . Dudenverlag, Mannheim 2003, ISBN 3-411-10023-0 , pág.537
2. ^ ^{A b} Heinz Wörn, Uwe Brinkschulte: Sistemas en tiempo real. Conceptos básicos, funciones, aplicaciones . Springer, Berlín a. a. 2005, ISBN 3-540-20588-8 , págs. 321 , doi : 10.1007 / b139050 . 
3. ↑ Boris Burger, Ondrej Paulovic, Milos Hasan: Métodos de visualización en tiempo real en la demostración ( en ) En: CESCG-2002 . Universidad Técnica de Viena . 21 de marzo de 2002. Consultado el 21 de marzo de 2011.