PROFINET, EtherNet/IP, EtherCAT, OPC UA et MQTT : à chacun son rôle

En bref :

utilisez

PROFINET, EtherNet/IP ou EtherCAT

lorsqu’un API (PLC) ou contrôleur de mouvement doit échanger périodiquement des données de procédé avec un robot, un variateur ou des E/S, selon des délais prévisibles. Choisissez

OPC UA

pour présenter des informations machine structurées aux logiciels de supervision et

MQTT

pour diffuser événements et télémétrie à plusieurs applications via un broker de publication/abonnement. Ces technologies ne sont pas interchangeables : une usine bien conçue peut les combiner. Le bon choix dépend avant tout des contrôleurs en place, de leurs interfaces et licences, des données à échanger et du comportement attendu en cas de perte de communication — pas d’un chiffre de vitesse annoncé.

Guide d’ingénierie mis à jour le 13 octobre 2026. Comparaison fondée sur les normes et les documentations publiées, et non sur des mesures en laboratoire ni sur une certification de compatibilité d’un modèle précis de robot et d’API.

En un coup d’œil : quel protocole de communication industrielle choisir ?

Règle pratique :

choisissez un protocole

par interface

, et non un seul pour toute l’usine. Un API peut piloter un robot en PROFINET, tandis qu’une passerelle lit les données OPC UA et publie certains événements en MQTT.

Même câble Ethernet, métiers très différents

L’Ethernet industriel regroupe plusieurs technologies et non un langage universel. Un connecteur ressemblant à du RJ45, un câble Ethernet ou une infrastructure partagée ne rendent pas automatiquement deux appareils compatibles. Leurs rôles, piles protocolaires, mécanismes temporels, adressages et données applicatives diffèrent.

La séparation essentielle concerne les

données de commande cycliques

et les

informations de supervision

. Les premières sont actualisées régulièrement pour permettre au contrôleur d’exécuter la séquence machine avec des entrées et sorties à jour. Les secondes alimentent des outils qui ont besoin d’historique et de contexte : MES, SCADA, maintenance ou analytique.

Un robot peut attendre un mot de commande actualisé à chaque intervalle d’E/S configuré. Un tableau de production, lui, a surtout besoin de connaître le début et la fin des cycles ou l’apparition d’un défaut. Transporter tous ces événements dans la table d’E/S cycliques complique inutilement l’intégration ; utiliser un message MQTT classique comme unique interverrouillage temporel critique serait une erreur d’architecture.

Le déterminisme ne se résume pas à la vitesse.

La prévisibilité et les limites de temps comptent autant que le débit moyen. La réaction effective comprend l’actualisation réseau, la périodicité de la tâche API, le traitement du contrôleur robot et la logique applicative. Un réseau rapide ne compense pas une séquence lente ou mal conçue.

1. PROFINET : la commande cyclique dans les architectures à API

PROFINET

, maintenu par PROFIBUS & PROFINET International (PI), est destiné à l’automatisation industrielle : données cycliques de procédé, diagnostics et intégration dans les outils d’ingénierie. Habituellement, l’API est l’

IO-Controller

et le contrôleur robot ou la station d’E/S déportées est un

IO-Device

. Ils échangent les données d’entrée et de sortie configurées.

Fonctionnement de PROFINET

PROFINET prend en charge des E/S cycliques en temps réel. Parmi ses mécanismes figurent

RT (Real Time)

, adapté à de nombreuses applications d’automatisation, et

IRT (Isochronous Real Time)

, pour des besoins de synchronisation plus stricts lorsqu’il est disponible. PI développe également des capacités liées au Time-Sensitive Networking (TSN). Ce ne sont pas de simples cases à cocher : le contrôleur, le périphérique, le firmware et le réseau retenus doivent réellement les prendre en charge.

En plus des E/S cycliques, les techniciens utilisent l’identification des appareils, les alarmes, les diagnostics et le paramétrage. L’intégration repose généralement sur un fichier

GSDML

, description XML du périphérique PROFINET présentant modules, tailles de données et fonctionnalités au logiciel d’ingénierie.

Exemple : un API et un robot en PROFINET

L’API peut envoyer une condition d’autorisation, un numéro de programme et une demande de démarrage. Le robot retourne prêt, occupé, terminé et défaut. Le contrat de signaux précise la signification de chaque bit, son propriétaire et la reprise après interruption. PROFINET transporte des octets,

mais ne définit pas la logique d’échange (« handshake ») propre au fabricant du robot

.

Quand choisir PROFINET :

si l’installation l’utilise déjà, si le contrôleur robot possède le rôle IO-Device requis et si l’environnement API accepte le GSDML et le mapping exacts. La prise en charge de PROFINET ne signifie pas automatiquement disponibilité de PROFIsafe, d’IRT ou de fonctions de mouvement.

2. EtherNet/IP : la commande CIP sur des réseaux Ethernet/IP

EtherNet/IP

, maintenu par ODVA, transporte le

Common Industrial Protocol (CIP)

sur des technologies standard Ethernet et Internet. Il sert aux échanges d’E/S et de diagnostics. Son nom ne désigne pas une liaison Ethernet générique et n’implique aucune compatibilité directe avec PROFINET.

E/S cycliques et messages explicites

CIP distingue l’échange de données d’E/S, souvent appelé

implicit messaging

, de l’accès par requête/réponse aux objets d’un équipement, appelé

explicit messaging

. Les E/S cycliques utilisent couramment UDP, et les messages explicites TCP. Les connexions échangent des

assemblies

d’octets dont le sens dépend du modèle de données et du paramétrage du dispositif.

Dans une liaison API–robot typique, l’API est un

I/O scanner

et l’interface du robot un

adapter

. Terminologie et modes de connexion peuvent varier selon le fabricant et la génération. Le fichier

EDS (Electronic Data Sheet)

aide à intégrer l’appareil, mais il faut aussi vérifier les instances d’assembly, les longueurs d’entrée et sortie, le chemin de connexion et l’intervalle de paquets demandé (

RPI

). Un EDS seul n’assure pas une intégration complète et automatique.

ODVA spécifie aussi CIP Safety, CIP Motion, CIP Sync et CIP Security. Leur existence dans cette famille de protocoles

ne prouve pas leur disponibilité sur un robot donné

.

Quand choisir EtherNet/IP :

si l’architecture API fonctionne avec CIP, si le robot ou le préhenseur offre le bon rôle adapter et si les tailles, le mapping et les intervalles ont été vérifiés. Un ping confirme simplement l’accessibilité IP, pas une connexion cyclique opérationnelle.

3. EtherCAT : traitement à la volée et synchronisation

EtherCAT

, soutenu par l’EtherCAT Technology Group (ETG), adopte un fonctionnement différent. Un

MainDevice

envoie une trame dans un segment ; chaque

SubDevice

lit ses sorties et insère ses entrées pendant le passage de la trame. Ce traitement

on-the-fly

évite de multiplier les échanges individuels et convient au contrôle distribué exigeant.

Pourquoi EtherCAT n’est pas du TCP/IP ordinaire

Les trames classiques de données de procédé utilisent le format Ethernet, généralement identifié par EtherType

0x88A4

. Ce

ne sont pas des paquets TCP ou UDP habituels

. Un commutateur bureautique, un routeur IP ou un broker MQTT ne fait pas automatiquement partie d’un segment EtherCAT valable. Le matériel et la topologie doivent respecter l’architecture prévue.

Les

Distributed Clocks (DC)

peuvent synchroniser des équipements compatibles, par exemple plusieurs servovariateurs. Ils ne rendent pas automatiquement possible une coordination de mouvement entre n’importe quels robots.

La configuration fait généralement appel au fichier XML

ESI (EtherCAT SubDevice Information)

. Il faut vérifier les objets de données, états opérationnels, modes de synchronisation, interfaces physiques et versions de firmware. Certaines implémentations demandent également des fonctions spécifiques du constructeur.

Quand choisir EtherCAT :

lorsque la machine repose sur EtherCAT, que le mouvement distribué ou la synchronisation sont utiles et que tous les éléments — interface robot comprise — acceptent les rôles et fonctions nécessaires. Une valeur théorique de cycle ne suffit pas à justifier ce choix.

4. OPC UA : des informations machine riches de sens

OPC Unified Architecture (OPC UA)

, développé par l’OPC Foundation, est une architecture de communication industrielle indépendante des plateformes. Elle représente machines, propriétés, relations et méthodes dans des modèles que les logiciels peuvent parcourir et interpréter. Elle utilise couramment client/serveur, et peut proposer publication/abonnement lorsque cela est implémenté. Le standard prévoit aussi authentification, chiffrement et autorisation.

L’intérêt des modèles d’information

Imaginez un MES qui souhaite connaître le mode de fonctionnement du robot, son programme sélectionné, son alarme active et son nombre de pièces produites. Dans un simple tableau d’E/S d’API, ces valeurs ne seraient que des offsets et numéros de bits. Un serveur OPC UA peut proposer des objets nommés, des types et des relations explicites. Il faut toujours connaître le modèle concret, mais l’intégration ne dépend plus uniquement d’une liste d’octets sans contexte.

Pour la robotique,

OPC 40010-1, OPC UA for Robotics – Part 1: Vertical Integration

définit un modèle destiné aux systèmes de niveau supérieur. La référence officielle mentionne la

version 1.02, publiée le 8 septembre 2025

. Un fournisseur peut annoncer un serveur OPC UA sans implémenter ce modèle complémentaire ni toutes ses fonctions facultatives.

OPC UA sert-il uniquement à surveiller ?

Non. OPC UA prend en charge lecture, écriture, méthodes et publication/abonnement. Les travaux

Field Level Communications / OPC UA FX

étendent son champ vers les communications de terrain, y compris des exigences de temps réel. Il faut donc nuancer : même si OPC UA se trouve souvent au-dessus du réseau de commande dans une cellule classique, il n’est pas intrinsèquement incapable de contrôler. Tout usage de commande dépend des profils, dispositifs et performances temporelles réellement validés.

Quand choisir OPC UA :

si plusieurs plateformes doivent disposer de données structurées, explorables et protégées. Paramétrez certificats, authentification, permissions, points de terminaison sécurisés et portée des lectures/écritures. La présence d’OPC UA n’autorise pas automatiquement un MES à déclencher un mouvement.

5. MQTT : diffuser les événements de production

MQTT

est un protocole de messagerie publication/abonnement normalisé par OASIS. Un dispositif ou logiciel edge publie sur un

topic

; un broker redistribue le message aux abonnés intéressés. L’émetteur n’a pas besoin de joindre directement chaque tableau de bord, base de données ou service analytique.

Exemple de topic et de payload MQTT

Une passerelle pourrait publier vers

factory/bilbao/cell-03/robot-01/status

le JSON illustratif suivant :

{
  "schema_version": 1,
  "asset_id": "robot-01",
  "timestamp_utc": "2026-10-13T12:00:00Z",
  "state": "running",
  "program_id": "job-024",
  "parts_completed": 1842,
  "source_quality": "good"
}

Données uniquement illustratives, non mesurées sur un équipement réel.

MQTT ne précise pas ce que signifient

state

,

program_id

ou

parts_completed

. Le contrat d’intégration doit spécifier unités, types, horodatages, identifiants d’événements, propriétaires, versions de schéma et traitement des données périmées.

Ce que garantissent les niveaux QoS de MQTT

• 
  QoS 0 :
  
  au maximum une livraison au niveau MQTT ; le message peut être perdu.
• 
  QoS 1 :
  
  au moins une livraison au niveau MQTT ; des doublons sont possibles.
• 
  QoS 2 :
  
  exactement une livraison dans l’échange MQTT concerné, avec davantage de surcharge. Cela ne garantit pas l’exécution exactement une fois d’une transaction de base de données ou d’une action physique du robot.

Un message conservé (

retained

) affiche utilement le dernier état, mais celui-ci peut être ancien. Sessions persistantes, nouvelles tentatives et expiration des messages doivent être réglées volontairement. Prévoyez horodatages, règles de fraîcheur et, au besoin, identifiants d’événements ou clés d’idempotence. Sécurisez avec clients authentifiés, TLS si approprié, droits par topic et accès restreint au broker.

Quand choisir MQTT :

pour distribuer événements de fonctionnement, alertes de maintenance et télémétrie historique. Un service cloud capable de publier un topic ne remplace ni le handshake cyclique API–robot ni une fonction de sécurité validée.

Comment ces technologies cohabitent dans une cellule robotisée

Prenons une cellule d’emballage comprenant robot industriel, API, préhenseur, capteurs et tableau de supervision. Une architecture possible distingue :

1. 
   Commande machine :
   
   l’API échange ordres et états avec le robot par un bus de terrain cyclique pris en charge. Le contrôleur robot exécute son programme validé. Variateurs et E/S peuvent utiliser ce réseau ou un autre réseau de terrain.
2. 
   Sécurité fonctionnelle :
   
   un système conçu séparément surveille les protecteurs et arrêts sécurisés ; selon l’analyse de risques, il emploie des E/S filaires de sécurité ou un protocole compatible certifié.
3. 
   Données opérationnelles structurées :
   
   robot, API ou passerelle publient certains états et diagnostics par OPC UA avec des droits d’écriture limités.
4. 
   Diffusion d’événements :
   
   une passerelle autorisée transforme les changements d’état sélectionnés en événements MQTT et les transmet au broker, sans intégrer ce dernier à la boucle de commande indispensable.
5. 
   Applications métier :
   
   MES, maintenance et analytique exploitent ces informations pour traçabilité, TRS/OEE et dépannage.

Ce n’est pas un modèle imposé à tous. Certains sites communiquent directement entre API et MES, utilisent un historien ou n’emploient pas MQTT. Une passerelle doit résoudre un problème réel, et non ajouter un service supplémentaire qui peut tomber en panne.

Exemple pratique : un handshake API–robot robuste

Le protocole transporte le signal ; le

contrat d’interface

définit le comportement de la machine. Voici un exemple pour un cycle robot de prise et dépose. Les noms et directions sont conceptuels : ils ne constituent ni un standard ni un mapping constructeur.

Séquence possible :

l’API valide les préconditions normales de la machine, sélectionne le programme, présente un identifiant de commande inédit et demande le cycle. Le robot indique la commande acceptée, passe à occupé puis signale la fin pour ce même identifiant. L’API ne demande rien de nouveau avant d’avoir rapproché l’ordre précédent de son résultat. Un démarrage, une temporisation expirée ou une rupture de liaison ne doit jamais transformer une ancienne demande en nouveau mouvement.

Le contrat doit gérer retour de l’alimentation, arrêts d’urgence, arrêts de protection, redémarrages, changements de programme, défauts simultanés et mode manuel. Les bits applicatifs

Ready

et

Heartbeat


ne sont pas des signaux de sécurité certifiés

, sauf conception et validation spécifiques dans une architecture de sécurité appropriée. Les états du bus de terrain ordinaire ne prouvent pas que la cellule est sûre.

Ne pas confondre E/S, mouvements et sécurité fonctionnelle

Trois questions d’ingénierie sont souvent mélangées :

• 
  Handshake d’E/S standard :
  
  échange de demandes, états, numéros de programme et diagnostics ; un petit bloc cyclique peut suffire.
• 
  Coordination de mouvement :
  
  synchronisation d’axes, suivi de convoyeur ou mouvements coordonnés de robots. Des options constructeur, horloges synchronisées, profils pris en charge ou interfaces propriétaires peuvent être nécessaires, au-delà d’un cycle d’E/S plus court.
• 
  Sécurité fonctionnelle :
  
  détection des situations dangereuses et exécution de fonctions validées. Les protocoles peuvent inclure
  
  PROFIsafe
  
  ,
  
  CIP Safety
  
  ou
  
  Safety over EtherCAT (FSoE)
  
  avec équipements de sécurité compatibles, conception et validation adaptées.

Logique de sécurité, communication de sécurité,

Safe Torque Off

, arrêt de protection et arrêt d’urgence ne sont pas synonymes. Leurs fonctions, niveaux de performance et conditions de redémarrage dépendent de l’analyse de risques et des normes applicables.

Choisir le bon protocole en six étapes

1. 
   Inventorier les équipements exacts.
   
   Relevez CPU de l’API, contrôleur robot, E/S, variateurs, versions de firmware, cartes réseau et licences réellement installées. La marque d’un robot ne garantit pas toujours les mêmes interfaces.
2. 
   Définir le rôle de chaque donnée.
   
   Classez les échanges en commandes/états cycliques, mouvement, communication liée à la sécurité, diagnostic ou télémétrie de gestion.
3. 
   Contrôler les rôles réseau.
   
   Distinguez PROFINET IO-Controller/IO-Device, EtherNet/IP scanner/adapter et EtherCAT MainDevice/SubDevice. Deux appareils qui annoncent le même protocole peuvent avoir des rôles incompatibles.
4. 
   Demander les preuves d’intégration.
   
   Obtenez GSDML, EDS et paramètres de connexion, ou ESI. Pour OPC UA : endpoints, namespaces et profils de sécurité ; pour MQTT : contrat du broker et des payloads.
5. 
   Spécifier délais et défaillances.
   
   Fixez intervalles, fraîcheur, temporisations et état de machine après une perte de liaison ou un redémarrage. Distinguez temps de cycle API, traitement robot et sécurité.
6. 
   Valider une liaison minimale au banc.
   
   Établissez la connexion, échangez des E/S représentatives, vérifiez types et ordre des octets, puis provoquez une déconnexion et un redémarrage avant le choix définitif.

Trois situations d’achat fréquentes

Cas A : installation déjà en PROFINET.

Si le robot offre une option IO-Device compatible, conserver ce bus peut simplifier ingénierie, pièces de rechange et maintenance. Vérifiez la licence installée, pas seulement la brochure.

Cas B : environnement API basé sur CIP.

L’interface adapter EtherNet/IP du robot peut représenter la voie la plus simple. Vérifiez assemblies, tailles, RPI et réactions aux pannes avant d’écrire le programme API.

Cas C : machine EtherCAT avec plusieurs servomoteurs.

EtherCAT peut convenir aux variateurs et E/S, tandis qu’un robot industriel autonome utilise un autre bus pour son handshake de programmes si son contrôleur l’exige. Une machine peut légitimement posséder plusieurs réseaux de terrain.

Ce qui compte davantage que les temps de cycle annoncés

Les valeurs théoriques impressionnantes des fabricants peuvent être vraies pour certains montages, mais ne décrivent pas la cellule complète. Distinguez :

• 
  Intervalle d’actualisation du bus :
  
  fréquence des échanges de données configurées.
• 
  Gigue (
  
  jitter
  
  ) :
  
  variation temporelle des arrivées ou exécutions.
• 
  Période de tâche API :
  
  lecture des entrées, calcul et écriture des sorties.
• 
  Réaction du contrôleur robot :
  
  moment où le logiciel détecte l’entrée et change d’état.
• 
  Réponse physique :
  
  temps supplémentaire avant que l’actionneur réagisse dans la séquence validée.

Pour un handshake début/occupé/terminé, prévisibilité, diagnostics et compatibilité importent souvent davantage qu’un gain infime sur le cycle réseau. Les variateurs synchronisés changent l’équilibre. Si la temporisation est critique, mesurez-la sur le matériel retenu : le nom du protocole n’est pas une mesure.

Segmentation réseau, accès distant et cybersécurité

OPC UA et MQTT offrent de la visibilité, mais créent aussi de nouvelles possibilités d’accès. Une défense en profondeur sépare le réseau de commande des systèmes de supervision et d’entreprise, n’ouvre que les flux nécessaires et empêche qu’une panne analytique se transforme en défaillance de commande.

• 
  Segmentation :
  
  définissez zones machine, supervision et entreprise, avec routage contrôlé et pare-feu appropriés.
• 
  Identités :
  
  utilisez des comptes de service dédiés, permissions minimales et pas de mots de passe partagés par défaut ni de clients anonymes illimités.
• 
  Certificats et chiffrement :
  
  configurez les modes de sécurité OPC UA, certificats de confiance et transport sécurisé MQTT ; surveillez les expirations.
• 
  Moindre privilège :
  
  exposition en lecture seule par défaut ; les écritures distantes passent par un flux de commandes autorisé et journalisé.
• 
  Défaillances indépendantes :
  
  la perte du cloud, du broker, de l’historien ou du SCADA ne doit jamais produire un état machine dangereux.
• 
  Maintenance :
  
  conservez sauvegardes, plans réseau, informations constructeur et procédure maîtrisée pour mises à jour et identifiants.

Ce guide ne constitue pas un audit de cybersécurité d’usine. Les protections réelles dépendent de l’analyse des menaces, des contraintes de production, des obligations applicables et du matériel présent.

Mise en service : les essais à documenter

• 
  Identité des appareils :
  
  contrôleur, firmware, modules et licences attendus sont présents.
• 
  Configuration :
  
  fichiers, ordre des modules, assemblies et ordre des octets/bits concordent.
• 
  Rôles/adressage :
  
  chaque interface joue effectivement son rôle contrôleur/périphérique ou client/serveur.
• 
  Handshake nominal :
  
  sélection, prêt, demande, accepté, occupé et terminé sont cohérents aux deux extrémités.
• 
  Entrées invalides :
  
  programmes inconnus, valeurs malformées ou commandes contradictoires sont rejetés ou traités sans danger.
• 
  Perte de communication :
  
  la déconnexion provoque l’alarme et la réaction prévues ; la reconnexion n’entraîne pas de mouvement inattendu.
• 
  Remise sous tension :
  
  API, robot et passerelle rapprochent les états et suppriment les anciennes demandes.
• 
  Fraîcheur des données :
  
  abonnés OPC UA/MQTT différencient état actuel, déconnecté et périmé.
• 
  Contrôle d’accès :
  
  écritures, publications et connexions interzones non autorisées sont refusées.
• 
  Validation de sécurité :
  
  un personnel qualifié vérifie séparément fonctions de sécurité, défauts et redémarrage.

Archivez la matrice d’interface approuvée et les résultats des essais avec les schémas électriques, le programme API et les sauvegardes robot. Personne ne devrait devoir deviner le sens d’un bit en observant une machine en production.

Questions fréquentes

PROFINET ou EtherNet/IP : lequel est meilleur ?

Aucun n’est universellement supérieur. Les deux conviennent à de nombreuses liaisons cycliques entre API et robot. Le parc d’API, les options du contrôleur robot, les outils, les rôles et les besoins de maintenance orientent généralement le choix. Validez l’ensemble concret plutôt que de comparer des vitesses nominales.

EtherCAT est-il plus rapide que PROFINET ?

EtherCAT cible les échanges déterministes efficaces et les équipements synchronisés. PROFINET possède lui aussi plusieurs mécanismes temps réel, notamment IRT. Sans appareils, topologie, cycles configurés et tâche complète identifiés, un classement générique de vitesse n’apporte pas de réponse d’ingénierie.

Un API et un robot peuvent-ils communiquer directement en OPC UA ?

Oui, s’ils disposent de fonctions OPC UA compatibles et si l’application est conçue pour cela. Mais un serveur OPC UA ne fournit pas automatiquement une interface d’E/S cycliques adaptée ni une chaîne de sécurité validée. Examinez précisément la fonction demandée et son implémentation.

MQTT peut-il démarrer ou arrêter un robot industriel ?

Une application peut recevoir une commande MQTT, mais MQTT seul n’assure ni commande de mouvement déterministe et sûre ni arrêt de sécurité. Les commandes distantes exigent autorisation, vérification d’état par l’API ou le robot et mécanismes machine validés. Les fonctions de sécurité ne doivent pas dépendre de MQTT classique.

Peut-on utiliser le même switch avec PROFINET, EtherNet/IP et EtherCAT ?

Ne le supposez pas. Certaines installations PROFINET et EtherNet/IP peuvent utiliser une infrastructure Ethernet industrielle managée adaptée, sous réserve de contraintes de protocole, temps et topologie. Les échanges cycliques EtherCAT fonctionnent autrement et exigent un segment compatible. Des câbles identiques n’impliquent aucune interopérabilité.

À quoi servent les fichiers GSDML, EDS et ESI ?

Ce sont des descriptions des appareils destinées aux outils d’ingénierie :

GSDML

pour PROFINET,

EDS

pour de nombreuses intégrations EtherNet/IP et

ESI

pour EtherCAT. Ils facilitent la configuration des données, paramètres et identités, sans remplacer la vérification du firmware, des rôles et du sens applicatif des signaux.

Conclusion : définir d’abord la frontière de commande

Une bonne architecture de départ peut combiner

bus cyclique pour les séquences machine, fonctions de sécurité validées séparément, données structurées OPC UA pour la supervision et MQTT uniquement lorsque la diffusion d’événements par broker apporte une valeur réelle

. C’est un modèle de réflexion, non une obligation universelle. La réussite dépend des interfaces effectivement installées, d’un contrat de signaux sans ambiguïté et d’un comportement testé lors des défaillances.

Avant d’acheter une carte réseau ou une licence, le document le plus utile est parfois une seule page indiquant

qui possède chaque signal, sur quel réseau il passe, combien de temps il reste valable et ce qui se produit lorsqu’il disparaît

.

Sources et vérifications complémentaires

Documentation primaire des organismes de normalisation consultée pour cette mise à jour :

• 
  PROFIBUS & PROFINET International — technologie PROFINET
  
  : variantes temps réel, diagnostics, PROFIsafe.
• 
  PI — spécification GSDML pour PROFINET
  
  : descriptions XML PROFINET et fichiers GSD PROFIBUS.
• 
  ODVA — EtherNet/IP
  
  : architecture CIP et communication cyclique sur UDP.
• 
  EtherCAT Technology Group — technologie EtherCAT
  
  : traitement à la volée, Distributed Clocks, sécurité.
• 
  ETG — EtherCAT Compendium
  
  : états, ingénierie et mise en œuvre.
• 
  OPC Foundation — OPC Unified Architecture
  
  : modèles d’information et sécurité.
• 
  OPC Foundation — OPC UA for Robotics, Part 1
  
  : version 1.02 du 8 septembre 2025.
• 
  OPC Foundation — Field Level Communications / OPC UA FX
  
  .
• 
  OASIS — MQTT Version 5.0
  
  : norme du 7 mars 2019.

Note de vérification :

ces références fondent les principes et spécifications publiés, pas les options réellement installées ni la compatibilité de deux appareils non identifiés, et elles ne constituent pas des mesures sur une usine donnée. Sources vérifiées le 13 octobre 2026.

Vous préparez l’intégration d’un robot avec un API ?

Commencez par identifier le contrôleur du robot, le modèle d’API, les firmwares, les options de bus et les signaux à échanger. Retrouvez d’autres dossiers sur

AYXWORKS Robotics & Automation

, notamment sur la

prise de pièces guidée par vision et sa récupération

. La faisabilité et le partage des responsabilités peuvent être examinés avec Eurobots/ReBots ; découvrez également le

portfolio AYXWORKS

.

Pour échanger :

quelle interface vous a posé le plus de problèmes à la mise en service : mapping PROFINET, assemblies EtherNet/IP, réglages EtherCAT, sécurité OPC UA ou cohérence des payloads MQTT ?

Illustration intégrée : schéma explicatif original AYXWORKS. Il ne remplace pas un plan réseau propre au projet. Conservez les crédits de l’image mise en avant selon sa licence effective.