Udvikling af en industriel applikation: hvordan forbereder man inputdata?

Forberedelse af inputdata til et projekt med en industriel applikation er i dag ikke et administrativt trin, man kan “lukke undervejs”, men en beslutning, der har direkte betydning for idriftsættelsestid, omkostninger ved ændringer og ansvarsfordeling efter implementeringen. I et produktionsmiljø fungerer applikationen sjældent isoleret: den skal indgå i den eksisterende automatik, kvalitetsflowet, vedligeholdelsen og ofte også i krav til sporbarhed og compliance. Hvis der fra start mangler en entydig beskrivelse af processen, datakilderne, de operationelle undtagelser og ansvarsgrænserne mellem parterne, designer teamet ikke en løsning, men forsøger at genskabe virkeligheden ved trial-and-error. Det er netop her, tidsplanen forlænges – ikke på grund af programmeringen, men på grund af korrektioner af forudsætninger, ekstra besøg på anlægget, diskussioner om scope og behovet for omarbejdning efter test på stedet.

Den største fejl er som regel, at man kun betragter listen over de funktioner, applikationen forventes at have, som “inputdata”. I et industrielt projekt er randbetingelserne imidlertid lige så vigtige: hvem der indtaster data og hvornår, hvilke signaler der kommer fra styresystemet, hvad der sker ved manglende kommunikation, hvilke manuelle workarounds der er acceptable, hvilke hændelser der skal registreres, og hvilke operatørbeslutninger der har konsekvenser for kvalitet eller sikkerhed. Forretningmæssigt er denne sondring afgørende, fordi det netop er i disse grænseflader, de dyreste ændringer opstår. Hvis applikationen skal understøtte produktionen og ikke kun præsentere data, bliver et upræcist projektgrundlag meget hurtigt til et problem i organiseringen af samarbejdet mellem integrator, softwareleverandør og vedligeholdelse. Hver af disse parter ser kun en del af processen, men konsekvenserne af en forkert beslutning bæres som regel af investoren: i form af nedetid, ekstra godkendelser og tvister om, hvorvidt en given funktion var “indlysende” eller faktisk lå uden for scope.

I praksis ses det tydeligt i et enkelt eksempel med en applikation, der overvåger recepter, produktionspartier eller et register over kvalitetshændelser. Hvis teamet går i gang uden at have fastlagt, hvilke data der er kildedata, hvilke der kun er afledte, hvem der må korrigere dem, og om en korrektion skal efterlade et spor, viser problemet sig ikke i mockup-fasen, men først under idriftsættelsen eller ved en intern audit. Pludselig viser det sig, at applikationen “virker”, men at man ikke på det grundlag kan rekonstruere et partis forløb, forklare en afvigelse eller dokumentere, hvorfor operatøren traf en bestemt beslutning. Her glider spørgsmålet om forberedelse af inputdata naturligt over i design af sporbarhed for produkt og proces, og nogle gange også i budgettering af compliance, fordi enhver sen ændring i måden data registreres på, kræver ombygning af logik, grænseflader og accepttest.

Et praktisk kriterium for at vurdere situationen er enkelt: før implementeringen starter, skal man for hver nøgleinformation kunne angive dens ejer, kilde, tidspunkt for opståen, valideringsregel og konsekvens ved fejl. Hvis teamet ikke kan gøre det uden at støtte sig til antagelser eller “kontrol på anlægget”, er inputdataene ikke klar, og projektet vil indhente manglerne på det dyrest tænkelige tidspunkt. Det er værd at måle ikke kun afleveringsfristen for applikationen, men også antallet af scopeændringer efter godkendt analyse, antallet af spørgsmål der blokerer implementeringen, den tid der kræves til tværfaglige afklaringer samt antallet af rettelser, der først bliver synlige under test i produktionen. Det er indikatorer for kvaliteten af projektforberedelsen og ikke kun for kvaliteten af leverandørens arbejde.

Først i dette lys bliver betydningen af compliance tydelig. Hvis applikationen påvirker maskinens funktion, måden den betjenes på, registreringen af sikkerhedsrelevante hændelser eller dokumentationen af procesparametre, kan måden inputdata defineres på også påvirke omfanget af overensstemmelsesvurdering og teknisk dokumentation. Det vil ikke altid være et spørgsmål om CE-mærkning, fordi det afhænger af applikationens rolle og systemets arkitektur, men hvis man ignorerer denne sammenhæng i starten af projektet, øger det næsten altid omkostningerne ved de senere afklaringer. Derfor skal beslutningen træffes nu: Skal forberedelsen af projektinput behandles som en formalitet før bestilling af arbejdet, eller som en ingeniørmæssig fase, hvor ansvar afklares, risikoen for ændringer begrænses, og der skabes forudsætninger for en reelt kortere implementering.

Hvor omkostning eller risiko oftest vokser

De største omkostninger opstår som regel ikke i selve programmeringen af den industrielle applikation, men dér, hvor inputdataene er ufuldstændige, inkonsistente eller kun beskriver den ønskede forretningseffekt uden de tekniske betingelser for at opnå den. Hvis det fra start ikke er klart, hvilke signaler der er den autoritative datakilde, hvad procesens grænsetilstande er, hvem der godkender reglerne for alarmering, og hvilke hændelser der skal registreres, begynder projektteamet at træffe stedfortrædende beslutninger. Det er netop her, antallet af scopeændringer efter godkendt analyse vokser, der opstår spørgsmål, som blokerer implementeringen, og afklaringerne mellem automatik, vedligeholdelse, kvalitet og sikkerhed trækker ud. For projektet betyder det ikke kun forsinkelse, men også en forskydning af ansvaret: leverandøren bliver ansvarlig for en løsning, hvis forudsætninger ofte er blevet lagt til grund stiltiende og ikke gennem bevidst aftale.

En anden kilde til risiko er, at funktionskrav forveksles med designbeslutninger. I praksis viser det sig ved, at kunden beskriver en skærm, en rapport eller en styringsmåde, men ikke definerer det operationelle formål, randbetingelserne og undtagelserne. Så kommer enhver senere procesændring til at ligne en “mindre justering”, selv om den i virkeligheden kræver ombygning af logikken, test og nye afklaringer. Et godt vurderingskriterium er enkelt: Hvis man for et givent krav ikke entydigt kan svare på, hvem der træffer beslutningen, på grundlag af hvilke data, inden for hvilken tid og med hvilken effekt på processen, så er det endnu ikke et færdigt input. Her glider emnet naturligt over i de mest almindelige fejl i industriprojekter, fordi problemet ikke kun handler om dokumentation, men om selve måden løsningen bliver defineret på.

Et praktisk eksempel er en applikation, der skal overvåge omstilling af en linje og blokere opstart ved uoverensstemmelse i receptparametre. Hvis projektinputtet begrænser sig til udsagnet om, at “systemet skal sikre korrekte indstillinger”, er risikoen næsten sikker. Det skal afklares, hvilke parametre der er kritiske, hvor de hentes fra, om operatøren må overskrive dem, hvordan tab af kommunikation håndteres, hvad der regnes som bekræftelse af overensstemmelse, og om blokeringen kun er procesmæssig, eller om den påvirker maskinens sikkerhedsfunktion. Uden disse afklaringer vil de afsluttende test næsten altid afsløre en konflikt om ansvar: produktionen forventer fleksibilitet, kvalitet kræver et auditerbart spor, og vedligehold har brug for mulighed for sikker bypass i servicetilstand. Det er ikke udførelsesdetaljer, men manglende input, som koster mest ved projektets afslutning.

En særskilt risikokategori opstår, når applikationen griber ind i maskinens logik, arbejdssekvensen, måden alarmer kvitteres på eller registreringen af hændelser, der er væsentlige for sikkerhed og kvalitet. I så fald er emnet ikke længere kun et IT-spørgsmål. Hvis projektet ændrer betingelserne for brug af maskinen, måden der reageres på fejl, eller omfanget af de oplysninger, der kræves for at dokumentere overensstemmelse, kan det falde ind under risikoanalyse i projektet og i næste led også forberedelse af maskinen til overensstemmelsesvurdering og teknisk dokumentation. Det vil ikke i alle tilfælde have betydning for CE-mærkning, fordi det er applikationens faktiske rolle i systemarkitekturen, der er afgørende, men kriteriet er klart: Hvis en fejl i applikationen kan ændre procesadfærden på en måde, der påvirker sikkerhed, produkt eller dokumentationsforpligtelser, skal dette afklares før implementering og ikke efter afleveringstest.

Set fra et implementeringsstyringsperspektiv er det derfor ikke enkelte tekniske fejl, der er dyrest, men manglen på beslutninger truffet på det rigtige tidspunkt. Derfor bør kvaliteten af input vurderes ikke ud fra beskrivelsens omfang, men ud fra evnen til at lukke tvister, allerede før programmeringsarbejdet går i gang. Hvis der efter opstartsworkshops stadig ikke findes et entydigt svar på, hvilke krav der er kritiske, hvilke der kun er brugerpræferencer, hvad der skal valideres, og hvilke ændringer der udløser yderligere risikoanalyse eller compliance-afklaringer, så er tidsplanen kun tilsyneladende sikker. I praksis betyder det, at omkostning og ansvar blot er skubbet til en fase, hvor korrektioner er langsomst og dyrest.

Sådan griber man emnet an i praksis

I praksis begynder en kortere implementeringstid ikke med hurtigere programmering, men med at begrænse antallet af beslutninger, der først skal træffes under implementeringen. Input til projektet for en industriel applikation bør derfor organiseres ikke omkring en funktionsbeskrivelse, men omkring de steder, hvor projektet kan gå i stå: ansvarsgrænser, driftsbetingelser, afhængigheder til automatikken, påvirkning af processikkerheden, valideringskrav og regler for ændringshåndtering. Hvis teamet får en omfattende beskrivelse af brugerens forventninger, men det ikke er afklaret, hvem der godkender alarmlogikken, hvilke signaler der er den autoritative kilde, hvordan nød- eller fallback-drift ser ud, og hvad der må ændres uden en ny vurdering af konsekvenserne, så er tidsplanen kun tilsyneladende stabil. I den situation kommer omkostningen senere i form af rettelser, uenigheder ved aflevering og ansvar, der flyder mellem leverandørerne.

Derfor er det værd fra starten at bruge ét enkelt kriterium til at vurdere kvaliteten af inputmaterialet: om det på det grundlag er muligt entydigt at knytte en teknisk beslutning til en ansvarlig, en betingelse for idriftsættelse og en metode til verifikation. Det kriterium skaber bedre struktur end den generelle konstatering, at “kravene er beskrevet”. For en manager betyder det, at nogle få spørgsmål skal være lukket, før arbejdet bestilles: om applikationen kun visualiserer processen, eller også styrer dens adfærd; om den påvirker produktets kvalitetsparametre; om den skal integreres med den eksisterende automatik; om vedligehold skal overtage konfigurationen efter implementeringen; og om der forventes ændringer efter idriftsættelse. Hvis svarene på disse spørgsmål er betingede eller spredt ud over korrespondance, så har projektet endnu ikke reelle inputdata, men kun et sæt arbejdsmæssige antagelser. Forskellen er væsentlig, fordi arbejdsmæssige antagelser som regel ikke holder til virkeligheden på produktionsgulvet.

Et godt eksempel er en applikation, der skal indsamle data fra produktionslinjen, vise udstyrets status og give operatøren mulighed for at ændre visse indstillinger. I salgsfasen bliver et sådant omfang ofte behandlet som “et standard operatørlag”, men for implementeringen er det afgørende at skelne mellem, hvilke indstillinger der kun vedrører drift, og hvilke der påvirker procesforløbet, produktkvaliteten eller maskinens adfærd i unormale tilstande. Hvis dette ikke bliver afklaret før implementeringen, vil programmøren forberede en mekanisme til redigering af parametre, integratoren vil koble den til styringen, og først under overtagelsesprøverne opstår spørgsmålet, om ændring af en given værdi kræver spærring, ændringsspor, ekstra godkendelse eller en fornyet risikoanalyse. På det tidspunkt er problemet ikke længere teknisk. Det bliver en tvist om ansvar: hvem der godkendte funktionen til brug, hvem der skulle vurdere dens indvirkning på sikkerheden, og hvem der bærer konsekvenserne, hvis det efter idriftsættelsen viser sig, at rettighedsomfanget var for bredt.

Derfor bør den praktiske forberedelse af inputdata afsluttes med en kort, men bindende beskrivelse af projektets beslutningslogik og ikke kun med en liste over skærmbilleder, rapporter eller signaler. En sådan beskrivelse bør fastlægge, hvilke funktioner der er omfattet af funktionel overtagelse, hvilke der kræver bekræftelse fra slutbrugeren, og hvilke der udløser yderligere afklaringer med integratoren, vedligeholdelsesafdelingen eller den person, der er ansvarlig for overensstemmelse. Det er her, emnet naturligt glider over i organiseringen af samarbejdet mellem softwarehuset, integratoren og driften, for uden afklaring af ansvarsgrænseflader kan selv en korrekt udviklet industriel applikation gå i stå i grænsefladen mellem systemer. Hvis applikationen derimod påvirker maskinens funktioner på en måde, der er væsentlig for sikkerheden, eller ændrer systemets tilsigtede adfærd, er det samme inputmateriale ikke længere kun et projektdokument, men får også betydning for den videre overensstemmelsesvurdering og den tekniske dokumentation.

Normative referencer bør først inddrages, når det er klart, at applikationen faktisk påvirker sikkerhedsområdet, produktets overensstemmelse eller kræver formel validering. Ikke enhver industriel applikation vil falde inden for dette område, men det må man ikke antage uden at kontrollere det. Kriteriet er praktisk: hvis en funktionsfejl, en forkert konfiguration eller en uautoriseret ændring af en parameter kan ændre maskinens tilstand, processen eller operatørens beslutning på en måde, der har betydning for sikkerhed, kvalitet eller dokumentationsforpligtelser, kræver projektet ikke kun en præcisering af kravene, men også en tidligere gennemgang af risikoanalyse og vurdering af påvirkningen på overensstemmelse. Det er netop her, det oftest afgøres, om implementeringen bliver kortere, eller blot hurtigere bevæger sig ind i en fase med dyre korrektioner.

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

Selv godt forberedte inputdata forkorter ikke implementeringen, hvis teamet behandler dem som en funktionsbeskrivelse og ikke som rammebetingelser for ansvar, ændringer og overtagelse. I projekter med industrielle applikationer skyldes forsinkelser sjældent selve programmeringen; oftere opstår de, fordi det ved idriftsættelsen viser sig, at inputdata ikke fastlægger, hvem der godkender procesparametre, hvem der har ansvaret for kvaliteten af data fra udstyret, under hvilke betingelser ændringer må indføres, og hvad der danner grundlag for overtagelse. Så begynder implementeringen at leve sit eget liv: enhver uklarhed kræver en ekstra beslutning, enhver beslutning åbner risikoen for en tvist om omfanget, og enhver korrektion udført på anlægget øger omkostningerne og ansvaret på begge sider. Hvis målet er at forkorte implementeringstiden, skal inputmaterialet kunne bruges ikke kun af projektøren, men også af integratoren, vedligeholdelsesafdelingen, kvalitetsafdelingen og de personer, der er ansvarlige for overensstemmelse.

Særlig forsigtighed er nødvendig i situationer, hvor applikationen skal arbejde med uensartede data fra forskellige styringer, overordnede systemer eller manuelle operatørindtastninger. Det er her, fælden med tilsyneladende fuldstændighed oftest opstår: signaloversigten findes, skærmbillederne er beskrevet, men der er ingen entydige regler for prioritet, betydningen af fejltilstande, dataenes gyldighedstid eller systemets reaktion ved manglende opdatering. I praksis fører det til fejl, som formelt ikke er en softwarefejl, men en konsekvens af en uafklaret driftsmodel. For projektlederen er det en vigtig sondring, fordi den påvirker omkostningerne ved ændringer og det kontraktmæssige ansvar. Et godt vurderingskriterium er enkelt: hvis man for en nøglefunktion ikke kan angive datakilden, beslutningsejeren, afvisningsbetingelsen og måden at bekræfte korrekt funktion på i én sætning, så er inputdataene stadig for svage til, at man sikkert kan gå videre til implementering.

Det ses tydeligt i eksemplet med en applikation, der beregner procesindstillinger og sender dem videre til det udførende system eller viser dem til operatøren som grundlag for en beslutning. Hvis det ikke fra starten er fastlagt, om værdierne er informative, vejledende eller styrende, ved implementeringsteamet ikke, hvilket testregime der skal anvendes, og hvem der har beføjelse til at acceptere en afvigelse fra den forventede adfærd. Den slags uklarhed bliver som regel først synlig under idriftsættelsen, når spørgsmålet opstår, om produktionen kan startes trods ufuldstændig validering af historiske data eller på trods af manuelle omgåelser. I den situation er det kun tilsyneladende, at tidsplanen forkortes med “midlertidige” løsninger: risikoen for reklamationer og driftsstop vokser, og i yderste konsekvens også ansvaret for skade som følge af en forkert procesbeslutning. Derfor bør man før implementeringen fastlægge et målbart kriterium: findes der for hver funktion, som påvirker procesparametrene, et entydigt scenarie for accepttest med definition af fejlagtige data, manglende data og handling efter genetablering af kommunikationen. Det er ikke formalisme, men en forudsætning for en forudsigelig idriftsættelse.

Først på den baggrund bliver det tydeligt, hvornår emnet ophører med kun at være et spørgsmål om organiseringen af implementeringen og begynder at bevæge sig ind i området for risikoanalyse og klargøring af maskinen til den videre overensstemmelsesvurdering. Hvis applikationen ændrer maskinens driftslogik, påvirker operatørens beslutninger i sikkerhedskritiske situationer eller bliver en del af en funktion, som den tilladte procestilstand afhænger af, er det ikke nok blot at “præcisere kravene”. Man skal kontrollere, om inputmaterialet gør det muligt at dokumentere den tilsigtede funktion, begrænsningerne i anvendelsen og betingelserne for validering, for uden dette kan implementeringen godt afsluttes teknisk, men alligevel gå i stå ved overtagelsen, i den tekniske dokumentation eller ved en senere audit. I praksis er grænsen tydelig: Hvis datafejl, forkert konfiguration eller en uautoriseret ændring af en parameter kan medføre en konsekvens, der er væsentlig for sikkerheden, produktkvaliteten eller dokumentationsforpligtelserne, bør projektet kobles til en særskilt risikoanalyse og ikke afsluttes alene med funktionstest. Det er netop i krydsfeltet mellem implementering, risikoanalyse og de fremtidige krav i forbindelse med CE-mærkning, at de dyreste korrektioner oftest opstår — korrektioner, som set fra tidsplanens perspektiv ligner småting, men i virkeligheden sender projektet tilbage til forudsætningsfasen.