Différences entre le temps réel dur, le temps réel doux et le 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 dur et logiciel ont du sens pour moi. Mais, il n'y a pas d'explication ou d'exemple réel d'un système en temps réel ferme. Selon le lien ci-dessus:

Ferme: Les ratés de délais 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 son échéance.

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

Dans les commentaires, Charles a demandé que je soumette des wikis de balises pour les nouvelles balises. L'exemple d'un "système temps réel ferme" que j'ai fourni pour leentreprise en temps réeltag était un système de service de lait. Si le système délivre du lait après son expiration, alors 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 juste l'idée que j'ai formée dans ma tête lorsque j'ai lu la définition pour la première fois. Je recherche un bien meilleur exemple, et peut-être une meilleure définition de l' entreprise en temps réel qui améliorera ma notion de celui-ci.

Le temps réel dur signifie que vous devez absolument respecter toutes les échéances. Très peu de systèmes ont cette exigence. Quelques 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 finiront par se dégrader si trop 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 en manquez trop et 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 attraper la plupart pour comprendre les données. Plus important encore, personne ne mourra s'ils ne fonctionnent pas correctement.

La ligne est floue, car même un stimulateur cardiaque peut être légèrement désactivé sans 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 fracture, mais vous le savez quand vous le sentez.

Temps réel difficile

La définition dure du temps réel considère toute échéance manquée comme une défaillance du système. Cette planification est largement utilisée dans les systèmes critiques de mission 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 qu'un dysfonctionnement du capteur ait causé une série d'erreurs système. Les pilotes ont décroché l'avion tout en répondant à des relevés d'instruments périmés. Les 12 membres d'équipage et 216 passagers ont été tués.

• Le vaisseau spatial Mars Pathfinder a été presque perdu lorsqu'une inversion de priorité a provoqué le redémarrage du système. Une tâche de priorité plus élevée n'a pas été achevée à temps en raison du blocage 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 a 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 une date limite est dépassée, le travail d'impression est interrompu.

Temps réel ferme

La définition en temps réel ferme permet des délais rarement manqués. Dans ces applications, le système peut survivre aux échecs de 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:

• Systèmes de fabrication avec des lignes d'assemblage de robots où le non-respect d'un délai entraîne un assemblage incorrect d'une pièce. Tant que les pièces endommagées sont assez rares pour être capturées par le contrôle qualité et pas trop coûteuses, la production se poursuit.

• Un décodeur de câble numérique décode les horodatages pour le moment où les images doivent apparaître à l'écran. Étant donné que les trames sont sensibles à l'ordre du temps, un délai non respecté provoque une gigue, ce qui diminue la qualité de service. Si l'image manquée devient plus tard disponible, cela ne fera que provoquer plus de gigue pour l'afficher, donc c'est inutile. Le spectateur peut toujours profiter du programme si la gigue ne se produit pas trop souvent.

Temps réel doux

La définition douce en temps réel tient compte des délais fréquemment manqués, et tant que les tâches sont exécutées en temps opportun, leurs résultats continuent d'avoir de la valeur. Les tâches terminées peuvent avoir une valeur croissante jusqu'à l'échéance et une valeur décroissante au-delà.

Exemples:

• Les stations météorologiques ont de nombreux capteurs pour lire la température, l'humidité, la vitesse du vent, etc. Les mesures doivent être prises 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 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 pour que le jeu se déroule correctement. Tant que les tâches sont complètement relativement ponctuelles, le jeu sera agréable, sinon il se peut qu'il ne traîne qu'un peu.

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

Après avoir lu la page Wikipédia et d'autres pages sur l'informatique en temps réel. J'ai fait les inférences suivantes:

1> Pour un système en temps réel dur , si le système ne respecte pas le délai même une fois que le système est considéré comme ayant échoué.

2> Pour un système temps réel ferme , même si le système ne respecte pas le délai, peut-être plus d'une fois (c'est-à-dire pour plusieurs demandes), le système n'est pas considéré comme ayant échoué. 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 la date limite de cette requête particulière passée ( l'utilité d'un résultat est nulle après sa date limite ). Un exemple hypothétique peut être un système de prévision de tempête (si une tempête est prévue avant l'arrivée, alors le système a fait son travail, la prévision après que l'événement s'est déjà produit ou quand il se produit n'a aucune valeur).

3> Pour un système temps réel Soft , même si le système ne respecte pas le délai, peut-être plus d'une fois (c'est-à-dire pour plusieurs demandes), le système n'est pas considéré comme ayant échoué. Mais, dans ce cas, les résultats des requêtes ne sont pas sans valeur pour un résultat après son échéance, n'est pas nul , il se dégrade plutôt au fur et à mesure que le temps passe après l'échéance. Exemple: Streaming audio-vidéo.

Voici un lien vers une ressource très utile.

Il est courant d'associer une grande catastrophe à la définition du temps réel dur, mais ce n'est pas pertinent. Tout échec à répondre à une contrainte dure en temps réel 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.

Ferme et souple ne parviennent tout simplement pas à être automatiquement déclarés rompus en cas de non-respect d'un délai unique.

Pour un bon exemple de temps réel dur, à 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 des graphiques et du matériel de chronométrage.

Si quelque chose dans la boucle de génération vidéo ne manquait qu'une seule échéance, tout l'affichage aurait un problème, ce qui serait intolérable, même si c'était rare. Ce serait un système défectueux et vous le rapporteriez à la boutique pour un remboursement. C'est donc difficile en temps réel.

Évidemment, 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 sont tombés en panne », mais rarement« le soleil a explosé »).

Et n'oublions pas qu'il y a parfois une condition de fonctionnement implicite "pendant que quelqu'un regarde". Si personne ne vous voit enfreindre les règles (ou s'ils l'ont fait mais qu'ils meurent du feu avant de le dire à personne), et que personne ne peut prouver que vous avez enfreint les règles après coup, alors c'est un peu la même chose que si vous n'enfreigniez jamais les règles!

Le moyen le plus simple de distinguer les différents types de types de systèmes en temps réel est de répondre à la question:

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

Ainsi, en fonction de la réponse que vous obtenez à 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 le non-respect 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 par exemple réagit avec 1 seconde de retard, les conséquences pourraient être mortelles et il ne sera d'aucune utilité d'avoir le sac gonflé une fois que la voiture s'est déjà écrasée.

2. Ferme : Non, mais les 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. À titre d'exemple simple, considérons un système de cryptage vidéo. Normalement, le mot de passe de cryptage est généré dans le serveur (tête de réseau vidéo) et envoyé au décodeur client. Ce processus doit être synchronisé afin que normalement le décodeur reçoive le mot de passeavant de commencer à recevoir les images 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 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 trames cryptées avec le même ont déjà causé les problèmes.

3. 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 qu'obtenir une réponse du système en dehors du délai est toujours utile pour l'utilisateur final, mais son utilité se dégrade après avoir atteint 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 pour lire les capteurs de température, il sera un peu lent à réagir en cas de brusques changements de température. Cependant, à la fin, il finira par réagir au changement et ajuster 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.

Un temps réel doux est le plus simple à 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 certaines 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 invalide, nous disons simplement que les performances du système n'étaient pas à la hauteur (le système a donné de faibles performances!).

Dans un système en 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 d'un robot effectuant un travail comme le traçage de lignes, etc. Si un obstacle vient sur son chemin et que le robot ne traite pas cette information dans un délai programmé (presque instantané!), Le robot est réputé avoir échoué dans sa tâche (le système du robot peut également être complètement détruit!).

Dans un système en temps réel d'entreprise , si le résultat de l'exécution du processus arrive 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 ennemie ou pour une 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 arrive, le paquet actuel (celui qui a manqué la date limite) n'a pas d'importance si le traitement a été terminé (ou à moitié ou presque terminé) est abandonné / rejeté. Mais l'ordinateur au sol n'est pas considéré comme ayant complètement échoué.

Pour définir «temps réel souple», il est plus facile de le comparer avec «temps réel dur». Ci-dessous, nous verrons que le terme «temps réel ferme» constitue un malentendu à propos de «temps réel doux».

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) qui peut être lié à sa devise 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 du «temps réel dur», 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 satisfaisante de l'événement où 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 dur font l'hypothèse très forte que tout ce qui concerne l'application, le système et l'environnement est statique et connu a 'priori - par exemple, quelles tâches, qu'elles sont périodiques, leurs heures d'arrivée, leurs périodes, leurs délais, qu'elles ont gagné 'pas de conflits de ressources, et globalement l'évolution temporelle du système. Dans un système de commande 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 toutes les échéances soient respectées.

Ce modèle mental est délibérément et très utilement assez général pour englober à la fois dur et mou 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 ne respectent les délais
• ou aucune tâche n'est plus de 20% en retard
• 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 de cas logiciels en temps réel dans de nombreuses applications.

Envisagez l'application d'une tâche unique consistant à aller chercher votre enfant après l'école. Cela n'a probablement pas de date limite réelle, mais il y a une valeur pour vous et votre enfant en fonction du moment où cet événement a lieu. Trop tôt gaspille des ressources (comme votre temps) et trop tard a une certaine valeur négative parce que votre enfant pourrait être laissé seul et potentiellement en danger (ou du moins incommodé).

Contrairement au cas spécial statique en temps réel dur, le temps réel souple ne fait que le minimum d'hypothèses spécifiques à l'application nécessaires concernant 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 et le temps pour le faire est dynamique en fonction de la météo, des conditions de circulation, etc. Vous pourriez être tenté de sur-approvisionner votre système 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, en refusant peut-être 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 pour les manœuvres cibles. La satisfaction maximale pour terminer les tâches de mise à jour du cours est obtenue par une frappe destructrice directe sur la cible. Mais une tentative de surapprovisionnement en 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 serez peut-être moins mais suffisamment satisfait si le missile frappe suffisamment près de la cible pour la désactiver.

De toute évidence, 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 en temps réel doux sont également très courants 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 obtenir une valeur acceptable.

La clé de voûte des systèmes en temps réel est la «prévisibilité». Le cas dur en temps réel ne s'intéresse qu'à un seul cas particulier de prévisibilité - c'est-à-dire que les tâches respecteront toutes leurs échéances et que la valeur maximale possible sera atteinte par cet événement. Ce cas particulier est appelé «déterministe».

Il existe un spectre de prévisibilité. Le déterminisme (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étrique et les points finaux du spectre doivent être interprétés en fonction d'un modèle de prévisibilité choisi; tout entre ces deux points extrêmes est 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 souples) ont une prévisibilité non déterministe, par exemple, des temps d'achèvement des tâches et donc des valeurs tirées de ces événements.

En général (en théorie), la prévisibilité, et donc la valeur acceptable de manière acceptable, peut être rendue aussi proche que nécessaire du point final déterministe - mais à un prix qui peut être physiquement impossible ou excessivement cher (comme au combat ou peut-être même en aller chercher votre enfant à 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 d'un modèle de prévisibilité pour raisonner sur les latences d'événements et les valeurs résultantes.

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

• la probabilité qu'aucune tâche ne rate 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, étant donné qu'en combat, l'attaque a toujours l'avantage sur la défense, lequel de ces deux scénarios de calcul en temps réel préférez-vous:

• parce que la destruction parfaite de tous les missiles hostiles est très improbable ou impossible, affectez vos ressources défensives pour maximiser la probabilité qu'autant de missiles hostiles parmi les plus menaçants (par exemple, en fonction de leurs cibles) soient interceptés avec succès (l'interception rapprochée compte car elle peut déplacer le missile hostile hors de sa trajectoire);

• se plaindre que ce n'est pas un problème informatique en temps réel car il est dynamique au lieu de 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, donc cela ne vous intéresse pas .

Malgré les divers malentendus sur le temps réel doux dans la communauté informatique en temps réel, le temps réel doux est très général et puissant, bien que potentiellement complexe par rapport au temps réel dur. Les systèmes en temps réel doux tels que 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 en temps réel dur peut fournir des garanties déterministes - le plus souvent que toutes les tâches respecteront leurs délais, l'interruption ou le temps de réponse à l'appel système sera toujours inférieur à x, etc. - SI ET UNIQUEMENT SI des hypothèses très fortes 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 durs sont un problème de recherche ouvert sauf pour des cas assez simples)

Un système en temps réel souple n'offre pas de garanties déterministes, il est destiné à fournir la meilleure opportunité probabiliste et la meilleure prévisibilité de l'actualité, spécifiées et accomplies de manière analytique, qui soient réalisables dans les circonstances dynamiques actuelles, selon des critères spécifiques à l'application.

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

«Firm real-time» est un cas particulier mal défini de «soft real-time». Il n'est pas nécessaire d'utiliser ce terme si le terme «temps réel logiciel» est compris et utilisé correctement.

J'ai une discussion plus détaillée beaucoup plus précise du temps réel, du temps réel dur, du temps réel doux, de la prévisibilité, du déterminisme et des sujets connexes sur mon site web real-time.org.

temps réel - Se rapportant à un système ou à un 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 opportun 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 par l'IEEE (Institute of Electrical and Electronics Engineers).

Considérez 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 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 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?

Le temps réel est difficile car si la réponse est en retard, des données peuvent être perdues.

Considérez 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 petite gigue limitée, mais parfois d'autres tâches dans l'aide auditive entraînent un retard de certaines données, provoquant une impulsion de bruit sur le haut-parleur. Ce système est-il dur, ferme ou souple 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 inoffensif et n'altère pas significativement la qualité de l'expérience.

Considérez 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 traite cet événement, il envoie plus de données à l'imprimante. Ce système est-il dur, ferme ou souple en temps réel?

C'est un temps réel doux car plus il répond rapidement, 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

Peut-être que la définition est fautive.

D'après mon expérience, je séparerais les deux en fonction 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 collez 300 ms de code et le système n'est pas cassé, il n'a pas été développé. Vous serez remplacé avant d'avoir terminé. 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 peut être considéré comme souple . Si vous manquez de temps, vous pourriez espérer moins de charge la prochaine fois, vous pouvez régler 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 UX n'est pas utile. Une Skoda pourrait ne pas être cassée en cas de problème, mais une BMW le sera certainement.

La définition s'est élargie au fil des ans au détriment du terme. Ce que l'on appelle maintenant le temps réel "dur" est ce que l'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 unilatéraux) entraîneraient des données incorrectes ou un comportement incorrect devraient être considérés en temps réel. Les systèmes sans cette caractéristique seraient considérés comme non en temps réel.

Cela ne veut pas dire que le temps n'a pas d'intérêt dans les systèmes non temps réel, cela signifie simplement que les exigences de synchronisation dans de tels systèmes n'entraînent pas des résultats fondamentalement incorrects.

Les systèmes en temps réel dur utilisent une version préemptive de la planification prioritaire, de sorte que les tâches critiques soient immédiatement planifiées, tandis que les systèmes en temps réel doux utilisent une version non préemptive de la planification prioritaire, ce qui permet à la tâche actuelle d'être terminée avant que le contrôle ne soit transféré à la priorité supérieure tâche, entraînant des retards supplémentaires. Ainsi, les délais des tâches sont suivis de manière critique dans les systèmes temps réel dur, alors que dans les systèmes temps réel doux, ils ne sont pas traités si sérieusement.