In een eerder blog beschreven we hoe Git een belangrijke stap is richting professionele PLC-softwareontwikkeling. Door broncode centraal op te slaan, ontstaat meer controle over wijzigingen, betere samenwerking en volledige traceerbaarheid. Inmiddels zien we dat deze manier van werken ook bij machinebouwers steeds meer zijn intrede doet. Daarnaast maken steeds meer PLC-fabrikanten hun ontwikkeltools geschikt voor het gebruik van Git. 

Maar Git hoeft niet het eindpunt te zijn. De volgende stap is om Git als startpunt te gebruiken voor een grotendeels geautomatiseerd ontwikkelproces. 

Door de ontwikkelstraat rondom PLC-software te automatiseren, kunnen veel terugkerende werkzaamheden zonder handmatige tussenkomst worden uitgevoerd. Denk aan het controleren en compileren van software, het genereren van documentatie, het samenstellen van release notes en het voorbereiden van een nieuwe release. 

Engineers houden daardoor meer tijd over voor het ontwikkelen en verbeteren van machinefunctionaliteit. Tegelijkertijd ontstaat een vast proces waarin wijzigingen worden gecontroleerd, gereviewd en vrijgegeven. 

Van wijziging naar nieuwe softwareversie 

Binnen onze eigen ontwikkelstraat begint een softwarewijziging met een work item. Daarin beschrijft een engineer waarom een aanpassing of uitbreiding nodig is, eventueel aangevuld met uitleg en documentatie. 

Vervolgens maakt de engineer vanuit de development code, vanaf de git server, een eigen branch: een werkkopie waarin de aanpassing wordt ontwikkeld en getest. Zodra het werk klaar is, wordt via een pull request gevraagd om de wijzigingen samen te voegen met de developmentcode. 

Vanaf dat moment neemt de automatisering een deel van het proces over. Op de server wordt de code gecontroleerd op syntaxfouten. Als de code door deze controle komt, volgt een review door een tweede engineer. Die kan opmerkingen bij de wijzigingen plaatsen, waarna de eerste engineer deze verwerkt. 

Pas als alle opmerkingen zijn verwerkt en de tweede engineer de wijziging heeft goedgekeurd, wordt de code automatisch samengevoegd met de development code. Vervolgens wordt daarvan een nieuwe versie gebouwd en intern beschikbaar gesteld. 

Zo is kwaliteitscontrole niet alleen iets wat aan het einde van een project plaatsvindt. Iedere wijziging doorloopt dezelfde stappen voordat deze onderdeel wordt van de gezamenlijke software. 

Van development naar release 

Niet iedere wijziging wordt direct een officiële release. Het team bepaalt wanneer een nieuwe releaseversie wordt gemaakt, bijvoorbeeld nadat aanpassingen eerst op een testmachine hebben gedraaid. 

Ook daarbij wordt dezelfde gecontroleerde werkwijze gevolgd. Een engineer geeft aan welke wijzigingen vanuit de development versie moeten worden meegenomen naar de release. Een tweede engineer controleert en keurt dit goed. 

Na die goedkeuring wordt automatisch een proces gestart dat de geselecteerde wijzigingen overneemt in de releaseversie. Vervolgens wordt de nieuwe release gebouwd en beschikbaar gesteld. Ook werkzaamheden rondom de release worden automatisch uitgevoerd. Zo worden onder andere de versienummering en documentatie bijgewerkt en worden release notes aangemaakt. 

Het resultaat is een reproduceerbaar proces waarin iedere release op dezelfde manier tot stand komt en achteraf terug te vinden is welke wijzigingen erin zijn opgenomen. 

Documentatie groeit mee met de software 

Vrijwel iedere organisatie kent het probleem van documentatie die achterloopt op de software. Niet omdat het belang ervan wordt onderschat, maar omdat het bijwerken ervan vaak een handmatige stap is die gemakkelijk wordt vergeten. 

Binnen de geautomatiseerde ontwikkelstraat wordt de documentatie daarom automatisch bijgewerkt. Wordt er bijvoorbeeld een nieuwe functie aan de software toegevoegd, dan wordt deze ook opgenomen in de bijbehorende documentatie. 

Het naslagwerk waarin wordt uitgelegd hoe functies werken, blijft daardoor aansluiten op de softwareversie die daadwerkelijk wordt gebruikt. Dat is niet alleen handig tijdens de ontwikkeling, maar ook bij service, onderhoud en toekomstige uitbreidingen. 

Eén verbetering beschikbaar voor meerdere projecten 

Automatisering wordt nog interessanter wanneer projecten volgens een vaste structuur worden opgebouwd. Binnen het Gain Standard Beckhoff Framework (GSBF) werken we daarom met een vaste architectuur en projectstructuur. 

Dat maakt het mogelijk om veel software tussen projecten te hergebruiken. Denk bijvoorbeeld aan software voor het aansturen van een motor. De basis daarvan is voor verschillende projecten hetzelfde. 

Voorheen werd zulke software vaak uit een bestaand project gekopieerd en binnen een nieuw project verder ontwikkeld. Een verbetering die daar werd gemaakt, kwam vervolgens niet automatisch terecht in andere projecten. Zeker wanneer meerdere projecten parallel liepen, moesten zulke wijzigingen handmatig worden overgenomen. Daardoor konden verschillende versies van dezelfde functionaliteit ontstaan. 

Binnen GSBF worden verbeteringen centraal doorgevoerd. Een wijziging in het framework is daardoor beschikbaar voor nieuwe projecten die met een volgende release van het framework worden opgebouwd. Ook bestaande installaties kunnen eenvoudiger worden bijgewerkt door een nieuwe release van de gebruikte GSBF-libraries in het machineproject te laden. 

Van één verbetering naar meerdere machines 

Dat voordeel wordt duidelijk bij een machinebouwer met meerdere machines in het veld. Een deel daarvan kan al langere tijd in productie zijn, terwijl andere machines nog worden getest. 

Tijdens die testfase komen soms fouten of mogelijke verbeteringen naar voren. Als zo’n verbetering onderdeel wordt van een nieuwe release van de libraries, kan deze vervolgens ook in andere machineprojecten worden toegepast. Daarvoor hoeft niet opnieuw handmatig dezelfde wijziging in verschillende projecten te worden aangebracht. 

De engineer laadt de laatste release van de libraries in het betreffende machineproject en kan de bijgewerkte software vervolgens naar de machine downloaden. In veel gevallen kan dat volgens onze huidige werkwijze zelfs op afstand. 

Zo wordt het eenvoudiger om verbeteringen die tijdens één project ontstaan ook beschikbaar te maken voor andere machines die dezelfde functionaliteit gebruiken. 

De volgende stap: automatisch testen 

Een groot deel van onze ontwikkelstraat is inmiddels geautomatiseerd. Eén onderdeel dat we op dit moment nog niet toepassen, is het geautomatiseerd functioneel testen van PLC-code. 

Daarbij wordt niet alleen gecontroleerd of code technisch correct kan worden verwerkt, maar ook of de werking na een wijziging nog klopt. Bij een eenvoudige berekening zou een automatische test bijvoorbeeld na iedere aanpassing kunnen controleren of dezelfde invoer nog steeds het verwachte resultaat oplevert. 

Voor PLC-software waren hiervoor lange tijd weinig geschikte oplossingen beschikbaar. Inmiddels heeft Beckhoff hier tooling voor ontwikkeld, maar binnen onze huidige ontwikkelstraat maken we daar nog geen gebruik van. 

Het laat wel zien waar verdere automatisering naartoe kan groeien. Naast compilatie, reviews, documentatie en releasebeheer kunnen in de toekomst ook steeds meer softwaretests en andere kwaliteitscontroles onderdeel worden van hetzelfde proces. 

Een investering die zich blijft herhalen 

Het opzetten van een geautomatiseerde ontwikkelstraat vraagt in eerste instantie tijd. De winst zit vervolgens niet alleen in één snellere release, maar vooral in alle handelingen die daarna niet telkens opnieuw handmatig uitgevoerd hoeven te worden. 

Bij iedere volgende wijziging en iedere volgende release wordt hetzelfde proces opnieuw gebruikt. En doordat projecten binnen GSBF volgens een vaste structuur zijn opgebouwd, kan die werkwijze over meerdere projecten worden toegepast. 

Daarmee verschuift de rol van Git naar build en test server. Het is niet langer alleen de plek waar verschillende versies van broncode worden beheerd, maar het startpunt van een ontwikkelproces waarin wijzigingen gecontroleerd, gereviewd, samengevoegd, gedocumenteerd en uiteindelijk vrijgegeven worden. 

Voor machinebouwers en system integrators levert dat een ontwikkelproces op dat minder afhankelijk is van losse handmatige stappen. Engineers kunnen zich meer richten op de software zelf, terwijl rondom iedere wijziging een vaste werkwijze wordt gevolgd. 

Git bracht versiebeheer naar PLC-softwareontwikkeling. De volgende stap is automatiseren wat daarna gebeurt. 

~Marco Conrads 

Geplaatst: november 2026