MQTT, OPC UA eller direkte kommunikation med PLC – hvordan vælger man den rette model til dataudveksling i et industriprojekt?

Valget mellem MQTT, OPC UA og direkte kommunikation med PLC er ikke længere en rent teknisk beslutning. I dag påvirker det valg samtidig systemarkitekturen, omkostningerne ved idriftsættelse, leverandørernes ansvarsområde og tempoet i godkendelsesforløbet. I praksis handler det ikke om, hvilken protokol der er “bedst”, men om hvilken model for dataudveksling der passer til projektets reelle funktion: om der er behov for enkel integration af signaler fra én maskine, overvågning af en linje, dataudveksling med overordnede systemer eller måske distribueret styring, som skal videreudvikles i de kommende år. En fejl på dette trin viser sig som regel ikke med det samme i laboratoriet, men senere: under opstart, ved validering, ved skift af PLC-leverandør eller når vedligeholdsafdelingen forsøger at finde årsagen til en forstyrrelse og det viser sig, at data er inkonsistente, forsinkede eller uden kontekst.

Set fra projektets side er det mest risikable at vælge kommunikationsmodel “af vane”. Direkte kommunikation med PLC kan være fristende, fordi den giver hurtig adgang til registre og ofte forkorter den første fase af implementeringen. Men et sådant valg binder let den overordnede applikation til en bestemt controller, hukommelsesadressering og producentens implementeringsmåde. Ved ændring af programversion, hardwaremigrering eller udbygning af linjen kommer omkostningen tilbage i form af omarbejdning, regressionstest og diskussioner om ansvaret for procesdata. MQTT fungerer til gengæld godt dér, hvor let distribution af information og adskillelse mellem afsendere og modtagere er vigtig, men det kræver en bevidst definition af datasemantik, leveringskvalitet og principper for drift af brokeren. OPC UA vælges ofte som et kompromis mellem interoperabilitet og informationsstruktur, men heller ikke det løser problemerne af sig selv: hvis datamodellen er dårlig, vil formelt korrekt kommunikation stadig føre til forkerte driftsmæssige beslutninger.

Det praktiske beslutningskriterium er enkelt, selv om det ofte overses: man skal først fastlægge, om den pågældende udveksling vedrører information, styring eller en funktion, der påvirker maskinens driftssikkerhed. Hvis kanalen udelukkende bruges til overvågning, rapportering eller overførsel af recepter i en kontrolleret tilstand, kan løsningerne sammenlignes ud fra vedligeholdelse, skalerbarhed og integration. Hvis der derimod via samme vej skal sendes kommandoer, som påvirker bevægelse, arbejdssekvens, spærringer eller udstyrets klarstatus, er emnet straks ikke længere kun et IT-spørgsmål. Så skal man ikke kun vurdere forsinkelse og transmissionspålidelighed, men også forudsigeligheden af systemets adfærd ved tab af forbindelsen, efter genstart af systemet, efter ændring af softwareversion og ved fejlagtig fortolkning af status fra et eksternt system. Det er det punkt, hvor problemstillingen naturligt glider over i praktisk risikovurdering for designbeslutninger, og nogle gange også i området sikring mod uventet opstart.

Et typisk eksempel fra produktionsvirksomheder ser ofte sådan ud: I begyndelsen er målet kun at læse data fra maskinen til visualisering eller et rapporteringssystem, så teamet vælger en hurtig forbindelse direkte til PLC’en. Efter nogle måneder bruges den samme kanal til at skrive indstillinger, kvittere alarmer og senere også til fjernbetjente servicekommandoer. Formelt fungerer systemet stadig, men arkitekturen svarer ikke længere til det reelle ansvar. Det er ikke længere klart, hvilket lag der er den autoritative kilde til maskinens status, hvem der har ansvaret for autorisation af ændringer, og hvordan det kan dokumenteres, at ekstern kommunikation ikke skaber en vej til utilsigtet opstart. Her opstår der ikke kun spørgsmål om protokollen, men også om fordelingen af funktioner mellem styrings-, overvågnings- og sikkerhedslaget samt, i scenarier med direkte kommunikation til PLC, om konsekvenserne for det elektriske lag og forbindelserne i maskinen.

Den normative og overensstemmelsesmæssige betydning af dette valg opstår derfor, når modellen for dataudveksling påvirker maskinens adfærd i normal drift og ved fejltilstande. Ikke enhver integration falder straks ind under kravene til sikkerhedsfunktioner, men enhver bør vurderes med hensyn til konsekvenserne af fejl, tab af kommunikation og en forkert handlingssekvens. Hvis det via en ekstern grænseflade er muligt at ændre maskinens tilstand, frigive en spærring, genoptage en cyklus eller omgå den logik, der er forudsat lokalt, skal kommunikationsbeslutningen kobles til risikovurderingen og i relevante tilfælde også til kravene om forebyggelse af uventet opstart. Derfor kræver dette emne en beslutning nu, på stadiet for forudsætninger og arkitektur, og ikke først ved idriftsættelsen. Det er netop dér, man stadig kan fastlægge målbare kriterier: hvem der ejer datamodellen, hvad den acceptable konsekvens af tab af forbindelsen er, hvor mange integrationspunkter der skal vedligeholdes efter et PLC-skift, og hvordan det dokumenteres, at kommunikationen ikke flytter ansvar uden for systemets planlagte omfang.

Hvor omkostninger eller risiko oftest vokser

De fleste problemer skyldes ikke selve valget mellem MQTT, OPC UA og direkte kommunikation med PLC, men at kommunikationens rolle i maskinens eller anlæggets arkitektur bliver defineret forkert. Projektet begynder at blive dyrere, når en kanal, der var tænkt til udveksling af hjælpedata, pludselig kommer til at bære driftsmæssige beslutninger, som proceskontinuitet, udstyrets tilstand eller operatørens handlinger afhænger af. I praksis betyder det, at teamet implementerer en løsning, som ser billigere og hurtigere ud, men senere må supplere med omveje: ekstra hardwaresignaler, lokale spærringer, undtagelser i styringslogikken, særskilte mekanismer til kvittering og gendannelse af tilstand efter tab af forbindelsen. Det er netop disse sene korrektioner, der skaber omkostninger, forsinkelser og uenighed om ansvaret mellem integratoren, softwareleverandøren og slutbrugeren. Et praktisk vurderingskriterium er enkelt: Man skal afklare, om systemet ved tab af kommunikation blot skal “holde op med at rapportere”, eller om det kan gå i en farlig tilstand, en procesteknisk forkert tilstand eller en produktionsteknisk dyr situation.

I modeller baseret på direkte kommunikation med PLC stiger risikoen typisk dér, hvor interfacet bliver afhængigt af en bestemt producent, softwareversion og styringens hukommelsesstruktur. Ved idriftsættelsen fungerer det ofte fint, men omkostningen viser sig ved udskiftning af styringen, modernisering af linjen eller tilkobling af endnu et overordnet system. Hver sådan ændring kræver ny datamapping, verifikation af typer, adresser, rettigheder og adfærd ved transmissionsfejl. Set fra produktejerens side er det væsentligt, fordi vedligeholdelsen ophører med at være forudsigelig: dokumentationen bliver hurtigt forældet, viden bliver hos leverandøren, og ansvaret for datakorrekthed bliver spredt. Hvis teamet ikke kan pege på en ejer af datamodellen samt en procedure for ændring af den efter en PLC-opdatering, er omkostningen ved fremtidig integration allerede bygget ind i projektet, selv om den endnu ikke er synlig.

Ved MQTT og OPC UA er den mest almindelige fejl en anden: Man antager, at kommunikationslaget i sig selv løser problemet med datasemantik og pålideligheden af beslutninger. MQTT er velegnet til at transportere hændelser og telemetri, men uden en omhyggelig definition af emner, leveringskvalitet, retention og identifikation af kilden er det let at ende i en situation, hvor modtageren får data, der formelt er korrekte, men ubrugelige eller forsinkede i forhold til processen. OPC UA strukturerer til gengæld informationsmodellen og gør interoperabilitet lettere, men implementeringen bliver ofte undervurderet, hvis udstyret ikke har en ensartet forberedt struktur for objekter, tilstande og metoder. Et praktisk eksempel opstår ved recepter, batchkvittering eller fjernoptagelse af en cyklus: Hvis det ikke er entydigt defineret, hvilken part der kvitterer for modtagelse af kommandoen, hvilken der kvitterer for udførelsen, og hvilken der kun registrerer den i loggen, er det efter den første hændelse svært at påvise, om fejlen opstod i applikationslaget, kommunikationslaget eller i maskinens logik. Et godt beslutningskriterium er her ikke protokollens “moderne” karakter, men om det er muligt entydigt at beskrive tilstanden, kommandoens kilde, gyldighedsbetingelserne og måden, arbejdet gendannes på efter en forstyrrelse.

En særskilt kilde til omkostninger er at blande driftskrav sammen med krav til sikkerhed og overensstemmelse. Hvis man via MQTT, OPC UA eller direkte adgang til PLC kan påvirke maskinens bevægelse, frigivelse af spærringer, opstartssekvensen eller parametre med beskyttelsesmæssig betydning, er emnet ikke længere kun et IT-spørgsmål. Her glider problemstillingen naturligt over i en praktisk analyse af kommunikationens konsekvenser for maskinsikkerheden i projekteringsbeslutninger: Det er ikke selve protokollen, der skal vurderes, men konsekvenserne af en forkert kommando, forældede data, uautoriseret ændring af indstillinger og uoverensstemmelser mellem lokal og ekstern tilstand. I aktuatorsystemer, også hydrauliske, kan kommunikationsvalget påvirke, hvordan funktioner til stop, aflastning, bevægelsesspærring og sikker tilbagevenden til drift realiseres, og det kan derfor være knyttet til de projekteringskrav, der anvendes ved overensstemmelsesvurdering. Hvis det eksterne interface begynder at påvirke beskyttelsesfunktioner eller adfærd, som operatøren opfatter som en del af sikkerheden, skal det behandles som et element i sikkerhedsarkitekturen og ikke som et bekvemt integrationstillæg.

Set fra projektstyringens synspunkt er den sikreste beslutning den, som ikke kun kan forsvares teknisk, men også organisatorisk. Derfor er det værd at fastlægge nogle målbare kriterier, før modellen for dataudveksling vælges: tiden til genetablering af korrekt drift efter tab af forbindelsen, antallet af steder hvor datamapping skal vedligeholdes, måden informationsmodellen versionsstyres på, omfanget af regressionstest efter ændring af PLC samt dokumentation for, at ekstern kommunikation ikke omgår lokale beskyttelsesmekanismer. Når svarene på disse spørgsmål er uklare, bevæger projektet sig som regel allerede ind i et område, hvor selve kommunikationsbeslutningen bør omfattes af en mere formel risikovurdering og i nogle anvendelser også koordineres med projekteringskrav vedrørende aktuatorer og spærringsforanstaltninger. Det er det punkt, hvor valget mellem MQTT, OPC UA og direkte kommunikation ikke længere handler om tekniske præferencer, men bliver en beslutning om vedligeholdelsesomkostninger, ansvarsgrænser og hele løsningens robusthed over for fejl.

Hvordan man griber emnet an i praksis

I praksis bør valget mellem MQTT, OPC UA og direkte kommunikation med PLC ikke tage udgangspunkt i teknologien, men i spørgsmålet om, hvilken driftsmæssig effekt dataudvekslingen skal skabe, og hvem der har ansvaret for resultatet. Hvis data udelukkende bruges til overvågning, rapportering eller til at forsyne overordnede systemer, vil prioriteten være en integration, der er robust over for ændringer, og en tydelig informationsmodel. Hvis der derimod på den anden side optræder kommandoer, som påvirker cyklusforløb, recepter, driftstilstande eller betingelser for opstart, er beslutningen ikke længere kun et IT-spørgsmål. Så påvirker kommunikationsformen allerede ansvarsgrænsen mellem integratoren, maskinproducenten, vedligeholdelsen og procesejeren. Det har direkte konsekvenser for projektet: et andet omfang af accepttest, anden ændringsdokumentation, en anden skala af regression efter ændringer i styreprogrammet og en anden vedligeholdelsesomkostning efter idriftsættelse.

Et godt beslutningskriterium er, hvor kilden til sandheden om maskinens tilstand og logikken for tilladelse til drift skal ligge. Direkte kommunikation med PLC kan være berettiget dér, hvor enkelhed i eksekveringsvejen, få mellemled og fuld forudsigelighed i styringens adfærd er afgørende. Prisen er som regel en stærk binding af løsningen til et konkret PLC-program, en bestemt dataadresse og praksis hos én leverandør. OPC UA er et fornuftigt valg, når projektet kræver en mere stabil datamodel, bedre adskillelse mellem applikationslaget og styreprogrammet samt større tydelighed i signalernes semantik. MQTT egner sig især, når data skal distribueres til mange modtagere, ud over en enkelt relation mellem system og styring, og når en indirekte kommunikationsmodel er acceptabel. Det er dog ikke et neutralt valg: jo flere mellemlag, brokerlag, oversættere og mappinger, desto større er fejlfladen, og desto vanskeligere er det at dokumentere, at en ændring på integrationssiden ikke bryder med de forudsætninger, der er lagt til grund for den lokale styring.

En typisk projekteringsfejl er, at teamet vælger en model, som er bekvem for integrationen under idriftsættelsen, og først senere opdager vedligeholdelsesomkostningen. Et praktisk eksempel: Et overordnet system skal gemme recepter og skifte driftstilstand på flere stationer. Hvis dette løses ved direkte skrivning til PLC’ens hukommelsesområder, vil løsningen i starten være hurtig, men enhver ændring i styringens datastruktur vil udløse test på begge sider af interfacet, og ansvaret for konsistensen i recepterne vil begynde at flyde ud. Hvis samme tilfælde i stedet baseres på entydigt definerede objekter og tilstande på OPC UA-siden, bliver det lettere at adskille ændringer i maskinprogrammet fra ændringer i systemet på højere niveau, men informationsmodellen og dens versionsstyring skal vedligeholdes. Brug af MQTT i et sådant scenarie giver derimod først mening, når der reelt er behov for distribution af data til flere systemer, og når styringen af forsinkelser, leveringsbekræftelse og genskabelse af tilstand efter tab af forbindelse er beskrevet og verificeret i test. Ellers køber teamet sig til en fleksibilitet, som det ikke får brugt, og står tilbage med flere ekstra fejlpunkter.

Det er også her, emnet naturligt glider over i en praktisk risikovurdering af projektbeslutninger. Hvis kommunikationskanalen kan ændre maskinens tilstand, frigive en sekvens, genoptage driften efter tab af forbindelse eller indirekte påvirke aktuatorer, skal man ikke kun vurdere transmissionens pålidelighed, men også konsekvenserne af en forkert eller forsinket kommando. I nogle anvendelser berører dette allerede kravene til sikring mod utilsigtet opstart, fordi selv en teknisk korrekt integration ikke må skabe en omgåelsesvej uden om lokale spærringer eller procedurer for afbrydelse af energi. Inden for dette område bør valget af kommunikation koordineres med styrearkitekturen, det elektriske lag og reglerne for softwareændringer og ikke træffes som en selvstændig integrationsbeslutning. Set fra en managers perspektiv betyder det en enkel regel: Modellen for dataudveksling er kun den rigtige, hvis det kan dokumenteres, hvem der godkender ændringen, hvordan en sikker tilstand genskabes efter en fejl, og hvilke KPI’er der skal måles efter implementeringen, for eksempel tid til genetablering af drift, antal hændelser efter ændringer samt antal steder, hvor datamapping vedligeholdes.

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

Ved implementering er det ikke selve valget mellem MQTT, OPC UA og direkte kommunikation med PLC, der skaber den største risiko, men de skjulte antagelser, som teamet lægger til grund uden formel bekræftelse. I projektpraksis er de dyreste situationer dem, hvor modellen for dataudveksling vælges til en funktionsdemonstration og ikke til den reelle driftsform, vedligeholdelse og ansvarsfordeling ved ændringer. MQTT implementeres ofte med den antagelse, at det blot skal bruges til enkel overførsel af data til overordnede systemer, hvorefter det efter nogle måneder begynder at bære operationelle kommandoer. OPC UA vælges som en “universel” løsning, men uden at det fastlægges, hvilke tjenester, datamodeller og rettighedsmekanismer der faktisk skal bruges. Direkte kommunikation med PLC virker som den korteste vej, indtil det viser sig, at hver ny datamodtager kræver særskilt mapping, regressionstest og afstemning med leverandøren af styringen. For en manager har det en enkel konsekvens: Implementeringsomkostningen slutter ikke, når forbindelsen er etableret, men strækker sig over hele cyklussen af ændringer, fejl og tekniske godkendelser.

Det vigtigste beslutningsspørgsmål bør derfor ikke være “hvad kan vi sætte i drift hurtigst”, men “hvor ophører ansvaret for dataenes betydning og konsekvenserne af deres anvendelse”. Hvis kommunikationen udelukkende bruges til overvågning af processen, vil vurderingskriterierne være andre, end hvis den samme kommunikationsvej skal påvirke recepter, driftsparametre, spærringer eller styresekvenser. Her glider emnet naturligt over i en praktisk risikovurdering af designbeslutninger: man skal ikke kun vurdere sandsynligheden for tab af forbindelse, men også om en forkert værdi, en forsinket opdatering eller en tvetydig mapping af en variabel kan medføre fejlagtig funktion af maskinen eller linjen. Hvis svaret er ja, er kommunikationsarkitekturen ikke længere kun et integrationsspørgsmål. Den bliver et element, der påvirker styrefunktionen, godkendelsen af anlægget og integratorens ansvar ved sammenkobling af delsystemer.

I praksis ses det tydeligt i et enkelt scenarie: et overordnet system skal læse statusser fra flere styringer, og efter idriftsættelsen beder brugeren desuden om fjernændring af indstillinger. Ved kommunikation direkte med PLC ender det ofte med, at der tilføjes flere registre, undtagelser og workarounds, som afhænger af den konkrete producent. I MQTT er problemet ofte tab af entydighed: meddelelsen kommer frem, men uden en klart defineret kontekst ved modtageren ikke, om værdien er aktuel, bekræftet, og hvilken driftstilstand den stammer fra. I OPC UA er faldgruben ikke selve protokollen, men en alt for optimistisk antagelse om, at informationsmodellen på enhedssiden svarer til det, som den overordnede applikation kræver. Derfor bør det praktiske vurderingskriterium omfatte tre forhold: hvem der ejer dataenes semantik, hvordan værdiernes gyldighed og aktualitet bekræftes, og hvordan ændringsproceduren ser ud efter idriftsættelse. Hvis teamet svarer generelt eller leverandørafhængigt på et af disse spørgsmål, betyder det, at omkostningen ved fremtidige ændringer netop er blevet flyttet til vedligeholdelsesfasen.

En særskilt faldgrube er at undervurdere de fysiske og installationsmæssige konsekvenser. I projekter, hvor valget af model for dataudveksling påvirker placeringen af mellemudstyr, ekstra strømforsyning, kabelføring eller netværksopdeling, begynder emnet at gribe ind i projekteringen af det elektriske lag og forbindelserne i maskinen. Det gælder især løsninger med ekstra kommunikationsgateways, industrielle computere eller switche, som i dokumentationen ser uskyldige ud, men som i styretavlen betyder plads, køling, beskyttelse, service og yderligere fejlpunkter. I sådanne tilfælde kan kommunikationsbeslutningen ikke adskilles fra detailprojektet. Teamet bør kunne redegøre for, hvad der sker ved strømsvigt i mellemudstyret, hvordan kommunikationstilstanden genskabes, og om fejl i transmissionslaget ikke skaber et tvetydigt billede af maskinens tilstand for operatøren eller det overordnede system.

Henvisningen til krav om overensstemmelse opstår først, når dataudvekslingskanalen påvirker styrefunktionen, måden maskinen anvendes på eller grænserne for ansvar mellem leverandører. Inden for dette område er det ikke nok at fastslå, at protokollen er “industriel” eller almindeligt anvendt. Det skal påvises, at den valgte arkitektur er vurderet i konteksten af forudsigelige fejltilstande, driftsmæssige ændringer og grænseflader mellem delsystemer, hvilket i praksis fører til en metodisk risikovurdering i overensstemmelse med projektets fastlagte omfang. Hvis systemet sammensættes af standardmoduler, styringer og kommunikationslag fra forskellige parter, øges også betydningen af en formel placering af integratorens ansvar. Det er som regel det tidspunkt, hvor det er værd at sætte projektet på pause og kontrollere ikke kun skemaet for dataudveksling, men også grænserne for ændringer efter godkendelse, reglerne for validering af ændringer samt vedligeholdelses-KPI’er: tiden til genetablering af kommunikation, antallet af hændelser efter opdateringer og antallet af grænseflader, der kræver manuel mapping.