Refaktorisering av en äldre industriapplikation – när är det motiverat och hur genomför man den utan risk för produktionen?

Varför ämnet är viktigt i dag

Refaktorering av en äldre industriapplikation är inte längre en fråga om kodens estetik eller om att förenkla underhållet. I dag är det ett beslut som påverkar produktionskontinuitet, kostnadsförutsägbarhet och omfattningen av systemägarens ansvar. I många anläggningar har styrande applikationer, operatörsverktyg och kommunikationslager utvecklats under lång tid utan en sammanhållen arkitektur, ofta kring utrustning, bibliotek och integrationsmekanismer där stödet är begränsat eller har upphört. Ett sådant läge kan vara acceptabelt under en tid, men bara fram till den punkt där varje ytterligare ändring börjar kosta mer än den funktionalitet den ska leverera. Då är frågan inte längre om man ska röra den gamla applikationen, utan om organisationen fortfarande har kontroll över hur den beter sig i produktionsmiljö.

Ämnets betydelse beror på att teknisk skuld i industriella system mycket snabbt blir en operativ skuld. Om applikationen är svår att återskapa, är beroende av enskilda personer, saknar tillförlitliga reproducerbara tester eller har en logik där produktionsfunktioner blandas med funktioner för säkerhet och diagnostik, blir varje incident dyrare än ett motsvarande problem i ett kontorssystem. Konsekvensen är inte bara stillestånd. Till detta kommer kostnaden för underhållspersonalens arbete, risken för felaktiga tillfälliga lösningar under tidspress, svårigheten att visa att man har agerat med tillbörlig omsorg efter en ändring samt problemet att skilja mellan vad som var ett tidigare fel och vad som är en följd av projektgruppens ingrepp. För chefen och produktägaren är det praktiska kriteriet enkelt: om tiden och osäkerheten vid införandet av ytterligare mindre ändringar ökar snabbare än deras affärsvärde, har applikationen nått ett läge där beslutet om refaktorering måste fattas medvetet och inte skjutas upp till det första kritiska haveriet.

De flesta misstagen uppstår när refaktorering behandlas som en modernisering “utan påverkan på processen”, trots att den i praktiken förändrar hur systemet fattar beslut. I praktiken räcker det med ett till synes litet ingrepp: byte av en kommunikationskomponent, ombyggnad av schemaläggningen av uppgifter, ändring av logiken för buffring av sensordata eller upprensning av startsekvensen efter en omstart. På papperet är detta tekniska justeringar. I anläggningen kan de däremot ändra tidpunkten för en signal, ordningen för när spärrar släpps, reaktionen vid förlorad kommunikation eller applikationens beteende efter ett strömavbrott. Det är just här som refaktorering övergår i en praktisk bedömning av ändringsrisk enligt ISO 12100: det handlar inte om huruvida koden är “bättre”, utan om maskinen, linjen eller arbetsstationen fortfarande beter sig förutsägbart efter ändringen i normala tillstånd, vid störningar och efter återstart.

Ett bra test på om beslutet är moget är att kontrollera om teamet kan dra gränsen mellan en ändring i applikationens interna struktur och en ändring av en funktion som är viktig för processen eller säkerheten. Om den gränsen inte går att beskriva på nivån signaler, tillstånd och övergångsvillkor är projektet förenat med risk oavsett leverantörens kvalitet. I industriella miljöer är situationer särskilt känsliga där applikationen deltar i sekvenser för start, stopp, felåterställning, kvittering av larm eller samverkar med system för frånkoppling av energi och spärrar. Då uppstår inte bara en fråga om programvaruarkitektur, utan också om skydd mot oavsiktlig igångsättning och om analysen även omfattar elinstallationen, styrlogiken och beroendena mellan olika enheter. Det är just här som en till synes lokal refaktorering upphör att vara en IT-uppgift och blir en teknisk ändring som kräver en fullständig beslutsprocess.

Hänvisningen till normativa krav blir relevant först i detta skede, eftersom standarder inte ersätter projekteringsbeslutet men hjälper till att avgränsa dess omfattning. Om ändringen kan påverka villkoren för start, stopp, återupptagande av drift efter en störning eller skyddsåtgärder, måste den bedömas som en riskändring och inte som vanligt kodunderhåll. Om ingreppet berör logik som samverkar med frånkoppling av energi, spärrar eller sekvensen för säker åtkomst, öppnas också naturligt området för krav som rör skydd mot oavsiktlig igångsättning. Ur ansvarssynpunkt är därför det viktigaste inte bara “om man ska refaktorera”, utan om organisationen kan visa att den känner till ändringens gränser, har acceptanskriterier baserade på processens beteende och kan skilja mellan att ordna upp systemet och en modifiering som kräver fullständig riskbedömning samt samordning med projektering av installationen och tester på plats.

Var kostnaden eller risken oftast ökar

Den största kostnadsökningen vid refaktorisering av en äldre industriell applikation beror sällan på själva koden. Problemet uppstår oftast när ändringen klassas fel: teamet behandlar den som en upprensning av programmets struktur, medan det i praktiken är systemets tidsmässiga beteende, ordningsföljden mellan steg eller villkoren för övergång mellan tillstånd som förändras. I en produktionsmiljö får ett sådant misstag direkta konsekvenser för projektet. Tidsplanen slutar motsvara den verkliga omfattningen, tester planeras utifrån IT-funktionalitet i stället för processförloppet, och ansvaret för resultatet blir otydligt mellan underhåll, automation och programvaruleverantören. Det praktiska kriteriet är enkelt: om ändringen kräver att man på nytt bekräftar startsekvens, stopp, återupptagande efter störning eller reaktion på signaler från skyddskretsar, då handlar det organisatoriskt inte längre om en “säker refaktorisering”, utan om en ändring som kan skapa risk för produktionen och som kan kräva en annan godkännandeprocess.

Det andra typiska området där kostnaderna växer är när ett konstruktionsbeslut fattas utan full överblick över beroenden. Äldre industriella applikationer är ofta tätt sammanflätade med styrsystemets konfiguration, ställdon, visualisering, datalagring och operatörsrutiner. I dokumentationen ser detta ut som ett enda system, men i praktiken är det flera lager som har utvecklats under många år av olika team. En refaktorisering som ska förbättra kodens läsbarhet eller förenkla framtida underhåll kan omärkligt ändra innebörden av fördröjningar, villkor för spärrar, standardvärden efter omstart eller sättet att hantera kommunikationsfel. Följden blir inte bara en teknisk korrigering, utan också kostnader för stillestånd, extra prov på anläggningen och tvister om felet fanns tidigare eller infördes genom ändringen. Därför bör man före beslutet inte bedöma enbart modifieringens storlek, utan också antalet och kritikaliteten hos gränssnitten: hur många signaler, recept, driftlägen och praktiska driftmässiga kringlösningar som är beroende av den koddel som ska byggas om. Ju fler sådana punkter det finns, desto mindre rimligt är det att refaktorisera “på köpet” inom ramen för en annan uppgift.

I praktiken är de mest kostsamma projekten ofta de där teamet upptäcker de verkliga kraven först under idrifttagningen. Ett typiskt exempel är ombyggnad av en sekvensmodul som enligt beskrivningen “gör samma sak, bara renare”. Efter införandet visar det sig dock att den tidigare versionen innehöll odokumenterade beteenden som kompenserade för brister i anläggningen: en kort signalhållning, tolerans för en försenad givare, en specifik ordning för kvittering av larm eller ett villkor som avgör om serviceåtkomst är möjlig. I koden såg detta ut som ett fel eller teknisk skuld, men för processen var det en del av stabiliseringen. Om refaktoriseringen tar bort sådana mekanismer utan att deras funktion först klarläggs uppstår kostnaden omedelbart: antalet insatser efter idrifttagning ökar, acceptanstiden blir längre och logiken måste återskapas under press från den pågående driften. Därför bör nyttan med refaktorisering också bedömas utifrån möjligheten att återskapa det nuvarande systemets beteende. Om organisationen saknar händelseloggar, tillförlitliga beskrivningar av driftlägen och testscenarier som bygger på den verkliga processen, måste man först skapa ett underlag för bedömning och därefter fatta beslut om ombyggnad.

Detta leder direkt vidare till en praktisk riskbedömning av ändringar när modifieringen påverkar skyddsfunktioner, sekvenser för säkert tillträde, styrning av rörelser hos ställdon eller anläggningens beteende vid spänningsbortfall och återinkoppling. Inom ett sådant område begränsas kostnaden för ett fel inte till programmeringskorrigeringar, eftersom frågan om ansvar för att godkänna ändringen för drift också uppstår. Om applikationen samverkar med hydrauliska system, pneumatiska system eller lösningar som tvåhandsstyrning, blir gränsen mellan refaktorisering och teknisk ändring ännu snävare och det krävs en kontroll av att skyddsåtgärdernas konstruktionsantaganden inte har påverkats. Först här är det motiverat att använda strukturerade metoder för riskbedömning enligt ISO 12100, inklusive det angreppssätt som används i praktiken enligt ISO/TR 14121-2, och för hydrauliska system även de konstruktionskrav som struktureras av SS-EN ISO 4413. Det handlar inte om formalism för formalismens egen skull, utan om en enkel beslutsregel: om ändringen kan påverka processens eller operatörens säkerhet, måste kostnaden beräknas tillsammans med validering, tester på anläggningen och ansvarskraven, inte enbart utifrån programmerarens arbetstid.

Hur man närmar sig frågan i praktiken

I praktiken bedöms värdet av att refaktorera en äldre industriell applikation inte utifrån hur tekniskt attraktiv förändringen är, utan utifrån om det samtidigt går att minska driftsrisken och behålla kontrollen över införandet. För chefen och produktägaren innebär det ett enkelt perspektivskifte: frågan är inte om koden “bör städas upp”, utan om applikationens nuvarande skick faktiskt försvårar underhåll, testning, felsökning eller införandet av ytterligare ändringar på ett sätt som uppfyller kraven. Om svaret är ja, är refaktorisering motiverad, men bara i en omfattning som kan avskiljas från produktionen och följas upp utifrån mätbara effekter. Ett bra beslutsunderlag är att jämföra två kostnader: kostnaden för att låta applikationen vara kvar i nuvarande skick, inklusive stillestånd, diagnostid, beroende av enskilda personer och risken för felaktiga ändringar, samt kostnaden för en kontrollerad ombyggnad med tester, validering och driftsättning. Utan en sådan jämförelse tappar projektet vanligtvis styrning, eftersom teamet finansierar kodstädning med en budget avsedd för funktionalitet, medan ansvaret för konsekvenserna i anläggningen förblir oklart.

Därför bör det första beslutet inte vara “vi skriver om” eller “vi låter det vara”, utan att fastställa förändringens gräns. I ett moget arbetssätt skiljer man den del som enbart rör programvarans struktur från den del som påverkar processlogik, start- och stoppsekvenser, driftlägen, kommunikation med drivsystem och beteendet efter störningar i strömförsörjningen. Denna åtskillnad får direkta konsekvenser för både kostnad och organisation. En förändring som begränsas till ett lager för att strukturera koden kan genomföras i en kortare cykel och med mindre medverkan från underhållsorganisationen. En förändring som påverkar maskinens eller linjens beteende kräver däremot en testplan på plats, ett servicefönster, en återgångsprocedur och ett tydligt besked om vem som godkänner återgång till drift. Det är också värt att mäta inte bara tiden för programmeringsarbetet, utan även tiden för att återställa systemet efter ett misslyckat försök, antalet områden som omfattas av regressionstester och den tid som behövs för att diagnostisera en avvikelse efter driftsättning. Det är sådana indikatorer som visar om refaktoriseringen faktiskt minskar projektrisken, och inte bara förbättrar arbetskomforten för utvecklingsteamet.

Ett praktiskt exempel är typiskt för äldre styrsystemsapplikationer: koden innehåller många upprepade delar som ansvarar för rörelsespärrar, larmhantering och växling mellan manuellt och automatiskt läge. Teamet vill standardisera dem, eftersom den nuvarande strukturen försvårar vidareutveckling och skapar skillnader mellan stationer. Ett sådant beslut är först motiverat efter att man har kontrollerat att standardiseringen inte ändrar de villkor under vilka ett ställdon får tillstånd att röra sig, och att en annan sekvens för återställning av tillstånd inte uppstår efter omstart av styrsystemet. Om applikationen även styr ventiler, drivsystem eller system med lagrad energi kan även en till synes “intern” refaktorisering hamna inom området för riskbedömning av förändringen enligt ISO 12100 och kräva en analys av skyddet mot oavsiktlig igångsättning. I ett sådant fall är en rimlig praxis att genomföra refaktoriseringen stegvis: först återskapa beteendet i testmiljö, därefter bryta ut moduler utan att ändra logiken och sedan verifiera på plats med ett förberett återgångsscenario. Det begränsar det operativa ansvaret och gör det möjligt att avbryta införandet innan problemet påverkar produktionen.

Först i detta skede behövs en normativ referens, eftersom standarder inte ersätter det tekniska beslutet men hjälper till att strukturera den punkt där förändringen upphör att vara enbart programmeringsarbete. Om refaktoriseringen påverkar skyddsåtgärder, villkor för säkert tillträde, frånkoppling av energi eller systemens beteende efter stopp och omstart, faller den naturligt inom ramen för en praktisk och strukturerad riskbedömning av förändringen, även med användning av ett arbetssätt som är känt från ISO/TR 14121-2. När det finns risk för oavsiktlig igångsättning måste man inte bara granska själva koden utan även logiken för frånkoppling och återinkoppling av energi, vilket direkt leder till frågor som förknippas med ISO 14118. Om applikationen dessutom är kopplad till hydraulik eller pneumatik får bedömningen inte bortse från dessa systems konstruktionsantaganden, eftersom en felaktig styrsekvens kan äventyra deras säkra funktion oavsett om själva programmet i sig är korrekt; då blir det också motiverat att utgå från krav som strukturerar konstruktionen av hydrauliska system. I praktiken betyder detta en sak: omfattningen av refaktoriseringen avgörs inte av hur elegant lösningen är, utan av gränsen för ansvaret för anläggningens säkra beteende efter förändringen.

Vad man ska se upp med vid införandet

Införandet av refaktorisering i en äldre industriell applikation är det skede där även ett korrekt arkitekturbeslut kan utvecklas till ett operativt problem. Hela initiativet förlorar sitt värde där förändringen förbättrar koden men försämrar anläggningens förutsägbarhet i drift eller utökar teamets ansvar utöver det som har identifierats och godkänts. Det vanligaste felet är att behandla införandet som en vanlig publicering av en ny version. I produktionsmiljö är det inte bara viktigt att applikationen fungerar, utan också att alla övergångstillstånd beter sig identiskt efter förändringen: uppstart efter strömavbrott, omstart av kommunikation, återläsning av recept, hantering av larm, spärrar och manuella lägen. Det praktiska kriteriet är enkelt: om teamet inte entydigt kan beskriva vilka beteenden som måste förbli oförändrade efter införandet, betyder det att förutsättningarna för en säker driftsättning ännu inte finns.

I beslutsskedet inför ett införande behöver man skilja mellan en tekniskt reversibel ändring och en ändring som, när den väl har tagits i drift, skapar ett nytt utgångsläge och försvårar en återgång. Det får direkta konsekvenser för både kostnad och tidplan. En refaktorisering som kräver samtidig uppdatering av styrsystem, visualisering, dataserver och gränssnitt mot överordnade system är inte längre en enskild programmeringsuppgift; den blir en samordnad produktionsändring med flera möjliga felpunkter. Därför bör man före införandet använda ett godkännandekriterium som inte bygger på deklarationen “testerna gick igenom”, utan på förmågan att kontrollerat rulla tillbaka ändringen inom en tid som är acceptabel för processen. Om det inte finns en tillförlitlig återgångsprocedur finns det heller ingen grund för att hävda att risken är under kontroll. I praktiken är det bättre att mäta inte en abstrakt “införandekvalitet”, utan indikatorer som tiden för att återställa föregående version, antalet gränssnitt som påverkas av ändringen samt antalet funktioner vars korrekthet kan verifieras i anläggningen utan ingrepp i produktionen.

Ett bra exempel är en situation där refaktoriseringen förbättrar hanteringen av undantag och felmeddelanden, men samtidigt ändrar ordningen för initiering efter en omstart av systemet. I testmiljön ser allt korrekt ut, eftersom utrustningen är tillgänglig direkt och processen inte körs under belastning. I anläggningen kan samma kod däremot starta sekvensen vid en annan tidpunkt än tidigare, vilket leder till förlorad synkronisering med drivsystemen, felaktig tolkning av klarsignaler eller att en materialbatch blir stående i ett mellanläge. En sådan incident behöver inte innebära ett tekniskt fel i strikt mening, men den genererar kostnader för stillestånd, kassation, omstart och ett ytterligare ansvar för beslutet att återuppta driften. Det är just här som frågan om refaktorisering övergår i en praktisk bedömning av ändringsrisker: inte när ändringen är stor, utan när dess konsekvenser inte längre kan begränsas till programvarulagret.

Ansvarsgränsen blir ännu tydligare där applikationen påverkar skyddsfunktioner, logik för frigivning av rörelse, avlastningssekvenser, stopp och återstart efter en störning. I ett sådant fall räcker det inte längre med att jämföra kodversioner eller med ett funktionstest utfört av integratören. Det behövs en strukturerad bedömning av om ändringen påverkar risknivån och om den inte bryter mot förutsättningarna för säker drift av maskinen eller anläggningen. Detta är ett naturligt tillfälle att gå in i området för riskbedömning enligt ISO 12100 samt de arbetssätt som används vid bedömning av ändringsrisker, och i mer komplexa fall kan ett metodiskt angreppssätt enligt ISO/TR 14121-2 vara till hjälp. Om applikationen styr hydrauliska eller pneumatiska system måste man dessutom kontrollera att den nya logiken inte ändrar villkoren för säker styrning av energi och rörelseordningen; då är även de konstruktionskrav som gäller för dessa system viktiga, inte bara programmets korrekthet i sig. För projektgruppen innebär detta en sak: ett införande kan anses vara förberett först när omfattningen av det tekniska, driftsmässiga och efterlevnadsrelaterade ansvaret har definierats före idrifttagningen, och inte först efter den första incidenten.