Réponse rapide
Versionner l’architecture logicielle d’un robot permet de relier composants, interfaces, dépendances, configuration, matériel, règles et tests à un comportement observé. Une évolution peut modifier délai, autorité ou repli même si le code fonctionnel semble inchangé. Version active, compatibilité, approbation et retour arrière sont donc conservés ensemble.
Figer le système et ses variantes
Diagrammes, manifests, images, pilotes, paramètres, firmware, modèles et certificats sont identifiés par version. Les interfaces et migrations possèdent une compatibilité déclarée. Une configuration précédente est restaurable avec son environnement.
Déployer et comparer progressivement
Simulation, banc, canari et fenêtre contrôlée mesurent latence, charge, énergie, défauts, qualité et sécurité. Journaux attribuent chaque événement à la version active. Une divergence bloque la généralisation et permet le retour.
Ne pas versionner le code en oubliant les paramètres
Calibration, seuil, carte, dépendance ou pilote peuvent changer le comportement sans modification du module. Un numéro de build incomplet empêche l’audit. Toute mise à jour doit être intégrale, signée et réversible.
Sources et références
- [1] Robotics communications safety — NIST