Différences entre temps réel dur, temps réel doux et temps réel ferme?
j'ai lu les définitions pour les différentes notions de temps réel , et les exemples fournis pour les systèmes en temps réel dur et doux me semblent sensés. Mais, il n'y a pas d'explication réelle ou d'exemple d'un système de temps réel ferme. Selon le lien ci-dessus:
Firm: les dépassements de délais peu fréquents sont tolérables, mais ils peuvent nuire à la qualité du service du système. L'utilité d'un résultat est zéro après sa date d'échéance.
Est-il une distinction claire entre la ferme en temps réel vs rigide ou souple, en temps réel, et est-il un bon exemple qui illustre cette distinction?
dans les commentaires, Charles a demandé que je soumette des wikis de tags pour les nouvelles tags. L'exemple d'un" système d'entreprise en temps réel "que j'ai fourni pour l'étiquette d'entreprise en temps réel était un système de service de lait. Si le système délivre du lait après sa date d'expiration, 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, j'ai formé dans ma tête quand j'ai lu la définition. Je cherche un bien meilleur exemple, et peut-être une meilleure définition de entreprise en temps réel qui améliorera ma notion de celui-ci.
11 réponses
dur temps réel signifie que vous devez absolument frapper chaque date limite. Très peu de systèmes ont cette exigence. On peut citer 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 en temps réel fermes/souples peuvent ne pas respecter certaines échéances, mais la performance finira par se dégrader si trop de systèmes ne sont pas respectés. Un bon exemple est le système audio de votre ordinateur. Si vous manquez quelques morceaux, pas grand chose, mais miss trop et tu vas finir par dégrader le système. Similaire serait capteurs sismiques. Si vous manquez quelques points de données, pas grand chose, mais vous devez attraper la plupart d'entre eux pour donner un sens aux données. Plus important encore, personne ne va mourir si elles ne fonctionnent pas correctement.
la ligne est floue, parce que même un pacemaker peut être éteint d'une petite quantité 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 vraiment de division, mais on le sait quand on le sent.
le hard real-time definition considère tout délai manqué comme une défaillance du système. Ce calendrier est largement utilisé dans les systèmes essentiels à la mission où le non-respect des contraintes temporelles entraîne des pertes de vie ou de biens.
exemples:
-
le vol 447 d'Air France s'est écrasé dans l'océan après un dysfonctionnement du capteur causé une série d'erreurs dans le système. Les pilotes ont décroché alors qu'ils répondaient à des lectures d'instruments désuètes. Les 12 membres d'équipage et les 216 passagers ont été tués.
-
la sonde Mars Pathfinder a été presque perdue lorsqu'une inversion de priorité a provoqué le redémarrage du système. Une tâche plus prioritaire n'a pas été exécutée à temps parce qu'elle était bloquée par une tâche moins prioritaire. Le problème a été corrigé et le vaisseau s'est posé réussi.
-
une imprimante à jet d'encre est dotée d'une tête d'impression dotée d'un logiciel de contrôle permettant de déposer la quantité d'encre correcte sur une partie spécifique du papier. Si une date limite n'est pas respectée, le travail d'impression est ruiné.
Entreprise En Temps Réel
la définition firm real-time tient compte des délais rarement manqués. Dans ces applications le système peut survivre aux échecs de tâche aussi longtemps qu'ils sont convenablement espacés, cependant la valeur de l'achèvement de la tâche tombe à zéro ou devient impossible.
exemples:
-
systèmes de fabrication avec lignes d'assemblage de robots où le fait de ne pas respecter une date limite entraîne un assemblage inadéquat d'une pièce. Tant que les pièces ruinées sont assez rares pour être attrapées par la qualité contrôle et pas trop coûteux, puis la production se poursuit.
-
un boîtier de décodage numérique décode les horodateurs lorsque les images doivent apparaître à l'écran. Étant donné que les délais sont fonction des commandes, le non-respect de la date limite cause des problèmes, ce qui diminue la qualité du service. Si le cadre manqué devient disponible plus tard, il ne causera plus de jitter pour l'afficher, donc il est inutile. Le spectateur peut encore apprécier le programme si jitter ne se produit pas trop souvent.
Soft Real-Time
la définition soft real-time permet des délais souvent 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 achevées peuvent avoir une valeur croissante jusqu'à la date limite et une valeur décroissante au-delà de celle-ci.
exemples:
-
les stations météorologiques ont de nombreux capteurs pour 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. Même si un capteur de lecture peut être précoce ou tardive par rapport aux autres, il peut encore être pertinent tant qu'il est assez proche.
-
une console de jeu vidéo exécute un logiciel pour un moteur de jeu. Il y a beaucoup de les 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 joue correctement. Tant que les tâches sont tout à fait relativement à l'heure le jeu sera agréable, et si non il ne peut être un peu en retard.
Siewert: des Systèmes Temps Réel Embarqués et des Composants.
Liu & Layland: Algorithmes d'Ordonnancement pour Multiprogramming dans un Dur en Temps Réel de l'Environnement.
Marchand & Silly-Chetto: Ordonnancement Dynamique de Doux Apériodique les Tâches et les Tâches Périodiques avec des 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 Dur système en temps réel , si le système ne respecte pas la date limite, même une fois que le système est considéré comme ayant Échoué.
2> Pour un Cabinet de système en temps réel , même si le système ne respecte pas le délai, éventuellement plusieurs fois (c'est à dire pour des demandes multiples), le système est pas considéré comme un échec. Aussi, les réponses pour les demandes (réponses à une requête, le résultat d'un travail, etc.) sont sans valeur une fois passé le délai pour cette demande particulière ( l'utilité d'un résultat est zéro après son délai ). Un exemple hypothétique peut être un système de prévision des tempêtes (si une tempête est prévue avant son arrivée, alors le système a fait son travail, la prévision après que l'événement a déjà eu lieu ou quand il se produit est sans valeur).
3> Pour un Soft real-time system , même si le système ne respecte pas le délai, éventuellement plusieurs fois (c'est à dire pour des demandes multiples), le système n'est pas considéré comme un échec. Mais, dans ce cas, les résultats des demandes ne sont pas sans valeur valeur pour un résultat après sa date limite , n'est pas zéro , plutôt il se dégrade que le temps passe après la date limite. Par exemple. Streaming audio-vidéo.
ici est un lien vers une ressource qui a été très utile.
il est populaire d'associer une grande catastrophe à la définition de dur en temps réel, mais ce n'est pas pertinent. Tout échec à répondre à une contrainte dure 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 à la définition.
entreprise et soft tout simplement ne pas être automatiquement déclaré cassé à défaut de respecter un délai unique.
pour un bon exemple de dur en temps réel, à partir de la page que vous avez liée:
les premiers systèmes de jeux vidéo tels que Atari 2600 et Cinematronics vector graphics avaient des besoins difficiles en temps réel en raison de la nature des graphiques et du matériel de synchronisation.
si quelque chose dans la boucle de génération de vidéo a manqué juste une date butoir unique alors l'ensemble de l'affichage serait un bug, ce qui serait intolérable, même si elle était rare. Ce serait un système cassé et vous prendriez de retour au magasin pour un remboursement. Il est donc difficile en temps réel.
évidemment, n'importe quel système peut être soumis à des situations qu'il ne peut pas gérer, il est donc nécessaire de restreindre la définition à être dans les conditions d'exploitation prévues -- notant que dans les applications critiques pour la sécurité, les gens doivent planifier pour des conditions terribles ("le liquide de refroidissement s'est évaporé", "les freins ont échoué", mais rarement "le soleil a explosé").
et n'oublions pas que parfois il y a un "pendant que quelqu'un regarde" implicite. Si personne ne vous voit enfreindre les règles (ou s'ils l'ont fait mais ils meurent le feu avant de le dire à quelqu'un), et personne ne peut prouver que vous avez enfreint les règles après le fait, alors c'est un peu la même chose que si vous n'avez jamais enfreint les règles!
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:
est-ce qu'une réponse du système retardée (après la date limite) est encore utile ou non?
ainsi, selon la réponse que vous obtenez pour cette question, votre système pourrait être inclus dans l'une des catégories suivantes:
- Dur : Non, et le retard de les réponses sont considérées comme une défaillance du système
C'est le cas lorsque l'absence de ligne de temps rendra le système inutilisable. Par exemple, le système de commande du système de coussin gonflable de la voiture devrait détecter la collision et gonfler rapidement le sac. L'ensemble du processus prend plus ou moins d'un vingt-cinquième de seconde. Donc, si le système par exemple réagir avec 1 seconde de retard, les conséquences pourraient être mortel et il sera d'aucune utilité d'avoir le sac gonflé une fois la voiture a déjà en panne.
- entreprise : Non, mais des réponses différées ne sont pas nécessaires une défaillance du système
C'est le cas lorsque manque la date limite est tolérable, mais il aura une incidence sur la qualité du service. Comme un exemple simple considèrent un système de cryptage Vidéo. Normalement, le mot de passe de cryptage est généré dans le serveur (tête de ligne vidéo) et envoyé au client set-top box. Ce processus doit être synchronisé de sorte que normalement la boîte de dialogue reçoit le mot de passe avant de commencer à recevoir les cadres vidéo cryptés. Dans ce cas, un retard peut conduire à des problèmes de vidéo puisque la boîte de décodage n'est pas capable de décoder les images parce qu'elle 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 puisque les cadres cryptés avec la même chose ont déjà causé les problèmes.
- Soft : Oui, mais le service du système est dégradé
D'après la description Wikipédia l'utilité d'un résultat se dégrade après sa date limite . Cela signifie qu'obtenir une réponse du système hors délai est toujours utile pour l'utilisateur final, mais son utilité se détériore après avoir atteint le délai. Un simple exemple de 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 un certain retard à lire les capteurs de température, il sera un peu lent à réagir en cas de changements brusques de température. Cependant, à la fin il va réagir au changement et d'ajuster en conséquence la température de la garder constante par exemple. Donc dans ce cas la réaction retardée est utile, mais elle dégrade la qualité du système de service.
Un doux "en temps réel 151920920" est plus facile à comprendre, même si le résultat est obtenu après la date limite, les résultats sont encore considérées comme valables.
exemple: navigateur Web - nous demandons certaines URL, il faut un certain temps pour charger la page. 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 la performance du système n'était pas jusqu'à la marque (le système a donné de faibles performances!).
Dans dur "en temps réel 151920920" système", si le résultat est obtenu après la date limite, le système est considéré comme ayant échoué complètement.
exemple: dans le cas d'un robot faisant un certain travail comme le traçage de ligne, 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 dit ont échoué dans leur tâche (le système de robot peut aussi être complètement détruit!).
Dans "151910920 ferme" en temps réel système", si le résultat de l'exécution du processus qui vient après la date limite, nous ignorer que le résultat, mais le système n'est pas appelé à avoir été omis.
exemple: communication par Satellite pour la surveillance des positions ennemies ou pour une autre tâche. Si la station d'informatique au sol à laquelle les satellites envoient les cadres sont périodiquement surchargés, et le cadre courant (paquet) n'est pas traité à temps et le prochain cadre arrive, le paquet courant (celui qui a manqué la date limite) n'a pas d'importance si le traitement a été fait (ou à moitié fait ou presque) est abandonné/jeté. Mais l'ordinateur au sol n'est pas appelé pour avoir complètement échoué.
Pour définir le "temps réel souple," il est plus facile de comparer avec "dur en temps réel."Ci-dessous nous allons voir que le terme "entreprise en temps réel" constitue un malentendu à propos de "temps réel souple."
parler de façon désinvolte, 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
"151900920 • * si, ou dans la mesure où, il leur est manifeste avec un retard (latence) qui peut être lié à sa perception monnaie "151900920 • * c'est-à-dire dans un délai où l'information ou l'événement a une valeur acceptable pour eux.il existe de nombreuses définitions ad hoc de" dur en temps réel", mais dans ce modèle mental, dur en temps réel est représenté par le terme" si". Plus précisément, en présumant que les actions en temps réel (comme 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 se limite au cas spécial où toutes les tâches sont terminées. les tâches respectent les délais.
Dur en temps réel des systèmes, les très fortes présomptions que tout au sujet de l'application et du système et de l'environnement est statique et connu un " a priori-par exemple, les tâches, qu'elles sont périodiques, leurs heures d'arrivée, de leurs règles, de leurs échéances, qu'ils n'ont pas de conflits de ressources, et dans l'ensemble le temps de l'évolution du système. Dans le cas d'un système de commandes de vol d'un aéronef ou d'un système de freinage d'automobile et dans bien d'autres cas, ces hypothèses peuvent généralement être satisfaites pour que tous les délais seront respectés.
Ce modèle mental est délibérément et très utilement assez général pour englober à la fois hard et soft en temps réel--soft est accommodé par la phrase" dans la mesure où". Par exemple, supposons que l'événement d'achèvement des tâches ait une valeur sous-optimale mais acceptable si
- pas plus de 10% des tâches ne respectent pas leurs délais
- ou aucune tâche est plus de 20% tardy
- ou le retard moyen de toutes les tâches n'est pas plus de 15%
- ou le retard maximal parmi toutes les tâches est inférieur à 10%
ce sont tous des exemples communs de cas doux en temps réel dans un grand nombre d'applications.
envisagez l'application mono-tâche de prendre votre enfant après l'école. Qui n'a probablement pas d'une date limite, au lieu de cela, il est important pour vous et votre enfant basé sur le 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 au moins incommodé).
contrairement au cas spécial statique hard real-time, soft real-time ne fait que le minimum nécessaire des hypothèses spécifiques à l'application concernant les tâches et le système, et des incertitudes sont attendues. Pour récupérer votre enfant, vous devez conduire à l'école, et le temps de le faire est dynamique en fonction des conditions météorologiques, des conditions de circulation, etc. Vous pourriez être tenté de surapprovisionner votre système (c.-à-d. permettre ce que vous espérez être le pire cas de temps de conduite), mais encore une fois, c'est gaspiller des ressources (votre temps, et occuper le véhicule familial, peut-être en niant 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érer d'autres exemples. Tous les systèmes de combat militaire sont soft en temps réel. Pour par exemple, envisagez d'effectuer une attaque aérienne sur un véhicule terrestre hostile à l'aide d'un missile guidé avec des mises à jour de celui-ci comme manœuvres de la cible. La satisfaction maximale pour accomplir les tâches de mise à jour de cours est atteinte par une frappe destructive directe sur la cible. Mais une tentative à disposition des ressources pour s'assurer de ce résultat est généralement beaucoup trop cher, et peut-être même impossible. Dans ce cas, vous pourriez être moins mais suffisamment satisfait si le missile frappe assez près de la cible pour le désactiver.
de toute évidence, les scénarios de combat comportent un grand nombre d'incertitudes dynamiques qui doivent être prises en compte par la gestion des ressources. Les systèmes souples en temps réel sont également très répandus dans de nombreux systèmes civils, tels que l'automatisation industrielle, bien qu'il soit évident que les systèmes militaires sont 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 dur en temps réel case 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 d'ici là. 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 la prévisibilité; l'autre point final est la prévisibilité minimale (non-déterminisme maximal). Le spectre métrique et les résultats doivent être interprétés en fonction d'un modèle de prévisibilité choisi; tout ce qui se situe entre ces deux résultats est un degré d'imprévisibilité (= degrés de non-déterminisme).
la plupart des systèmes en temps réel (c'est-à-dire 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 obtenues à partir de ces événements.
en général (en théorie), la prévisibilité, et donc la valeur satisfaisante acceptable, peut être faites aussi près 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 ramassant votre enfant à l'école).
temps réel Souple nécessite une application spécifique au choix d'un modèle de probabilité (et non du fréquentiste modèle), et donc la prévisibilité modèle pour raisonner sur les événements des latences et des valeurs qui en résulte.
renvoyant à la liste ci-dessus de événements qui fournissent une valeur acceptable, maintenant nous pouvons ajouter des cas non déterministes, tels que
- la probabilité qu'aucune tâche ne manquera son échéance de plus de 5% est supérieure à 0,87. (Notez le nombre de critères d'ordonnancement qui y sont exprimés.)
dans une application de défense antimissile, étant donné le fait qu'au combat l'attaque a toujours l'avantage sur la défense, lequel de ces deux scénarios de calcul en temps réel vous prefer:
-
parce que la destruction parfaite de tous les missiles hostiles est très improbable ou impossible, assignez vos ressources défensives pour maximiser la probabilité que le plus grand nombre des missiles hostiles les plus menaçants (par exemple, en fonction de leurs cibles) seront interceptés avec succès (l'interception étroite compte parce qu'elle peut déplacer le missile hostile hors trajectoire);
-
se plaignent que ce n'est pas un problème de calcul en temps réel parce qu'il est dynamique au lieu de statique, et les concepts et techniques en temps réel traditionnels ne s'appliquent pas, et il semble plus difficile que statique dur en temps réel, de sorte que vous n'êtes pas intéressé par elle.
malgré les divers malentendus sur soft real-time dans la communauté de l'informatique en temps réel, soft real-time est très générale et puissante, bien que potentiellement complexe par rapport à hard real-time. Systèmes souples en temps réel comme résumé ici ont une longue histoire réussie de l'utilisation en dehors du temps réel informatique communauté.
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 respecteront leurs délais, le temps d'interruption ou le temps de réponse de l'appel système sera toujours inférieur à x, etc.-SI ET SEULEMENT si des suppositions très fortes sont faites et sont correctes que tout ce que les choses sont statiques et connues a priori (en général, de telles garanties pour les systèmes durs en temps réel sont un problème de recherche ouvert à l'exception de cas assez simples)
Un soft du système en temps réel n'est pas déterministe garanties, il est destiné à fournir le meilleur possible analytiquement spécifié et réalisé probabiliste, la rapidité et la prévisibilité de l'actualité qu'il est possible, en vertu de l'actuelle dynamique des circonstances, selon l'application de critères spécifiques.
évidemment dur en temps réel est un simple cas spécial de temps réel doux. De toute évidence, les assurances analytiques non déterministes non déterministes de soft real-time peuvent être très complexes à fournir, mais elles sont obligatoires dans les cas les plus courants en temps réel (y compris les plus dangereux comme le combat) puisque la plupart des cas en temps réel sont dynamiques et non statiques.
Ferme "en temps réel" est mal définie et cas particulier de "temps réel souple."Il n'est pas nécessaire pour ce terme si le terme "temps réel doux" est compris et utilisé correctement.
j'ai une discussion plus détaillée beaucoup plus précise de temps réel, dur en temps réel, doux en temps réel, la prévisibilité, le 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 qu'un processus externe se produit, afin que les résultats du calcul puissent être utilisés pour contrôler le processus externe, le surveiller ou y répondre en temps opportun. [Norme IEEE 610.12.1990]
je sais que cette définition est ancienne, très ancienne. Je ne peux pas, cependant, trouver une définition plus récente par L'IEEE (Institute of Electrical and Electronics Engineers).
peut-être que la définition est fautive.
d'après mon expérience, je distinguerais les deux comme dépendant du matériel et du logiciel.
si vous avez 200ms pour gérer une interruption entraînée par le matériel, c'est ce que vous avez. Vous mettez 300ms de code dedans et le système n'est pas cassé, il n'a pas été développé. Vous serez mis à l'écart avant que vous avez terminé. Votre code ne fonctionne pas ou n'est pas adapté. De nombreux systèmes ont un traitement défini avec précision période. Vidéo, télécoms, etc.
si vous écrivez une application qui est en temps réel, cela pourrait être considéré doux . Si vous manquez de temps, vous pouvez espérer moins de charge 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.
pour le regarder d'un point de vue UX n'est pas utile. Une Skoda ne sera peut-être pas cassée si elle tombe en panne, mais une BMW le sera certainement.
La définition s'est élargie au fil des années, au détriment du terme. Ce qui est maintenant appelé "dur" temps réel est ce qui était simplement appelé temps réel. Ainsi, les systèmes dans lesquels des fenêtres de synchronisation manquantes (plutôt que des délais à Sens Unique) 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'est pas d'intérêt dans le non-temps réel systèmes, cela signifie simplement que les exigences de synchronisation dans de tels systèmes n'entraînent pas de résultats fondamentalement incorrects.
Envisager une tâche que les entrées de données à partir du port série. Lorsque de nouvelles données arrivent au 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 a 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 plus de données arrivent, les nouvelles données sont perdues. Ce système est-il dur, ferme ou mou en temps réel?
il est dur temps réel parce que si la réponse est tardive, les données peuvent être perdues.
Envisager une aide auditive que les entrées des sons à partir d'un microphone, manipule les données audio, puis renvoie les données vers un haut-parleur. Le système est habituellement doté d'un petit jitter, mais parfois d'autres tâches dans l'appareil auditif provoquent un retard de certaines données, ce qui provoque une impulsion de bruit sur le haut-parleur. Ce système est-il dur, ferme ou mou en temps réel?
Il est entreprise en temps réel parce qu'il 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.
Envisager une tâche qui affiche des données à une imprimante. Lorsque l'imprimante est en attente de 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 mou en temps réel?
Il est soft real time parce que plus il répond vite, mieux c'est, mais la valeur du système (la largeur de bande est la quantité de données imprimées par seconde) diminue avec la latence.
UTAustinX: UT.RTBN.12.01 X réseaux Bluetooth en temps réel