Continue integratie drijft op vertrouwen in kwaliteit

Iedereen met een smartphone weet niet beter dan dat er regelmatig updates worden geïnstalleerd voor de apps die op zijn telefoon staan. Het voordeel hiervan is dat de nieuwe mogelijkheden gelijk beschikbaar zijn, eventuele bugs zijn opgelost en dat de smartphone beter is beschermd tegen cybersecurityrisico’s. Om dit voor elkaar te krijgen, hebben de appontwikkelaars een team van software-engineers die gezamenlijk werken aan verbeteringen en waarbij het bouwen, testen en verspreiden van de code in de appstores volledig is geautomatiseerd.

Vergelijk dat eens met de situatie binnen de industriële automatisering. Kunnen we zo maar een wijziging doorvoeren in de code van een productiemachine, medisch apparaat, robotapplicatie of landbouwvoertuig? Dat is helaas niet zo eenvoudig. Veiligheid is hier natuurlijk van een heel andere orde. Bij dit soort applicaties wordt vaak handmatig veel getest en wordt de kwaliteit van de software bepaald door de resultaten die zijn behaald bij de oplevering van het systeem.

En machines of installaties die al in het veld staan? Als hier een verbetering in de code noodzakelijk is, moet een service-engineer of programmeur dat ter plekke doen. En wat voor gevolgen heeft dit voor de rest van de code? Hoe vaak hoor je niet: ‘Vorige week is er iemand langs geweest om de software te wijzigen en nu werkt er iets niet meer. Zal wel aan de nieuwe software liggen.’ Heb jij het vertrouwen dat jouw gewijzigde software op afstand kan worden uitgerold zonder uitgebreide tests op locatie?

Volg de regels

Hoe krijgen de bouwers van die apps dat dan voor elkaar? Ten eerste gebruiken ze de juiste tools voor de applicaties die ze maken. Waarschijnlijk bouwen ze verder op allerlei reeds beschikbare softwareobjecten die ze integreren met hun eigen code. Uiteraard vertrouwen ze erop dat deze bestaande code goed werkt, net als dat een plc-programmeur niet twijfelt aan een standaard functieblok voor een timer.

Wat doen appbouwers nog meer? Ze spreken programmeerregels af. Dat begint met zoiets eenvoudigs als de naamgeving van variabelen, maar loopt door tot standaard templatecode en de automatisch controle van de complexiteit van functies. Daarnaast is het bouwen en het testen van de code volledig geautomatiseerd zodat niet al die honderden of duizenden functies elke keer opnieuw handmatig hoeven te worden gecheckt. Daarmee is er tevens garantie dat er geen regressie optreedt, wat wil zeggen dat een wijziging op een plek van de code geen negatieve invloed heeft op een andere plek in de code.

 advertorial 

RFID-toegangsbeveiliging nu nog makkelijker

Voor Identification and Access Management (I.A.M.) heeft Pilz het bedrijfsmoduskeuze- en toegangsautorisatiesysteem PITmode. Voor een onderdeel van dit systeem, de PITreader, heeft Pilz een RFID-transponder in kaart- en stickerformaat ontwikkeld. Alle varianten zijn vrij beschrijfbaar en rechten kunnen vastgelegd worden door gebruik te maken van de eenvoudig passende softwaretools.

Hoe krijgen we dit voor elkaar binnen de industriële automatisering? Ten eerste zijn de leveranciers van de automatiseringscomponenten een belangrijke schakel. Zij leveren al kant-en-klare bibliotheken met geteste code, voor bijvoorbeeld de aansturing van servodrives. Ook leveren fabrikanten van safetycontrollers gecertificeerde functies en functieblokken mee die gegarandeerd deze veilige status bewaken. Hierbij kun je er dus op vertrouwen dat je die code zonder risico kunt toepassen.

Wat doe je met je eigen gemaakte code? Een mooie trend is dat de Plcopen-organisatie zich hard maakt voor standaardisatie van code. Zodoende krijg je een leidraad die niet alleen leveranciers aanhouden, maar die je ook zelf kunt implementeren. Een standaard functieblok met een standaard interface. Het functieblok bevat een standaard ‘Plcopen state machine’ voor bijvoorbeeld motionapplicaties of safetyfunctieblokken, en ook voor algemene functieblokken is een gestandaardiseerd concept beschikbaar. Een plc-programmeur hoeft deze enkel aan te roepen en het werkt.

Hoe zorg je ervoor dat je eigen code ook daadwerkelijk aan die standaarden voldoet? Daarvoor zijn gelukkig tools beschikbaar. Die helpen je bij het opstellen van de testcode, het automatisch uitvoeren en het rapporteren van de resultaten. Uiteraard kost het maken van deze tests tijd, maar het geeft vertrouwen in de kwaliteit van je software.

Let op de tijd

Om te komen tot continue integratie in de industriële automatisering is het advies om standaard programmeerregels en templates te volgen. Zet deze bijvoorbeeld op met een state model zoals in een UML-statediagram. Controleer de regels met bijvoorbeeld een static analysis-tool waarmee je – naast de standaard compilerchecks – ook automatisch kunt controleren of je je eigen programmeerregels volgt. Voer code reviewing uit zodat boven water komt als je per ongeluk iets over het hoofd hebt gezien. Zet de wijzigingen in een versiebeheersysteem zodat altijd is terug te vinden welke wijzigingen zijn doorgevoerd en je – indien nodig – kunt terugvallen op een vorige versie. En misschien wel het allerbelangrijkste: zorg voor automatische tests.

Zodra je dit voor elkaar hebt, heb je al grote zekerheid dat de code van hoge kwaliteit is. Maar dan ben je er helaas nog niet. Een van de grootste verschillen tussen een industriële applicatie en bijvoorbeeld een app of kantoorsoftware is de factor tijd. Een cnc-machine moet zijn assen cyclisch synchroon aansturen binnen milliseconden. Een hydraulisch systeem moet snel genoeg zijn druk of positie kunnen regelen om niet in een onveilige situatie te belanden. En een robot moet snel kunnen reageren bij detectie van een product dat hij moet oppakken. Ook hier zijn tools voor die de uitvoeringssnelheid van je applicatie bepalen. Deze profilers meten niet enkel de totale cyclustijd, maar ook per functie of methode de benodigde tijd om de code uit te voeren. Dit geeft inzicht in mogelijke risico’s. Indien nodig, kun je er dan voor kiezen om de code te optimaliseren of om een snellere processor te selecteren.

Fix de bug

Als dit voor elkaar is, komt de volgende fase: continuous delivery en continuous deployment. Tussen die twee termen zit een wezenlijk verschil. Zie de delivery als de levering van de code aan de productie. Voor een machinebouwer betekent dit dat altijd de laatste – en dus ook beste – versie van de software beschikbaar is. Ook dit kun je automatiseren via bijvoorbeeld een testmanager, buildtool of script. Als alle tests zijn doorstaan, kun je hiermee automatisch de applicatie laden in de machinecontroller, of beschikbaar stellen op een server waarvandaan productie haar op de machine zet. Zodoende krijg je directe terugkoppeling van de machine als er nog software-issues zijn.

Continuous deployment kan worden bereikt door de applicatie op afstand automatisch te laden in de controllers van machines of installaties op locatie. Nu steeds meer machines aan het internet worden gekoppeld om data te kunnen verzamelen of service op afstand uit te voeren, bestaat die mogelijkheid. Zo kan een bugfix, essentiële verbetering of securitypatch een belangrijke reden zijn om een update door te voeren. En nu je vertrouwen hebt in de kwaliteit van je software, is er geen enkele reden om het niet te doen.