Réponse rapide
On teste un serveur d’action indisponible en simulant absence, redémarrage, délai et reprise, puis en vérifiant que le client ne laisse pas le robot poursuivre sans supervision. Le résultat attendu doit rester explicite dans chaque cas.
Provoquer les pannes
Le serveur est arrêté avant l’acceptation, pendant l’exécution et juste avant le résultat. Le réseau peut aussi retarder ou dupliquer des messages afin d’exposer les hypothèses du client.
Définir un état local sûr
Le client applique un délai, arrête de renvoyer des objectifs et demande une reprise contrôlée. Le serveur, lorsqu’il revient, ne reprend pas automatiquement une mission dont l’état physique est inconnu.
Vérifier les traces
Journaux, états moteur et capteurs sont comparés pour confirmer que l’interface logicielle correspond au comportement réel. Les critères d’échec et de reprise sont testés sur le matériel représentatif.
Le silence du serveur n’est pas un arrêt
Un client qui ne reçoit plus de message ne sait pas si le robot est immobile, en mouvement ou bloqué. Une stratégie locale de limitation et une voie d’arrêt indépendante sont nécessaires lorsque la mission présente un danger.
Sources et références
- [1] Interfaces: topics, services and actions — ROS 2 — Open Robotics