Sharing IT Best Practices with youSharing IT Best Practices with you
Embedded Software
De afgelopen jaren heeft embedded software zich een plaats verworven in steeds meer producten. Enerzijds producten welke oorspronkelijk zonder elektronica werden bestuurd, zoals bijvoorbeeld horloges, en anderzijds producten die zonder elektronica niet mogelijk zouden zijn, zoals bijvoorbeeld draadloze telefoons. De eerste elektronische besturingen in producten werden uitgevoerd met analoge elektronica (denk aan timers). Hierna kwamen digitale schakelingen, opgebouwd met standaard logische schakelingen. Met de komst van de microprocessor en de microcontroller werden steeds meer functies in software gerealiseerd.
Eén van de producten die door de microprocessor mogelijk werden is de Personal Computer (PC). Voor PC’s wordt over de gehele wereld software ontwikkeld en men kan steeds verschillende software laden, terwijl wijzigingen (updates) eenvoudig zijn uit te voeren.
Dat in steeds meer producten ook “computers” zitten, waarin embedded software de functionaliteit bepaalt is voor de gebruikers van deze producten niet zichtbaar en ook niet van belang: het product moet gewoon functioneren zoals verwacht en het is de gebruiker om het even of dit mechanisch, elektronisch of door middel van kabouters gebeurt. De software die de functionaliteit van de elektronische besturing in producten bepaalt is eigenlijk geen echte software meer: het wordt onderdeel van de hardware. Er zijn duidelijke verschillen tussen de “vluchtige” software in computers en de “bevroren” software in producten. Om dit verschil aan te duiden wordt deze laatste wel aangeduid met de term “embedded software”. In navolging van deze term is voor de besturingselektronica in producten de term “embedded systems” ontstaan.
Een Embedded System is een elektronische besturing welke in een product is ingebed, en daarmee een onveranderlijk deel van dat product en zijn functionaliteit is geworden.
Onder Embedded Software verstaan we software (instructies voor een computerarchitectuur, welke stap voor stap worden uitgevoerd) in het embedded system, welke alleen bedoeld is om de hardware zijn voor het product vastgelegde taak te doen uitvoeren en welke door de gebruiker van het product niet is te veranderen.
In Personal Computers komen we ook embedded software tegen, zoals bijvoorbeeld in de BIOS, in de harddiskdrive, in de toetsenbord-processor (in de PC) en in de processor in het toetsenbord.
Embedded systems komen we zo langzamerhand overal tegen. In calculators, telefoons, spelcomputers, televisies, audio-apparatuur, camera’s, kamerthermostaten, koortsthermometers, magnetron-ovens, wasmachines, auto’s, kopiëermachines, modems, printers, harddisks, vliegtuigen, raketten, satellieten, telefooncentrales… te veel om op te noemen. Reeds lang voordat de term Embedded Systems werd uitgevonden werden ze al overal toegepast. Embedded systems kunnen bestaan uit:
Dit is een zeer diverse verzameling. De overeenkomst is het feit dat embedded systems door middel van embedded software tot leven komen.
Overigens kan men in embedded systems ook weer embedded systems tegenkomen: een modem-chip is een embedded system (met microcontroller en DSP functies), sommige AD-conversie chips hebben een processor aan boord die intern voor de gebruiker onzichtbare code uitvoert, een grafische LCD display module heeft ook een microcontroller die de opdrachten voor het display uitvoert.
Embedded systems worden opgebouwd uit elektronische componenten: IC’s, transistoren, weerstanden, condensatoren, spoelen, trafo’s, connectors en dergelijke. Het gegevensverwerkende deel wordt bepaald door één of meer IC’s. Vroeger ontwierpen we nog systemen opgebouwd uit standaard digitale IC’s. Eerst waren dit TTL (Transistor-Transistor Logic) IC’s, later vergelijkbare functies in CMOS. Tegenwoordig worden deze standaard functies nauwelijks meer gebruikt en worden de functies van de specifieke toepassing gerealiseerd in programmeerbare hardware en met behulp van microcomputer structuren. In het eerste geval wordt de hardware op een chip permanent geprogrammeerd in een speciale configuratie. In het tweede geval wordt de hardware met een daartoe geëigende architectuur door elke instructie geherconfigureerd. In beide gevallen wordt uitgegaan van universele bouwstenen en wordt de functie van de bouwsteen bepaald door een vastgelegde (embedded) programmering.
De volgende bouwstenen komen we zoal tegen:
Bij de hiervoor genoemde microprocessor, microcontroller en DSP is een algemene eigenschap dat een opgeslagen lijst van instructies sequentiëel wordt uitgevoerd. Bij embedded systems noemt men deze lijst met instructies de embedded software. Daarnaast bestaat er nog programmeerbare hardware, waarvoor de algemene term Programmable Logic Device (PLD) wordt gehanteerd. Uit marketingoverwegingen worden door de fabrikanten van de PLD’s allerlei verschillende benamingen bedacht zoals PAL, GAL, EPLD, FPGA, SPGA, PASIC, … De essentie is echter dat tussen de aansluitpinnen van een universeel gefabriceerd IC logische functies kunnen worden geconfigureerd en dat dit door de gebruiker (de fabrikant van het product en niet de IC fabrikant) kan worden gedaan.
Wat dit laatste betreft is er ook weer niet zo’n groot verschil tussen PLD’s en microcontrollers: in beide gevallen wordt door de productontwerper de functie gedefinieerd en syntactisch (in een of andere programmeertaal) beschreven, gecompileerd (vertaald naar het specifieke device) en in het device geprogrammeerd.
Wanneer voor een product een specifiek IC wordt ontworpen, dat vervolgens door de chipfabrikant kant en klaar voor de toepassing van één klant wordt gefabriceerd, dan spreekt men over een Application Specific Integrated Circuit (ASIC).
Deze naamgeving is altijd enigszins arbitrair: Een Mask-Programmed Microcontroller, waarin door de chipfabrikant het door de toepasser ontwikkelde embedded software programma wordt vastgelegd, zou men volgens deze laatste definitie ook een ASIC kunnen noemen, terwijl ook een geprogrammeerde PLD een application specific integrated circuit is geworden. Voor een goede communicatie is het echter belangrijker om met een eenmaal gekozen naam een duidelijk omschreven structuur aan te geven dan dat de naam exact aangeeft wat de structuur doet. Net als niet iedereen die Timmerman heet een timmerman is of iedereen die Janssen heet een zoon van Jan hoeft te zijn. Een modem chip, welke de aansluiting van een computer aan de telefoonlijn realiseert, is zeer application specifiek en heeft DSP functies aan boord. Toch is hier de benaming modem chip wel zo duidelijk.
In de meeste embedded systemen nemen de hierboven geschetste programmeerbare (configureerbare) componenten slechts een klein fysiek deel van het geheel in. Het embedded systeem moet immers communiceren met de buitenwereld en van voeding worden voorzien. Daarvoor zijn allerlei interface schakelingen (voor bijvoorbeeld analoog, PWM, spanning, stroom, seriële interface, galvanische scheiding, relais, trafo’s, display’s, druktoetsen) en schakelingen voor EMC (filters: LC, RC, ferriet) nodig. De signaalverwerking en de gebruikers- interactie wordt echter voor het grootste deel bepaald door de programmeerbare bouwstenen.
Dezelfde verscheidenheid die we bij de embedded systems tegenkomen zien we natuurlijk ook weer terug bij de embedded software. Een belangrijk gemeenschappelijke kenmerk is echter dat embedded software foutloos moet zijn. Het wordt in een product vastgelegd en is daarna niet meer te wijzigen. PC software heeft altijd wel enkele meer of minder hinderlijke “bugs”. De echt hinderlijke bugs kunnen worden gerepareerd door een “maintenance”-programma op diskette te versturen. De minder hinderlijke bugs laat men zitten tot de “volgende versie” van het programma uitkomt. Bij embedded software is dit onmogelijk zo niet ongewenst: Wanneer bijvoorbeeld een elektronisch brandstofinspuitsysteem van een auto in bepaalde omstandigheden niet goed blijkt te functioneren, dan moeten alle auto’s van dat type worden teruggehaald naar de garage om van nieuwe software te worden voorzien. En dan mag je hopen dat deze systemen zijn uitgerust met een flash-geheugen, zodat de software kan worden gewijzigd via de diagnose connector. Zo niet, dan moet wellicht de gehele elektronica worden vervangen!
De reden dat embedded software wordt onderscheiden van “gewone” software is dat er aan embedded software speciale eisen worden gesteld. Dit kunnen we illustreren door op een aantal punten de vergelijking tussen embedded software en PC software te maken:
Embedded systems moeten niet alleen foutloos werken, ze moeten ook foutloos blijven werken. Wanneer een PC vastloopt, kan men deze herstarten en is men hoogstens wat gegevens kwijt. Een TV kan men wel herstarten door de spanning te onderbreken. TV afstandsbedieningen kunnen weer op gang worden gebracht door de batterij tijdelijk uit te nemen. Calculators hebben meestal een harde reset via één van de drukknoppen. Het wordt door de gebruiker echter niet getolereerd wanneer dit vaker dan een enkele keer in de levensduur voorkomt. Embedded systems moeten eigenlijk onder alle omstandigheden blijven functioneren. In kritische gevallen zal er redundantie en extra hard- en software moeten worden ingebouwd om aan de betrouwbaarheidseisen te kunnen voldoen (denk bijvoorbeeld aan medische apparaten, gasbranderautomaten, remsystemen, raketten en satellieten).
Testen is een belangrijk middel om te verifiëren dat het product juist werkt en juist reageert op ongewoon of onverwacht gebruik of onverwachte gebeurtenissen, zoals statische ontlading of andere stoorsignalen, welke de normale programmaloop kunnen verstoren. Wanneer tijdens het testen van een nieuw ontwikkeld product een fout of probleem wordt ontdekt moet de oorzaak ervan natuurlijk direkt worden opgespoord en uitgeschakeld. Veel belangrijker is echter dat tevens meteen de oorzaak van het ontstaan van de fout wordt onderzocht: fouten mogen eigenlijk niet worden weggetest maar dienen systematisch te worden voorkomen.
Watchdog circuits alleen zijn volmaakt ontoereikend om het goede verloop van alle software te garanderen. Het komt wel voor dat de watchdog door een deel van de software wordt koest gehouden, terwijl een ander deel van de software niet meer correct functioneert. De watchdog hardware dient daarom ten allen tijde te worden gecomplementeerd met software die permanent controleert of alle programma’s nog op de juiste wijze aflopen. Voorts dient te worden bepaald in welke staat het systeem moet terechtkomen na het actief worden van de watchdog. Het realiseren van een betrouwbaar watchdogsysteem dat zo alert mogelijk reageert op alle mogelijke verstoringen van het normale verloop van de programma’s, en naar de buitenwereld het doet voorkomen alsof er dan niets is gebeurd, vereist een gedegen inzicht in het verloop van het softwareproces en is beslist niet eenvoudig.
Een algemene techniek om tijdens de gehele ontwikkeling de kwaliteit in de hand te houden is het maken van een gedegen specificatie. Dat is niet de “functionele specificatie” die over de muur wordt gegooid. Dat is ook niet een specificatie waar zonodig een handtekening van de opdrachtgever onder moet. Dat is een zeer volledige specificatie, in duidelijke, voor normale mensen begrijpelijke taal. Hierin beschrijft men eerst de gehele context (fabrikant, gebruiker, markt, alternatieven, redenen van keuzes, enz.) waarin het product moet functioneren, zodat tijdens het uitvoeren van de ontwikkeling zo weinig mogelijk ad-hoc keuzes meer gemaakt moeten worden. Wanneer er toch nog keuzes gemaakt moeten worden, dan is het aan de hand van de duidelijk beschreven context mogelijk de implicaties van elke keuze voor alle facetten van het product kunnen doorzien (zie ook mijn lezing tijdens de Electronics’95; de tekst daarvan is te vinden op www.malotaux.nl).
Een andere belangrijke voorwaarde voor het realiseren van een goed product is de aanwezigheid van een interdiciplinair projectteam, waarin marketing, industriëel ontwerper, hardwareontwikkelaar, software-ontwikkelaar, mechanica-ontwikkelaar, producent en eventuele andere verantwoordelijke betrokkenen permanent kontakt met elkaar hebben om het beste resultaat te realiseren. Zodra één van deze betrokkenen niet geheel achter deze doelstelling staat, is het product gedoemd te mislukken.
Tenslotte is het goed om erop te wijzen dat het niet realistisch is bij een eerste product gebaseerd op embedded systems meteen het meest uitgekauwde resultaat te verwachten. Men moet altijd de learning-curve doorlopen, ervaring opdoen, fouten maken en daarvan leren. Bij elke nieuwe ontwikkeling kan men dan bouwen op de eerder opgedane ervaringen. Een manier om toch zo snel mogelijk state-of-the-art embedded systems in nieuwe producten te realiseren is het inschakelen van gespecialiseerde ingenieursbureaus. Een synergie tussen hun expertise en Uw markt- en productkennis levert dan sneller een beter resultaat.
Discussieer mee op LinkedIn.
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.