¿Diferencias entre tiempo real duro, tiempo real suave y tiempo real firme?

Duro en Tiempo Real

La definición en tiempo real considera que cualquier fecha límite perdida es un fallo del sistema. Esta programación se utiliza ampliamente en sistemas de misión crítica donde el incumplimiento de las restricciones de tiempo resulta en una pérdida de vidas o bienes.

Ejemplos:

• El vuelo 447 de Air France se estrelló en el océano después de que un mal funcionamiento del sensor causara una serie de errores en el sistema. Los pilotos detuvieron el avión mientras respondiendo a lecturas de instrumentos obsoletas. Los 12 tripulantes y 216 pasajeros murieron.

• La nave espacial Mars Pathfinder casi se perdió cuando una inversión de prioridad causó que el sistema se reiniciara. Una tarea de mayor prioridad no se completó a tiempo debido a que fue bloqueada por una tarea de menor prioridad. El problema fue corregido y la nave espacial aterrizó con éxito.

• Una impresora de inyección de tinta tiene un cabezal de impresión con software de control para depositar la cantidad correcta de tinta en un parte específica del artículo. Si se pierde una fecha límite, el trabajo de impresión se arruina.

Firme en Tiempo Real

La definición firme en tiempo real permite que los plazos se incumplan con poca frecuencia. En estas aplicaciones, el sistema puede sobrevivir a los fallos de las tareas siempre y cuando estén espaciados adecuadamente, sin embargo, el valor de la finalización de la tarea cae a cero o se vuelve imposible.

Ejemplos:

• Sistemas de fabricación con las líneas de montaje de robots donde la falta de un plazo resulta en el montaje incorrecto de una pieza. Mientras las piezas arruinadas sean lo suficientemente infrecuentes como para ser atrapadas por el control de calidad y no demasiado costosas, la producción continúa.

• Un decodificador de cable digital decodifica las marcas de tiempo para cuándo deben aparecer los marcos en la pantalla. Dado que los marcos son sensibles al orden de tiempo, una fecha límite perdida causa jitter, disminuyendo la calidad del servicio. Si el fotograma perdido más tarde está disponible, solo causará más nerviosismo para mostrarlo, por lo que es inútil. El espectador todavía puede disfrutar del programa si el jitter no ocurre con demasiada frecuencia.

Suave en Tiempo Real

La definición suave en tiempo real permite que los plazos se pierdan con frecuencia, y mientras las tareas se ejecuten a tiempo, sus resultados seguirán teniendo valor. Las tareas completadas pueden tener un valor creciente hasta la fecha límite y un valor decreciente más allá de ella.

Ejemplos:

• Las estaciones meteorológicas tienen muchos sensores para leer la temperatura, la humedad, la velocidad del viento, etc. Las lecturas deben tomarse y transmitirse a intervalos regulares, sin embargo, los sensores no están sincronizados. A pesar de que la lectura de un sensor puede ser temprana o tardía en comparación con los demás, todavía puede ser relevante siempre y cuando esté lo suficientemente cerca.

• Una consola de videojuegos ejecuta software para un motor de juegos. Hay muchos recursos que debe ser compartida entre sus tareas. Al mismo tiempo, las tareas deben completarse de acuerdo con el calendario para que el juego juegue correctamente. Mientras las tareas estén siendo completamente relativamente a tiempo, el juego será agradable, y si no, solo puede retrasarse un poco.

^{Siewert: Sistemas y Componentes Embebidos en Tiempo Real.
Liu & Layland: Algoritmos de Programación para Multiprogramación en un Entorno Duro en Tiempo Real.
Marchand & Silly-Chetto: Programación Dinámica de Tareas Aperiódicas Suaves y Tareas Periódicas con Saltos.}

Después de leer la página de Wikipedia y otras páginas sobre computación en tiempo real. Hice las siguientes inferencias:

1> Para un sistema duro en tiempo real, si el sistema no cumple con la fecha límite incluso una vez que se considera que el sistema ha fallado.

2> Para un Sistema firme en tiempo real, incluso si el sistema no cumple con el plazo, posiblemente más de una vez (es decir, para múltiples solicitudes), no se considera que el sistema haya fallado. Además, las respuestas a las solicitudes (respuestas a una consulta, resultado de una tarea, etc.) no valen nada una vez que la fecha límite para esa solicitud en particular ha pasado (La utilidad de un resultado es cero después de su fecha límite). Un ejemplo hipotético puede ser un sistema de pronóstico de tormentas(si se predice una tormenta antes de la llegada, entonces el sistema ha hecho su trabajo, la predicción después de que el evento ya ha ocurrido o cuando está sucediendo no tiene valor).

3 > Para un sistema en tiempo real suave , incluso si el sistema no cumple plazo, posiblemente más de una vez (es decir, para múltiples solicitudes), el sistema no se considera que ha fallado. Pero, en este caso los resultados de las solicitudes no son inútiles valor para un resultado después de su fecha límite, no es cero , sino que se degrada a medida que pasa el tiempo después de la fecha límite. Eg.: Streaming audio-video.

Aquí hay un enlace a un recurso que fue muy útil.

Es popular asociar alguna gran catástrofe con la definición de tiempo real duro, pero esto no es relevante. Cualquier falla para cumplir con una restricción de tiempo real dura simplemente significa que el sistema está roto. La gravedad del resultado cuando algo es etiquetado como "roto" no es material para la definición.

Firme y suave simplemente no se declaran automáticamente roto en el incumplimiento de un plazo único.

Para un ejemplo justo de tiempo real duro, desde la página que linked:

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 sincronización.

Si algo en el bucle de generación de vídeo perdiera solo una fecha límite, entonces toda la pantalla se fallaría, lo que sería intolerable, incluso si fuera raro. Eso sería un sistema roto y lo llevarías de vuelta a la tienda para un reembolso. Así que es difícil en tiempo real.

Obviamente, cualquier sistema puede estar sujeto a situaciones que no puede manejar, por lo que es necesario restringir la definición a estar dentro de las condiciones de operación esperadas noting notando que en aplicaciones críticas para la seguridad las personas deben planificar para condiciones terribles ("el refrigerante se ha evaporado", "los frenos han fallado", pero rara vez "el sol ha explotado").

Y no olvidemos que a veces hay una condición de funcionamiento implícita "mientras alguien está mirando". Si nadie ve rompes las reglas (o si lo hicieron, pero mueren en el incendio antes de decírselo a nadie), y nadie puede probar que rompiste las reglas después del hecho, ¡entonces es algo así como si nunca rompieras las reglas!

La forma más sencilla de distinguir entre los diferentes tipos de sistemas en tiempo real es responder a la pregunta:

¿Una respuesta del sistema retrasada (después de la fecha límite) sigue siendo útil o no?

Así que dependiendo de la respuesta que obtenga para esta pregunta, su sistema podría incluirse como una de las siguientes categorías:

1. Difícil : No, y las respuestas retrasadas se consideran un fallo del sistema

Este es el caso cuando falta el la línea muerta hará que el sistema sea inutilizable. Por ejemplo, el sistema que controla el sistema de Airbag del automóvil debe detectar el accidente e inflar rápidamente la bolsa. Todo el proceso toma más o menos un veinticinco de segundo. Por lo tanto, si el sistema, por ejemplo, reacciona con 1 segundo de retraso, las consecuencias podrían ser mortales y no será ningún beneficio tener la bolsa inflada una vez que el automóvil ya se haya estrellado.

1. Firme : No, pero las respuestas retrasadas no son necesarias un fallo del sistema

Este es el caso cuando el incumplimiento del plazo es tolerable, pero afectará a la calidad del servicio. Como un ejemplo simple considere un sistema de encriptación de video. Normalmente la contraseña de cifrado se genera en el servidor (cabecera de vídeo) y se envía al decodificador del cliente. Este proceso debe sincronizarse para que normalmente el decodificador reciba la contraseña antes de comenzar a recibir los fotogramas de vídeo cifrados. En este caso, un retraso puede conducir a fallos de vídeo ya que el decodificador no es capaz de decodificar los fotogramas porque aún no ha recibido la contraseña. En este caso, el servicio (película, un partido de fútbol interesante, etc.) podría verse afectado por no cumplir con el plazo. Recibir la contraseña con retraso en este caso no es útil ya que los fotogramas cifrados con la misma ya han causado los fallos.

1. Soft : Sí, pero el servicio del sistema está degradado

A partir de la wikipedia descripción la utilidad de un resultado se degrada después de su fecha límite. Eso significa que obtener una respuesta del sistema fuera de la fecha límite sigue siendo útil para el usuario final, pero su utilidad se degrada después de alcanzar la fecha límite. Un ejemplo sencillo para este caso es un software que controla automáticamente la temperatura de una habitación (o un edificio). En este caso, si el sistema tiene algunos retrasos en la lectura de los sensores de temperatura, será un poco lento para reaccionar ante los cambios bruscos de temperatura. Sin embargo, al final terminará reaccionando al cambio y ajustando en consecuencia la temperatura para mantenerlo constante, por ejemplo. Así que en este caso la reacción retardada es útil, pero degrada la calidad del servicio del sistema.

Un tiempo real suave es más fácil de entender, en el que incluso si el resultado se obtiene después de la fecha límite, los resultados todavía se consideran válidos.

Ejemplo: Navegador web: Solicitamos cierta URL, lleva algún tiempo cargar la página. Si el sistema tarda más de lo esperado en proporcionarnos la página, la página obtenida no se considera inválida, solo decimos que el rendimiento del sistema no estaba a la altura de la marca (el sistema dio baja ¡actuación!).

En el sistema hard real time, si el resultado se obtiene después de la fecha límite, se considera que el sistema ha fallado completamente.

Ejemplo: En el caso de un robot haciendo algún trabajo como trazado de líneas, etc. Si un obstáculo viene en su camino, y el robot no procesa esta información dentro de algún plazo programado (¡casi instantáneo!), se dice que el robot ha fallado en su tarea (el sistema de robot también puede quedar completamente destruido!).

En sistema firme en tiempo real , si el resultado de la ejecución del proceso viene después de la fecha límite, descartamos ese resultado, pero no se denomina que el sistema haya fallado.

Ejemplo: Comunicación satelital para monitoreo de posición enemiga o alguna otra tarea. Si la estación informática terrestre a la que los satélites envían los fotogramas periódicamente está sobrecargada, y el fotograma actual (paquete) no se procesa a tiempo y aparece el siguiente fotograma, el paquete actual (el que perdió la fecha límite) no importa si el procesamiento se realizó (o medio hecho o casi terminado) se deja de lado/se descarta. Pero la computadora de tierra no se llama para haber fallado completamente.

Para definir "tiempo real suave", es más fácil compararlo con "tiempo real duro". A continuación veremos que el término "tiempo real firme" constituye un malentendido sobre "tiempo real suave"."

Hablando casualmente, la mayoría de las personas implícitamente tienen un modelo mental informal que considera la información o un evento como "en tiempo real"

* si, o en la medida en que, se les manifiesta con un retraso (latencia) que puede estar relacionado con su moneda percibida

* es decir, en un tiempo marco que la información o evento tiene un valor aceptablemente satisfactorio para ellos.

Existen numerosas definiciones ad hoc de "tiempo real duro", pero en ese modelo mental, el tiempo real duro está representado por el término "si". Específicamente, suponiendo que las acciones en tiempo real (como las tareas) tienen plazos de finalización, el valor aceptablemente satisfactorio del evento que todas las tareas completadas se limita al caso especial de que todas las tareas cumplan con sus plazos.

Los sistemas duros en tiempo real hacen las suposiciones muy fuertes de que todo sobre la aplicación y el sistema y el entorno es estático y conocido a ' priori-por ejemplo, qué tareas, que son periódicas, sus tiempos de llegada, sus períodos, sus plazos, que no tendrán conflictos de recursos, y en general la evolución del tiempo del sistema. En un sistema de control de vuelo de una aeronave o un sistema de frenado automotriz y muchos otros casos, esas suposiciones generalmente se pueden cumplir para que se cumplan todos los plazos.

Este mental el modelo es deliberada y muy útilmente lo suficientemente general como para abarcar tanto duro como blando en tiempo real soft suave es acomodado por la frase "en la medida en que". Por ejemplo, supongamos que el evento task completions tiene un valor subóptimo pero aceptable si

• no más del 10% de las tareas no cumplen sus plazos
• o ninguna tarea es más de 20% tarde
• o la tardanza media de todas las tareas no es superior al 15%
• o la tardanza máxima entre todas las tareas es menor que 10%

Todos estos son ejemplos comunes de casos suaves en tiempo real en muchas aplicaciones.

Considere la aplicación de una sola tarea de recoger a su hijo después de la escuela. Eso probablemente no tiene una fecha límite real, en su lugar, hay algo de valor para usted y su hijo en función de cuándo se lleva a cabo ese evento. Demasiado temprano desperdicia recursos (como su tiempo) y demasiado tarde tiene algún valor negativo porque su hijo podría quedarse solo y potencialmente en peligro (o al menos inconvenientes).

A diferencia del caso especial estático hard real-time, soft real-time hace solo las suposiciones mínimas necesarias específicas de la aplicación sobre las tareas y el sistema, y se esperan incertidumbres. Para recoger a su hijo, tiene que conducir hasta la escuela, y el tiempo para hacerlo es dinámico dependiendo del clima, las condiciones del tráfico, etc. Es posible que se sienta tentado a sobre-aprovisionar su sistema (es decir, permitir lo que usted espera es el peor tiempo de conducción caso), pero de nuevo esto es perder recursos (su tiempo, y ocupar el vehículo de la familia, posiblemente negando el uso por otros miembros de la familia).

Ese ejemplo puede no parecer costoso en términos de recursos desperdiciados, pero considere otros ejemplos. Todos los sistemas de combate militar son suaves en tiempo real. Por ejemplo, considere realizar un ataque aéreo a un vehículo terrestre hostil utilizando un misil guiado con actualizaciones a él como las maniobras del objetivo. La máxima satisfacción para completar las tareas de actualización del curso se logra mediante una ataque destructivo en el objetivo. Pero un intento de exceso de recursos para asegurarse de este resultado suele ser demasiado caro e incluso puede ser imposible. En este caso, usted puede estar menos pero lo suficientemente satisfecho si el misil golpea lo suficientemente cerca del objetivo para desactivarlo.

Obviamente los escenarios de combate tienen muchas incertidumbres dinámicas posibles que deben ser acomodadas por la gestión de recursos. Los sistemas suaves en tiempo real también son muy comunes en muchos sistemas civiles, como la automatización industrial, aunque obviamente los militares son los más peligrosos y urgentes para lograr un valor aceptablemente satisfactorio en.

La piedra angular de los sistemas en tiempo real es la "previsibilidad"."El caso difícil en tiempo real solo está interesado en un caso especial de previsibilidad i es decir, que todas las tareas cumplan con sus plazos y que el máximo valor posible se logre con ese evento. Ese caso especial se llama " determinista."

Hay un espectro de previsibilidad. Determinista (determinismo) es un punto final (máxima predictibilidad) en el espectro de predictibilidad; el otro punto final es la predictibilidad mínima (máximo no determinismo). La métrica y los puntos finales del espectro deben interpretarse en términos de un modelo de previsibilidad elegido; todo entre esos dos puntos finales es grados de imprevisibilidad (= grados de no determinismo).

La mayoría de los sistemas en tiempo real (a saber, los blandos) tienen previsibilidad no determinista, para ejemplo, de los tiempos de finalización de las tareas y por lo tanto los valores obtenidos de esos eventos.

En general (en teoría), la previsibilidad, y por lo tanto el valor aceptablemente satisfactorio, se puede hacer tan cerca del punto final determinista como sea necesario but pero a un precio que puede ser físicamente imposible o excesivamente caro (como en combate o tal vez incluso en recoger a su hijo de la escuela).

El tiempo real suave requiere una elección específica de la aplicación de un modelo de probabilidad (no el común modelo frecuentista) y por lo tanto modelo de previsibilidad para el razonamiento sobre latencias de eventos y valores resultantes.

Volviendo a la lista anterior de eventos que proporcionan un valor aceptable, ahora podemos agregar casos no deterministas, como

• la probabilidad de que ninguna tarea pierda su fecha límite en más del 5% es mayor que 0.87. (Nótese el número de criterios de programación expresados allí.)

En una aplicación de defensa antimisiles, dado el hecho de que en combate la ofensiva siempre tiene la ventaja sobre la defensa, cuál de estos dos escenarios de computación en tiempo real preferirías:

• Debido a que la destrucción perfecta de todos los misiles hostiles es muy improbable o imposible, asigne sus recursos defensivos para maximizar la probabilidad de que muchos de los misiles hostiles más amenazantes (por ejemplo, en función de sus objetivos) sean interceptados con éxito (la interceptación cercana cuenta porque puede mover el misil hostil fuera de curso);

• Se quejan de que este no es un problema de computación en tiempo real porque es dinámico en lugar de estático, y los conceptos y técnicas tradicionales en tiempo real no se aplican, y suena más difícil que estático duro en tiempo real, por lo que no está interesado en él.

A pesar de los diversos malentendidos sobre el tiempo real suave en la comunidad informática en tiempo real, el tiempo real suave es muy general y poderoso, aunque potencialmente complejo en comparación con el tiempo duro en tiempo real. Los sistemas suaves en tiempo real, como se resume aquí, tienen una larga historia exitosa de uso fuera de la comunidad de computación en tiempo real .

Para responder directamente a la pregunta de OP:

Un sistema duro en tiempo real puede proporcionar garantías deterministas-por lo general, que todas las tareas cumplirán con sus plazos, el tiempo de respuesta de interrupción o llamada al sistema siempre será menor que x, etc.- SI Y SOLO SI se hacen suposiciones muy fuertes y son correctas que todo lo que importa es estático y conocidos a ' priori (en general, tales garantías para sistemas duros en tiempo real son un problema de investigación abierto, excepto para casos bastante simples)

Un sistema suave en tiempo real no ofrece garantías deterministas, sino que está destinado a proporcionar la mejor oportunidad probabilística posible, especificada analíticamente y lograda, y la previsibilidad de la oportunidad que son factibles en las circunstancias dinámicas actuales, de acuerdo con criterios específicos de la aplicación.

Obviamente duro en tiempo real es un caso especial simple de tiempo real suave. Obviamente, las garantías analíticas no deterministas de soft real-time pueden ser muy complejas de proporcionar, pero son obligatorias en los casos más comunes en tiempo real (incluidos los más peligrosos y críticos para la seguridad, como el combate) ya que la mayoría de los casos en tiempo real son dinámicos y no estáticos.

"Tiempo real firme" es un caso especial mal definido de "tiempo real suave"."No hay necesidad de este término si el término "tiempo real suave" se entiende y utiliza correctamente.

I tener una discusión más detallada mucho más precisa de tiempo real, tiempo real duro, tiempo real suave, previsibilidad, determinismo y temas relacionados en mi sitio web real-time.org.

Tiempo real-Perteneciente a un sistema o modo de operación en el que la computación se realiza durante el tiempo real que ocurre un proceso externo, con el fin de que los resultados de la computación se pueden utilizar para controlar, monitorear o responder al proceso externo de manera oportuna. [Norma IEEE 610.12.1990]

Sé que esta definición es antigua, muy antigua. No puedo, sin embargo, encontrar una definición más reciente por el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos).

Tal vez la definición es errónea.

Desde mi experiencia, separaría los dos como dependientes de hardware y software.

Si tiene 200 ms para dar servicio a una interrupción impulsada por hardware, eso es lo que tiene. Metes 300ms de código ahí y el sistema no está roto, no ha sido desarrollado. Te cambiarán antes de que termines. Su código no funciona o no es adecuado para su propósito. Muchos sistemas tienen períodos de procesamiento muy definidos. Vídeo, telecomunicaciones, etc.

Si estás escribiendo una aplicación que es en tiempo real, esto podría considerarse suave. Si se queda sin tiempo, podría esperar menos carga la próxima vez, podría ajustar el sistema operativo, agregar algo de memoria o incluso actualizar el hardware. Tienes opciones.

Mirarlo desde una perspectiva de UX no es útil. Un Skoda podría no estar roto si falla, pero un BMW seguro que lo estará.

La definición se ha ampliado a lo largo de los años en detrimento del término. Lo que ahora se llama tiempo real "duro" es lo que solía llamarse simplemente tiempo real. Por lo tanto, los sistemas en los que las ventanas de tiempo faltantes (en lugar de los plazos de tiempo de un solo lado) resultarían en datos incorrectos o un comportamiento incorrecto deben considerarse en tiempo real. Los sistemas sin esa característica se considerarían no en tiempo real.

Eso no quiere decir que el tiempo no sea de interés en sistemas en tiempo no real, solo significa que los requisitos de tiempo en tales sistemas no resultan en resultados fundamentalmente incorrectos.

Considere una tarea que ingresa datos desde el puerto serie. Cuando llegan nuevos datos, el puerto serie activa un evento. Cuando el software presta servicios a ese evento, lee y procesa los nuevos datos. El puerto serie tiene un hardware para almacenar los datos entrantes (2 en el MSP432, 16 en el TM4C123) de modo que si el búfer está lleno y llegan más datos, se pierden los nuevos datos. ¿Este sistema es duro, firme o suave en tiempo real?

Es difícil en tiempo real porque si la respuesta es tardía, los datos pueden ser perder.

Considere un audífono que ingresa sonidos desde un micrófono, manipula los datos de sonido y luego envía los datos a un altavoz. El sistema suele tener un jitter pequeño y limitado, pero ocasionalmente otras tareas en el audífono hacen que algunos datos lleguen tarde, causando un pulso de ruido en el altavoz. ¿Este sistema es duro, firme o suave en tiempo real?

Es tiempo real firme porque causa un error que se puede percibir pero el efecto es inofensivo y no lo hace alterar significativamente la calidad de la experiencia.

Considere una tarea que envía datos a una impresora. Cuando la impresora está inactiva, la impresora activa un evento. Cuando el software da servicio a ese evento, envía más datos a la impresora. ¿Este sistema es duro, firme o suave en tiempo real?

Es tiempo real suave porque cuanto más rápido responde mejor, pero el valor del sistema (ancho de banda es la cantidad de datos impresos por segundo) disminuye con latencia.

UTAustinX: UT.RTBN.12.01 x Redes Bluetooth en tiempo real