La performance industrielle avec des solutions digitales est étroitement liée à leur capacité de collecte de données de manière sécurisée et agile. Nous faisons le point sur un protocole standardisé: le protocole OPC UA, pourquoi et comment il répond aux enjeux de l’industrie 4.0.
Un peu d’histoire
Dans les années 90’s, Microsoft lance le OLE (Object Linking and Embedding), technique qui permet le dialogue inter application (ex: insertion d’une image dans un traitement de texte). Puis arrive en 1995, l’ OPC (OLE for process Control), extension d’OLE pour relier les applications Microsoft et les matériels industriels (matériels et logiciels, liaison d’un API avec sa supervision).
En 2011, l’OPC devient Open Platform Communication, marque déposée de la fondation OPC solidaire de Microsoft. Cette fondation est constituée de constructeurs de renom de différentes marques et fait naître diverses spécifications au fil du temps :
- OPC-DA : DataAccess
- OPC-AE : Alarm & Events
- OPC-HDA : Historical Data Access…
A présent, l’OPC-UA (Unified Architecture) ne nécessite plus l’utilisation obligatoire de Windows, et complète les fonctionnalités existantes par de nouvelles technologies comme XML / service Web … .
Ce que l’on peut faire
La communication est unifiée entre le(s) serveur(s) OPC-UA et le(s) client(s) OPC_UA. Tout organe devant prendre part à une communication OPC_UA doit obligatoirement intégrer la couche logiciel ad-hoc.
- une couche Serveur OPC-UA pour les organes devant mettre à disposition de la data. Cette couche peut être hébergée par du matériel industriel (automate programmable / robot), par des cartes spécifiques (raspi …) ou autre PC.
- une couche Client OPC-UA pour les organes devant consommer de la data (lecture / écriture). Divers types de Client OPC existent (voir une liste non exhaustive ci-dessous). On en trouve pour divers OS comme Windows / linux / Andoid.
La partie Client OPC-UA peut être également intégrée à des outils professionnels comme les ateliers de programmation des automates programmables et des robots (par exemple siemens TIA Portal) ou encore dans des logiciels de supervision (SCADA) tel factory system / wonderware … .
Architecture client / serveur
Dans un architecture plusieurs clients peuvent être en communication avec plusieurs serveurs.
Certains équipements peuvent jouer un double rôle Client et Serveur pour d’autres Clients.
Pour un équipement communicant (avec un protocole particulier style modbus TCP ou autre) et ne disposant pas nativement de la couche Serveur OPC-UA devant être intégré à une architecture OPC-UA, il faudra obligatoirement mettre en œuvre une passerelle de communication OPC-UA. Cette passerelle communique avec les organes de terrains via des protocoles particuliers (modbus, …) et joue le rôle de serveur OPC-UA pour les clients.
Divers fournisseurs sont présents comme par exemple :
- Advantech / Prosoft / …
- les constructeurs d’automate comme Siemens (SIMATIC IoT2040)
- des passerelles avec un peu d’intelligence (programmable) comme le Modicon M262
- …Le type de passerelle est à choisir en fonction des protocoles terrain dont on a besoin.
Les technologies Low-code / No code peuvent également héberger la stack OPC-UA comme par exemple Node-Red OPC-UA qui intègre des nœuds OPC-UA client et des nœuds OPC-UA server utilisables sur des ordinateurs ou des systèmes embarqués beaucoup plus légers style Raspberry.
Références :
https://reference.opcfoundation.org/
Chez Pingflow en tant que professionnels des écrans de management visuel, nous maîtrisons toutes les finesses des écrans d’affichage dynamique et de management visuel.
N’hésitez pas à nous solliciter pour en savoir plus.
