Leren van PLC Simulatie Uitdagingen: Een Praktische Gids

Deze krachtige stelling uit een dissertatie van dhr. Roland Schulz uit 2002 vat het goed samen.

Kort gezegd: "Proberen en testen helpt om fouten te vinden."

Ik schrijf hier niet over de simulatie van gehele productieinstallaties, maar verbreek het principe verder naar individuele eenheden (componenten), zoals automatiseringsprogramma's of gebruikersprojecten.

In het verleden, als jonge medewerker bij Phoenix Contact, moest ik ook programmeren leren en zou ik blij zijn geweest met een simulator van de controller. Simpelweg om meer te leren over de werking en functie van de blokken of programma's door "trial and error". Helaas bestond dat toen niet en de PLC-simulatie die volgde was erg beperkt. IEC61131-3 code kon goed worden gesimuleerd, maar het miste de ondersteuning van speciale apparaten of simpelweg het verschillende gedrag van code tussen Intel en ARM of Motorola gebaseerde systemen.

Met deze gedachten in gedachten en de herinneringen aan de pijn die we hadden met de "klassieke" simulatie van een PLC, gingen we op zoek naar iets met echte toegevoegde waarde zonder enorme inspanningen. Inspanningen enerzijds in de ontwikkeling van een simulatie en inspanningen die later bij het gebruik ervan kunnen ontstaan.

Als gebruiker wil ik mijn project met één muisklik naar een PLC of naar een simulatie kunnen sturen. Ik wil geen rekening hoeven te houden met processorarchitecten, en ik wil zeker niet gedwongen worden om functies in mijn code te verbergen of, erger nog, te verwijderen die niet worden ondersteund door de simulatie.

Wat ligt er voor de hand dan om de echte firmware in de simulatie te gebruiken, die ook op de echte besturingshardware wordt gebruikt? En dat is precies wat er is gebeurd.

Tegenwoordig zijn er volwassen systeememulaties die niet alleen toestaan om verschillende besturingssystemen onder Windows te draaien. Ze laten ook emulatie van verschillende processorarchitecturen en hun kenmerken toe.

Het is geen geheim dat onze controllers op Linux draaien. Maar het is belangrijk voor de ontwikkeling van code dat hier ook verschillende processorarchitecturen worden gebruikt.

In de engineering, in ons geval PLCnext Engineer, moet de klant kunnen kiezen tussen het IP-adres van de controller of de simulatie - met één muisklik zonder zich zorgen te maken over verdere code-aanpassingen of binaire codecompatibiliteit.

Wat is eruit gekomen?

We vonden de systeememulatie QEMU en gebruiken deze om onze controllers te simuleren. QEMU is een "open source machine emulatie" en biedt precies wat we zochten.

"Gewoon" de firmware erin draaien en QEMU emuleert het complete Linux-systeem van PLCnext Technology, inclusief de ARM-processorarchitectuur van sommige PLCnext controllers - en de PLCnext simulatie was geboren. Toegegeven, we hebben een paar kleine beperkingen opgenomen. PROFINET-communicatie of andere communicatieprotocollen zijn uitgeschakeld. Maar de OPC UA-server is bijvoorbeeld niet beïnvloed.

Echter, alle speciale kenmerken van PLCnext Technology konden worden behouden. Dus ik kan ook mijn C/C++, C# of Matlab Simulink programma's en componenten naar de simulatie sturen. Ook APPs, die ik voor bepaalde toepassingen in de Store kan vinden, kunnen zo naar de uitvoering worden gebracht.

Enkele verdere beperkingen zijn voor de hand liggend - determinisme is niet te verwachten van zo'n gesimuleerd systeem. En afhankelijk van de belasting van mijn Windows-systeem, kan er de een of andere watchdog op de PLCnext simulatie optreden. Maar in dergelijke gevallen kan ik het simulatieproces altijd een hogere prioriteit geven in het Windows-systeem en dan zijn de watchdog-fouten snel opgelost.

En nu heb ik het eindelijk, een simulatie, of misschien zelfs, afhankelijk van de definitie, een emulatie van mijn controller. Maar helaas moest ik programmeren leren zonder het, en nu programmeer ik niet meer zo veel.