MQTT, OPC UA ar tiesioginė komunikacija su PLC – kaip pasirinkti duomenų mainų modelį pramoniniame projekte?

Pasirinkimas tarp MQTT, OPC UA ir tiesioginės komunikacijos su PLC jau nebėra vien techninis sprendimas. Šiandien jis kartu lemia sistemos architektūrą, paleidimo sąnaudas, tiekėjų atsakomybės ribas ir priėmimo darbų tempą. Praktikoje svarbu ne tai, kuris protokolas yra „geresnis“, o kuris duomenų mainų modelis atitinka realią projekto paskirtį: ar reikia paprastos signalų integracijos iš vienos mašinos, linijos priežiūros, duomenų mainų su aukštesnio lygio sistemomis, o gal paskirstyto valdymo, kuris bus plėtojamas dar daugelį metų. Klaida šiame etape paprastai neišryškėja iš karto laboratorijoje, o vėliau: paleidimo metu, validuojant, keičiant PLC tiekėją arba tada, kai techninės priežiūros skyrius bando atsekti sutrikimo priežastį ir paaiškėja, kad duomenys yra nenuoseklūs, vėluoja arba neturi konteksto.

Projekto požiūriu pavojingiausia yra komunikacijos modelį pasirinkti „iš įpročio“. Tiesioginė komunikacija su PLC dažnai vilioja tuo, kad suteikia greitą prieigą prie registrų ir neretai sutrumpina pirmąjį diegimo etapą. Tačiau toks pasirinkimas lengvai susieja aukštesnio lygio taikomąją sistemą su konkrečiu valdikliu, atminties adresacija ir gamintojo įgyvendinimo būdu. Keičiant programos versiją, migruojant aparatinę įrangą ar plečiant liniją, sąnaudos sugrįžta kaip perdarymai, regresiniai bandymai ir ginčai dėl atsakomybės už proceso duomenis. Tuo tarpu MQTT gerai pasiteisina ten, kur svarbus lengvas informacijos paskirstymas ir siuntėjų atskyrimas nuo gavėjų, tačiau tam reikia sąmoningai apibrėžti duomenų semantiką, pristatymo kokybę ir brokerio priežiūros taisykles. OPC UA dažnai pasirenkamas kaip kompromisas tarp sąveikumo ir informacijos struktūros, tačiau ir jis problemų neišsprendžia savaime: jei duomenų modelis netinkamas, formaliai teisinga komunikacija vis tiek lemia neteisingus operacinius sprendimus.

Praktinis sprendimo kriterijus yra paprastas, nors dažnai ignoruojamas: pirmiausia reikia nustatyti, ar konkretūs mainai susiję su informacija, valdymu, ar funkcija, turinčia įtakos mašinos eksploatavimo saugai. Jei kanalas skirtas tik stebėsenai, ataskaitoms ar receptūrų perdavimui kontroliuojamu režimu, sprendimus galima lyginti pagal priežiūrą, mastelio keitimą ir integraciją. Tačiau jei tuo pačiu keliu turi būti perduodamos komandos, darančios įtaką judesiui, darbo sekai, blokavimams ar įrenginio parengties būsenai, tema iš karto nustoja būti vien informacinių technologijų klausimu. Tuomet reikia vertinti ne tik perdavimo vėlinimą ir patikimumą, bet ir elgsenos nuspėjamumą praradus ryšį, po sistemos paleidimo iš naujo, pakeitus programinės įrangos versiją ir išorinei sistemai klaidingai interpretavus būseną. Tai momentas, kai klausimas natūraliai pereina į praktinę projektinių sprendimų rizikos analizę, o kartais ir į apsaugos nuo netikėto paleidimo sritį.

Tipinis pavyzdys gamybos įmonėse atrodo panašiai: pradžioje tikslas yra tik nuskaityti duomenis iš mašinos vizualizacijai arba ataskaitų sistemai, todėl komanda pasirenka greitą tiesioginį ryšį su PLC. Po kelių mėnesių tuo pačiu kanalu jau pradedami perduoti nustatymų įrašai, aliarmų patvirtinimai, o vėliau ir nuotolinės techninės priežiūros komandos. Formaliai sistema vis dar „veikia“, tačiau architektūra nebeatitinka realios atsakomybės. Nebeaišku, kuris sluoksnis yra patikimas mašinos būsenos šaltinis, kas atsako už pakeitimų autorizavimą ir kaip įrodyti, kad išorinė komunikacija nesudaro kelio netyčiniam paleidimui. Šiame etape kyla klausimų ne tik dėl protokolo, bet ir dėl funkcijų paskirstymo tarp valdymo, priežiūros ir saugos sluoksnių bei, tiesioginės komunikacijos su PLC scenarijuose, dėl pasekmių elektros daliai ir jungtims mašinoje.

Todėl norminė ir atitikties reikšmė šio pasirinkimo išryškėja tada, kai duomenų mainų modelis daro įtaką mašinos elgsenai normaliomis ir sutrikimų sąlygomis. Ne kiekviena integracija iš karto patenka į saugos funkcijoms taikomų reikalavimų sritį, tačiau kiekviena turi būti įvertinta pagal klaidos pasekmes, ryšio praradimą ir neteisingą veiksmų seką. Jei per išorinę sąsają galima pakeisti mašinos būseną, atlaisvinti blokavimą, atnaujinti ciklą arba apeiti vietoje numatytą logiką, sprendimas dėl komunikacijos turi būti susietas su rizikos analize, o atitinkamais atvejais ir su reikalavimais, skirtais netikėto paleidimo prevencijai. Todėl šis klausimas turi būti sprendžiamas dabar, prielaidų ir architektūros etape, o ne tik paleidimo metu. Būtent tada dar galima nustatyti išmatuojamus kriterijus: kam priklauso duomenų modelis, kokios ryšio praradimo pasekmės yra leistinos, kiek integracijos taškų reikės prižiūrėti pakeitus PLC ir kaip bus įrodyta, kad komunikacija neperkelia atsakomybės už suplanuotų sistemos ribų.

Kur dažniausiai didėja sąnaudos arba rizika

Daugiausia problemų kyla ne dėl paties pasirinkimo tarp MQTT, OPC UA ir tiesioginio ryšio su PLC, o dėl to, kad šiam ryšiui neteisingai priskiriamas vaidmuo mašinos ar įrenginio architektūroje. Projektas pradeda brangti tada, kai kanalas, numatytas pagalbinių duomenų mainams, ima perduoti operacinius sprendimus, nuo kurių priklauso proceso tęstinumas, įrenginio būsena ar operatoriaus veiksmai. Praktikoje tai reiškia, kad komanda įdiegia tariamai pigesnį ir greitesnį sprendimą, o vėliau prideda apeinamuosius sprendimus: papildomus aparatinius signalus, vietinius blokavimus, išimtis valdiklio logikoje, atskirus patvirtinimo mechanizmus ir būsenos atkūrimą nutrūkus ryšiui. Būtent šios vėlyvos korekcijos sukuria papildomas išlaidas, vėlavimus ir ginčus dėl atsakomybės tarp integratoriaus, programinės įrangos tiekėjo ir galutinio naudotojo. Praktinis vertinimo kriterijus yra paprastas: reikia nustatyti, ar praradus ryšį sistema turi tik „nustoti teikti ataskaitas“, ar gali pereiti į pavojingą, technologiškai neteisingą arba gamybos požiūriu brangią būseną.

Modeliuose, paremtuose tiesioginiu ryšiu su PLC, rizika paprastai didėja ten, kur sąsaja tampa priklausoma nuo konkretaus gamintojo, programinės įrangos versijos ir valdiklio atminties struktūros. Paleidimo etape tai dažnai veikia gerai, tačiau tikrosios sąnaudos išryškėja keičiant valdiklį, modernizuojant liniją arba prijungiant dar vieną aukštesnio lygio sistemą. Kiekvienam tokiam pakeitimui reikia iš naujo susieti duomenis, patikrinti tipus, adresus, teises ir elgseną perdavimo klaidos atveju. Produkto savininko požiūriu tai svarbu, nes priežiūra tampa nebeprognozuojama: dokumentacija greitai praranda aktualumą, žinios lieka pas rangovą, o atsakomybė už duomenų teisingumą išsiskaido. Jeigu komanda negali aiškiai nurodyti, kas yra duomenų modelio savininkas ir kokia yra jo keitimo procedūra po PLC atnaujinimo, būsimų integracijos darbų kaina jau yra įskaičiuota į projektą, net jei šiandien to dar nesimato.

MQTT ir OPC UA atveju dažniausia klaida yra kitokia: manoma, kad komunikacijos sluoksnis pats išspręs duomenų semantikos ir sprendimų patikimumo problemą. Tuo tarpu MQTT gerai perduoda įvykius ir telemetriją, tačiau kruopščiai neapibrėžus temų, pristatymo kokybės, išlaikymo ir šaltinio identifikavimo, nesunku sukurti situaciją, kai gavėjas gauna formaliai teisingus, bet praktiškai nenaudingus arba proceso atžvilgiu pavėluotus duomenis. OPC UA savo ruožtu sutvarko informacinį modelį ir palengvina sąveikumą, tačiau jo diegimas dažnai nepakankamai įvertinamas, jei įrenginiuose nėra nuosekliai parengtos objektų, būsenų ir metodų struktūros. Praktinis pavyzdys išryškėja dirbant su receptūromis, partijų patvirtinimu ar nuotoliniu ciklo atnaujinimu: jeigu nėra vienareikšmiškai apibrėžta, kuri pusė patvirtina komandos priėmimą, kuri – jos įvykdymą, o kuri tik įrašą registre, po pirmojo incidento sunku įrodyti, ar klaida atsirado taikomosios programos sluoksnyje, komunikacijos sluoksnyje, ar pačioje mašinos logikoje. Geras sprendimo kriterijus čia yra ne protokolo „šiuolaikiškumas“, o tai, ar galima vienareikšmiškai aprašyti būseną, komandos šaltinį, galiojimo sąlygas ir darbo atkūrimo būdą po sutrikimo.

Atskiras išlaidų šaltinis yra eksploatacinių reikalavimų maišymas su saugos ir atitikties reikalavimais. Jeigu per MQTT, OPC UA arba tiesioginę prieigą prie PLC galima daryti įtaką mašinos judėjimui, blokavimų atleidimui, paleidimo sekai ar parametrams, turintiems apsauginę reikšmę, tema nustoja būti vien tik informacinių technologijų klausimu. Šioje vietoje tema natūraliai pereina į praktinę rizikos analizę projektiniams sprendimams: reikia vertinti ne patį protokolą, o klaidingos komandos, duomenų neaktualumo, neteisėto nustatymų pakeitimo ir neatitikties tarp vietinės bei išorinės būsenos pasekmes. Vykdomosiose sistemose, taip pat ir hidraulinėse, komunikacijos sprendimas gali turėti įtakos tam, kaip įgyvendinamos sustabdymo, apkrovos nuėmimo, judesio blokavimo ir saugaus grįžimo į darbą funkcijos, todėl jis gali būti susijęs su projektavimo reikalavimais, taikomais atliekant atitikties vertinimą. Jeigu išorinė sąsaja pradeda veikti apsaugines funkcijas arba elgseną, kurią operatorius suvokia kaip apsaugos dalį, tai reikia laikyti saugos architektūros elementu, o ne patogiu integracijos priedu.

Projektų valdymo požiūriu saugiausias sprendimas yra tas, kurį galima pagrįsti ne tik techniškai, bet ir organizaciškai. Todėl prieš pasirenkant duomenų mainų modelį verta nustatyti kelis išmatuojamus kriterijus: teisingo darbo atkūrimo laiką po ryšio praradimo, vietų, kuriose reikia palaikyti duomenų susiejimą, skaičių, informacinio modelio versijavimo būdą, regresinių bandymų apimtį po PLC pakeitimo ir įrodymą, kad išorinė komunikacija neapeina vietinių apsaugos mechanizmų. Kai atsakymai į šiuos klausimus yra neaiškūs, projektas paprastai jau patenka į sritį, kurioje pats komunikacijos sprendimas turėtų būti įtrauktas į formalesnį rizikos vertinimą, o kai kuriais taikymo atvejais taip pat suderintas su projektavimo reikalavimais, taikomais vykdomiesiems elementams ir blokavimo priemonėms. Tai momentas, kai pasirinkimas tarp MQTT, OPC UA ir tiesioginės komunikacijos nustoja būti techninio prioriteto klausimu ir tampa sprendimu dėl priežiūros sąnaudų, atsakomybės ribų ir viso sprendimo atsparumo klaidoms.

Kaip prie to prieiti praktiškai

Praktikoje pasirinkimą tarp MQTT, OPC UA ir tiesioginės komunikacijos su PLC verta pradėti ne nuo technologijos, o nuo klausimo, kokį eksploatacinį rezultatą turi duoti duomenų mainai ir kas prisiima atsakomybę už jų rezultatą. Jei duomenys skirti tik stebėsenai, ataskaitoms ar aukštesnio lygmens sistemų aprūpinimui, prioritetas bus integracijos atsparumas pokyčiams ir aiškus informacinis modelis. Tačiau jei kitoje pusėje atsiranda komandos, darančios įtaką ciklo eigai, receptūroms, darbo būsenoms ar paleidimo sąlygoms, sprendimas nebėra vien IT klausimas. Tuomet komunikacijos būdas jau daro įtaką atsakomybės ribai tarp integratoriaus, mašinos gamintojo, techninės priežiūros ir proceso savininko. Tai turi tiesioginių pasekmių projektui: skiriasi priėmimo bandymų apimtis, pakeitimų dokumentavimas, regresijos mastas po valdiklio programos modifikavimo ir priežiūros sąnaudos po įdiegimo.

Geras sprendimo kriterijus yra tai, kur turi būti „vienintelis tiesos šaltinis“ apie mašinos būseną ir veikimo leidimo logiką. Tiesioginė komunikacija su PLC gali būti pagrįsta ten, kur svarbus vykdymo kelio paprastumas, nedidelis tarpinių grandžių skaičius ir visiškas valdiklio pusės elgsenos nuspėjamumas. To kaina paprastai yra stiprus sprendimo susiejimas su konkrečia PLC programa, duomenų adresais ir vieno tiekėjo praktika. OPC UA yra racionalus pasirinkimas, kai projektui reikia stabilesnio duomenų modelio, geresnio taikomosios dalies atskyrimo nuo valdiklio programos ir aiškesnės signalų semantikos. MQTT pirmiausia pasiteisina tada, kai duomenys turi būti paskirstomi daugeliui gavėjų, neapsiribojant viena sistemos ir valdiklio sąsaja, ir kai priimtinas tarpinės komunikacijos modelis. Tačiau tai nėra neutralus pasirinkimas: kuo daugiau tarpinių sluoksnių, brokerių, vertėjų ir susiejimų, tuo didesnis klaidų paviršius ir tuo sunkiau įrodyti, kad integracijos pusėje atliktas pakeitimas nepažeidžia prielaidų, priimtų vietiniam valdymui.

Tipinė projektavimo klaida yra ta, kad komanda pasirenka integracijai patogų modelį paleidimo etape, o tik vėliau pamato priežiūros kainą. Praktinis pavyzdys: aukštesnio lygmens sistema turi įrašyti receptūras ir perjungti kelių darbo vietų veikimo režimus. Jei tai daroma tiesiogiai rašant į PLC atminties sritis, pradžioje sprendimas bus greitas, tačiau kiekvienas duomenų struktūros pakeitimas valdiklyje reikalaus bandymų abiejose sąsajos pusėse, o atsakomybė už receptūrų nuoseklumą ims nykti. Jei tas pats atvejis bus paremtas aiškiai apibrėžtais objektais ir būsenomis OPC UA pusėje, bus lengviau atskirti mašinos programos pakeitimą nuo aukštesnio lygmens sistemos pakeitimo, tačiau reikės prižiūrėti informacinį modelį ir jo versijavimą. Savo ruožtu MQTT naudojimas tokiam scenarijui turi prasmę tik tada, kai iš tiesų reikia duomenų paskirstymo daugeliui sistemų ir kai delsos, pristatymo patvirtinimo bei būsenos atkūrimo po ryšio praradimo kontrolė yra aprašyta ir patikrinta bandymais. Priešingu atveju komanda nusiperka lankstumą, kurio neišnaudos, o lieka su papildomais gedimų taškais.

Čia tema natūraliai pereina į praktinę rizikos analizę projektiniams sprendimams. Jei komunikacijos kanalas gali pakeisti mašinos būseną, atblokuoti seką, atnaujinti darbą po ryšio nutrūkimo arba netiesiogiai paveikti vykdomuosius elementus, reikia įvertinti ne tik perdavimo patikimumą, bet ir klaidingos arba pavėluotos komandos pasekmes. Kai kuriose taikymo srityse ši tema jau susijusi su reikalavimais apsaugai nuo netikėto paleidimo, nes net techniškai teisinga integracija negali sudaryti kelio apeiti vietines blokavimo priemones ar energijos atjungimo procedūras. Tokiu mastu komunikacijos pasirinkimas turėtų būti derinamas su valdymo architektūra, elektrine dalimi ir programinės įrangos keitimo taisyklėmis, o ne priimamas kaip savarankiškas integracijos sprendimas. Vadovo požiūriu tai reiškia paprastą taisyklę: duomenų mainų modelis yra tinkamas tik tada, kai galima parodyti, kas tvirtina pakeitimą, kaip po gedimo atkuriama saugi būsena ir kokie KPI bus matuojami po įdiegimo, pavyzdžiui, darbo atkūrimo laikas, incidentų skaičius po pakeitimų ir vietų, kuriose palaikomas duomenų susiejimas, skaičius.

Į ką atkreipti dėmesį diegiant

Diegimo metu didžiausią riziką kelia ne pats pasirinkimas tarp MQTT, OPC UA ir tiesioginės komunikacijos su PLC, o paslėptos prielaidos, kurias komanda priima jų formaliai nepatvirtinusi. Projektavimo praktikoje brangiausios yra situacijos, kai duomenų mainų modelis parenkamas funkcijos demonstravimui, o ne realiam eksploatavimo, priežiūros ir atsakomybės už pakeitimus režimui. MQTT kartais diegiamas darant prielaidą, kad tai bus paprastas duomenų perdavimas į aukštesnio lygmens sistemas, o po kelių mėnesių juo jau pradedamos perduoti operacinės komandos. OPC UA pasirenkamas kaip „universalus“ sprendimas, tačiau iš anksto nenustačius, kurios paslaugos, duomenų modeliai ir teisių mechanizmai iš tikrųjų bus naudojami. Tiesioginė komunikacija su PLC atrodo trumpiausias kelias tol, kol nepaaiškėja, kad kiekvienam kitam duomenų gavėjui reikia atskiro susiejimo, regresinių bandymų ir suderinimų su valdiklio tiekėju. Vadovui tai reiškia paprastą pasekmę: diegimo kaina nesibaigia ryšio paleidimu, ji tęsiasi per visą pakeitimų, gedimų ir techninių priėmimų ciklą.

Todėl svarbiausias sprendimo klausimas turėtų būti ne „ką galime paleisti greičiausiai“, o „kur baigiasi atsakomybė už duomenų prasmę ir jų panaudojimo pasekmes“. Jei komunikacija skirta tik proceso stebėsenai, vertinimo kriterijai bus kitokie nei tada, kai tas pats kanalas turi daryti įtaką receptūroms, darbo parametrams, blokavimams ar valdymo sekoms. Šioje vietoje tema natūraliai pereina į praktinę rizikos analizę projektiniams sprendimams: reikia įvertinti ne tik ryšio praradimo tikimybę, bet ir tai, ar klaidinga reikšmė, pavėluotas atnaujinimas arba dviprasmis kintamojo susiejimas gali sukelti netinkamą mašinos ar linijos veikimą. Jei atsakymas teigiamas, komunikacijos architektūra nebėra vien integracijos klausimas. Ji tampa elementu, turinčiu įtakos valdymo funkcijai, sistemos priėmimui ir integratoriaus atsakomybei sujungiant posistemes.

Praktikoje tai gerai matyti iš paprasto scenarijaus: aukštesnio lygio sistema turi nuskaityti būsenas iš kelių valdiklių, o paleidus projektą naudotojas papildomai paprašo nuotoliniu būdu keisti nustatymus. Kai komunikacija vyksta tiesiogiai su PLC, dažnai tenka pridėti vis daugiau registrų, išimčių ir apeinamųjų sprendimų, priklausančių nuo konkretaus gamintojo. MQTT atveju problema dažnai yra vienareikšmiškumo praradimas: pranešimas pasiekia gavėją, tačiau be aiškiai apibrėžto konteksto neaišku, ar reikšmė yra aktuali, patvirtinta ir iš kokio darbo režimo ji gauta. OPC UA atveju spąstai slypi ne pačiame protokole, o pernelyg optimistinėje prielaidoje, kad įrenginio pusėje esantis informacinis modelis atitinka tai, ko reikalauja aukštesnio lygio programa. Todėl praktinis vertinimo kriterijus turėtų apimti tris dalykus: kam priklauso duomenų semantika, kaip patvirtinamas reikšmių galiojimas ir aktualumas, ir kaip atrodo pakeitimų procedūra po paleidimo. Jei į bent vieną iš šių klausimų komanda atsako pernelyg bendrais bruožais arba priklausomai nuo tiekėjo, tai reiškia, kad būsimų pakeitimų kaštai ką tik buvo perkelti į eksploatavimo etapą.

Atskiri spąstai yra nepakankamai įvertintos fizinės ir diegimo pasekmės. Projektuose, kuriuose duomenų mainų modelio pasirinkimas daro įtaką tarpinių įrenginių vietai, papildomam maitinimui, kabelių trasavimui ar tinklo segmentavimui, tema jau paliečia mašinos elektros sluoksnio ir jungčių projektavimą. Tai ypač aktualu sprendimams su papildomais komunikacijos šliuzais, pramoniniais kompiuteriais ar komutatoriais, kurie dokumentacijoje atrodo nekaltai, tačiau valdymo spintoje reiškia vietą, aušinimą, apsaugas, aptarnavimą ir papildomus gedimo taškus. Tokiu atveju komunikacijos sprendimas negali būti atskirtas nuo vykdomojo projekto. Komanda turi gebėti nurodyti, kas nutiks dingus tarpinio įrenginio maitinimui, kaip bus atkuriama komunikacijos būsena ir ar perdavimo sluoksnio gedimas nesukurs operatoriui ar aukštesnio lygio sistemai dviprasmiško mašinos būsenos vaizdo.

Nuoroda į atitikties reikalavimus atsiranda tik tada, kai duomenų mainų kanalas daro įtaką valdymo funkcijai, mašinos naudojimo būdui arba atsakomybės riboms tarp tiekėjų. Tokiu atveju nepakanka pasakyti, kad protokolas yra „pramoninis“ arba plačiai naudojamas. Reikia parodyti, kad pasirinkta architektūra buvo įvertinta numatomų gedimo būsenų, eksploatacinių pakeitimų ir sąsajų tarp posistemių kontekste, o praktikoje tai veda prie metodiško rizikos vertinimo pagal priimtą projekto apimtį. Jei sistema surenkama iš paruoštų modulių, valdiklių ir komunikacijos sluoksnių iš skirtingų subjektų, didėja ir formalus integratoriaus atsakomybės priskyrimo svarbumas. Paprastai tai yra momentas, kai verta sustabdyti projektą ir patikrinti ne tik duomenų mainų schemą, bet ir pakeitimų ribas po priėmimo, pakeitimų validavimo taisykles bei eksploatavimo KPI: komunikacijos atkūrimo laiką, incidentų skaičių po atnaujinimų ir sąsajų, kurioms reikia rankinio susiejimo, skaičių.