Réponse rapide
Une fonction de sécurité ne doit pas dépendre d’un seul nœud applicatif, d’un topic non garanti ou d’un superviseur saturable. L’architecture sépare détection, décision d’arrêt, énergie et réarmement selon l’analyse de risques, avec interfaces surveillées et contrôleur indépendant si nécessaire. ROS 2 facilite les échanges, mais ne remplace pas cette séparation.
Définir frontières et états sûrs
Les nœuds applicatifs publient état et intention ; une chaîne dédiée valide présence, vitesse, zone et défauts critiques. Timeouts, permissions, horloges et réaction à la déconnexion sont explicites. Une sortie matérielle ou un contrôleur indépendant ne dépend pas de la planification générale.
Éprouver les pannes de la pile
Les tests injectent CPU saturé, message périmé, nœud arrêté, réseau coupé, horloge incohérente et redémarrage. Le robot doit atteindre un état sûr, informer l’opérateur et supprimer les commandes résiduelles. Profils QoS, versions et paramètres sont figés pour comparer les campagnes.
Éviter le nœud de sécurité de façade
Appeler un module « safety » ou filtrer une commande dans un script ne constitue pas une fonction validée. Dépendances, privilèges, accès réseau et voies de sortie sont audités. Paquet, distribution ou configuration modifiés déclenchent analyse d’impact et requalification.
Sources et références
- [1] Nodes — ROS 2 documentation