Gamyklos plėtra ir IT/OT architektūra – kodėl po kelių metų improvizuotos integracijos atsisuka prieš jus?

Kodėl ši tema šiandien svarbi

Gamyklos plėtra vis rečiau apsiriboja vienos mašinos pastatymu ar dar vienos linijos paleidimu atskirai nuo visumos. Dažniausiai tai reiškia aplinkos plėtrą, kurioje gamybos sistemos, techninė priežiūra, kokybė, planavimas, sandėlis ir valdymo ataskaitų teikimas turi keistis duomenimis ir daro tarpusavio įtaką proceso prieinamumui. Tokioje sistemoje IT/OT architektūra nustoja būti techniniu klausimu, kurį galima „nuspręsti vėliau“, ir tampa projektiniu sprendimu, turinčiu finansinių bei organizacinių pasekmių. Laikinos integracijos veikia paleidimo etape, nes išsprendžia einamąją problemą: greitai prijungia naują mašiną, eksportuoja kelis signalus į ataskaitą, apeina senesnio valdiklio apribojimus. Tačiau po kelerių metų jos atsisuka prieš pačią įmonę, kai gamykla bando didinti našumą, atitikti naujus atitikties reikalavimus arba saugiai pakeisti įrenginio darbo būdą. Tuomet paaiškėja, kad problema yra ne pavienis laidas ar scenarijus, o nuoseklių komunikacijos, atsakomybių ir funkcijų atskyrimo principų stoka.

Didžiausia klaida – tokius sprendimus laikyti neutraliais sąnaudų požiūriu. Jie tik nukelia sąnaudas į ateitį ir paprastai tai padaro pačiu netinkamiausiu momentu: plėtros, audito, incidento ar tiekėjo keitimo metu. Projekto požiūriu pasekmė yra ne vien didesnė kito etapo įgyvendinimo kaina, bet ir nuspėjamumo praradimas. Komanda jau nebežino, kurios priklausomybės yra kritinės gamybos tęstinumui, kur baigiasi integratoriaus atsakomybė ir kur prasideda gamyklos savininko atsakomybė, taip pat kurie pakeitimai reikalauja pakartotinio rizikos vertinimo. Praktikoje būtent čia prasideda paslėptų neteisingų projektinių sprendimų sąnaudų sritis: papildomos prastovos, skubūs serviso darbai, pakartotiniai priėmimai, sunkumai dokumentuojant pakeitimus ir ginčai dėl garantijos apimties. Jei architektūra nebuvo aprašyta kaip sąmoningas gamyklos plėtros modelis, kiekvienas kitas etapas bus apsunkintas technine ir organizacine skola.

Geras praktinis patikrinimas yra ne klausimas, ar integracija „veikia“, o ar ją bus galima saugiai ir nuspėjamai pakeisti po dviejų ar trijų investicijos etapų. Jei naujai linijai reikia rankiniu būdu susieti signalus keliose vietose, žinios apie jungtis yra išskaidytos tarp tiekėjų, o viso duomenų kelio atkūrimas reikalauja analizuoti valdiklių kodą, tarpines duomenų bazes ir nedokumentuotas paslaugas, projektas jau pateko į padidintos rizikos kelią. Situaciją verta vertinti pagal tris išmatuojamus kriterijus: laiką, reikalingą kontroliuojamam pakeitimui įgyvendinti, galimybę vienareikšmiškai nurodyti kiekvieno duomenų mainų proceso savininką ir gebėjimą atkurti gedimo ar modifikacijos poveikį gamybai bei saugai. Jei šių trijų dalykų neįmanoma aiškiai apibrėžti, problema susijusi ne su komandos patogumu, o su viso projekto valdomumu.

Praktikoje nuolat kartojasi tas pats scenarijus: gamykla paleidžia naują gamybos zoną ir, siekdama greito starto, prijungia procesų duomenis prie verslo sistemų per tarpinius sprendimus, sukurtus už tikslinės architektūros ribų. Kurį laiką viskas atrodo tvarkinga, nes duomenų srauto pakanka ataskaitoms ir einamajai priežiūrai. Problemos prasideda toliau automatizuojant, integruojant su technine priežiūra arba keičiant mašinos veikimo logiką. Tuomet vienas pakeitimas operacinėje grandyje paveikia ataskaitas, aliarmus, receptūras ar nuotolinę prieigą, o priklausomybės jau nebėra akivaizdžios. Jei sprendimas papildomai įsikiša į funkcijas, susijusias su stabdymu, energijos atjungimu ar pakartotinio paleidimo blokavimu, tema nustoja būti vien informacinių technologijų klausimu. Ji pereina į funkcinės saugos sritį ir reikalauja atskiros analizės, įskaitant patikrinimą, ar nebuvo pažeistos prielaidos dėl apsaugos nuo netikėto paleidimo. Šioje vietoje IT/OT architektūra tiesiogiai susiliečia su rizikos analize gamyklos plėtros projekte ir su sprendimais, kurie vėliau daro įtaką ir atitikties vertinimo apimčiai bei techninei dokumentacijai.

Todėl sprendimą šia tema reikia priimti dabar, o ne pasibaigus paleidimo darbams. Ne todėl, kad kiekviena integracija nuo pat pradžių turi būti išplėtota, o todėl, kad jau starto metu būtina atskirti laikiną sprendimą nuo sprendimo, kuris taps nuolatinės gamyklos architektūros dalimi. Toks atskyrimas turi turėti projektines pasekmes: atskirą sprendimo savininką, apėjimo sprendimo atsisakymo sąlygas, dokumentavimo reikalavimus ir pakartotinio vertinimo kriterijus plėtros metu. Jei gamykla planuoja tolesnius investicijų etapus, mašinų modernizavimą ar pasirengimą atitikties vertinimui, tokio atskyrimo nebuvimas beveik visada padidina pakeitimo kainą ir išplečia investuotojo atsakomybės apimtį. Būtent todėl IT/OT architektūra šiandien nėra projekto priedas, o viena iš sąlygų išlaikyti sąnaudų, grafiko ir rizikos kontrolę.

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

Didžiausias gamyklos plėtros kaštų šaltinis paprastai nėra pačios sąsajos tarp IT ir OT, o „laikinai“ priimtų sprendimų pasekmės, kai po kelerių metų jie ima veikti kaip nuolatinė architektūra. Laikina integracija atsisuka prieš organizaciją ne todėl, kad buvo techniškai netobula, o todėl, kad niekas neapibrėžė jos ribų: kas atsako už pakeitimą, kurie duomenys yra pirminiai, kaip po gedimo atkurti konfigūraciją ir kada toks apeinamasis sprendimas turi būti panaikintas. Praktikoje kaštai auga ten, kur laikinas sprendimas be formalaus sprendimo, kad nuo šio momento jis tampa kritiniu elementu, patenka į techninę priežiūrą, gamybą, kokybės valdymą ar vadovybės ataskaitų rengimą. Projektui tai vėliau reiškia ginčus dėl biudžeto ir apimties, o organizacijai – ir atsakomybės išsklaidymą: gedimas atrodo kaip techninė problema, nors jo priežastis buvo neužbaigtas architektūrinis sprendimas. Naudingas vertinimo kriterijus čia yra paprastas klausimas: ar po gamyklos išplėtimo galima aiškiai nurodyti proceso savininką, duomenų savininką ir saugaus pakeitimo procedūrą, neįtraukiant „vienintelio žmogaus, kuris žino, kaip tai veikia“. Jei ne, rizika jau yra įrašyta į projektą.

Kita augančių kaštų sritis – neatskirtas valdymo sluoksnis nuo verslo duomenų mainų sluoksnio. Pirmajame investicijos etape toks supaprastinimas gali atrodyti patrauklus: tas pats serveris tarpininkauja ryšiui su mašina, archyvuoja duomenis, tiekia juos ataskaitai ir aptarnauja nuotolinę serviso prieigą. Esant vienai linijai tai veikia tariamai teisingai, tačiau vėlesniuose plėtros etapuose kiekvieno tikslo pakeitimas ima veikti ir kitus. Įmonės sistemos priverstinis atnaujinimas gali sutrikdyti gamybos tęstinumą, o poreikis greitesniam ataskaitų rengimui gali lemti įsikišimą į anksčiau stabiliai veikusių įrenginių konfigūraciją. Tuomet paslėpti neteisingų projektinių sprendimų kaštai neapsiriboja tik papildomu įrangos ar integratoriaus paslaugų pirkimu. Kur kas skaudesni yra prastovų, pakartotinių bandymų, naktinio darbo diegimų metu ir būtinybės atkurti niekur neužfiksuotas žinias kaštai. Projektų valdymo požiūriu protingas minimumas – įvertinti, ar gedimas arba pakeitimas IT dalyje gali sustabdyti mašinos ar linijos veikimą. Jei atsakymas teigiamas, architektūrą reikia koreguoti nepriklausomai nuo to, kad „kol kas veikia“.

Tipinis pavyzdys iškyla prijungiant naujas mašinas prie esamos gamyklos infrastruktūros. Tiekėjas įrenginį paleidžia greitai, nes reikia priėmimo ir gamybos starto, todėl ryšį su gamyklos sistemomis įgyvendina per papildomą kompiuterį, failus eksportuojantį scenarijų arba rankiniu būdu koreguojamą signalų žemėlapį. Po metų atsiranda dar viena mašina, po dvejų metų pasikeičia aukštesnio lygio sistema, o po trejų paaiškėja, kad niekas nebegali vienareikšmiškai aprašyti, kurie pranešimai yra kritiniai procesui, kurie skirti tik ataskaitoms, o kurie svarbūs diagnostikai ar partijų atsekamumui. Šioje vietoje tema iš dalies pereina ir į mašinų naudojimo instrukcijų rengimo sritį, nes jeigu operatorius, techninė priežiūra ar servisas neturi dokumentuotų veiksmų taisyklių ryšio dingimo, rankinio apeinamojo režimo ar parametrų atkūrimo po komponento pakeitimo atveju, problema nustoja būti vien informacinių technologijų klausimu. Ji tampa saugaus eksploatavimo organizavimo ir vėlesnės atsakomybės už naudojimo būdą bei modifikacijas dalimi.

Tik šiame etape tampa aišku, kodėl klausimas grįžta ir vertinant atitiktį, techninę dokumentaciją bei planuojant pakeitimų biudžetą. Jeigu integracija daro įtaką mašinos funkcijoms, blokuočių logikai, būsenų patvirtinimo būdui ar naudotojui perduodamai informacijai, gali prireikti pakartotinės rizikos analizės ir patikrinimo, ar dokumentacija vis dar atitinka realų sprendimą. Šio vertinimo apimtis priklauso nuo pakeitimo pobūdžio, todėl jos neįmanoma sąžiningai nuspręsti vienu universaliu sakiniu, tačiau būtent dėl to laikini sprendimai yra tokie brangūs: jie apsunkina nustatymą, kas iš tikrųjų buvo pakeista ir kokios yra teisinės bei eksploatacinės pasekmės. Sprendimus priimančiai komandai praktinis kriterijus yra toks: jeigu integracijos pakeitimo neįmanoma aprašyti konfigūracijos dokumentacijoje, bandymų procedūroje ir eksploatavimo taisyklėse, nesiremiant neformaliomis žiniomis, vadinasi, projektas jau pateko į zoną, kur auga ne tik techniniai kaštai, bet ir investuotojo, projekto vadovo bei asmenų, leidžiančių sprendimą eksploatuoti, atsakomybė.

Kaip prie to prieiti praktiškai

Praktikoje klausimas skamba ne taip, ar IT ir OT integruoti greičiau, o kur nubrėžti ribą tarp laikino sprendimo ir architektūrinės skolos, kuri po kelerių metų užblokuos gamyklos plėtrą. Laikini sujungimai paprastai atsiranda paleidimo spaudimo sąlygomis: reikia greitai paimti duomenis iš mašinos, pridėti naują liniją, sujungti kokybės sistemą su gamybos registrais arba užtikrinti nuotolinę serviso prieigą. Problema prasideda tada, kai „trumpam“ įdiegtas sprendimas tampa pagrindu tolesniems projektiniams sprendimams. Komanda praranda aiškų atsakomybių pasidalijimą, o kiekviena plėtra reikalauja atkurti žinias iš susirašinėjimo, vietinių nustatymų ir operatorių praktikos. Tai jau nebe smulkus techninis nepatogumas, o veiksnys, darantis įtaką grafikui, pakeitimo kaštams ir galimybei parodyti, kas ir kuo remdamasis leido konkretų sprendimą eksploatuoti.

Todėl tinkamas požiūris prasideda nuo architektūrinio sprendimo, o ne nuo įrankio pasirinkimo. Vadovas arba srities savininkas turėtų reikalauti, kad kiekvienai naujai integracijai būtų aiškiai apibrėžtas veiklos tikslas, paskirti atsakingi asmenys abiejose IT/OT ribos pusėse ir nustatytos priežiūros sąlygos po paleidimo. Jeigu neaišku, kas atsako už duomenų šaltinį, kas tvirtina konfigūracijos pakeitimą, kas testuoja poveikį procesui ir kas sprendžia dėl avarinio režimo, projektas iš esmės perkelia riziką į eksploatacijos etapą. Būtent čia natūraliai atsiranda projekto vadovo vaidmuo priimant IT/OT sprendimus: ne kaip terminų koordinatoriaus, o kaip žmogaus, kuris priverčia aiškiai paskirstyti atsakomybes dar prieš tai, kai laikinas sprendimas biudžete ir grafike įrašomas kaip „greitas apėjimas“. Praktinis vertinimo kriterijus paprastas: jeigu planuojamos integracijos nebus įmanoma prižiūrėti pasikeitus tiekėjui, pakeitus valdiklį ar išplėtus liniją be pirminio apėjimo autoriaus įsitraukimo, tai nėra laikinas sprendimas, o būsimos projekto sąnaudos.

Geras testas – esamos linijos išplėtimas papildoma darbo vieta, kuri turi perduoti duomenis į aukštesnio lygio sistemą ir kartu reaguoti į jau veikiančios dalies būsenas. Jeigu komanda nusprendžia tiesiogiai prijungti signalus ir neformaliai versti duomenis „nes taip bus greičiau“, iš pradžių viskas gali veikti tinkamai. Tačiau ilgainiui atsiranda šalutinis poveikis: tampa sunkiau nustatyti, ar klaida kyla dėl mašinos logikos, komunikacijos sluoksnio, ar ataskaitų teikimo programos; priėmimo bandymai apima tik standartinius scenarijus; vieno elemento modernizavimas verčia vienu metu taisyti kelias vietas. Tada išryškėja ir paslėptos neteisingų projektinių sprendimų sąnaudos: papildomos prastovos diagnostikai, brangiai kainuojantis integratoriaus dalyvavimas atliekant kiekvieną pakeitimą, ginčai dėl garantijos apimties ir vėlavimai kituose investicijos etapuose. Todėl verta matuoti ne tik paleidimo laiką, bet ir integracijos taškų, kuriems reikia rankinės konfigūracijos, skaičių, laiką, reikalingą incidentui po pakeitimo išanalizuoti, taip pat pakeitimų, kuriuos reikia testuoti skersai visos sistemos, o ne lokaliai, skaičių.

Tik šiame kontekste prasminga kalbėti apie saugos ir atitikties reikalavimus. Jeigu integracija daro įtaką mašinos darbo būsenoms, blokavimams, signalų patvirtinimams, paleidimo ar sustabdymo sekai, ji nustoja būti neutraliu informacinių technologijų priedu. Priklausomai nuo pakeitimo pobūdžio, gali atsirasti poreikis iš naujo atlikti rizikos vertinimą, atnaujinti techninę dokumentaciją ir patikrinti, ar eksploatavimo būdas vis dar atitinka prielaidas, priimtas konkrečiai mašinai ar linijai. Tai ypač aiškiai matyti ten, kur integracijos sluoksnis pradeda netiesiogiai veikti saugios prieigos sąlygas, energijos atjungimą arba apsaugą nuo netikėto paleidimo. Tokiu atveju architektūrinis sprendimas iš diegimo patogumo srities pereina į teisinės ir techninės atsakomybės sritį. Jeigu komanda negali parodyti, kurios jungtys yra tik informacinio pobūdžio, o kurios daro įtaką mašinos elgsenai, tai ženklas, kad šį klausimą reikia iškelti iš „sistemų integracijos“ lygmens ir vertinti kaip pakeitimą, reikšmingą saugai, biudžetui ir sprendimą tvirtinančių asmenų atsakomybei.

Į ką atkreipti dėmesį diegiant

Daugiausia problemų kyla ne dėl pačios IT/OT integracijos, o dėl to, kad projekte ji traktuojama kaip greita priemonė naujai funkcijai paleisti, o ne kaip ilgalaikis gamyklos architektūros elementas. Būtent tada laikinos jungtys atsisuka po kelių metų: plečiant liniją, keičiant valdiklius, keičiantis aukštesnio lygio sistemos tiekėjui arba atliekant saugos auditą paaiškėja, kad niekas negali vienareikšmiškai nurodyti sąsajos savininko, jos veikimo principų ar gedimo pasekmių. Projektui tai reiškia ne tik techninės skolos kainą, bet ir organizacines sąnaudas: daugiau derinimų, ilgesnius skersinius testus, sudėtingesnį priėmimą ir didesnę riziką, kad vėlavimas išryškės tik pabaigoje, kai grafikas jau mažiausiai lankstus. Šioje vietoje tema natūraliai pereina į paslėptų neteisingų projektinių sprendimų sąnaudų sritį, nes problemos šaltinis yra ne pavienė vykdymo klaida, o sprendimas tinkamą architektūrą atidėti vėlesniam laikui.

Diegiant todėl verta vertinti sprendimą ne pagal tai, ar jis „veiks dabar“, o pagal tai, ar jį bus galima prižiūrėti ir saugiai keisti nuspėjamu būdu. Praktinis kriterijus paprastas: jeigu planuojamai integracijai nėra aprašytos atsakomybės ribos, gedimo režimas, versijavimo taisyklės ir bandymų po pakeitimo procedūra, ji dar nėra parengta diegti į gamybą, net jeigu veikia bandomojoje darbo vietoje. Tai ypač svarbu ten, kur ta pati sąsaja turi aptarnauti ir dabartinį investicijos etapą, ir būsimą plėtrą. Gamyklos plėtra beveik visada didina priklausomybių tarp sistemų skaičių, o laikini sprendimai blogiausiai veikia būtent tada, kai daugėja išimčių, apėjimų ir vietinių susitarimų. Projekto vadovo požiūriu tai reiškia būtinybę anksti nuspręsti, kas tvirtina ribinius sprendimus tarp automatikos, techninės priežiūros, informacinių technologijų ir atitikties, nes priešingu atveju atsakomybė išsiskaido būtent ten, kur vėliau kyla didžiausi ginčai dėl kainos ir termino.

Tipinis praktinis pavyzdys – papildomai įdiegti duomenų mainus tarp linijos ir ataskaitų sistemos per tarpinį scenarijų arba nedokumentuotą paslaugą, veikiančią serveryje, kuris „jau stovi gamykloje“. Paleidimo etape toks sprendimas atrodo racionalus: nereikia nieko keisti mašinos tiekėjo pusėje, sutrumpėja diegimo laikas ir galima greitai parodyti verslo rezultatą. Problema išryškėja vėliau. Atnaujinus operacinę sistemą, pakeitus adresaciją, atkūrus atsarginę kopiją arba pakeitus įrenginį, niekas nebegali būti tikras, ar signalų susiejimo logika vis dar atitinka realų proceso veikimą. Jeigu šis mechanizmas dalyvauja patvirtinimuose, blokavimuose, užsakymų eilės sudaryme arba paleidimo sąlygose, gedimas nustoja būti vien IT incidentu ir pradeda veikti linijos prieinamumą, gamybos kokybę bei atsakomybę už sprendimo leidimą eksploatuoti. Tuomet tema natūraliai pereina į rizikos vertinimą keičiant mašinas ir gamybos linijas fabriko plėtros projekte, nes reikia įvertinti ne tik gedimo tikimybę, bet ir neteisingos informacijos, neteisingos sekos bei neteisingos operatoriaus reakcijos pasekmes.

Tik šiame kontekste prasminga remtis formaliaisiais reikalavimais. Jeigu integracijos sluoksnis atlieka tik informacinę funkciją ir tai galima techniškai įrodyti, pareigų apimtis bus kitokia nei tuo atveju, kai jis daro įtaką mašinos ar linijos veiksenai. Tačiau jeigu jis veikia darbo logiką, paleidimo, sustabdymo, patvirtinimo ar apėjimo sąlygas, diegimą reikia vertinti kaip techniškai reikšmingą ir potencialiai su sauga susijusį pakeitimą, o ne kaip paprastą sistemos išplėtimą. Tai gali reikšti, kad būtina iš naujo patikrinti prielaidas, kuriomis grindžiamas rizikos vertinimas, techninė dokumentacija ir konkrečiam sprendimui taikomos atitikties sąlygos. Praktikoje saugus klausimas skamba ne „ar tai galima prijungti“, o „ar po diegimo sugebėsime įrodyti, ką ši sąsaja daro, kas už ją atsako ir kaip valdome pakeitimą“. Jeigu atsakymas nėra vienareikšmis, atidėto architektūrinio sprendimo kaina paprastai sugrįžta per kitą modernizaciją, sertifikavimą ar incidentą, ir tada tai jau būna ne tik techninė, bet ir valdymo problema, susijusi ir su mašinų atitikties vertinimu.