Is een REST API altijd geschikt voor de industrie? Wanneer kiest u beter voor wachtrijen, brokers en eventgedreven communicatie?

De vraag of REST API geschikt is voor de industrie gaat vandaag niet meer over een voorkeursstijl voor integratie, maar over de keuze waar een project de kosten, vertraging en operationele verantwoordelijkheid neerlegt. In een industriële omgeving houdt een communicatie-interface al snel op een “technische laag” te zijn en gaat die de continuïteit van het proces, de reproduceerbaarheid van handelingen, de auditmogelijkheden en de manier van reageren op storingen beïnvloeden. REST werkt goed waar we een eenvoudige aanroep, een eenduidig antwoord en duidelijke controle over de status van het verzoek verwachten. Het probleem begint wanneer het systeem moet blijven functioneren ondanks tijdelijke onbeschikbaarheid van een van de betrokken partijen, wanneer berichten met bevestiging moeten worden afgeleverd, of wanneer één gebeurtenis gevolgen moet hebben in meerdere onafhankelijke domeinen. Dan is de keuze tussen een synchrone aanvraag en een wachtrij, broker en eventgedreven communicatie technisch niet langer neutraal.

Juist nu is dat van belang, omdat steeds meer industriële projecten besturing, onderhoud, kwaliteitssystemen, productierapportage en externe diensten samenbrengen in één keten van afhankelijkheden. Als de architectuur uitsluitend op synchrone aanroepen wordt gebaseerd, krijgt het team vaak een systeem dat ogenschijnlijk eenvoudig is, maar kwetsbaar wordt zodra het aantal integraties toeneemt, het netwerk instabiel is of een strikte eventhistorie vereist is. De kosten van zo’n beslissing worden niet zichtbaar tijdens een functiedemo, maar later: in processen die worden geblokkeerd door een onbeschikbare component, in het moeizaam reconstrueren van een incidentverloop, in het handmatig afstemmen van statussen tussen systemen en in discussies over de vraag of een operatie daadwerkelijk is uitgevoerd of alleen is uitgezet. Voor de product owner en de projectmanager is het praktische criterium eenvoudig: er moet worden bepaald of een bepaalde gegevensuitwisseling het karakter heeft van “vraag–antwoord hier en nu”, of eerder van “registreer een feit en zorg voor verdere afhandeling, ook bij verstoringen”. Van dat antwoord hangt niet alleen de technologie af, maar ook het verantwoordelijkheidsmodel tussen teams.

In de praktijk is dat goed zichtbaar in machinesystemen waarin één operatorhandeling of één procesgebeurtenis op meerdere plaatsen moet worden vastgelegd, doorgegeven en bevestigd. Als een toezichthoudende applicatie synchrone verzoeken naar opeenvolgende diensten stuurt en op alle antwoorden wacht, kan een tijdelijk probleem in één onderdeel de hele sequentie stilleggen, terwijl een deel van de bedrijfseffecten onafhankelijk zou moeten optreden. Een broker of wachtrij maakt het daarentegen mogelijk om het moment van acceptatie van informatie los te koppelen van het moment van verwerking, de eventhistorie te behouden en herhaling na een fout eenvoudiger te beheersen. Dat betekent niet dat eventgedreven communicatie altijd beter is: als een onmiddellijke beslissing nodig is die verdere machinebeweging blokkeert, of als de operator direct een bindend antwoord moet krijgen, kan een asynchroon model zonder goed ontworpen tussenstaten de onzekerheid juist vergroten. Daarom is het zinvol om al aan het begin van het project niet alleen de responstijd te meten, maar ook het aantal verloren of gedupliceerde berichten, de tijd die nodig is om afwijkende statussen af te stemmen en de mogelijkheid om de reeks gebeurtenissen na een incident te reconstrueren.

Dit onderwerp raakt vanzelf aan de risicobeoordeling in industriële projecten, omdat de keuze van de communicatiemethode invloed heeft op het gevolg van een fout, de detecteerbaarheid van afwijkingen en de mogelijkheid om doeltreffende risicobeperkende maatregelen in te voeren. Als via de interface functies lopen waarvan een foutieve uitvoering kan leiden tot onbedoeld opstarten, een gevaarlijke toestandsverandering of verlies van controle over energie, dan is het onderwerp niet langer uitsluitend IT-gerelateerd en verschuift het naar het domein van het ontwerp van het machinesysteem en de beoordeling van beschermende maatregelen. Op dat punt komt ook de grens in beeld vanaf waar verwante vraagstukken moeten worden meegenomen, waaronder beveiliging tegen onverwacht opstarten en de praktische risicobeoordeling volgens ISO 12100 volgens de gekozen methodiek. Met andere woorden: de beslissing over REST, een wachtrij of een broker moet niet na een integratiedemo worden genomen, maar op het moment dat het team de gevolgen van een foutief of vertraagd bericht voor het proces, de veiligheid en de verantwoording van handelingen kan benoemen.

Waar de kosten of het risico het vaakst toenemen

De meeste verkeerde beslissingen komen niet voort uit de keuze voor de “verkeerde technologie”, maar uit het inzetten van REST API voor taken waarvoor het niet is ontworpen. In de industrie lopen de kosten op wanneer een vraag–antwoordinterface communicatie moet dragen die gevoelig is voor tijdelijke onbeschikbaarheid, de volgorde van gebeurtenissen of de noodzaak van een betrouwbare uitvoeringsbevestiging. Als het systeem alleen de actuele status van een apparaat moet uitlezen of een opdracht moet aannemen waarvan het uitblijven eenvoudig kan worden gedetecteerd en zonder neveneffecten opnieuw kan worden verzonden, is REST vaak voldoende. Als het resultaat er echter van afhangt of een bericht precies één keer, in de juiste volgorde en met de mogelijkheid om de historie na een incident te reconstrueren is aangekomen, dan overstijgen de kosten om de beperkingen van REST te omzeilen al snel de schijnbare eenvoud van de implementatie. In de praktijk betekent dit extra logica voor herhalingen, eigen buffermechanismen, het afstemmen van afwijkende statussen en een lastigere toewijzing van verantwoordelijkheid wanneer een apparaat een bewerking later dan verwacht of zelfs twee keer heeft uitgevoerd.

In de ontwerpfase lijkt het probleem meestal onschuldig: het team gaat uit van een stabiel netwerk, continue beschikbaarheid van diensten en een eenduidige toestand aan beide kanten van de integratie. In een industriële omgeving houden die aannames zelden lang stand. Er treden verbindingsonderbrekingen op, een apparaat wordt herstart, een tussensysteem krijgt een update of er is simpelweg overbelasting tijdens een productiewissel. Dan begint een architectuur die uitsluitend op synchrone aanroepen is gebaseerd het risico af te schuiven op applicaties en operators. De projectkosten stijgen dan niet alleen door programmeeraanpassingen, maar ook door hersteltests, extra operationele procedures en discussies over welke partij “had moeten weten” dat het verzoek niet was uitgevoerd. Het praktische besliscriterium is eenvoudig: als onbeschikbaarheid van de ontvanger de zender niet mag stilleggen en een bericht veilig moet worden bewaard om later te worden verwerkt, dan moet een wachtrij, broker of eventgedreven communicatie serieus worden overwogen in plaats van puur REST.

Een goed voorbeeld is de integratie van een besturingssysteem met een lijn, waarbij één systeem een receptuurwijziging opdraagt en meerdere andere systemen die wijziging moeten ontvangen, bevestigen en op het juiste moment in de cyclus toepassen. Met REST is een aanroep als “parameters instellen” snel gebouwd, maar het is lastiger te garanderen dat alle betrokken onderdelen dezelfde informatie hebben ontvangen, dat een ouder bericht een nieuwer bericht niet overschrijft en dat na een storing kan worden vastgesteld wie welke opdracht heeft gezien. Een eventbroker of wachtrij ordent dit probleem op een andere manier: het bericht wordt een blijvend feit in het systeem, dat kan worden gevolgd, opnieuw verwerkt en onafhankelijk door meerdere ontvangers kan worden opgehaald. Dit is niet alleen een technische keuze. Hiervan hangt af of bij een klacht over een partij, een stilstand of een incident het verloop van de systeembeslissingen kan worden aangetoond, en dus ook of contractuele, operationele of interne verantwoordelijkheid kan worden toegewezen. Waar traceerbaarheid belangrijk is, is het zinvol niet alleen de responstijd te meten, maar ook het aantal berichten dat opnieuw moet worden verzonden, de tijd die nodig is om de toestand na een storing te synchroniseren en de mogelijkheid om de volgorde van gebeurtenissen te reconstrueren zonder handmatige samenvoeging uit meerdere logboeken.

Dit onderwerp raakt aan risicobeoordeling volgens ISO 12100 zodra een foutief of vertraagd bericht het gedrag van een machine, proces of beschermingsmaatregel kan veranderen. In zo’n geval volstaat de vraag naar het gebruiksgemak van de integratie niet meer; dan moeten het effect, de detecteerbaarheid en de mogelijkheid om de gevolgen te beperken worden beoordeeld, wat aansluit bij de praktijk die bekend is uit ISO 12100. Als de communicatie betrekking heeft op veiligheidsgerelateerde functies, vergrendelingen, startvoorwaarden of bevestigingen van de energietoestand, verschuift de grens van de ontwerpverantwoordelijkheid van applicatieniveau naar het niveau van het volledige machinesysteem. Ook in actuatiesystemen, waaronder hydraulische systemen, kan een onjuiste aanname over tijdige informatieoverdracht botsen met de ontwerpprincipes voor beschermingsmaatregelen en veilige toestanden, wat vanzelf leidt naar vraagstukken die worden geassocieerd met NEN-EN-ISO ISO 4413. Met andere woorden: wachtrijen en brokers zijn niet “per definitie beter”, maar worden de juiste keuze waar een ontwerp bestand moet zijn tegen communicatiestoringen zonder verlies van controle, historie en verantwoordelijkheid voor uitgevoerde handelingen.

Hoe je dit in de praktijk aanpakt

In de praktijk is de vraag niet of een REST API goed of slecht is, maar of die past bij de gevolgen van een fout, vertraging of het uitblijven van een antwoord in een bepaald industrieel proces. Als de communicatie vooral dient voor het uitlezen van gegevens, het starten van administratieve handelingen of integratie met bedrijfssystemen, dan is een request-response-interface vaak de eenvoudigste en goedkoopste oplossing. Het probleem begint wanneer het ontwerp uitgaat van continuïteit van informatie-uitwisseling ondanks tijdelijke onbeschikbaarheid van een van de partijen, de noodzaak van geordende verwerking van gebeurtenissen of de verplichting om te reconstrueren wie, wanneer en op basis waarvan een bepaalde toestandswijziging heeft veroorzaakt. In zo’n situatie verlaagt REST als standaardmechanisme vaak de instapkosten, maar verhoogt het de kosten van storingsafhandeling, toestandsafstemming na een onderbreking en incidentonderzoek. Dat is het moment waarop wachtrijen, brokers en eventgedreven communicatie ophouden een “architectonische toevoeging” te zijn en een middel worden om ontwerprisico en operationele verantwoordelijkheid te beperken.

Voor het team en de manager betekent dit dat een architectuurbeslissing moet worden genomen op basis van enkele meetbare proceseigenschappen, en niet op basis van de voorkeur van de uitvoerende partij. Het meest bruikbare criterium is eenvoudig: er moet worden vastgesteld wat er met een bericht moet gebeuren als de ontvanger op het moment van verzenden niet reageert. Als het juiste antwoord luidt “niets kritisch, de operatie kan veilig opnieuw worden uitgevoerd of verworpen”, dan volstaat REST meestal. Als het bericht daarentegen moet worden bewaard, na hervatting van de werking moet worden afgeleverd, slechts één keer of in een aantoonbare volgorde moet worden verwerkt, dan begint een synchrone architectuur niet meer aan te sluiten op de proceseisen. Het is verstandig dit al in de uitgangspunten vast te leggen als acceptatiecriteria: de toelaatbare duur van onbeschikbaarheid van de partner, de manier van opnieuw verzenden, de regels voor deduplicatie, de mogelijkheid om gebeurteniscorrelaties te volgen en de manier waarop de toestand na een storing wordt hersteld. Zonder zulke afspraken lijkt een project aanvankelijk sneller van start te gaan, maar later keert dit terug in de vorm van kostbare integratiewijzigingen, discussies over de reikwijdte van verantwoordelijkheden en operationele afwijkingen die moeilijk af te sluiten zijn.

Een goed voorbeeld is een lijn of cel waarin het bovenliggende systeem opdrachten doorgeeft en de besturingen en werkstations terugmelden wat is uitgevoerd, welke afkeur is opgetreden, welke blokkades er zijn of wanneer tussen bedrijfsmodi wordt gewisseld. Als elke gebeurtenis direct via REST wordt “opgevraagd”, ontstaat bij een kortstondig verlies van de verbinding al snel een verschil tussen de werkelijke toestand en de toestand die in de applicatie zichtbaar is. Vanuit productie leidt dat tot handmatige afstemming, vanuit kwaliteit tot een gat in de partijhistorie en vanuit onderhoud tot onzekerheid of een bepaald commando daadwerkelijk is uitgevoerd of alleen is verzonden. Een broker met duurzame opslag van berichten lost niet alles op, maar maakt de verantwoordelijkheden wel duidelijker: de zender heeft de gebeurtenis doorgegeven, het tussensysteem heeft die bewaard en de ontvanger heeft die wel of niet bevestigd. Dat is een wezenlijk verschil bij het analyseren van de oorzaken van stilstand en bij het vaststellen of een fout voortkwam uit de proceslogica, een netwerkstoring of een onjuiste volgorde van handelingen door de operator. Juist daarom heeft de keuze voor een communicatiemodel niet alleen invloed op de implementatiekosten, maar ook op de tijd die nodig is voor inbedrijfstelling, service en audit.

Dit onderwerp raakt aan de praktische risicobeoordeling volgens ISO 12100 zodra een bericht niet langer alleen informatie is, maar een voorwaarde wordt voor de werking van een machine, proces of beschermingsmaatregel. Als de mogelijkheid om te starten, het werk na een stop te hervatten, een sequentie vrij te geven of een veilige energietoestand te bevestigen afhangt van de correcte overdracht van een status, dan wordt een integratiebeslissing onderdeel van een zwaarder wegende ontwerpbeslissing. In zo’n geval moet niet alleen de beschikbaarheid van de communicatie worden beoordeeld, maar ook de gevolgen van uitval, vertraging, duplicatie en verkeerde interpretatie; hier komt de methodiek uit ISO 12100 vanzelf in beeld. Waar communicatie raakt aan de voorwaarden voor het voorkomen van onverwacht opstarten, mag de informatielaag bovendien niet worden behandeld als vervanging van oplossingen die bedoeld zijn voor energieafschakeling en een veilige toestand. Dat is de grens waar dit onderwerp al raakt aan de analyse van beveiliging tegen onverwacht opstarten en breder aan het ontwerpen van het machinesysteem dat verder gaat dan alleen functionaliteit. Met andere woorden: REST is geschikt voor de industrie wanneer het proces de beperkingen ervan bewust accepteert; als dat niet zo is, zijn queueingmechanismen en eventgedreven communicatie geschikter, omdat die beter aansluiten op eisen rond continuïteit, traceerbaarheid en beheersing van de gevolgen van storingen.

Waar u bij de implementatie op moet letten

De meest voorkomende fout bij de implementatie is dat de keuze voor REST API of eventgedreven communicatie wordt gezien als een puur technische beslissing, terwijl het in de industrie een beslissing is met operationele en organisatorische gevolgen. REST houdt niet op te werken zodra het op de productievloer wordt ingezet, maar de beperkingen ervan worden wel snel zichtbaar op plekken waar het systeem verbindingsonderbrekingen, ongelijkmatige belasting, tijdelijke onbeschikbaarheid van diensten en de noodzaak om het verloop van gebeurtenissen later te reconstrueren moet kunnen opvangen. Als de architectuur ervan uitgaat dat elk antwoord direct en bij de eerste poging moet binnenkomen, wordt het ontwerp kwetsbaar. Het gevolg is meestal voorspelbaar: de integratiekosten lopen op, er ontstaan steeds meer noodoplossingen en de verantwoordelijkheid voor een onjuiste procestoestand vervaagt tussen de leveranciers van de systemen. Queues en brokers lossen het probleem op hun beurt ook niet automatisch op; zij brengen hun eigen risico’s mee, zoals vertraagde verwerking, dubbele berichten, de noodzaak om sequenties te ordenen en complexere monitoring. De vraag is dus niet of REST altijd geschikt is voor de industrie, maar of een bepaald proces de eigenschappen van deze communicatievorm verdraagt zonder het risico door te schuiven naar productie, onderhoud en compliance.

In de ontwerpfase is het zinvol om een eenvoudig beoordelingscriterium te hanteren: wat gebeurt er precies met het proces als een bericht niet aankomt, twee keer aankomt of te laat aankomt. Als het gevolg alleen een vertraagde verversing van gegevens in een rapportagesysteem is, kan REST voldoende zijn. Als het uitblijven van een antwoord echter een sequentie blokkeert, handmatige interventie afdwingt, leidt tot verlies van de uitvoeringshistorie van een bewerking of het moeilijk maakt om vast te stellen wie op basis waarvan een beslissing heeft genomen, dan begint een synchrone architectuur al tijdens de inbedrijfstelling kosten te veroorzaken. In zo’n situatie brengt communicatie op basis van een queue of broker de verantwoordelijkheden meestal beter in kaart: de zender bevestigt de overdracht, de ontvanger verwerkt in zijn eigen tempo en het team kan achterstanden, herhalingen en fouten volgen. Voor de projectmanager betekent dit dat niet alleen de beschikbaarheid van de dienst moet worden gemeten, maar ook indicatoren zoals de wachttijd van een bericht, het percentage herhalingen, het aantal niet-afgehandelde berichten en de tijd die nodig is om na een incident de gebeurtenishistorie te reconstrueren.

In de praktijk wordt het probleem vooral zichtbaar waar één integratie meerdere rollen tegelijk gaat vervullen. Bijvoorbeeld: het bovenliggende systeem stuurt een opdracht naar een werkstation, ontvangt een bevestiging van uitvoering en legt tegelijk een status vast die bepalend is voor het verdere opstarten van de lijn. Zolang het gaat om de uitwisseling van bedrijfsgegevens, kan een vertraging van enkele seconden acceptabel zijn. Maar zodra hetzelfde communicatiepad invloed krijgt op een uitvoeringsbeslissing in het proces, is het geen neutrale IT-toevoeging meer. Dan vertaalt een verkeerde keuze van het mechanisme zich niet alleen in de kosten van stilstand, maar ook in de verantwoordelijkheid voor de vraag of het systeem voorspelbaar reageert op verlies van verbinding, een herstart van de dienst of een dubbel bericht. Dat is het moment waarop het onderwerp vanzelf overgaat in het gebied van het ontwerpen van het machinesysteem dat verder reikt dan alleen functionaliteit: er moet worden bepaald welke gevolgen van storingen toelaatbaar zijn en welke van de integratielaag moeten worden gescheiden.

Deze grens wordt nog belangrijker zodra de communicatie raakt aan voorwaarden die samenhangen met functionele veiligheid of met risicobeoordeling. Als het voldoen aan een veilige toestand, toestemming om het werk te hervatten, bevestiging van het wegvallen van gevaarlijke energie of een andere beschermende functie afhangt van een correcte gegevensuitwisseling, dan volstaat een goede integratiepraktijk niet. Dan moet duidelijk worden vastgesteld of het betreffende element uitsluitend een informatielaag blijft, of al binnen de reikwijdte valt van het ontwerpen van besturingssysteemelementen die verantwoordelijk zijn voor veiligheidsfuncties. Op dat punt komen de juiste vragen uit het domein van NEN-EN-ISO ISO 13849-1 en de praktische risicobeoordeling volgens ISO 12100 in beeld, maar pas nadat de functie en de gevolgen van een storing zijn gedefinieerd. Voor het team betekent dit dat duidelijk moet worden gescheiden wat via een queue, broker of REST kan worden afgehandeld, en wat niet uitsluitend op algemene communicatie mag worden gebaseerd. Als die grens niet vanaf het begin wordt vastgelegd, komen de kosten later terug in de vorm van ontwerpwijzigingen, discussies bij de oplevering en een beslissingsverantwoordelijkheid die moeilijk te verdedigen is.