Rūpnīcas attīstība un IT/OT arhitektūra – kāpēc pagaidu integrācijas pēc dažiem gadiem rada problēmas?

Kāpēc šī tēma šodien ir svarīga

Rūpnīcas attīstība arvien retāk nozīmē vienas iekārtas pievienošanu vai nākamās līnijas palaišanu izolēti. Parasti tā nozīmē vides paplašināšanu, kurā ražošanas sistēmām, tehniskajai uzturēšanai, kvalitātei, plānošanai, noliktavai un vadības atskaitēm ir jāapmainās ar datiem un tās savstarpēji ietekmē procesa pieejamību. Šādā situācijā IT/OT arhitektūra vairs nav tehnisks jautājums, ko “izlems vēlāk”, bet kļūst par projektēšanas lēmumu ar finansiālām un organizatoriskām sekām. Pagaidu integrācijas darbojas palaišanas posmā, jo atrisina aktuālu problēmu: ātri pieslēdz jaunu iekārtu, eksportē dažus signālus atskaitei, apiet vecāka kontroliera ierobežojumus. Tās atspēlējas pēc dažiem gadiem, kad uzņēmums mēģina palielināt ražīgumu, izpildīt jaunas atbilstības prasības vai droši mainīt iekārtas darbības veidu. Tad izrādās, ka problēma nav atsevišķs vads vai skripts, bet gan vienotu komunikācijas, atbildības un funkciju nodalīšanas principu trūkums.

Lielākā kļūda ir uzskatīt šādus risinājumus par izmaksu ziņā neitrāliem. Tie tikai pārceļ izmaksas laikā un parasti to dara visnepiemērotākajā brīdī: paplašināšanas laikā, audita laikā, incidenta gadījumā vai mainot piegādātāju. No projekta skatpunkta sekas nav tikai dārgāka nākamā posma ieviešana, bet arī paredzamības zudums. Komanda vairs nezina, kuras atkarības ir kritiskas ražošanas nepārtrauktībai, kur beidzas integratora atbildība un kur sākas rūpnīcas īpašnieka atbildība, kā arī kurām izmaiņām nepieciešams atkārtots riska novērtējums. Praksē tieši šeit sākas nepareizu projektēšanas lēmumu slēpto izmaksu zona: papildu dīkstāves, operatīvi servisa darbi, atkārtotas pieņemšanas, grūtības dokumentēt izmaiņas un strīdi par garantijas apjomu. Ja arhitektūra nav aprakstīta kā apzināts rūpnīcas attīstības modelis, tad katrs nākamais posms būs apgrūtināts ar tehnisko un organizatorisko parādu.

Labs praktisks pārbaudījums nav jautājums, vai integrācija “darbojas”, bet gan tas, vai to var droši un paredzami mainīt pēc diviem vai trim investīciju posmiem. Ja jaunai līnijai nepieciešama manuāla signālu kartēšana vairākās vietās, zināšanas par savienojumiem ir izkaisītas starp piegādātājiem, bet pilnas datu plūsmas atjaunošanai nepieciešama kontrolieru koda, starpbāzu un nedokumentētu pakalpojumu analīze, tad projekts jau ir nonācis paaugstināta riska zonā. Situāciju ir vērts vērtēt pēc trim izmērāmiem kritērijiem: laiks, kas nepieciešams kontrolētu izmaiņu ieviešanai, iespēja nepārprotami norādīt katras datu apmaiņas īpašnieku un spēja atjaunot avārijas vai modifikācijas ietekmi uz ražošanu un drošību. Ja šīs trīs lietas nav skaidri nosakāmas, tad problēma nav saistīta ar komandas ērtībām, bet gan ar visa projekta vadāmību.

Piemērs no prakses atkārtojas bieži: uzņēmums palaiž jaunu ražošanas zonu un ātras palaišanas vajadzībām pieslēdz procesa datus biznesa sistēmām, izmantojot starprisinājumus, kas izveidoti ārpus mērķa arhitektūras. Kādu laiku viss izskatās pareizi, jo datu plūsma ir pietiekama atskaitēm un ikdienas uzraudzībai. Problēmas sākas pie turpmākas automatizācijas, integrācijas ar tehnisko uzturēšanu vai mainot iekārtas darbības loģiku. Tad viena izmaiņa operatīvajā slānī ietekmē atskaites, trauksmes, receptes vai attālināto piekļuvi, un atkarības vairs nav acīmredzamas. Ja risinājums turklāt iejaucas funkcijās, kas saistītas ar apturēšanu, enerģijas atslēgšanu vai atkārtotas palaišanas bloķēšanu, tēma vairs nav tikai informācijas tehnoloģiju jautājums. Tā pāriet funkcionālās drošības jomā un prasa atsevišķu analīzi, tostarp pārbaudi, vai nav pārkāpti pieņēmumi par aizsardzību pret negaidītu iedarbināšanu. Šajā brīdī IT/OT arhitektūra tieši saskaras ar riska analīzi rūpnīcas attīstības projektā un ar lēmumiem, kas vēlāk ietekmē arī atbilstības novērtēšanas apjomu un tehnisko dokumentāciju.

Tāpēc šī tēma prasa lēmumu tagad, nevis pēc palaišanas pabeigšanas. Ne tāpēc, ka katrai integrācijai jau no sākuma jābūt sarežģītai, bet tāpēc, ka jau startā ir jānošķir pagaidu risinājums no risinājuma, kam jākļūst par daļu no rūpnīcas pastāvīgās arhitektūras. Šai atšķirībai jāatstāj ietekme uz projektu: atsevišķs lēmuma īpašnieks, apiešanas risinājuma atsaukšanas nosacījumi, dokumentācijas prasības un atkārtotas izvērtēšanas kritēriji paplašināšanas gadījumā. Ja uzņēmums plāno nākamos investīciju posmus, iekārtu modernizāciju vai sagatavošanos atbilstības novērtēšanai, šādas nošķiršanas trūkums gandrīz vienmēr palielina izmaiņu izmaksas un paplašina investora atbildības apjomu. Tieši tāpēc IT/OT arhitektūra šodien nav projekta papildinājums, bet viens no priekšnoteikumiem, lai saglabātu kontroli pār izmaksām, termiņiem un risku.

Kur visbiežāk pieaug izmaksas vai risks

Parasti visdārgākā rūpnīcas attīstības daļa nav pašas saskarnes starp IT un OT, bet gan sekas lēmumiem, kas pieņemti “uz brīdi” un pēc dažiem gadiem sāk pildīt pastāvīgas arhitektūras funkciju. Pagaidu integrācija atmaksājas ar problēmām nevis tāpēc, ka tā būtu tehniski nepilnīga, bet tāpēc, ka neviens nav noteicis tās robežas: kurš atbild par izmaiņām, kuri dati ir avota dati, kā pēc avārijas atjaunot konfigurāciju un kurā brīdī pagaidu risinājums ir jālikvidē. Praksē izmaksas pieaug tur, kur pagaidu risinājums bez formāla lēmuma nonāk ekspluatācijas uzturēšanā, ražošanā, kvalitātes nodrošināšanā vai vadības atskaitēs un no tā brīža faktiski kļūst par kritisku elementu. Projektam tas nozīmē vēlākus strīdus par budžetu un apjomu, bet organizācijai — arī atbildības izplūšanu: atteice izskatās pēc tehniskas problēmas, lai gan tās cēlonis bija nenoslēgts arhitektūras lēmums. Noderīgs vērtēšanas kritērijs šeit ir vienkāršs jautājums: vai pēc uzņēmuma paplašināšanas var skaidri norādīt procesa īpašnieku, datu īpašnieku un drošu izmaiņu procedūru, neiesaistot “vienīgo cilvēku, kurš zina, kā tas darbojas”. Ja nē, risks projektā jau ir iestrādāts.

Otra pieaugošo izmaksu joma ir vadības slāņa nenodalīšana no biznesa datu apmaiņas slāņa. Investīciju pirmajā posmā šāds saīsināts ceļš šķiet vilinošs: viens un tas pats serveris nodrošina saziņu ar iekārtu, arhivē datus, baro atskaiti un apkalpo attālinātu servisa piekļuvi. Vienai līnijai tas šķietami darbojas korekti, taču nākamajos paplašināšanas posmos jebkuras izmaiņas vienā mērķī ietekmē pārējos. Atjauninājums, ko pieprasa uzņēmuma sistēma, var izjaukt ražošanas nepārtrauktību, bet vajadzība pēc ātrākas atskaišu sagatavošanas var novest pie iejaukšanās to iekārtu konfigurācijā, kas iepriekš darbojās stabili. Tad kļūdainu projektēšanas lēmumu slēptās izmaksas neaprobežojas tikai ar papildu aparatūras vai integratora pakalpojumu iegādi. Daudz sāpīgākas ir dīkstāvju izmaksas, atkārtotas pārbaudes, nakts darbs ieviešanas laikā un nepieciešamība atjaunot zināšanas, kas nekur nav dokumentētas. No projektu vadības viedokļa saprātīgs minimums ir novērtēt, vai atteice vai izmaiņas IT daļā var apturēt iekārtas vai līnijas operatīvo funkciju. Ja atbilde ir apstiprinoša, arhitektūra ir jākoriģē neatkarīgi no tā, ka “pagaidām tas darbojas”.

Tipisks piemērs parādās, pieslēdzot jaunas iekārtas esošajai uzņēmuma infrastruktūrai. Piegādātājs iekārtu iedarbina ātri, jo nepieciešama pieņemšana un ražošanas sākšana, tāpēc saziņu ar uzņēmuma sistēmām nodrošina ar papildu datoru, skriptu failu eksportam vai manuāli labotu signālu karti. Pēc gada tiek pievienota nākamā iekārta, pēc diviem gadiem mainās virsvadības sistēma, bet pēc trim izrādās, ka neviens vairs nespēj nepārprotami aprakstīt, kuri ziņojumi ir kritiski procesam, kuri kalpo tikai atskaitēm un kuri ir svarīgi diagnostikai vai partiju izsekojamībai. Šajā brīdī tēma daļēji pāriet arī uz mašīnu lietošanas instrukciju izstrādi, jo, ja operatoram, ekspluatācijas uzturēšanas personālam vai servisam nav dokumentētu rīcības noteikumu sakaru zuduma, manuāla apiešanas režīma vai parametru atjaunošanas gadījumā pēc komponenta nomaiņas, problēma vairs nav tikai IT jautājums. Tā kļūst par drošas ekspluatācijas organizācijas un turpmākās atbildības elementu par lietošanas veidu un veiktajām izmaiņām.

Tikai šajā posmā kļūst redzams, kāpēc jautājums atgriežas arī pie atbilstības novērtēšanas, tehniskās dokumentācijas un izmaiņu budžetēšanas. Ja integrācija ietekmē iekārtas funkcijas, bloķējumu loģiku, stāvokļu apstiprināšanas veidu vai lietotājam sniegto informāciju, var būt nepieciešama atkārtota riska analīze un pārbaude, vai dokumentācija joprojām atbilst faktiskajam risinājumam. Šī novērtējuma apjoms ir atkarīgs no izmaiņu rakstura, tāpēc to nevar godprātīgi izšķirt ar vienu universālu teikumu, taču tieši tāpēc pagaidu risinājumi ir tik dārgi: tie apgrūtina noteikt, kas patiesībā ir mainīts un kādas ir juridiskās un ekspluatācijas sekas. Lēmumu pieņēmēju komandai praktisks kritērijs ir šāds: ja integrācijas izmaiņas nav iespējams aprakstīt konfigurācijas dokumentācijā, testēšanas procedūrā un ekspluatācijas noteikumos, neatsaucoties uz neformālām zināšanām, tad projekts jau ir nonācis zonā, kur pieaug ne tikai tehniskās izmaksas, bet arī investora, projekta vadītāja un personu, kas risinājumu pielaiž darbam, atbildība.

Kā šai tēmai pieiet praksē

Praksē jautājums nav par to, vai IT un OT integrēt ātrāk, bet gan par to, kur novilkt robežu starp pagaidu risinājumu un arhitektūras parādu, kas pēc dažiem gadiem bloķēs rūpnīcas attīstību. Pagaidu savienojumi parasti rodas palaišanas spiediena apstākļos: vajag ātri iegūt datus no iekārtas, pievienot jaunu līniju, sasaistīt kvalitātes sistēmu ar ražošanas reģistriem vai nodrošināt attālinātu servisa piekļuvi. Problēma sākas brīdī, kad risinājums, kas ieviests “uz brīdi”, kļūst par pamatu nākamajiem projektēšanas lēmumiem. Komanda zaudē skaidru atbildības sadalījumu, un katra paplašināšana prasa atjaunot zināšanas no sarakstes, lokālajiem iestatījumiem un operatoru prakses. Tā vairs nav neliela tehniska neērtība, bet faktors, kas ietekmē grafiku, izmaiņu izmaksas un spēju pierādīt, kurš un uz kāda pamata konkrēto risinājumu ir pielaidis darbam.

Tāpēc pareiza pieeja sākas ar arhitektūras lēmumu, nevis ar rīka izvēli. Vadītājam vai atbildīgajam par konkrēto jomu būtu jāprasa, lai katrai jaunai integrācijai būtu noteikts operatīvais mērķis, atbildīgais abās IT/OT robežas pusēs un uzturēšanas nosacījumi pēc palaišanas. Ja nav zināms, kurš atbild par datu avotu, kurš apstiprina konfigurācijas izmaiņas, kurš testē ietekmi uz procesu un kurš lemj par avārijas režīmu, tad projekts faktiski pārnes risku uz ekspluatācijas posmu. Tieši šeit dabiski sākas projekta vadītāja loma IT/OT lēmumos: nevis kā termiņu koordinatoram, bet kā personai, kas panāk atbildību sadalījuma skaidru noteikšanu, pirms pagaidu risinājums tiek ierakstīts budžetā un grafikā kā “ātrs apiešanas variants”. Praktisks vērtēšanas kritērijs ir vienkāršs: ja plānoto integrāciju nevar uzturēt pēc piegādātāja maiņas, kontroliera nomaiņas vai līnijas paplašināšanas bez sākotnējā apiešanas risinājuma autora iesaistes, tad tas nav pagaidu risinājums, bet gan nākotnes projekta izmaksas.

Labs pārbaudījums ir situācija, kad esoša līnija tiek paplašināta ar papildu darba staciju, kurai jānodod dati augstāka līmeņa sistēmai un vienlaikus jāreaģē uz stāvokļiem jau strādājošajā daļā. Ja komanda izvēlas signālus pieslēgt tieši un datu neformālu translāciju veikt “jo tā būs ātrāk”, sākumā viss var darboties pareizi. Taču ar laiku parādās blakusefekti: kļūst grūtāk noteikt, vai kļūda izriet no iekārtas loģikas, komunikācijas slāņa vai atskaišu lietotnes; pieņemšanas testi aptver tikai standarta scenārijus; viena elementa modernizācija vienlaikus prasa labojumus vairākās vietās. Tad atklājas arī kļūdainu projekta lēmumu slēptās izmaksas: papildu dīkstāves diagnostikai, dārga integratora klātbūtne pie katrām izmaiņām, strīdi par garantijas apjomu un kavējumi nākamajos investīciju posmos. Tāpēc ir vērts mērīt ne tikai palaišanas laiku, bet arī to integrācijas punktu skaitu, kuriem nepieciešama manuāla konfigurēšana, laiku, kas vajadzīgs incidenta analīzei pēc izmaiņām, un to izmaiņu skaitu, kuras jātestē caurviju veidā, nevis lokāli.

Tikai uz šī fona ir jēga atsaukties uz drošības un atbilstības prasībām. Ja integrācija ietekmē iekārtas darba stāvokļus, bloķējumus, signālu apstiprinājumus, palaišanas vai apturēšanas secību, tā vairs nav neitrāls IT papildinājums. Atkarībā no izmaiņu rakstura tas var radīt nepieciešamību pēc atkārtotas riska un līnijas drošības analīzes, tehniskās dokumentācijas atjaunināšanas un pārbaudes, vai ekspluatācijas veids joprojām atbilst pieņēmumiem, kas noteikti konkrētajai iekārtai vai līnijai. Īpaši skaidri tas redzams tur, kur integrācijas slānis sāk netieši ietekmēt drošas piekļuves nosacījumus, enerģijas atslēgšanu vai negaidītas palaišanas novēršanu. Šādā gadījumā arhitektūras lēmums no ieviešanas ērtības jautājuma pāriet juridiskās un tehniskās atbildības jomā. Ja komanda nespēj pierādīt, kuri savienojumi ir tikai informatīvi un kuri ietekmē iekārtas uzvedību, tas ir signāls, ka jautājums jāizceļ no “sistēmu integrācijas” līmeņa un jāuztver kā izmaiņas, kas ir būtiskas drošībai, budžetam un to personu atbildībai, kuras apstiprina risinājumu.

Kam pievērst uzmanību ieviešanas laikā

Visvairāk problēmu nerodas no pašas IT/OT integrācijas, bet gan no tā, ka projektā to uztver kā ātru līdzekli jaunas funkcijas palaišanai, nevis kā noturīgu rūpnīcas IT/OT arhitektūras elementu. Tieši tad pagaidu savienojumi atriebjas pēc dažiem gadiem: līnijas paplašināšanas laikā, nomainot kontrolierus, mainot augstāka līmeņa sistēmas piegādātāju vai drošības auditā izrādās, ka neviens nespēj nepārprotami norādīt interfeisa īpašnieku, tā darbības principus un atteices sekas. Projektam tas nozīmē ne tikai tehniskā parāda izmaksas, bet arī organizatoriskas izmaksas: vairāk saskaņojumu, ilgākus caurviju testus, sarežģītāku pieņemšanu un lielāku risku, ka kavējums parādīsies tikai beigās, kad grafiks jau ir vismazāk elastīgs. Šajā brīdī tēma dabiski pāriet kļūdainu projekta lēmumu slēpto izmaksu jomā, jo problēmas avots nav viena izpildes kļūda, bet gan lēmums atlikt sakārtotu arhitektūru uz vēlāku laiku.

Tāpēc ieviešanas laikā risinājumu ir vērts vērtēt nevis pēc tā, vai tas “darbojas tagad”, bet gan pēc tā, vai to var uzturēt un droši mainīt paredzamā veidā. Praktiskais kritērijs ir vienkāršs: ja plānotajai integrācijai nav aprakstīts atbildības sadalījums, atteices režīms, versiju pārvaldības principi un testēšanas procedūra pēc izmaiņām, tad tā vēl nav gatava ieviešanai ražošanā, pat ja darbojas testēšanas stendā. Tas ir īpaši svarīgi tur, kur vienam un tam pašam interfeisam jāapkalpo gan pašreizējais investīciju posms, gan turpmākā paplašināšana. Rūpnīcas attīstība gandrīz vienmēr palielina atkarību skaitu starp sistēmām, un pagaidu risinājumi darbojas vissliktāk tieši tad, kad pieaug izņēmumu, apiešanas variantu un lokālu vienošanos skaits. No projekta vadītāja skatpunkta tas nozīmē nepieciešamību jau agrīni noteikt, kurš apstiprina robežlēmumus starp automatizāciju, ekspluatācijas uzturēšanu, informācijas tehnoloģijām un atbilstību, jo bez tā atbildība izplūst tieši tur, kur vēlāk rodas vislielākie strīdi par izmaksām un termiņiem.

Tipisks praktisks piemērs ir datu apmaiņas pievienošana starp līniju un atskaišu sistēmu, izmantojot starpskriptu vai nedokumentētu servisu, kas palaists serverī, kurš “jau atrodas uzņēmumā”. Nodošanas ekspluatācijā posmā šāds risinājums šķiet racionāls: nav jāveic izmaiņas no iekārtas piegādātāja puses, ieviešana notiek ātrāk un biznesa rezultātu var parādīt īsā laikā. Problēma parādās vēlāk. Pēc operētājsistēmas atjaunināšanas, adresācijas maiņas, dublējuma atjaunošanas vai iekārtas nomaiņas nevienam vairs nav pārliecības, vai signālu kartēšanas loģika joprojām atbilst procesa realitātei. Ja šis mehānisms piedalās apstiprinājumos, bloķēšanās funkcijās, uzdevumu rindas veidošanā vai palaišanas nosacījumos, kļūme vairs nav tikai IT incidents, bet sāk ietekmēt līnijas pieejamību, ražošanas kvalitāti un atbildību par risinājuma nodošanu ekspluatācijā. Tad tēma dabiski pāriet uz riska analīzi un līnijas drošību rūpnīcas attīstības projektā, jo jānovērtē ne tikai atteices varbūtība, bet arī nepareizas informācijas, nepareizas secības un operatora nepareizas reakcijas sekas.

Tikai šādā kontekstā ir jēga atsaukties uz formālajām prasībām. Ja integrācijas slānis paliek tikai informatīvs un to var tehniski pierādīt, pienākumu apjoms būs citāds nekā situācijā, kad tas ietekmē iekārtas vai līnijas darbību. Taču, ja tas iedarbojas uz darba loģiku, palaišanas, apturēšanas, apstiprināšanas vai apiešanas nosacījumiem, ieviešana jāuztver kā tehniski un potenciāli arī drošības ziņā nozīmīgas izmaiņas, nevis kā parasta sistēmas paplašināšana. Tas var nozīmēt nepieciešamību atkārtoti pārbaudīt riska novērtējuma pieņēmumus, tehnisko dokumentāciju un konkrētajam risinājumam pieņemtos atbilstības novērtēšanas nosacījumus. Praksē drošs jautājums nav “vai to var pieslēgt”, bet gan “vai pēc ieviešanas mēs spēsim pierādīt, ko šī saskarne dara, kurš par to atbild un kā mēs kontrolējam izmaiņas”. Ja atbilde nav viennozīmīga, atliktā arhitektūras lēmuma izmaksas parasti atgriezīsies nākamās modernizācijas, sertifikācijas vai incidenta laikā, un tad tā jau būs ne tikai tehniska, bet arī vadības problēma.