Différences entre temps réel dur, temps réel souple et temps réel ferme?

J’ai lu les définitions des différentes notions de temps réel , et les exemples fournis pour les systèmes temps réel durs et souples ont un sens pour moi. Mais, il n’existe pas de véritable explication ou exemple de système temps réel ferme. Selon le lien ci-dessus:

Entreprise: les échéances peu fréquentes sont tolérables, mais peuvent dégrader la qualité de service du système. L’utilité d’un résultat est zéro après son échéance.

Existe-t-il une distinction claire entre le temps réel ferme et le temps réel dur ou mou, et existe-t-il un bon exemple qui illustre cette distinction?

Dans les commentaires, Charles a demandé que je soumette des wikis tag pour les nouvelles balises. L’exemple d’un «système temps réel ferme» que j’ai fourni pour l’étiquette « temps réel ferme» était un système de dissortingbution de lait. Si le système livre du lait après son délai d’expiration, le lait est considéré comme “non utile”. On peut tolérer de manger des céréales sans lait, mais la qualité de l’expérience est dégradée.

C’est juste l’idée que j’ai formée dans ma tête lorsque j’ai lu la définition au départ. Je cherche un meilleur exemple, et peut-être une meilleure définition de l’ entreprise en temps réel qui améliorera ma notion.

Le temps réel difficile signifie que vous devez absolument atteindre chaque échéance. Très peu de systèmes ont cette exigence. Certains exemples sont les systèmes nucléaires, certaines applications médicales telles que les stimulateurs cardiaques, un grand nombre d’applications de défense, l’avionique, etc.

Les systèmes temps réel fermes / souples peuvent manquer certaines échéances, mais les performances finissent par se dégrader si un nombre trop important de données est manquant. Un bon exemple est le système audio de votre ordinateur. Si vous manquez quelques bits, pas de problème, mais en manquez trop et vous allez éventuellement dégrader le système. Semblable serait des capteurs sismiques. Si vous manquez quelques points de données, ce n’est pas grave, mais vous devez attraper la plupart d’entre eux pour comprendre les données. Plus important encore, personne ne va mourir si elle ne fonctionne pas correctement.

La ligne est floue, car même un stimulateur cardiaque peut être éteint sans trop tuer le patient, mais c’est l’essentiel.

C’est un peu comme la différence entre chaud et chaud. Il n’y a pas de véritable fossé, mais vous le savez quand vous le ressentez.

Dur temps réel

La définition dure en temps réel considère que toute échéance manquée est une défaillance du système. Cette planification est largement utilisée dans les systèmes critiques où le non-respect des contraintes de synchronisation entraîne une perte de vie ou de propriété.

Exemples:

  • Le vol 447 d’Air France s’est écrasé dans l’océan après un dysfonctionnement du capteur ayant provoqué une série d’erreurs du système. Les pilotes ont calé l’avion tout en répondant aux lectures d’instruments obsolètes. Les 12 membres d’équipage et 216 passagers ont été tués.

  • Le vaisseau spatial Mars Pathfinder était presque perdu lorsqu’un système d’inversion prioritaire provoquait le redémarrage du système. Une tâche de priorité plus élevée n’a pas été achevée à temps en raison d’une tâche moins prioritaire. Le problème a été corrigé et le vaisseau spatial a atterri avec succès.

  • Une imprimante à jet d’encre a une tête d’impression avec un logiciel de contrôle pour déposer la quantité correcte d’encre sur une partie spécifique du papier. Si une date limite est manquée, le travail d’impression est détruit.


Temps réel ferme

La définition en temps réel ferme permet de respecter les délais rarement respectés. Dans ces applications, le système peut survivre à des défaillances de tâches tant qu’elles sont correctement espacées, mais la valeur de l’achèvement de la tâche tombe à zéro ou devient impossible.

Exemples:

  • Les systèmes de fabrication avec des lignes d’assemblage de robots où le dépassement d’une échéance entraîne un assemblage incorrect d’une pièce. Tant que les pièces en ruine sont assez rares pour être captées par le contrôle de la qualité et pas trop coûteuses, la production continue.

  • Un décodeur de câble numérique décode les horodatages lorsque des images doivent apparaître à l’écran. Les trames étant sensibles à l’ordre temporel, une échéance manquée provoque une gigue, diminuant la qualité de service. Si la trame manquante devient disponible par la suite, elle ne fera qu’exposer davantage de gigue, elle sera donc inutile. Le spectateur peut toujours profiter du programme si la gigue ne se produit pas trop souvent.


Temps réel doux

La définition en temps réel souple tient compte des délais fréquemment manqués et, tant que les tâches sont exécutées à temps, leurs résultats continuent d’avoir de la valeur. Les tâches terminées peuvent avoir une valeur croissante jusqu’à la date limite et la valeur décroissante.

Exemples:

  • Les stations météorologiques disposent de nombreux capteurs pour la lecture de la température, de l’humidité, de la vitesse du vent, etc. Les mesures doivent être sockets et transmises à intervalles réguliers, mais les capteurs ne sont pas synchronisés. Même si une lecture de capteur peut être précoce ou tardive par rapport aux autres, elle peut toujours être pertinente tant qu’elle est suffisamment proche.

  • Une console de jeux vidéo exécute un logiciel pour un moteur de jeu. De nombreuses ressources doivent être partagées entre ses tâches. Dans le même temps, les tâches doivent être complétées conformément au calendrier de jeu du jeu. Tant que les tâches sont complètement relatives dans le temps, le jeu sera agréable et, dans le cas contraire, il se peut que le jeu soit un peu retardé.


Siewert: Systèmes et composants intégrés en temps réel.
Liu & Layland: Algorithmes de planification pour la multiprogrammation dans un environnement temps réel difficile.
Marchand & Silly-Chetto: Programmation dynamic de tâches apériodiques et de tâches périodiques avec sauts.

Après avoir lu la page Wikipedia et d’autres pages sur l’informatique en temps réel. J’ai fait les déductions suivantes:

1> Pour un système temps réel difficile , si le système ne parvient pas à respecter les délais, même une fois que le système est considéré comme ayant échoué.

2> Pour un système en temps réel ferme , même si le système ne parvient pas à respecter l’échéance, peut-être plus d’une fois (par exemple pour plusieurs demandes), le système n’est pas considéré comme ayant échoué. De même, les réponses aux demandes (réponses à une requête, résultat d’une tâche, etc.) ne valent rien une fois la date limite pour cette demande particulière passée ( l’utilité d’un résultat est zéro après son échéance ). Un exemple hypothétique peut être un système de prévision des tempêtes (si une tempête est prédite avant l’arrivée, alors le système a fait son travail, la prédiction après que l’événement soit déjà arrivé ou quand il se produit est sans valeur).

3> Pour un système temps réel souple , même si le système ne parvient pas à respecter l’échéance, peut-être plus d’une fois (par exemple pour plusieurs demandes), le système n’est pas considéré comme ayant échoué. Mais, dans ce cas, les résultats des demandes ne sont pas sans valeur pour un résultat après son échéance, il n’est pas nul , mais il se dégrade au fil du temps après la date limite. Par exemple: Streaming audio-video.

Voici un lien vers une ressource très utile.

Il est populaire d’associer une grande catastrophe à la définition du temps réel difficile, mais cela n’est pas pertinent. Tout échec à respecter une contrainte matérielle en temps réel signifie simplement que le système est cassé. La gravité du résultat lorsque quelque chose est étiqueté “cassé” n’est pas importante pour la définition.

Les contrats fermes et souples ne sont tout simplement pas déclarés automatiquement rompus en cas de non-respect d’un seul délai.

Pour un bon exemple de dur temps réel, à partir de la page que vous avez liée:

Les premiers systèmes de jeux vidéo tels que les graphiques vectoriels Atari 2600 et Cinematronics avaient des exigences en temps réel difficiles en raison de la nature du matériel graphique et de synchronisation.

Si quelque chose dans la boucle de génération de vidéo ne manquait qu’une seule échéance, l’affichage entier serait un problème, ce qui serait intolérable, même si c’était rare. Ce serait un système cassé et vous le rapporteriez au magasin pour un remboursement. Donc c’est dur en temps réel.

De toute évidence, tout système peut être sujet à des situations qu’il ne peut pas gérer, il est donc nécessaire de limiter la définition aux conditions de fonctionnement attendues – notant que dans les applications critiques pour la sécurité, les gens doivent prévoir des conditions terribles les freins ont échoué “, mais rarement” le soleil a explosé “).

Et n’oublions pas que parfois il y a une condition de fonctionnement implicite «pendant que quelqu’un regarde». Si personne ne vous voit enfreindre les règles (ou si c’est le cas mais qu’ils meurent avant d’en parler), et que personne ne peut prouver que vous avez enfreint les règles après coup, c’est comme si vous n’aviez jamais enfreint les règles!

La manière la plus simple de distinguer les différents types de systèmes en temps réel est de répondre à la question suivante:

Une réponse différée du système (après la date limite) est-elle encore utile ou non?

Ainsi, en fonction de la réponse que vous obtenez pour cette question, votre système peut être inclus dans l’une des catégories suivantes:

  1. Difficile : Non, et les réponses différées sont considérées comme une défaillance du système

C’est le cas lorsque la date limite manquante rendra le système inutilisable. Par exemple, le système contrôlant le système Airbag de la voiture doit détecter le crash et gonfler rapidement le sac. L’ensemble du processus prend plus ou moins un vingt-cinquième de seconde. Ainsi, si le système, par exemple, réagit avec une seconde de retard, les conséquences pourraient être mortelles et il ne serait pas avantageux que le sac soit gonflé une fois que la voiture est déjà tombée en panne.

  1. Firm : Non, mais les réponses différées ne sont pas nécessairement une défaillance du système

C’est le cas lorsque le délai est insuffisant, mais cela affectera la qualité du service. Comme exemple simple, considérons un système de cryptage vidéo. Normalement, le mot de passe de cryptage est généré sur le serveur (vidéo Head End) et envoyé au décodeur client. Ce processus doit être synchronisé afin que le décodeur reçoive normalement le mot de passe avant de commencer à recevoir les images vidéo cryptées. Dans ce cas, un délai peut entraîner des problèmes vidéo, car le boîtier décodeur n’est pas en mesure de décoder les images car il n’a pas encore reçu le mot de passe. Dans ce cas, le service (film, match de football intéressant, etc.) pourrait être affecté par le non-respect du délai. Recevoir le mot de passe avec retard dans ce cas n’est pas utile car les images cryptées avec le même ont déjà provoqué les problèmes.

  1. Soft : Oui, mais le service système est dégradé

A partir de la description de wikipedia, l’utilité d’un résultat se dégrade après son échéance . Cela signifie que la réponse du système en dehors de la date limite est toujours utile pour l’utilisateur final, mais son utilité se dégrade après la date limite. Un exemple simple pour ce cas est un logiciel qui contrôle automatiquement la température d’une pièce (ou d’un bâtiment). Dans ce cas, si le système a des retards de lecture des capteurs de température, il sera un peu lent à réagir aux changements de température brusques. Cependant, à la fin, il finira par réagir au changement et en ajustant la température en conséquence, par exemple. Donc, dans ce cas, la réaction retardée est utile, mais elle dégrade la qualité de service du système.

Un doux temps réel est le plus facile à comprendre, dans lequel même si le résultat est obtenu après la date limite, les résultats sont toujours considérés comme valables.

Exemple: Navigateur Web – Nous demandons une certaine URL, le chargement de la page prend un certain temps. Si le système prend plus de temps que prévu pour nous fournir la page, la page obtenue n’est pas considérée comme invalide, nous disons simplement que les performances du système n’étaient pas à la hauteur (le système a donné de faibles performances!).

Dans le système temps réel dur , si le résultat est obtenu après la date limite, le système est considéré comme ayant complètement échoué.

Exemple: dans le cas où un robot effectue un travail tel que le traçage de ligne, etc. Si un obstacle survient sur son chemin et que le robot ne traite pas cette information dans un délai programmé (presque instantané!), Le robot est en panne dans sa tâche (le système de robot peut aussi être complètement détruit!).

Dans le système en temps réel ferme , si le résultat de l’exécution du processus intervient après la date limite, nous rejetons ce résultat, mais le système n’est pas considéré comme ayant échoué.

Exemple: communication par satellite pour la surveillance de la position de l’ennemi ou pour toute autre tâche. Si la station d’ordinateur au sol à laquelle les satellites envoient périodiquement les trames est surchargée et que la trame (paquet) en cours n’est pas traitée à temps et que la trame suivante arrive, le paquet actuel (celui qui a manqué la date limite) importe peu si le traitement a été effectué (ou à moitié fait ou presque terminé) est supprimé / supprimé. Mais l’ordinateur au sol n’est pas considéré comme ayant complètement échoué.

Pour définir “soft real-time”, il est plus facile de le comparer avec “hard real-time”. Nous verrons ci-dessous que le terme “entreprise en temps réel” constitue un malentendu à propos de “soft real-time”.

En parlant avec désinvolture, la plupart des gens ont implicitement un modèle mental informel qui considère l’information ou un événement comme étant “en temps réel”.

• si, ou dans la mesure où, il leur est manifeste avec un retard (latence) pouvant être lié à la monnaie perçue

• c’est-à-dire, dans un laps de temps donné, que l’information ou l’événement a une valeur satisfaisante pour eux.

Il existe de nombreuses définitions ad hoc différentes de «dur réel», mais dans ce modèle mental, le temps réel dur est représenté par le terme «si». Plus précisément, en supposant que les actions en temps réel (telles que les tâches) ont des délais d’exécution, la valeur acceptable satisfaisante de l’événement que toutes les tâches terminent est limitée au cas particulier où toutes les tâches respectent leurs délais.

Les systèmes durs en temps réel émettent des hypothèses très fortes selon lesquelles tout ce qui concerne l’application, le système et l’environnement est statique et connu a priori – par exemple, les tâches périodiques, les temps d’arrivée, les délais, Il n’y a pas de conflits de ressources et, globalement, l’évolution temporelle du système. Dans un système de commande de vol d’un avion ou dans un système de freinage automobile et dans de nombreux autres cas, ces hypothèses peuvent généralement être satisfaites afin que toutes les échéances soient respectées.

Ce modèle mental est délibérément et très utilement suffisamment général pour englober à la fois le dur et le doux en temps réel – le soft est accommodé par l’expression «dans la mesure où». Par exemple, supposons que l’événement de fin de tâche a une valeur sous-optimale mais acceptable si

  • pas plus de 10% des tâches manquent leurs délais
  • ou aucune tâche est plus de 20% de retard
  • ou le retard moyen de toutes les tâches ne dépasse pas 15%
  • ou le retard maximal entre toutes les tâches est inférieur à 10%

Ce sont tous des exemples courants de cas en temps réel dans de très nombreuses applications.

Considérez l’application à tâche unique de choisir votre enfant après l’école. Cela n’a probablement pas de date butoir réelle, mais il y a une certaine valeur pour vous et votre enfant en fonction du moment où cet événement a lieu. Le gaspillage des ressources trop précoces (comme votre temps) et l’apparition tardive d’une valeur négative car votre enfant pourrait être laissé seul et potentiellement en danger (ou du moins incommodé).

Contrairement au cas spécial statique en temps réel, le temps réel modéré ne fait que les hypothèses minimales nécessaires à l’application concernant les tâches et le système, et des incertitudes sont attendues. Pour venir chercher votre enfant, vous devez vous rendre à l’école, et le temps nécessaire pour le faire est dynamic, en fonction de la météo, des conditions de circulation, etc. Vous pourriez être tenté de suralimenter votre système (c.-à-d. dans le pire des cas, le temps de conduite), mais encore une fois, cela gaspille des ressources (votre temps et l’occupation du véhicule familial, éventuellement en refusant l’utilisation par d’autres membres de la famille).

Cet exemple peut ne pas sembler coûteux en termes de ressources gaspillées, mais considérons d’autres exemples. Tous les systèmes de combat militaires sont souples en temps réel. Par exemple, envisagez d’effectuer une attaque aérienne sur un véhicule terrestre hostile à l’aide d’un missile guidé avec les mises à jour apscopes aux manœuvres de la cible. La satisfaction maximale pour accomplir les tâches de mise à jour du cours est obtenue par une frappe destructive directe sur la cible. Mais une tentative de surapprovisionnement de ressources pour s’assurer de ce résultat est généralement beaucoup trop coûteuse et peut même être impossible. Dans ce cas, vous pouvez être moins mais suffisamment satisfait si le missile frappe assez près de la cible pour la désactiver.

De toute évidence, les scénarios de combat comportent de nombreuses incertitudes dynamics auxquelles la gestion des ressources doit faire face. Les systèmes temps réel souples sont également très courants dans de nombreux systèmes civils, tels que l’automatisation indussortingelle, même si, de toute évidence, les systèmes militaires sont les plus dangereux et les plus urgents pour obtenir une valeur acceptable satisfaisante.

La clé de voûte des systèmes en temps réel est la “prévisibilité”. Le cas concret en temps réel s’intéresse à un seul cas particulier de prévisibilité – à savoir que les tâches respectent toutes leurs délais et que la valeur maximale possible sera atteinte grâce à cet événement. Ce cas particulier est nommé “déterministe”.

Il y a un spectre de prévisibilité. Déterministe (déterminisme) est un point final (prévisibilité maximale) sur le spectre de prévisibilité; l’autre point final est la prévisibilité minimale (non-déterminisme maximal). La mésortingque du spectre et les points d’extrémité doivent être interprétés en termes de modèle de prévisibilité choisi; tout ce qui se trouve entre ces deux extrémités est le degré d’imprévisibilité (= degrés de non-déterminisme).

La plupart des systèmes en temps réel (à savoir les systèmes souples) ont une prévisibilité non déterministe, par exemple, des délais d’exécution des tâches et, par conséquent, des valeurs obtenues à partir de ces événements.

En général (en théorie), la prévisibilité, et donc la valeur acceptable acceptable, peut être rendue aussi proche du critère déterministe que nécessaire – mais à un prix qui peut être physiquement impossible ou excessivement coûteux (comme au combat ou peut-être même en ramasser votre enfant de l’école).

Le temps réel doux nécessite un choix spécifique à l’application d’un modèle de probabilité (pas le modèle fréquentiste commun) et donc un modèle de prévisibilité pour raisonner sur les latences d’événement et les valeurs résultantes.

En revenant à la liste ci-dessus des événements qui fournissent une valeur acceptable, nous pouvons maintenant append des cas non déterministes, tels que

  • la probabilité qu’aucune tâche ne dépasse son échéance de plus de 5% est supérieure à 0,87. (Notez le nombre de critères de planification exprimés ici.)

Dans une application de défense antimissile, compte tenu du fait que l’attaque au combat a toujours l’avantage par rapport à la défense, lequel de ces deux scénarios informatiques en temps réel préféreriez-vous:

  • comme la destruction parfaite de tous les missiles hostiles est très improbable ou impossible, affectez vos ressources défensives pour maximiser la probabilité que le plus grand nombre de missiles hostiles (par exemple, basés sur leurs cibles) soient interceptés avec succès. peut déplacer le missile hostile hors route);

  • déplorez qu’il ne s’agisse pas d’un problème informatique en temps réel car il est dynamic au lieu d’être statique, et les concepts et techniques traditionnels en temps réel ne s’appliquent pas, et cela semble plus difficile que le temps réel statique statique; .

En dépit des divers malentendus concernant le temps réel en temps réel dans la communauté informatique en temps réel, le temps réel logiciel est très général et puissant, bien que potentiellement complexe par rapport au temps réel difficile. Les systèmes temps réel logiciels résumés ici ont une longue histoire d’utilisation réussie en dehors de la communauté informatique en temps réel .

Pour répondre directement à la question OP:

Un système dur en temps réel peut fournir des garanties déterministes – le plus souvent que toutes les tâches respectent leurs délais, le temps de réponse aux interruptions ou aux appels système sera toujours inférieur à x, etc. – SI ET UNIQUEMENT si des hypothèses très fortes sont émises et correctes, tout ce qui compte est statique et connu a priori (en général, de telles garanties pour les systèmes temps réel durs sont un problème de recherche ouvert, sauf dans des cas plutôt simples)

Un système temps réel souple ne fournit pas de garanties déterministes, il vise à fournir la meilleure rapidité et la prévisibilité probabilistes analytiquement spécifiées possibles et prévisibles, réalisables dans les circonstances dynamics actuelles, selon des critères propres à chaque application.

Évidemment, le temps réel dur est un cas particulier simple de temps réel souple. De toute évidence, les assurances analytiques non déterministes en temps réel peuvent être très complexes à fournir, mais elles sont obligatoires dans les cas les plus courants (y compris les plus critiques pour la sécurité tels que le combat), car la plupart des cas statique.

“Firm real-time” est un cas particulier mal défini de “soft real-time”. Ce terme n’est pas nécessaire si le terme “temps réel souple” est compris et utilisé correctement.

J’ai une discussion plus détaillée et beaucoup plus précise sur mon site Web real-time.org à propos de sujets en temps réel, en temps réel, en temps réel, de prévisibilité, de déterminisme et autres sujets connexes.

temps réel – Relatif à un système ou à un mode de fonctionnement dans lequel le calcul est effectué pendant la durée réelle d’un processus externe, afin que les résultats des calculs puissent être utilisés pour contrôler, surveiller ou répondre au processus externe dans les délais. manière. [Norme IEEE 610.12.1990]

Je sais que cette définition est ancienne, très ancienne. Je ne peux cependant pas trouver de définition plus récente de l’IEEE (Institut des ingénieurs élecsortingciens et électroniciens).

Peut-être que la définition est en faute.

D’après mon expérience, je séparerais les deux en fonction du matériel et du logiciel.

Si vous avez 200ms pour traiter une interruption pilotée par le matériel, c’est ce que vous avez. Vous collez 300ms de code et le système n’est pas cassé, il n’a pas été développé. Vous serez éteint avant d’avoir fini. Votre code ne fonctionne pas ou n’est pas adapté à vos besoins. De nombreux systèmes ont des durées de traitement définies. Vidéo, télécoms, etc.

Si vous écrivez une application qui est en temps réel, cela peut être considéré comme un logiciel mou . Si vous manquiez de temps, vous pourriez espérer moins de charge la prochaine fois, vous pourriez régler le système d’exploitation, append de la mémoire ou même mettre à niveau le matériel. Vous avez des options.

Le regarder sous un angle UX n’est pas utile. Une Skoda ne sera peut-être pas brisée si elle cède, mais une BMW sera sûre.

La définition s’est élargie au fil des ans au désortingment du terme. Ce qu’on appelle maintenant “temps réel” est ce qu’on appelait simplement le temps réel. Ainsi, les systèmes dans lesquels des fenêtres de chronométrage manquantes (plutôt que des délais impartis) entraîneraient des données incorrectes ou un comportement incorrect devraient être pris en compte en temps réel. Les systèmes sans cette caractéristique seraient considérés comme non temps réel.

Cela ne veut pas dire que le temps n’intéresse pas les systèmes non temps réel, cela signifie simplement que les exigences de temps dans de tels systèmes n’entraînent pas de résultats fondamentalement incorrects.

Considérons une tâche qui entre les données du port série. Lorsque de nouvelles données arrivent, le port série déclenche un événement. Lorsque le logiciel gère cet événement, il lit et traite les nouvelles données. Le port série dispose d’un matériel permettant de stocker les données entrantes (2 sur le MSP432, 16 sur le TM4C123) de sorte que si le tampon est plein et que davantage de données arrivent, les nouvelles données sont perdues. Ce système est-il dur, ferme ou en temps réel?

C’est dur en temps réel car si la réponse est en retard, les données peuvent être perdues.


Considérez une aide auditive qui entre les sons d’un microphone, manipule les données sonores, puis transmet les données à un haut-parleur. Le système a généralement une gigue réduite et limitée, mais occasionnellement, d’autres tâches dans l’aide auditive entraînent un retard dans certaines données, provoquant une impulsion de bruit sur le haut-parleur. Ce système est-il dur, ferme ou en temps réel?

Il est ferme en temps réel car il provoque une erreur qui peut être perçue, mais l’effet est sans danger et ne modifie pas de manière significative la qualité de l’expérience.


Considérons une tâche qui génère des données sur une imprimante. Lorsque l’imprimante est inactive, l’imprimante déclenche un événement. Lorsque le logiciel gère cet événement, il envoie plus de données à l’imprimante. Ce système est-il dur, ferme ou en temps réel?

Il est doux en temps réel car plus vite il répond, mieux c’est, mais la valeur du système (la bande passante est la quantité de données imprimées par seconde) diminue avec la latence.

UTAustinX: UT.RTBN.12.01x Réseaux Bluetooth en temps réel