Kennismaking met ADD-Controls.
De firma ADD-Controls ontwerpt en fabriceert elektronica voor industriële toepassingen. Een groot deel hiervan bestaat uit machinebesturingen. Voorbeelden hiervan zijn: een besturing voor een vacumeermachine, deurbesturingen en liften. Wij zijn gevestigd in Amersfoort. Wij hebben een team van 5 mensen die zich reeds 15 jaar bezighouden met het ontwikkelen van elektronica op klantenspecificatie. Onze klanten bestaan voor het grootste gedeelte uit bedrijven met een mechanische achtergrond, en met veelal beperkte kennis van elektronica. Wij proberen dan ook alle facetten van een ontwikkelproject voor de klant te organiseren. Dit omvat onder meer ook het begeleiden van keuringen, testen van het product service en co-ontwerp. Veel machines worden tegenwoordig bestuurd m.b.v. een PLC. Dit is standaard apparatuur die door personeel van de machinebouwer kan worden geprogrammeerd en relatief goedkoop is. Om verschillende redenen kan een machinebouwer toch besluiten een besturing met een dedicated product te realiseren. Men kan bijvoorbeeld slechts een beperkte inbouwruimte hebben, men kan bezorgd zijn over de mogelijkheden voor derden om de besturing te kopiëren en de ook kunnen er speciale eisen worden aan de besturing, die met standaard producten niet kunnen worden gehonoreerd. Het ontwerpproces verloopt meestal volgens een vastomlijnd traject: 1)opstellen van de specificaties
- van de klant - normering - onze eigen spec's
2) ontwerp hardware + software 3) realisatie van proto's 4) verificatie/validatie van het ontwerp Ad normering: Sinds 1997 zijn machineontwerpers gehouden zich te houden aan de 'machinerichtlijn'. Dit is een E.G.richtlijn met kracht van wet. De machinerichtlijn verwijst ontwerpers naar de EN954. Deze norm geeft ontwerpprincipes voor veiligheidsfuncties van machines. Er wordt geëist dat er een risico beoordeling wordt gemaakt. Het ontwerp van de machine moet zo worden uitgevoerd, dat de veiligheid gewaarborgd is. 1
Behalve aan de machinerichtlijn is men ook gebonden aan de productnorm(en). In principe is voor elk product (of productgroep) een norm aanwezig waarin de voor dat product geldende eisen zijn opgenomen. Diegene die het product in verkeer brengt is verantwoordelijk voor de juiste toepassing van wettelijke eisen en normen. Dit zal in de meeste gevallen de machinebouwer zijn. Die moet dan ook een z.g. technisch dossier aanleggen waarin de toepassing van de regels voor een bepaalde machine is vastgelegd. Ter verduidelijking: De door AC gebouwde besturingen zijn erg klein. D.w.z. de systemen hebben een gering aantal in- en outputs; de programma's beslaan niet meer dan 8 kB.Er wordt gebruik gemaakt van z.g. single chip controllers. Op een chip zijn alle componenten tezamen gebracht : programmageheugen, datageheugen, ALU en peripherals. Het gebruik van deze componenten is noodzakelijk om de ontwikkeltijd beperkt te kunnen houden. Verificatie.
Het belang van correct werkende software in machinebesturingen is evident. Dit belang wordt nog duidelijker als de machine een veiligheidsgerelateerde toepassing heeft. Zo kan het falen van de software in een deurbesturing leiden tot een letterlijk knellende ervaring. Wat is echter "correct"in dit verband? De klant en de ontwikkelaar kunnen hier zeer verschillend over denken terwijl In de normen ook niet eenduidig is vastgelegd wat "correct" is. Het zal in elk voorkomend geval veel vakmanschap en ervaring van de ontwikkelaar vragen om de gevoelsmatige definities van correctheid in de praktijk om te zetten en te toetsen. De aard van "embedded sytems" maakt, dat het testen van de software extra aandacht verdient. Men zou graag de toestand van het systeem willen kennen en de veranderingen t.g.v. de veranderde inputsignalen willen monitoren. Door de beperkte in- en uitvoermogelijkheden van een embedded systeem is dit niet (simpel) te realiseren.
2
In de huidige praktijk wordt de correctheid gecontroleerd m.b.v. een emulator. Dit apparaat vervangt fysiek de controllerchip en is gekoppeld met een p.c. Door de emulator wordt de werking van de chip in real-time nagebootst. Het programma kan op willekeurige plaatsen worden gestopt en gestart. Door het invoegen van "breakpoints" kan de programma flow worden onderzocht en de inhoud van de registers en i/o variabelen kan worden uitgelezen en aangepast. De emulator is een zeer veelzijdig apparaat en heeft vele voordelen. Behoudens een enkele uitzondering is de hele functionaliteit van de chip in real-time verifieerbaar. Het wijzigen van het programma m.b.v. de emulator is zeer snel realiseerbaar, zodat in korte tijd aanpassingen kunnen worden gemaakt. Helaas heeft de emulator ook grote nadelen. De apparatuur is vrij duur en complex. Voor elke chip is tevens een andere emulator noodzakelijk, hetgeen de investering extra groot maakt. Het belangrijkste nadeel is echter de testtijd. Elke testvector moet handmatig worden aangebracht en gechecked, waardoor de testtijd vaak onhanteerbaar lang wordt.Dit probleem wordt stringenter wanneer de besturing complexer wordt. Een belangrijke parameter daarbij is het aantal koppelingen (met andere chips, p.c.. etc) dat de besturing moet onderhouden. In het geval van een systeem met meerdere stations, die gekoppeld zijn met een bus, wordt het emuleren een schier hopeloze aangelegenheid. Alternatieve methoden. De onvrede over het werken met de emulator heeft ons ertoe gebracht alternatieve methoden te zoeken. De gedachten gaan dan allereerst in de richting van een meer automatische manier van het genereren van testvectoren. Helaas bleek al snel dat dit geen haalbare kaart was. Het is niet eenvoudig zinvolle testvectoren te verzinnen. Daarbij is door de aard van het "embedded systeem" de testvector niet eenvoudig aan te brengen. Dit kost relatief veel dure hardware die bovendien productgebonden en dus meestal niet herbruikbaar is. Een andere mogelijkheid vormt simulatie. Hiervoor gelden echter vergelijkbare bezwaren. De hardware wordt nu vervangen door software, die per product moet worden vervaardigd. Het testen van deze sofware leidt tot een cirkelredenering.
3
Formele verificatie.
Een 3-de mogelijkheid wordt gevormd door formele verificatie (FV). Ac heeft tezamen met het centrum voor Wiskunde en Informatica In Amsterdam geparticipeerd in een STW project om een beter beeld te krijgen van de mogelijkheden van FV in onze systemen. We hebben een model gemaakt van één van onze besturingen en dit model is door het CWI getest op een aantal eigenschappen. Een van de proposities die onderzocht zijn was: is het systeem deadlock vrij? Hierbij wordt eigenlijk meteen het verschil met emulatormethode zichtbaar. Zelfs voor een simpele toestandsmachine is het bijna onmogelijk m.b.v.trial and error (emuleren) vast te stellen of het systeem deadlockvrij is. Het blijk echter dat ook voor FV al snel de grens van het haalbare( verifiëerbare ) bereikt is. Voor de praktische toepassing is tevens de beschikbaarheid van voldoende computerfaciliteiten een probleem. In onze optiek wordt echter de grootste hinderpaal gevormd door de noodzaak een model te maken van het systeem. In feite wordt de ontwerper verplicht Het systeem meerder malen te ontwerpen. Bij het genoemde onderzoek speelde dit nauwelijks een rol, omdat er al een bestaand systeem was. Hiervan hebben we onderzocht wat het effect was van geplande verbeteringen. Het bedenken van een model dat kan worden gebruikt voor FV behoort op dit moment zeker niet tot de bekende technieken van software ontwikkelaars. Ik hoop echter dat deze problematiek kan worden ondervangen, wanneer er een koppeling kan worden gemaakt, direct van het programma ( bijv. in C) naar een verificatie tool. Er zijn momenteel al ideeën (mogelijkheden?) in die richting. Onze verdere evaluaties zullen zeker in die richting verder gevoerd worden. Een andere mogelijkheid om de toepassing van FV te verruimen ligt in de mogelijkheid proposities en toestandsmachine op elkaar af te stemmen.
4
Tenslotte. FV vormt zeker een waardevolle uitbreiding van de gereedschappen van de ontwikkelaar van embedded producten. De praktische toepasbaarheid is echter nog beperkt. Het zou zeker in het kader van stimulering van de toepassing van embedded systemen passen om extra aandacht, tijd en geld, te besteden aan de ontwikkeling hiervan.
5
