Conectați OPC UA la Azure IoT Edge / OPC Publisher

Înainte de a începe

• Un runtime IoT Edge pe un gateway care poate ajunge atât la serverele OPC UA, cât și la cloud.
• Un fișier de configurare published-nodes care listează endpointurile și identificatorii de noduri la care să se aboneze.
• Un plan pentru modul în care certificatul publisher-ului va primi încredere pe fiecare server cu care vorbește. Aceasta este partea care întârzie implementările, nu containerul.
• Rețea de ieșire dinspre gateway. Partea OPC UA este doar de intrare din perspectiva publisher-ului, motiv pentru care se potrivește unei rețele stratificate.

Configurarea

1. Scrieți fișierul published-nodesO intrare pentru fiecare endpoint, fiecare cu o listă de identificatori de noduri, intervalele lor de publicare și de eșantionare și, opțional, o bandă moartă. Stocați URI-ul spațiului de nume în identificatorul nodului acolo unde sintaxa permite, în loc de un index brut, astfel încât o descărcare în PLC să nu întrerupă pe tăcute colectarea.
2. Implementați modululImplementați-l ca modul IoT Edge, cu fișierul de configurare și cu un volum persistent pentru directorul lui PKI. Volumul nu este opțional - vedeți capcanele.
3. Acordați încredere publisher-ului pe fiecare serverLa prima conexiune, certificatul publisher-ului ajunge în magazinul de certificate respinse al fiecărui server. Un administrator îl mută în cele de încredere, pe fiecare server. Prevedeți timp real pentru asta la nivel de parc de echipamente sau implementați mai întâi o soluție de gestiune a certificatelor.
4. Alegeți codificarea în mod deliberatPublisher-ul poate emite JSON reversibil sau nereversibil. Cel nereversibil este mai mic și mai ușor de citit, dar elimină informațiile de tip și nu poate fi convertit înapoi. Decideți înainte ca consumatorii din aval să fie scriși pe baza lui.
5. Verificați ce soseșteVerificați mesajele din IoT Hub și confirmați că au supraviețuit codul de stare și SourceTimestamp. În codificarea JSON o stare Good este 0 și este omisă complet, deci un câmp de stare absent înseamnă Good, nu date lipsă - codul din aval trebuie scris știind asta.
6. Reglați înainte de a scalaSetați intervalele de publicare la ceea ce are nevoie consumatorul din cloud, nu la cel mai rapid pe care îl poate da PLC-ul, aplicați benzi moarte pe mărimile analogice și păstrați mic numărul de intervale distincte. Fiecare interval distinct devine încă o abonare pe server.

Cum arată spațiul de adrese

Publisher-ul nu modelează nimic - el transmite mai departe nodurile pe care le enumerați. Semantica rămâne acolo unde ați pus-o, ceea ce în practică înseamnă fie că identificatorii de nod poartă semnificație prin convenție, fie că ceva din aval o reatașează. Dacă mașina implementează o specificație companion, acea structură se pierde dacă nu o codificați în denumirea topicurilor sau a tag-urilor.

Capcanele

• Un volum PKI nepersistent regenerează certificatul aplicației la fiecare repornire a containerului, deci lista de încredere a fiecărui server se învechește la fiecare implementare. Acesta este cel mai frecvent eșec de implementare a OPC Publisher.
• Documentația spune clar că a face echipamentele să accepte certificatul publisher-ului este cel mai mare obstacol cu care se confruntă majoritatea administratorilor OT. Tratați-l ca pe o sarcină de proiect cu un responsabil, nu ca pe un detaliu de configurație.
• JSON-ul non-reversibil pierde în tăcere informația de tip. Un consumator din aval nu poate deosebi un Int32 de un Double, ceea ce contează din momentul în care cineva face aritmetică.
• Reverse connect este acceptat doar pentru opc.tcp, iar publisher-ul ascultă pentru el pe un port configurabil. Util într-o rețea stratificată după modelul Purdue, unde sunt permise doar conexiunile spre exterior.
• Indicii de namespace scriși în clar într-un fișier de noduri publicate se strică după un download de program în PLC. Folosiți URI-uri de namespace acolo unde sintaxa identificatorului de nod o permite.

Cum scoateți date OEE din el

Disponibilitatea, contorizările și motivele ajung toate în cloud dacă mașina le expune, dar publisher-ul transmite valori, nu le interpretează. Tranzițiile mașinii de stare sosesc ca modificări de valoare, deci calculul duratei se face în aval și depinde de intervalul dumneavoastră de publicare - un interval de 10 secunde nu poate rezolva o micro-oprire de 3 secunde. Abonați-vă la evenimentele de condiție din Part 9 pentru motivele de nefuncționare, în loc să interogați un registru de motive. Timpul de producție planificat și contextul comenzii nu se află în mașină și nu vor apărea aici.

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.