On entend beaucoup parler d’Universal Automation, mais ….
Chez Indus4Tech nous vivons au quotidien dans l’écosystème IEC 61131-3 avec Codesys, la norme qui a façonné la programmation automate depuis 30 ans. Depuis quelques mois pourtant, un autre nom circule de plus en plus dans les conférences et salons : Universal Automation (UAO), porté par la norme IEC 61499. Certains la présentent comme la relève naturelle de l’IEC 61131-3, d’autres comme un simple complément académique resté 20 ans dans les cartons. La vérité est plus nuancée — et c’est ce qu’on vous propose de démêler ici.
Qu’est-ce que l’IEC 61499 ?
Bonne question sur un sujet encore mal connu du terrain. Voici une vue d’ensemble claire :
IEC 61499 est une norme internationale (CEI, publiée en 2005, révisée en 2012) qui définit un langage de conception système pour les architectures de commande distribuées. Ce n’est pas un langage de programmation au sens de l’IEC 61131-3 : c’est un modèle qui décrit comment des blocs fonctionnels événementiels (Event-driven Function Blocks) se connectent entre eux, s’exécutent, et se répartissent sur plusieurs contrôleurs, indépendamment du matériel.
Concrètement, chaque bloc fonctionnel IEC 61499 possède des entrées/sorties données ET événements (contre données uniquement en IEC 61131-3).
Le bloc ne s’exécute que lorsqu’un événement le déclenche — on parle d’exécution pilotée par les événements, à l’opposé du scan cyclique qui balaie en permanence tout le programme automate classique.
Qu’est-ce qu’Universal Automation (UAO) ?
UniversalAutomation.org (UAO) est une association internationale à but non lucratif, née en 2020, qui rassemble aujourd’hui plus d’une centaine de membres (fabricants, intégrateurs, académiques). Sa mission : fournir un runtime d’exécution partagé, basé sur l’IEC 61499, en source protégée mutualisée (« guarded-source »), pour que les applications automate deviennent enfin portables d’un matériel à l’autre, un peu comme Codesys l’a fait pour l’IEC 61131-3, mais en poussant le concept encore plus loin sur la distribution et le découplage logiciel/matériel.
IEC 61131-3 vs IEC 61499 : les points communs
Les deux normes partagent une base commune qu’il ne faut pas perdre de vue :
- Toutes deux sont des normes CEI (IEC), pensées pour l’automatisme industriel
- Toutes deux reposent sur le concept de bloc fonctionnel (Function Block) comme brique de programmation réutilisable
- Toutes deux visent l’indépendance vis-à-vis du matériel et la portabilité des applications
- Un bloc fonctionnel IEC 61499 peut très bien contenir, à l’intérieur, du code écrit en langage IEC 61131-3 (ST notamment) — les deux normes ne s’opposent donc pas totalement dans l’implémentation
IEC 61131-3 vs IEC 61499 : les différences
| Critère | IEC 61131-3 (Codesys, TIA Portal…) | IEC 61499 (UAO) |
| Nature | Langage de programmation (5 langages normés) | Langage de conception système, pas un langage de programmation |
| Modèle d’exécution | Scan cyclique (lecture E/S → exécution → écriture E/S → répétition) | Piloté par les événements (le bloc s’exécute quand un événement arrive) |
| Cible | Un automate, une tâche | Système distribué sur plusieurs contrôleurs/hardware |
| Interface des blocs | Données uniquement | Données et événements |
| Ancienneté / maturité | 1993, écosystème massif (600+ fabricants pour Codesys) | 2005/2012, écosystème naissant (UAO ~100 membres) |
| Déterminisme temps réel | Très mature, éprouvé en production depuis 30 ans | Prometteur mais encore peu de retours industriels à grande échelle |
| Portabilité réelle | Bonne via Codesys, mais dialectes possibles selon fabricants | Portabilité native visée dès la conception de la norme |
Confrontation : atouts et limites de chaque norme
IEC 61131-3 (avec Codesys)
✅ Maturité et fiabilité éprouvées depuis 30 ans en production
✅ Écosystème gigantesque : plus de 600 fabricants, main-d’œuvre qualifiée disponible partout
✅ Certification sécurité fonctionnelle ==SIL2/SIL3== largement industrialisée (TÜV)
✅ Déterminisme temps réel bien maîtrisé (cycles 1-10 ms, voire sub-ms en motion EtherCAT)
⚠️ Pensée à l’origine pour un automate, la distribution multi-contrôleurs reste une surcouche (réseaux, bus de terrain, OPC UA) plutôt qu’un principe natif
⚠️ Portabilité réelle parfois limitée par les extensions propriétaires des fabricants
IEC 61499 (avec UAO)
✅ Pensée nativement pour les architectures distribuées et le découplage logiciel/matériel
✅ Modèle événementiel plus proche du génie logiciel moderne (composants réutilisables façon « IT »)
✅ Portage naturel vers l’Industrie 4.0 : reconfiguration dynamique, edge computing, jumeaux numériques
⚠️ Écosystème encore jeune : peu de fabricants, peu d’intégrateurs formés, peu de retours d’expérience terrain à grande échelle
⚠️ Le modèle d’exécution événementiel est critiqué dans la littérature académique pour son manque de clarté sur la gestion des priorités d’événements — un point qui complique le débogage
⚠️ Certification sécurité fonctionnelle encore peu répandue comparée à l’offre SIL2/SIL3 mature de l’IEC 61131-3
Les autres normes à connaître dans cet écosystème
L’IEC 61499 n’est pas la seule brique du puzzle « automatisation ouverte et distribuée ». Trois autres standards reviennent souvent dans les mêmes discussions :
- OPC UA (IEC 62541) — Ce n’est pas une norme de programmation automate mais un protocole d’échange de données indépendant du fabricant, sécurisé nativement (authentification, chiffrement), qui structure l’information selon des modèles standardisés. OPC UA est complémentaire aux deux normes précédentes : Codesys l’intègre nativement, et UAO/IEC 61499 s’appuie dessus pour ses échanges IT/OT.
- MTP — Module Type Package (VDI/VDE/NAMUR 2658) — Norme dédiée aux industries de process modulaires (chimie, pharma) qui décrit comment un module de production « s’auto-décrit » pour s’intégrer automatiquement dans un système de contrôle de niveau supérieur. Des runtimes IEC 61499/UAO génèrent aujourd’hui directement des fichiers MTP (ex. bibliothèque PA-Toolkit pour Codesys chez Festo), preuve que ces normes se combinent en pratique.
- O-PAS (Open Process Automation Standard, porté par l’Open Group) — Standard d’architecture système pour les DCS (Distributed Control Systems) du monde process, visant lui aussi l’interopérabilité multi-fournisseurs, mais à un niveau plus large que le seul contrôleur.
Ces normes ne sont pas concurrentes entre elles : elles s’adressent à des couches différentes de l’architecture (programmation contrôleur, échange de données, description de module, architecture système).
Compatibilité et passerelles possibles
Dans la réalité du terrain, l’opposition « IEC 61131-3 contre IEC 61499 » est trompeuse. Les architectures qui émergent aujourd’hui les combinent :
- Un bloc fonctionnel IEC 61499 peut embarquer du code IEC 61131-3 (Structured Text notamment) — l’automaticien formé Codesys n’a donc pas à tout réapprendre pour comprendre la logique interne d’un bloc UAO.
- OPC UA fait office de passerelle naturelle entre un parc d’automates IEC 61131-3 existant et une couche de supervision ou d’orchestration IEC 61499 : les variables Codesys sont publiées en OPC UA, consommées côté UAO, sans réécrire l’existant.
- Certains constructeurs font déjà cohabiter un runtime UAO/IEC 61499 avec un runtime Codesys IEC 61131-3 sur le même hardware, chacun gérant sa couche : Codesys pour la logique déterministe locale, UAO pour l’orchestration distribuée et la génération MTP.
- Dans la majorité des cas concrets aujourd’hui, l’IEC 61499 se positionne au-dessus de la couche machine existante (orchestration, reconfiguration dynamique, intégration modulaire) plutôt qu’en remplacement direct du programme automate IEC 61131-3 qui continue de piloter les E/S en temps réel.
Faut-il migrer vers l’IEC 61499 dès maintenant ?
Pour la très grande majorité des projets industriels — machines spéciales, lignes de production, process — l’IEC 61131-3 et Codesys restent aujourd’hui le choix le plus sûr : écosystème mature, compétences disponibles, certification sécurité éprouvée. L’IEC 61499 et Universal Automation méritent en revanche toute votre attention si vos enjeux touchent à la reconfiguration dynamique de systèmes distribués à l’intégration modulaire multi-sites (process modulaire, MTP) ou à des architectures nativement logicielles et découplées du matériel. Les deux mondes ne s’excluent pas : ils se complètent, et savoir naviguer entre les deux devient un vrai atout technique.
— veille technologique, conseil, intégration, retrofit —
Échangeons sur vos besoins en architecture d’automatisation
Nous vous accompagnons dans l’analyse et le choix des standards adaptés à vos enjeux industriels.
👉 Contactez-nous directement.
