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

Question

J'ai lu les définitions des différentes notions de temps réel et les exemples fournis pour les systèmes en temps réel durs et mous me paraissent logiques. Mais, il n'y a pas de véritable explication ou exemple d'un système en temps réel ferme. Selon le lien ci-dessus :

Ferme : Les dépassements de délai peu fréquents sont tolérables, mais peuvent dégrader la qualité de service du système. L'utilité d'un résultat est nulle après sa date limite.

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

Dans les commentaires, Charles a demandé que je soumette des wikis de tags pour les nouveaux tags. L'exemple de "système ferme en temps réel" que j'ai fourni pour le tag entreprise-temps réel Le tag était un système de distribution de lait. Si le système livre du lait après sa date de péremption, alors 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 je me suis faite en lisant la définition au départ. Je suis à la recherche d'un bien meilleur exemple, et peut-être d'une meilleure définition de entreprise en temps réel qui améliorera ma conception de la chose.

Answer 1

Temps réel dur

El temps réel dur considère toute échéance non respectée comme une défaillance du système. Cet ordonnancement est largement utilisé dans les systèmes critiques où le non-respect des contraintes de temps entraîne une perte de vie ou de biens.

Exemples :

• Le vol 447 d'Air France s'est écrasé dans l'océan après qu'un dysfonctionnement d'un capteur a provoqué une série d'erreurs système. Les pilotes ont fait décrocher l'avion en réagissant à des relevés d'instruments périmés. Les 12 membres d'équipage et les 216 passagers ont été tués.

• Le vaisseau spatial Mars Pathfinder a failli être perdu lorsqu'une inversion de priorité a provoqué des redémarrages du système. Une tâche de priorité supérieure n'a pas été achevée à temps parce qu'elle était bloquée par une tâche de priorité inférieure. Le problème a été corrigé et le vaisseau spatial s'est posé avec succès.

• Une imprimante à jet d'encre est dotée d'une tête d'impression avec un logiciel de contrôle pour déposer la bonne quantité d'encre sur une partie spécifique du papier. Si un délai n'est pas respecté, le travail d'impression est gâché.

---

Entreprise en temps réel

El entreprise en temps réel La définition permet de ne pas dépasser fréquemment les délais. Dans ces applications, le système peut survivre aux échecs des tâches tant qu'ils sont suffisamment espacés, 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 chaînes de montage robotisées où le non-respect d'un délai entraîne le montage incorrect d'une pièce. Tant que les pièces défectueuses sont suffisamment rares pour être détectées par le contrôle de la qualité et qu'elles ne sont pas trop coûteuses, la production se poursuit.

• Un décodeur numérique pour le câble décode des horodatages indiquant le moment où les images doivent apparaître à l'écran. Comme les trames sont sensibles à l'ordre chronologique, un dépassement de délai entraîne une gigue, ce qui diminue la qualité du service. Si la trame manquée devient disponible plus tard, son affichage ne fera qu'augmenter la gigue, ce qui la rend inutile. Le téléspectateur peut toujours profiter du programme si la gigue ne se produit pas trop souvent.

---

Soft Real-Time

El temps réel doux La définition permet de dépasser fréquemment les délais, et tant que les tâches sont exécutées dans les temps, leurs résultats continuent d'avoir de la valeur. Les tâches achevées peuvent avoir une valeur croissante jusqu'à l'échéance et une valeur décroissante au-delà.

Exemples :

• Les stations météorologiques sont dotées de nombreux capteurs permettant de lire la température, l'humidité, la vitesse du vent, etc. Les relevés doivent être effectués et transmis à intervalles réguliers, mais les capteurs ne sont pas synchronisés. Les relevés doivent être effectués et transmis à intervalles réguliers, mais les capteurs ne sont pas synchronisés. Même si le relevé d'un capteur est en avance ou en retard par rapport aux autres, il peut être pertinent tant qu'il est suffisamment proche.

• Une console de jeu vidéo exécute un logiciel pour un moteur de jeu. De nombreuses ressources doivent être partagées entre ses tâches. En même temps, les tâches doivent être accomplies selon le calendrier prévu pour que le jeu se déroule correctement. Tant que les tâches sont accomplies relativement à temps, le jeu sera agréable, sinon il ne sera que légèrement décalé.

---

Siewert : Systèmes et composants embarqués en temps réel.
Liu & Layland : Algorithmes d'ordonnancement pour la multiprogrammation dans un environnement temps réel difficile.
Marchand & Silly-Chetto : Ordonnancement dynamique de tâches apériodiques douces et de tâches périodiques avec sauts.

Answer 2

Le temps réel dur signifie que vous devez absolument respecter tous les délais. Très peu de systèmes ont cette exigence. Citons par exemple 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/soft peuvent manquer quelques échéances, mais les performances finiront par se dégrader si elles sont trop nombreuses. Un bon exemple est le système de sonorisation de votre ordinateur. Si vous ratez quelques bits, ce n'est pas grave, mais si vous en ratez trop, vous finirez par dégrader le système. Il en va de même pour les capteurs sismiques. Si vous manquez quelques points de données, ce n'est pas grave, mais vous devez en capturer la plupart pour donner un sens aux données. Plus important encore, personne ne va mourir s'ils ne fonctionnent pas correctement.

La limite est floue, car même un stimulateur cardiaque peut être faussé par une petite quantité sans tuer le patient, mais c'est l'essentiel.

C'est un peu comme la différence entre chaud et tiède. Il n'y a pas de réelle différence, mais vous le savez quand vous le sentez.

Answer 3

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 en temps réel dur Si le système ne parvient pas à respecter le délai même une fois, il est considéré comme ayant échoué.

2> Pour un Système ferme en temps réel Ainsi, même si le système ne parvient pas à respecter le délai, éventuellement plus d'une fois (c'est-à-dire pour plusieurs demandes), il 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.) sont sans valeur une fois que le délai pour cette demande particulière est passé ( L'utilité d'un résultat est nulle 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 son arrivée, alors le système a fait son travail, la prédiction après que l'événement se soit déjà produit ou lorsqu'il se produit n'a aucune valeur).

3> Pour un Système logiciel en temps réel Ainsi, même si le système ne parvient pas à respecter le délai, éventuellement plus d'une fois (c'est-à-dire pour plusieurs demandes), il n'est pas considéré comme ayant échoué. Mais, dans ce cas, les résultats des demandes ne sont pas sans valeur la valeur d'un résultat après sa date limite, n'est pas zéro Elle se dégrade au fur et à mesure que le temps passe après l'échéance. Par exemple : Streaming audio-vidéo.

Ici est un lien vers une ressource qui a été très utile.

Answer 4

Il est courant d'associer une grande catastrophe à la définition du temps réel dur, mais ce n'est pas pertinent. Tout échec à satisfaire une contrainte de temps réel dur signifie simplement que le système est cassé. La gravité du résultat lorsque quelque chose est qualifié de "cassé" n'est pas importante pour la définition.

Il n'est pas possible de déclarer automatiquement que l'on ne respecte pas un seul délai.

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

Les premiers systèmes de jeux vidéo, comme l'Atari 2600 et les graphiques vectoriels de Cinematronics, avaient des exigences de temps réel très strictes en raison de la nature des graphiques et du matériel de synchronisation.

Si quelque chose dans la boucle de génération vidéo manquait ne serait-ce qu'une seule échéance, l'ensemble de l'affichage se bloquerait, ce qui serait intolérable, même si c'est rare. Ce serait un système cassé et vous le rapporteriez au magasin pour être remboursé. Il s'agit donc d'un temps réel difficile.

Il est évident que tout système peut être soumis à des situations qu'il ne peut pas gérer, il est donc nécessaire de restreindre la définition aux conditions de fonctionnement prévues - en notant que dans les applications critiques pour la sécurité, les gens doivent prévoir des conditions terribles ("le liquide de refroidissement s'est évaporé", "les freins ont lâché", mais rarement "le soleil a explosé").

Et n'oublions pas qu'il existe parfois une condition implicite de fonctionnement "pendant que personne ne regarde". Si personne ne vous voit enfreindre les règles (ou si c'est le cas mais qu'ils éteignent le feu avant de le dire à qui que ce soit), et si personne ne peut prouver que vous avez enfreint les règles après coup, alors c'est un peu comme si vous n'aviez jamais enfreint les règles !

Answer 5

La façon 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, selon la réponse que vous obtenez à cette question, votre système pourrait être inclus dans l'une des catégories suivantes :

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

C'est le cas lorsque le non-respect de la date limite rendra le système inutilisable. Par exemple, le système qui contrôle le système d'airbag d'une voiture doit détecter l'accident et gonfler rapidement le sac. L'ensemble du processus prend plus ou moins un vingt-cinquième de seconde. Ainsi, si le système réagit avec une seconde de retard, les conséquences pourraient être mortelles et il ne servirait à rien de gonfler le sac une fois que la voiture se serait déjà écrasée.

2. Ferme : Non, mais les réponses retardées ne sont pas nécessairement une défaillance du système.

C'est le cas lorsque le non-respect du délai est tolérable mais qu'il affecte la qualité du service. Prenons un exemple simple : un système de cryptage vidéo. Normalement, le mot de passe de cryptage est généré dans l'ordinateur de l'utilisateur. serveur (tête de réseau vidéo) et envoyé au boîtier décodeur du client. Ce processus doit être synchronisé de manière à ce que le boîtier décodeur reçoive normalement la mot de passe avant de commencer à recevoir les trames vidéo cryptées. Dans ce cas, un retard peut entraîner des problèmes vidéo, car le décodeur n'est pas en mesure de décoder les images parce qu'il n'a pas encore reçu le mot de passe. Dans ce cas, le service (film, un match de football intéressant, etc.) pourrait être affecté par le non-respect du délai. Dans ce cas, la réception tardive du mot de passe n'est pas utile puisque les images cryptées avec ce mot de passe ont déjà causé les problèmes.

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

D'après la description de wikipedia l'utilité d'un résultat se dégrade après son échéance . En d'autres termes, obtenir une réponse du système avant la date limite est toujours utile pour l'utilisateur final, mais son utilité se dégrade une fois la date limite atteinte. 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 quelques retards dans la lecture des capteurs de température, il sera un peu lent à réagir aux changements brusques de température. Cependant, à la fin, il finira par réagir au changement et ajustera en conséquence la température pour la maintenir constante, par exemple. Dans ce cas, la réaction retardée est donc utile, mais elle dégrade la qualité de service du système.