Para definir "tiempo real suave", es más fácil compararlo con "tiempo real duro".
Hablando casualmente, la mayoría de las personas tiene implícitamente 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 período de tiempo en el que la información o el evento tiene un valor aceptablemente satisfactorio para ellos.
Existen numerosas definiciones diferentes de "tiempo real difícil", pero en ese modelo mental, el término "si" representa el tiempo real difícil. Específicamente, suponiendo que las acciones en tiempo real (como las tareas) tengan plazos de finalización, el valor aceptablemente satisfactorio del evento de que todas las tareas se completen se limita al caso especial de que todas las tareas cumplan con sus plazos.
Los sistemas duros en tiempo real hacen suposiciones muy fuertes de que todo lo relacionado con la aplicación, el sistema y el entorno es estático y se conoce a priori, por ejemplo, qué tareas, que son periódicas, sus tiempos de llegada, sus períodos, sus plazos, que ganaron No tiene conflictos de recursos y, en general, la evolución temporal del sistema. En un sistema de control de vuelo de una aeronave o en un sistema de frenos automotrices 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 el tiempo real duro como el blando: el blando se adapta a la frase "en la medida en que". Por ejemplo, suponga que el evento de finalización de tareas tiene un valor subóptimo pero aceptable si
- no más del 10% de las tareas pierden sus plazos
- o ninguna tarea tiene más del 20% de retraso
- o la tardanza promedio de todas las tareas no es más del 15%
- o la tardanza máxima entre todas las tareas es inferior al 10%
Todos estos son ejemplos comunes de casos blandos 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 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 un valor negativo porque su hijo podría quedarse solo y potencialmente en peligro (o al menos incomodado).
A diferencia del caso especial de tiempo real estático, el tiempo real suave solo hace 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 a la escuela, y el tiempo para hacerlo es dinámico, dependiendo del clima, las condiciones del tráfico, etc. Es posible que tenga la tentación de sobreaprovisionar su sistema (es decir, permita que lo que espera sea el en el peor de los casos, el tiempo de conducción), pero nuevamente esto está desperdiciando recursos (su tiempo y ocupando el vehículo familiar, 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 de aeronave en un vehículo terrestre hostil usando 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 en el objetivo. Pero un intento de sobreaprovisionar recursos para asegurarse de este resultado suele ser demasiado costoso e incluso puede ser imposible. En este caso, puede estar menos satisfecho pero suficiente si el misil golpea lo suficientemente cerca del objetivo como para desactivarlo.
Obviamente, los escenarios de combate tienen una gran cantidad de posibles incertidumbres dinámicas que la gestió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 satisfactorio.
La piedra angular de los sistemas en tiempo real es la "previsibilidad". El caso difícil en tiempo real está interesado en un solo caso especial de previsibilidad, es decir, que todas las tareas cumplan con sus plazos y que ese evento logre el máximo valor posible. Ese caso especial se llama "determinista".
Hay un espectro de previsibilidad; 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 de esos eventos. En general, la previsibilidad y, por lo tanto, el valor, se pueden hacer tan cerca del punto final determinista como sea necesario, pero a un precio que puede ser físicamente imposible o excesivamente costoso (como en el combate o tal vez incluso al 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 modelo frecuente de frecuentista) y, por lo tanto, un modelo de previsibilidad para razonar sobre las latencias de eventos y los 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.
En una aplicación de defensa antimisiles, dado 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ía:
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 tantos de los misiles hostiles más amenazantes (por ejemplo, basados en sus objetivos) sean interceptados con éxito (la intercepción cercana cuenta porque puede mover el misil hostil fuera de curso);
se quejan de que este no es un problema informático 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, por lo que no está interesado en realizar actividades de I + D en tiempo real flexible.
A pesar de los diversos malentendidos sobre el tiempo real flexible en la comunidad informática en tiempo real (pero no en otros campos no informáticos), el tiempo real flexible es muy general y poderoso, y potencialmente muy complejo en comparación con el tiempo real difícil.
Para responder directamente a la pregunta de OP:
un sistema duro en tiempo real puede proporcionar garantías deterministas: lo más común es que todas las tareas cumplan con sus plazos, la interrupción o el tiempo de respuesta de la llamada del sistema siempre será menor que x, etc. todo lo que importa es estático y se conoce a priori (en general, tales garantías para sistemas de tiempo real difíciles son un problema de investigación abierto, excepto en casos bastante simples)
un sistema blando en tiempo real no ofrece garantías deterministas, está destinado a proporcionar la mejor oportunidad probabilística analíticamente especificada posible y la previsibilidad de la oportunidad que sea factible en las circunstancias dinámicas actuales, de acuerdo con 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 deterministas analíticas en tiempo real pueden ser muy complejas, pero son obligatorias en los casos en tiempo real más comunes (incluidos los más peligrosos para la seguridad, como el combate), ya que la mayoría de los casos son dinámicos y no estáticos.
Tengo una discusión detallada mucho más precisa de tiempo real, tiempo real duro, tiempo real blando, previsibilidad, determinismo y temas relacionados en mi sitio web real-time.org .