Hvordan kobler man en PLC til en digital twin?

En demo er forholdsvis enkel. En PLC-variabel flytter en cylinder i Unity, nogle signaler skifter tilstand, og forbindelsen ser ud til at være løst. Det svære begynder, når opsætningen skal bruges på en rigtig maskine og leve videre gennem ændringer i PLC-program, mekanik og varianter.

Hvis Unity-modellen kender konkrete OPC UA NodeIds, forbindelsesdetaljer og platformsspecifikke adresser, bliver 3D-applikationen tæt koblet til én bestemt styring. En ændring i PLC-projektet kan så ende som en ændring i Unity-applikationen. Det er ikke en særlig god grænse mellem automation og software.

Fejlsøgning er en anden udfordring. Hvis en ventil ikke reagerer i den virtuelle maskine, skal teamet hurtigt kunne se, om problemet ligger i PLC-logikken, forbindelsen, signalmappingen eller modellen. Hvis hele integrationen er gemt i Unity-koden, bliver supporten let afhængig af den person, der byggede den første version.

For maskinbyggere med flere platforme eller maskinvarianter bliver problemet endnu tydeligere. Siemens, B&R, Beckhoff, Rockwell og robotstyringer har ikke de samme runtime- og integrationsmuligheder. Det giver mere mening at holde de forskelle i et integrationslag end at bygge den digitale twin om til hver controller.

Vi byggede Gateway, fordi den samme integrationsopgave gik igen i vores projekter med digitale twins og virtuel idriftsættelse. En projektspecifik connector kan løse den første maskine, men bliver hurtigt teknisk gæld på den næste.

neexo Gateway er vores produkt til den del af løsningen. Den kører lokalt mellem maskinstyringen og Unity og samler forbindelser, variabler, signalbindinger, runtime-værdier og diagnostik ét sted.

På Unity-siden arbejder vores PowerTools-klient med stabile variabelnavne og ID'er i stedet for rå OPC UA NodeIds. Unity behøver derfor ikke kende alle detaljer om den underliggende PLC-forbindelse. Det giver en renere grænse mellem maskinsoftware og 3D-applikation.

For kunden er værdien ikke endnu en softwarekomponent. Værdien er, at integrationen bliver synlig, vedligeholdelig og nemmere at genbruge i stedet for at være gemt som projektspecifik kode, som kun den oprindelige udvikler forstår.

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 relevante tags, oprette signalbindinger og kontrollere live-værdier. Runtime-delen håndterer den løbende dataudveksling med Unity.

En maskinkonfiguration kan gruppere flere controllerkilder under den samme aktive maskine. Gateway kan forbinde kilderne samlet, mens Unity fortsat arbejder mod det samme realtime-lag. Det er vigtigt på maskiner og linjer, hvor styringen ikke nødvendigvis kommer fra én leverandør.

Gateway har i dag forbindelsesveje 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.

Tag en maskinstation med sensorer, et par servoakser og en sekvens i PLC-programmet. Unity skal ikke vide, hvordan hvert signal adresseres i den konkrete controller. Gateway holder styr på forbindelsen og mappingen, mens Unity arbejder med de signaler, modellen faktisk har brug for.

Gateway har også sin egen diagnostik, runtime-status, lokale logs og værktøjer til at samle relevante supportdata. Den centrale PLC-til-Unity-runtime kører lokalt. Det er mindre synligt end selve 3D-modellen, men det er afgørende, når løsningen skal kunne supporteres 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.

Den første gevinst er tydeligere ansvar. PLC-programmet ejer maskinlogikken. Den digitale twin ejer den virtuelle adfærd og visualisering. Gateway ejer forbindelsen mellem de to.

Det gør dele af løsningen lettere at genbruge på næste maskine. En ny variant kan stadig kræve nye signaler og ny modeladfærd, men teamet starter ikke med at opfinde hele forbindelsen igen. Det samme princip er vigtigt, hvis kunden skifter controllerplatform eller bruger forskellige styringer i samme produktprogram.

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

Der er også en kommerciel gevinst. En digital twin er nemmere at sælge som en reel engineering-leverance, når kunden kan se, hvordan den kobles til den eksisterende maskinsoftware, og hvordan forbindelsen kan drives og supporteres bagefter. Gateway gør den del af leverancen mere ensartet og mindre afhængig af engangskode.

Det er vigtigt for os, fordi neexo ikke kun vil levere en flot 3D-model. Værdien ligger i, at automation, HMI, simulation og den digitale maskinmodel kan arbejde sammen i et setup, som maskinbyggerens egne folk kan forstå.

Ja. Det er en central del af arkitekturen. En maskinkonfiguration i Gateway kan indeholde flere controllerforbindelser, og Gateway kan forbinde kilderne samlet for den aktive maskine. Unity arbejder stadig mod det samme realtime-lag og behøver ikke en særskilt integrationsarkitektur for hver PLC.

Det passer bedre til virkelige maskiner og linjer. En løsning kan have en hoved-PLC, en separat controller til et delsystem og en robotstyring. De behøver ikke komme fra samme leverandør, så længe den enkelte forbindelse kan håndteres af en understøttet connector eller protokol.

Det er sådan uafhængighed af PLC-brand skal forstås: Unity-siden er gjort uafhængig af de konkrete controlleradresser og protokoller. Controllersiden er stadig specifik. Siemens S7, TwinCAT ADS, OPC UA, Logix Echo, Universal Robots og MQTT kræver ikke den samme opsætning, og vi påstår ikke, at enhver PLC er plug-and-play.

For maskinbyggeren betyder det, at den samme Unity-simulering og modelstruktur kan bruges på tværs af blandede styringer og flere maskinvarianter, uden at PLC-leverandørens detaljer flyttes ind i 3D-koden. Signalmappingen skal stadig være korrekt, men integrationsarkitekturen skal ikke opfindes på ny hver gang.

I virtuel idriftsættelse er forbindelsen ikke målet i sig selv. Den skal gøre det muligt at teste den rigtige maskinlogik 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 giver en fast grænse mellem styring og twin. Unity-modellen kan arbejde med variabelnavne og signalbindinger, mens forbindelsen til den konkrete controller håndteres separat. Det er især nyttigt, når et projekt bevæger sig fra tidlig simulation til mere realistiske testopsætninger.

Gateway hænger derfor tæt sammen med vores øvrige arbejde med PLC-integration, motion control, HMI og Unity-baserede digitale twins. Den erstatter ikke de discipliner. Den giver dem et kontrolleret sted at mødes.

Gateway erstatter ikke PLC-engineering. 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 safety-validering 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 skal heller ikke forstås som en universel fieldbus-emulator. Timing, netværksadfærd og hardwareeffekter, som betyder noget på den endelige installation, skal testes i et setup, der kan bevise netop de egenskaber. Emulering er et separat udviklingsspor og ikke det samme produktproblem, som Gateway løser i dag.

Den afgrænsning er bevidst. Vi vil hellere være tydelige om, hvad en digital test kan bevise, end gøre virtuel idriftsættelse til et løfte om, at fysisk idriftsættelse forsvinder.

Gateway er relevant, når en digital twin skal længere end visualisering og arbejde sammen med den faktiske maskinsoftware. Det gælder især, når løsningen skal kunne gentages på flere maskiner, varianter eller projekter, og når kunden selv skal kunne forstå og supportere integrationen.

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

Et godt første spørgsmål er derfor ikke, hvilken 3D-motor I vil bruge. Det er: Hvilke styringer har maskinen, hvilke signaler skal modellen bruge, hvad skal kunne simuleres, og hvad skal stadig bevises på rigtig hardware?

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