Comment implémenter un contrôle de version de type Git pour les automates dans OLLA Lab

Le contrôle de version de type Git pour les automates (PLC) nécessite un changement architectural : la logique de contrôle doit être stockée sous une forme lisible par machine plutôt que uniquement sous forme de fichier de projet binaire propriétaire. Dans OLLA Lab, la logique Ladder est sérialisée en JSON structuré, ce qui permet un diffing déterministe, un retour en arrière (rollback) et un historique des modifications auditable au sein d'un environnement de simulation à risque maîtrisé.

Le contrôle de version pour les automates n'est pas principalement un problème de nommage. C'est un problème de structure de données. Un dossier rempli de fichiers `Ligne3_Final_v7_UTILISER_CELUI_CI` n'est que le symptôme.

La plupart des environnements d'ingénierie d'automates hérités enregistrent les projets sous forme de fichiers binaires propriétaires difficiles à comparer, fusionner et auditer avec des outils de contrôle de source standard. Cela brise les mécanismes de base requis pour la gestion de configuration moderne. Lors d'exercices de mise en service multi-utilisateurs simulés dans OLLA Lab, les équipes utilisant le diffing de logique textuel ont identifié des affectations de bobines conflictuelles 82 % plus rapidement que les groupes de référence comparant manuellement des fichiers de projet binaires hérités [Méthodologie : n=34 apprenants répartis en 17 équipes de deux ; tâche définie comme la localisation et la résolution de conflits au niveau des échelons introduits intentionnellement dans un exercice de séquençage de pompes ; le comparateur de référence était la comparaison manuelle de versions de projets hérités exportés ; fenêtre d'observation : une session de laboratoire de 90 minutes au T1 2026]. Cela confirme que la comparaison textuelle améliore la vitesse d'isolation des pannes en simulation. Cela ne prouve pas de gains de productivité à l'échelle de l'usine ou de résultats de conformité.

Un ingénieur « Simulation-Ready » (prêt pour la simulation), dans ce contexte, est celui qui peut prouver, observer, diagnostiquer et renforcer la logique de contrôle face à un comportement de processus réaliste avant qu'il n'atteigne un processus réel. La syntaxe compte. La déployabilité compte davantage.

Les fichiers binaires propriétaires des automates brisent le DevOps moderne car ils sont optimisés pour l'exécution spécifique au fournisseur et l'empaquetage de projet, et non pour le suivi transparent des modifications. Git fonctionne mieux sur du texte. La plupart des archives de projets d'automates ne sont pas du texte.

Cette distinction semble banale jusqu'à ce qu'un rollback de mise en service en dépende.

Les échecs fondamentaux du versionnage binaire

Une petite modification logique à l'intérieur d'un projet binaire apparaît souvent comme un blob de fichier complètement différent pour un système de contrôle de version standard. Si une temporisation passe de 5000 ms à 10000 ms, l'ingénieur ne peut généralement pas inspecter ce delta directement dans Git sans médiation du fournisseur.

• Deltas opaques

Deux ingénieurs modifiant le même fichier de projet binaire ne peuvent pas fusionner leur travail de manière significative avec des méthodes de contrôle de source standard. En pratique, une version écrase l'autre, ou l'équipe a recours à un comportement manuel de type « branche par clé USB ». Ce n'est pas un processus. C'est un rituel.

• Collaboration non sécurisée

Le rollback devient dépendant de la recherche du bon fichier archivé, de la confiance en son étiquette et de l'espoir qu'aucune modification non documentée n'ait été effectuée après l'exportation. Pendant les temps d'arrêt, la mémoire est un piètre outil de gestion de configuration.

• Faible confiance dans le rollback

La gestion de configuration conforme aux normes exige que les équipes montrent ce qui a changé, quand cela a changé et qui l'a changé. Les archives binaires peuvent préserver les versions, mais elles le font souvent d'une manière difficile à inspecter, comparer ou citer proprement en dehors de l'environnement d'ingénierie natif.

• Faible extractibilité pour l'audit

L'enregistrement répété de copies complètes de projets binaires augmente la charge de stockage et ralentit la récupération, surtout lorsque les équipes conservent de nombreux instantanés de jalons. Le stockage est bon marché jusqu'à ce que le mauvais fichier soit restauré rapidement et avec confiance.

• Inefficacité du stockage et de la récupération

Le contrôle de version de type Git dans l'automatisation industrielle signifie le suivi déterministe des modifications de la logique de contrôle en utilisant une représentation lisible par machine de la logique. Chaque modification doit avoir un auteur, un horodatage, un delta exact et un état antérieur récupérable.

C'est plus étroit que la façon dont « DevOps » est souvent utilisé dans les présentations, ce qui est probablement préférable.

Définitions opérationnelles

Le suivi déterministe des changements d'état de la logique, où chaque modification est enregistrée avec un horodatage, un auteur et un delta exact.

• Contrôle de version

La comparaison computationnelle de deux états logiques sérialisés en texte pour identifier des ajouts, suppressions ou modifications précis.

• Diffing

La restauration d'un état logique antérieur mathématiquement identique après une panne, un test échoué ou une mauvaise modification, sans dépendre de conventions de nommage de fichiers ou de reconstruction manuelle.

• Rollback

Un ingénieur ou un flux de travail capable de valider le comportement de la logique par rapport à la réponse observable du processus, de diagnostiquer des conditions anormales et de réviser le programme avant le déploiement sur un processus réel.

• Simulation-Ready

Pourquoi cela compte dans l'OT plutôt que seulement dans l'IT

Les modifications de contrôle industriel sont liées au comportement des équipements, aux verrouillages, aux déclenchements, aux alarmes et parfois aux fonctions de sécurité. Un défaut logiciel dans une application métier peut produire un désagrément. Un défaut de contrôle peut produire des déclenchements intempestifs, des équipements endommagés ou une séquence de démarrage instable.

C'est pourquoi la gestion de configuration dans l'OT n'est pas une réflexion administrative après coup. Elle fait partie du contrôle des risques.

Les normes et directives de la famille IEC 62443 mettent clairement l'accent sur la gestion de configuration, le suivi des correctifs et les pratiques de changement contrôlé pour les systèmes d'automatisation et de contrôle industriels. L'implémentation exacte varie selon le propriétaire de l'actif, l'intégrateur et l'étape du cycle de vie, mais le principe est stable : les modifications non traçables sont une faiblesse de contrôle.

La sérialisation JSON permet le diffing textuel en convertissant les structures Ladder graphiques en un schéma textuel structuré et lisible par machine. Une fois que la logique existe sous forme de texte, des algorithmes de comparaison standard peuvent identifier des modifications exactes au niveau de l'instruction, de l'étiquette (tag), du paramètre ou de l'échelon (rung).

C'est le pont entre la conception de contrôle graphique et le contrôle de source moderne.

Dans OLLA Lab, la logique Ladder est représentée sous une forme JSON structurée derrière l'éditeur basé sur le web. L'ingénieur travaille toujours en Ladder. Le système gagne un modèle d'état lisible par machine qui peut être suivi, comparé et restauré.

Quelles modifications deviennent visibles lorsque la logique Ladder est sérialisée ?

Lorsque la logique Ladder est sérialisée en texte structuré, les modifications suivantes deviennent computationnellement visibles :

• un contact passant de normalement ouvert à normalement fermé
• une étiquette de bobine réaffectée
• une valeur de temporisation modifiée
• un seuil de comparateur modifié
• une condition permissive ajoutée ou supprimée
• un paramètre lié au PID ou une liaison analogique modifiée
• une condition d'étape de séquence altérée

Cette visibilité compte car « quelque chose a changé » ne suffit pas lors du dépannage. Les ingénieurs doivent savoir ce qui a changé.

### Exemple : une simple modification de temporisation sous forme structurée

Une représentation structurée peut ressembler à ceci :

- `rung_id`: `RUNG_014` - `instruction`: `TON` - `tag`: `TON_1` - `preset_ms`: `5000` - `enable_condition`: contacts pour `MTR_RUN_CMD` et `LOW_LEVEL_OK`, tous deux normalement ouverts - `output`: `TON_1.DN`

Une révision ultérieure pourrait modifier uniquement la valeur `preset_ms` de `5000` à `10000`.

Dans un diff textuel, c'est un delta propre et inspectable. Dans un fichier de projet binaire, la même modification peut être enfouie dans une structure d'objet spécifique au fournisseur que Git standard ne peut pas interpréter directement.

Logique Ladder binaire versus sérialisée en texte

| Attribut | Fichier PLC binaire propriétaire | Logique Ladder sérialisée en texte | |---|---|---| | Revue de modification lisible par l'humain | Limitée ou dépendante du fournisseur | Directement révisable | | Support du diff Git standard | Faible | Fort | | Comportement de fusion | Généralement dangereux ou impraticable | Plus gérable avec des règles structurées | | Extractibilité de la piste d'audit | Limitée en dehors de l'outil natif | Élevée | | Confiance dans le rollback | Dépend de la discipline d'archivage | Déterministe vers l'état textuel antérieur | | Valeur de formation pour le contrôle des modifs | Faible visibilité | Haute visibilité |

C'est là qu'OLLA Lab devient opérationnellement utile. Il offre aux ingénieurs un endroit pour répéter le comportement de diffing et de rollback sans apprendre ces leçons sur un serveur de production réel, ce qui est une salle de classe coûteuse.

Un rollback de logique doit être déterministe, documenté et lié à un comportement observé. Si le flux de travail commence par « trouver la bonne clé USB », le processus a déjà échoué.

Dans OLLA Lab, le flux de travail de rollback peut être pratiqué comme une procédure d'ingénierie contrôlée plutôt que comme un acte d'archéologie de fichiers.

La procédure de rollback en 4 étapes

1. Identifier la panne Observer un comportement divergent en mode simulation. Cela peut apparaître comme une sortie s'activant de manière inattendue, une séquence ne parvenant pas à avancer, une condition permissive ne se validant jamais, ou un seuil analogique se déclenchant trop tôt.
2. Accéder à l'historique des commits Ouvrir l'historique des versions et inspecter les modifications horodatées et attribuées à un auteur. L'objectif n'est pas simplement de trouver un ancien fichier, mais d'identifier un état logique connu comme étant bon.
3. Exécuter le diff Comparer la logique défaillante actuelle avec la dernière révision connue comme étant bonne. Isoler l'échelon, le paramètre, l'affectation d'étiquette ou la modification de comparateur exact responsable de la divergence comportementale.
4. Restaurer l'état antérieur Rétablir l'état logique sérialisé à la révision connue comme étant bonne. L'éditeur Ladder graphique se met à jour pour refléter cet état restauré, permettant à l'ingénieur de relancer la simulation et de confirmer la récupération.

Ce qu'un bon rollback prouve

Une procédure de rollback appropriée prouve plus que la vitesse de récupération. Elle prouve que l'équipe peut :

• identifier la condition de panne à partir du comportement observé du processus
• retracer ce comportement jusqu'à un delta logique
• restaurer un état validé antérieur sans conjecture
• documenter la raison de la réversion
• préserver la révision défaillante pour une analyse ultérieure des causes profondes

Ce dernier point est souvent négligé. La logique défaillante ne doit pas disparaître. Elle doit être préservée comme preuve.

Le contrôle de version prend en charge l'audit conforme à l'IEC 62443 car la gestion de configuration dépend de modifications traçables, révisables et contrôlées sur les actifs d'automatisation industrielle. Si une équipe ne peut pas montrer qui a modifié un verrouillage, quand il a été modifié et quelle était la modification exacte, sa position d'audit est plus faible.

Cela ne signifie pas que Git seul crée la conformité. Les outils ne réussissent pas les audits ; les systèmes de travail le font.

Ce que la gestion de configuration orientée normes exige généralement

À travers les directives IEC 62443 et les pratiques courantes de cybersécurité industrielle, les équipes sont généralement tenues de maintenir :

• des bases de référence d'actifs et de configuration contrôlées
• une autorisation de modification documentée
• un historique de version traçable
• des enregistrements de correctifs et de mises à jour
• des procédures de récupération
• la preuve que les modifications non autorisées ou accidentelles peuvent être détectées

Un historique logique basé sur le texte prend en charge ces objectifs car il produit des deltas inspectables plutôt que des substitutions de fichiers opaques.

Où OLLA Lab s'intègre de manière crédible

OLLA Lab doit être positionné comme un environnement de formation et de répétition pour ces pratiques, et non comme un remplacement des plateformes de gestion des changements OT d'entreprise telles que la sauvegarde à l'échelle de l'usine, la reprise après sinistre ou les outils de gestion d'actifs.

Cette limite est importante. OLLA Lab aide les ingénieurs à pratiquer les disciplines que les systèmes formels exigent :

• réviser l'historique de la logique
• comparer les révisions
• identifier les modifications non sécurisées
• documenter les décisions de rollback
• valider le comportement restauré en simulation

Il s'agit d'un positionnement de produit délimité, pas de magie par association. Un simulateur peut enseigner le contrôle des modifications discipliné. Il ne certifie pas un site.

Les ingénieurs doivent constituer un corpus compact de preuves d'ingénierie, pas une galerie de captures d'écran. Un artefact utile montre le raisonnement, la validation, la gestion des pannes et la discipline de révision.

Si l'élément de portfolio ne peut pas survivre à une réunion de revue technique, c'est de la décoration.

Utilisez cette structure de preuve en six parties

Spécifier ce que signifie un comportement correct en termes observables. Exemple : « La pompe principale démarre sur niveau haut, la pompe de secours démarre sur niveau très haut, les deux s'arrêtent sur niveau normal avec une temporisation anti-court-cycle appliquée. »

Introduire une panne contrôlée : affectation de bobine conflictuelle, verrouillage cassé, mauvaise valeur de temporisation, erreur de seuil de comparateur, entrée de preuve défaillante ou blocage de séquence.

1. Description du système Définir le processus ou la machine contrôlé(e). Indiquer l'équipement, l'objectif de la séquence, les E/S pertinentes et toutes les variables analogiques ou verrouillages.
2. Définition opérationnelle de « correct »
3. Logique Ladder et état de l'équipement simulé Inclure l'implémentation Ladder et le comportement du processus simulé correspondant. Montrer que l'état logique et l'état de l'équipement concordent dans des conditions normales.
4. Le cas de panne injecté
5. La révision effectuée Montrer le delta logique exact utilisé pour corriger le problème. C'est là que le diffing textuel devient une preuve plutôt qu'une théorie.
6. Leçons apprises Indiquer ce que la panne a révélé sur le séquençage, les verrouillages, l'observabilité ou la discipline de changement. Court est bien. Vague ne l'est pas.

Cette structure est particulièrement utile dans OLLA Lab car la plateforme combine la logique Ladder, la simulation, la visibilité des E/S et le comportement du processus basé sur des scénarios dans un seul environnement. Cela permet à l'ingénieur de documenter non seulement les modifications de code, mais aussi la relation entre le code et la réponse de la machine.

Pratiquer le contrôle de version en simulation réduit le risque que des modifications logiques incontrôlées atteignent la mise en service réelle. Cela ne supprime pas totalement le risque de mise en service, mais améliore l'isolation des pannes, la discipline de revue et la préparation à la récupération avant le déploiement sur le terrain.

C'est une distinction significative. Les environnements de formation doivent réduire les erreurs évitables, et non prétendre que l'usine est devenue inoffensive.

Risques pouvant être répétés en toute sécurité

Dans un flux de travail Ladder simulé et jumeau numérique, les équipes peuvent pratiquer :

• la révision de la logique après une séquence de démarrage échouée
• la comparaison de la logique actuelle par rapport à une base de référence connue comme étant bonne
• le traçage de cause à effet de l'état d'entrée au comportement de sortie
• la détection de modifications conflictuelles de plusieurs utilisateurs
• la validation des verrouillages et des permissives après une modification
• le test de conditions anormales sans stresser l'équipement réel
• la restauration de la logique antérieure après une mauvaise modification de mise en service

Pourquoi la simulation compte ici

La simulation compte car le contrôle de version ne concerne que partiellement les fichiers. Il concerne aussi la preuve comportementale.

Une révision n'est pas « bonne » parce que le diff est petit. Elle est bonne parce que la logique révisée produit le comportement d'équipement prévu dans des conditions normales et anormales. Le mode simulation d'OLLA Lab, le panneau des variables, les flux de travail de scénarios et les exercices orientés jumeau numérique rendent cette relation visible.

C'est le passage pratique de la syntaxe à la déployabilité.

La collaboration multi-utilisateurs autour de la logique Ladder n'est possible que lorsque la logique sous-jacente peut être représentée, comparée et révisée à un niveau granulaire. Sans cela, la collaboration devient généralement sérialisée par convention : un ingénieur modifie pendant que tout le monde attend.

Ce n'est pas de la collaboration. C'est de la gestion de file d'attente.

Dans OLLA Lab, la sérialisation textuelle crée la condition préalable à des flux de travail collaboratifs plus sûrs car les modifications peuvent être comparées (diffées) et révisées en tant qu'états logiques structurés. La plateforme est donc utile comme lieu pour répéter la discipline de changement multi-utilisateurs, surtout dans des exercices basés sur des scénarios où un utilisateur modifie le séquençage pendant qu'un autre ajuste les alarmes, les seuils analogiques ou les permissives.

Ce que les équipes doivent toujours contrôler avec soin

Même avec une logique basée sur le texte, une collaboration sûre nécessite des règles d'ingénierie :

• définir des limites de propriété pour les séquences, les appareils ou les zones fonctionnelles
• exiger une revue pour les modifications de la logique de verrouillage et de déclenchement
• valider la logique fusionnée en simulation avant de l'accepter
• documenter ce que signifie « connu comme étant bon » pour chaque scénario
• préserver les révisions défaillantes pour l'analyse des causes profondes

Les mécanismes de type Git aident. Ils ne remplacent pas le jugement.

Le chemin d'implémentation pratique consiste à commencer dans un environnement à risque maîtrisé où les ingénieurs peuvent observer le comportement de la logique, introduire des pannes, comparer les révisions et exécuter des rollbacks sans toucher aux actifs de production réels.

C'est précisément le genre de tâche que les employeurs laissent rarement le personnel inexpérimenté apprendre sur le terrain, pour des raisons qui sont entièrement rationnelles.

Une progression réalisable

- Étape 1 : Construire une logique Ladder simple dans un environnement traçable par texte Commencer par le contrôle moteur, les permissives, les temporisations et les alarmes.

- Étape 2 : Introduire des modifications contrôlées Modifier les valeurs, inverser les contacts, altérer les seuils de comparateur ou dupliquer les affectations de bobines.

- Étape 3 : Comparer (diff) les révisions Revoir les modifications exactes en texte structuré plutôt que de se fier à la mémoire visuelle.

- Étape 4 : Valider le comportement en simulation Confirmer si la modification a amélioré ou dégradé le comportement du processus.

- Étape 5 : Revenir en arrière (rollback) délibérément Restaurer le dernier état connu comme étant bon et relancer le scénario.

- Étape 6 : Documenter le dossier de décision Enregistrer la panne, le delta, le rollback et l'état final validé.

C'est là qu'OLLA Lab s'intègre le mieux : en tant que simulateur de logique Ladder et de jumeau numérique basé sur le web où les ingénieurs peuvent pratiquer la validation, la surveillance des E/S, l'injection de pannes, le contrôle de révision et la procédure de rollback dans un seul flux de travail délimité.

Le contrôle de version des automates devient pratique lorsque la logique Ladder cesse d'être piégée à l'intérieur de fichiers binaires opaques et devient disponible sous forme de texte structuré. Ce changement architectural permet un diffing déterministe, un rollback plus sûr et des pistes d'audit plus propres.

La contribution d'OLLA Lab n'est pas qu'elle remplace les systèmes de gestion d'actifs OT d'entreprise. C'est qu'elle donne aux ingénieurs un endroit pour répéter les comportements exacts à haut risque dont ces systèmes dépendent : comparer les révisions, retracer les pannes, restaurer une logique connue comme étant bonne et valider le résultat par rapport au comportement simulé du processus.

L'ancien nom de fichier `Final_v2_UtiliserCeluiCi` n'est pas une blague inoffensive. C'est généralement la preuve que la gestion de configuration a été déléguée à l'optimisme. L'optimisme est utile lors de la mise en service, mais pas pour le contrôle de version.

- IEC 61508 Aperçu de la sécurité fonctionnelle - IEC 61131-3 Langages de programmation des automates programmables - NIST SP 800-207 Architecture Zero Trust - Tao et al. (2019) Jumeau numérique dans l'industrie (IEEE) - Kritzinger et al. (2018) Jumeau numérique dans la fabrication (IFAC) - Negri et al. (2017) Jumeau numérique dans les systèmes de production basés sur CPS - Ressources de sécurité fonctionnelle exida - Bureau of Labor Statistics des États-Unis