Comment préparer la logique API pour les audits de capacité systématique selon la norme CEI 61508 édition 3

Pour préparer la logique API aux audits de capacité systématique selon la norme CEI 61508 édition 3, les ingénieurs doivent fournir des preuves comportementales démontrant que le logiciel réagit de manière déterministe et sûre dans des conditions de défaillance définies. Un environnement de simulation tel que OLLA Lab peut être utilisé comme bac à sable de vérification délimité pour tester les propriétés de sécurité, documenter la gestion des défaillances et renforcer la logique avant l'audit formel et la validation physique.

La sécurité logicielle selon la CEI 61508 n'est pas principalement une question d'esthétique du code. Il s'agit de démontrer que la logique se comporte de manière correcte, reproductible et sûre lorsque le processus sort de son fonctionnement nominal.

Cette distinction est d'autant plus importante dans l'édition 3, où la charge de la preuve concernant le comportement systématique du logiciel devrait se durcir plutôt que de s'assouplir. L'analyse des défaillances matérielles repose toujours sur des mesures probabilistes telles que le PFD et le PFH. Un logiciel ne tombe pas en panne par usure ; il échoue systématiquement en raison d'erreurs de conception, de lacunes dans les spécifications, d'interactions imprévues et de cas limites non testés.

Une étude comparative interne récente d'Ampergon Vallis confirme ce point. Lors d'une analyse interne de 500 cas de test de fonctions instrumentées de sécurité (SIF) simulés dans OLLA Lab, 68 % des ébauches de logique initiale ont échoué à un test de robustesse lorsqu'elles ont été soumises à une dérive analogique, à un comportement d'entrée à état obsolète ou à un forçage hors plage [Méthodologie : n=500 tâches de validation SIF simulées sur des scénarios de pompes, convoyeurs, CVC et skid de processus ; comparateur de référence = ébauche de première passe avant révision ; fenêtre temporelle = janv.-fév. 2026]. Cela confirme que la logique de première intention omet souvent la gestion des états anormaux. Cela ne soutient aucune affirmation concernant les taux de défauts à l'échelle de l'industrie ou les résultats de conformité formels.

Le changement pratique réside dans une insistance accrue sur la preuve de la capacité systématique par des preuves reproductibles, et non par la simple affirmation du respect d'un cycle de vie.

La CEI 61508 a toujours traité le logiciel différemment du matériel, car les fautes logicielles sont systématiques plutôt qu'aléatoires. En pratique, cela signifie que les discussions de l'édition 3 se concentrent sur la capacité du processus de développement et de vérification à démontrer que les exigences de sécurité logicielle ont été traduites en un comportement contrôlé et testable. « Nous avons examiné le code attentivement » n'est pas une déclaration inutile, mais elle n'est plus suffisante.

Un second changement est l'attente croissante d'une intégration de l'assurance logicielle avec des préoccupations adjacentes telles que la cybersécurité, le contrôle de configuration et la discipline de la chaîne d'outils. Cela ne fusionne pas la CEI 61508 avec la CEI 62443, mais la séparation n'est plus aussi confortable que certaines équipes le souhaiteraient.

### Attentes logicielles : Édition 2 vs Édition 3

| Sujet | Accent de l'édition 2 | Orientation de l'édition 3 | |---|---|---| | Assurance logicielle | Respect du cycle de vie, discipline de revue, tests structurels | Preuves comportementales plus fortes, vérification reproductible, preuve testable par machine si possible | | Gestion des fautes | Souvent documentée sous forme narrative | Pression croissante pour des tests explicites d'états anormaux et des résultats traçables | | Support des outils | Utile mais non central | Plus important lorsque les outils améliorent la répétabilité, la traçabilité et la couverture des tests | | Relation cybersécurité | Souvent traitée séparément | Interaction plus explicite avec le développement sécurisé et l'intégrité du système | | Preuve de capacité systématique | Démonstration axée sur le processus | Processus plus preuve observable que la logique se comporte sûrement dans des cas limites définis |

La correction importante est la suivante : l'édition 3 ne signifie pas que le logiciel bénéficie désormais d'une formule magique comme le matériel. Cela signifie que les allégations logicielles doivent être étayées par des preuves plus solides.

La capacité systématique est la capacité démontrée du processus de développement et de la logique résultante à éviter, détecter et contrôler les fautes systématiques au niveau requis par la fonction de sécurité cible.

Pour les ingénieurs API, cette définition devient concrète lorsqu'elle est traduite en comportements observables :

• La logique de sécurité s'exécute de manière prévisible et délimitée.
• Les transitions d'état sont explicites et récupérables.
• Les fautes conduisent le système vers un état sûr défini.
• La logique non sécuritaire ne corrompt ni ne retarde le comportement de sécurité.
• Les preuves de test sont reproductibles et traçables par rapport aux exigences.

C'est ici que le contraste entre syntaxe et déployabilité devient utile. Un barreau (rung) peut être syntaxiquement valide et rester dangereux à mettre en service.

La capacité systématique n'est pas non plus un badge de produit. Elle n'est pas conférée par l'utilisation d'un simulateur, d'un générateur de code ou d'un assistant IA. Elle est établie par une spécification, une mise en œuvre, une vérification, une documentation et une validation finale disciplinées dans le flux de travail d'assurance réel.

Le regroupement exact peut varier selon les méthodologies, mais un ensemble pratique de propriétés de sécurité logicielle utilisé dans les travaux avancés de sécurité fonctionnelle inclut les comportements suivants que les ingénieurs doivent être capables de tester et d'expliquer.

Les 16 propriétés de sécurité en termes opérationnels

• Complétude — Chaque mode de fonctionnement, transition, chemin de déclenchement et chemin de récupération requis est défini.
• Exactitude — La logique implémentée correspond à l'exigence de sécurité et à la philosophie de contrôle énoncées.
• Cohérence — Les tags, états, transitions et verrouillages se comportent uniformément dans tout le programme.
• Déterminisme — Les mêmes entrées dans les mêmes conditions produisent les mêmes sorties dans les limites d'exécution requises.
• Robustesse — La logique gère les entrées erronées, bruitées, obsolètes, manquantes ou hors plage sans comportement dangereux.
• Absence d'interférence — Les tâches non sécuritaires, les actions IHM, les diagnostics ou la logique auxiliaire n'altèrent pas le comportement de sécurité de manière inappropriée.
• Traçabilité — Les exigences, barreaux, tags, tests et résultats peuvent être liés sans conjecture.
• Vérifiabilité — La structure du code permet des tests indépendants et un jugement clair de réussite/échec.
• Maintenabilité — Les modifications futures peuvent être effectuées sans créer de régressions de sécurité cachées.
• Simplicité — La conception évite une complexité inutile qui obscurcit l'intention ou augmente le risque de faute.
• Défensivité — La logique anticipe les états invalides et les gère explicitement.
• Récupérabilité — Après une faute, le système ne revient qu'au travers de conditions de réinitialisation contrôlées et définies.
• Délimitation (Boundedness) — Les temporisateurs, compteurs, mise à l'échelle analogique et transitions d'état restent dans des limites connues.
• Observabilité — Les états internes et les points de décision peuvent être inspectés pendant la vérification.
• Comportement de sécurité intégrée (Fail-safe) — La perte de signal, le désaccord ou l'état de processus invalide entraîne une réponse sûre là où c'est requis.
• Testabilité — Les ingénieurs peuvent injecter des conditions et confirmer les résultats attendus sans ambiguïté.

Les cinq propriétés que les équipes API sous-estiment généralement

- Déterminisme : Le comportement du cycle de balayage (scan) doit rester prévisible sous toutes les combinaisons d'entrées pertinentes. - Robustesse : La dérive analogique, les contacts rebondissants et les valeurs de communication obsolètes ne doivent pas produire une rétention d'état dangereuse. - Complétude : Chaque transition de machine à états nécessite une condition d'entrée et une condition de sortie sûre. - Absence d'interférence : La logique d'affichage, la messagerie et les fonctionnalités de confort ne doivent pas perturber l'exécution de la sécurité. - Vérifiabilité : Si l'architecture ne peut pas être testée proprement, le problème d'audit commence avant le problème sur site.

Ce sont des comportements d'ingénierie. Si une équipe ne peut pas les démontrer dans des conditions de test contrôlées, la discussion d'audit devient plus interprétative qu'elle ne devrait l'être.

« Prêt pour la simulation » doit être défini opérationnellement, et non de manière décorative.

Un ingénieur « Prêt pour la simulation » est capable de prouver, d'observer, de diagnostiquer et de durcir la logique de contrôle contre un comportement de processus réaliste avant que cette logique n'atteigne un processus réel. Cela inclut bien plus que l'écriture de syntaxe Ladder. Cela comprend :

• le mappage des E/S au comportement de l'équipement prévu,
• la définition de ce que signifie « correct » avant le test,
• le forçage des conditions normales et anormales,
• le traçage de la cause à effet via les tags et les états,
• l'identification des modes de défaillance,
• la révision de la logique après une faute,
• et la comparaison de l'état de l'équipement simulé par rapport à l'état du Ladder.

C'est la différence entre dessiner des barreaux et répéter le jugement de mise en service.

La simulation virtuelle valide le déterminisme en rendant le comportement d'exécution observable dans des conditions reproductibles.

Dans un environnement de simulation délimité, les ingénieurs peuvent exécuter la logique, maintenir les conditions constantes, basculer les entrées dans des séquences contrôlées et observer si les sorties et les états internes changent exactement comme prévu. Le point clé est la répétabilité.

Avec OLLA Lab, ce flux de travail de vérification peut inclure :

• l'exécution de la logique Ladder en mode simulation sans matériel physique,
• le basculement des entrées discrètes et le forçage des valeurs analogiques,
• la surveillance de l'état des tags via le panneau des variables,
• la comparaison du comportement des barreaux avec les objectifs du scénario et la réponse de l'équipement,
• et la répétition du même test après chaque révision.

Pour les vérifications de déterminisme, les ingénieurs doivent tester au moins ces cas :

• des séquences d'entrées identiques répétées plusieurs fois,
• des changements d'entrées asynchrones près des limites de transition,
• des transitions dépendantes de temporisateurs,
• le comportement de réinitialisation et de redémarrage,
• la perte et la restauration des permissifs,
• les franchissements de seuils analogiques avec bruit ou dérive.

Une idée fausse courante est que la simulation ne prouve que la fonctionnalité de base. Utilisée correctement, elle peut également montrer si la logique possède des limites comportementales stables.

OLLA Lab doit être positionné comme un bac à sable de vérification à risque contenu, et non comme un moteur de certification.

Sa valeur opérationnelle est directe : les ingénieurs peuvent construire une logique Ladder dans un éditeur basé sur le Web, l'exécuter en simulation, inspecter les variables et le comportement des E/S, et valider la logique par rapport à des modèles de machines basés sur des scénarios et des jumeaux numériques avant la mise en service physique. Cela le rend utile pour le durcissement pré-audit, la répétition des fautes et la capture de preuves.

Dans ce rôle délimité, OLLA Lab prend en charge plusieurs tâches de vérification pertinentes :

- Éditeur de logique Ladder : construire et réviser la logique de contrôle en utilisant des types d'instructions standard, y compris les temporisateurs, compteurs, comparateurs, mathématiques, logique et PID. - Mode Simulation : exécuter la logique en toute sécurité, arrêter et relancer les tests, et forcer les conditions d'entrée sans exposition matérielle. - Panneau des variables et visibilité des E/S : inspecter les tags, sorties, valeurs analogiques et comportement de boucle tout en traçant la cause à effet. - Scénarios 3D/WebXR/VR : comparer le comportement du Ladder par rapport à la réponse de la machine ou du processus dans des contextes opérationnels réalistes. - Validation par jumeau numérique : tester si la séquence prévue se comporte réellement correctement par rapport à un modèle d'équipement virtuel. - Pratique de mise en service basée sur des scénarios : répéter les verrouillages, alarmes, retours de preuve, déclenchements, permissifs et logique de réinitialisation. - Guide de laboratoire GeniAI : fournir un support guidé et une assistance Ladder pendant l'apprentissage et la préparation aux tests.

Ce dernier point nécessite une limite. L'assistance IA peut accélérer la rédaction et l'explication. Elle ne remplace pas la revue déterministe, la vérification indépendante ou le jugement de sécurité.

La validation par jumeau numérique signifie tester la logique de contrôle par rapport à une représentation virtuelle de l'équipement ou du comportement du processus pour confirmer que les décisions de la logique produisent la réponse système prévue.

Dans le travail lié à la sécurité, cela signifie poser des questions telles que :

• Une condition de déclenchement force-t-elle l'état sûr attendu ?
• Un délai d'attente de retour de preuve se comporte-t-il correctement ?
• Une réinitialisation manuelle reste-t-elle bloquée tant que tous les permissifs ne sont pas sains ?
• La gestion des défaillances analogiques empêche-t-elle un faux redémarrage ou une continuation dangereuse cachée ?
• La séquence récupère-t-elle proprement après un arrêt anormal ?

C'est là qu'OLLA Lab devient opérationnellement utile. La structure de scénario de la plateforme, la visibilité des E/S et le cadrage du jumeau numérique permettent aux ingénieurs de tester le comportement plutôt que de simplement inspecter la syntaxe.

Cela dit, la validation par jumeau numérique ne remplace pas l'acceptation finale sur site, la validation des dispositifs ou les activités certifiées du cycle de vie de sécurité. Il s'agit d'une couche de preuve de pré-mise en service.

Les ingénieurs doivent tester les cas de faute qui exposent des hypothèses cachées dans la logique, en particulier là où la rétention d'état, les permissifs et l'interprétation analogique peuvent échouer silencieusement.

Un ensemble de fautes pré-audit utile comprend :

- Capteur hors plage : valeurs basses, hautes, équivalentes à NaN ou invraisemblables - Dérive analogique : mouvement graduel à travers les seuils d'alarme et de déclenchement - Entrée discrète rebondissante : bruit de transition répété sur les fins de course ou les retours - Entrée à état obsolète : valeur gelée alors que les conditions de processus devraient changer - Perte de permissif : retour du démarreur moteur perdu, preuve de vanne absente, pression non établie - Condition de cycle d'alimentation ou de redémarrage : validation des bits retenus et de l'état de démarrage - Mauvais usage de la réinitialisation manuelle : réinitialisation disponible avant que le danger ne soit écarté - Interruption de séquence : arrêt ou déclenchement pendant une transition d'étape - Substitut de perte de communication : statut gelé ou invalide provenant d'un sous-système dépendant - Désaccord de verrouillage : commande émise alors que le retour contredit l'état attendu de l'équipement

Ces tests sont importants car de nombreuses défaillances dangereuses ne sont pas spectaculaires. Ce sont des discordances silencieuses entre ce que le Ladder croit et ce que l'équipement fait réellement.

Un dossier prêt pour l'audit doit documenter le raisonnement technique et la preuve comportementale, pas seulement des captures d'écran.

Utilisez cette structure compacte pour chaque scénario ou fonction lié à la sécurité :

Capturez l'insight d'ingénierie : hypothèse cachée, permissif manquant, chemin de réinitialisation ambigu, problème de temporisation ou risque d'interférence.

1. Description du système Définissez l'équipement, l'objectif du processus, le mode de fonctionnement et le rôle de sécurité.
2. Définition opérationnelle de « correct » Énoncez le comportement attendu exact, y compris les permissifs, déclenchements, conditions de réinitialisation, temporisation et état sûr.
3. Logique Ladder et état de l'équipement simulé Montrez les barreaux pertinents, le mappage des tags et l'état de l'équipement ou du processus utilisé en simulation.
4. Le cas de faute injecté Documentez la condition anormale introduite, comment elle a été forcée et pourquoi elle est importante.
5. La révision effectuée Enregistrez le changement de logique, l'ajustement de paramètre ou la correction de gestion d'état effectuée après le test.
6. Leçons apprises

Cette structure est délibérément simple. Les auditeurs et les relecteurs préfèrent généralement des preuves qu'ils peuvent suivre sans archéologie interprétative.

Les ingénieurs peuvent utiliser OLLA Lab pour générer des artefacts pré-audit reproductibles en liant chaque test à un scénario, un ensemble de conditions forcées, un comportement de tag observable et une révision documentée.

Un flux de travail pratique ressemble à ceci :

1. Sélectionner un scénario avec des objectifs opérationnels explicites Par exemple, une chaîne d'arrêt d'urgence, un contrôle de pompe maître/esclave, une séquence de convoyeur ou un ensemble de permissifs de CTA.
2. Définir le comportement sûr attendu avant le test Énoncez ce qui doit se passer lors d'un déclenchement, d'une réinitialisation et d'une entrée anormale.
3. Exécuter le Ladder en mode simulation Utilisez l'éditeur et les contrôles de simulation pour exécuter la logique dans des conditions normales d'abord.
4. Forcer la faute via le panneau des variables Injectez des valeurs analogiques hors plage, supprimez le retour de preuve, basculez les verrouillages ou simulez des états obsolètes.
5. Observer et enregistrer la réponse Confirmez si les sorties, états, alarmes et chemins de réinitialisation se comportent comme défini.
6. Réviser la logique et relancer le cas exact C'est la partie importante. Une preuve sans historique de révision est souvent juste un journal intime.
7. Capturer les paramètres du scénario et le résumé des résultats Préservez les conditions de test afin qu'un autre relecteur puisse reproduire le résultat.

Dans ce flux de travail, la valeur d'OLLA Lab n'est pas qu'il prouve la conformité par lui-même. Sa valeur est qu'il aide les ingénieurs à créer un corpus reproductible de preuves comportementales avant la soumission formelle à l'audit et avant que l'équipement réel ne devienne le banc d'essai.

Une implémentation d'arrêt d'urgence défensive doit appliquer un comportement de perte de sécurité intégrée, une réinitialisation manuelle explicite et une protection contre les conditions de redémarrage prématuré ou forcé.

[Langage : Schéma à contacts (Ladder) - CEI 61131-3]

|----[/] E_STOP_OK ----+-------------------------------( ) SAFE_TRIP_ACTIVE | | |----[/] SAFETY_RELAY_FB-+

|----[ ] E_STOP_OK ----[ ] SAFETY_RELAY_FB ----[ ] RESET_PB ----[/] SAFE_TRIP_ACTIVE ----[TON ANTI_TIEDOWN 500ms] |------------------------------------------------------------------------------------------------------------( ) RESET_PERMISSIVE

|----[ ] RESET_PERMISSIVE ----[ ] ALL_PERMISSIVES_OK ----[ ] NO_ACTIVE_FAULTS ----[/] START_INHIBIT ----( ) SAFETY_ENABLE

|----[/] SAFETY_ENABLE ------------------------------------------------------------------------------------( ) MOTOR_RUN_CMD

Pourquoi ce modèle est important

- Complétude : le redémarrage nécessite des conditions saines définies, pas seulement la restauration de l'arrêt d'urgence. - Robustesse : la perte du retour du relais de sécurité ou de la santé de l'arrêt d'urgence force le comportement de déclenchement. - Récupérabilité : la réinitialisation est manuelle et conditionnée. - Comportement de sécurité intégrée : l'absence d'entrées de sécurité saines supprime l'activation. - Absence d'interférence : le chemin de sécurité est explicite et séparable de la logique de confort.

En pratique, l'implémentation exacte dépend de la plateforme, de l'architecture de sécurité et du chemin matériel certifié. Le point ici est structurel : la récupération sûre doit être méritée, pas supposée.

Les simulations 3D et VR aident lorsqu'elles améliorent l'observabilité des conséquences du processus, et non lorsqu'elles ajoutent simplement du théâtre visuel.

Dans OLLA Lab, les scénarios 3D/WebXR/VR peuvent aider les ingénieurs à comparer l'état du Ladder par rapport à la réponse visible de l'équipement. C'est utile lors du test de :

• la progression de la séquence,
• la temporisation des actionneurs,
• les dépendances de retour de preuve,
• les conditions d'alarme,
• le mouvement verrouillé,
• et les conséquences de la réinitialisation par l'opérateur.

L'avantage pour l'ingénierie est que les erreurs de logique deviennent plus faciles à repérer lorsque l'équipement virtuel fait quelque chose d'évidemment faux pour une raison traçable.

Cela dit, la preuve reste côté logiciel et délimitée par la simulation. Elle renforce la vérification de pré-mise en service. Elle ne remplace pas la validation physique, le comportement certifié du dispositif ou le dossier de sécurité formel.

Les équipes doivent utiliser l'assistance IA pour l'accélération au niveau de l'ébauche et de l'explication, puis appliquer une revue humaine déterministe au niveau de la décision.

Dans OLLA Lab, GeniAI peut aider à l'intégration, à l'explication des barreaux, aux suggestions correctives et au support de rédaction Ladder. C'est utile, surtout pour l'apprentissage structuré et l'itération précoce. Cela réduit la friction, mais la réduction de la friction n'est pas la même chose que l'assurance de sécurité.

Pour la logique liée à la sécurité, les équipes doivent exiger :

• un mappage explicite des exigences,
• une revue indépendante de la logique générée,
• une simulation par injection de fautes,
• une révision documentée après les cas d'échec,
• et une approbation finale par un ingénieur qualifié dans le cadre du cycle de vie de sécurité du projet.

Le contraste mémorable est simple : génération d'ébauche versus veto déterministe. Le second est le travail.

Les ingénieurs doivent commencer par convertir les allégations de sécurité abstraites en cas de test reproductibles.

Une séquence pratique est :

• identifier les fonctions liées à la sécurité dans le périmètre de l'API,
• définir le comportement correct pour les états normaux, de déclenchement, de réinitialisation et anormaux,
• mapper chaque fonction à un petit ensemble de propriétés de sécurité,
• exécuter une simulation par injection de fautes avant les tests matériels,
• documenter les révisions dans un dossier de preuves compact,
• et réserver la mise en service réelle à la validation, pas à la première découverte.

Si votre flux de travail actuel traite encore les tests d'états anormaux comme quelque chose qui se produit une fois que le panneau est sous tension, le processus est en retard.

_Texte alternatif de l'image : Capture d'écran du panneau des variables OLLA Lab démontrant un test de capacité systématique. Une entrée analogique est forcée hors plage, et la logique passe à un état sûr, illustrant la propriété de robustesse dans un flux de travail d'audit CEI 61508 simulé._

- CEI 61131-3 : Automates programmables — Partie 3 : Langages de programmation - Vue d'ensemble de la CEI 61508 (sécurité fonctionnelle) - Cadre de gestion des risques liés à l'IA du NIST (AI RMF 1.0) - Jumeau numérique dans la fabrication : une revue de littérature catégorique et une classification (IFAC, DOI) - Jumeau numérique dans l'industrie : état de l'art (IEEE, DOI)

Expert en sécurité fonctionnelle et systèmes de contrôle industriel, spécialisé dans la conformité CEI 61508 et l'optimisation des flux de travail de validation logicielle.

Contenu validé par les équipes techniques d'Ampergon Vallis Lab pour la conformité aux principes de la CEI 61508 édition 3 et les méthodologies de simulation OLLA Lab.