real-time - programa - sistemas en tiempo real pdf

¿Diferencias entre tiempo real en tiempo real, tiempo real suave y tiempo real en firme? (11)

He leído las definiciones de las diferentes nociones de tiempo real , y los ejemplos proporcionados para los sistemas de tiempo real duros y blandos tienen sentido para mí. Pero no hay una explicación real o ejemplo de un sistema firme en tiempo real. De acuerdo con el enlace de arriba:

Firma: los incumplimientos de fecha límite 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.

¿Existe una clara distinción entre el tiempo real de la empresa frente al tiempo real en tiempo real o blando, y hay un buen ejemplo que ilustra esa distinción?

En los comentarios, Charles me pidió que envíe wikis de etiquetas para las nuevas etiquetas. El ejemplo de un "sistema firme en tiempo real" que proporcioné para la etiqueta firm-real-time fue un sistema de suministro de leche. Si el sistema entrega leche después de su tiempo de caducidad, entonces la leche se considera "no útil". Uno puede tolerar comer cereal sin leche, pero la calidad de la experiencia se degrada.

Esta es solo la idea que formé en mi cabeza cuando inicialmente leí la definición. Estoy buscando un ejemplo mucho mejor, y tal vez una mejor definición de la empresa en tiempo real que mejorará mi noción de ello.

Duro en tiempo real

La definición rígida en tiempo real considera que cualquier fecha límite incumplida es una falla del sistema. Esta programación se usa ampliamente en sistemas de misión crítica donde el incumplimiento de las restricciones de tiempo resulta en una pérdida de vida o propiedad.

Ejemplos:

El vuelo 447 de Air France se estrelló en el océano luego de que un mal funcionamiento del sensor causara una serie de errores del sistema. Los pilotos pararon el avión mientras respondían a lecturas de instrumentos obsoletas. Los 12 tripulantes y 216 pasajeros fueron asesinados.
La nave espacial Mars Pathfinder casi se perdió cuando una inversión de prioridad provocó que el sistema se reiniciara. Una tarea de mayor prioridad no se completó a tiempo debido a que estaba 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 una parte específica del papel. 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 fechas de entrega que no se cumplen con frecuencia. En estas aplicaciones, el sistema puede sobrevivir a fallas de tareas siempre que estén adecuadamente espaciadas, sin embargo, el valor de la finalización de la tarea se reduce a cero o se vuelve imposible.

Ejemplos:

Los sistemas de fabricación con líneas de ensamblaje de robots donde falta una fecha límite resultan en el ensamblaje incorrecto de una pieza. Mientras las piezas arruinadas sean lo suficientemente infrecuentes como para ser atrapadas por el control de calidad y no sean demasiado costosas, entonces la producción continúa.
Un decodificador de cable digital decodifica marcas de tiempo para cuando los marcos deben aparecer en la pantalla. Dado que los marcos son sensibles a las órdenes de tiempo, una fecha límite no cumplida causa inestabilidad, lo que disminuye la calidad del servicio. Si el cuadro omitido más tarde está disponible, solo causará más inestabilidad para mostrarlo, por lo que es inútil. El espectador todavía puede disfrutar del programa si la trepidación no ocurre con demasiada frecuencia.

Tiempo real suave

La definición suave en tiempo real permite fechas de entrega incumplidas con frecuencia, y siempre que las tareas se ejecuten oportunamente, sus resultados siguen 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. Aunque la lectura de un sensor puede ser temprana o tardía en comparación con las demás, puede ser relevante siempre que esté lo suficientemente cerca.
Una consola de videojuegos ejecuta software para un motor de juego. Hay muchos recursos que deben compartirse entre sus tareas. Al mismo tiempo, las tareas deben completarse de acuerdo con el cronograma para que el juego se reproduzca correctamente. Siempre que las tareas se realicen de forma relativamente relativamente puntual, el juego será agradable y, si no, solo se retrasará un poco.

^{Siewert: Sistemas integrados en tiempo real y componentes.} ^{Liu y Layland: Algoritmos de programación para multiprogramación en un entorno de tiempo real difícil.} ^{Marchand & Silly-Chetto: programación dinámica de tareas aperiódicas blandas y tareas periódicas con saltos.}

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

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

Considere un audífono que ingresa sonidos de un micrófono, manipula los datos de sonido y luego los envía a un altavoz. El sistema generalmente tiene fluctuaciones pequeñas y limitadas, pero ocasionalmente otras tareas en el audífono causan que algunos datos lleguen tarde, causando un ruido en el altavoz. ¿Es este sistema duro, firme o suave en tiempo real?

Es firme en tiempo real porque causa un error que puede percibirse pero el efecto es inofensivo y no altera significativamente la calidad de la experiencia.

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

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

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

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 difícil 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 el plazo, posiblemente más de una vez (es decir, para varias solicitudes), no se considera que el sistema haya fallado. Además, las respuestas para las solicitudes (respuestas a una consulta, resultado de una tarea, etc.) no tienen valor una vez que ha vencido el plazo para esa solicitud en particular ( 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 pronostica una tormenta antes de la llegada, entonces el sistema ha hecho su trabajo, la predicción después de que el evento ya haya ocurrido o cuando suceda no tiene ningún valor).

3> Para un sistema Soft en tiempo real , incluso si el sistema no cumple con la fecha límite, posiblemente más de una vez (es decir, para varias solicitudes), no se considera que el sistema haya fallado. Pero, en este caso, los resultados de las solicitudes no tienen valor inútil 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. Ej .: transmisión de audio y video.

Here hay un enlace a un recurso que fue muy útil.

Difícil en tiempo real significa que debes cumplir absolutamente con cada fecha límite. Muy pocos sistemas tienen este requisito. Algunos ejemplos son los sistemas nucleares, algunas aplicaciones médicas como marcapasos, una gran cantidad de aplicaciones de defensa, aviónica, etc.

Los sistemas firmes / blandos en tiempo real pueden pasar por alto algunos plazos, pero al final el rendimiento se degradará si se pierden demasiados. Un buen ejemplo es el sistema de sonido en su computadora. Si pierde algunas partes, no es gran cosa, pero echa de menos demasiadas y finalmente va a degradar el sistema. Similares serían los sensores sísmicos. Si pierde algunos puntos de datos, no es gran cosa, pero tiene que atrapar a la mayoría de ellos para dar sentido a los datos. Más importante aún, nadie va a morir si no funcionan correctamente.

La línea es borrosa, porque incluso un marcapasos puede estar apagado en una pequeña cantidad sin matar al paciente, pero esa es la esencia general.

Es como la diferencia entre calor y calor. No hay una división real, pero lo sabes cuando lo sientes.

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

Firme y suave simplemente no se declara automáticamente roto en el incumplimiento de una sola fecha límite.

Para un ejemplo justo de tiempo real, desde la página que vinculó:

Los primeros sistemas de videojuegos como los gráficos vectoriales Atari 2600 y Cinematronics tenían requisitos duros en tiempo real debido a la naturaleza de los gráficos y el hardware de sincronización.

Si algo en el ciclo de generación de video se perdiera solo una fecha límite, toda la pantalla fallaría, lo que sería intolerable, incluso si fuera poco frecuente. Eso sería un sistema roto y lo llevaría de vuelta a la tienda para obtener un reembolso. Entonces 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 las condiciones de funcionamiento esperadas, teniendo en cuenta que en las aplicaciones de seguridad crítica las personas deben planificar 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 te ve romper las reglas (o si lo hicieron pero mueren antes de contárselo a nadie), y nadie puede probar que rompiste las reglas después del hecho, entonces es como si nunca hubieras roto las reglas.

La definición se ha expandido a lo largo de los años en detrimento del término. Lo que ahora se llama "Duro" en tiempo real es lo que solía llamarse simplemente en tiempo real. De modo que los sistemas en los que faltan ventanas de tiempo (en lugar de fechas límite de tiempo de un solo lado) darían como resultado datos incorrectos o un comportamiento incorrecto deberían 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 los sistemas que no son en tiempo real, simplemente significa que los requisitos de tiempo en tales sistemas no resultan en resultados fundamentalmente incorrectos.

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

¿Sigue siendo útil o no una respuesta tardía del sistema (después de la fecha límite)?

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

Difícil : No, y las respuestas demoradas se consideran una falla del sistema

Este es el caso cuando perder la línea muerta hará que el sistema sea inutilizable. Por ejemplo, el sistema que controla el sistema Airbag del automóvil debería detectar el choque e inflar rápidamente la bolsa. Todo el proceso lleva más o menos un veinticinco de segundo. Por lo tanto, si el sistema, por ejemplo, reacciona con un segundo de retraso, las consecuencias podrían ser mortales y no será beneficioso que la bolsa se inflara una vez que el automóvil ya se ha estrellado.

Firma : No, pero las respuestas demoradas no son necesarias una falla del sistema

Este es el caso cuando la fecha límite es tolerable, pero afectará la calidad del servicio. Como un simple ejemplo, considere un sistema de encriptación de video. Normalmente, la contraseña de cifrado se genera en el servidor (cabecera de video) y se envía al decodificador del cliente. Este proceso debe sincronizarse, por lo que normalmente el decodificador recibe la contraseña antes de comenzar a recibir los cuadros de video encriptados. En este caso, una demora puede ocasionar fallas de video ya que el decodificador no puede decodificar los marcos 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 el incumplimiento de la fecha límite. Recibir la contraseña con retraso en este caso no es útil ya que los cuadros encriptados con el mismo ya han causado los fallos.

Suave : Sí, pero el servicio del sistema está degradado

A partir de la descripción de la wikipedia, 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 llegar a la fecha límite. Un ejemplo simple 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 algunas demoras al leer los sensores de temperatura, será un poco lento para reaccionar ante bruscos cambios de temperatura. Sin embargo, al final terminará reaccionando al cambio y ajustando en consecuencia la temperatura para mantenerlo constante, por ejemplo. Entonces, en este caso, la reacción retrasada es útil, pero degrada la calidad del servicio del sistema.

Para definir "tiempo real suave", es más fácil compararlo con "tiempo real difícil". 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 tiene implícitamente un modelo mental informal que considera que la información o un evento son "en tiempo real"

• si, o en la medida en que, se les manifieste con un retraso (latencia) que pueda estar relacionado con su moneda percibida

• es decir, en un marco de tiempo que la información o evento tiene un valor aceptable aceptable para ellos.

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

Los sistemas duros en tiempo real hacen suposiciones muy sólidas 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 ganaron No tienen conflictos de recursos, y en general la evolución del tiempo del sistema. En un sistema de control de vuelo de la aeronave o en un sistema de frenado automotriz y en muchos otros casos, esas suposiciones generalmente pueden cumplirse para que se cumplan todos los plazos.

Este modelo mental es deliberadamente y muy útil lo suficientemente general como para abarcar tanto en tiempo real como en tiempo real. Soft es acomodado por la frase "en la medida de que". Por ejemplo, suponga que el evento de finalización de tareas tiene un valor inferior pero óptimo si

no más del 10% de las tareas pierden sus fechas límite
o ninguna tarea es más del 20% tardía
o la tardanza promedio de todas las tareas no es más del 15%
o la tardanza máxima entre todas las tareas es menos del 10%

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

Considere la aplicación de tarea única de recoger a su hijo después de la escuela. Probablemente no tenga una fecha límite real, en cambio hay algo de valor para usted y su hijo en función de cuándo se produce ese evento. Demasiado temprano desperdicia recursos (como su tiempo) y demasiado tarde tiene algún valor negativo porque su hijo puede quedar solo y potencialmente en peligro (o al menos incomodado).

A diferencia del caso especial estático en tiempo real, el tiempo real suave 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, debe conducir hasta la escuela, y el tiempo para hacerlo es dinámico en función del clima, las condiciones del tráfico, etc. Podría verse tentado a aprovisionar en exceso su sistema (es decir, permitir lo que espera que sea el en el peor de los casos, tiempo de conducción), pero una vez más, esto está desperdiciando recursos (su tiempo y ocupando el vehículo familiar, posiblemente negando el uso de 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 blandos en tiempo real. Por ejemplo, considere realizar un ataque aéreo en un vehículo terrestre hostil utilizando un misil guiado con actualizaciones a medida que el objetivo maniobra. La máxima satisfacción para completar las tareas de actualización del curso se logra mediante un ataque destructivo directo sobre el objetivo. Pero un intento de aprovisionar recursos en exceso para asegurar este resultado suele ser demasiado costoso e incluso imposible. En este caso, puede estar menos pero 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 la administración de recursos debe tener en cuenta. Los sistemas blandos 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 aceptable.

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

Hay un espectro de previsibilidad. Determinístico (determinismo) es un punto final (máxima predictibilidad) en el espectro de previsibilidad; el otro punto final es la mínima predictibilidad (máximo no determinismo). Los puntos finales y métricos del espectro deben interpretarse en términos de un modelo de predictibilidad elegido; todo lo que se encuentra entre esos dos puntos finales es grados de imprevisibilidad (= grados de no determinismo).

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

En general (en teoría), la previsibilidad y, por lo tanto, un valor aceptablemente satisfactorio, pueden realizarse tan cerca del punto final determinista como sea necesario, pero a un precio que puede ser físicamente imposible o excesivamente costoso (como en combate o quizás incluso en recogiendo 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 modelo frecuentista común) y, por lo tanto, un modelo de predictibilidad para el razonamiento sobre las latencias de eventos y los valores resultantes.

Refiriéndonos 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. (Tenga en cuenta la cantidad de criterios de programación expresados allí).

En una aplicación de defensa de misiles, dado el hecho de que en el combate la ofensiva siempre tiene la ventaja sobre la defensa, ¿cuál de estos dos escenarios informáticos en tiempo real preferiría?

porque la destrucción perfecta de todos los misiles hostiles es muy poco probable o imposible, asigne sus recursos defensivos para maximizar la probabilidad de que muchos de los misiles hostiles más amenazantes (por ejemplo, basados en sus objetivos) sean interceptados con éxito (los intersticios de intercepción cercanos porque puede mover el misil hostil fuera del curso);
se quejan de que no se trata de 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 el tiempo fijo estático 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 en tiempo real es muy general y potente, aunque potencialmente complejo en comparación con el tiempo real. Los sistemas blandos en tiempo real que se resumen aquí tienen una larga y exitosa historia de uso fuera de la comunidad informática en tiempo real .

Para responder directamente la pregunta OP:

Un sistema en tiempo real puede proporcionar garantías determinísticas: lo más común es que todas las tareas cumplan con sus plazos, la interrupción o el tiempo de respuesta de llamada del sistema siempre será menor que x, etc. SI Y SÓLO si se hacen suposiciones muy fuertes y son correctas. todo lo que importa es estático y conocido a priori (en general, tales garantías para sistemas duros en tiempo real son un problema abierto de investigación, excepto en casos bastante simples)

Un sistema blando en tiempo real no garantiza de manera determinista, sino que pretende proporcionar la mejor puntualidad probabilística analíticamente posible y lograda y la previsibilidad de la puntualidad que son factibles en las circunstancias dinámicas actuales, de acuerdo con los criterios específicos de la aplicación.

Obviamente, el tiempo real difícil es un caso especial simple de tiempo real suave. Obviamente, las garantías analíticas no determinantes en tiempo real pueden ser muy complejas de proporcionar, pero son obligatorias en los casos más comunes en tiempo real (incluidos los más peligrosos como el combate) ya que la mayoría de los casos en tiempo real son dinámicos, no estático.

"Firme en tiempo real" 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 usa correctamente.

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

Tal vez la definición es la culpa.

Según mi experiencia, separaría los dos como dependientes de hardware y software.

Si tienes 200 ms para reparar una interrupción por hardware, eso es lo que tienes. Usted pega 300ms de código allí y el sistema no está roto, no ha sido desarrollado. Te desconectarán antes de que hayas terminado. Su código no funciona o no es adecuado para su propósito. Muchos sistemas tienen períodos de procesamiento definidos con rigor. Video, telecomunicaciones, etc.

Si está 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 sintonizar el sistema operativo, agregar algo de memoria o incluso actualizar el hardware. Tienes opciones.

Mirarlo desde una perspectiva UX no es útil. Un Skoda podría no estar roto si falla, pero un BMW seguro como el infierno.

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, tarda algo de tiempo en 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 no válida, solo diremos que el rendimiento del sistema no fue el correcto (¡el sistema dio un bajo rendimiento!).

En sistemas duros en tiempo real , si el resultado se obtiene después de la fecha límite, se considera que el sistema ha fallado por completo.

Ejemplo: en el caso de un robot que realiza algún trabajo como el trazado de líneas, etc. Si surge un obstáculo en su camino y el robot no procesa esta información dentro de un plazo programado (¡casi instantáneo!), Se dice que el robot falló en su tarea (¡el sistema del robot también puede ser completamente destruido!).

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

Ejemplo: comunicación satelital para monitoreo de posición enemigo o alguna otra tarea. Si la estación de la computadora de tierra a la cual los satélites envían los marcos periódicamente está sobrecargada, y el cuadro actual (paquete) no se procesa a tiempo y aparece el siguiente cuadro, el paquete actual (el que omitió el plazo) no importa si el procesamiento se realizó (o medio hecho o casi terminado) se descarta / descarta. Pero la computadora de tierra no se considera que ha fallado por completo.

tiempo real - Perteneciente a un sistema o modo de operación en el cual el cálculo se realiza durante el tiempo real que ocurre un proceso externo, para que los resultados del cálculo se puedan usar para controlar, monitorear o responder al proceso externo de manera oportuna manera. [Estándar IEEE 610.12.1990]

Sé que esta definición es vieja, muy antigua. No obstante, no puedo encontrar una definición más reciente del IEEE (Instituto de Ingenieros Eléctricos y Electrónicos).