Hvordan kobles PLC-platforme til den digitale tvilling og virtuel idriftsættelse?

Virtuel idriftsættelse er en metode, hvor maskinens styringslogik testes mod en repræsentativ model af maskinen, før den er færdigbygget og kablet. PLC'en udfører sekvenser, interlocks, modes og HMI-kommandoer, mens den digitale twin repræsenterer maskinens bevægelser, sensorer, materialeflow og operatørkontekst.

Det er sjældent realistisk at skifte PLC-familie midt i et maskinprojekt for at få en bestemt simulationsfunktion. Valget handler derfor om, hvordan den eksisterende PLC-platform kan indgå i et testmiljø med Unity.

B&R, Beckhoff, Siemens og Rockwell adskiller sig i, hvor langt I kommer på en engineering-pc, hvordan runtime kobles til Unity gennem neexo Gateway, og hvornår en fysisk controller stadig er nødvendig til netværk, I/O eller fieldbus. Andre leverandører kan indgå i samme testsystem, hvis deres runtime eller hardware kan udveksle de aftalte signaler.

En PLC-simulation kan teste logik, alarmer og HMI-flows uden en 3D-model. Virtuel idriftsættelse opstår, når PLC-logikken også testes mod en model, der repræsenterer maskinens faktiske adfærd og de signaler, som PLC-programmet forventer.

neexo Gateway er integrationslaget mellem PLC-platformen, andre datakilder og Unity-modellen. Unity håndterer geometri, kinematik, fysik, sensorer, materialeflow og operatørkontekst. Gatewayen håndterer den kontrollerede signaludveksling mellem modellen og automationssystemet.

I praksis læser Gatewayen kommandoer og statusværdier fra PLC'en, oversætter dem til de aftalte datatyper og sender dem til Unity-modellen. Unity-modellen beregner derefter den relevante maskinadfærd og returnerer eksempelvis sensorstatus, positionsfeedback, materialetilstedeværelse eller fejltilstande til PLC'en.

Gatewayen er den dokumenterede kontrakt mellem controls-teamet og teamet bag den digitale twin. Her defineres signalnavne, datatyper, læse- og skriveretning, eventuelle tvungne signaler, kildeprioritet og versionsstyring af mappingen.

Det gør det muligt at koble flere datakilder til samme Unity-model. En maskinsektion kan styres af en fysisk PLC, mens et tilstødende modul kører på en simuleret PLC-runtime. Robotter, databaser, testværktøjer og emuleret eksternt udstyr kan indgå som yderligere kilder, hvis deres ansvar i testsystemet er tydeligt defineret.

Unity-modellen erstatter ikke PLC-logikken. Den repræsenterer processen og maskinens fysiske adfærd, mens PLC-programmet fortsat styrer sekvenser, interlocks og operatørfunktioner.

B&R Automation Studio indeholder Automation Runtime Simulation, ofte kaldet ARsim, samt ACOPOS Simulation til relevante motion-scenarier. Det gør det muligt at afvikle PLC-applikationen og dele af motion-logikken på en engineering-pc, før den fysiske controller og tavle er klar.

ARsim er relevant til tidlig test af sekvenser, alarmer, modes og HMI-logik. Unity-modellen kan i samme forløb repræsentere endestop, sensorfeedback, materialeflow og den rumlige adfærd, som PLC-programmet afhænger af. B&R beskriver ARsim og ACOPOS Simulation som en del af deres modelbaserede udviklings- og simulationsmiljø. Se B&Rs side om modelling and simulation.

neexo Gateway kan koble B&R-applikationen til Unity gennem et projektdefineret interface, eksempelvis PLC-eksponerede data eller B&Rs PVI-grænseflade. I nogle arkitekturer bruges også OPC UA, når PLC-siden stiller de relevante tags til rådighed.

Det afgørende er, at mappingen bygger på den samme autoritative tagliste som PLC-projektet. Signaler for kommandoer, sensorer, aksetilstande, kvitteringer og fejl skal have ét defineret ejerskab. Unity bør kun returnere de signaler, som modellen repræsenterer.

En fysisk B&R-controller er relevant, når testkravet omfatter controllerens konkrete netværksadfærd, fieldbus-konfiguration, fysisk I/O eller kommunikation med eksternt udstyr. ARsim er ofte tilstrækkelig til daglig udvikling og tidlig regressionstest, mens HIL typisk bruges til udvalgte testforløb før virtual FAT eller fysisk FAT.

TwinCAT 3 Usermode Runtime kan afvikle det samme PLC-program på en engineering-pc, uden EtherCAT og uden de deterministiske egenskaber fra en normal realtidsruntime. Det rækker til daglige sekvens-, alarm- og HMI-tests mod en Unity-model. Det rækker ikke, når fysisk EtherCAT-I/O, hardwareafhængige sløjfer eller realtidsadfærd er en del af FAT-risikoen.

Beckhoffs dokumentation for TwinCAT 3 Usermode Runtime beskriver blandt andet engineering-, external-control- og fast-as-possible-scenarier. TwinCAT er velegnet til at køre PLC-sekvenser og HMI-flows sammen med en Unity-model, mens maskinens mekaniske respons simuleres i modellen. Kinematik, sensorer, collision detection og materialeflow skal fortsat modelleres bevidst. Se Beckhoffs produktbeskrivelse af TwinCAT 3 Usermode Runtime.

neexo Gateway kan forbinde TwinCAT og Unity gennem ADS, som er Beckhoffs native kommunikationslag, eller gennem OPC UA, hvis projektet skal eksponere et mere standardiseret interface. ADS er ofte relevant, når Unity-modellen kobles tæt til én TwinCAT-installation. OPC UA kan være mere praktisk, når flere systemer skal læse fra de samme PLC-variabler.

Gatewayen samler signalerne i en fælles mapping, så Unity ikke behøver at kende den konkrete TwinCAT-struktur. Det gør det lettere at udskifte en softwarebaseret runtime med fysisk hardware uden at ændre Unity-modellen eller opbygge mappingen på ny.

TwinCAT 3 Usermode Runtime har ikke adgang til EtherCAT og leverer ikke samme deterministiske egenskaber som en normal realtidsruntime. HIL er derfor relevant, når projektet skal teste fysisk EtherCAT-I/O, hardwareafhængige feedback-sløjfer, konkrete netværkskomponenter eller adfærd, der afhænger af realtid. I et typisk forløb bruges Usermode Runtime til daglige tests, og en fysisk Beckhoff-controller til de testcases, hvor hardware og netværk er en del af risikoen.

Siemens tilbyder S7-PLCSIM og S7-PLCSIM Advanced til softwarebaseret simulation af S7-controlleren. S7-PLCSIM Advanced giver mulighed for flere virtuelle controllere og integration med eksterne test- og simulationsværktøjer.

For mange projekter er PLC- og HMI-simulation et naturligt første trin. Her kan teamet teste sekvenslogik, alarmer, recepter og operatørflows uden at have en færdig maskinmodel. Når Unity kobles på, kan den samme PLC-logik testes mod repræsentative sensor- og procesfeedback fra den digitale twin. Se Siemens' oversigt over S7-PLCSIM Advanced.

neexo Gateway kan kobles til Siemens gennem S7-kommunikation over TCP/IP, S7-PLCSIM Advanced API eller OPC UA, afhængigt af PLC-type, netværksopsætning og den ønskede testarkitektur. Valget bør tage udgangspunkt i, hvilke data der skal udveksles, hvor mange virtuelle controllere der indgår, og om Unity-modellen kører på samme netværk som PLC-runtime-miljøet.

Gatewayen skal gøre grænsen mellem PLC og model tydelig. PLC'en kan sende kommandoer til en transportør eller robotcelle, mens Unity returnerer sensorer, positionsstatus og materialetilstedeværelse. Det skal fremgå af testplanen, hvilke signaler der repræsenterer rigtig maskinadfærd, og hvilke signaler der midlertidigt erstatter udstyr, som ikke indgår i modellen.

HIL med en fysisk Siemens-controller er relevant, når testen omfatter PROFINET-enheder, kommunikation mellem fysiske controllere, fysisk I/O eller kundespecifik netværkskonfiguration. Det samme gælder, hvis der er risiko knyttet til hardwareafhængige moduler eller forbindelser til eksternt udstyr. S7-PLCSIM Advanced er stærkt til tidlig logiktest, men erstatter ikke den fysiske validering af netværk, safety-hardware eller procesudstyr. Unity-modellen kan anvendes i begge situationer, hvis signal mappingen er stabil på tværs af runtime og fysisk PLC.

Rockwell Automation tilbyder FactoryTalk Logix Echo til emulering af Logix-controllere. Det giver mulighed for at teste Logix-applikationer, før den fysiske controller er klar, og er relevant til tidlig afprøvning af sekvenser, alarmer og HMI-logik.

Rockwell har også Emulate3D som en separat 3D-simuleringsløsning. Det kan være relevant at kende i Rockwell-projekter, men en Unity-baseret digital twin kan kobles til Logix-applikationen gennem neexo Gateway uden at være bundet til Rockwells 3D-miljø. Se Rockwells produktbeskrivelse af FactoryTalk Logix Echo.

neexo Gateway kan koble Unity til fysiske eller emulerede Logix-controllere gennem CIP-baseret tagkommunikation over EtherNet/IP eller andre aftalte interfaces i projektet. Gatewayen læser de tags, som PLC-programmet anvender, og udveksler kun de signaler, der er nødvendige for den konkrete maskinmodel.

Det gør det muligt at anvende den samme Unity-model i både et softwarebaseret testforløb og et HIL-setup. PLC-programmet kan bevare sin Logix-struktur, mens Unity-teamet arbejder med en tydelig mapping mellem controller-tags og modellens signaler.

En fysisk Rockwell-controller er relevant, når testkravet omfatter fysisk EtherNet/IP-kommunikation, I/O-moduler, drev, sikkerhedskomponenter eller integration med andet Rockwell- og kundeudstyr. FactoryTalk Logix Echo er et godt udgangspunkt for tidlig test af applikationslogikken, men kan ikke alene dokumentere den samlede hardware- og netværksadfærd.

Software in the loop, ofte forkortet SIL, er normalt det bedste sted at starte. PLC-koden afvikles på en engineering-pc eller i en virtuel runtime, og Unity-modellen returnerer de signaler, som PLC'en forventer fra den fysiske maskine. Det giver korte iterationsforløb, fordi ændringer i PLC-programmet hurtigt kan testes igen.

SIL er særligt relevant til sekvenslogik, interlocks, alarmer, modes, HMI-flows og gentagelige regressionstests. Det er også her, projektet kan opdage fejl i signal mapping, før fysisk hardware og kundetid er involveret.

Hardware in the loop, HIL, anvender en fysisk controller, mens maskinens proces og en del af I/O fortsat repræsenteres digitalt. HIL vælges, når testkravet handler om controllerens konkrete udførelse, netværksforbindelser, fieldbus, hardwareinterfaces eller samspillet med eksternt udstyr.

Mange projekter har gavn af at kombinere de to. SIL bruges i den løbende udvikling, mens HIL bruges til målrettede testcases før virtual FAT. Unity-modellen og neexo Gateway bør være den samme i begge miljøer, så overgangen ikke skaber en ny manuel mapping eller en parallel tagliste.

Tabellen er en teknisk oversigt, ikke en erstatning for en integrationsafklaring. Den konkrete PLC-type, softwareversion, licensmodel, netværksarkitektur og maskinens risikoprofil har betydning for det endelige valg.

Signal mapping er forbindelsen mellem PLC-logikken og værdien af den digitale twin. Hvis et PLC-tag ændrer navn, datatype eller funktion, skal ændringen kunne identificeres og behandles i Unity-projektet. Ellers risikerer teamet at gennemføre et testforløb med signaler, der ser rigtige ud, men ikke længere svarer til PLC-programmet.

Én autoritativ signalkilde bør danne grundlag for både PLC-projektet og Gatewayens mapping. Det kan være en tag-eksport, en struktureret I/O-liste eller en anden kontrolleret projektartefakt. Undgå at vedligeholde en separat kopi af signalerne i regneark, e-mails eller lokale noter. Mappingen bør dokumentere, om et signal læses eller skrives, hvilken datatype det har, hvilken PLC- eller datakilde der ejer signalet, og hvilken del af Unity-modellen der anvender det. Ved flere datakilder skal det også fremgå, hvilken kilde der har prioritet i det aktuelle testforløb.

Maskiner fungerer sjældent isoleret. En pakkemaskine skal måske håndtere signaler fra upstream- og downstream-udstyr, robotter, vision-systemer, transportører eller kundens eksisterende linjestyring. Det er ikke altid relevant eller muligt at modellere hele produktionslinjen. Her kan neexo Gateway samle flere kilder og præsentere dem for Unity-modellen gennem samme strukturerede signalmodel. Et bestået virtual commissioning-scenarie er kun troværdigt, hvis de simulerede svartider, kvitteringer og fejltilstande er realistiske nok til det, der skal verificeres.

Når en PLC-release ændrer en tagstruktur, bør Gatewayen og Unity-modellen give en synlig fejl frem for stiltiende at fortsætte med en ufuldstændig mapping. Det gør afvigelser til et engineering-spørgsmål, der kan løses, før de bliver til et forkert testresultat.

En digital twin gør det muligt at flytte en stor del af testarbejdet frem i projektet, men den erstatter ikke den endelige fysiske validering. Safety-funktioner, sikkerhedscontroller, Performance Level, SIL-krav, elektromekanisk performance og faktiske procesegenskaber skal fortsat verificeres på den rigtige maskine. Det samme gælder mekaniske tolerancer, kabelbevægelser, pneumatisk og hydraulisk respons, produktemnernes reelle variation og procesforhold, som modellen ikke repræsenterer.

Start med de testområder, der udgør den største FAT-risiko: sikkerhedsrelaterede sekvenser, modeskift, kritiske maskincyklusser, centrale HMI-flows og interfaces til andet udstyr. Aftal, hvor detaljeret Unity-modellen skal være, og definér arkitekturen: softwarebaseret runtime eller fysisk hardware, hvordan Gatewayen tilgår controlleren, og hvilke datakilder der indgår. Før kunden inviteres til virtual FAT, bør projektteamet gennemføre en intern generalprøve med PLC-ansvarlig, HMI-operatør, ansvarlig for den digitale twin og testansvarlig.