C’est une norme CEI qui définit comment concevoir des systèmes de commande distribués, via des blocs fonctionnels pilotés par des événements, indépendants du matériel sur lequel ils s’exécutent.
Ce n’est pas un langage de programmation, mais un langage de conception système.

UAO est une association internationale à but non lucratif qui développe et maintient un runtime d’exécution partagé basé sur l’IEC 61499, en source protégée mutualisée (« guarded-source »).
L’objectif : rendre les applications automate portables d’un fabricant à l’autre, quel que soit le hardware.

Voir le site UniversalAutomation.org

Non, pas à court ni moyen terme. L’IEC 61131-3 (avec Codesys, TIA Portal, etc.) reste la norme de référence pour la programmation automate classique, avec un écosystème massif et une certification sécurité mature.
L’IEC 61499 se positionne aujourd’hui plutôt en complément, sur la couche d’orchestration et de distribution.

L’IEC 61131-3 fonctionne en scan cyclique : le programme est relu en boucle, entrées → traitement → sorties.
L’IEC 61499 fonctionne en mode événementiel : un bloc fonctionnel ne s’exécute que lorsqu’un événement le déclenche, ce qui est plus proche des architectures logicielles modernes (microservices, IT).

Oui.
Un bloc fonctionnel IEC 61499 peut contenir, en interne, du code écrit dans un langage IEC 61131-3 comme le Structured Text (ST).
Un automaticien formé Codesys peut donc comprendre et contribuer à la logique interne d’un bloc UAO sans tout réapprendre.

Ce sont des normes complémentaires, pas concurrentes, qui couvrent d’autres couches de l’architecture :
• OPC UA (IEC 62541) — protocole d’échange de données sécurisé, indépendant du fabricant
• MTP — description standardisée d’un module de production pour l’intégrer automatiquement (process modulaire, chimie/pharma)
• O-PAS — standard d’architecture système pour les DCS multi-fournisseurs (Open Group) L’IEC 61499/UAO s’appuie souvent sur OPC UA pour ses échanges, et peut générer des fichiers MTP.

L’offre est aujourd’hui beaucoup moins mature que sur l’IEC 61131-3, où des solutions comme CODESYS Safety sont certifiées SIL2/SIL3 selon l’IEC 61508 depuis plusieurs années.
Pour toute application safety critique aujourd’hui, l’IEC 61131-3 reste la voie la plus sûre et la plus documentée.

Le runtime (ou CODESYS Control) est le logiciel embarqué sur la cible (automate, PC industriel, Raspberry Pi…) qui exécute le programme IEC 61131-3. C’est lui qui assure le cycle automate, la communication avec les Entrées/Sorties, les bus de terrain et les protocoles réseau.

L’association UAO compte une centaine de membres : fabricants de matériel, intégrateurs, universités.
Des cas d’usage concrets existent notamment dans l’offshore, le process modulaire (via MTP) et les architectures de reconfiguration dynamique, mais l’adoption reste encore limitée comparée aux 600+ fabricants intégrant Codesys.

Cela dépend de vos enjeux.
Si vos projets touchent à l’intégration modulaire multi-sites, à la reconfiguration dynamique de systèmes distribués ou à des architectures logicielles découplées du matériel, une veille active — voire une première formation — a du sens.
Pour la majorité des projets machines/lignes de production classiques, la maîtrise de l’IEC 61131-3 reste la priorité.