Réponse rapide
Une architecture centralisée simplifie parfois cohérence et supervision, mais concentre calcul, réseau et points de panne. Une architecture distribuée rapproche traitement et capteurs et peut continuer localement, au prix de synchronisation, contrats et diagnostic plus exigeants. Le choix se fait sur latence, bande passante, énergie, criticité, maintenance et comportement en mode dégradé.
Répartir les responsabilités
Perception, planification, commande et sécurité sont placées selon leurs délais et contraintes. Une boucle critique ne dépend pas d’un réseau non déterministe, tandis qu’un calcul lourd peut être séparé avec résultat horodaté et expirant. Chaque module décrit état, version, qualité et réaction à la déconnexion.
Éprouver les communications
Les essais injectent latence, perte, duplication, désordre et redémarrage d’un nœud. Le robot doit maintenir une action sûre, s’arrêter ou transférer la responsabilité sans commandes concurrentes. Les journaux corrèlent horloges et identifiants pour distinguer défaut réseau et défaut de calcul.
Ne pas confondre nombre de nœuds et tolérance
Répartir un service ne supprime pas sa dépendance si un module central reste indispensable à l’arrêt. Interfaces, compatibilités et versions sont testées ensemble. La tolérance à panne est démontrée par scénario, pas déduite d’un schéma d’architecture.
Sources et références
- [1] Robotics and Autonomous Systems — NIST