Vanhan teollisuussovelluksen refaktorointi – milloin se on järkevää ja miten se tehdään ilman riskiä tuotannolle?

Miksi tämä aihe on nyt tärkeä

Vanhan teollisuussovelluksen refaktorointi ei ole enää koodin siisteyteen tai ylläpidon helppouteen liittyvä kysymys. Nykyisin kyse on tuotannon jatkuvuudesta, kustannusten ennakoitavuudesta ja siitä, missä laajuudessa vastuu kuuluu järjestelmän omistajalle. Monissa laitoksissa ohjaussovelluksia, operaattorityökaluja ja tiedonsiirtokerroksia on kehitetty vuosien ajan ilman yhtenäistä arkkitehtuuria, usein sellaisten laitteiden, kirjastojen ja integraatiomekanismien ympärille, joiden tuki on rajallinen tai jo päättynyt. Tällainen tilanne voi olla jonkin aikaa hyväksyttävä, mutta vain siihen asti, kunnes jokainen seuraava muutos alkaa maksaa enemmän kuin se toiminnallisuus, joka muutoksella on tarkoitus tuottaa. Silloin kysymys ei enää ole siitä, kannattaako vanhaan sovellukseen koskea, vaan siitä, hallitseeko organisaatio edelleen sen toimintaa tuotanto-olosuhteissa.

Aiheen merkitys johtuu siitä, että teollisuusjärjestelmissä tekninen velka muuttuu hyvin nopeasti operatiiviseksi velaksi. Jos sovellusta on vaikea toisintaa, se on yhden tai muutaman henkilön varassa, siitä puuttuvat luotettavat regressiotestit tai sen logiikassa tuotantotoiminnot sekoittuvat turvallisuuteen ja diagnostiikkaan liittyviin toimintoihin, jokainen häiriötilanne tulee kalliimmaksi kuin vastaava ongelma toimistojärjestelmässä. Seurauksena ei ole pelkkä seisokki. Mukaan tulevat kunnossapidon työpanoksen kustannukset, aikapaineessa tehtyjen virheellisten kiertoratkaisujen riski, vaikeus osoittaa asianmukainen huolellisuus muutoksen jälkeen sekä ongelma erottaa, mikä oli aiempi vika ja mikä projektiryhmän tekemän muutoksen seurausta. Johtajalle ja tuoteomistajalle käytännöllinen kriteeri on yksinkertainen: jos seuraavien pienten muutosten toteutusaika ja käyttöönottoon liittyvä epävarmuus kasvavat nopeammin kuin niiden liiketoiminta-arvo, sovellus on tullut tilaan, jossa refaktoroinnista on päätettävä tietoisesti eikä vasta ensimmäisen kriittisen vian jälkeen.

Eniten virheitä syntyy silloin, kun refaktorointia pidetään modernisointina ”ilman vaikutusta prosessiin”, vaikka todellisuudessa se muuttaa tapaa, jolla järjestelmä tekee päätöksiä. Käytännössä jo näennäisesti pieni muutos riittää: tiedonsiirtokomponentin vaihto, tehtäväajastuksen uudelleenjärjestely, anturidatan puskurointilogiikan muuttaminen tai käynnistyssekvenssin selkeyttäminen uudelleenkäynnistyksen jälkeen. Paperilla nämä ovat teknisiä siistimistoimia. Tuotantotilassa ne voivat kuitenkin muuttaa signaalin antohetkeä, lukitusten vapautusjärjestystä, toimintaa yhteyden katketessa tai sovelluksen käyttäytymistä sähkökatkon jälkeen. Juuri tässä refaktorointi muuttuu käytännön muutosriskin arvioinniksi: kyse ei ole siitä, onko koodi ”parempaa”, vaan siitä, käyttäytyvätkö kone, linja tai työasema muutoksen jälkeen edelleen ennakoitavasti normaaleissa tilanteissa, häiriötilanteissa ja uudelleenkäynnistyksen jälkeen.

Hyvä tapa arvioida päätöksen kypsyyttä on tarkistaa, pystyykö tiimi määrittämään rajan sovelluksen sisäisen rakenteen muutoksen ja prosessin tai turvallisuuden kannalta olennaisen toiminnallisen muutoksen välille. Jos tätä rajaa ei pystytä kuvaamaan signaalien, tilojen ja siirtymisehtojen tasolla, hankkeeseen liittyy riski toteuttajan laadusta riippumatta. Teollisuusympäristössä erityisen herkkiä ovat tilanteet, joissa sovellus osallistuu käynnistys-, pysäytys-, vikakuittaus- tai hälytysten kuittaussekvenssiin tai toimii yhdessä energianerotusjärjestelmien ja lukitusten kanssa. Tällöin kyse ei enää ole vain ohjelmistoarkkitehtuurista, vaan myös suojauksesta odottamattomalta käynnistymiseltä sekä siitä, kattaako analyysi myös sähköasennuksen, ohjauslogiikan ja laitteiden väliset riippuvuudet. Tässä vaiheessa näennäisesti paikallinen refaktorointi lakkaa olemasta IT-tehtävä ja muuttuu tekniseksi muutokseksi, joka edellyttää täysimääräistä päätöksentekomenettelyä.

Viittaus standardien vaatimuksiin tulee merkitykselliseksi vasta tässä vaiheessa, koska standardit eivät korvaa suunnittelupäätöstä, vaan jäsentävät sen laajuuden. Jos muutos voi vaikuttaa käynnistys-, pysäytys- tai häiriön jälkeisen toiminnan palauttamisen ehtoihin taikka suojatoimenpiteisiin, sitä on arvioitava riskin muutoksena eikä tavanomaisena koodin ylläpitona. Jos muutos koskee logiikkaa, joka toimii yhdessä energianerotuksen, lukitusten tai turvallisen pääsyn sekvenssin kanssa, avautuu luonnollisesti myös odottamattomalta käynnistymiseltä suojaamista koskevien vaatimusten alue. Vastuun näkökulmasta tärkeintä ei siis ole pelkkä kysymys ”refaktoroidaanko vai ei”, vaan se, pystyykö organisaatio osoittamaan tuntevansa muutoksen rajat, omaavansa prosessin käyttäytymiseen perustuvat hyväksymiskriteerit ja erottamaan järjestelmän siistimisen sellaisesta muutoksesta, joka edellyttää täydellistä riskinarviointia sekä koordinointia asennussuunnittelun ja kohteessa tehtävien testien kanssa.

Missä kustannukset tai riskit kasvavat useimmiten

Vanhan teollisuussovelluksen refaktoroinnissa suurin kustannusten kasvu johtuu harvoin itse koodista. Ongelman taustalla on yleensä muutoksen virheellinen luokittelu: tiimi käsittelee sitä ohjelman rakenteen siistimisenä, vaikka todellisuudessa muuttuvat järjestelmän ajallinen käyttäytyminen, toimintojen järjestys tai tilasiirtymien ehdot. Tuotantoympäristössä tällaisella virheellä on suora vaikutus projektiin. Aikataulu ei enää vastaa todellista laajuutta, testit suunnitellaan IT-toiminnallisuuden eikä prosessin kulun mukaan, ja vastuu lopputuloksesta hämärtyy kunnossapidon, automaation ja ohjelmistotoimittajan välillä. Käytännön kriteeri on tässä yksinkertainen: jos muutoksen jälkeen on tarpeen varmistaa uudelleen käynnistys-, pysäytys- ja häiriön jälkeisen uudelleenkäynnistyksen sekvenssi tai reaktio suojapiirien signaaleihin, kyse ei enää ole organisatorisessa mielessä ”turvallisesta refaktoroinnista”, vaan muutoksesta, joka voi aiheuttaa riskiä tuotannolle ja edellyttää erilaista hyväksyntämenettelyä.

Toinen tyypillinen kustannusten kasvun lähde on suunnittelupäätös, joka tehdään ilman kokonaiskuvaa riippuvuuksista. Vanhat teollisuussovellukset ovat usein kietoutuneet yhteen ohjaimen konfiguraation, toimilaitteiden, visualisoinnin, tiedon arkistoinnin ja operaattorien menettelytapojen kanssa. Dokumentaatiossa tämä näyttää yhdeltä järjestelmältä, mutta käytännössä kyse on kerroksista, joita eri tiimit ovat kehittäneet vuosien ajan. Refaktorointi, jonka tarkoitus on parantaa koodin luettavuutta tai helpottaa myöhempää ylläpitoa, voi huomaamatta muuttaa viiveiden merkitystä, lukitusehtoja, oletusarvoja uudelleenkäynnistyksen jälkeen tai viestintävirheen käsittelytapaa. Seurauksena ei ole pelkkä tekninen korjaus, vaan myös seisokkien, lisätestien kohteessa ja kiistojen kustannus siitä, oliko vika olemassa jo aiemmin vai syntyikö se muutoksen myötä. Siksi ennen päätöstä kannattaa arvioida muutoksen koon sijasta liittymäpisteiden määrä ja kriittisyys: kuinka moni signaali, resepti, käyttötila ja käytännön kiertotapa riippuu siitä koodin osasta, jota ollaan muuttamassa. Mitä enemmän tällaisia pisteitä on, sitä vähemmän järkeä on tehdä refaktorointia ”siinä sivussa” muun tehtävän yhteydessä.

Käytännössä erityisen kalliita ovat projektit, joissa tiimi tunnistaa todelliset vaatimukset vasta käyttöönoton aikana. Tyypillinen esimerkki on sekvenssimoduulin uudistaminen, jonka kuvauksen mukaan ”tekee saman, mutta siistimmin”. Käyttöönoton jälkeen käy kuitenkin ilmi, että aiempi versio sisälsi dokumentoimattomia toimintatapoja, jotka kompensoivat kohteen puutteita: signaalin lyhyen ylläpidon, myöhästyvän anturin sietämisen, hälytyksen kuittauksen tietyn järjestyksen tai ehdon, josta huoltotilan käyttö riippuu. Koodissa tämä näytti virheeltä tai tekniseltä velalta, mutta prosessin kannalta se oli vakauttava elementti. Jos refaktorointi poistaa tällaiset mekanismit ilman, että niiden tehtävä tunnistetaan, kustannus näkyy heti: käyttöönoton jälkeisten toimenpiteiden määrä kasvaa, vastaanottoaika pitenee ja logiikkaa joudutaan rakentamaan uudelleen tuotannon paineessa. Siksi refaktoroinnin mielekkyyttä on arvioitava myös sen perusteella, voidaanko nykyisen järjestelmän käyttäytyminen toistaa. Jos organisaatiolla ei ole tapahtumalokia, luotettavia käyttötilojen kuvauksia ja todelliseen prosessiin perustuvia testiskenaarioita, on ensin rakennettava arvioinnin perusta ja vasta sen jälkeen tehtävä päätös uudistamisesta.

Tämä näkökulma liittyy suoraan muutosten käytännön riskinarviointiin silloin, kun muutos vaikuttaa suojaustoimintoihin, turvallisen pääsyn sekvensseihin, toimilaitteiden liikkeen ohjaukseen tai laitoksen käyttäytymiseen sähkönsyötön katketessa ja palautuessa. Tällaisessa laajuudessa virheen kustannus ei rajoitu ohjelmistokorjauksiin, vaan esiin nousee myös vastuu muutoksen hyväksymisestä käyttöön. Jos sovellus toimii yhdessä hydraulisten tai pneumaattisten järjestelmien kanssa tai ratkaisujen, kuten kahden käden ohjauksen, kanssa, refaktoroinnin ja teknisen muutoksen välinen raja kapenee entisestään ja edellyttää tarkistamista, onko suojaustoimenpiteiden suunnitteluperusteita rikottu. Vasta tässä vaiheessa on perusteltua tukeutua jäsenneltyihin riskinarviointimenetelmiin ISO 12100:n mukaisesti, mukaan lukien käytännössä ISO/TR 14121-2:n pohjalta sovellettava lähestymistapa, ja hydraulijärjestelmien osalta myös suunnitteluvaatimuksiin, joita jäsentää SFS-EN ISO 4413. Kyse ei ole muodollisuuksista muodollisuuksien vuoksi, vaan yksinkertaisesta päätösperiaatteesta: jos muutos voi vaikuttaa prosessin tai käytön turvallisuuteen, sen kustannukset on laskettava yhdessä validoinnin, kohteessa tehtävien testien ja vastuunhallinnan kanssa, ei pelkästään ohjelmoijan työajan perusteella.

Kuinka aihetta kannattaa lähestyä käytännössä

Käytännössä vanhan teollisuussovelluksen refaktoroinnin mielekkyyttä ei arvioida muutoksen teknologisen houkuttelevuuden perusteella, vaan sen mukaan, voidaanko samalla pienentää käytönaikaisia riskejä ja säilyttää käyttöönotto hallinnassa. Managerin ja tuoteomistajan näkökulmasta tämä tarkoittaa yksinkertaista ajattelutavan muutosta: kysymys ei ole siitä, ”kannattaako koodia siistiä”, vaan siitä, vaikeuttaako sovelluksen nykytila tosiasiallisesti ylläpitoa, testausta, vikojen korjaamista tai uusien muutosten toteuttamista vaatimusten mukaisesti. Jos vastaus on kyllä, refaktorointi on perusteltu, mutta vain siinä laajuudessa, joka voidaan erottaa tuotannon toiminnasta ja arvioida mitattavien vaikutusten perusteella. Hyvä päätöskriteeri on tässä kahden kustannuksen vertailu: sovelluksen nykytilaan jättämisen kustannus, johon sisältyvät seisokit, diagnostiikkaan kuluva aika, riippuvuus yksittäisistä henkilöistä ja virheellisen muutoksen riski, sekä hallitun uudistamisen kustannus testauksineen, validointeineen ja käyttöönottoineen. Ilman tällaista vertailua projekti karkaa yleensä hallinnasta, koska tiimi rahoittaa koodin siistimistä toiminnallisuuksille varatusta budjetista, ja vastuu muutoksen vaikutuksista kohteessa jää määrittelemättä.

Siksi ensimmäinen päätös ei saisi olla ”kirjoitamme uudelleen” tai ”jätämme ennalleen”, vaan muutoksen rajan määrittäminen. Kypsässä lähestymistavassa erotetaan toisistaan osa, joka koskee vain ohjelmiston rakennetta, ja osa, joka vaikuttaa prosessilogiikkaan, käynnistys- ja pysäytyssekvensseihin, käyttötiloihin, taajuusmuuttajien tai käyttöjen kommunikointiin sekä toimintaan sähkökatkon jälkeen. Tällä erottelulla on suora vaikutus kustannuksiin ja organisointiin. Muutos, joka rajoittuu koodia jäsentävään kerrokseen, voidaan toteuttaa lyhyemmässä syklissä ja vähäisemmällä kunnossapidon osallistumisella. Muutos, joka vaikuttaa koneen tai linjan käyttäytymiseen, edellyttää jo kohteessa tehtävien testien suunnitelmaa, huoltoikkunaa, palautusmenettelyä sekä yksiselitteistä määrittelyä siitä, kuka hyväksyy käyttöönoton. Samalla kannattaa mitata paitsi ohjelmointityön kestoa myös aikaa, joka tarvitaan järjestelmän palauttamiseen epäonnistuneen yrityksen jälkeen, regressiotestauksen piiriin kuuluvien alueiden määrää ja aikaa, joka kuluu poikkeaman diagnosointiin käyttöönoton jälkeen. Nämä ovat mittareita, jotka osoittavat, vähentääkö refaktorointi todella projektin riskiä eikä ainoastaan paranna kehitystiimin työskentelymukavuutta.

Käytännön esimerkki on tyypillinen vanhemmille ohjaussovelluksille: koodissa on useaan kertaan kopioituja osia, jotka vastaavat liikkeen estoista, hälytysten käsittelystä ja siirtymistä käsiajon ja automaattitilan välillä. Tiimi haluaa yhtenäistää ne, koska nykyinen rakenne vaikeuttaa jatkokehitystä ja aiheuttaa eroja asemien välillä. Tällainen päätös on järkevä vasta sen jälkeen, kun on varmistettu, ettei yhtenäistäminen muuta ehtoja, joilla toimilaite saa liikeluvan, eikä ohjaimen uudelleenkäynnistyksen jälkeen synny erilaista tilan palautussekvenssiä. Jos sovellus ohjaa myös venttiilejä, käyttöjä tai järjestelmiä, joissa on varastoitunutta energiaa, näennäisesti ”sisäinenkin” refaktorointi voi siirtyä muutoksen riskin arvioinnin alueelle ja edellyttää suojausta odottamattomalta käynnistymiseltä (ISO 14118) koskevaa analyysia. Tällaisessa tapauksessa järkevä käytäntö on toteuttaa refaktorointi vaiheittain: ensin käyttäytymisen toistaminen testiympäristössä, sitten moduulien eriyttäminen ilman logiikan muuttamista ja sen jälkeen varmistus kohteessa ennalta valmistellulla palautusskenaariolla. Tämä rajaa operatiivista vastuuta ja mahdollistaa käyttöönoton keskeyttämisen ennen kuin ongelma heijastuu tuotantoon.

Vasta tässä vaiheessa tarvitaan normatiivinen viitekehys, sillä standardit eivät korvaa teknistä päätöstä, mutta ne jäsentävät hetken, jolloin muutos lakkaa olemasta pelkkää ohjelmointityötä. Jos refaktorointi vaikuttaa suojatoimintoihin, turvallisen pääsyn ehtoihin, energian erotukseen tai järjestelmien käyttäytymiseen pysäytyksen ja uudelleenkäynnistyksen jälkeen, se kuuluu luontevasti muutoksen käytännöllisen riskinarvioinnin piiriin, jota tehdään järjestelmällisesti myös ISO/TR 14121-2:sta tunnetun lähestymistavan avulla. Kun mukana on odottamattoman käynnistymisen riski, on tarkastettava itse koodin lisäksi myös energian erotuksen ja palautuksen logiikka, mikä johtaa suoraan ISO 14118:aan liitettyihin kysymyksiin. Jos sovellus taas liittyy hydrauliikkaan tai pneumatiikkaan, arvioinnissa ei voida sivuuttaa näiden järjestelmien suunnitteluperiaatteita, koska virheellinen ohjaussekvenssi voi vaarantaa niiden turvallisen toiminnan riippumatta siitä, onko itse ohjelma oikein; tällöin on perusteltua tukeutua myös hydraulijärjestelmien suunnittelua jäsentäviin vaatimuksiin. Käytännössä tämä tarkoittaa yhtä asiaa: refaktoroinnin laajuuden ratkaisee ei ratkaisun eleganssi vaan se raja, johon asti ulottuu vastuu laitoksen turvallisesta käyttäytymisestä muutoksen jälkeen.

Mitä käyttöönotossa on syytä varoa

Vanhan teollisuussovelluksen refaktoroinnin käyttöönotto on vaihe, jossa oikeakin arkkitehtuuripäätös voi muuttua operatiiviseksi ongelmaksi. Koko hankkeen mielekkyys päättyy siihen, että muutos parantaa koodia mutta heikentää laitoksen toiminnan ennakoitavuutta tai laajentaa tiimin vastuuta pidemmälle kuin mitä on tunnistettu ja hyväksytty. Yleisin virhe on käsitellä käyttöönottoa tavallisena uuden version julkaisuna. Tuotantoympäristössä ratkaisevaa ei ole vain se, toimiiko sovellus, vaan myös se, säilyvätkö kaikki siirtymätilanteet muutoksen jälkeen täsmälleen samanlaisina: käynnistys sähkökatkon jälkeen, tiedonsiirron uudelleenkäynnistys, reseptien palautus sekä hälytysten, estojen ja käsiajon käsittely. Käytännön kriteeri on yksinkertainen: jos tiimi ei pysty yksiselitteisesti kuvaamaan, minkä käyttäytymisten on pysyttävä muuttumattomina käyttöönoton jälkeen, turvalliselle käyttöönotolle ei vielä ole edellytyksiä.

Toteutuspäätöksen vaiheessa on erotettava teknisesti palautettavissa oleva muutos sellaisesta muutoksesta, joka käyttöönoton jälkeen muodostaa uuden lähtötilan ja vaikeuttaa paluuta entiseen. Tällä on suora vaikutus kustannuksiin ja aikatauluun. Refaktorointi, joka edellyttää samanaikaista päivitystä ohjaimiin, visualisointiin, datapalvelimeen ja ylemmän tason järjestelmien rajapintoihin, ei ole enää yksittäinen ohjelmistotehtävä, vaan siitä tulee koordinoitu tuotantomuutos, jossa on useita vikapisteitä. Siksi ennen käyttöönottoa kannattaa ottaa käyttöön hyväksymiskriteeri, joka ei perustu ilmoitukseen ”testit läpäisty”, vaan siihen, voidaanko muutos peruuttaa hallitusti prosessin kannalta hyväksyttävässä ajassa. Jos luotettavaa palautusmenettelyä ei ole, ei myöskään ole perusteita väittää, että riski on hallinnassa. Käytännössä on hyödyllisempää mitata ei abstraktia ”käyttöönoton laatua”, vaan esimerkiksi edellisen version palauttamiseen kuluvaa aikaa, muutoksesta riippuvaisten rajapintojen määrää sekä niiden toimintojen määrää, joiden oikea toiminta voidaan varmistaa asennuksessa puuttumatta tuotantoon.

Hyvä esimerkki on tilanne, jossa refaktorointi selkeyttää poikkeusten ja virheilmoitusten käsittelyä, mutta samalla muuttaa alustuksen järjestystä järjestelmän uudelleenkäynnistyksen jälkeen. Testiasemalla kaikki näyttää oikealta, koska laitteet ovat heti käytettävissä eikä prosessi käy kuormitettuna. Laitoksessa sama koodi voi kuitenkin käynnistää sekvenssin eri hetkellä kuin aiemmin, mikä johtaa synkronoinnin menetykseen käyttöjen kanssa, valmiussignaalien virheelliseen tulkintaan tai materiaalierän pysähtymiseen välitilaan. Tällainen tapaus ei välttämättä tarkoita teknisessä mielessä vikaa, mutta se aiheuttaa seisokin, hukan, uudelleenkäynnistyksen ja työn jatkamista koskevaan päätökseen liittyvän lisävastuun kustannukset. Juuri tässä refaktorointi kytkeytyy muutosten käytännön riskinarviointiin: ei silloin, kun muutos on suuri, vaan silloin, kun sen vaikutuksia ei voida rajata ohjelmistokerrokseen.

Vastuun raja tulee vielä selvemmin esiin siellä, missä sovellus vaikuttaa suojatoimintoihin, liikkeellelähdön sallimisen logiikkaan, kuormanpoistosekvensseihin, pysäytykseen ja uudelleenkäynnistykseen häiriön jälkeen. Tällöin pelkkä koodiversioiden vertailu tai integraattorin tekemä toiminnallinen testi ei enää riitä. Tarvitaan jäsennelty arvio siitä, muuttaako muutos riskitasoa ja vaarantaako se koneen tai asennuksen turvallisen käytön lähtöoletuksia. Tämä on luonteva hetki siirtyä ISO 12100:n mukaiseen riskinarviointiin sekä muutosten riskin arvioinnissa käytettyihin käytäntöihin, ja monimutkaisemmissa tapauksissa apua voi olla myös ISO/TR 14121-2:sta tunnetusta menetelmällisestä lähestymistavasta. Jos sovellus ohjaa hydraulisia tai pneumaattisia järjestelmiä, on lisäksi tarkistettava, muuttaako uusi logiikka energian turvallisen ohjauksen ehtoja ja liikkeiden järjestystä; tällöin merkitystä on myös näille järjestelmille ominaisilla suunnitteluvaatimuksilla eikä vain itse ohjelman oikealla toiminnalla. Projektiryhmälle tämä tarkoittaa yhtä asiaa: käyttöönottoa voidaan pitää valmisteltuna vasta silloin, kun teknisen, käytöllisen ja vaatimustenmukaisuuteen liittyvän vastuun laajuus on määritelty ennen käynnistystä eikä vasta ensimmäisen tapauksen jälkeen.