Vana tööstusrakenduse refaktoreerimine – millal on see mõistlik ja kuidas teha seda nii, et tootmine ei satuks ohtu?

Miks see teema on täna oluline

Vana tööstusrakenduse refaktoreerimine ei ole enam koodi esteetika ega hoolduse mugavuse küsimus. Täna on see otsus, mis puudutab tootmise järjepidevust, kulude prognoositavust ja süsteemi omaniku vastutuse ulatust. Paljudes ettevõtetes on juhtimisrakendusi, operaatoritööriistu ja kommunikatsioonikihte arendatud aastaid ilma ühtse arhitektuurita, sageli seadmete, teekide ja integratsioonimehhanismide ümber, mille tugi on piiratud või lõppenud. Selline olukord võib mõnda aega olla talutav, kuid ainult seni, kuni iga järgmine muudatus hakkab maksma rohkem kui funktsionaalsus, mida see peaks andma. Siis ei ole küsimus enam selles, kas vana rakendust üldse puutuda, vaid selles, kas organisatsioon kontrollib selle käitumist tootmistingimustes endiselt.

Teema olulisus tuleneb sellest, et tööstussüsteemides muutub tehniline võlg väga kiiresti operatiivseks võlaks. Kui rakendust on raske taastoota, see sõltub üksikutest inimestest, puuduvad usaldusväärsed regressioonitestid või selle loogika segab tootmisfunktsioonid ohutuse ja diagnostikaga seotud funktsioonidega, siis on iga intsident kallim kui samalaadne probleem kontorisüsteemis. Tagajärg ei ole ainult seisak. Lisanduvad käiduhoolduse tööjõukulu, ajasurve all kasutatavate ekslike ajutiste lahenduste risk, probleem hoolsuskohustuse tõendamisel pärast muudatust ning raskus eristada, mis oli varasem rike ja mis projektimeeskonna sekkumise tagajärg. Juhi ja tooteomaniku jaoks on praktiline kriteerium lihtne: kui järgmiste väikeste muudatuste juurutamise aeg ja ebakindlus kasvavad kiiremini kui nende äriline väärtus, on rakendus jõudnud seisu, kus refaktoreerimise otsus tuleb teha teadlikult, mitte lükata seda edasi kuni esimese kriitilise rikkega.

Kõige rohkem vigu tekib siis, kui refaktoreerimist käsitletakse moderniseerimisena „ilma mõjuta protsessile”, kuigi tegelikult muudab see süsteemi otsustusloogikat. Praktikas piisab näiliselt väikesest sekkumisest: kommunikatsioonikomponendi väljavahetamine, ülesannete ajastuse ümberkujundamine, andurite andmete puhverdamise loogika muutmine või taaskäivituse järel käivitusjärjestuse korrastamine. Paberil on need tehnilised korrastustööd. Tootmises võivad need aga muuta signaali andmise hetke, blokeeringute vabastamise järjekorda, reaktsiooni side katkemisele või rakenduse käitumist pärast toite kadumist. Just siin läheb refaktoreerimise teema üle muudatuse praktiliseks riskihindamiseks: küsimus ei ole selles, kas kood on „parem”, vaid selles, kas masin, liin või töökoht käitub pärast muudatust endiselt ettearvatavalt normaal-, häire- ja taaskäivitustingimustes.

Hea proovikivi otsuse küpsuse hindamiseks on kontrollida, kas meeskond suudab tõmmata piiri rakenduse sisemise struktuuri muutmise ja protsessi või ohutuse seisukohalt olulise funktsiooni muutmise vahele. Kui seda piiri ei ole võimalik kirjeldada signaalide, olekute ja üleminekutingimuste tasandil, on projekt riskantne sõltumata teostaja kvaliteedist. Tööstuskeskkonnas on eriti tundlikud olukorrad, kus rakendus osaleb käivitamise, seiskamise, vigade lähtestamise, alarmide kinnitamise järjestuses või töötab koos energia eraldamise süsteemide ja blokeeringutega. Sel hetkel ei teki enam ainult küsimus tarkvara arhitektuuri kohta, vaid ka kaitse kohta ootamatu käivitumise eest ning selle kohta, kas analüüs hõlmab ka elektripaigaldist, juhtimisloogikat ja seadmetevahelisi sõltuvusi. Just siin lakkab näiliselt lokaalne refaktoreerimine olemast IT-ülesanne ja muutub tehniliseks muudatuseks, mis nõuab täielikku otsustusdistsipliini.

Viide normatiivsetele nõuetele muutub siin oluliseks alles selles etapis, sest standardid ei asenda projekteerimisotsust, kuid aitavad selle ulatust korrastada. Kui muudatus võib mõjutada käivitamise, seiskamise, häire järel töö taastamise tingimusi või kaitsemeetmeid, tuleb seda hinnata kui riskimuudatust, mitte kui tavapärast koodihooldust. Kui sekkumine puudutab loogikat, mis töötab koos energia eraldamise, blokeeringute või ohutu juurdepääsu järjestusega, avaneb loomulikult ka nõuete valdkond, mis puudutab kaitset ootamatu käivitumise eest. Vastutuse seisukohalt ei ole seega kõige olulisem mitte ainult „kas refaktoreerida”, vaid kas organisatsioon suudab tõendada, et ta tunneb muudatuse piire, tal on protsessi käitumisel põhinevad vastuvõtukriteeriumid ja ta oskab eristada süsteemi korrastamist muudatusest, mis nõuab täielikku riskihindamist vastavalt ISO 12100-le ning koordineerimist paigaldise projekteerimise ja objektil tehtavate katsetega.

Kus kulu või risk kõige sagedamini kasvab

Vana tööstusrakenduse refaktoreerimisel ei tulene suurim kulukasv enamasti mitte koodist endast. Probleemi allikas on tavaliselt muudatuse vale kvalifitseerimine: meeskond käsitleb seda programmi struktuuri korrastamisena, kuigi tegelikult muutub süsteemi ajakäitumine, toimingute järjekord või olekutevaheliste üleminekute tingimused. Tootmiskeskkonnas on sellisel eksimusel otsene mõju projektile. Ajakava ei vasta enam tegelikule mahule, testid kavandatakse IT-funktsionaalsuse, mitte protsessi kulgemise järgi ning vastutus tulemuse eest hajub hoolduse, automaatika ja tarkvaratarnija vahel. Praktiline kriteerium on siin lihtne: kui pärast muudatust tuleb uuesti kinnitada käivitamise, seiskamise, häirejärgse töö taastamise järjestus või reaktsioon kaitseahelate signaalidele, siis ei ole see organisatsioonilises mõttes enam „ohutu refaktoreerimine”, vaid muudatus, mis võib tekitada tootmisriski ja nõuda teistsugust heakskiidukorda. Kaitse ootamatu käivitumise eest vastavalt ISO 14118-le on sellistes olukordades otseselt asjakohane lähtekoht.

Teine tüüpiline kulude kasvu allikas on projekteerimisotsus, mis tehakse ilma sõltuvustest täielikku pilti omamata. Vanad tööstusrakendused on sageli tihedalt põimunud kontrolleri konfiguratsiooni, täiturseadmete, visualiseerimise, andmearhiveerimise ja operaatori protseduuridega. Dokumentatsioonis paistab see ühe süsteemina, kuid tegelikkuses on tegu kihtidega, mida eri meeskonnad on aastate jooksul arendanud. Refaktoreerimine, mille eesmärk on parandada koodi loetavust või lihtsustada edasist hooldust, võib märkamatult muuta viiteaegade tähendust, blokeeringute tingimusi, taaskäivituse järgseid vaikeväärtusi või sidevea käsitlemise viisi. Tagajärg ei ole ainult tehniline parandus, vaid ka seisakute kulu, täiendavad katsed objektil ja vaidlused selle üle, kas puudus oli olemas juba varem või tekkis muudatuse tulemusena. Seetõttu tasub enne otsust hinnata mitte ainult muudatuse mahtu, vaid ka kokkupuutepunktide arvu ja kriitilisust: kui palju signaale, retsepte, töörežiime ja kasutuses olevaid möödaviike sõltub sellest koodiosast, mida plaanitakse ümber ehitada. Mida rohkem selliseid punkte on, seda vähem on mõistlik teha refaktoreerimist „möödaminnes” mõne muu ülesande käigus. Selles etapis on oluline ka ohtude tuvastamine vastavalt standardile ISO 12100.

Praktikas on eriti kulukad projektid, kus meeskond avastab tegelikud nõuded alles kasutuselevõtu käigus. Tüüpiline näide on järjestikmooduli ümberehitamine, mis kirjelduse järgi „teeb sama asja, ainult puhtamalt”. Pärast juurutamist selgub aga, et eelmine versioon sisaldas dokumenteerimata käitumisi, mis kompenseerisid objekti puudusi: signaali lühiajaline hoidmine, hilineva anduri talumine, alarmi kustutamise eriline järjekord või tingimus, millest sõltub hooldusrežiimi sisenemine. Koodis näis see vea või tehnilise võlana, kuid protsessi jaoks oli see stabiliseeriv element. Kui refaktoreerimine eemaldab sellised mehhanismid nende funktsiooni mõistmata, ilmneb kulu kohe: kasutuselevõtujärgsete sekkumiste arv kasvab, vastuvõtuaeg pikeneb ja loogikat tuleb taastada tehase töö surve all. Seetõttu tuleb refaktoreerimise mõttekust hinnata ka selle järgi, kas olemasoleva süsteemi käitumist on võimalik taastoota. Kui organisatsioonil puudub sündmuste register, usaldusväärne töörežiimide kirjeldus ja tegelikul protsessil põhinevad testistsenaariumid, tuleb esmalt luua hindamiseks vajalik alus ja alles seejärel teha otsus ümberehitamise kohta.

See teema läheb otseselt üle muudatuste praktiliseks riskihindamiseks siis, kui muudatus mõjutab kaitsefunktsioone, ohutu juurdepääsu järjestusi, täiturite liikumise juhtimist või paigaldise käitumist toite kadumisel ja taastumisel. Sellises ulatuses ei piirdu vea maksumus programmeerimisparandustega, sest lisandub ka küsimus vastutusest muudatuse tööks heakskiitmisel. Kui rakendus töötab koos hüdrauliliste, pneumaatiliste süsteemide või selliste lahendustega nagu kahekäejuhtimine, muutub piir refaktoreerimise ja tehnilise muudatuse vahel veelgi kitsamaks ning tuleb kontrollida, ega kaitsemeetmete projekteerimise aluseid ei ole rikutud. Alles siin on põhjendatud tugineda korrastatud riskihindamise meetoditele, sealhulgas praktikas ISO/TR 14121-2 alusel kasutatavale lähenemisele, ning hüdrosüsteemide puhul ka projekteerimisnõuetele, mida korrastab EVS EN ISO 4413. Asi ei ole formalismis formalismi pärast, vaid lihtsas otsustusreeglis: kui muudatus võib mõjutada protsessi või käitamise ohutust, tuleb selle kulu arvestada koos valideerimise, objektil tehtavate testide ja vastutusrežiimiga, mitte ainult programmeerija tööajaga. Sellisel juhul on asjakohane ka muudatuse riskihindamine vastavalt ISO 12100-le.

Kuidas teemale praktikas läheneda

Praktikas hinnatakse vana tööstusrakenduse refaktoreerimise mõttekust mitte muudatuse tehnoloogilise atraktiivsuse järgi, vaid selle järgi, kas samaaegselt on võimalik vähendada käitusriskide taset ja hoida juurutamine kontrolli all. Juhi ja tooteomaniku jaoks tähendab see lihtsat vaatenurga muutust: küsimus ei ole selles, kas koodi „tasub korrastada”, vaid selles, kas rakenduse praegune seis raskendab tegelikult hooldust, testimist, rikete kõrvaldamist või järgmiste muudatuste nõuetekohast sisseviimist. Kui vastus on jaatav, on refaktoreerimine põhjendatud, kuid ainult sellises ulatuses, mida saab tootmise tööst eraldada ja hinnata mõõdetavate mõjude alusel. Hea otsustuskriteerium on siin kahe kulu võrdlus: rakenduse praegusesse seisu jätmise kulu, mis hõlmab seisakuid, diagnoosimise aega, sõltuvust üksikutest inimestest ja vale muudatuse riski, ning kontrollitud ümberehituse kulu koos testide, valideerimise ja kasutuselevõtuga. Ilma sellise võrdluseta väljub projekt tavaliselt kontrolli alt, sest meeskond rahastab koodi korrastamist funktsionaalsuse eelarvest, samal ajal kui vastutus objektil tekkivate tagajärgede eest jääb määratlemata.

Seetõttu ei peaks esimene otsus olema „kirjutame ümber” või „jätame nii”, vaid muudatuse piiri määratlemine. Küpses lähenemises eristatakse osa, mis puudutab üksnes tarkvara struktuuri, osast, mis mõjutab protsessi loogikat, käivitus- ja seiskamisjärjestusi, töörežiime, sidet ajamitega ning süsteemi käitumist pärast toitehäiret. Sellel eristusel on otsene mõju nii kuludele kui ka korraldusele. Ainult koodi korrastava kihiga piirduvat muudatust saab teha lühema tsükliga ja väiksema hoolduspersonali kaasamisega. Muudatus, mis mõjutab masina või liini käitumist, nõuab juba objektil tehtavate testide plaani, hooldusakent, tagasipööramise protseduuri ning üheselt määratud vastutajat, kes kiidab heaks kasutusse lubamise. Seejuures tasub mõõta mitte ainult programmeerimistööde kestust, vaid ka süsteemi taastamise aega pärast ebaõnnestunud katset, regressioonitestidega kaetud alade arvu ja aega, mis kulub kõrvalekalde diagnoosimiseks pärast käivitamist. Need on näitajad, mis näitavad, kas refaktoreerimine tegelikult vähendab projekti riski, mitte ei paranda üksnes arendusmeeskonna töömugavust.

Praktiline näide on vanemate juhtimisrakenduste puhul tüüpiline: kood sisaldab korduvalt dubleeritud lõike, mis vastutavad liikumisblokeeringute, alarmide käsitlemise ning käsitsi- ja automaatrežiimi vaheliste üleminekute eest. Meeskond soovib need ühtlustada, sest praegune ülesehitus raskendab edasiarendust ja tekitab töökohtade vahel erinevusi. Selline otsus on mõistlik alles pärast kontrolli, kas ühtlustamine ei muuda tingimusi, mille korral täiturseade saab liikumisloa, ning kas kontrolleri taaskäivituse järel ei teki teistsugust oleku taastamise järjestust. Kui rakendus juhib ka ventiile, ajameid või salvestatud energiaga süsteeme, võib isegi näiliselt „sisemine” refaktoreerimine liikuda muudatusega seotud riskihindamise valdkonda ja nõuda kaitse ootamatu käivitumise eest vastavalt standardile ISO 14118 analüüsi. Sellisel juhul on mõistlik praktika teha refaktoreerimine etappide kaupa: esmalt taastada käitumine testkeskkonnas, seejärel eraldada moodulid ilma loogikat muutmata ning seejärel kontrollida lahendust objektil koos ettevalmistatud tagasipöördumisstsenaariumiga. See piirab käitusvastutust ja võimaldab juurutamise katkestada enne, kui probleem mõjutab tootmist.

Alles selles etapis on vaja normatiivset viidet, sest standardid ei asenda tehnilist otsust, kuid aitavad korrastada hetke, mil muudatus lakkab olemast üksnes programmeerimistöö. Kui refaktoreerimine mõjutab kaitsemeetmeid, ohutu juurdepääsu tingimusi, energia eraldamist või süsteemide käitumist pärast seiskamist ja taaskäivitamist, siis kuulub see loomulikult praktilise muudatuse riskihindamise alla, mida tehakse korrastatud viisil ka ISO/TR 14121-2-st tuntud lähenemist kasutades. Kui tekib ootamatu käivitumise oht, tuleb kontrollida mitte ainult koodi ennast, vaid ka energia eraldamise ja taastamise loogikat, mis viib otseselt ISO 14118-ga seostatavate teemadeni. Kui rakendus on seotud hüdraulika või pneumaatikaga, ei tohi hindamine jätta kõrvale nende süsteemide projekteerimise lähtealuseid, sest vale juhtimisjärjestus võib rikkuda nende ohutut toimimist sõltumata programmi enda korrektsusest; siis on põhjendatud tugineda ka hüdrosüsteemide projekteerimist korrastavatele nõuetele. Praktikas tähendab see üht: refaktoreerimise ulatuse ei määra lahenduse elegants, vaid vastutuse piir selle eest, et paigaldis käituks pärast muudatust ohutult.

Millele juurutamisel tähelepanu pöörata

Vana tööstusrakenduse refaktoreerimise juurutamine on hetk, mil isegi õige arhitektuurne otsus võib muutuda käitusprobleemiks. Kogu ettevõtmise mõte lõpeb seal, kus muudatus parandab koodi, kuid halvendab paigaldise töö prognoositavust või laiendab meeskonna vastutust kaugemale sellest, mis on tuvastatud ja heaks kiidetud. Kõige sagedasem viga on käsitleda juurutamist tavalise uue versiooni avaldamisena. Tootmiskeskkonnas ei loe ainult see, kas rakendus töötab, vaid ka see, kas pärast muudatust käituvad kõik üleminekuseisundid identselt: käivitumine pärast toite kadumist, side taaskäivitamine, retseptide taastamine, alarmide, blokeeringute ja käsirežiimide käsitlemine. Praktiline kriteerium on lihtne: kui meeskond ei suuda üheselt kirjeldada, milline käitumine peab pärast juurutamist jääma muutumatuks, siis tähendab see, et ohutuks kasutuselevõtuks ei ole veel tingimusi loodud.

Rakendamise üle otsustamise etapis tuleb selgelt eristada tehniliselt tagasipööratavat muudatust sellisest muudatusest, mis pärast käivitamist loob uue lähteolukorra ja muudab tagasimineku keerulisemaks. Sellel on otsene mõju nii kulule kui ka ajakavale. Refaktoreerimine, mis nõuab samaaegselt kontrollerite, visualiseerimise, andmeserveri ja ülemiste süsteemide liideste uuendamist, ei ole enam üksik arendusülesanne; sellest saab koordineeritud tootmismuudatus, millel on mitu võimalikku tõrkepunkti. Seetõttu tasub enne juurutamist võtta kasutusele vastuvõtukriteerium, mis ei põhine deklaratsioonil „testid on läbitud”, vaid võimel muudatus kontrollitult tagasi võtta protsessi jaoks vastuvõetava aja jooksul. Kui usaldusväärne tagasipöördumise protseduur puudub, siis puudub ka alus väita, et risk on kontrolli all. Praktikas on mõistlik mõõta mitte abstraktset „juurutuse kvaliteeti”, vaid selliseid näitajaid nagu eelmise versiooni taastamise aeg, muudatusest sõltuvate liideste arv ning nende funktsioonide arv, mille korrektsust saab paigaldisel kinnitada tootmisse sekkumata.

Hea näide on olukord, kus refaktoreerimine korrastab erindite käsitlemist ja veateateid, kuid muudab samal ajal süsteemi taaskäivituse järgset initsialiseerimisjärjekorda. Teststendis näib kõik korrektne, sest seadmed on kohe kättesaadavad ja protsess ei tööta koormuse all. Tehases võib sama kood siiski käivitada järjestuse teisel hetkel kui varem, mis viib sünkroonist välja ajamitega, valmisolekusignaalide vale tõlgendamiseni või materjalipartii seiskumiseni vaheolekus. Selline juhtum ei pruugi tähendada tehnilist riket kitsas mõttes, kuid tekitab seisaku, praagi, korduskäivituse ja töö jätkamise otsusega seotud lisavastutuse kulu. Just siin liigub refaktoreerimise teema muudatuste praktilise riskihindamise juurde: mitte siis, kui muudatus on suur, vaid siis, kui selle mõju ei ole enam võimalik piirata ainult tarkvarakihiga.

Vastutuse piir muutub veelgi selgemaks seal, kus rakendus mõjutab kaitsefunktsioone, liikumise lubamise loogikat, koormuse mahavõtmise järjestusi, seiskamist ja taaskäivitamist pärast häiret. Sellisel juhul ei piisa enam koodiversioonide võrdlemisest ega integraatori tehtud funktsionaalsest testist. Vaja on korrastatud hinnangut sellele, kas muudatus muudab riskitaset ja kas see ei riku masina või paigaldise ohutu töö eeldusi. See on loomulik hetk siseneda riskihindamise valdkonda vastavalt ISO 12100-le ning muudatuste riskihindamisel kasutatavatesse praktikatesse, ja keerukamate juhtumite korral on abiks ka metoodiline lähenemine, mis on tuntud standardist ISO/TR 14121-2. Kui rakendus juhib hüdraulilisi või pneumaatilisi süsteeme, tuleb lisaks kontrollida, kas uus loogika ei muuda energia ohutu juhtimise tingimusi ega liikumiste järjekorda; siis on olulised ka nende süsteemide jaoks kehtivad projekteerimisnõuded, mitte ainult programmi enda korrektsus. Projektimeeskonna jaoks tähendab see üht: juurutust saab pidada ettevalmistatuks alles siis, kui tehnilise, käidulise ja vastavusega seotud vastutuse ulatus on määratletud enne käivitamist, mitte alles pärast esimest intsidenti.