Kui veedate aega tööstusliku asjade Interneti ümber, olete kuulnud sama arutelu ikka ja jälle. Kas kasutada MQTT-d või OPC UA-d? Küsimus raamitakse võistlusena, justkui üks protokoll peab võitma ja teine kaotama. Praktikas on see raamimine vale. MQTT ja OPC UA olid loodud põhimõtteliselt erinevate probleemide lahendamiseks ning enamik IIoT tootmisarhitektuure kasutavad lõpuks mõlemat – sageli samal ajal, samas lüüsis.
See artikkel selgitab lahti, mida iga protokoll tegelikult hästi teeb, kus need lagunevad ja kuidas otsustada, milline neist kuulub teie andmekonveieri kummale poole.
TL;DR
- MQTT liigutab baite. See on kerge transpordivahend avaldamiseks/tellimiseks, kasuliku koormuse agnostiline ja ideaalne piiratud võrkude ja pilve telemeetria jaoks.
- OPC UA liigutab tähendust. See on täielik teabe modelleerimise raamistik, millel on sisseehitatud turvalisus, semantilised andmed ja leitavus – loodud tehase põrandate koostalitlusvõimeks.
- Need ei välista üksteist. OPC UA PubSub (14. osa) võib töötada üle MQTT, pakkudes teile semantilisi andmeid kerge pubi/subi peal.
- Tüüpiline IIoT lüüs räägib OPC UA-d (või Modbus, EtherNet/IP, S7) lõunaküljel ja avaldab seejärel põhjapoolsel küljel MQTT maakleritele.
Kaks erinevat päritolu, kaks erinevat mõtteviisi
MQTT sündis 1999. aastal IBM-is, mille kujundasid Andy Stanford-Clark ja Arlen Nipper naftajuhtmete jälgimiseks satelliidiühenduste kaudu. Piirangud kujundasid selle kõike: eeldage, et võrk on aeglane, kallis ja ebausaldusväärne; oletagem, et seade on väike; hoia protokolli päist mikroskoopilisena; las rakendus otsustab, mida kasulikku koormasse panna. Kaks aastakümmet hiljem sai MQTT 3.1.1-st ISO standard (ISO/IEC 20922) ja MQTT 5 lisas funktsioone, mida tänapäevased pilvarhitektuurid ootavad – kasutaja omadused, sõnumite aegumine, jagatud tellimused, põhjuskoodid.
OPC UA tekkis teisest maailmast. OPC Foundation avaldas esimese spetsifikatsiooni 2008. aastal OPC Classicu (OLE for Process Control) järglasena, mis sidus tööstuse Microsoft DCOM-iga. Mandaat oli see sõltuvus katkestada, lahendades samal ajal raskema probleemi: kuidas panna Siemensi PLC, Beckhoffi liikumiskontroller, B&R servoajam ja Rockwelli DCS üksteist semantiliselt mõistma, mitte ainult töötlemata baite vahetama? OPC UA vastus oli teabemudel – ennast kirjeldav aadressiruum, kus andmetel on tüübid, seosed ja tähendus.
Need päritolulood selgitavad peaaegu iga järgnevat disainiotsust.
Arhitektuur
MQTT on maaklerikeskne ja lahutatud. Väljaandjad saadavad teemadele sõnumeid. Tellijad registreerivad huvi teemade vastu. Keskmaakler fännab liiklust. Väljaandjad ja tellijad ei tea kunagi teineteisest otse. Maakler võib olla väike sisseehitatud Mosquitto eksemplar või rühmitatud HiveMQ juurutus, mis käsitleb miljoneid kliente – protokoll ei hooli.
OPC UA oli algselt klient-server. Klient avab seansi serveriga ja väljastab seejärel teenuseid: aadressiruumi uurimiseks sirvige, sõlme väärtustele juurdepääsemiseks käsud "Lugege" ja "Kirjutage", muudatustest teavitamiseks käsku "CreateSubscription". Server on olekupõhine ja autoriteetne. See töötas LAN-is hästi, kuid ei ulatunud pilve stiilis ventilaatorini.
OPC UA 14. osasse lisati 2018. aastal PubSub, mis toetab nii maakleripõhist transporti (MQTT, AMQP) kui ka maaklerita (UDP multicast). See oli sihtasutuse kinnitus, et maailm on puhtalt klient-serverilt edasi liikunud.
Protocol selection by design axis
bar chartAndmemudelid
Siin erinevad kaks protokolli kõige teravamalt.
MQTT on kasuliku koormuse agnostiline. Sõnumi sisuks võib olla JSON, Protobuf, CBOR, töötlemata binaar, JPEG või lihttekst. Protokoll kannab seda, kuid ei tõlgenda seda. Teie teemahierarhia (tehas/liin-3/ahi/temperatuur) on nimetamiskokkulepe, mille te ise välja mõtlete ja jõustate. Kui tellija peab teadma, et temperatuur on Celsiuse kraadides ja jääb vahemikku 0–400, on see teadmine väljaspool protokolli – dokumentatsioonis, lepingus, skeemiregistris.
OPC UA on intensiivselt struktureeritud. Igal aadressiruumi sõlmel on 'NodeId', 'BrowseName', 'DataType', 'Value' ja viited teistele sõlmedele. Peal olevad kaasspetsifikatsioonid – PLCopen juhtimisloogika jaoks, automaatne ID RFID-lugejate jaoks, MachineTool, Pump, Robotics, Weihenstephan õlletehaste jaoks – määratlevad, kuidas "Pump" või "MachineTool" OPC UA tingimustes välja näeb. Klient, kes pole teie seadet kunagi näinud, saab ilma eelneva kokkuleppeta ühenduse luua, aadressiruumi sirvida, saadaolevat avastada ja mõista iga väärtuse semantikat.
See võimalus – täieliku semantikaga ühendamine ja avastamine – on OPC UA tapmisfunktsioon. See teeb ka selle raskemaks.
Turvalisus
MQTT tugineb transpordi krüptimisel TLS-ile, autentimiseks kasutajanime/parooli või kliendi sertifikaatidele ning autoriseerimiseks maakleri tasemel ACL-idele. Turvamudel elab maakleri juures. Erinevad maaklerid rakendavad autoriseerimist erinevalt ja protokollis endas pole standardset viisi peeneteraliste lubade väljendamiseks.
OPC UA on sõnumikihti sisse lülitatud krüptograafiline turvalisus. X.509 sertifikaadid nii kliendi kui serveri jaoks, konfigureeritavad turbepoliitikad ("Basic256Sha256", "Aes256_Sha256_RsaPss"), sõnumipõhine allkirjastamine ja krüpteerimine, rakenduse autentimisest eraldiseisev kasutaja autentimine ja 18. osas määratletud rollipõhine juurdepääsukontroll. Keskkondade jaoks, mis peavad näitama vastavust C4IP-le või O6NER2C-le. UA annab teile primitiivid, mis vastavad otse standarditele.
See on üks tugevamaid argumente OPC UA kasuks tehase põrandal: turvamudel loodi esimesest päevast alates tööstuslike juhtimissüsteemide jaoks.
Ribalaius ja üldkulud
MQTT minimaalne pakett on 2 baiti fikseeritud päist pluss muutuv päis ja kasulik koormus. Lühikese teema 4-baidise ujuki "AVALDAMINE" tuleb juhtmele alla 20 baiti. QoS 0 (tulista ja unusta), 1 (vähemalt üks kord) ja 2 (täpselt üks kord) võimaldavad vahetada usaldusväärsust ribalaiuse vastu.
OPC UA Binary on paljusõnalisem. Lihtne jälgitava üksuse teatis võib kesta 50–100 baiti. Seansid, tellimused ja turbemärgid lisavad olekuhalduskulusid. Protokoll oli mõeldud kohtvõrgu läbilaskevõime, mitte mobiilsidevõrgu ribalaiuse jaoks. OPC UA HTTPS/SOAP-i kaudu (vana XML-i sidumine) oli tõeliselt raske ja seda kasutatakse nüüd harva.
OPC UA PubSub MQTT või UDP kaudu vähendab märkimisväärselt üldkulusid, eriti JSON- või binaar-UADP-kodeeringu korral. See kombinatsioon on üha enam õige lahendus roheväljade jaoks, mis vajavad nii semantilist struktuuri kui ka ribalaiuse tõhusust.
Leitavus
Ühendage MQTT klient maakleriga, mida te pole kunagi näinud. Mida saate teha? Saate tellida # (kõik metamärgid) ja jälgida liikluse liikumist ning seejärel proovida teemahierarhiat ja kasuliku koormuse vormingut ümber kujundada. See on teie ainus võimalus ilma väliste dokumentideta.
Ühendage OPC UA klient serveriga, mida te pole kunagi näinud. Saate sirvida kogu aadressiruumi, kontrollida andmetüüpe, lugeda ajaloolisi väärtusi, vaadata, millised meetodid on kutsutavad, ja tuvastada, kas server rakendab teadaolevat kaasspetsifikatsiooni. Protokoll on põhimõtteliselt introspekteeritav.
Süsteemide puhul, mis arenevad sageli – kus masinaid lisatakse, eemaldatakse või konfigureeritakse ümber – on see oluline. OPC UA kliendid kohanduvad automaatselt. MQTT kliendid peavad oma lepinguid sagedusalast väljas värskendama.
Millal MQTT-d kasutada
MQTT on õige valik, kui:
- Saadate telemeetria servseadmetest pilve, eriti mobiilside-, satelliidi- või muude piiratud ribalaiusega linkide kaudu.
- Teil on palju väljaandjaid ja tellijaid ning teil on vaja nende vahel lahtist sidet.
- Te integreerute hüperskaleeritavate asjade Interneti platvormidega (AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ Cloud) – kõik need räägivad MQTT-d emakeelena.
- Te kontrollite kasuliku koormuse vormingut otsast lõpuni ega vaja tarnijatevahelist semantilist koostalitlusvõimet.
- Piiratud ressurssidega mikrokontrolleritel on vaja väikest kliendijalajälge.
- Te ühendate OT-andmed IT-süsteemidega (Kafka, aegridade andmebaasid, ärianalüüsi tööriistad).
Millal kasutada OPC UA-d
OPC UA on õige valik, kui:
- Loed andmeid tehase põrandal asuvatest PLC-dest ja liikumiskontrolleritest. Enamik suuremaid müüjaid – Siemens (S7-1500), Beckhoff (TwinCAT), B&R (Automatiseerimisstuudio), Rockwell, ABB – tarnivad oma kontrolleritesse OPC UA servereid.
- Teil on vaja semantilist koostalitlusvõimet erinevate tarnijate seadmete vahel, ilma et kirjutaksite igaühe jaoks kohandatud adaptereid.
- Te tegutsete reguleeritud keskkonnas (farmaatsia, autotööstus, kosmosetööstus), kus andmete päritolu ja turvalisus on olulised.
- Teie andmestruktuur muutub aja jooksul ja kliendid peavad kohanema ilma uuesti kompileerimata.
- Rakendate teadaolevat kaasspetsifikatsiooni (Weihenstephan õlletehaste jaoks, Euromap plastmasinate jaoks, Umati tööpinkide jaoks).
- Vajate sisseehitatud tuge ajaloolise juurdepääsu, häirete ja tingimuste ning meetodite (väljakutsutavate funktsioonide) jaoks.
Hübriidmuster: OPC UA lõunas, MQTT põhjas
Enamik kaasaegseid IIoT-lüüsisid – sealhulgas Modibus MB213 – rakendavad sisuliselt tõlkekihti. Lõunaküljel (välja poole) räägib lüüs neid protokolle, mida väliseadmed: Modbus RTU ja TCP, OPC UA klient PLC-dele, EtherNet/IP, Siemens S7, BACnet hoone automatiseerimiseks. Põhjaküljel (pilve või ettevõtte suunas) avaldab see MQTT maakleritele, sageli TLS-i ja kliendi sertifikaatidega, kasutades kasuliku koormuse struktuuri jaoks sageli Sparkplug B-d.
See muster töötab, kuna mõlema poole nõuded on erinevad. Tehase põrand vajab determinismi, leitavust ja standardiseeritud semantikat – OPC UA territoorium. Tee pilveni vajab ribalaiuse tõhusust, lahtist sidet ja laia ökosüsteemi tuge – MQTT territooriumi. Värav on koht, kus tõlge toimub.
Süüteküünal B: semantikaga MQTT
Vanilla MQTT suurim nõrkus on kandevõime struktuuri puudumine. Sparkplug B, Cirrus Linki välja töötatud Eclipse Foundationi spetsifikatsioon, käsitleb seda. See määratleb:
Süüteküünal B ei vasta OPC UA semantilisele sügavusele – puuduvad kaaslase spetsifikatsioonid, meetodid ega häirete ja tingimuste mudel. Kuid see on oluliselt kergem kui OPC UA ja paljude pilvega seotud telemeetria kasutusjuhtude jaoks on see parim koht.
- Standardiseeritud teema nimeruum (spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id})
- Sünni- ja surmatunnistused, et tellijad teaksid, milliseid mõõdikuid väljaandja pakub ja millal see võrguühenduseta lülitub
- Tugevalt trükitud mõõdikumääratlused koos tehniliste ühikute, skaleerimise ja ajaloolise olekuga
- Järjestuste nummerdamine sõnumi kadumise tuvastamiseks
OPC UA PubSub MQTT kaudu
Kui soovite OPC UA semantilist rikkust, kuid MQTT transporditõhusust, on OPC UA PubSub MQTT-le (14. osa) üha enam soovitatav muster roheväljade jaoks. Väljaandja jadab OPC UA sõnumid UADP binaarkodeeringu või JSON-kodeeringu abil ja avaldab need MQTT teemadel. Abonendid saavad täielikult trükitud OPC UA andmed ilma seansi loomise üldkuludeta.
Kompromiss: tööriistade küpsus on madalam kui vanilla MQTT või OPC UA klient-server. Mitte iga maakler, mitte iga pilveplatvorm ja mitte iga SCADA-süsteem ei käitle OPC UA PubSub veel graatsiliselt. Oodake, et see paraneb järgmise kahe kuni kolme aasta jooksul kiiresti.
Otsuste raamistik
Kui kahtlete, esitage kolm küsimust:
Kus andmed asuvad ja kuhu need peavad jõudma? Tehase põrandad: OPC UA. Tehase põrandast pilveni: MQTT (või OPC UA PubSub MQTT kaudu). Pilvest pilve: MQTT.
Kes juhib skeemi? Kui juhite nii väljaandjat kui ka tellijat, töötab MQTT ja dokumenteeritud kasuliku koormuse vorming. Kui vajate tarnijatevahelist koostalitlusvõimet ilma kahepoolsete lepinguteta, OPC UA.
Mis on ribalaiuse eelarve? Mobiilside, LPWAN või satelliit: kalduge MQTT poole. Juhtmega LAN ilma piiranguteta: OPC UA on hea.
| Mure | MQTT | OPC UA |
|---|---|---|
| Kasuliku koorma suurus | Minimaalne | Kõrgem |
| Sisseehitatud semantika | Ei | Jah |
| Leitavus | Ei | Jah |
| Pilve ökosüsteem | Suurepärane | Piiratud |
| Taimepõranda kasutuselevõtt | Kasvav | Domineeriv |
| Turvamudel | Transport (TLS) | Sõnum + Transport |
| Kaaslase tehnilised andmed | Ei (süüteküünal B lähim) | Paljud |
| Parim sobivus | Telemeetria, pilvesild | Koostalitlusvõime, juhtimissüsteemid |
Lõppmõte
Aus vastus küsimusele "MQTT või OPC UA?" on peaaegu alati "mõlemad, erinevates kohtades". MQTT on õige tööriist baitide tõhusaks teisaldamiseks võrkude vahel. OPC UA on õige tööriist tähenduse edastamiseks tarnijate vahel. Hästi läbimõeldud IIoT-arhitektuur kasutab igaühte neist seal, kus selle tugevused ühtivad eesseisva probleemiga.
Just seetõttu eksisteerivad tööstuslikud väravad – et muuta piir nende kahe maailma vahel puhtaks, turvaliseks ja jälgitavaks.
Modibus MB213 toetab MQTT-d (TLS-i, Sparkplug B-ga ja konfigureeritava QoS-iga) ja OPC UA-d (kliendi- ja serverirollid) koos Modbus RTU/TCP ja muude tööstuslike protokollidega. Konkreetse arhitektuuri arutamiseks [võtke meiega ühendust](https://modibus.com).