Conectați OPC UA la Mosquitto / broker MQTT

Înainte de a începe

• Ceva care chiar vorbește OPC UA: un publisher, un colector sau un gateway. Brokerul este o destinație, nu un client, și nicio configurație de broker nu va face un PLC să publice.
• O decizie despre formatul payload-ului înainte să existe primul topic. OPC UA PubSub peste MQTT cu JSON este ruta bazată pe standarde; forma JSON proprie a unui colector și Sparkplug B sunt alternativele obișnuite, iar acestea nu sunt interschimbabile.
• O convenție de denumire a topicurilor agreată cu cine le va consuma, pentru că arborele de topicuri este contractul, iar redenumirea lui ulterioară defectează dintr-o dată fiecare abonat.
• TLS cu certificate reale și autentificare configurate înainte ca ceva din producție să publice. Un broker deschis într-o rețea de fabrică este o fabrică deschisă.

Configurarea

1. Configurați mai întâi brokerul pentru TLS și autentificareSetați un listener explicit, dezactivați accesul anonim, configurați credențiale sau certificate de client și adăugați control de acces pe topicuri pentru fiecare client. Să faceți asta înainte să existe vreun publisher este mult mai ușor decât să o aplicați retroactiv pe o flotă de publisheri.
2. Proiectați ierarhia de topicuri pornind de la fabrică, nu de la spațiul de adreseUn arbore de topicuri derivat mecanic din căile de browsing OPC UA este comod și produce topicuri la care nimeni nu se poate abona util. Derivați-l din sit, zonă, linie și mașină, apoi puneți numele semnalului la frunză. Acolo unde un publisher chiar oferă rutare automată din numele de browsing, țineți cont că trebuie escapate caracterele rezervate MQTT și verificați ce face publisher-ul cu ele.
3. Alegeți și fixați codificarea payload-uluiDacă folosiți OPC UA PubSub peste MQTT, decideți între UADP și JSON, iar dacă alegeți JSON, între forma reversibilă și cea nereversibilă. JSON-ul nereversibil pierde informația de tip și nu poate fi reconstruit, ceea ce este o surpriză care apare peste luni de zile la un consumator din aval.
4. Decideți mesajele reținute și last will pe clasă de topicMesajele reținute îi dau imediat unui abonat nou valoarea curentă, ceea ce este corect pentru stare și identitate și greșit pentru evenimente, unde un mesaj reținut redă ceva ce s-a întâmplat deja. Configurați un topic last-will pentru fiecare publisher, astfel încât un colector căzut să fie vizibil.
5. Setați calitatea serviciului potrivit semnificației datelorCalitatea serviciului 0 este în regulă pentru o valoare analogică de frecvență mare pe care oricum o veți reeșantiona și este inacceptabilă pentru un eveniment de oprire sau pentru incrementarea unui contor, pentru că o sincopă de rețea pur și simplu îl pierde. Folosiți at-least-once pentru orice depinde un calcul și faceți consumatorii idempotenți.
6. Verificați sarcina utilă cu un client înainte de a construi consumatoriAbonați-vă cu MQTT Explorer sau cu un client de linie de comandă și citiți octeții reali de pe fir. Rețineți în special că, în codificarea JSON OPC UA, o stare Good este valoarea zero și este omisă, deci un câmp de stare lipsă înseamnă stare bună, nu date lipsă.
7. Monitorizați brokerul și publisher-ele separatUrmăriți numărul de conexiuni la broker și mesajele pierdute și generați alerte privind starea publisher-elor prin topicuri de tip last-will sau printr-un topic de heartbeat pentru fiecare mașină. Tăcerea pe un topic este ambiguă și are nevoie de un semnal independent ca să fie interpretată.

Cum arată spațiul de adrese

MQTT nu are model, ci doar un șir de topic și o sarcină utilă, așa că tot ceea ce știa spațiul de adrese OPC UA trebuie re-exprimat de ceea ce publică. Aceasta este decizia centrală de proiectare a unui spațiu de nume unificat: ierarhia de topicuri plus schema sarcinii utile reprezintă întregul model informațional pentru toți consumatorii. OPC UA PubSub transportă metadatele setului de date alături de date, ceea ce păstrează tipurile și numele câmpurilor și este motivul pentru care calea bazată pe standarde merită configurarea suplimentară; JSON-ul unui colector ad-hoc de obicei nu le păstrează, iar atunci semnificația unui câmp se află într-un document, undeva. Indiferent ce alegeți, publicați URI-ul spațiului de nume OPC UA și identificatorul nodului în sarcina utilă sau în metadatele topicului, astfel încât o valoare să poată fi urmărită înapoi până la nodul din care provine.

Capcanele

• Tratarea brokerului ca fiind integrarea în sine este greșeala clasică. Brokerul mută octeți; semantica vine din proiectarea topicurilor și a payload-ului de către publisher, iar acea proiectare este locul unde se află munca reală a proiectului.
• Calitatea serviciului 0 pe date de tip eveniment pierde evenimente fără să anunțe, exact în condițiile de rețea care produc cele mai interesante evenimente. Înregistrările de opriri și incrementările de contoare au nevoie de livrare at-least-once.
• Mesajele reținute pe topicuri de evenimente redau evenimente vechi fiecărui nou abonat, ceea ce corupe consumatorii care presupun că un mesaj înseamnă acum.
• Codificarea JSON non-reversibilă pierde informația de tip și nu poate fi parcursă dus-întors. Alegeți deliberat și consemnați alegerea; descoperirea ei în aval este costisitoare.
• În codificarea JSON din OPC UA, o stare Good este zero și este omisă, așa că un consumator care tratează un câmp de stare lipsă drept date lipsă va elimina valori bune.
• Arborii de topicuri derivați automat din căile de navigare codifică structura internă a PLC-ului în spațiul de nume al întregii fabrici și se schimbă atunci când se schimbă programul PLC.
• Brokerul devine un punct unic de defectare la nivel de fabrică și o graniță de securitate la nivel de fabrică. Puneți-l în cluster sau acceptați explicit riscul și nu lăsați niciodată accesul anonim activat pentru că a fost comod la punerea în funcțiune.
• MQTT nu oferă nicio garanție de ordonare între topicuri diferite. O schimbare de stare și contorizarea care îi corespunde pot ajunge în altă ordine dacă sunt publicate pe topicuri separate, așa că puneți în același mesaj faptele care trebuie să fie consecvente între ele.

Cum scoateți date OEE din el

Brokerul nu contribuie cu nimic la OEE prin el însuși și îl poate deteriora pe tăcute. Ceea ce face bine este să decupleze colectarea de calcul, astfel încât o platformă de analiză să poată consuma starea mașinii, contorizările și motivele fără a menține sesiuni către fiecare PLC. Cerințele pe care le impune sunt concrete: publicați tranzițiile de stare ca evenimente, cu marcajul de timp propriu al mașinii în payload, în loc să vă bazați pe momentul sosirii; publicați incrementele de contorizare sau contoarele absolute cu suficient context pentru a detecta resetările; folosiți livrare at-least-once pentru ambele; și dați fiecărei mașini un topic de heartbeat sau last-will, astfel încât tăcerea să poată fi deosebită de o mașină oprită. Timpul de producție planificat, calendarele de schimb, contextul comenzii și timpii de ciclu standard nu sunt date de mașină și trebuie să ajungă la calcul din MES sau ERP, nu prin publicare manuală pe un topic și apoi uitare.

Verificat ultima dată la 7 septembrie 2026 față de OPC UA 1.05.07. OPC UA Connect este o resursă educațională și nu este afiliată cu OPC Foundation.