Nommage des topics MQTT pour l'OEE: un modèle pour chaque ligne

Points clés

• Nommez les topics depuis l'usine vers le bas : site, area, line, machine, puis la valeur.
• Utilisez des IDs stables, pas des noms affichés, en minuscules et sans espaces.
• Le MQTT "simple" vous laisse choisir l'arborescence. Sparkplug B impose sa propre forme, votre hiérarchie se place dans les IDs.
• Garder le timestamp dans le message, horodaté à la source, pas dans le topic.
• Publiez seulement les changements, ainsi le broker transporte des événements plutôt que du bruit.

MQTT transporte les données d'usine sous forme de messages sur des topics nommés. Pour l'OEE, le nom du topic est la manière dont chaque système ultérieur trouve l'état d'une machine et les compteurs. Choisissez un seul modèle depuis l'usine vers le bas, appliquez-le sur chaque ligne, et ne renommez jamais un topic une fois que des données y circulent.

Fabrico, logiciel OEE et light MES avec caméras IA, journalise automatiquement les arrêts à partir du signal machine, quelle que soit la façon dont ce signal voyage. La manière dont les données atteignent Fabrico sur votre réseau se définit avec l'équipe technique de Fabrico. Ce guide couvre l'aspect de nommage indépendant du fournisseur.

Pourquoi le nommage des topics MQTT importe-t-il pour l'OEE ?

• Les abonnés filtrent par topic. Un bon arbre permet à un seul abonnement de collecter chaque filler d'un site.
• Les rapports se joignent sur les noms. Les IDs de ligne et de machine dans les topics doivent correspondre à ceux du calendrier des équipes.
• L'historique suit le topic. Renommez un topic et les données du mois dernier semblent appartenir à une autre machine.

Un broker MQTT ne vérifie pas les noms pour vous. Le modèle utilisé par la première gateway devient le modèle de l'usine — décidez-le avant que la première ligne soit mise en service.

Quel modèle les topics OEE doivent-ils suivre ?

La plupart des usines suivent les niveaux ISA-95, qui structurent aussi l'idée d'un espace de noms unifié : un seul arbre partagé pour tout le site. Les gateways de périphérie construisent souvent exactement cet arbre à partir des données PLC.

Ainsi, l'état du filler sur la ligne 4 se trouve à plant2/packaging/line4/filler/state. Notre guide du unified namespace couvre l'idée plus large.

Quelles règles gardent les noms de topics propres ?

• Minuscules uniquement. Les topics MQTT sont sensibles à la casse, donc Line4 et line4 sont deux topics différents.
• Pas d'espaces et pas de caractères spéciaux. Utilisez lettres, chiffres et underscore.
• N'utilisez jamais + ou # dans un nom. Ce sont les jokers que les abonnés utilisent.
• Ne commencez pas par une barre ou par $. Les topics commençant par $ sont réservés à l'usage du broker.
• Utilisez des IDs qui ne changent jamais. "filler" reste "filler" quand la machine est remplacée.
• Gardez les unités hors du nom. Mettez l'unité dans le message ou dans la liste de tags, pour qu'un topic ne change pas si l'unité change.
• Notez le modèle par écrit sur une page et donnez-le à chaque intégrateur avant qu'il ne connecte une gateway.

Plain MQTT ou Sparkplug B ?

Avec plain MQTT vous concevez tout l'arbre vous-même, comme ci-dessus. Sparkplug B ajoute un format de topic fixe, un format de payload et un état de session. Ses topics suivent spBv1.0/group_id/message_type/edge_node_id/device_id, et la partie namespace doit être spBv1.0.

Dans Sparkplug, votre hiérarchie d'usine entre dans les IDs. Le groupe pourrait être plant2_packaging, l'edge node line4_gw et le device filler. Les valeurs voyagent comme metrics à l'intérieur du message, pas comme topics séparés. Notre guide sur Sparkplug B explique ses messages de birth et death.

Exemple détaillé : topics pour une ligne

Ligne exemple (chiffres illustratifs, pas un client). La ligne 4 a trois machines : un filler, un capper et un labeller. Chacune publie cinq valeurs : state, total_count, reject_count, fault_code et sku. Cela fait 3 x 5 = 15 topics.

• plant2/packaging/line4/filler/state
• plant2/packaging/line4/capper/fault_code
• plant2/packaging/line4/labeller/total_count

Un abonnement sur plant2/packaging/+/+/state collecte l'état de chaque machine dans packaging. Le joker + correspond exactement à un niveau.

Maintenant le volume. Interroger les 15 valeurs toutes les secondes envoie 15 x 3,600 = 54 000 messages par heure.

Au lieu de cela, publiez états, fautes et SKU seulement lorsqu'ils changent, environ 100 messages par heure. Envoyez les deux compteurs sur chaque machine toutes les 10 secondes: 3 x 2 x 360 = 2 160 messages. Cela fait environ 2 260 messages par heure, soit environ 96% de moins.

Quelles erreurs de nommage posent problème plus tard ?

• Noms affichés dans les topics, comme "Filler (new)", qui changent quand quelqu'un édite un écran.
• Renommer une ligne après un changement de layout, si bien que son historique se divise en deux.
• Mélange de langues ou d'orthographes entre sites, empêchant un rapport de groupe de les joindre.
• Un topic géant portant toute l'usine dans un seul message, que personne ne peut filtrer.
• Pas de timestamp dans le message, si bien que les événements prennent l'heure d'arrivée au lieu de l'heure de survenue.

Publier seulement les changements est l'idée du report by exception. Notre article sur report by exception vs polling en parle, et MQTT in manufacturing couvre le protocole.

Où se situe Fabrico ?

Fabrico est une Manufacturing Performance Platform avec vision par ordinateur. L'OEE et le light MES viennent en premier, sur un seul jeu de noms de lignes et de machines.

• Journalisation automatique des arrêts à partir du signal machine.
• L'opérateur confirme la raison en une seule tape, car un topic transporte un état, pas une cause.
• OEE en direct par ligne et par équipe, chaque perte évaluée en argent.
• Une vue unique sur plusieurs usines, qui ne fonctionne que lorsque les noms correspondent.

C'est la couche OEE d'un light MES. Vous commencez sur une ligne, avec une référence et une date de décision convenues à l'avance. Il n'y a pas de plan gratuit et pas de paliers : chaque usine reçoit un devis.

Foire aux questions

Qu'est-ce qu'une convention de nommage des topics MQTT ?

C'est la règle fixe de l'usine sur la construction des topics, comme site, area, line, machine et value, dans cet ordre. Chaque gateway la suit. Ainsi tout système peut trouver les données d'une machine par son nom, et un rapport peut joindre lignes et usines sans cartographie manuelle.

Les topics MQTT doivent-ils suivre ISA-95 ?

Pour l'OEE c'est un choix sensé. Les niveaux ISA-95 de site, area, line et machine correspondent à la façon dont les usines sont gérées et reportées. La plupart des designs de unified namespace utilisent cet ordre. L'important est de choisir un seul modèle et de l'utiliser partout.

Quel est le format de topic Sparkplug B ?

Les topics Sparkplug B suivent spBv1.0, puis group ID, message type, edge node ID et device ID. La partie namespace doit être spBv1.0. Votre hiérarchie usine va dans les IDs de groupe, node et device, et les valeurs voyagent comme metrics dans le message.

Comment fonctionnent les wildcards MQTT ?

Les abonnés peuvent utiliser deux wildcards. Un plus correspond exactement à un niveau, donc plant2/packaging/+/filler/state correspond au filler de chaque ligne packaging. Un dièse correspond à tous les niveaux restants, donc plant2/# correspond à tout dans ce site.

Le timestamp doit-il être dans le topic ou le message ?

Dans le message. Les topics indiquent d'où proviennent les données ; ils ne doivent pas changer à chaque événement. Horodatez chaque événement avec l'horloge du PLC ou du gateway au moment où il se produit. Mettez cette heure dans le payload, ainsi un message retardé garde son temps réel.

Apportez votre arbre de topics à une démo

Apportez la liste des lignes de votre usine. Nous montrerons les arrêts et compteurs d'une ligne, nommés comme votre usine opère.

Request a demo · Contact us