Udvikling af fabrikken og IT/OT-arkitektur – hvorfor giver provisoriske integrationer bagslag efter nogle år?

Hvorfor emnet er vigtigt i dag

Udvikling af en fabrik handler stadig sjældnere om blot at opstille én ekstra maskine eller sætte endnu en linje i drift isoleret fra resten. Det betyder som regel en udbygning af et miljø, hvor produktionssystemer, vedligehold, kvalitet, planlægning, lager og ledelsesrapportering skal udveksle data og samtidig påvirker hinandens betydning for processens tilgængelighed. I en sådan struktur er IT/OT-arkitekturen ikke længere et teknisk spørgsmål, man kan “afklare senere”, men en projektrelateret beslutning med økonomiske og organisatoriske konsekvenser. Midlertidige integrationer fungerer i idriftsættelsesfasen, fordi de løser et aktuelt problem: de kobler hurtigt en ny maskine på, eksporterer nogle få signaler til en rapport eller omgår begrænsninger i en ældre styring. Efter nogle år viser de deres bagside, når virksomheden forsøger at øge kapaciteten, opfylde nye compliancekrav eller ændre anlæggets driftsmåde på en sikker måde. Så viser det sig, at problemet ikke er et enkelt kabel eller et script, men fraværet af sammenhængende principper for kommunikation, ansvar og adskillelse af funktioner.

Den største fejl er at betragte sådanne løsninger som omkostningsneutrale. De flytter blot omkostningen frem i tiden, og som regel sker det på det værst tænkelige tidspunkt: ved udbygning, audit, hændelser eller leverandørskifte. Set fra projektets side er konsekvensen ikke kun en dyrere implementering af næste fase, men også tab af forudsigelighed. Teamet ved ikke længere, hvilke afhængigheder der er kritiske for produktionens kontinuitet, hvor integratorens ansvar slutter, og hvor anlægsejerens ansvar begynder, eller hvilke ændringer der kræver en ny risikovurdering. I praksis er det netop her, området med skjulte omkostninger ved forkerte projektbeslutninger begynder: ekstra stop, ad hoc-servicearbejde, gentagne godkendelser, vanskeligheder med at dokumentere ændringer og tvister om garantiens omfang. Hvis arkitekturen ikke er beskrevet som en bevidst model for fabrikkens udvikling, vil hver næste fase være belastet af teknisk og organisatorisk gæld.

En god praktisk test er ikke at spørge, om integrationen “virker”, men om den kan ændres sikkert og forudsigeligt om to eller tre investeringsfaser. Hvis en ny linje kræver manuel mapping af signaler flere steder, viden om forbindelserne er spredt mellem leverandører, og genskabelse af den fulde datasti kræver analyse af styringskode, mellemliggende databaser og udokumenterede tjenester, så er projektet allerede kommet ind på et spor med forhøjet risiko. Det er værd at vurdere situationen ud fra tre målbare kriterier: den tid, der kræves for at gennemføre en kontrolleret ændring, muligheden for entydigt at udpege ejeren af hver dataudveksling samt evnen til at genskabe, hvordan en fejl eller ændring påvirker produktion og sikkerhed. Hvis disse tre forhold ikke er tydelige, handler problemet ikke om teamets bekvemmelighed, men om styrbarheden af hele projektet.

Et eksempel fra praksis går igen: en virksomhed sætter et nyt produktionsområde i drift og kobler for at komme hurtigt i gang procesdata til forretningssystemer via mellemløsninger, der er etableret uden for den tiltænkte arkitektur. I en periode ser alt korrekt ud, fordi dataflowet er tilstrækkeligt til rapportering og løbende overvågning. Problemet opstår ved yderligere automatisering, integration med vedligehold eller ved ændring af maskinens driftslogik. Så påvirker én ændring i det operationelle lag rapporter, alarmer, recepter eller fjernadgang, og afhængighederne er ikke længere indlysende. Hvis løsningen desuden griber ind i funktioner, der vedrører stop, afbrydelse af energi eller blokering af genstart, er emnet ikke længere kun et IT-spørgsmål. Det bevæger sig over i området for funktionel sikkerhed og kræver en særskilt analyse, herunder en verifikation af, om forudsætningerne for beskyttelse mod uventet opstart er blevet overholdt. Her møder IT/OT-arkitekturen direkte risikovurderingen i fabrikkens udviklingsprojekt samt de beslutninger, der senere også påvirker omfanget af overensstemmelsesvurdering og den tekniske dokumentation.

Derfor kræver dette emne en beslutning nu og ikke først efter afsluttet idriftsættelse. Ikke fordi enhver integration fra begyndelsen skal være omfattende, men fordi man allerede ved opstart skal skelne mellem en midlertidig løsning og en løsning, der skal indgå i virksomhedens permanente arkitektur. Denne sondring bør have projektmæssige konsekvenser: en særskilt beslutningsejer, betingelser for udfasning af workarounden, dokumentationskrav og kriterier for fornyet vurdering ved udbygning. Hvis virksomheden planlægger yderligere investeringsfaser, modernisering af maskiner eller forberedelse til overensstemmelsesvurdering, vil fraværet af en sådan sondring næsten altid øge ændringsomkostningerne og udvide investorens ansvar. Derfor er IT/OT-arkitektur i dag ikke et tillæg til projektet, men en af forudsætningerne for at bevare kontrollen over omkostninger, tidsplan og risiko.

Hvor vokser omkostninger eller risiko oftest

Det dyreste ved udviklingen af en fabrik er som regel ikke selve grænsefladerne mellem IT og OT, men konsekvenserne af beslutninger, der blev truffet “midlertidigt”, og som efter nogle år begynder at fungere som en permanent IT/OT-arkitektur. En midlertidig integration giver bagslag, ikke fordi den teknisk set var mangelfuld, men fordi ingen fastlagde dens grænser: hvem der har ansvaret for ændringer, hvilke data der er de primære, hvordan konfigurationen genskabes efter en fejl, og hvornår en workaround skal fjernes. I praksis vokser omkostningerne dér, hvor en midlertidig løsning glider ind i vedligehold, produktion, kvalitet eller ledelsesrapportering uden en formel beslutning om, at den fra dette tidspunkt er et kritisk element. For projektet betyder det senere konflikter om budget og omfang, og for organisationen også et udvisket ansvar: en fejl ser ud som et teknisk problem, selv om årsagen var en arkitekturbeslutning, der aldrig blev lukket. Et nyttigt vurderingskriterium er her et enkelt spørgsmål: Kan man efter udbygning af anlægget pege på en procesejer, en dataejer og en procedure for sikker ændring uden at involvere “den eneste person, der ved, hvordan det virker”? Hvis ikke, er risikoen allerede bygget ind i projektet.

Et andet område med stigende omkostninger er manglende adskillelse mellem styringslaget og laget for udveksling af forretningsdata. I den første fase af investeringen kan en sådan genvej virke fristende: den samme server formidler kommunikationen med maskinen, arkiverer data, leverer input til rapportering og håndterer fjernadgang for service. Ved en enkelt linje fungerer det tilsyneladende korrekt, men i de næste udbygningsfaser påvirker enhver ændring med ét formål også de øvrige. En opdatering, der er påtvunget af virksomhedens system, kan forstyrre produktionskontinuiteten, og behovet for hurtigere rapportering kan føre til indgreb i konfigurationen af udstyr, som tidligere arbejdede stabilt. Her består de skjulte omkostninger ved forkerte projektbeslutninger ikke kun i ekstra indkøb af hardware eller integratorydelser. Langt mere belastende er omkostningerne til driftsstop, gentagne test, natarbejde under implementeringer samt nødvendigheden af at genskabe viden, som aldrig blev dokumenteret. Set fra projektstyringens synspunkt er et fornuftigt minimum at vurdere, om en fejl eller ændring i IT-delen kan stoppe maskinens eller linjens operative funktion. Hvis svaret er ja, kræver arkitekturen korrektion, uanset at det “indtil videre virker”.

Et typisk eksempel opstår, når nye maskiner kobles på anlæggets eksisterende infrastruktur. Leverandøren sætter udstyret hurtigt i drift, fordi der er behov for overtagelse og produktionsstart, og derfor etableres kommunikationen med anlæggets systemer via en ekstra computer, et script, der eksporterer filer, eller et manuelt ændret signalkort. Efter et år kommer endnu en maskine til, efter to år skiftes det overordnede system, og efter tre år viser det sig, at ingen entydigt kan beskrive, hvilke meddelelser der er kritiske for processen, hvilke der kun bruges til rapportering, og hvilke der har betydning for diagnostik eller sporbarhed af batcher. På dette punkt bevæger emnet sig allerede delvist over i området udarbejdelse af brugsanvisninger til maskiner, for hvis operatøren, vedligehold eller service ikke har dokumenterede procedurer for tab af kommunikation, manuel bypass eller genskabelse af parametre efter udskiftning af en komponent, er problemet ikke længere udelukkende IT-relateret. Det bliver en del af organiseringen af sikker drift og det efterfølgende ansvar for brugsmåden og for ændringer.

Først på dette trin bliver det tydeligt, hvorfor emnet også vender tilbage ved overensstemmelsesvurdering, teknisk dokumentation og budgettering af ændringer. Hvis integrationen påvirker maskinens funktioner, spærringslogikken, måden tilstande bekræftes på eller de oplysninger, der gives til brugeren, kan det være nødvendigt med en fornyet risikoanalyse og en verifikation af, om dokumentationen stadig svarer til den faktiske løsning. Omfanget af denne vurdering afhænger af ændringens karakter, så det kan ikke afgøres redeligt med én universel sætning, men netop derfor er provisoriske løsninger så dyre: de gør det vanskeligere at fastslå, hvad der faktisk blev ændret, og hvilke juridiske og driftsmæssige konsekvenser det har. For beslutningsteamet er det praktiske kriterium følgende: Hvis en ændring i integrationen ikke kan beskrives i konfigurationsdokumentationen, testproceduren og driftsreglerne uden henvisning til uformel viden, er projektet allerede gået ind i en zone, hvor ikke kun de tekniske omkostninger vokser, men også ansvaret for investoren, projektlederen og de personer, der godkender løsningen til drift.

Hvordan man griber emnet an i praksis

I praksis er spørgsmålet ikke, om IT og OT skal integreres hurtigere, men hvor grænsen skal trækkes mellem en midlertidig løsning og en arkitekturgæld, der om nogle år vil blokere fabrikkens udvikling. Midlertidige forbindelser opstår som regel under pres fra idriftsættelsen: man skal hurtigt hente data ud af maskinen, tilføje en ny linje, koble kvalitetssystemet sammen med produktionsregistrene eller sikre fjernadgang for service. Problemet begynder, når en løsning, der blev indført “for en kort periode”, bliver grundlaget for de næste projektbeslutninger. Teamet mister en tydelig ansvarsfordeling, og enhver udbygning kræver, at viden genskabes ud fra korrespondance, lokale indstillinger og operatørernes praksis. Det er ikke længere en mindre teknisk ulempe, men en faktor, der påvirker tidsplanen, ændringsomkostningerne og evnen til at dokumentere, hvem der godkendte den pågældende løsning til drift, og på hvilket grundlag.

Derfor begynder den rigtige tilgang med en arkitekturbeslutning og ikke med valg af værktøj. Lederen eller den ansvarlige for området bør kræve, at hver ny integration har et klart defineret driftsmæssigt formål, en ansvarlig på begge sider af IT/OT-grænsen samt fastlagte vilkår for vedligehold efter idriftsættelse. Hvis det ikke er klart, hvem der har ansvaret for datakilden, hvem der godkender ændringer i konfigurationen, hvem der tester konsekvenserne for processen, og hvem der beslutter nødtilstand, så flytter projektet i praksis risikoen over i driftsfasen. Det er netop her, projektlederens rolle i IT/OT-beslutninger naturligt begynder: ikke som koordinator af deadlines, men som den person, der tvinger en afklaring af ansvar igennem, før en midlertidig løsning bliver skrevet ind i budget og tidsplan som en “hurtig workaround”. Et praktisk vurderingskriterium er enkelt: Hvis den planlagte integration ikke kan vedligeholdes efter leverandørskifte, udskiftning af styring eller udbygning af linjen uden medvirken fra den, der lavede den oprindelige workaround, så er det ikke en midlertidig løsning, men en fremtidig projektomkostning.

En god test er situationen, hvor en eksisterende linje udbygges med en ekstra station, som skal sende data til det overordnede system og samtidig reagere på tilstande fra den del, der allerede er i drift. Hvis teamet vælger at koble signaler direkte på og lave en uformel oversættelse af data, “fordi det går hurtigere”, kan alt i starten fungere korrekt. Med tiden viser bivirkningerne sig dog: Det bliver sværere at afgøre, om fejlen skyldes maskinlogikken, kommunikationslaget eller rapporteringsapplikationen; overtagelsestestene dækker kun standardscenarier; modernisering af ét element tvinger rettelser igennem flere steder på én gang. Det er også her, de skjulte omkostninger ved forkerte projektbeslutninger bliver synlige: ekstra stop til fejlsøgning, dyr tilstedeværelse af integratoren ved hver ændring, tvister om garantiens omfang og forsinkelser i de næste investeringsfaser. Derfor er det værd at måle ikke kun idriftsættelsestiden, men også antallet af integrationspunkter, der kræver manuel konfiguration, den tid der skal bruges på hændelsesanalyse efter en ændring, samt antallet af ændringer, der skal testes på tværs i stedet for lokalt.

Først på den baggrund giver det mening at forholde sig til krav om sikkerhed og overensstemmelse. Hvis integrationen påvirker maskinens driftstilstande, spærringer, signalbekræftelser, opstarts- eller stopsekvens, er den ikke længere et neutralt IT-tillæg. Afhængigt af ændringens karakter kan det udløse behov for en fornyet risikovurdering, opdatering af den tekniske dokumentation og kontrol af, om driftsmåden fortsat svarer til de forudsætninger, der er lagt til grund for den pågældende maskine eller linje. Det ses særligt tydeligt dér, hvor integrationslaget begynder indirekte at påvirke betingelserne for sikker adgang, afbrydelse af energi eller forebyggelse af uventet opstart. I sådanne tilfælde bevæger arkitekturbeslutningen sig fra at handle om implementeringsmæssig bekvemmelighed til at handle om juridisk og teknisk ansvar. Hvis teamet ikke kan dokumentere, hvilke forbindelser der udelukkende er informative, og hvilke der påvirker maskinens adfærd, er det et tegn på, at emnet skal løftes ud af niveauet “systemintegration” og behandles som en ændring med betydning for sikkerhed, budget og ansvaret hos de personer, der godkender løsningen.

Hvad man skal være opmærksom på ved implementering

De fleste problemer skyldes ikke selve integrationen mellem IT og OT, men at man i projektet behandler den som et hurtigt middel til at få en ny funktion i drift og ikke som et varigt element i fabrikkens IT/OT-arkitektur. Det er netop dér, de midlertidige forbindelser hævner sig efter nogle år: ved udbygning af linjen, udskiftning af styringer, skift af leverandør til det overordnede system eller ved en sikkerhedsaudit viser det sig, at ingen entydigt kan pege på, hvem der ejer interfacet, hvilke regler det fungerer efter, eller hvilke konsekvenser en fejl har. For projektet betyder det ikke kun omkostningen ved teknisk gæld, men også en organisatorisk omkostning: flere afklaringer, længere tværgående test, vanskeligere overtagelser og større risiko for, at forsinkelsen først opstår til sidst, når tidsplanen er mindst fleksibel. Her glider emnet naturligt over i de skjulte omkostninger ved forkerte projektbeslutninger, fordi kilden til problemet ikke er en enkelt udførelsesfejl, men beslutningen om at udskyde en ordentlig arkitektur til senere.

Ved implementering bør løsningen derfor ikke vurderes ud fra, om den “virker nu”, men om den kan vedligeholdes og ændres sikkert på en forudsigelig måde. Det praktiske kriterium er enkelt: Hvis den planlagte integration ikke har en beskrevet ansvarsfordeling, fejltilstand, versionsstyringsprincipper og testprocedure efter ændringer, er den endnu ikke klar til produktionsimplementering, selv om den fungerer på en teststation. Det er især vigtigt dér, hvor det samme interface skal understøtte både den nuværende investeringsfase og en fremtidig udbygning. Udviklingen af fabrikken øger næsten altid antallet af afhængigheder mellem systemer, og midlertidige løsninger fungerer dårligst netop dér, hvor antallet af undtagelser, workarounds og lokale aftaler vokser. Set fra projektlederens perspektiv betyder det, at man tidligt må afklare, hvem der godkender grænsebeslutninger mellem automation, vedligehold, IT og compliance, for uden det udviskes ansvaret præcis dér, hvor den største konflikt om omkostninger og tidsplan senere opstår.

Et typisk praktisk eksempel er at tilføje dataudveksling mellem linjen og rapporteringssystemet via et mellemliggende script eller en udokumenteret tjeneste, der kører på en server, som “allerede står på fabrikken”. I idriftsættelsesfasen virker løsningen rationel: den kræver ingen ændringer hos maskinleverandøren, forkorter implementeringen og gør det muligt hurtigt at vise et forretningsmæssigt resultat. Problemet opstår senere. Efter en opdatering af operativsystemet, ændring af adressering, gendannelse fra backup eller udskiftning af en enhed er der ingen, der med sikkerhed ved, om logikken for signalmapping stadig svarer til den faktiske proces. Hvis denne mekanisme indgår i kvitteringer, blokeringer, kølægning af ordrer eller startbetingelser, er fejlen ikke længere blot en IT-hændelse, men begynder at påvirke linjens tilgængelighed, produktkvaliteten og ansvaret for at frigive løsningen til drift. Her glider emnet naturligt over i analyse af risiko i et fabriksudviklingsprojekt, fordi man ikke kun skal vurdere sandsynligheden for fejl, men også konsekvenserne af forkerte oplysninger, en forkert sekvens og en forkert operatørreaktion.

Først på den baggrund giver det mening at henvise til de formelle krav. Hvis integrationslaget udelukkende har en informativ funktion, og dette kan dokumenteres teknisk, vil omfanget af forpligtelser være et andet end i en situation, hvor det påvirker maskinens eller linjens adfærd. Hvis det derimod påvirker driftslogikken, betingelserne for start, stop, kvittering eller bypass, skal implementeringen behandles som en ændring med teknisk og potentielt sikkerhedsmæssig betydning og ikke som en almindelig udvidelse af systemet. Det kan betyde, at forudsætningerne for risikovurderingen, den tekniske dokumentation og de overensstemmelsesbetingelser, der er lagt til grund for den pågældende løsning, skal kontrolleres igen. I praksis lyder den sikre beslutning ikke “kan det tilsluttes”, men “vil vi efter implementeringen kunne dokumentere, hvad dette interface gør, hvem der har ansvaret for det, og hvordan vi styrer ændringen”. Hvis svaret ikke er entydigt, vil omkostningen ved den udsatte arkitekturbeslutning som regel vende tilbage ved næste modernisering, certificering eller hændelse, og så vil det ikke længere kun være et teknisk problem, men også et ledelsesmæssigt problem.