Hvordan designer man industrielle applikationer, der er robuste over for midlertidige netværksudfald, genstart af enheder og tab af forbindelse?

At en industriel applikation kan modstå kortvarigt netværksudfald, genstart af enheder og tab af forbindelse, er i dag ikke blot en ekstra komfortfunktion, men en forudsætning for, at processen fungerer korrekt, og for at ansvaret fortsat ligger hos producenten, integratoren eller slutbrugeren. I industrielle miljøer er bortfald af kommunikation ikke en usædvanlig hændelse: det opstår ved servicearbejde, omlægning af infrastrukturen, opstart efter strømsvigt, opdateringer, overbelastning af netværket eller almindelig fejl på en edge-enhed. Hvis applikationen under sådanne forhold mister konsistens i tilstanden, duplikerer kommandoer eller efter genetablering af forbindelsen udfører forsinkede operationer uden kontrol af konteksten, er problemet ikke længere kun IT-relateret. Det bliver et spørgsmål om proceskontinuitet, funktionel sikkerhed, kvaliteten af produktionsdata og sporbarheden af projekteringsbeslutninger.

Derfor skal emnet afklares i starten af projektet og ikke først efter den første idriftsættelse. En arkitektur, der er robust over for afbrydelser i kommunikationen, påvirker måden, maskinens tilstande modelleres på, principperne for databuffering, rækkefølgen for bekræftelse af kommandoer, betingelserne for genetablering af sessioner og logikken for tilbagevenden til drift efter genstart. Hvis teamet udskyder disse beslutninger, ender det som regel med dyre nødløsninger: lokale særregler, manuel rydning af køer, ekstra operatørspærringer eller udbygning af overvågningslaget alene for at kompensere for manglende forudsigelig adfærd i udstyret. Det praktiske vurderingskriterium er enkelt: For hver væsentlig funktion skal man entydigt kunne svare på, hvad der sker ved tab af forbindelse, hvad der sker efter genstart, og hvem der bekræfter genoptagelsen af driften. Hvis svaret er “det afhænger af implementeringen” eller “operatøren kan se, at noget er galt”, er der endnu ikke truffet en projekteringsbeslutning, men blot flyttet risiko over i driften.

Det ses tydeligst i grænsefladen mellem applikationen og maskinens eller processens bevægelse. Forestil dig et system, hvor operatørpanelet sender en kommando om at starte en cyklus, og styringen udfører den med forsinkelse på grund af et kortvarigt tab af forbindelse. Hvis applikationen efter genetablering af kommunikationen sender kommandoen igen, fordi den ikke har modtaget en bekræftelse, kan det føre til dobbelt udførelse af operationen eller opstart under andre betingelser end dem, operatøren så på det tidspunkt, hvor kommandoen blev givet. Her begynder spørgsmålet om kommunikationsrobusthed at bevæge sig ind i området for beskyttelse mod uventet opstart: Ikke enhver genstart er et sikkerhedsproblem, men enhver genstart, som kan ændre opstartsbetingelserne uden bevidst bekræftelse og uden kontrol af udstyrets tilstand, kræver analyse på dette niveau. Det samme gælder blokeringsanordninger og låsning: Hvis applikationslogikken tilskynder personalet til at omgå besværlige spærringer efter en netværksfejl, ligger problemet ikke kun i brugeradfærden, men i selve projekteringsbeslutningen.

Set fra et ledelses- og complianceperspektiv er det derfor afgørende ikke, om afbrydelser i kommunikationen “forekommer”, men om projektet kan dokumentere sikker og forudsigelig adfærd i sådanne grænsetilstande. Det er også her, emnet går over i en praktisk risikovurdering: Man skal skelne mellem funktioner, hvor forsinkelse eller tab af en del af de historiske data er acceptabelt, og funktioner, hvor tab af kontekst kan føre til en forkert operatørbeslutning, beskadigelse af produktet eller fare ved genstart. Det giver mening at måle ikke en abstrakt “systemstabilitet”, men indikatorer, der viser de projekteringsmæssige konsekvenser: antallet af tvetydige genoptagelser efter genstart, antallet af kommandoer, der kræver manuel afstemning af tilstanden, den tid der er nødvendig for sikker tilbagevenden til drift, samt tilfælde hvor systemet ikke kan dokumentere, om en kommando er blevet udført. Først på den baggrund giver normative krav og beslutninger om tekniske foranstaltninger mening: analyse af opstartsbetingelser efter strømsvigt, risikovurdering for scenarier med tab af forbindelse samt valg af blokerings- og overvågningsløsninger dér, hvor selve IT-mekanismen ikke giver tilstrækkelig sikkerhed.

Hvor omkostninger eller risiko oftest vokser

I projekter med industrielle applikationer, der skal være robuste over for kortvarigt netværksudfald, genstart af enheder og tab af forbindelse, stiger omkostningerne oftest ikke på grund af de tekniske mekanismer i sig selv, men på grund af forkerte antagelser om procestilstanden efter en forstyrrelse. Hvis teamet antager, at systemet “vender tilbage til normal drift”, når forbindelsen genetableres, kommer det før eller siden til at betale for manuel afstemning af tilstande, rettelser i styrelogikken, ekstra accepttest eller driftsbegrænsninger, som først indføres efter idriftsættelsen. De dyreste situationer er dem, hvor applikationen ikke entydigt kan afgøre, om en kommando er blevet udført, afbrudt, duplikeret eller kun registreret i interfacet. Det er ikke et spørgsmål om brugervenlighed, men om ansvar for den fysiske virkning: bevægelse af et drev, ændring af et setpunkt, åbning af en ventil, kvittering af en alarm eller genoptagelse af en cyklus.

En anden kilde til projektforsinkelser er en forkert fordeling af ansvar mellem operatørlaget, den mellemliggende applikation og maskinstyringen. Hvis beslutningen om, hvad der skal ske efter en genstart, udskydes “til implementeringen”, ender teamet som regel med uensartede regler: panelet viser den sidst kendte tilstand, styringen starter en initialiseringsprocedure, og det overordnede system afspiller ventende kommandoer uden sikkerhed for, om de stadig er relevante. I praksis skal dette afklares tidligere og helt eksplicit: hvilke operationer der kan gentages uden bivirkninger, hvilke der kræver bekræftelse af anlæggets aktuelle tilstand, og hvilke der ved tab af forbindelse skal udløbe og gå til sikker tilstand. Et godt beslutningskriterium er enkelt: Hvis en fejlagtig genoptagelse af en operation kan ændre energitilstanden, aktuatorens position, produktkvaliteten eller menneskers sikkerhedsforhold, må man ikke alene basere sig på applikationens hukommelse om den sidste tilstand.

Det ses tydeligt i eksemplet med en sekvens, som før kommunikationsudfaldet sendte kommando om at lukke afskærmningen og starte cyklussen, men som efter genstart af operatørstationen genskaber skærmbilledet “klar til drift”. Hvis applikationen ikke skelner mellem tilstandene: kommando modtaget, udførelse bekræftet, udførelse afbrudt, uafklaret tilstand, får operatøren et billede, der virker sammenhængende, men i virkeligheden er ufuldstændigt. Konsekvensen kan være unødige driftsstop, fordi betjeningen ikke tør genoptage processen, eller omvendt: en uautoriseret opstart, fordi brugerfladen ikke viser, at der kræves en ny verifikation. For projektlederen betyder det senere en dyr årsagsanalyse, ændring af testscenarier og behov for at tilføje midlertidige omgåelsesprocedurer. For produktejeren er det en risiko for reklamationer og tvister om ansvarsfordelingen, især når kravspecifikationen ikke entydigt beskriver systemets adfærd efter strømsvigt eller kommunikationsudfald. Derfor er det værd at måle ikke kun tilgængelighed, men også antallet af uafklarede tilstande efter genstart, antallet af operationer der kræver manuel afstemning, samt tiden til opnåelse af sikker driftsklarhed.

En særskilt omkostningskategori er at forveksle kommunikationsrobusthed med funktionel sikkerhed. Det forhold, at applikationen kan buffere data, gentage transmissioner eller genskabe en session, betyder endnu ikke, at maskinen vil opføre sig sikkert ved tab af forbindelsen. Når konsekvensen af en forstyrrelse berører funktioner relateret til bevægelse, lagret energi, låsninger eller betingelser for genstart, glider emnet naturligt over i en praktisk risikovurdering. Her skal man ikke kun undersøge sandsynligheden for netværksfejl, men frem for alt de mulige følger af fejlagtig tilstandsinformation og fejlagtig genoptagelse. Hvis systemet omfatter hydraulik, kommer der krav til aktuatorernes adfærd ved strømsvigt og trykfald; her må applikationsbeslutninger ikke være i modstrid med de projekteringsprincipper, der gælder for hydrauliske systemer. Tilsvarende kan problemet dér, hvor genoprettelse af driftsklarhed afhænger af lukning af en afskærmning eller frigivelse af en låsning, også komme ind på området for låseanordninger og modstandsdygtighed mod omgåelse af sikkerhedsforanstaltninger, fordi presset for “hurtig genoptagelse” meget ofte senere fører til farlige driftspraksisser.

En normativ reference giver først mening på dette trin, når det allerede er klart, hvilket scenarie der har en teknisk og organisatorisk konsekvens. Hvis tab af forbindelse eller genstart kan ændre betingelserne for sikker opstart, skal det beskrives i risikovurderingen og ikke overlades som standardadfærd hos softwareproducenten eller leverandøren af styringen. Hvis aktuatorsystemet efter strømsvigt kan indtage en procesmæssigt ugunstig eller farlig tilstand, skal det kontrolleres, om kravene til den pågældende type drev og medie kræver yderligere konstruktive foranstaltninger, uafhængigt af applikationslogikken. Et praktisk grænsekriterium er følgende: Når en fejl efter genskabelse af tilstanden kun kan fjernes ved en operatørprocedure, er emnet ikke længere kun IT-relateret, men også et spørgsmål om projektering og overensstemmelse. Det er netop her, at beslutningen om applikationsarkitekturen ophører med at være et spørgsmål om implementeringsbekvemmelighed og bliver et element i ansvaret for hele systemets sikre og forudsigelige adfærd, herunder i forhold til CE-certificering af maskiner.

Hvordan man griber emnet an i praksis

I praksis begynder en industriel applikations robusthed over for kortvarigt netværksudfald, genstart af udstyr og tab af forbindelse ikke med valg af teknologi, men med en beslutning om, hvilke fejlkonsekvenser der er acceptable, og hvilke der ikke er. Teamet bør fra starten skille tre ting ad: procestilstanden, styringstilstanden og den tilstand, der vises til operatøren. Denne sondring er afgørende for, om applikationen efter et kommunikationsbrud blot skal genskabe visningen, eller om den også må genoptage styringen, kommandokøen eller den teknologiske sekvens. Hvis disse lag smeltes sammen til ét, ender projektet som regel med dyr tilføjelse af undtagelser, manuelle omgåelsesprocedurer eller en tvist om ansvaret efter idriftsættelsen. For en manager er én ting vigtig her: Manglen på en eksplicit arkitekturbeslutning reducerer ikke risikoen, men flytter den blot til fasen med overtagelse, service og overensstemmelse i industriel automatisering.

Operationelt betyder det, at man for hvert kritisk scenarie skal definere, hvad systemet skal bevare efter en forstyrrelse, og hvad det ikke må bevare. Det handler ikke om den generelle formulering “skal fungere efter reconnect”, men om præcise regler: hvilke data der genskabes fra vedvarende lagring, hvilke der skal bekræftes fra enheden, hvilke kommandoer der mister gyldighed efter timeout, og hvilke der kræver ny autorisation eller operatørbekræftelse. Et godt beslutningskriterium er enkelt: Hvis det efter en genstart ikke entydigt kan fastslås, om en tidligere kommando blev udført, bør systemet ikke automatisk udføre den igen. Det samme gælder alarmer, batchtællere, driftstilstande og teknologiske spærringer. En sådan specifikation kan virke som en mindre projektdetalje, men uden den stiger omkostningerne til integrationstest, fordi enhver uklarhed vender tilbage som en fejl, der er vanskelig at genskabe. Samtidig øges ansvaret hos løsningens ejer, fordi man senere skal kunne dokumentere, at adfærden ved tab af forbindelse var forudsigelig og tilsigtet.

Et typisk eksempel er en applikation, der sender en kommando om at starte en cyklus til styringen og derefter mister forbindelsen, før den modtager en bekræftelse. Hvis applikationen sender kommandoen igen “for en sikkerheds skyld”, når forbindelsen er genetableret, kan den starte cyklussen en gang til. Hvis den omvendt antager, at kommandoen helt sikkert blev udført, kan den genskabe procestilstanden forkert og tillade efterfølgende operationer i forkert rækkefølge. Den rigtige tilgang er at designe kommandoer og svar, så de kan skelnes i tid og identificeres, og så man efter en genstart kan kontrollere enhedens faktiske tilstand, før forretningslogikken genoptages. Her bør man ikke kun måle systemets tilgængelighed, men også antallet af tvetydige tilstandsgendannelser, antallet af manuelle indgreb efter genstart samt den tid, der kræves for at genetablere driften sikkert. Det er indikatorer, som viser de reelle omkostninger ved arkitekturen og ikke kun udviklernes bekvemmelighed.

Grænsen til risikovurdering opstår, når en forkert gendannelse af tilstanden kan ændre maskinens, sekvensens eller aktuatorsystemets adfærd. I så fald er emnet ikke længere kun et IT-spørgsmål, men bevæger sig ind i området for praktisk risikovurdering, også i den betydning, der anvendes i metodikken ved ISO/TR 14121-2. Hvis der efter strømsvigt eller genstart af udstyret er mulighed for automatisk genoptagelse af bevægelse, tilførsel af medium, frigivelse af et aktuatorelement eller overgang til driftstilstand uden operatørens bevidste samtykke, handler det også om beskyttelse mod uventet opstart, hvilket kræver et bredere perspektiv end selve applikationslogikken. Hvor der indgår hydrauliske eller pneumatiske drev, kommer der desuden konstruktionsmæssige krav og systemets adfærd ved energitab oveni, så beslutningen om en “blød” genoptagelse af driften ikke kan træffes uafhængigt af de tekniske forhold i hele installationen. Ud fra et overensstemmelsesperspektiv er det sikreste ikke at gætte på processens intention efter en forstyrrelse, men på forhånd at fastlægge betingelserne for tilbagevenden til drift og knytte dem til konkrete ansvarsområder: applikationen, styringen, aktuatorsystemet og operatøren.

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

De fleste fejl ved implementering af industrielle applikationer, der skal være robuste over for kortvarigt netværksudfald, genstart af udstyr og tab af forbindelse, skyldes ikke selve teknologien, men en forkert placering af ansvaret. Teamet antager, at “robustheden” bliver løst af kommunikationslaget, cloudleverandøren eller styringen, mens problemet i virkeligheden ligger i relationen mellem procestilstand, enhedstilstand og datatilstand. Hvis disse tre niveauer ikke adskilles allerede under idriftsættelse og accept, begynder projektet at skabe en tilsyneladende pålidelighed: Applikationen fungerer efter genstart, men ingen kan dokumentere, om den efter genstart genskabte en tilstand, der var korrekt, sikker og i overensstemmelse med den fysiske virkelighed. Det har direkte betydning for omkostningerne, fordi senere rettelser som regel kræver ændringer samtidig i styrelogikken, operatørgrænsefladen, hændelsesregistreringen og opstartsprocedurerne. Det har også betydning for ansvaret, fordi det ved en hændelse er svært at forsvare en løsning, hvor det ikke entydigt er fastlagt, hvem der bekræfter, at driften kan genoptages, og på hvilket grundlag. Det er især vigtigt i forbindelse med CE-certificering af maskiner.

I praksis er den farligste faldgrube at behandle tab af forbindelse som en almindelig teknisk fejl og ikke som en særskilt driftstilstand for systemet. Hvis applikationen ved netværksudfald bufferer operationer og efter genetablering af forbindelsen afspiller dem uden at kontrollere den aktuelle kontekst, kan den udføre handlinger, der er forsinkede, ikke længere tilladte eller i modstrid med linjens faktiske tilstand. Det samme problem opstår efter genstart af udstyr: Den tidligere gemte logiske tilstand kan formelt være komplet, men fysisk forældet, fordi aktuatorens position, mediets tryk, konfigurationen af driftstilstanden eller operatørens indgreb i mellemtiden er ændret. Et godt beslutningskriterium er også her enkelt: Hvis systemet efter gendannelse af tilstanden skal udføre en handling, der påvirker processen, skal det først være muligt at verificere, at handlingen er tilladt, på grundlag af de aktuelle signaler og ikke kun ud fra historikken, der blev gemt før forstyrrelsen. Hvis en sådan verifikation ikke kan dokumenteres, er det mere sikkert at gå til en tilstand, der kræver eksplicit bekræftelse eller ny synkronisering.

Et godt eksempel er en station, som ved et kortvarigt bortfald af kommunikationen mister forbindelsen til det overordnede system, men lokalt stadig registrerer en del af indgangssignalerne. Set fra programmets perspektiv kan det være fristende at “afslutte sekvensen”, når forbindelsen vender tilbage, for ikke at miste cyklustid. Problemet opstår, hvis operatøren i mellemtiden har fjernet emnet, en aflastningsventil er blevet aktiveret, panelet er blevet genstartet, eller drevet er skiftet til en anden tilstand. I applikationslogikken kan alt stadig se konsistent ud, og alligevel vil genoptagelse af trinnet være en teknologisk fejl eller en fare. Derfor bør man ved implementering ikke kun vurdere antallet af tabte meddelelser eller tiden til at genskabe sessionen, men også indikatorer, der viser kvaliteten af systemets adfærd efter en forstyrrelse: hvor mange gange systemet krævede manuel resynkronisering, hvor mange operationer der blev afvist som forældede, og hvor mange genstarter der endte med overgang til sikker tilstand i stedet for automatisk genoptagelse. Det er bedre mål for løsningens modenhed end selve tjenestens tilgængelighed, fordi de viser, om robustheden er opnået på bekostning af kontrollen over processen.

Grænsen, hvor dette emne ikke længere kun er et spørgsmål om applikationsarkitektur, nås hurtigere, end projektteams normalt antager. Hvis tab af forbindelse, genstart af styringen eller gendannelse af opgavekøen kan påvirke maskinbevægelse, tilførsel af energi eller ændring af aktuatorernes tilstand, bliver emnet i praksis til en risikovurdering. På dette punkt er det ikke længere nok at hævde, at løsningen “normalt fungerer korrekt”; der er behov for en analyse af afvigelsesscenarier, også i en logik, der ligger tæt på den tilgang, der anvendes i ISO/TR 14121-2. Hvis der desuden efter genetablering af strømforsyning eller kommunikation er mulighed for automatisk genoptagelse af funktioner, handler emnet også om beskyttelse mod uventet opstart og skal vurderes bredere i sammenhæng med opstartsbetingelser og energiafbrydelsens tilstand. Der, hvor systemet omfatter hydraulik eller pneumatik, kan man ikke adskille den programmeringsmæssige beslutning fra anlæggets adfærd efter energibortfald; i sådanne tilfælde skal man også kontrollere de konstruktionskrav, der gælder for hele systemet, og ikke kun korrektheden af applikationskoden.