Introduction

Champ d’application : Cet article explique ce qu’est le langage de contrainte d’objet (OCL), pourquoi il est important pour la validation des fichiers SCL dans les projets IEC 61850, ce que définit la norme IEC TS 61850-6-3, et où s’insère l’outil open-source RiseClipse. Il ne couvre pas les détails d’implémentation de l’OCL pour les développeurs d’outils, ni tous les aspects du test de conformité IEC 61850.

Si vous avez déjà ouvert un fichier SCL provenant d’un autre fournisseur et vous êtes demandé s’il est réellement correct – pas seulement bien formé en XML, mais sémantiquement valide selon la norme IEC 61850 – vous comprenez déjà le problème que l’OCL cherche à résoudre.

La validation par schéma XML vous indique si le fichier est correctement structuré. Elle ne peut pas vous dire si une souscription GOOSE référence un jeu de données valide, si un nœud logique contient les objets de données requis, ou si deux LD sont connectés d’une manière logique. Ce niveau de vérification nécessite quelque chose de plus expressif.

Le langage de contrainte d’objet (OCL) est ce « quelque chose ». À partir de 2025, l’IEC a publié la norme IEC TS 61850-6-3, une spécification technique qui décrit formellement la manière dont les règles OCL doivent être rédigées et appliquées aux fichiers basés sur XML IEC 61850 – y compris les fichiers SCL.

Cet article explique ce qu’est l’OCL, pourquoi il est important pour les ingénieurs travaillant avec les fichiers SCD et ICD, comment il est utilisé dans l’outil open-source RiseClipse, et ce que définit le travail en cours de normalisation.

Qu’est-ce que l’OCL ?

L’OCL — Object Constraint Language — est un langage formel développé à l’origine dans le cadre de la spécification Unified Modeling Language (UML). Il permet d’exprimer des contraintes et des requêtes sur des modèles d’objets de manière précise et sans ambiguïté.

Alors que les diagrammes UML décrivent ce à quoi ressemble un modèle, l’OCL permet d’écrire des règles sur ce qui doit toujours être vrai dans un modèle valide.

Une contrainte OCL est une déclaration logique attachée à un élément du modèle. Par exemple, dans le contexte de l’IEC 61850, on pourrait exprimer une règle telle que :

Chaque LDevice doit contenir au moins un LN0 et au plus un.

Ou encore :

Une référence externe GOOSE (ExtRef) doit pointer vers un jeu de données existant dans le fichier.

Le schéma XML ne peut pas imposer des règles comme celles-ci. L’OCL, lui, peut. Parce que l’OCL opère au niveau du modèle – et non au niveau de la syntaxe XML – il peut naviguer dans les relations entre les éléments à travers l’ensemble du fichier de configuration.

Pourquoi la validation des fichiers SCL nécessite plus qu’un schéma XML

L’IEC 61850 utilise le langage de configuration de sous-station (SCL) pour décrire la configuration des dispositifs électroniques intelligents (IED), la topologie de la sous-station et la communication entre eux. Les fichiers SCL – SSD, SCD, ICD, CID, IID – sont des documents XML.

Le schéma XML (XSD) valide la structure de ces fichiers : noms des éléments, attributs, cardinalité. Cela est nécessaire, mais pas suffisant.

La norme IEC 61850 contient des règles supplémentaires que le schéma XML ne peut pas exprimer :

  • Les références croisées entre les éléments (un signal abonné doit correspondre à un signal publié par le nom et le type)
  • Les contraintes qui dépendent des valeurs des attributs ("si type = GOOSE, alors...")
  • Les règles concernant les objets de données obligatoires et optionnels selon la classe du nœud logique
  • Les vérifications de cohérence d'ingénierie entre différentes sections d'un fichier SCD

Sans des règles vérifiables automatiquement pour ces contraintes, la validation a été laissée aux outils qui l'effectuaient à leur manière — de manière incohérente, incomplète ou pas du tout. Le résultat est la découverte tardive de problèmes d'interopérabilité : lors des essais d'acceptation en usine, de la mise en service sur site ou lors d'événements d'interopérabilité.

IEC TS 61850-6-3 : La Nouvelle Norme

En 2025, le groupe de travail 10 du TC57 de l’IEC a publié IEC TS 61850-6-3:2025 — « Format des règles traitables par machine pour la validation des fichiers XML basés sur IEC 61850 ».

Cette Spécification technique réalise trois choses :

  1. Définit le format pour écrire des règles de validation OCL pour IEC 61850 — une manière structurée et standardisée d’exprimer les contraintes que les outils peuvent importer et exécuter.
  2. Soutient trois cas d’usage principaux : - Valider les fichiers SCL à chaque étape du processus d’ingénierie - Vérifier la conformité après une mise à niveau ou une rétrogradation entre éditions de normes - Étendre les règles standard par des règles OCL privées (spécifiques aux fournisseurs ou aux projets)
  3. Sépare le format des règles elles-mêmes — la Spécification technique couvre la manière d’écrire les règles, tandis que les ensembles de règles réels sont publiés sous forme de composants de code associés aux parties correspondantes de l’IEC 61850 (comme l’IEC 61850-6).

La norme a été publiée le 8 juillet 2025. C’est le premier document officiel de l’IEC qui décrit comment OCL doit être utilisé dans l’écosystème IEC 61850.

Note : L’IEC TS 61850-6-3 est une Spécification technique, pas une norme internationale complète. Elle définit un cadre et un format ; les ensembles de règles OCL spécifiques pour les fichiers SCL sont développés séparément par le groupe de travail 10 TF OCL et ne sont pas encore entièrement publiés au début de 2026.

Fonctionnement pratique des règles OCL

Le flux de validation :

flowchart LR
    A[Standard IEC 61850\nModèle UML] -->|définit| B[Règles OCL\n.fichiers .ocl]
    C[Fichier SCL\nSCD / ICD / CID] -->|chargé dans| D[Instance de modèle]
    B -->|appliquées à| D
    D -->|produit| E[Rapport de validation\nerreurs / avertissements]
    E -->|retour d'information à| F[Ingénieur /\nIntégrateur système]
  1. Le modèle UML de l’IEC 61850 est la référence. Les règles OCL sont écrites par rapport à ce modèle — elles décrivent quelles contraintes sont toujours valides.
  2. Un fichier SCL est chargé dans un outil qui l’instancie en tant que modèle d’objets (plutôt que de simplement parser le XML).
  3. Les règles OCL sont appliquées à cette instance de modèle.
  4. Les violations sont signalées avec des emplacements et des descriptions précises.

OCL fonctionne au niveau sémantique : il peut naviguer dans le graphe d’objets — suivre les références, vérifier les conditions à travers le fichier — de manière impossible avec les vérifications XSD ou XSLT.

La principale implémentation open-source de la validation SCL basée sur OCL est RiseClipse, développée par CentraleSupélec et EDF R&D en France dans le cadre du programme de recherche RISEGrid.

RiseClipse : - Charge les fichiers SCL et les instancie en objets EMF (Eclipse Modeling Framework) conformes au modèle UML SCL - Applique des ensembles de contraintes OCL exprimés dans des fichiers .ocl - Signale les violations au niveau sémantique — non seulement « élément manquant » mais aussi « cette référence externe pointe vers un jeu de données inexistant »

Les fichiers de contraintes OCL pour SCL sont publiés dans un dépôt open-source sur GitHub : riseclipse/riseclipse-ocl-constraints-scl2003.

RiseClipse peut être utilisée de plusieurs façons : - Outil en ligne de commande (fat JAR) pour l’intégration dans les pipelines CI/CD et les flux de travail d’ingénierie - Image Docker pour un déploiement conteneurisé - Triangle MicroWorks SCL Navigator — un outil commercial intégrant le moteur OCL de RiseClipse, avec un mode lecteur gratuit disponible - CoMPAS (projet LFEnergy) — utilise RiseClipse comme moteur de validation SCL en arrière-plan

RiseClipse est utilisée depuis au moins 2015 lors des événements d’interopérabilité IEC 61850 (voir : Marcadet et al., PSCC 2016). L’adoption plus large dans l’industrie reste limitée ; l’outil et les ensembles de règles associés sont encore en cours de maturation.

Les travaux du TF OCL du WG10 : que se passe-t-il actuellement ?

Le groupe de travail 10 (WG10) de l’IEC TC57 dispose d’un groupe de travail dédié à OCL (TF OCL), chargé de développer les ensembles de règles à publier conjointement avec les parties de la norme. Ces ensembles de règles définissent formellement et de manière vérifiable par machine ce que signifie pour un fichier SCL de respecter IEC 61850-6.

Les travaux du groupe de travail sont décrits dans la norme technique IEC TS 61850-6-3:2025, qui établit le cadre et le format des ensembles de règles OCL. Comme indiqué dans la spécification technique, le processus de développement des règles exige de tester les règles candidates sur des fichiers d’ingénierie réels afin de vérifier leur exactitude et leur exhaustivité avant leur publication normative.

Il s’agit d’un scénario typique pour les travaux de normalisation en phase initiale : les règles doivent être validées sur la gamme de configurations réelles avant de pouvoir être publiées de manière normative. L’équilibre entre exhaustivité et délai de publication est un défi courant à ce stade du développement de la spécification.

Aucun calendrier complet pour la première publication d’un ensemble de règles n’a été annoncé publiquement à ce jour.

Conséquences pratiques pour les ingénieurs et intégrateurs

Pour les ingénieurs travaillant avec des fichiers SCL, la validation basée sur OCL comble un vide connu : des vérifications sémantiques que la validation XSD ne peut pas effectuer. L’importance pratique dépend de la rapidité avec laquelle les fournisseurs d’outils adopteront les ensembles de règles publiés.

Les fonctionnalités spécifiques que permettent les règles OCL :

Vérification plus complète. Les règles OCL peuvent détecter des erreurs que la validation XSD manque — références pendantes, objets obligatoires manquants, configuration incohérente entre les IED.

Contrôles cohérents entre outils. Lorsque l’ensemble de règles est standardisé par l’IEC et publié sous forme de code traitable par machine, différents outils peuvent exécuter les mêmes vérifications sur la même base normative. Aujourd’hui, les outils appliquent des sous-ensembles différents des règles de la norme, ce qui entraîne des résultats incohérents.

Traçabilité de la correspondance règle-clause. Chaque règle OCL peut être reliée à une clause spécifique de la norme IEC 61850. Si un fichier échoue à une vérification, l’ingénieur peut identifier la exigence normative qui est violée.

Extensions de règles privées. L’IEC TS 61850-6-3 autorise explicitement les règles OCL privées — des contraintes spécifiques au projet ou au fournisseur, au-delà de la norme. Les entreprises peuvent encoder leurs propres règles d’ingénierie dans le même langage formel.

Les ingénieurs devraient s’attendre à ce que la validation SCL dans les outils devienne plus stricte à mesure que les ensembles de règles OCL sont publiés et adoptés. Les fichiers qui passent les vérifications basiques XSD aujourd’hui pourraient nécessiter des corrections lorsqu’ils sont validés contre un ensemble complet de règles OCL.

Limitations

Plusieurs limites pratiques s’appliquent à la validation SCL basée sur OCL tel qu’il existe aujourd’hui :

Couverture des règles incomplète. La première publication de l’ensemble de règles OCL du WG10 TF est en cours de finalisation au début de 2026. Elle ne couvrira pas toutes les contraintes de l’IEC 61850-6. Les ensembles de règles s’élargiront dans les versions ultérieures.

Adoption limitée des outils. À la première moitié de 2026, RiseClipse et CoMPAS sont les principaux outils utilisant la validation SCL basée sur OCL. La plupart des outils commerciaux d’ingénierie IEC 61850 n’implémentent pas encore les ensembles de règles de l’IEC TS 61850-6-3.

Maturité de RiseClipse. RiseClipse est un outil issu de la recherche. Il a été utilisé lors d’événements de tests d’interopérabilité et dans des contextes de recherche. Il n’est pas encore un outil de test de conformité certifié, et les ensembles de règles OCL qu’il utilise ne sont pas encore les ensembles finalisés publiés par l’IEC.

Portée de l’IEC TS 61850-6-3. La spécification technique définit un format pour les règles — pas les règles elles-mêmes. La qualité de la validation dépend de la complétude et de la correction des fichiers de règles OCL appliqués, ce qui varie selon l’implémentation.

Effort d’intégration. Intégrer la validation basée sur OCL dans les flux de travail d’ingénierie existants exige un support d’outils. Tous les éditeurs SCL ou les configurateurs de systèmes ne prennent pas en charge l’import et l’exécution des règles OCL.

Erreurs courantes

« OCL est une nouvelle norme IEC 61850. »
OCL n’est pas un nouveau protocole de communication ou un nouveau modèle de données. C’est un langage pour exprimer des règles de validation. L’élément nouveau est l’IEC TS 61850-6-3, qui définit comment OCL doit être utilisé dans le contexte IEC 61850.

« La validation XSD suffit. »
La validation XML Schema est nécessaire mais pas suffisante pour la correction du SCL. La validation XSD vérifie la structure ; OCL vérifie la sémantique. Un fichier SCL peut être valide selon XSD et pourtant être incorrect sur le plan logique.

« Seuls les développeurs d’outils doivent s’intéresser à cela. »
Les entreprises et les intégrateurs de systèmes rencontreront la validation basée sur OCL dans les outils d’ingénierie à mesure que l’adoption progresse. Comprendre ce qu’elle vérifie — et pourquoi — aide les ingénieurs à interpréter les résultats de validation et à rédiger des fichiers de configuration corrects.

« Les règles sont complètes et définitives. »
Le TF OCL continue de publier l’ensemble initial de règles. Ces règles évolueront. Des extensions de règles privées sont possibles. Il s’agit d’un processus continu, et non d’une publication unique.

Conclusion

La validation basée sur OCL comble un vide existant depuis longtemps dans l’ingénierie IEC 61850 : l’absence de règles formelles, vérifiables par machine, au-delà du schéma XML. L’IEC TS 61850-6-3 fournit la définition du format. Le WG10 TF OCL développe les ensembles de règles.

Pour les ingénieurs et les intégrateurs système, l’impact pratique dépendra de l’adoption des outils et de la vitesse à laquelle les ensembles de règles seront publiés et finalisés. En principe, les fichiers contenant des erreurs sémantiques — références croisées pointant vers rien, objets obligatoires manquants, abonnements incohérents — peuvent être détectés aujourd’hui par des outils basés sur OCL ; en pratique, la couverture et les outils sont encore en développement.

Le premier lot de règles est en cours de finalisation au début de 2026. À mesure que les ensembles de règles et les outils évoluent, l’OCL a le potentiel de devenir une composante standard des flux de travail d’ingénierie et de mise en service des fichiers SCL.

Sources et références

  • IEC TS 61850-6-3:2025, Format des règles traitables par machine pour la validation des fichiers XML IEC 61850, IEC Webstore, publié le 8 juillet 2025
  • Projet RiseClipse : riseclipse.github.io
  • Contraintes OCL RiseClipse pour SCL : github.com/riseclipse/riseclipse-ocl-constraints-scl2003
  • D. Marcadet et al., RiseClipse : pourquoi travailler au niveau du modèle est meilleur pour valider les fichiers SCL IEC 61850, PSCC 2016
  • Comité d’étude CIGRE B5, 2024 : Introduction à l’IEC 61850-6-3 OCL : règles traitables par machine pour la validation des fichiers XML IEC 61850 — CIGRE 2024, Comité d’étude B5 (numéro complet et liste des auteurs non confirmés dans les sources publiques)
  • Triangle MicroWorks SCL Navigator avec moteur OCL RiseClipse : trianglemicroworks.com
  • CoMPAS SCL Validator (LFEnergy) : github.com/com-pas/compas-scl-validator

Dernière mise à jour : mars 2026