Pijnlijke herinneringen aan PLC-simulaties

Deze omvangrijke uitspraak uit een proefschrift van de heer Roland Schulz uit 2002 vat het geheel goed samen.

Kortom:"Proberen en testen helpt om fouten te vinden".

Nu schrijf ik hier niet over de simulatie van hele productie-installaties, maar splits het principe verder op in afzonderlijke eenheden (componenten), zoals automatiseringsprogramma's of gebruikersprojecten.

Vroeger moest ik als jonge medewerker bij Phoenix Contact ook leren programmeren en had graag een simulatie van de besturing gehad. Gewoon om via "try and error" meer te weten te komen over de werking en functie van de blokken of programma's. Helaas bestond die toen nog niet en de PLC-simulatie die volgde was zeer beperkt. IEC61131-3-code kon goed worden gesimuleerd, maar het ontbrak de ondersteuning van speciale apparaten of gewoon het verschillende gedrag van code tussen Intel en ARM of op Motorola gebaseerde systemen.

Met deze gedachten in het achterhoofd en de herinneringen aan de pijn die we hadden met de "klassieke" simulatie van een PLC, gingen we op zoek naar echt iets met toegevoegde waarde zonder enorme inspanningen te leveren. Inspanningen enerzijds bij het ontwikkelen van een simulatie en inspanningen die zich later bij het gebruik ervan kunnen voordoen.

Als gebruiker wil ik mijn project naar een PLC of naar een simulatie kunnen sturen, hoogstens met een muisklik. Ik wil geen aandacht besteden aan processorarchitecturen, en ik wil zeker niet gedwongen worden om functies in mijn code te verbergen of, erger nog, te verwijderen die niet door de simulatie worden ondersteund.

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

Tegenwoordig zijn er volwaardige systeememulaties waarmee niet alleen verschillende besturingssystemen onder Windows kunnen worden uitgevoerd. Ze maken ook emulatie van verschillende processorarchitecturen en hun kenmerken mogelijk.

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

In de engineering, in ons geval de 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 kwam er uit die gedachten?

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

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

Alle bijzondere eigenschappen van PLCnext Technology konden echter behouden blijven. Zo kan ik ook mijn C/C++, C# of Matlab Simulink programma's en componenten naar de simulatie sturen. Ook APP's, die ik voor bepaalde applicaties in de Store kan vinden, kunnen zo naar de uitvoering worden gebracht.

Enkele verdere beperkingen liggen voor de hand - determinisme is niet te verwachten van een dergelijk gesimuleerd systeem. En afhankelijk van de belasting van mijn Windows-systeem, kan er een of andere waakhond zijn op de PLCnext-simulatie. Maar in dergelijke gevallen kan ik het simulatieproces altijd een hogere prioriteit geven in het Windows-systeem en dan worden 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 leren programmeren zonder, en nu programmeer ik niet zoveel meer.