Refaktoriranje stare industrijske aplikacije – kada ima smisla i kako ga provesti bez rizika za proizvodnju?

Zašto je ova tema danas važna

Refaktoriranje stare industrijske aplikacije odavno više nije pitanje estetike koda ili praktičnosti održavanja. Danas je to odluka koja utječe na kontinuitet proizvodnje, predvidljivost troškova i opseg odgovornosti vlasnika sustava. U mnogim pogonima upravljačke aplikacije, operatorski alati i komunikacijski slojevi razvijali su se godinama bez jedinstvene, usklađene arhitekture, često oko uređaja, biblioteka i integracijskih mehanizama čija je podrška ograničena ili je prestala. Takvo stanje neko vrijeme može biti prihvatljivo, ali samo do trenutka kada svaka sljedeća promjena počne koštati više od same funkcionalnosti koju treba isporučiti. Tada pitanje više nije treba li dirati staru aplikaciju, nego ima li organizacija još uvijek kontrolu nad njezinim ponašanjem u proizvodnim uvjetima.

Važnost ove teme proizlazi iz toga što se u industrijskim sustavima tehnološki dug vrlo brzo pretvara u operativni dug. Ako je aplikaciju teško ponovno uspostaviti, ako ovisi o pojedincima, nema pouzdane regresijske testove ili joj logika miješa proizvodne funkcije s funkcijama povezanima sa sigurnošću i dijagnostikom, tada će svaki incident biti skuplji nego sličan problem u uredskom sustavu. Posljedica nije samo zastoj. Tu su i trošak rada održavanja, rizik pogrešnih zaobilaznih rješenja primijenjenih pod pritiskom vremena, problem dokazivanja dužne pažnje nakon promjene te poteškoća u razdvajanju onoga što je bio raniji kvar od onoga što je posljedica intervencije projektnog tima. Za menadžera i vlasnika proizvoda praktični kriterij je jednostavan: ako vrijeme i neizvjesnost uvođenja sljedećih manjih promjena rastu brže od njihove poslovne vrijednosti, aplikacija je ušla u stanje u kojem odluku o refaktoriranju treba donijeti svjesno, a ne odgađati do prvog kritičnog kvara.

Najviše pogrešaka nastaje kada se refaktoriranje tretira kao modernizacija „bez utjecaja na proces”, iako u stvarnosti mijenja način na koji sustav donosi odluke. U praksi je dovoljna i naizgled mala intervencija: zamjena komunikacijske komponente, preuređenje rasporeda zadataka, promjena logike međuspremanja podataka sa senzora ili sređivanje sekvence pokretanja nakon restarta. Na papiru su to tehnička uređenja. U pogonu, međutim, mogu promijeniti trenutak slanja signala, redoslijed otpuštanja blokada, reakciju nakon gubitka veze ili ponašanje aplikacije nakon nestanka napajanja. Upravo tu tema refaktoriranja prelazi u praktičnu ocjenu rizika promjene: nije riječ o tome je li kod „bolji”, nego ponašaju li se stroj, linija ili radna stanica nakon promjene i dalje predvidljivo u normalnim stanjima, pri poremećajima i nakon ponovnog pokretanja.

Dobar test zrelosti odluke jest provjera može li tim jasno odrediti granicu između promjene unutarnje strukture aplikacije i promjene funkcije važne za proces ili sigurnost. Ako se ta granica ne može opisati na razini signala, stanja i uvjeta prijelaza, projekt je rizičan bez obzira na kvalitetu izvođača. U industrijskom okruženju posebno su osjetljive situacije u kojima aplikacija sudjeluje u sekvenci pokretanja, zaustavljanja, resetiranja grešaka, potvrđivanja alarma ili surađuje sa sustavima za isključenje energije i blokadama. U tom se trenutku više ne postavlja samo pitanje arhitekture softvera, nego i zaštite od neočekivanog pokretanja te obuhvaća li analiza i električnu instalaciju, upravljačku logiku i ovisnosti među uređajima. Upravo je to mjesto na kojem naizgled lokalno refaktoriranje prestaje biti informatički zadatak i postaje tehnička promjena koja zahtijeva puni režim odlučivanja.

Pozivanje na normativne zahtjeve ovdje postaje važno tek u toj fazi, jer norme ne mogu zamijeniti projektnu odluku, ali mogu urediti njezin opseg. Ako promjena može utjecati na uvjete pokretanja, zaustavljanja, ponovne uspostave rada nakon poremećaja ili na zaštitne mjere, treba je ocjenjivati kao promjenu rizika, a ne kao obično održavanje koda. Ako zahvat dotiče logiku koja surađuje s isključenjem energije, blokadama ili sekvencom sigurnog pristupa, prirodno se otvara i područje zahtjeva koji se odnose na zaštitu od neočekivanog pokretanja. Iz perspektive odgovornosti zato nije najvažnije samo „treba li refaktorirati”, nego može li organizacija dokazati da poznaje granice promjene, ima kriterije prihvaćanja utemeljene na ponašanju procesa i zna razlikovati uređivanje sustava od izmjene koja zahtijeva potpunu ocjenu rizika te usklađivanje s projektiranjem instalacije i ispitivanjima na objektu.

Gdje najčešće rastu trošak ili rizik

Najveći rast troška pri refaktoriranju stare industrijske aplikacije rijetko proizlazi iz samog koda. Izvor problema obično je pogrešna kvalifikacija promjene: tim je tretira kao sređivanje strukture programa, dok se u stvarnosti mijenja ponašanje sustava u vremenu, redoslijed radnji ili uvjeti prijelaza između stanja. U proizvodnom okruženju takva pogreška ima izravan projektni učinak. Raspored više ne odgovara stvarnom opsegu, testovi se planiraju prema informatičkoj funkcionalnosti, a ne prema tijeku procesa, a odgovornost za rezultat razvodnjava se između održavanja, automatike i dobavljača softvera. Praktični kriterij ovdje je jednostavan: ako nakon promjene treba ponovno potvrditi sekvencu pokretanja, zaustavljanja, nastavka rada nakon poremećaja ili reakciju na signale iz zaštitnih krugova, to više nije „sigurno refaktoriranje” u organizacijskom smislu, nego promjena koja može stvarati rizik za proizvodnju i zahtijevati drukčiji način odobravanja.

Drugo tipično područje rasta troška jest projektna odluka donesena bez potpune slike o međuovisnostima. Stare industrijske aplikacije često su isprepletene s konfiguracijom upravljača, izvršnih uređaja, vizualizacije, arhiviranja podataka i operatorskih procedura. U dokumentaciji to izgleda kao jedan sustav, ali u praksi su to slojevi koje su godinama razvijali različiti timovi. Refaktoriranje koje treba poboljšati čitljivost koda ili olakšati daljnje održavanje može neprimjetno promijeniti značenje kašnjenja, uvjeta blokada, zadanih vrijednosti nakon ponovnog pokretanja ili načina obrade komunikacijske pogreške. Posljedica nije samo tehnički ispravak, nego i trošak zastoja, dodatnih ispitivanja na postrojenju i sporova oko toga je li nedostatak postojao ranije ili je uveden promjenom. Zato prije donošenja odluke vrijedi procijeniti ne samu veličinu izmjene, nego broj i kritičnost dodirnih točaka: koliko signala, recepata, načina rada i operativnih zaobilaznih rješenja ovisi o dijelu koda predviđenom za preinaku. Što je više takvih točaka, to refaktoriranje „usput”, uz neki drugi zadatak, ima manje smisla.

U praksi su osobito skupi projekti u kojima tim stvarne zahtjeve otkriva tek tijekom puštanja u rad. Tipičan primjer je preinaka sekvencijskog modula koji prema opisu „radi isto, samo čišće”. Nakon implementacije, međutim, pokazuje se da je prethodna verzija sadržavala nedokumentirana ponašanja koja su kompenzirala nesavršenosti postrojenja: kratko zadržavanje signala, toleranciju na zakašnjeli senzor, specifičan redoslijed resetiranja alarma ili uvjet o kojem ovisi mogućnost ulaska servisa. U kodu je to izgledalo kao pogreška ili tehnički dug, ali za proces je to bio element stabilizacije. Ako refaktoriranje ukloni takve mehanizme bez prepoznavanja njihove funkcije, trošak se pojavljuje odmah: raste broj intervencija nakon puštanja u rad, produljuje se vrijeme preuzimanja i logiku treba ponovno uspostavljati pod pritiskom rada postrojenja. Zato smisao refaktoriranja treba procjenjivati i prema mogućnosti rekonstrukcije ponašanja postojećeg sustava. Ako organizacija nema zapisnik događaja, vjerodostojne opise načina rada i scenarije ispitivanja utemeljene na stvarnom procesu, najprije treba izgraditi osnovu za procjenu, a tek potom donositi odluku o preinaci.

Ta se tema izravno pretvara u praktičnu procjenu rizika promjena kada izmjena utječe na zaštitne funkcije, sekvence sigurnog pristupa, upravljanje kretanjem izvršnih elemenata ili ponašanje instalacije nakon nestanka i povratka napajanja. U tom opsegu trošak pogreške ne svodi se samo na programske ispravke, jer se pojavljuje i pitanje odgovornosti za puštanje promjene u rad. Ako aplikacija surađuje s hidrauličkim, pneumatskim sustavima ili rješenjima kao što je dvouručno upravljanje, granica između refaktoriranja i tehničke promjene postaje još uža i zahtijeva provjeru jesu li narušene projektne pretpostavke zaštitnih mjera. Tek je ovdje opravdano pozvati se na uređene metode ocjenjivanja rizika prema ISO 12100, uključujući pristup koji se u praksi primjenjuje na temelju ISO/TR 14121-2, a kod hidrauličkih sustava i na projektne zahtjeve uređene normom HRN EN ISO 4413. Ne radi se o formalizmu radi formalizma, nego o jednostavnom pravilu odlučivanja: ako promjena može utjecati na sigurnost procesa ili rukovanja, njezin trošak treba računati zajedno s validacijom, ispitivanjima na postrojenju i režimom odgovornosti, a ne isključivo kroz vrijeme rada programera.

Kako temi pristupiti u praksi

U praksi se opravdanost refaktorizacije stare industrijske aplikacije ne procjenjuje prema tehnološkoj privlačnosti promjene, nego prema tome može li se istodobno smanjiti operativni rizik i zadržati nadzor nad provedbom. Za menadžera i vlasnika proizvoda to znači jednostavnu promjenu perspektive: pitanje nije treba li „srediti” kod, nego otežava li sadašnje stanje aplikacije održavanje, testiranje, otklanjanje kvarova ili uvođenje daljnjih izmjena u skladu sa zahtjevima. Ako je odgovor potvrdan, refaktorizacija ima smisla, ali samo u onom opsegu koji se može odvojiti od rada proizvodnje i obračunati na temelju mjerljivih učinaka. Dobar kriterij za odluku ovdje je usporedba dvaju troškova: troška ostavljanja aplikacije u sadašnjem stanju, koji uključuje zastoje, vrijeme dijagnostike, ovisnost o pojedinim osobama i rizik pogrešne izmjene, te troška kontrolirane pregradnje zajedno s testovima, validacijom i puštanjem u rad. Bez takve usporedbe projekt obično izmakne kontroli, jer tim financira sređivanje koda iz proračuna namijenjenog funkcionalnostima, a odgovornost za posljedice na postrojenju ostaje neodređena.

Zato prva odluka ne bi trebala biti „prepisujemo” ili „ostavljamo”, nego određivanje granice promjene. U zrelom pristupu odvaja se dio koji se odnosi isključivo na strukturu softvera od dijela koji utječe na logiku procesa, sekvence pokretanja, zaustavljanja, režime rada, komunikaciju s pogonima i ponašanje nakon poremećaja napajanja. To razlikovanje ima izravan troškovni i organizacijski učinak. Promjena ograničena na sloj koji uređuje kod može se provoditi u kraćem ciklusu i uz manje uključivanje službi održavanja. Promjena koja zadire u ponašanje stroja ili linije već zahtijeva plan ispitivanja na postrojenju, servisni prozor, postupak povrata na prethodno stanje te jasno određivanje tko odobrava puštanje u pogon. Pritom vrijedi mjeriti ne samo vrijeme izvođenja programerskih radova, nego i vrijeme potrebno za vraćanje sustava nakon neuspjelog pokušaja, broj područja obuhvaćenih regresijskim testovima i vrijeme potrebno za dijagnostiku odstupanja nakon puštanja u rad. To su pokazatelji koji pokazuju smanjuje li refaktorizacija doista rizik projekta, a ne samo poboljšava li komfor rada razvojnog tima.

Praktičan primjer tipičan je za starije upravljačke aplikacije: kod sadrži višestruko duplicirane dijelove odgovorne za blokade gibanja, obradu alarma i prijelaze između ručnog i automatskog načina rada. Tim ih želi ujednačiti jer sadašnji raspored otežava razvoj i uzrokuje razlike među radnim mjestima. Takva odluka ima smisla tek nakon provjere hoće li ujednačavanje promijeniti uvjete pod kojima izvršni element dobiva dopuštenje za kretanje te hoće li se nakon ponovnog pokretanja upravljača pojaviti drukčija sekvenca vraćanja stanja. Ako aplikacija upravlja i ventilima, pogonima ili sustavima s pohranjenom energijom, tada i naizgled „unutarnja” refaktorizacija može prijeći u područje ocjene rizika promjene prema ISO 12100 i zahtijevati analizu zaštite od neočekivanog pokretanja u skladu s ISO 14118. U takvom slučaju razumna praksa sastoji se u tome da se refaktorizacija provodi etapno: najprije se ponašanje reproducira u testnom okruženju, zatim se izdvajaju moduli bez promjene logike, a potom slijedi provjera na postrojenju uz unaprijed pripremljen scenarij povrata. To ograničava operativnu odgovornost i omogućuje prekid provedbe prije nego što se problem odrazi na proizvodnju.

Tek je u toj fazi potrebno normativno uporište, jer norme ne zamjenjuju tehničku odluku, ali uređuju trenutak u kojem promjena prestaje biti isključivo programski rad. Ako refaktorizacija utječe na zaštitne mjere, uvjete sigurnog pristupa, isključenje energije ili ponašanje sustava nakon zaustavljanja i ponovnog pokretanja, tada prirodno ulazi u područje praktične ocjene rizika promjena, koja se provodi na strukturiran način i uz primjenu pristupa poznatog iz ISO/TR 14121-2. Kada se pojavi rizik neočekivanog pokretanja, tada više ne treba provjeriti samo sam kod, nego i logiku isključenja i ponovne uspostave energije, što izravno vodi do pitanja povezanih s ISO 14118. Ako je pak aplikacija povezana s hidraulikom ili pneumatikom, procjena ne smije zanemariti projektne pretpostavke tih sustava, jer pogrešna upravljačka sekvenca može narušiti njihov siguran rad neovisno o ispravnosti samog programa; tada je opravdano posegnuti i za zahtjevima koji uređuju projektiranje hidrauličkih sustava. U praksi to znači jedno: o opsegu refaktorizacije ne odlučuje elegancija rješenja, nego granica odgovornosti za sigurno ponašanje instalacije nakon promjene.

Na što paziti pri provedbi

Provedba refaktorizacije stare industrijske aplikacije trenutak je u kojem se čak i ispravna arhitektonska odluka može pretvoriti u operativni problem. Smisao cijelog zahvata završava ondje gdje promjena poboljšava kod, ali pogoršava predvidljivost rada instalacije ili proširuje odgovornost tima izvan onoga što je prepoznato i odobreno. Najčešća pogreška jest tretiranje provedbe kao obične objave nove verzije. U proizvodnom okruženju nije važno samo radi li aplikacija, nego i ponašaju li se nakon promjene jednako sva prijelazna stanja: pokretanje nakon nestanka napajanja, ponovno uspostavljanje komunikacije, obnova receptura, obrada alarma, blokada i ručnih režima. Praktičan kriterij je jednostavan: ako tim ne može jednoznačno opisati koja ponašanja nakon provedbe moraju ostati nepromijenjena, to znači da još ne postoje uvjeti za sigurno puštanje u rad.

U fazi donošenja odluke o uvođenju promjene treba jasno razlikovati tehnički reverzibilnu promjenu od one koja nakon puštanja u rad stvara novo početno stanje i otežava povratak na prethodno. To izravno utječe na trošak i raspored. Refaktoriranje koje zahtijeva istodobno ažuriranje upravljačkih programa, vizualizacije, podatkovnog poslužitelja i sučelja prema nadređenim sustavima prestaje biti pojedinačni programski zadatak; postaje koordinirana promjena u proizvodnji s više mogućih točaka otkaza. Zato je prije uvođenja korisno prihvatiti kriterij odobrenja koji se ne temelji na izjavi „testovi su prošli”, nego na sposobnosti kontroliranog povlačenja promjene u roku prihvatljivom za proces. Ako ne postoji vjerodostojan postupak povratka, nema ni osnove za tvrdnju da je rizik stavljen pod kontrolu. U praksi je bolje mjeriti ne apstraktnu „kvalitetu uvođenja”, nego pokazatelje kao što su vrijeme vraćanja prethodne verzije, broj sučelja ovisnih o promjeni te broj funkcija čija se ispravnost može potvrditi na instalaciji bez zadiranja u proizvodnju.

Dobar primjer je situacija u kojoj refaktoriranje uređuje obradu iznimki i poruka o pogreškama, ali istodobno mijenja redoslijed inicijalizacije nakon ponovnog pokretanja sustava. Na testnom mjestu sve izgleda ispravno jer su uređaji odmah dostupni, a proces ne radi pod opterećenjem. U pogonu, međutim, isti kod može pokrenuti sekvencu u drukčijem trenutku nego prije, što dovodi do gubitka sinkronizacije s pogonima, pogrešnog tumačenja signala spremnosti ili zaustavljanja serije materijala u međustanju. Takav incident ne mora značiti kvar u tehničkom smislu, ali stvara trošak zastoja, škarta, ponovnog pokretanja i dodatne odgovornosti za odluku o nastavku rada. Upravo se ovdje tema refaktoriranja pretvara u praktičnu ocjenu rizika promjene prema ISO 12100: ne onda kada je promjena velika, nego onda kada se njezine posljedice ne mogu ograničiti samo na programsku razinu.

Granica odgovornosti postaje još jasnija ondje gdje aplikacija utječe na zaštitne funkcije, logiku dopuštenja kretanja, sekvence rasterećenja, zaustavljanje i ponovno pokretanje nakon poremećaja. U takvom slučaju više nije dovoljna usporedba verzija koda niti funkcionalni test koji provodi integrator. Potrebna je sustavna procjena mijenja li promjena razinu rizika i narušava li pretpostavke sigurna rada stroja ili postrojenja. To je prirodan trenutak za ulazak u područje ocjene rizika prema ISO 12100 te praksi koje se primjenjuju pri ocjeni rizika promjena, a u složenijim slučajevima korisnim se pokazuje i metodički pristup poznat iz ISO/TR 14121-2. Ako aplikacija upravlja hidrauličkim ili pneumatskim sustavima, dodatno treba provjeriti mijenja li nova logika uvjete sigurnog upravljanja energijom i redoslijed gibanja; tada su važni i projektni zahtjevi svojstveni tim sustavima, a ne samo ispravnost samog programa. Za projektni tim to znači jedno: može se smatrati da je uvođenje pripremljeno tek onda kada su opseg tehničke, eksploatacijske i usklađenosne odgovornosti definirani prije puštanja u rad, a ne tek nakon prvog incidenta.