Quels sont les éléments essentiels de la distribué des systèmes en temps réel?

un système distribué en temps réel compose deux ensembles de propriétés difficiles qui sont imposées par le domaine de problème ou le domaine de solution (ou les deux.)

distribué

Un distribué système de liens d'un certain nombre de independent computing entités ayant des propriétés locales par le biais d'un mécanisme de communication. En conséquence, les algorithmes et autres composants de conception doivent tenir compte du synchronie et du modèle de défaillance . Un résumé utile (qui n'est pas entièrement objectif) des préoccupations en matière de calcul distribué est inclus dans de Deutsch, "Eight Fallacies of Distributed Computing . (Voir cette exposition utile .) Tous ces éléments sont utiles à prendre en compte dans la conception distribuée (en temps réel); chacun constitue un point de départ pour essentiel de la conception et de la mise en œuvre de préoccupations:

1. le réseau est fiable
2. latence is zero
3. bande passante infinie
4. le réseau est sécurisé
5. la topologie ne change pas
6. il y a un administrateur
7. le coût du Transport est zéro
8. le réseau est homogène

Temps Réel

Un en temps réel est un système dans lequel la rapidité d'exécution de l'opération d'achèvement est une partie des exigences fonctionnelles et de l'exactitude de mesure du système. (J'ai ouvert un alors question ici pour essayer de clarifier cela.) En réalité, presque tous les systèmes peuvent être considérés comme "doux" en temps réel, qu'il y a généralement tacite exigences/attentes pour la rapidité des opérations. Nous nous réservons le temps réel terme, parfois qualifié par soft ou hard , pour les systèmes qui sont incorrect lorsque les contraintes de temps ne sont pas respectées. Notez que beaucoup de préoccupations résumées dans les erreurs ci-dessus se croisent avec l'actualité. (Voir aussi la étiquette en temps réel wiki )

il est utile de noter que les systèmes RT (et DRT) existent sur un continuum d'exigences, avec "déterministe" (ou conventionnellement, "151970920 dur" en temps réel ) à une extrémité. Cependant, de nombreux systèmes ont des contraintes de temps très importantes qui sont néanmoins non déterministes. En particulier dans le contexte des systèmes de DRT, il est également utile de séparer la notion d'activité urgence de l'activité priorité . Dans les grands systèmes où la latence et la défaillance sont des facteurs réels et non triviaux, la gestion explicite de l'informatique et les ressources de communication nécessaires pour mettre en œuvre les délais et d'autres exigences de conception deviennent de plus en plus importantes, et la séparation de ces deux dimensions devient importante.

composition distribuée en temps réel

• Explicite délais - Quelles sont les exigences, comment sont-ils mappés à des activités, sont-ils de vrais trans-nœud délais, comment les contraintes de temps, être représentée explicitement dans la conception et la mise en œuvre, et comment les défaillances seront-elles détectées, signalées et récupérées?
• time synchronization - quelles sont les exigences et les mécanismes pour réaliser la synchronisation de l'horloge? Wiki sur clock synchronization ; de nombreuses applications ne nécessitent que NTP ; des exigences plus strictes peuvent nécessiter un matériel spécial (par exemple, IRIG-B ) ou des approches.
• Synchrony requirements - quelles sont les hypothèses et les exigences en matière de synchronisation du système? Ceci est connecté à la synchronisation de l'horloge, mais pas identique. Quelques réflexions sur les modèles formels de Doug Jensen ; wikipedia sur système asynchrone et synchrone ; SO question on partial event ordering ;
• Design patterns - quelles sont les pièces mobiles, et comment sont-elles liées au cours du transport? (En particulier, comment ces relations d'incidence sur l'actualité?)
• Middleware - Comment allez-vous encoder les aspects distribués du système? Par exemple, CORBA en temps réel (voici une bonne page de OIS ) ou DDS .
• Time Contraintes - Comment allez-vous documenter, mesurer et appliquer les contraintes de temps dans le système?
• panne partielle -un système en temps réel a généralement des exigences de fiabilité. L'un des aspects uniques des systèmes distribués est la possibilité de classes entières de défaillances appelées défaillances "partielles", dues soit à de véritables défaillances de crash/comms, soit à des erreurs de ponctualité qui doivent être traitées comme des défaillances. donc question sur approches de basculement ;
• MSR - Ce système d'exploitation temps réel(s)?

quelques références

pour une présentation assez traditionnelle des systèmes DRT, jetez un oeil à kopetz' book . Pour une vue plus dynamique, les travaux de Jensen et son site Web sont recommandés . Dans le domaine de Java, je suggère de lire le excellent "Introduction à la fiabilité de la Programmation Distribuée" . Il ne traite pas de l'ensemble des questions liées à l'actualité, mais il aborde les échecs partiels d'une manière particulièrement claire.

récemment, le concept de détecteurs de défaillance (peu fiables) est apparu comme une construction synchrone utile, permettant un raisonnement théorique utile et des techniques pratiques de formulation/conception/construction pour les systèmes de DRT. Le livre séminal sur le sujet Sur l'impact de l'échec rapide de détecteurs en temps réel à tolérance de pannes des systèmes de , par Aguilera, Le Lann, et Toueg. Ce papier est une lourde luge, mais récompense chaque once d'investissement intellectuel.