Différences entre temps réel, temps réel doux et temps réel ferme
J'ai lu les définitions de différentes notions de temps réel , et les exemples fournis pour les systèmes temps réel stricts et indirects me paraissent tout à fait sensés. Mais il n’existe pas de véritable explication ni d’exemple de système en temps réel. Selon le lien ci-dessus:
Firm: Les échecs peu fréquents 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 en temps réel et le temps réel, et existe-t-il un bon exemple illustrant cette distinction?
Dans ses commentaires, Charles a demandé que je soumette des wikis de balises pour les nouvelles balises. L'exemple d'un "système en temps réel d'entreprise" que j'ai fourni pour la balise en temps réel était un système de distribution de lait. Si le système distribue du lait après son heure de péremption, le lait est considéré comme "inutile". 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 justement l’idée que je me suis faite dans la tête lorsque j’ai lu la définition pour la première fois. Je cherche un exemple bien meilleur, et peut-être une meilleure définition de entreprise en temps réel qui permettra d’en améliorer la notion.
Difficile en temps réel signifie que vous devez absolument respecter toutes les échéances. 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/logiciels peuvent ne pas respecter certaines échéances, mais les performances risquent de se dégrader si trop de personnes sont manquées. Un bon exemple est le système audio de votre ordinateur. Si vous manquez quelques bits, ce n'est pas grave, mais si vous en oubliez trop, vous finirez par dégrader le système. Les capteurs sismiques seraient similaires. Si vous manquez quelques points de données, ce n'est pas grave, mais vous devez en saisir la plupart pour donner un sens aux données. Plus important encore, personne ne mourra s'il ne fonctionne pas correctement.
La ligne est floue, car même un stimulateur cardiaque peut être désactivé par une petite quantité sans tuer le patient, mais c'est le général Gist.
C'est un peu comme la différence entre chaud et chaud. Il n'y a pas vraiment de division, mais vous le savez quand vous le sentez.
Difficile en temps réel
La définition hard real-time considère que toute échéance manquée est une défaillance du système. Cet ordonnancement est largement utilisé dans les systèmes stratégiques, où le non-respect des contraintes de synchronisation entraîne des pertes de vies ou des dégâts matériels.
Exemples:
Le vol 447 d’Air France s’est écrasé dans l’océan à la suite d’une défaillance du capteur qui a entraîné une série d’erreurs système. Les pilotes ont calé l'aéronef en répondant à des relevés d'instruments obsolètes. Les 12 membres d'équipage et 216 passagers ont été tués.
La sonde Mars Pathfinder était presque perdue lorsqu'une inversion de priorité entraînait le redémarrage du système. Une tâche de priorité supérieure n'a pas été achevée à temps car bloquée par une tâche de priorité inférieure. Le problème a été corrigé et le vaisseau spatial a atterri avec succès.
Une imprimante à jet d'encre comporte une tête d'impression dotée d'un logiciel de contrôle permettant de déposer la quantité d'encre appropriée sur une partie spécifique du papier. Si une date limite est manquée, le travail d'impression est ruiné.
Ferme en temps réel
La définition ferme en temps réel permet de respecter des échéances peu fréquentes. Dans ces applications, le système peut survivre à des échecs de tâche tant qu'ils sont correctement espacés. Toutefois, 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 non-respect d'une date limite a pour conséquence l'assemblage incorrect d'une pièce. Tant que les pièces en ruine sont suffisamment rares pour être saisies 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. Étant donné que les trames sont sensibles à l'ordre chronologique, une échéance manquée provoque une instabilité, ce qui diminue la qualité de service. Si plus tard, la trame manquée devient disponible, cela ne fera que créer plus de jitter, c'est donc inutile. Le téléspectateur peut toujours profiter du programme si la gigue ne se produit pas trop souvent.
Temps réel doux
La définition soft real-time permet de respecter les délais fréquemment constatés et, tant que les tâches sont exécutées dans les délais impartis, leurs résultats continuent d'avoir de la valeur. Les tâches terminées peuvent avoir une valeur croissante jusqu'à la date limite et une valeur décroissante après celle-ci.
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. Même si une lecture de capteur peut être précoce ou tardive par rapport aux autres, elle peut néanmoins être pertinente tant qu'elle est suffisamment proche.
Une console de jeu vidéo exécute un logiciel pour un moteur de jeu. Il y a beaucoup de ressources qui doivent être partagées entre ses tâches. En même temps, les tâches doivent être complétées conformément au planning pour que le jeu soit correctement joué. Tant que les tâches sont relativement à l’heure, le jeu sera agréable, sinon il risque de prendre un peu de retard.
Siewert: Systèmes et composants intégrés en temps réel.
Liu & Layland: Algorithmes de planification pour la multiprogrammation dans un environnement en temps réel difficile.
Marchand & Silly-Chetto: Ordonnancement dynamique de tâches apériodiques douces 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 inférences suivantes:
1> Pour un système temps réel dur, si le système ne respecte pas l’échéance, même une fois que le système est considéré comme ayant échoué.
2> Pour un système en temps réel Firm, même si le système ne respecte pas l’échéance, éventuellement plusieurs fois (c’est-à-dire pour plusieurs demandes), le système n’est pas considéré en panne. De plus, les réponses aux requêtes (réponses à une requête, résultat d'une tâche, etc.) sont sans valeur une fois que le délai de cette requête est écoulé (L'utilité d'un résultat est nulle après son délai). Un exemple hypothétique peut être un système de prévision de tempête (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 se soit déjà produit ou quand il se produit est sans valeur).
3> Pour un système temps réel Soft, même si le système ne respecte pas l’échéance, éventuellement plusieurs fois (c’est-à-dire pour plusieurs requêtes), le système n’est pas considéré en panne. Mais, dans ce cas, les résultats des demandes ne sont pas sans valeur valeur pour un résultat après son échéance, n'est pas nul, mais se dégrade au fil du temps. Ex .: en streaming audio-vidéo.
Ici est un lien vers une ressource qui a été très utile.
Il est courant d'associer une grande catastrophe à la définition du temps réel, mais ce n'est pas pertinent. Tout manquement à une contrainte temps réel dure signifie simplement que le système est en panne. La gravité du résultat lorsque quelque chose est étiqueté "cassé" n'est pas importante pour la définition.
Firm et soft ne parviennent tout simplement pas à être automatiquement déclarés cassés s'ils ne respectent pas un délai.
Pour un bon exemple de temps réel difficile, à partir de la page que vous avez liée:
Les premiers systèmes de jeu vidéo tels que l’Atari 2600 et les graphiques vectoriels Cinematronics avaient des exigences en temps réel difficiles en raison de la nature du matériel graphique et de la minuterie.
Si quelque chose dans la boucle de génération vidéo ne manquait qu'une seule échéance, l'affichage entier deviendrait invisible, ce qui serait intolérable, même si c'était rare. Ce serait un système défectueux et vous le rapporteriez au magasin pour un remboursement. C'est donc difficile en temps réel.
De toute évidence, tout système peut être soumis à des situations qu’il ne peut pas gérer. Il est donc nécessaire de limiter la définition aux conditions de fonctionnement attendues. Notez que, dans les applications critiques pour la sécurité, les utilisateurs doivent se préparer à des conditions terribles ("le liquide de refroidissement s’est évaporé", " les freins ont échoué ", mais rarement" le soleil a explosé ").
Et n'oublions pas qu'il y a parfois une condition de fonctionnement implicite "pendant que tout le monde regarde". Si personne ne vous voit enfreindre les règles (ou s’ils l’ont fait, mais qu’ils mourront avant de le dire à personne) et que personne ne pourra prouver que vous avez enfreint les règles après coup, c’est un peu la même chose que si vous ne l’aviez jamais fait!
Le moyen le plus simple de distinguer les différents types de types de système temps réel consiste à répondre à la question suivante:
Est-ce qu'une réponse tardive du système (après la date limite) est toujours utile ou non?
Ainsi, en fonction de la réponse obtenue à cette question, votre système pourrait être inclus dans l'une des catégories suivantes:
- 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 l'absence de la date limite rendra le système inutilisable. Par exemple, le système contrôlant le système d’airbag de voiture devrait 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 par exemple avec une seconde de retard, les conséquences pourraient être mortelles et le fait de gonfler le sac une fois que la voiture est déjà tombée ne présente aucun avantage.
- Firm : Non, mais des réponses différées ne sont pas nécessaires en cas de défaillance du système
C’est le cas lorsque le non-respect du délai est tolérable, mais cela affectera la qualité du service. A titre d'exemple simple, considérons un système de cryptage vidéo. Normalement, le mot de passe de chiffrement est généré dans server (tête de vidéo) et envoyé au terminal client. Ce processus doit être synchronisé afin que, normalement, le boîtier décodeur reçoive le mot de passe avant de recevoir les images vidéo cryptées. Dans ce cas, un retard peut entraîner des problèmes vidéo car le décodeur ne peut pas 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. Dans ce cas, il n'est pas utile de recevoir le mot de passe avec retard, car les trames cryptées avec la même chose ont déjà causé les problèmes.
- 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 sa date limite. Autrement dit, obtenir une réponse du système dans les délais impartis reste utile pour l'utilisateur final, mais son utilité se dégrade une fois le délai imparti dépassé. Un exemple simple dans 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 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 à ajuster en conséquence la température pour le maintenir constant, par exemple. Donc, dans ce cas, la réaction différée est utile, mais elle dégrade la qualité de service du système.
Un soft real time 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 valides.
Exemple: Navigateur Web - Nous demandons une certaine URL, le chargement de la page prend un certain temps. Si le système met plus de temps que prévu à nous fournir la page, la page obtenue n'est pas considérée comme non valide, nous disons simplement que les performances du système n'étaient pas à la hauteur (le système a donné des performances faibles!).
Dans dur temps réel système, si le résultat est obtenu après la date limite, le système est considéré comme complètement défaillant.
Exemple: Dans le cas où un robot effectue un travail tel que traçage de ligne, etc. Si un obstacle se produit sur son chemin et que le robot ne traite pas cette information dans un délai programmé (presque instantanément), le robot est dit avoir échoué dans sa tâche (le système de robot peut également être complètement détruit!).
Dans entreprise en temps réel système, si le résultat de l'exécution du processus arrive après la date limite, nous l'annulons, 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 toute autre tâche. Si la station informatique au sol à laquelle les satellites envoient périodiquement les trames est surchargée et que la trame actuelle (paquet) n'est pas traitée à temps et que la trame suivante est affichée, le paquet actuel (celui qui a manqué l'heure) n'a plus d'importance si le traitement a été effectué (ou à moitié ou presque) est abandonné/rejeté. Mais l'ordinateur au sol n'est pas censé avoir complètement échoué.
Pour définir «temps réel modéré», il est plus facile de le comparer à «temps réel difficile». Nous verrons ci-dessous que le terme "entreprise en temps réel" constitue un malentendu au sujet du "temps réel souple".
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ù, cela leur est manifeste avec un retard (latence) qui peut être lié à sa monnaie perçue
• c’est-à-dire dans un laps de temps où l’information ou l’événement a une valeur acceptable pour eux.
Il existe de nombreuses définitions ad hoc différentes de «temps réel difficile», mais dans ce modèle mental, le temps réel réel est représenté par le terme «si». Spécifiquement, en supposant que les actions en temps réel (telles que les tâches) ont des délais d’achèvement, la valeur acceptable de l’événement que toutes les tâches sont terminées est limitée au cas particulier où toutes les tâches respectent leurs délais.
Les systèmes en temps réel difficiles supposent très fermement que tout ce qui concerne l'application, le système et l'environnement est statique et connu à priori - par exemple, quelles tâches, quelles sont leurs tâches périodiques, leurs heures d'arrivée, leurs périodes, leurs délais, ce qu'ils ont gagné pas de conflits de ressources, et globalement l’évolution temporelle du système. Dans un système de contrôle de vol d'aéronef ou un système de freinage automobile et dans de nombreux autres cas, ces hypothèses peuvent généralement être satisfaites, de sorte que tous les délais soient respectés.
Ce modèle mental est délibérément et très utilement assez 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 ait une valeur sous-optimale mais acceptable si
- pas plus de 10% des tâches ne respectent pas les délais
- ou aucune tâche n'est retardée à plus de 20%
- ou le retard moyen de toutes les tâches ne dépasse pas 15%
- ou le retard maximum parmi toutes les tâches est inférieur à 10%
Ce sont tous des exemples courants d’affaires en temps réel dans de très nombreuses applications.
Considérez l’application unique consistant à récupérer votre enfant après l’école. Cela n’a probablement pas de date limite réelle, mais votre enfant et votre enfant ont une certaine valeur en fonction du moment où cet événement a lieu. Trop tôt gaspille des ressources (comme votre temps) et trop tard a une valeur négative car votre enfant peut être laissé seul et potentiellement en danger (ou au moins dérangé).
Contrairement au cas spécial statique en temps réel strict, soft real-time n'émet que le minimum nécessaire d'hypothèses spécifiques à l'application sur les tâches et le système, et des incertitudes sont attendues. Pour aller chercher votre enfant, vous devez vous rendre à l'école en voiture. Le temps nécessaire pour le faire est dynamique, en fonction des conditions météorologiques, de la circulation, etc. Vous pourriez être tenté de sur-approvisionner votre système (c.-à-d. Autoriser ce que vous espérez dans le pire des cas, le temps de conduite), mais encore une fois, cela gaspille des ressources (votre temps, et occuper le véhicule de la famille, voire empêcher l’utilisation par d’autres membres de la famille).
Cet exemple peut ne pas sembler coûteux en termes de gaspillage de ressources, mais considérons d’autres exemples. Tous les systèmes de combat militaires sont en temps réel doux. Par exemple, envisagez de lancer une attaque aérienne sur un véhicule terrestre hostile en utilisant un missile guidé avec des mises à jour correspondant aux manœuvres de la cible. La satisfaction maximale pour l'achèvement des tâches de mise à jour du cours est obtenue par un coup direct destructif sur la cible. Mais tenter de sur-allouer des ressources pour obtenir ce résultat est généralement beaucoup trop coûteux et peut même être impossible. Dans ce cas, vous pouvez être moins satisfait mais suffisamment satisfait si le missile frappe suffisamment près de la cible pour le désactiver.
Il est évident que les scénarios de combat comportent un grand nombre d'incertitudes dynamiques possibles qui doivent être prises en compte par la gestion des ressources. Les systèmes temps réel souples sont également très répandus dans de nombreux systèmes civils, tels que l’automatisation industrielle, bien que les systèmes militaires soient évidemment les plus dangereux et les plus urgents pour atteindre une valeur acceptable de manière satisfaisante.La clé de voûte des systèmes temps réel est la "prévisibilité". Le cas difficile en temps réel n’intéresse qu’un seul cas particulier de prévisibilité - c’est-à-dire que les tâches respecteront toutes leurs échéances et que cet événement aura le maximum de valeur possible. Ce cas particulier est nommé "déterministe".
Il existe un spectre de prévisibilité. Déterministe (déterminisme) est un point final (prévisibilité maximale) sur le spectre de prévisibilité; l'autre objectif est la prévisibilité minimale (non déterminisme maximal). La métrique et les points finaux du spectre doivent être interprétés en termes de modèle de prévisibilité choisi; tout ce qui se situe entre ces deux points extrêmes correspond à des degrés d'imprévisibilité (= degrés de non-déterminisme).
La plupart des systèmes en temps réel (à savoir les systèmes logiciels) ont une prévisibilité non déterministe, par exemple, du temps nécessaire à l'exécution des tâches et, partant, des valeurs obtenues grâce à ces événements.
En général (en théorie), la prévisibilité, et donc une valeur acceptable satisfaisante, peut être rendue aussi proche du résultat déterministe que nécessaire - mais à un prix physiquement impossible ou excessivement coûteux (comme au combat ou peut-être même dans le cas contraire). ramasser votre enfant à l'école).
Le logiciel en temps réel souple nécessite le choix d'un modèle de probabilité spécifique à l'application (et non le modèle fréquentiste habituel) et donc d'un modèle de prévisibilité permettant de raisonner sur les latences des événements et les valeurs résultantes.
En revenant à la liste ci-dessus d'événements qui fournissent une valeur acceptable, nous pouvons maintenant ajouter des cas non déterministes, tels que.
- dans une application de défense antimissile, compte tenu du fait qu’au combat, l’offensive a toujours un avantage sur la défense, lequel de ces deux scénarios de calcul en temps réel préféreriez-vous:
en dépit des divers malentendus concernant le temps réel modéré dans la communauté informatique en temps réel, le temps réel modéré 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 souples, tels que résumés ici, ont une longue histoire d'utilisation réussie en dehors de la communauté en temps réel computing.
Pour répondre directement à la question OP:.
Un système en temps réel difficile peut fournir des garanties déterministes - le plus souvent, toutes les tâches respectent leurs délais, le temps de réponse des appels système ou des interruptions sera toujours inférieur à x, etc. - SI ET SEULEMENT SI des hypothèses très strictes sont formulées et sont 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 difficiles constituent un problème de recherche ouvert, sauf dans des cas assez simples).
Un système en temps réel souple ne donne pas de garanties déterministes, il est censé fournir la meilleure opportunité probabiliste et accomplie analytiquement spécifiée et accomplie qui soit réalisable dans les circonstances dynamiques actuelles, en fonction de critères spécifiques à l'application.
Il est évident que le temps réel difficile est un simple cas particulier de temps réel doux. Il est évident que les assurances non déterministes analytiques en temps réel de soft soft peuvent être très complexes à fournir, mais sont obligatoires dans les cas les plus courants en temps réel (y compris les plus dangereux pour la sécurité, tels que les combats), car la plupart des cas en temps réel sont dynamiques. statique.
"Firm temps réel" est un cas particulier mal défini de "soft temps réel". Ce terme n'est pas nécessaire si le terme "temps réel souple" est compris et utilisé correctement.
J'ai une discussion beaucoup plus détaillée, beaucoup plus précise, sur le temps réel, le temps réel dur, le temps réel doux, la prévisibilité, le déterminisme et des sujets connexes sur mon site web real-time.org.
I have a more detailed much more precise discussion of real-time, hard real-time, soft real-time, predictability, determinism, and related topics on my web site real-time.org.
temps réel - Relatif à un système ou mode de fonctionnement dans lequel le calcul est effectué pendant le temps réel où un processus externe se produit, afin que les résultats du calcul puissent être utilisés pour contrôler, surveiller ou répondre au processus externe en temps voulu manière. [Norme IEEE 610.12.1990]
Je sais que cette définition est ancienne, très ancienne. Je ne trouve toutefois pas de définition plus récente de l'IEEE (Institute of Electrical and Electronics Engineers).
Considérez une tâche qui entre des données du port série. Lorsque de nouvelles données arrivent, le port série déclenche un événement. Lorsque le logiciel traite cet événement, il lit et traite les nouvelles données. Le port série dispose d'un matériel pour stocker les données entrantes (2 sur le MSP432, 16 sur le TM4C123) de telle 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 souple en temps réel?
C'est dur en temps réel parce que si la réponse est en retard, les données peuvent être perdues.
Envisagez une aide auditive qui entre les sons d'un microphone, manipule les données sonores, puis envoie les données à un haut-parleur. Le système a généralement une instabilité faible et limitée, mais parfois, d'autres tâches de l'aide auditive entraînent le retard de certaines données, ce qui provoque un bruit Impulsion sur le haut-parleur. Ce système est-il dur, ferme ou mou en temps réel?
C'est ferme en temps réel car cela provoque une erreur qui peut être perçue mais l'effet est inoffensif et ne modifie pas de manière significative la qualité de l'expérience.
Considérez une tâche qui transmet des données à une imprimante. Lorsque l'imprimante est inactive, elle déclenche un événement. Lorsque le logiciel traite cet événement, il envoie plus de données à l'imprimante. Ce système est-il dur, ferme ou mou en temps réel?
C'est temps réel modéré parce que plus la réponse est rapide, mieux c'est, mais la valeur du système (la bande passante correspond à la quantité de données imprimées par seconde) diminue avec la latence.
UTAustinX: Réseaux Bluetooth en temps réel UT.RTBN.12.01x
Peut-être que la définition est en faute.
De mon expérience, je séparerais les deux comme étant dépendants du matériel et du logiciel.
Si vous avez 200 ms pour traiter une interruption pilotée par le matériel, c'est ce que vous avez. Vous y mettez 300 ms de code et le système n'est pas en panne, il n'a pas été développé. Vous serez déconnecté avant d'avoir fini. Votre code ne fonctionne pas ou n'est pas adapté. De nombreux systèmes ont des périodes de traitement bien définies. Vidéo, télécoms etc.
Si vous écrivez une application en temps réel, cela pourrait être considéré comme soft. Si vous manquez de temps, vous pourriez espérer une charge moins lourde la prochaine fois, vous pouvez ajuster le système d'exploitation, ajouter de la mémoire ou même mettre à niveau le matériel. Vous avez des options.
Le regarder du point de vue de l'expérience utilisateur n'est pas utile. Une Skoda ne sera peut-être pas cassée si elle tombe en panne, mais une BMW aussi sûre que possible.
La définition s’est élargie au fil des ans au détriment du terme. Ce qu'on appelle maintenant "temps dur" est ce qu'on appelait simplement temps réel. Ainsi, les systèmes dans lesquels des fenêtres de minutage manquantes (plutôt que des délais unilatéraux) entraîneraient des données incorrectes ou un comportement incorrect doivent être considérés en temps réel. Les systèmes sans cette caractéristique seraient considérés comme n'étant pas en temps réel.
Cela ne veut pas dire que le temps n’a pas d’intérêt dans les systèmes hors temps réel, cela signifie simplement que les exigences de temps dans de tels systèmes ne donnent pas de résultats fondamentalement incorrects.
Les systèmes temps réel durs utilisent une version préemptive de la planification des priorités, de sorte que les tâches critiques soient immédiatement planifiées, tandis que les systèmes temps réel souples utilisent une version non préemptive de la planification des priorités, ce qui permet d’achever la tâche actuelle avant de transférer le contrôle à la priorité la plus élevée tâche, causant des retards supplémentaires. Ainsi, les délais des tâches sont scrupuleusement respectés dans les systèmes en temps réel dur, alors que dans les systèmes en temps réel souples, ils ne sont pas traités avec autant de sérieux.