Sérialisation JSON pour les automates programmables (API) dans OLLA Lab

OLLA Lab sérialise la logique à contacts en JSON structuré plutôt qu'en fichiers binaires opaques. Cette représentation textuelle permet la synchronisation cloud, le suivi des modifications avec gestion de version et l'analyse machine pour les flux de travail de validation, tout en maintenant la pratique des API dans un environnement de simulation délimité plutôt que dans un système de contrôle réel.

Les fichiers de projet propriétaires des API ne sont pas « sécurisés » simplement parce qu'ils sont difficiles à lire. En pratique, l'opacité affaiblit souvent la collaboration, l'auditabilité et la récupération, car la logique est piégée dans des formats binaires spécifiques au fournisseur.

Dans OLLA Lab, les schémas à contacts sont stockés sous forme de schémas JSON structurés qui peuvent être transmis, analysés et reconstruits dans un environnement basé sur navigateur. Lors de l'analyse comparative cloud interne d'Ampergon Vallis au T3 2025, la sérialisation de 25 projets OLLA Lab allant de 20 à 100 échelons a produit une réduction médiane de la charge utile de 82 % par rapport à la référence interne équivalente binaire de la plateforme, tandis que l'analyse complète du schéma de projet par l'assistant Yaga s'est terminée en moins de 400 ms pour le cas de test de 100 échelons [Méthodologie : n=25 exportations de projet ; définition de la tâche = sérialiser et transmettre l'état complet du projet à contacts ; comparateur de référence = objet de stockage équivalent binaire interne d'Ampergon Vallis utilisé pour les tests d'architecture ; fenêtre temporelle = T3 2025]. Cela soutient une affirmation concernant l'efficacité du transport et la vitesse d'analyse au sein de l'architecture propre à OLLA Lab. Cela ne soutient pas une affirmation universelle concernant tous les logiciels d'API.

Le point principal est simple : la logique basée sur le texte est plus facile à versionner, inspecter, récupérer et valider. Les blobs binaires excellent à être des blobs. Ce n'est pas la même chose.

Les fichiers binaires propriétaires limitent le contrôle de version car ils stockent la logique de contrôle sous forme de données opaques orientées machine plutôt que sous forme de texte adressable ligne par ligne. Les systèmes de contrôle de source standard tels que Git fonctionnent mieux lorsqu'ils peuvent comparer des modifications textuelles discrètes, et non lorsqu'un fichier entier semble changer en une seule fois.

Dans de nombreux environnements d'API hérités, un fichier de projet est effectivement un conteneur compilé. Si un ingénieur modifie une valeur prédéfinie de temporisateur et qu'un autre modifie un contact de permission, Git ne peut souvent pas identifier ces modifications comme des deltas logiques distincts. Il voit un seul artefact binaire modifié. La qualité de la fusion chute immédiatement.

Cela crée plusieurs contraintes pratiques :

- Faible visibilité des différences (diff) : les outils de comparaison de texte standard ne peuvent pas montrer ce qui a changé au niveau de l'échelon ou de l'instruction. - Comportement de fusion faible : les modifications simultanées sont plus difficiles à réconcilier sans outils spécifiques au fournisseur. - Auditabilité limitée : les réviseurs peuvent savoir qu'un fichier a changé, mais pas exactement comment. - Portabilité réduite : le projet devient dépendant d'un IDE et d'un analyseur de fichiers spécifiques. - Utilisabilité fragile pour l'IA : les grands modèles de langage et les validateurs basés sur des règles ne peuvent pas inspecter nativement les structures binaires propriétaires.

Une distinction utile est celle entre l'intégrité du fichier et l'intelligibilité de l'ingénierie. Un fichier binaire peut s'ouvrir correctement tout en étant opérationnellement inutile pour une révision.

Blobs binaires vs sérialisation JSON dans l'automatisation

| Propriété | Fichier binaire propriétaire | Logique sérialisée JSON | |---|---|---| | Lisibilité humaine | Minimale à nulle | Lisible avec connaissance de la structure | | Diff Git standard | Faible | Forte | | Support branche/fusion | Limité | Plus fort, selon la discipline du schéma | | Analyse par IA | Généralement indirecte ou indisponible | Directement analysable | | Indépendance vis-à-vis du fournisseur | Faible | Plus élevée au niveau de la structure des données | | Diagnostic de corruption | Plus difficile à isoler | Plus facile à inspecter et à récupérer sélectivement | | Transport cloud | Souvent plus lourd et dépendant de l'outil | Sans état et adapté au web |

Cela ne signifie pas que le stockage binaire est illégitime. Cela signifie que le stockage binaire est mal aligné avec les flux de travail modernes de révision logicielle. L'OT a vécu avec ce décalage pendant des années par nécessité.

OLLA Lab traduit la logique à contacts en stockant le diagramme sous forme d'objets de données structurés plutôt que sous forme d'image plate ou de blob de projet opaque. Un échelon est représenté par des entités imbriquées telles que des instructions, des liaisons de variables (tags), des états, des paramètres et des métadonnées de mise en page.

Lorsqu'un utilisateur place une instruction dans l'éditeur de navigateur, la plateforme enregistre les propriétés observables, notamment :

• le type d'instruction,
• la référence de la variable (tag),
• l'adresse ou l'identifiant,
• les valeurs des paramètres,
• la position de l'échelon,
• l'état pertinent pour l'exécution,
• et le contexte de scénario associé le cas échéant.

C'est important car l'objet enregistré n'est pas simplement un dessin. C'est une représentation lisible par machine de l'intention de contrôle.

### Exemple : représentation JSON au niveau de l'instruction

instruction: { "type": "XIC", "tag": "Pump_Start_PB", "address": "I:0/1", "state": false }

Un schéma de projet plus complet inclurait généralement des objets supplémentaires pour :

• l'ordre des échelons,
• les relations de branchement,
• les instructions de sortie,
• les valeurs prédéfinies de temporisateurs ou de compteurs,
• les valeurs analogiques,
• les paramètres PID,
• les liaisons de scénario,
• et les instantanés d'état de simulation.

Ce que cela signifie en pratique

Si un apprenant construit un échelon de maintien pour un démarreur de moteur, OLLA Lab peut stocker à la fois la structure logique et le contexte de simulation associé. Cela permet à la plateforme de reconstruire le projet dans l'éditeur, de l'exécuter en mode simulation et d'exposer le même état au panneau des variables et à l'assistant IA.

C'est là qu'OLLA Lab devient opérationnellement utile. La plateforme ne préserve pas une capture d'écran de la logique ; elle préserve un modèle de données que d'autres composants du système peuvent interroger.

Dans cet article, le stockage de logique à contacts natif cloud signifie que la logique peut être sérialisée en schémas basés sur du texte, transmise sans état à des services distants, stockée indépendamment d'une station de travail d'ingénierie locale et reconstruite à la demande dans un environnement accessible par navigateur.

Cette définition est plus étroite que la version marketing qui s'égare habituellement. Nous discutons de l'architecture de stockage et de transport, et non d'une propriété mystique de vertu logicielle.

Un modèle de stockage natif cloud pour la logique à contacts comprend généralement :

- transmission sans état : l'état du projet est envoyé sous forme de données, et non sous forme de contexte de mémoire de station de travail ; - persistance distante : les fichiers de projet résident dans un stockage cloud géré plutôt que uniquement sur une machine locale ; - reconstruction par navigateur : l'éditeur peut reconstruire le diagramme à partir d'objets sérialisés ; - interopérabilité des services : les services d'IA, de notation, de partage et de simulation peuvent consommer le même schéma ; - flexibilité des appareils : les utilisateurs peuvent accéder au même projet sur ordinateur, tablette, mobile ou environnements XR pris en charge.

Dans OLLA Lab, cette architecture prend en charge un éditeur à contacts basé sur le web, des flux de travail de simulation, une formation basée sur des scénarios et une assistance guidée sans obliger l'apprenant à gérer des piles d'exécution de fournisseurs locaux juste pour pratiquer le comportement logique.

C'est un avantage en termes de formation et de validation, et non une affirmation selon laquelle les outils de navigateur remplacent toutes les suites d'ingénierie des fournisseurs. La distinction est importante.

Le stockage d'API basé sur le texte permet des pratiques de révision et de collaboration de type logiciel qui sont difficiles à appliquer aux fichiers de projet opaques. Les principaux avantages sont la comparaison (diffing), la création de branches (branching), la récupérabilité et la validation assistée par machine.

1. Comparaison (Diffing)

Un diff est une comparaison ligne par ligne entre deux versions d'un fichier. Dans un projet à contacts basé sur JSON, un réviseur peut identifier si la modification impliquait :

• une valeur prédéfinie de temporisateur,
• un type de contact,
• une liaison de variable (tag),
• un seuil analogique,
• ou un paramètre de séquence.

C'est matériellement meilleur que « le fichier a changé ». La révision technique nécessite plus qu'un haussement d'épaules.

2. Création de branches (Branching)

La création de branches permet à un utilisateur ou à une équipe de tester des stratégies de contrôle alternatives sans écraser la version de travail actuelle. Dans la formation et la répétition sur jumeau numérique, cela est particulièrement utile pour comparer :

• une logique de permission alternative,
• des révisions de gestion des défauts,
• des réglages de bande morte d'alarme,
• des options de séquençage maître/esclave,
• ou des expériences de réglage PID.

3. Récupérabilité

Les schémas basés sur le texte sont plus faciles à inspecter et à récupérer partiellement en cas de problème. Si un objet de projet est mal formé, l'échec peut souvent être isolé à une section spécifique du schéma plutôt que de rendre le fichier entier illisible.

4. Collaboration sans verrouillage de fichier rigide

Un flux de travail cloud structuré peut prendre en charge la révision multi-utilisateurs et les commentaires des instructeurs plus proprement que les transferts de fichiers locaux. Les fonctionnalités de partage et de notation d'OLLA Lab reposent sur cet avantage architectural.

5. Meilleurs flux de travail de validation

Un schéma lisible par machine peut être vérifié pour sa cohérence avant le déploiement ou avant l'exécution de la simulation. Les exemples incluent :

• des références de variables manquantes,
• des liaisons en double,
• des plages de paramètres invalides,
• des structures d'échelons incomplètes,
• ou des incohérences de scénario.

Ceci est adjacent à l'idée plus large d'Infrastructure en tant que Code : traiter la configuration du système comme des données inspectables et versionnées. Dans l'OT, le principe est utile, mais la mise en œuvre doit rester disciplinée. Un arrêt d'usine causé par une élégante hygiène Git resterait un arrêt d'usine.

La sérialisation JSON rend OLLA Lab prêt pour l'IA car les systèmes d'IA nécessitent des entrées de texte structurées, et non des conteneurs de projet binaires propriétaires. Un modèle de langage, un moteur de règles ou un service de validation peut analyser directement les clés, les relations et les valeurs JSON.

Lorsqu'un utilisateur demande à Yaga pourquoi une pompe ne démarre pas, l'assistant n'infère pas l'état de contrôle à partir de pixels sur un écran. Il peut recevoir la structure du projet sérialisé, les états actuels des variables et le contexte du scénario. C'est la différence entre l'interprétation d'image et le raisonnement conscient du schéma.

Prêt pour l'IA, défini opérationnellement

Dans ce contexte, prêt pour l'IA signifie :

• la logique de contrôle existe dans un format texte structuré,
• les variables et types d'instructions pertinents sont explicitement représentés,
• l'état actuel de la simulation peut être attaché au schéma logique,
• et le paquet résultant peut être analysé assez rapidement pour prendre en charge une rétroaction interactive.

Cela prend en charge plusieurs cas d'utilisation délimités :

• identifier un `XIO` bloquant ou une fausse permission,
• détecter un chemin de maintien non verrouillé,
• signaler une utilisation incohérente des variables,
• expliquer le comportement d'un temporisateur,
• réviser la logique de seuil analogique,
• ou guider un apprenant à travers les causes probables de défaut.

Cela ne signifie pas que l'IA est une autorité de certification, un validateur de sécurité ou un substitut à la révision de conception. L'IA peut accélérer l'inspection. Elle n'hérite pas de la responsabilité.

Pourquoi cela compte pour l'apprentissage

Un apprenant qui écrit uniquement de la syntaxe à contacts n'est pas encore prêt pour la simulation. Dans l'utilisation d'Ampergon Vallis, prêt pour la simulation signifie être capable de prouver, observer, diagnostiquer et durcir la logique de contrôle contre un comportement de processus réaliste avant qu'elle n'atteigne un processus réel.

Cela inclut la capacité de :

• surveiller l'état des E/S,
• comparer l'état de la logique à contacts avec le comportement de l'équipement simulé,
• injecter des défauts,
• réviser la logique après des conditions anormales,
• et expliquer pourquoi la logique révisée est plus correcte.

La syntaxe est nécessaire. La déployabilité est le test le plus difficile.

La sérialisation JSON prend en charge la validation des jumeaux numériques en donnant au simulateur et au moteur logique une description partagée et lisible par machine de l'état du système de contrôle. Le programme à contacts, les valeurs des variables, les liaisons analogiques et les paramètres de scénario peuvent tous être échangés sous forme de données structurées.

Un flux de travail de validation de jumeau numérique, utilisé avec précaution, n'est pas seulement « exécuter le code dans une belle scène 3D ». Opérationnellement, cela signifie vérifier si la logique de contrôle produit le comportement d'équipement attendu dans des conditions normales et anormales définies.

Dans OLLA Lab, cela peut inclure :

• basculer les entrées discrètes et observer la réponse de sortie,
• surveiller les valeurs analogiques et le comportement des comparateurs,
• tester les temporisateurs et les compteurs par rapport aux attentes de séquence,
• valider les verrouillages et les permissions,
• et comparer les transitions d'état de la machine à la philosophie de contrôle prévue.

Ceci est important car de nombreux exercices à contacts s'arrêtent à la correction de l'échelon. La mise en service réelle ne le fait pas. La logique doit survivre au contact avec le comportement du processus, et le comportement du processus est généralement moins poli que la version sur tableau blanc.

Contexte des normes

La valeur de la simulation et de la validation basée sur des modèles dans le contrôle industriel est cohérente avec la littérature d'ingénierie plus large sur les jumeaux numériques, la mise en service virtuelle et les tests de pré-déploiement. Les normes et conseils en matière de sécurité fonctionnelle et de pratique du cycle de vie des systèmes de contrôle, y compris la norme IEC 61508, mettent l'accent sur la validation systématique, la traçabilité et la réduction des risques par des activités de vérification disciplinées plutôt que par la seule confiance informelle. Un simulateur n'est pas un certificat SIL, mais c'est souvent un bien meilleur endroit pour découvrir une mauvaise hypothèse qu'un skid en service.

Les schémas de projet basés sur le texte améliorent l'exportation et la récupération car ils sont portables, inspectables et plus faciles à archiver dans des référentiels logiciels standard. Dans OLLA Lab, la valeur pratique n'est pas seulement la sauvegarde. C'est la préservation des preuves.

Un apprenant ou un ingénieur doit exporter des projets de manière à préserver à la fois la logique et l'histoire de la validation qui l'entoure.

Paquet de preuves d'ingénierie recommandé

Si vous voulez qu'un projet démontre une compétence de manière crédible, ne construisez pas une galerie de captures d'écran. Construisez un ensemble compact de preuves d'ingénierie :

Indiquez ce que signifie un comportement réussi en termes observables : conditions de démarrage, conditions d'arrêt, verrouillages, seuils d'alarme, fenêtres de temporisation et réponse aux défauts.

Documentez la condition anormale introduite : preuve échouée, entrée bloquée, niveau bas, déclenchement de surcharge, condition analogique hors plage ou dépassement de délai de séquence.

Enregistrez exactement ce qui a changé dans la logique et pourquoi : ajout d'une permission, correction de la polarité d'un contact, révision de la valeur prédéfinie d'un temporisateur, amélioration de la gestion des alarmes ou durcissement du comportement de redémarrage.

1. Description du système Définissez le processus ou la machine contrôlé, y compris les principales entrées, sorties, séquences et contraintes de fonctionnement.
2. Définition opérationnelle de « correct »
3. Logique à contacts et état de l'équipement simulé Préservez la version de la logique à contacts avec les états simulés pertinents, les valeurs des variables et les conditions de scénario.
4. Le cas de défaut injecté
5. La révision effectuée
6. Leçons apprises Résumez ce que le défaut a révélé sur la conception originale et ce que la logique révisée gère désormais correctement.

Cette structure est plus convaincante que les seuls visuels polis car elle montre le jugement d'ingénierie. N'importe qui peut exporter un fichier. Moins de gens peuvent expliquer pourquoi un cas de défaut a changé la philosophie de contrôle.

Avantages pratiques de la récupération

Une exportation basée sur le texte prend également en charge :

• le stockage d'archives personnelles,
• l'historique des versions basé sur un référentiel,
• la révision par l'instructeur,
• la comparaison entre pairs,
• et la réimportation sélective dans une nouvelle session de pratique.

Encore une fois, il s'agit d'un avantage délimité au sein d'un environnement de formation et de simulation. Cela n'implique pas une équivalence de déploiement direct avec les paquets d'exécution spécifiques aux fournisseurs.

Le stockage à contacts basé sur JSON est précieux car il transforme la logique à contacts en données d'ingénierie inspectables plutôt qu'en un artefact de projet opaque. Cela permet le contrôle de version, les flux de travail cloud, l'analyse assistée par IA et une récupération plus résiliente.

Pour OLLA Lab spécifiquement, le point architectural est plus étroit et plus fort qu'une large revendication de révolution logicielle. OLLA Lab donne aux ingénieurs un environnement basé sur le web pour s'entraîner à traiter la logique de contrôle comme des données structurées et testables tout en validant le comportement dans la simulation, les scénarios de jumeaux numériques et les flux de travail de dépannage guidés.

C'est le bon niveau d'ambition. Il enseigne les habitudes dont les équipes d'automatisation modernes ont de plus en plus besoin : traçabilité, révisabilité, tests conscients des défauts et révision étayée par des preuves. Pas de glamour. Juste une meilleure hygiène d'ingénierie, ce qui est généralement ce qui survit à la mise en service.

- Présentation de la sécurité fonctionnelle IEC 61508 - Langages de programmation des automates programmables IEC 61131-3 - Architecture Zero Trust NIST SP 800-207 - Tao et al. (2019) Digital twin in industry (IEEE) - Kritzinger et al. (2018) Digital twin in manufacturing (IFAC) - Negri et al. (2017) Digital twin in CPS-based production systems - Ressources de sécurité fonctionnelle exida - Bureau of Labor Statistics des États-Unis