Hvordan kobler man en PLC til en digital twin?

En demo med én PLC kan se færdig ud: en variabel flytter en cylinder i Unity, nogle signaler skifter tilstand, og forbindelsen ser ud til at virke. Arbejdet begynder, når opsætningen skal leve videre gennem PLC-ændringer, mekanik og varianter på en rigtig maskine.

Hvis Unity-modellen kender konkrete OPC UA NodeIds, forbindelsesdetaljer og platformsspecifikke adresser, bliver 3D-applikationen bundet til én bestemt styring. En ændring i PLC-projektet ender så som en ændring i Unity. Automation og 3D-applikationen har brug for en tydeligere grænse end det.

Fejlsøgning er det næste problem. Hvis en ventil ikke bevæger sig i den virtuelle maskine, skal teamet kunne se, om fejlen ligger i PLC-logikken, forbindelsen, signaltilordningen eller modellen. Når den viden kun lever i Unity-koden, hænger supporten på den, der byggede den første version.

Maskinbyggere med flere platforme eller varianter ser det hurtigere. Siemens, B&R, Beckhoff, Rockwell og robotstyringer har ikke de samme runtime- og integrationsmuligheder. De forskelle hører hjemme i et integrationslag, ikke i en digital tvilling, der bygges om til hver styring.

Den samme integrationsopgave gik igen i vores projekter med digitale tvillinger og virtuel idriftsættelse. En projektspecifik connector kan få den første maskine i gang og bliver så teknisk gæld på den næste.

neexo Gateway er vores produkt til det lag. Den kører lokalt mellem maskinstyringen og Unity og samler forbindelser, variabler, signaltilordninger, aktuelle værdier og diagnostik ét sted.

På Unity-siden bruger vores PowerTools-klient stabile variabelnavne og ID'er i stedet for rå OPC UA NodeIds. Unity behøver ikke kende alle detaljer om den underliggende PLC-forbindelse. Maskinsoftware og 3D-applikation bliver på hver sin side af et stabilt interface.

For kunden skal integrationen kunne ses og vedligeholdes, så næste maskine kan genbruge den. Projektspecifik kode, som kun den oprindelige udvikler forstår, overlever ikke det skift.

Gateway Cockpit bruges til at sætte maskinforbindelsen op. Her kan man oprette flere forbindelser, gennemse de variabler styringerne stiller til rådighed, vælge tags, oprette signaltilordninger og kontrollere aktuelle værdier. Runtime-delen håndterer den løbende dataudveksling med Unity.

En maskinkonfiguration kan samle flere PLC-forbindelser under den samme aktive maskine. Unity arbejder så mod ét realtidsinterface i stedet for en særskilt integration for hver PLC, robot eller simulator. Det betyder noget på maskiner og linjer, hvor styringen ikke kommer fra én leverandør.

Gateway har i dag connectors til blandt andet OPC UA, Siemens S7 og PLCSIM Advanced, Beckhoff TwinCAT ADS, FactoryTalk Logix Echo, Universal Robots og MQTT. De enkelte forbindelser har ikke nødvendigvis samme valideringsniveau mod fysisk hardware, så vi skelner mellem implementeret funktionalitet og det, der er verificeret på en rigtig installation.

Gateway har også diagnostik, status, lokale logs og værktøjer til at samle supportdata. Runtime mellem PLC og Unity kører lokalt. Den er mindre synlig end 3D-modellen, men det er den, I har brug for, når løsningen skal kunne driftes efter den første demo.

Gateway kan pakkes som en lokal Windows-komponent sammen med en Unity Digital Twin. Den kan startes som del af løsningen og kan også køre som Windows Service ved mere permanente installationer.

Ansvaret bliver tydeligere. PLC-programmet ejer maskinlogikken. Den digitale tvilling ejer den virtuelle adfærd og visualisering. Gateway ejer forbindelsen mellem de to.

Dele af opsætningen kan så følge med til næste maskine. En ny variant kan stadig kræve nye signaler og ny modeladfærd, men teamet opfinder ikke hele forbindelsen igen.

Dialogen mellem automation, software og mekanik bliver også mere konkret. Man kan se forbindelsen, variablen og den aktuelle værdi i stedet for at spørge, om Unity får de rigtige data. Det forkorter vejen fra et symptom til den del af systemet, der skal undersøges.

Der er også en kommerciel side. En digital tvilling er nemmere at sælge som en del af maskinleverancen, når kunden kan se, hvordan den kobles til den eksisterende maskinsoftware, og hvordan forbindelsen kan drives bagefter.

Det, neexo skal levere, er en opsætning, hvor automation, HMI, simulation og den digitale maskinmodel kan arbejde sammen, og som maskinbyggerens egne folk kan forstå.

En aktiv maskinkonfiguration kan samle flere PLC-forbindelser, også fra forskellige leverandører, så længe hver forbindelse har en understøttet connector.

Det passer til, hvordan mange maskiner og linjer er bygget. En løsning kan have en hoved-PLC, en separat styring til et delsystem og en robotstyring. De behøver ikke komme fra samme leverandør.

Uafhængighed af PLC-brand betyder her, at Unity-siden ikke afhænger af de konkrete adresser og protokoller. Styringssiden er stadig specifik. Siemens S7, TwinCAT ADS, OPC UA, Logix Echo, Universal Robots og MQTT kræver ikke den samme opsætning, og ikke enhver PLC er plug-and-play.

For maskinbyggeren kan den samme Unity-simulering og modelstruktur bruges på tværs af blandede styringer og flere maskinvarianter. Signaltilordningen skal stadig være korrekt. Integrationsarkitekturen skal ikke opfindes på ny hver gang.

I virtuel idriftsættelse findes forbindelsen, så den rigtige maskinlogik kan testes mod en model, der reagerer på en kontrolleret og forståelig måde.

Når PLC'en sætter et output, skal den virtuelle maskine reagere. Når en simuleret sensor skifter tilstand, skal PLC-programmet få det relevante input tilbage. Hvis en sekvens stopper, skal teamet kunne se både styringens tilstand og den virtuelle maskines respons.

Gateway lægger en fast grænse mellem styring og tvilling. Unity-modellen kan arbejde med variabelnavne og signaltilordninger, mens forbindelsen til den konkrete styring håndteres separat. Det hjælper, når et projekt bevæger sig fra tidlig simulation til mere realistiske testopsætninger.

Gateway hænger sammen med vores øvrige arbejde med PLC-integration, motion control, HMI og Unity-baserede digitale tvillinger. De discipliner skal stadig have deres egen udvikling. Gateway er det sted, de mødes.

Gateway erstatter ikke PLC-udvikling. Den retter ikke et dårligt sekvensdesign, og den kan ikke gøre en model mere korrekt end den adfærd og de data, der er bygget ind i den.

Den erstatter heller ikke validering af sikkerhed eller fysisk idriftsættelse. Interlocks og sikre tilstande kan testes som logik, men den rigtige maskine skal stadig verificeres med det faktiske sikkerhedsudstyr, mekanik, sensorer og installation.

Gateway er heller ikke en universel feldbusemulator. Timing, netværksadfærd og hardwareeffekter, som betyder noget på den endelige installation, skal testes i en opsætning, der kan bevise netop de egenskaber. Emulering er et separat udviklingsspor fra det produktproblem, Gateway løser i dag.

Gateway er relevant, når en digital tvilling skal arbejde sammen med den faktiske maskinsoftware, ikke kun visualiseringen. Det hjælper mest, når løsningen skal kunne gentages på flere maskiner, varianter eller projekter, og når kunden selv skal kunne forstå og drive integrationen.

Den kan indgå i en leverance med virtuel idriftsættelse, en Unity Digital Twin eller et udviklingsforløb, hvor automation og software arbejder parallelt. I de projekter bruger vi Gateway som et neexo-produkt, ikke som skjult intern kode.

Start med maskinen, ikke 3D-motoren: Hvilke styringer har den, hvilke signaler skal modellen bruge, hvad skal kunne simuleres, og hvad skal stadig bevises på rigtig hardware?

Derfra kan vi tegne grænsen mellem styringerne, Gateway og den digitale tvilling, før integrationen bliver en dyr eftertanke.