MQTT pret OPC UA: rūpniecisko protokolu pārvaldība no iekārtu ražotāja skatpunkta
Gudrās ražošanas laikmetā mašīnām jāspēj ne tikai veikt uzdevumus, bet arī sazināties. Kā oriģinālo iekārtu ražotājam (OEM) ir svarīgi izvēlēties, kā pārsūtīt datus no programmējamā loģiskā kontroliera (PLC) uz mākoņserveri vai vietējo datu bāzi. Lai gan gan MQTT, gan OPC UA atvieglo datu pārraidi, to pamatstruktūras kalpo ļoti atšķirīgiem mērķiem rūpnieciskās automatizācijas jomā.
Rūpnieciskās savienojamības izcelsme
Lai saprastu šos protokolus, jāiepazīstas ar to vēsturi. MQTT (Ziņojumu rindas telemetrijas pārraide) sākotnēji radās kā risinājums naftas cauruļvadiem, kas savienoti ar satelītu. Tā radītājiem bija nepieciešama viegla un zemas enerģijas metode, lai pārvaldītu pārtraukto savienojumu. Savukārt OPC UA (Atvērtās platformas komunikāciju vienotā arhitektūra) attīstījās no Microsoft bāzes par piegādātājam neitrālu standartu. Šodien OPC fonds uztur to kā drošu, platformu neatkarīgu ietvaru rūpnīcu automatizācijai.
MQTT publicēšanas-abonēšanas modeļa mehānismi
MQTT balstās uz "publicēšanas/abonēšanas" arhitektūru. Šajā sistēmā centrālais starpnieks pārvalda visu datu plūsmu. Ierīce "publicē" datu kopu noteiktā tēmā pie starpnieka. Savukārt jebkurš klients "abonē" šo tēmu, lai saņemtu atjauninājumus. Šī atdalītā pieeja īpaši labi darbojas attālinātiem sensoriem ar nestabilu savienojumu. Tomēr, tā kā starpnieks atrodas vidū, gan mašīnai, gan klientam jāuztur ceļš uz šo centrālo mezglu.
OPC UA arhitektūras sarežģītība
Atšķirībā no vienkārša ziņojumu protokola, OPC UA ir visaptveroša saziņas arhitektūra. Tā ļauj tiešas, bagātīgas saites starp klientu un serveri. Šī struktūra ļauj "pārlūkot", kur serveris var reāllaikā izpētīt PLC iekšējo tagu struktūru. Lai gan tā atbalsta publicēšanu/abonēšanu, tās spēks slēpjas klienta/servera modelī. Turklāt lielākie vadības sistēmu ražotāji OPC UA iebūvē tieši savā aparatūrā, lai gan tā aktivizēšanai bieži nepieciešama licence.
MQTT priekšrocības mākoņintegrācijā
MQTT izceļas, kad joslas platums ir ierobežots vai kad dati jāpārsūta uz mākoņplatformām. Tā nelielais galvenes izmērs padara to ļoti ātru maziem datu apjomiem. Turklāt lielākie mākoņpakalpojumu sniedzēji, piemēram, AWS un Azure, izmanto MQTT kā galveno datu uzņemšanas protokolu. Tas padara integrāciju ar "Lielajiem datiem" salīdzinoši vienkāršu. Tomēr daudzi standarta rūpnieciskās automatizācijas kontrolieri nepiedāvā MQTT atbalstu tieši, bieži nepieciešami ārēji vārtejas vai pielāgota programmatūra.
Ātrdarbīgi dati un OPC UA priekšrocības
Ja lietojumprogramma prasa ātru, sinhronizētu datu plūsmu no testa stenda vai motora piedziņas, OPC UA parasti ir labāka izvēle. Tā efektīvi apstrādā lielus datu apjomus un nodrošina spēcīgas drošības funkcijas no paša sākuma. Tā kā tas ir nozares standarts, lielākā daļa mūsdienu distribūto vadības sistēmu (DCS) un SCADA sistēmu atpazīst OPC UA tagus bez papildu starpniekprogrammatūras. Šī iebūvētā saderība atvieglo ilgtermiņa rūpnīcas automatizācijas sistēmas uzturēšanu.
Pareizā protokola izvēle jūsu mašīnai
Galīgā izvēle bieži vien ir atkarīga no klienta esošās IT infrastruktūras. Ja rūpnīcā jau tiek izmantota konkrēta tehnoloģiju kopa, visticamāk, tiks prasīts izmantot šo protokolu jūsu mašīnai. Ja ir izvēles iespēja, apsveriet, kur dati tiks nosūtīti. Vietējai, ātrdarbīgai mašīnu savstarpējai saziņai (M2M) OPC UA piedāvā dziļāku integrāciju. Ja mērķis ir attālināta uzraudzība vai mākoņanalītika, MQTT nodrošina vienkāršāku ceļu.
Autora komentārs: hibrīdā realitāte
Manā profesionālajā pieredzē "MQTT pret OPC UA" debates bieži ir mānīgs pretstats. Daudzi mūsdienu rūpnieciskās automatizācijas projekti patiesībā izmanto abus. Es bieži izmantoju OPC UA ātrdarbīgai vietējai vadībai un datu apmaiņai starp PLC un operatora paneļu (HMI). Tajā pašā laikā izmantoju MQTT vārteju, lai nosūtītu apkopotus rādītājus uz mākoņa pārskatu paneli. Mans padoms OEM ražotājiem: neierobežojieties ar vienu protokolu. Drīzāk veidojiet elastīgu arhitektūru, kas var pielāgoties klienta konkrētajai digitālajai videi.
