Nuo į PLC orientuoto valdymo prie programine įranga apibrėžiamo automatizavimo
Pramoninė automatizacija pereina nuo tradicinio specializuotų PLC, mikrovaldiklių ir fiksuotos paskirties mašinų modelio. Šiuolaikinės sistemos vis dažniau derina PLC pagrįstą valdymą su didelio našumo MPU ir SoC, kad galėtų vykdyti HMI, mašininio matymo, kraštinę analitiką, ryšio, skaitmeninių dvynių ir dirbtinio intelekto darbo krūvius.
Ši raida nepadaro tradicinių valdymo architektūrų pasenusių. Priešingai, ji sukuria sluoksniuotą architektūrą, kurioje PLC gali ir toliau vykdyti deterministinį lauko lygio valdymą, o didesnio našumo skaičiavimo platformos atlieka priežiūros, analizės, vizualizacijos ir dirbtinio intelekto funkcijas.
Inžineriniu požiūriu svarbu ne vien pridėti skaičiavimo galios. Tikrasis iššūkis - užtikrinti, kad šie papildomi darbo krūviai nepakenktų nustatytų valdymo funkcijų spartai, pasiekiamumui ar vientisumui.
Fizinis dirbtinis intelektas kelia naują automatizavimo iššūkį
Fizinio dirbtinio intelekto diegimas apsunkina sistemos architektūrą, nes dirbtinio intelekto sugeneruota informacija gali daryti įtaką fizinei įrangai ir veiklos sprendimams.
Dirbtinio intelekto modelis gali nustatyti nenormalią mašinos būseną, aptikti vizualinę anomaliją, padėti atlikti prognozinę patikrą arba nustatyti su operatoriumi susijusią būseną. Tačiau dirbtinio intelekto išvados rezultatas yra tik viena visos automatizavimo grandinės dalių.
Sistemai vis tiek reikia gauti jutiklių informaciją, vykdyti dirbtinio intelekto modelį, patikrinti veikimo kontekstą, taikyti iš anksto apibrėžtas valdymo taisykles ir perduoti susidariusią būseną atitinkamai programai arba operatoriui.
Todėl, mano nuomone, pramoninis dirbtinis intelektas turėtų būti laikomas sprendimų palaikymo arba kontroliuojamo atsako darbo krūviu, o ne izoliuotu intelekto sluoksniu. Aplinkinė automatizavimo platforma lemia, ar dirbtinio intelekto informaciją galima apdoroti ir pagal ją veikti laikantis reikiamų laiko bei saugos ribų.
Mišrių kritiškumo lygių darbo krūviams būtina tikroji izoliacija
Šiuolaikiniai daugiabranduoliai procesoriai leidžia konsoliduoti funkcijas, kurioms anksčiau reikėjo atskirų aparatinės įrangos platformų. Dabar viena skaičiavimo sistema gali talpinti griežto realiojo laiko valdymą, HMI paslaugas, tinklo funkcijas, diagnostiką, įvykių registravimą, mašininį matymą, analitiką ir dirbtinio intelekto išvadas.
Šiems darbo krūviams keliami nevienodi reikalavimai.
Griežto realiojo laiko valdymo užduočiai gali būti nustatytas griežtas vykdymo terminas. HMI gali toleruoti kitokias laiko charakteristikas, o dirbtinio intelekto išvadų procesui gali reikėti daug CPU išteklių. Tinklo paslaugos taip pat sukuria išorinius ryšio kelius, kurie neturėtų turėti neribotos prieigos prie svarbių išteklių.
Todėl vien kelių programų įdiegimas daugiabranduoliame procesoriuje savaime nesukuria atsparios architektūros.
Veikimo aplinka turi užtikrinti laiko atskyrimo, atminties apsaugos, išteklių valdymo ir gedimų izoliavimo mechanizmus.
Aparatinės įrangos konsolidavimas nereiškia atsparumo
Aparatinės įrangos konsolidavimas gali sumažinti skaičiavimo platformų skaičių, supaprastinti laidų sistemą ir padidinti integraciją. Tačiau jis taip pat sukuria galimą bendrą gedimo tašką.
Jei nesusiję darbo krūviai dalijasi tuo pačiu procesoriumi ir veikimo aplinka, sugedusi tvarkyklė, nekontroliuojamai veikianti programa, atminties gedimas ar pažeista paslauga gali paveikti kitas funkcijas, nebent programinės įrangos architektūra nustato tinkamas ribas.
Tai vienas svarbiausių aspektų modernizuojant pasenusias automatizavimo sistemas.
Tikslas neturėtų būti vien perkelti daugiau funkcijų į mažesnį procesorių skaičių. Tikslas - konsoliduoti darbo krūvius nesukuriant nepriimtinų priklausomybių tarp jų.
Operacinė sistema tampa vykdymo kontrolės sluoksniu
Programinės įrangos apibrėžtoje automatizavimo architektūroje operacinė sistema nebėra vien platforma, kurioje vykdomos programos.
Tai lemia, kaip planuojamas procesų vykdymas, kaip apsaugoma atmintis, kaip pasiekiami aparatinės įrangos ištekliai ir kaip atskiros paslaugos sąveikauja tarpusavyje. Šie mechanizmai tiesiogiai lemia sistemos gebėjimą išlaikyti veikimą, kai sugenda atskiras komponentas.
Todėl atspari architektūra turėtų gebėti izoliuoti sugedusią paslaugą ir, jei tai leidžia sistemos projektas, atkurti tą paslaugą nepaleidžiant iš naujo nesusijusių programų.
Šis požiūris ypač aktualus pramoninėms sistemoms, kuriose visiškas sistemos paleidimas iš naujo gali nutraukti valdymo, vizualizavimo, ryšio ar gamybos operacijas.
Kodėl mikrobranduolio architektūra yra svarbi
Įprasta monolitinė operacinė sistema paprastai daugelį paslaugų, tvarkyklių, failų sistemų ir tinklo komponentų talpina itin privilegijuotoje branduolio aplinkoje.
Mikrobranduolys taiko kitokį architektūrinį požiūrį. Branduolyje paliekamas mažesnis pagrindinių funkcijų rinkinys, o daugeliui tvarkyklių, protokolų dėklų, failų sistemų ir sistemos paslaugų leidžiama veikti kaip atskiriems procesams apsaugotose adresų erdvėse.
Pramonės automatizavimo srityje ši architektūra gali pasiūlyti keletą naudingų savybių:
- Gedimų izoliavimas: Sugedusią tvarkyklę ar paslaugą galima izoliuoti nuo nesusijusių procesų.
- Kontroliuojamas atkūrimas: Atskirą paslaugą galima paleisti iš naujo nebūtinai perkraunant visą sistemą.
- Mažiau privilegijuoto kodo: Mažiau komponentų turi veikti su aukščiausio lygio sistemos teisėmis.
- Atminties izoliacija: Apsaugotos adresų erdvės padeda užkirsti kelią vienai programai tiesiogiai trukdyti kitai.
- Mišraus kritiškumo palaikymas: Realaus laiko valdymo užduotys gali veikti kartu su HMI, tinklo, analitikos ir DI užduotimis.
- Priežiūra per visą gyvavimo ciklą: Modulinės paslaugos gali supaprastinti priežiūrą ir komponentų lygmens atnaujinimus.
Mikrobranduolys nepanaikina programinės įrangos defektų ar kibernetinio saugumo pažeidžiamumų. Jo vertė slypi architektūrinių ribų nustatyme, kurios gali apriboti atskirų gedimų ar pažeidimų pasekmes.
Realaus laiko determinizmas išlieka esminiu reikalavimu
Pramonės modernizavimas neturėtų leisti, kad DI ir didelio našumo skaičiavimo reikalavimai nustelbtų deterministinio valdymo reikalavimus.
Valdymo taikomosioms programoms svarbu ne tik tai, kiek skaičiavimo galios yra prieinama. Sistema taip pat turi užtikrinti nuspėjamą planavimo veikimą ir ribotas atsako charakteristikas funkcijoms, kurioms nustatyti laiko reikalavimai.
Tai ypač svarbu, kai DI arba analitikos užduotys naudoja daug skaičiavimo išteklių.
Mano vertinimu, todėl praktinė architektūra yra ne „DI pakeičia valdymą“, o deterministinis valdymas veikia kartu su aukštesnio lygio intelektu, naudojant kontroliuojamas išteklių ribas.
Kibernetinis saugumas turi apimti visą gaminio gyvavimo ciklą
Techninė izoliacija yra tik viena kibernetinio atsparumo dalis.
Pramonės gamintojams taip pat reikia procesų, skirtų programinės įrangos komponentams nustatyti, pažeidžiamumams stebėti, atnaujinimams patvirtinti, programinės įrangos tiekimui kontroliuoti ir gaminiams prižiūrėti per visą jų eksploatavimo laiką.
ISA/IEC 62443 serija suteikia į gyvavimo ciklą orientuotą sistemą, ypač aktualią pramonės automatizavimo ir valdymo sistemoms. Kiti standartai, įskaitant ISO/SAE 21434, parodo, kaip struktūrizuotas kibernetinio saugumo rizikos valdymas gali būti taikomas nuo kūrimo iki eksploatavimo, priežiūros ir eksploatavimo nutraukimo.
Europos kibernetinio atsparumo aktas taip pat didina gaminių, kuriems jis taikomas, kibernetinio saugumo valdymo per visą gyvavimo ciklą svarbą.
Pramoninės įrangos gamintojams tai reiškia, kad kibernetinis saugumas pagrįstai negali būti laikomas tik galutinio etapo sertifikavimo veikla. Programinės įrangos sudėtį, pažeidžiamumų valdymą, atnaujinimo mechanizmus, tiekėjų valdymą ir gaminio priežiūrą reikia įvertinti sistemos kūrimo metu.
Saugumo architektūra turėtų palaikyti atkūrimą, o ne tik prevenciją
Tradicinėse kibernetinio saugumo diskusijose dažnai daugiausia dėmesio skiriama neleistinos prieigos prevencijai. Pramonės atsparumui užtikrinti reikia platesnio požiūrio.
Pažeistas arba sugedęs komponentas vis tiek gali atsirasti nepaisant prevencinių kontrolės priemonių. Todėl architektūra turi apriboti komponento galimybes paveikti kritines funkcijas ir numatyti aiškų atkūrimo kelią.
Taip suformuluojami trys vienas kitą papildantys inžineriniai tikslai:
- Užkirsti kelią neleistinam ar nenumatytam elgesiui.
- Izoliuoti gedimus ir pažeistus komponentus.
- Atkurti paveiktas paslaugas, išlaikant nepaveiktas operacijas.
Pramonės automatizavimui šis derinys yra praktiškesnis nei vien pasikliauti prevencija.
QNX kaip pamatinė realiojo laiko platforma
QNX užtikrina mikrobranduoliu pagrįstą realiojo laiko operacinės sistemos architektūrą, skirtą sistemoms, kuriose svarbūs nuspėjamas vykdymas, procesų izoliavimas ir kontroliuojama prieiga prie išteklių.
Pramonės automatizavimo architektūroje QNX gali užtikrinti pamatinę vykdymo aplinką taikomosioms programoms, tvarkyklėms, protokolų stekams ir failų sistemoms, veikiančioms apsaugotose adresų erdvėse. Prioritetais pagrįstas planavimas gali palaikyti skirtingų laiko reikalavimų krūvius.
Ši architektūra gali papildyti PLC pagrįstą valdymą, o ne jį pakeisti.
Praktinėje sistemoje gali būti naudojami PLC, skirti nusistovėjusiam lauko lygmens valdymui, o MPU arba SoC pagrindu veikiančios skaičiavimo platformos, kuriose veikia realiojo laiko operacinė sistema, gali būti naudojamos HMI, kompiuterinei regai, ryšiui, analitikai, priežiūros funkcijoms ir su DI susijusiems krūviams.
Praktiška pramonės modernizavimo architektūra
Todėl šiuolaikinę pramoninę sistemą galima laikyti keliais tarpusavyje veikiančiais sluoksniais:
- Lauko sluoksnis: jutikliai, pavaros, varikliai ir kita fizinė įranga.
- Valdymo sluoksnis: PLC ir valdikliai, atliekantys deterministinį automatizavimą.
- Skaičiavimo sluoksnis: MPU/SoC platformos, suteikiančios papildomų apdorojimo pajėgumų.
- Intelekto sluoksnis: kompiuterinė rega, analitika, DI išvados ir kiti skaičiavimo krūviai.
- Priežiūros sluoksnis: HMI, diagnostika, įvykių valdymas ir operacinės taikomosios programos.
- Ryšio sluoksnis: pramoniniai tinklai ir išorinio ryšio paslaugos.
- Pamatinis programinės įrangos sluoksnis: realiojo laiko operacinė sistema, izoliavimas, planavimas, išteklių valdymas ir atkūrimo mechanizmai.
Pagrindinis inžinerinis reikalavimas - apibrėžti ribas tarp šių sluoksnių, o ne laikyti visą skaičiavimo aplinką viena nediferencijuota taikomųjų programų erdve.
Modernizavimas turėtų išsaugoti esamas investicijas į valdymą
Pramonės įranga dažnai eksploatuojama daugelį metų. Pakeisti nusistovėjusį PLC pagrįstą valdymą vien todėl, kad atsirado naujos skaičiavimo galimybės, ne visada techniškai ar ekonomiškai pagrįsta.
Praktiškesnė modernizavimo strategija - išsaugoti patikrintas valdymo funkcijas ir papildyti jas skaičiavimo ištekliais.
MPU ir SoC pagrįstos platformos gali suteikti šiuolaikinėms HMI, dirbtinio intelekto, analitikos, vizualizacijos ir ryšio funkcijoms reikalingą skaičiavimo galią, o esami PLC gali toliau vykdyti deterministinį valdymą.
Šis būdas leidžia gamintojams diegti naujas galimybes be reikalo neardant nusistovėjusių valdymo architektūrų.
Mano, kaip inžinieriaus, požiūris: atsparumas prasideda nuo architektūros
Svarbiausia šio perėjimo pamoka yra ta, kad atsparumo negalima pridėti po to, kai sistema jau konsoliduota.
Kai valdymas, tinklo funkcijos, HMI, analitika ir dirbtinis intelektas naudoja bendrus skaičiavimo išteklius, izoliavimo ir atkūrimo mechanizmai turi būti numatyti jau pradinėje architektūroje.
Galingas procesorius pats savaime nesukuria atsparios automatizavimo sistemos. Taip pat dirbtinio intelekto modelis nepadaro automatizavimo sistemos išmanios, jei aplinkinė platforma negali gauti duomenų, vykdyti modelio, patikrinti jo rezultatų, užtikrinti iš anksto nustatytų politikų laikymosi ir reaguoti neperžengdama nustatytų veikimo ribų.
Todėl naujos kartos pramonės automatizavimas priklausys ne tik nuo didesnio skaičiavimo našumo, bet ir nuo to, kaip veiksmingai programinės įrangos architektūra kontroliuoja sąveiką tarp skaičiavimo krūvių.
Išvada
Pramonės automatizavimas pereina prie architektūros, kurioje PLC, didelio našumo procesoriai, dirbtinis intelektas, ryšys ir programinės įrangos apibrėžiamos funkcijos vis dažniau veikia kartu.
Tai sukuria didelių modernizavimo galimybių, tačiau kartu atsiranda naujų priklausomybių ir gedimų scenarijų.
Atspari architektūra turi apimti deterministinį vykdymą, procesų izoliavimą, atminties apsaugą, kontroliuojamą prieigą prie išteklių, gedimų lokalizavimą, kibernetinio saugumo valdymą per visą gyvavimo ciklą ir nustatytus atkūrimo mechanizmus.
Mikrobranduoliu pagrįstos realiojo laiko operacinės sistemos, tokios kaip QNX, yra vienas iš būdų įgyvendinti šiuos reikalavimus. Naudojamos kartu su esamomis PLC ir valdiklių technologijomis, tokios platformos gali suteikti programinės įrangos pagrindą, reikalingą šiuolaikiniams skaičiavimo krūviams integruoti, kartu išlaikant aiškias kritinių automatizavimo funkcijų ribas.
