Benno Beuting is directeur van Cordis Automation, dat op de High Tech Campus besturingssoftware ontwikkelt voor onder meer ASML, Nokia, Philips en VDL.

5 July 2012

Bij de realisatie van machinebesturingen komen vaak dezelfde problemen met dezelfde oplossingen naar boven. Cordis Automation ontwikkelde een ontwerpmethode en softwareplatform om dit te vereenvoudigen. Directeur Benno Beuting van deze campusbewoner deelt een aantal best practices.

Bij de ontwikkeling van apparaatbesturingen valt er op het gebied van kosten, doorlooptijd en kwaliteit nog veel te verbeteren. Bij Cordis Automation zijn we samen met onze partners continu bezig best practices op het gebied van besturingssoftware te verzamelen in een ontwikkelproces en softwareplatform met tools die multidisciplinair debuggen mogelijk maken. Bij die partners zien we een veel kortere ontwikkeltijd en een hoge betrouwbaarheid van hun steeds complexer wordende systemen.

De basis van onze methode is de platformaanpak. We vergelijken dit graag met het ontwikkelproces in de auto-industrie. Die sector gebruikt al decennialang herbruikbare platforms bij het ontwikkelen van nieuwe modellen. Dat heeft gezorgd voor een enorme efficiëntiewinst. Deze manier van werken is tegenwoordig zelfs zo ver doorgevoerd dat verschillende automerken een enkel platform delen.

Een platformaanpak maakt het mogelijk de applicatie los te koppelen van de hardware en het OS. Ook kan de focus komen te liggen op het oplossen van het specifieke besturingsvraagstuk, terwijl de goed geteste en volwassen basisfunctionaliteit off-the-shelf beschikbaar is. Het strikt doorvoeren van deze aanpak in alle fases van het ontwikkelproces (design, realisatie, testen en nazorg) zorgt voor een enorme winst in kosten, doorlooptijd, risicobeperking en betrouwbaarheid.

Door de succesvolle toepassing in de apparatenbouw ontwaakt nu ook de belangstelling bij andere spelers in de maakindustrie. We zijn dan ook altijd op zoek naar partijen die zich willen aansluiten om hun concurrentiepositie te versterken en een bijdrage te leveren aan verbetering van het platform. Maar de best practices die wij in kaart hebben gebracht, gelden voor iedereen die software bouwt voor een apparaat.

Laserunit

Kostenreductie van besturingsoplossingen kan op twee niveaus bereikt worden: de stukskosten zoals de hardware en de softwarelicenties, en de ontwikkelkosten. Wat betreft de hardware zijn er enorme kostenverschillen tussen PLC‘s, (industriële) pc‘s en embedded bordjes met Intel of Arm. Door de snelle ontwikkelingen bij mobiele devices komt er steeds goedkopere embedded hardware beschikbaar met tegelijkertijd enorme verbeteringen in prestaties en functionaliteit. Wat betreft het besturingssysteem valt er te besparen op licentiekosten, bijvoorbeeld door Linux te gebruiken. Vaak kiezen apparatenbouwers om historische redenen voor PLC‘s. We kunnen de trend echter niet negeren van hardwareleveranciers die standaard bordjes op de markt brengen met Linux-ondersteuning en een gegarandeerde levertijd van minimaal vijf jaar.

 advertorial 

The waves of Agile

Derk-Jan de Grood has created a rich source of knowledge for Agile coaches and leaders. With practical tips to create a learning organization that delivers quality solutions with business value. Order The waves of Agile here.

Cordis Platform Explorer
Met de Platform Explorer kunnen niet alleen softwareontwikkelaars maar ook de andere disciplines naar componenten navigeren en de status uitlezen of acties instarten.

Met een softwareplatform is het mogelijk om de applicatie te ontkoppelen van de onderliggende hardware en het OS. Ons eigen softwareplatform ondersteunt zowel PLC‘s, industriële pc‘s als embedded bordjes. In de softwarelaag zijn allerlei standaard ondersteunende mechanismen en patronen opgenomen zoals interfacing tussen architectuurcomponenten, interfacing met gebruikers, afhandeling van commando‘s en argumenten, statemachinegedrag, beveiligingen, storingen, meldingen, machine- en processettings, recepturen, datamonitoring, logging, taalwisseling, datapersistentie en simulatiemogelijkheden. Bedrijfsspecifieke implementaties zijn strikt gescheiden van de het generieke platform zodat de betrokken bedrijven onbelemmerd verbeteringen kunnen delen.

De applicatie is op deze manier ’min of meer‘ onafhankelijk van de onderliggende hardware en software. De implementatietaal (zoals PLC of C#) verschilt, maar de implementatiewijze is op hoofdlijnen gelijk. Voor elk van de ondersteunde besturingssystemen is een versie gemaakt met functioneel gelijke interfaces naar de applicatie.

Voor de implementatie van elk van de componenten, zoals de aansturing van een lift of een laserlasunit, gebruiken we templates. Deze zijn het beste te vergelijken met de templates die organisaties gebruiken voor het maken van tekstdocumenten. Hierin is een hoofdstuk met paragraafindeling gemaakt met ingevulde standaardtekst op specifieke plaatsen. Het doel is dat iedereen binnen de organisatie het document op dezelfde wijze en met dezelfde structuur maakt.

Bij het schrijven van software willen we hetzelfde bereiken. Omdat er een vaste structuur is, wordt het veel gemakkelijker om met meerdere personen samen te werken en werk over te dragen. Het template geeft een structuur en een voorgedefinieerde implementatie van bijvoorbeeld standaard interfaces, commando‘s en argumenten, settings, observers, statemachine-uitvoering en berichten. In de praktijk wordt dit ervaren als een enorm hulpmiddel zonder dat het beperkingen oplegt.

Polarisatie

Als ontwerpfouten pas zichtbaar worden in de eindfase van het project zijn de kosten om ze te herstellen erg hoog. Daarom is het belangrijk om de besturingsoplossing die in de ontwerpfase wordt gekozen te delen met de andere disciplines. Dit maakt multidisciplinaire validatie vooraf mogelijk. Het functionele gedrag moet hiervoor dusdanig beschreven zijn dat het door alle disciplines in het project te begrijpen is en de oplossing gemeenschappelijk kan worden afgestemd. In de praktijk wordt de softwarediscipline pas echt in het project betrokken wanneer dit al is vormgegeven, vaak omdat de organisatie vindt dat dit een taak is voor de (hoofd)constructeur. Op zich is hier natuurlijk iets voor te zeggen; de constructeur is de bedenker van de mechanisatieoplossing.

Cordis Transfer
Cordis ontwikkelde onder meer software om in een zonnecelfabricagelijn producten op een complexe roterende module te plaatsen en er weer af te halen.

Op het moment dat een systeem zo ver is dat er getest kan worden, breekt een dynamische fase aan. De verschillende disciplines moeten allemaal hun eigen activiteiten op de machine uitvoeren en de snelheid van de werkzaamheden is vanaf dat moment sterk afhankelijk van de beschikbare machinetijd. Dat het ontwikkelproces geen watervalmodel moet zijn, wordt breed gedragen. In de praktijk blijkt dit echter nog steeds vaak wel het geval te zijn: het systeem wordt eerst mechanisch opgebouwd, dan elektrisch aangesloten en daarna is het aan de softwarediscipline om het systeem aan de praat te krijgen.

Wanneer dat moment eindelijk aanbreekt, blijken er vaak allerlei systeemproblemen te zijn. De onbekende problemen die tot dan toe verborgen bleven, komen nu naar boven. Dit werkt polarisatie tussen de disciplines in de hand. Het is echter bijna naïef om te denken dat het hoofdzakelijk aan de software ligt als het systeem na de I/O-test nog niet werkt.

Om hiermee om te gaan, is een grote flexibiliteit nodig bij de softwarediscipline. Hardwarematige oplossingen zijn in deze fase duur en kosten veel tijd om te realiseren. Het ligt daarom voor de hand om naar een oplossing in de software te zoeken. Softwareontwikkelaars moeten snel tussenoplossingen kunnen aandragen en op een beheersbare manier aanpassingen doorvoeren.

Ondertussen moeten ze ook de andere disciplines ondersteunen bij het opsporen van fouten, want het aansturen van specifieke componenten voor testdoeleinden gaat doorgaans alleen via een specialistische softwareontwikkelkit. Het elektrisch testen van de sensoren en actuatoren, het in de lucht brengen van het veiligheidssysteem of het analyseren van storingen, overal moet de software-engineer een handje helpen.

Consulterende rol

Een enorme efficiëntieverbetering is daarom te halen met tooling waarmee de andere disciplines dit soort ondersteunende werkzaamheden zelf kunnen uitvoeren. Wij hebben daarvoor een grafische interface ontwikkeld, de Platform Explorer. Die maakt een verbinding met de platformsoftware op de controller en geeft de volledige softwarestructuur van de applicatie in een boomstructuur weer. Deze architectuur wordt door de platformsoftware gepubliceerd. Een gebruiker kan zo naar elk object bladeren en de eigenschappen weergeven en manipuleren, net zoals je met Windows Explorer door mappen naar bestanden kunt bladeren.

Van elk softwareobject – dat een-op-een overeenkomt met een machineonderdeel – worden de beschikbare commando‘s met argumenten getoond en elk object is vanuit de Platform Explorer uit te voeren. Ook kunnen de proces- en machineparameters worden getoond en eventueel gewijzigd en is de status van hardware-inputs en -outputs in te zien. Van storingen en meldingen wordt de status weergegeven en kan de historie worden bekeken. De afloop van het programma (zoals de functionele machineaansturing) kan exact worden gevolgd doordat de actuele en historische status van de statemachines wordt weergeven. Ook van de uitgevoerde commando‘s kan de historie worden ingezien. Dus bij storingssituaties kan worden teruggekeken wat hieraan is voorafgegaan.

De Platform Explorer is als standaard tool beschikbaar voor applicaties die op ons softwareplatform draaien. Dankzij het gereedschap hoeven de softwareontwikkelaars zich veel minder bezig te houden met de ondersteunende activiteiten en krijgen ze veel meer een consulterende rol, net zoals de mechanische constructeurs al hebben.

De tool komt ook van pas bij ondersteuning en onderhoud. Met name bij het verhelpen van storingen is het belangrijk diagnostische gegevens te verzamelen. Hiervoor wordt doorgaans een beroep gedaan op een software-engineer omdat die via de SDK ’van binnenuit‘ toegang heeft tot het systeem.

Door tools waarmee de diagnostische informatie via een eenvoudige grafische omgeving kunnen worden vergaard, ontstaat er een nieuwe situatie waarbij de service-engineer of de eindgebruiker zelf beter in staat wordt gesteld de oorzaak te achterhalen. De openheid, testfunctionaliteit en diagnosetools die de Platform Explorer beschikbaar stelt, gebruiken onze partners ook als salesargument naar hun eindklanten.

Een platformaanpak is lastig toe te passen op bestaande producten en ook voor nieuwe projecten is het introduceren van deze benadering niet eenvoudig wanneer een organisatie er niet mee bekend is. De ervaring leert echter dat een platformaanpak bij de realisatie van apparaatbesturingen resulteert in veel kortere ontwikkeltijden en een hogere betrouwbaarheid. Met flinke kostenreductie als gevolg.

Edited by Pieter Edelman