Er REST API altid egnet til industrien? Hvornår er det bedre at satse på køer, brokere og hændelsesdrevet kommunikation?

Spørgsmålet om, hvorvidt REST API egner sig til industrien, handler i dag ikke om en foretrukken integrationsstil, men om at beslutte, hvor projektet skal bære omkostningen, forsinkelsen og det driftsmæssige ansvar. I industrielle miljøer ophører kommunikationsgrænsefladen meget hurtigt med blot at være et “teknisk lag” og begynder i stedet at påvirke proceskontinuitet, reproducerbarhed i handlinger, mulighed for audit og måden, man reagerer på fejl. REST fungerer godt dér, hvor man forventer et enkelt kald, et entydigt svar og tydelig kontrol over anmodningens tilstand. Problemet opstår, når systemet skal fungere trods midlertidig utilgængelighed hos en af deltagerne, når meddelelser skal leveres med kvittering, eller når én hændelse skal udløse virkninger i flere uafhængige områder. I sådanne tilfælde er valget mellem en synkron anmodning og en kø, broker eller hændelsesbaseret kommunikation ikke længere teknisk neutralt.

Det er særligt relevant nu, fordi stadig flere industriprojekter forbinder styring, vedligehold, kvalitetssystemer, produktionsrapportering og eksterne tjenester i én samlet kæde af afhængigheder. Hvis arkitekturen udelukkende baseres på synkrone kald, ender teamet ofte med et system, der virker enkelt på overfladen, men som er skrøbeligt, når antallet af integrationer vokser, netværket er ustabilt, eller der stilles krav om et præcist hændelsesspor. Omkostningen ved en sådan beslutning viser sig ikke under en funktionsdemo, men senere: når processer blokeres af en utilgængelig komponent, når det er vanskeligt at genskabe et hændelsesforløb efter en incident, når tilstande mellem systemer må afstemmes manuelt, og når der opstår tvister om, hvorvidt en operation faktisk blev udført eller blot bestilt. For produktejeren og projektlederen er det praktiske kriterium enkelt: Man skal afgøre, om den konkrete dataudveksling har karakter af “spørgsmål–svar her og nu”, eller snarere “registrér et faktum og sørg for den videre håndtering, også ved forstyrrelser”. Svaret på det afgør ikke kun teknologien, men også ansvarsmodellen mellem teams.

I praksis ses det tydeligt i maskinsystemer, hvor én operatørhandling eller én proceshændelse skal registreres, videreformidles og bekræftes flere steder. Hvis en overvågningsapplikation sender synkrone anmodninger til efterfølgende tjenester og venter på det fulde sæt svar, kan et midlertidigt problem i ét element standse hele sekvensen, selv om en del af de forretningsmæssige konsekvenser burde indtræffe uafhængigt. En broker eller en kø gør det derimod muligt at adskille tidspunktet for modtagelse af informationen fra tidspunktet for behandlingen, bevare et spor af hændelsen og lettere styre genforsøg efter fejl. Det betyder ikke, at hændelsesbaseret kommunikation altid er bedre: Hvis der er behov for en øjeblikkelig beslutning, som blokerer maskinens videre bevægelse, eller operatøren straks skal have et bindende svar, kan en asynkron model uden veludformede mellemtilstande øge usikkerheden. Derfor bør man allerede i starten af projektet måle ikke kun svartid, men også antallet af tabte eller dublerede meddelelser, tiden til afstemning af afvigende tilstande og muligheden for at genskabe hændelsessekvensen efter en incident.

Dette tema hænger naturligt sammen med risikovurdering i henhold til ISO 12100 i industriprojekter, fordi valget af kommunikationsform påvirker fejlens konsekvens, muligheden for at opdage uregelmæssigheder og evnen til at indføre effektive risikoreducerende foranstaltninger. Hvis grænsefladen håndterer funktioner, hvor fejlagtig udførelse kan føre til utilsigtet opstart, en farlig tilstandsændring eller tab af kontrol over energi, er emnet ikke længere kun et IT-spørgsmål, men bliver en del af maskinsystemets design og vurderingen af beskyttelsesforanstaltninger. Her opstår også grænsen for, hvornår man skal inddrage beslægtede problemstillinger, herunder beskyttelse mod uventet opstart samt den praktiske risikovurdering efter den valgte metode. Med andre ord: Beslutningen om REST, kø eller broker bør ikke træffes efter en integrationsdemo, men først når teamet kan beskrive konsekvensen af en fejlagtig eller forsinket meddelelse for processen, sikkerheden og sporbarheden af handlinger.

Hvor omkostning eller risiko oftest vokser

De fleste fejlagtige beslutninger skyldes ikke valg af “forkert teknologi”, men at REST API bruges til opgaver, som det ikke er designet til. I industrien stiger omkostningen, når en anmodning–svar-grænseflade skal bære kommunikation, der er følsom over for midlertidig utilgængelighed, rækkefølgen af hændelser eller behovet for en pålidelig bekræftelse af udførelsen. Hvis systemet kun skal læse en enheds aktuelle tilstand eller modtage en kommando, hvor manglende levering let kan opdages og gentages uden bivirkninger, kan REST være tilstrækkeligt. Men hvis resultatet afhænger af, om meddelelsen nåede frem præcis én gang, i den rigtige rækkefølge og med mulighed for at genskabe historikken efter en incident, overstiger omkostningen ved at omgå REST’s begrænsninger hurtigt den tilsyneladende enkelhed i implementeringen. I praksis betyder det ekstra logik til genforsøg, egne mekanismer til buffering, afstemning af afvigende tilstande og vanskeligere placering af ansvar, når en enhed udførte operationen senere end forventet eller udførte den to gange.

I designfasen ser problemet som regel uskyldigt ud: teamet forudsætter et stabilt netværk, konstant tilgængelighed af tjenester og en entydig tilstand på begge sider af integrationen. I industrielle miljøer holder disse antagelser sjældent længe. Der opstår afbrydelser i forbindelsen, enheder genstartes, mellemliggende systemer opdateres, og nogle gange er der blot overbelastning i forbindelse med produktionsskift. I sådanne situationer begynder en arkitektur, der udelukkende bygger på synkrone kald, at skubbe risikoen over på applikationer og operatører. Projektomkostningerne stiger ikke kun på grund af softwarekorrektioner, men også som følge af reproduktionstests, ekstra driftsprocedurer og diskussioner om, hvilken side der “burde have vidst”, at anmodningen ikke blev udført. Det praktiske beslutningskriterium er enkelt: Hvis modtagerens utilgængelighed ikke må standse afsenderen, og meddelelsen skal kunne opbevares sikkert og behandles senere, bør man seriøst overveje en kø, en broker eller hændelsesbaseret kommunikation i stedet for ren REST.

Et godt eksempel er integrationen mellem et overvågningssystem og en linje i produktions- og proceslinjer, hvor ét system bestiller en ændring af en recept, og flere andre skal modtage, bekræfte og anvende denne ændring på det rette tidspunkt i cyklussen. Med REST er det let at opbygge et kald som “sæt parametre”, men det er vanskeligere at sikre, at alle relevante elementer har modtaget den samme information, at en ældre meddelelse ikke overskriver en nyere, og at det efter en fejl er muligt at fastslå, hvem der har set hvilken kommando. En hændelsesbroker eller en kø strukturerer problemet på en anden måde: Meddelelsen bliver et varigt faktum i systemet, som kan spores, genbehandles og hentes uafhængigt af flere modtagere. Det er ikke et valg, der kun er teknisk. Det afgør, om man ved en reklamation på et parti, et stop eller en hændelse kan dokumentere systemets beslutningsforløb og dermed også placere det kontraktmæssige, driftsmæssige eller interne ansvar. Der, hvor sporbarhed og ansvarlighed er vigtig, bør man ikke kun måle svartid, men også antallet af meddelelser, der kræver gentagelse, tiden til at afstemme tilstanden efter en fejl samt muligheden for at genskabe hændelsesforløbet uden manuel rekonstruktion fra flere logfiler.

Dette bliver et spørgsmål om risikovurdering i henhold til ISO 12100, når en forkert eller forsinket meddelelse kan ændre maskinens, processens eller beskyttelsesforanstaltningens adfærd. I et sådant tilfælde er det ikke længere nok at spørge til integrationsbekvemmelighed; man skal vurdere konsekvens, detekterbarhed og muligheden for at begrænse følgerne, hvilket er i tråd med praksis kendt fra ISO 12100. Hvis kommunikationen vedrører sikkerhedsrelaterede funktioner, blokeringer, startbetingelser eller bekræftelser af energitilstand, flytter grænsen for projekteringsansvar sig fra applikationsniveau til niveauet for hele maskinsystemet. Tilsvarende kan en fejlagtig antagelse om rettidig levering af information i aktuatorsystemer, også hydrauliske, være i konflikt med principperne for projektering af beskyttelsesforanstaltninger og sikre tilstande, hvilket naturligt leder videre til emner, der forbindes med DS/EN ISO 4413. Med andre ord er køer og brokere ikke “bedre per definition”, men de bliver det rigtige valg dér, hvor projektet skal kunne modstå kommunikationsfejl uden at miste kontrol, historik og ansvar for de udførte handlinger.

Sådan griber man emnet an i praksis

I praksis er spørgsmålet ikke, om et REST API er godt eller dårligt, men om det passer til konsekvenserne af fejl, forsinkelse og manglende svar i den pågældende industrielle proces. Hvis kommunikationen primært bruges til at læse data, igangsætte administrative handlinger eller integrere med forretningssystemer, kan en request-response-grænseflade være den enkleste og billigste løsning. Problemet opstår, når projektet forudsætter kontinuitet i informationsudvekslingen trods midlertidig utilgængelighed hos en af parterne, behov for ordnet behandling af hændelser eller pligt til at kunne genskabe, hvem der hvornår og på hvilket grundlag udløste en bestemt ændring af tilstanden. I en sådan opsætning sænker valget af REST som standardmekanisme ofte adgangsomkostningen, men øger omkostningerne ved fejlretning, afstemning af tilstanden efter et afbrud og afklaring af en hændelse. Det er det punkt, hvor køer, brokere og hændelsesbaseret kommunikation ophører med at være et “arkitektonisk supplement” og i stedet bliver et værktøj til at begrænse projektrisiko og driftsmæssigt ansvar.

For teamet og manageren betyder det, at den arkitektoniske beslutning skal træffes på grundlag af flere målbare proceselementer og ikke ud fra leverandørens præferencer. Det mest nyttige kriterium er enkelt: Man skal fastlægge, hvad der skal ske med meddelelsen, når modtageren ikke svarer på afsendelsestidspunktet. Hvis det korrekte svar er “intet kritisk, operationen kan sikkert gentages eller afvises”, er REST som regel tilstrækkeligt. Hvis meddelelsen derimod skal bevares, leveres efter genoptagelse af driften, behandles kun én gang eller i en rækkefølge, der kan dokumenteres, begynder en synkron arkitektur at komme på tværs af proceskravene. Det bør allerede i forudsætningsfasen skrives ind som acceptkriterier: den tilladte periode, hvor partneren kan være utilgængelig, metoden for gentagelse, regler for deduplikering, mulighed for at spore hændelseskorrelation og måden, hvorpå tilstanden genskabes efter en fejl. Uden sådanne aftaler kommer projektet tilsyneladende hurtigere i gang, men vender senere tilbage i form af dyre integrationsændringer, tvister om ansvarsomfang og driftsmæssige afvigelser, som er vanskelige at lukke.

Et godt eksempel er en linje eller en celle, hvor det overordnede system sender ordrer, og styringer samt stationer rapporterer udførelse, kassationer, blokeringer eller skift mellem driftstilstande. Hvis hver hændelse straks “forespørges” via REST, opstår der ved selv et kortvarigt tab af forbindelsen meget hurtigt en uoverensstemmelse mellem den faktiske tilstand og den tilstand, der vises i applikationen. Set fra produktionens side ender det med manuel afstemning, set fra kvalitetssiden med et hul i batchhistorikken, og set fra vedligeholdelsens side med usikkerhed om, hvorvidt en given kommando blev udført eller blot sendt. En broker med vedvarende lagring af meddelelser løser ikke alt, men den tydeliggør ansvaret: afsenderen har sendt hændelsen, det mellemliggende system har gemt den, og modtageren har enten bekræftet den eller ikke. Det er en grundlæggende forskel, når årsagerne til et stop skal analyseres, og når det skal afklares, om fejlen skyldtes proceslogikken, et netværksnedbrud eller en forkert operatørsekvens. Derfor påvirker valget af kommunikationsmodel ikke kun implementeringsomkostningerne, men også tiden til idriftsættelse, service og audit.

Dette bliver til et spørgsmål om praktisk risikovurdering i henhold til ISO 12100, når meddelelsen ikke længere blot er information, men en forudsætning for, at maskinen, processen eller beskyttelsesforanstaltningen kan fungere. Hvis muligheden for opstart, genoptagelse efter stop, frigivelse af en sekvens eller bekræftelse af en sikker energitilstand afhænger af korrekt overførsel af status, bliver integrationsbeslutningen en del af en tungere projekteringsbeslutning. I sådanne tilfælde skal man ikke kun vurdere kommunikationens tilgængelighed, men også konsekvenserne af tab, forsinkelse, dublering og fejltolkning; her melder den metodik sig naturligt, som er kendt fra ISO 12100. Derudover må informationslaget ikke behandles som en erstatning for løsninger beregnet til energiafbrydelse og sikker tilstand, når kommunikationen berører betingelserne for at forebygge uventet opstart. Her går grænsen, hvor emnet allerede berører analyse af beskyttelse mod uventet opstart og mere generelt projektering af maskinsystemet ud over den rene funktionalitet. Med andre ord er REST egnet til industrien, når processen bevidst accepterer dens begrænsninger; når den ikke gør det, er kømekanismer og hændelsesbaseret kommunikation mere passende, fordi de bedre opfylder kravene til kontinuitet, sporbarhed og kontrol med konsekvenserne af fejl.

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

Den mest almindelige fejl ved implementering er, at valget mellem REST API og hændelsesbaseret kommunikation behandles som en rent teknisk beslutning, selv om det i industrien er en beslutning med driftsmæssige og organisatoriske konsekvenser. REST holder ikke op med at fungere, bare fordi det bruges i produktionshallen, men dets begrænsninger bliver meget hurtigt tydelige dér, hvor systemet skal kunne absorbere afbrydelser i forbindelsen, ujævn belastning, midlertidig utilgængelighed af tjenester og behovet for senere at kunne genskabe hændelsesforløbet. Hvis arkitekturen forudsætter, at hvert svar skal komme med det samme og i første forsøg, bliver projektet skrøbeligt. Konsekvensen er som regel forudsigelig: integrationsomkostningerne stiger, der opstår flere workaround-mekanismer, og ansvaret for en forkert procestilstand bliver udvisket mellem systemleverandørerne. Omvendt løser køer og brokerløsninger ikke problemet automatisk; de introducerer deres egne risici, såsom forsinket behandling, dublering af meddelelser, behov for at holde styr på rækkefølgen og mere kompleks overvågning. Spørgsmålet er derfor ikke, om REST altid egner sig til industrien, men om den konkrete proces tolererer egenskaberne ved denne kommunikationsform uden at flytte risikoen over på produktion, vedligeholdelse og compliance.

I projekteringsfasen er det værd at anvende et enkelt vurderingskriterium: hvad sker der helt præcist med processen, hvis en meddelelse ikke når frem, når frem to gange eller når frem for sent. Hvis konsekvensen kun er en forsinket opdatering af data i rapportsystemet, kan REST være tilstrækkeligt. Hvis manglende svar derimod blokerer en sekvens, kræver manuel indgriben, fører til tab af historikken for udførte operationer eller gør det vanskeligt at fastslå, hvem der traf en beslutning og på hvilket grundlag, begynder den synkrone arkitektur allerede at skabe omkostninger under idriftsættelsen. I en sådan situation skaber kommunikation baseret på kø eller broker som regel en bedre ansvarsfordeling: afsenderen bekræfter afleveringen, modtageren behandler i sit eget tempo, og teamet får mulighed for at overvåge ophobninger, genforsøg og fejl. For projektlederen betyder det, at man ikke kun skal måle tjenestens tilgængelighed, men også indikatorer som meddelelsens ventetid, andelen af genforsøg, antallet af uafsluttede meddelelser og den tid, der kræves for at genskabe hændelseshistorikken efter en hændelse.

I praksis bliver problemet især synligt dér, hvor én integration begynder at udfylde flere roller på én gang. For eksempel: det overordnede system sender en ordre til en station, modtager en bekræftelse på udførelsen og registrerer samtidig en tilstand, som er afgørende for den videre opstart af linjen. Så længe vi taler om udveksling af forretningsdata, kan en forsinkelse på nogle få sekunder være acceptabel. Men hvis den samme kommunikationsvej begynder at påvirke en udførelsesbeslutning i processen, er den ikke længere et neutralt it-tillæg. Så får et forkert valg af mekanisme ikke kun betydning for omkostningerne ved driftsstop, men også for ansvaret for, om systemet reagerer forudsigeligt ved manglende forbindelse, genstart af en tjeneste eller en dubleret meddelelse. Det er det punkt, hvor emnet naturligt bevæger sig ind i projektering af maskinsystemet ud over den rene funktionalitet: det skal afgøres, hvilke fejlkonsekvenser der kan tolereres, og hvilke der kræver adskillelse fra integrationslaget.

Grænsen bliver endnu vigtigere, når kommunikationen begynder at berøre forhold med betydning for funktionel sikkerhed eller risikovurdering. Hvis opfyldelsen af en betingelse for sikker tilstand, tilladelse til genoptagelse af drift, bekræftelse af bortfald af farlig energi eller en anden funktion med beskyttelsesmæssig betydning afhænger af korrekt dataudveksling, er god integrationspraksis ikke tilstrækkelig. I så fald skal det fastlægges klart, om det pågældende element udelukkende forbliver et informationslag, eller om det allerede falder ind under projektering af styresystemelementer med ansvar for sikkerhedsfunktioner. Her opstår de relevante spørgsmål inden for DS/EN ISO 13849-1 samt praktisk risikovurdering efter den tilgang, der kendes fra ISO 12100, men først efter at funktionerne og konsekvenserne af fejl er blevet defineret. For teamet betyder det, at man skal adskille det, der kan håndteres via kø, broker eller REST, fra det, som ikke må baseres udelukkende på kommunikation til generelle formål. Hvis denne grænse ikke fastlægges fra begyndelsen, viser omkostningen sig senere i form af projektændringer, tvister ved overtagelse og et beslutningsansvar, som er vanskeligt at forsvare.