Ingebouwd systeem

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken

Een embedded system (ook wel Engels "embedded system") is een elektronische rekenmachine of computer , in een technische context betrokken is (embedded). De computer neemt ofwel bewakings-, controle- of regelfuncties over of is verantwoordelijk voor een of andere vorm van gegevens- of signaalverwerking, bijvoorbeeld voor versleuteling of ontsleuteling, codering of decodering of filtering.

Embedded systemen voeren de service - grotendeels onzichtbaar voor de gebruiker - uit in een groot aantal toepassingsgebieden en apparaten, bijvoorbeeld in medisch-technologische apparaten , wasmachines, vliegtuigen, motorvoertuigen, koelkasten, televisies, dvd-spelers, settopboxen , routers , mobiele telefoons of in het algemeen in consumentenelektronica . Bij complexe totaalsystemen gaat het meestal om het koppelen van een groot aantal overigens autonome, embedded systemen (bijvoorbeeld in voertuigen of vliegtuigen).

Embedded systemen zijn vaak speciaal aangepast aan een taak. Uit kostenoverwegingen is gekozen voor een geoptimaliseerde, gemengde hardware-software implementatie. Een dergelijke constructie combineert de grote flexibiliteit van software met de prestaties van de hardware . De software wordt zowel gebruikt om het systeem zelf te besturen als om te communiceren met de buitenwereld via gedefinieerde interfaces of protocollen (bijv. LIN-bus , CAN-bus , ZigBee voor draadloze communicatie of IP over Ethernet ).

Embedded systeem op een insteekkaart met processor, geheugen, voeding en externe interfaces

karakteriseren

In individuele gevallen kunnen embedded systemen gebaseerd zijn op hardware die vergelijkbaar is met die van werkstationcomputers ( embedded pc's ). Ze zijn echter doorgaans onderhevig aan zeer beperkende randvoorwaarden: minimale kosten, weinig ruimte-, energie- en opslagverbruik. Afzonderlijke componenten zoals de processor en het hoofdgeheugen zijn vaak gebaseerd op de doorontwikkeling van oudere componenten, wat de bruikbaarheid op lange termijn en de aanschaf van reserveonderdelen vergemakkelijkt. "Moderne" embedded systemen zijn vaak gebaseerd op processorplatforms die weinig gemeen hebben met de pc-wereld, maar zijn sterk geïntegreerd in termen van randmodules en verbruiken aanzienlijk minder energie dankzij moderne energiebesparende technologieën.

Voor veel toepassingen kan het gebruik van een oudere processorarchitectuur helpen om de kosten te verlagen. De architecturen van de MCS- 51- , Microchip-8Bit-PIC- of Z80- serie zijn ondanks hun leeftijd en bekende zwakheden nog steeds een zeer populaire basis voor embedded systemen. Het hergebruik van programmacode en toolchains en de terughoudendheid om "zonder noodzaak" volledig opnieuw te ontwerpen, zijn naast de pure materiaalkosten ook marginale factoren die niet mogen worden onderschat.

In een embedded systeem moet de software vaak aan realtime eisen voldoen. In de regel zijn er slechts sterk verminderde bronnen in vergelijking met pc-hardware, meestal zonder harde schijf, vaak zonder besturingssysteem, toetsenbord of scherm. Een ROM of flash-chip vervangt mechanische opslagcomponenten zoals een harde schijf; Energiebesparende processors kunnen het zonder ventilator, want bewegende delen betekenen slijtage en foutgevoeligheid. Als dat al gebeurt, is er meestal maar één toetsenbord en wordt de uitgang - indien aanwezig - gerealiseerd door een LCD .

De software op zo'n apparaat wordt firmware genoemd . Het staat meestal op ROM , maar steeds vaker op flashgeheugen . In het geval van een flashgeheugen is er de mogelijkheid van een firmware-update zonder de chip te hoeven vervangen. Als er maar één ROM beschikbaar is, moet meestal de hele chip worden vervangen, soms het hele circuit.

Firmware-componenten

De firmware bestaat in wezen uit drie componenten.

Bootloader
Zorgt voor het laden van het besturingssysteem en de applicatiesoftware. Dit biedt ook de mogelijkheid om het besturingssysteem en de applicatiesoftware in het flashgeheugen te updaten. Dit kan via een seriële interface (RS232) of via Ethernet en IP. Bekende bootloaders voor embedded systemen zijn RedBoot of U-Boot.
besturingssysteem
Dit softwareonderdeel zorgt onder andere voor multitasking, opslag en bestandsbeheer (bijv. JFFS2) evenals IP-services zoals TFTP , HTTP , SNMP en Telnet
Applicatiesoftware
Dit deel bevat de applicatiespecifieke software. Dit wordt ook wel applicatiesoftware genoemd .

Bij kleine embedded systemen kunnen de drie softwareonderdelen worden gecombineerd.

Platformen

Embedded systemen zijn gebouwd met behulp van veel verschillende CPU- architecturen ( 8051 , ARM , AVR , TI MSP430 , MIPS , PowerPC , 68000 / Coldfire , Intel x86 , 68HC12, C167 , Renesas M16C , H8S en diverse andere 8/16/32 bit CPU's) gerealiseerd .

Een subgroep van de architecturen zijn de processorfamilies (bijv. 8051, AVR, PIC16, ARM7, PowerPC 5xx, MIPS 4k, AMD AU1000, Intel Pentium M), waarin verschillende varianten kunnen worden bediend met dezelfde ontwikkeltools en debugging-tools. Verschillen binnen een processorfamilie zijn snelheid en vooral de apparatuur met geheugen en randapparatuur.

Een bijzonder flexibel platform zijn sterk geïntegreerde FPGA- modules waarmee enerzijds verschillende CPU-architecturen kunnen worden gesimuleerd (bijv. 68000 en PowerPC 405 op één chip), en anderzijds goed parallelle rekenkracht zonder processor - alleen met behulp van speciale logica - wordt beschikbaar gesteld kan. In echte toepassingen zijn beide benaderingen vaak geïntegreerd in een FPGA als SoC . Hard-wired harde macro's zoals de PowerPC-cores in verschillende Xilinx Virtex- FPGA's evenals flexibel configureerbare softcore-processors zoals Alteras Nios II , Xilinx' MicroBlaze , de Mico32 van Lattice of IP-cores van een microcontroller zoals PIC worden gebruikt als processors of 8051.

besturingssysteem

Embedded PC Simatic Microbox PC 427B van Siemens waarop het besturingssysteem Windows XP Embedded is geïnstalleerd.

In "kleine" systemen wordt vaak geen besturingssysteem gebruikt.

Als een besturingssysteem wordt gebruikt in embedded systemen, is het meestal een speciaal besturingssysteem (voorbeelden: QNX , VxWorks , Nucleus , OSEK , OS-9 , RTEMS , ECOS ). Er worden nu speciale zogenaamde embedded versies van standaard besturingssystemen zoals Linux (zie Embedded Linux ), NetBSD of Windows ( 3.x , CE , XP Embedded , Automotive of Windows Embedded POSReady 2009 / POSReady 7 ) gebruikt. Toepassingen hebben vaak zachte of zelfs harde realtime- eisen, zoals hieronder in meer detail wordt beschreven. Hiervoor moeten speciale realtime-besturingssystemen of besturingssystemen met daarvoor aangepaste cores [1] worden gebruikt.

Ontwikkelomgeving, programmering, tools

De software voor programma-ontwikkeling, d.w.z. compiler , assembler en debugger (hoewel er ook regelmatig hardware moet worden gebruikt voor debuggen), wordt meestal aangeboden door verschillende fabrikanten:

  • Fabrikanten van halfgeleiders die geïnteresseerd zijn in de verkoop van hun processors en controllers, en
  • Softwarebedrijven die gespecialiseerd zijn in dergelijke programma's.

De software voor embedded systemen, de firmware, wordt meestal gegenereerd met behulp van een cross-compiler . Deze compiler draait op het ontwikkelsysteem (pc-architectuur), d.w.z. normaal gesproken een andere architectuur dan die van het doelsysteem. Veel crosscompilers zijn niet beperkt tot een specifieke processor, maar kunnen machinecode genereren voor een hele familie processors, zoals ARM7, PowerPC 8xx.

Sommige fabrikanten bieden ook systeemontwerpkits aan die een prototypebord met de juiste processor bevatten, samen met een set softwareontwikkelingskits en documentatie voor hardware en software.

Steeds vaker wordt de software voor embedded systemen gemaakt met behulp van modelgebaseerde ontwikkeling, waarbij grafische modellen van het gedrag worden gespecificeerd, die vervolgens door middel van codegeneratie worden omgezet in C-code.

De programmeertaal die de voorkeur heeft is over het algemeen C of C++ , maar er zijn ook benaderingen zoals OSGi voor Java . Assemblertaal wordt gebruikt wanneer tijdkritische of apparaatstuurprogrammafuncties voornamelijk in interrupts worden geprogrammeerd, of wanneer het besturingssysteem zelf moet worden aangepast aan een nieuwe omgeving of CPU. Boven het besturingssysteem is assembler meer een marginaal fenomeen, maar assembler wordt vaker gebruikt in systemen zonder besturingssysteem en vooral met enorme geheugenbeperkingen. In veiligheidskritische toepassingen zoals vluchtbesturingscomputers worden meer exotische talen zoals Ada ook gebruikt in embedded systemen - hier moet u echter onderscheid maken tussen het tijdkritische en het veiligheidskritische toepassingsniveau, waarvoor verschillende applicaties en programmeertalen kunnen binnen het systeem verantwoordelijk zijn. Zogenaamde modelmatige ontwikkeling met MATLAB / Simulink of ASCET wordt vaak niet alleen in de auto-industrie gebruikt. C-code wordt automatisch gegenereerd uit de modellen, die op hun beurt worden gecompileerd voor de bijbehorende doelprocessor.

Het testen van software voor embedded systemen vindt vaak plaats in de vroege ontwikkelingsfasen op de pc. Hiervoor moet vaak de omgeving van de applicatie waarmee het embedded systeem communiceert worden gesimuleerd . Deze simulatie wordt dan MiL ( Model in the Loop ) of SiL (Software in the Loop) genoemd. Als de software is geïmplementeerd op de doelhardware, spreekt men daarentegen van HiL ( Hardware in the Loop ), de toegang tot de testhardware vanaf de pc vindt meestal plaats via een hardware-emulator .

Software ontwikkeling

Softwareontwikkeling voor embedded systemen verschilt fundamenteel van die voor desktop- of pc-systemen, omdat de focus hier ligt op de mogelijkheden van input/output . De functies hiervoor zijn hardware-afhankelijk en moeten voor elk systeem opnieuw worden ontwikkeld.

Foutopsporing, probleemoplossing

Debuggen omvat het debuggen van zowel de software als het geïntegreerde systeem. Voor het testen van software kan een in-circuit emulator (ICE) worden gebruikt, een combinatie van programma en hardware waarmee de software in het systeem, dat wil zeggen op de doelhardware, kan worden getest. Traditioneel moet de eigenlijke controller worden vervangen door de ICE-hardware (een bond-out processor ). Hierdoor kan de software comfortabel en zonder verdere tussenkomst in de doelhardware worden ontwikkeld. Omdat toegang tot de periferie van de CPU mogelijk is met de ICE, kunnen software- en hardwarefouten worden onderscheiden en gescheiden. In het verleden was hiervoor een logische analysator nodig die, als extra optie, de doel-CPU kon emuleren.

Tegenwoordig hebben embedded CPU's al een "narrow-gauge" ICE aan boord, zodat de hardware ICE niet absoluut noodzakelijk is. Daarentegen zijn de mogelijkheden van de debugging-software om de doel-CPU te beïnvloeden beperkt. Volledige bewaking van de CPU is niet mogelijk, maar de kosten worden aanzienlijk verlaagd. Als een volledig ontwikkeld ICE-systeem tot zescijferige euro's kost voor een 68000-derivaat, liggen de kosten voor zo'n "smalspoor"-systeem in het lagere driecijferige eurobereik. Meestal wordt een interface van het type JTAG gebruikt. Een alternatief voor Coldfire en 68000-derivaten is de Background Debug Module (BDM) -interface van Motorola.

Zelfs met moderne ARM-architecturen, controllers met Cortex-M3-kern, is het beschikbaar als een speciale debugging-kern: https://developer.arm.com/documentation/ddi0337/e/DDI0337E_cortex_m3_r1p1_trm.pdf (Hoofdstuk 10 ... 13) Dat is een onderdeel van de microcontroller dat niet nodig is voor het normale programmaverloop en alleen is ingebouwd voor foutopsporing. Deze debugging-core kan worden aangepakt met debugging-software via een JTAG- of SWD-adapter. Dit betekent dat de processor op elk punt in het programma kan worden gestopt en de waarden van de registers of het geheugen kunnen worden bekeken of gewijzigd. Stapsgewijze verwerking van de code voor het oplossen van problemen is ook mogelijk. De hardware die hier nodig is, is een JTAG- of SWD-adapter, die vaak beschikbaar is voor minder dan 100 €. De debugger-software kan variëren van volledig functionele freeware ( gdb + ddd , gdb + kgdb , Eclipse ) tot professionele software in de duizenden euro's.

Als alternatief worden vaak simulatoren gebruikt, die de interne structuur en randapparatuur van de microcontroller in software simuleren. Bij het debuggen moeten de “externe” signalen (toetsen, display) “met de hand” worden gesimuleerd, waarbij interrupts moeten worden gebruikt die niet in de simulator kunnen worden geïmplementeerd.

Ook voor embedded systemen zijn er ontwikkelingen op basis van Java . Gebaseerd op de eenvoudigere platformwisseling en de platformonafhankelijkheid met het weglaten van simulatoren (zie OSGi en Embedded Java ).

De microcode-interrupt laat de debugger op de hardware werken in plaats van alleen op de CPU. Vanuit het oogpunt van de CPU kunnen dan CPU-gebaseerde debuggers worden gebruikt om de elektronica van de computer te testen en, indien nodig, om fouten te diagnosticeren. Deze mogelijkheid is onderzocht en ontwikkeld op de PDP-11 (zie Programmed Data Processor ).

De systeemtest wordt uitgevoerd met behulp van hardware-in-the-loop- technologie, waarbij het voltooide systeem wordt aangesloten op speciale hardware die de systeemomgeving simuleert. Op deze manier kan het gedrag van het systeem in detail worden onderzocht met testgevallen.

Structuur van de systeemomgeving waarin het embedded systeem is ondergebracht

In de regel zijn er verschillende interfaces tussen het embedded systeem en de systeemomgeving die het embedded systeem huisvest. Afhankelijk van de toepassing van het embedded systeem kunnen deze interfaces in de praktijk heel verschillend worden geïmplementeerd. Een bijzondere van deze interfaces is de gebruikersinterface . Verder zijn er een of meer applicatieprogrammeerinterfaces tussen het systeem en de systeemomgeving.

Softwareconcepten om rekening te houden met de vereisten die voortvloeien uit de structuur van de systeemomgeving

Veel toepassingen worden pas zinvol en bruikbaar als de daarvoor benodigde signaalverwerking in realtime plaatsvindt . Apparaten, systemen en processen die het attribuut "realtime" krijgen, moeten volgens objectieve normen voldoen aan criteria als " tijdigheid ", " voorspelbaarheid ", " beveiliging " en " betrouwbaarheid ". [2] Dit vereist realtime planning van taken en processen . Daarnaast moet de maximale runtime voor het vervullen van een taak bepaalbaar zijn vanuit de systeemomgeving, dat wil zeggen dat deze gekoppeld moet zijn aan een deterministische processtroom. De reactietijd van het systeem om de taak te vervullen moet voldoen aan het criterium "tijdigheid".

Er worden verschillende softwareconcepten gebruikt om realtime verwerking te implementeren, waarbij rekening wordt gehouden met de gebruikersinterface(s) en de applicatieprogrammeerinterfaces.

Tijdgestuurd versus gebeurtenisgestuurd ontwerp voor embedded software

De hieronder genoemde zogenaamde "regelkring", die neerkomt op het ontwerp van een regelaar, is op zijn best geschikt voor uiterst eenvoudige regeling van embedded systemen in de industrie. Het hoeft niet eens te worden ondersteund met realtime. Dit is te onderscheiden van de zogenaamde "reactieve benadering", die neerkomt op het ontwerpen van een zogenaamd " reactief systeem " dat in constante interactie is met de omgeving, waarbij de omgeving domineert en het reactieve systeem daaraan ondergeschikt is.

Regellus

Regelkringen worden gebruikt voor regelsystemen die cyclische berekeningen uitvoeren op basis van ingangssignalen en uitgangssignalen verzenden (zie regeltechniek ); dit wordt ook wel "tijdgestuurd ontwerpen" genoemd (zie Embedded Software Engineering ).

Reactieve benadering

De reactieve benadering leidt tot het ontwerpen van een processtroom waarin aperiodiek voorkomende gebeurtenissen, zoals een toetsaanslag of een reeks toetsaanslagen, worden verwerkt en de daaruit voortvloeiende acties worden gestart. Dit wordt "event-driven design" genoemd (zie Embedded Software Engineering ).

Systeem starten

Alle embedded systemen hebben een opstartcode die na het inschakelen wordt doorlopen. Meestal deactiveert dit de interrupts , kalibreert de interne elektronica , test de computer ( RAM , ROM , CPU ) en start de eigenlijke programmacode nadat alles met succes is getest.

Veel van deze systemen zijn binnen 100 ms klaar voor gebruik. Zelfs na een kleine stroomstoring of een spanningsschommeling blijven deze apparaten onmiddellijk werken, omdat de interne hardware de hardware- en software -zelftest overslaat. Door mogelijk gewijzigde bits in het RAM treedt echter ongedefinieerd systeemgedrag op dat een circuit voor spanningsbewaking (Supply Voltage Supervisor, SVS of ook wel Brownout- detectie genoemd) vermijdt . De SVS activeert een "juiste" reset zodat het systeem volledig wordt geïnitialiseerd en de zelftests doorlopen.

De duur van de systeemstart is in de voertuigelektronica af te lezen aan de controlelampjes die bij het aanzetten van het contact gaan branden en na korte tijd weer uitgaan. Bij veel apparaten betekent de systeemstart dat het inschakelen langer duurt dan bij analoge apparaten zoals autoradio's .

Communicatie tussen de systeemtechnicus en het embedded systeem tijdens bedrijf

Embedded systemen hebben vaak geen eigen aansluiting voor een beeldscherm of invoerapparatuur. Indirecte gebruikerscommunicatie kan echter worden geleverd via data-interfaces. Netwerkcompatibele printers en andere apparaten hebben een webinterface of een seriële interface waarmee alle belangrijke configuratie-instellingen worden gemaakt via browser- of terminalemulatie.

Ontwerp van ingebedde systemen

De elektronica vormt een microprocessor met passende randapparatuur of een microcontroller . Sommige meer verouderde systemen gebruiken nog steeds mainframes of minicomputers voor algemene doeleinden.

Aspecten van ontwerpbeslissingen over embedded systemen

De volgende aspecten spelen een rol bij ontwerpbeslissingen voor embedded systemen:

integratie
Hoe meer functionaliteit de gebruikte microcontroller al bevat, hoe minder randapparatuur er nodig is om de aansluiting op de benodigde systeeminterfaces (input/output) mogelijk te maken. Hoe minder componenten een printplaat nodig heeft, hoe kleiner de benodigde ruimte voor de geleidersporen en de signaalvoortplantingstijden tussen de componenten. Deze overwegingen hebben ertoe geleid dat microcontrollers al voldoende RAM en andere randfuncties hebben.
Hardwarevereisten
Afhankelijk van de toepassingsomgeving van het systeem kan een grote verscheidenheid aan randvoorwaarden ontstaan. Als het gaat om zware omgevingsomstandigheden zoals hitte en stof, moet de hardware robuust zijn, d.w.z. vooral hermetische inkapseling . Als het om complexere systemen gaat, zijn industriële pc's vaak een oplossing. Als het gaat om constante mechanische trillingen, moeten stekkerverbindingen worden bespaard of bijzonder robuust worden gemaakt. Componenten met bewegende componenten zoals harde schijven of ventilatoren moeten zoveel mogelijk worden vermeden.
Energieverbruik
In veel gevallen worden embedded systemen aangedreven door batterijen. Net als bij watermeters worden deze alleen in het kalibratie-interval (5 jaar + looptijdreserve) vervangen. De lange looptijden worden bereikt door speciale chiptechnologieën (bijvoorbeeld CMOS ) en maatregelen in de software, zoals de slaapmodus.
Realtime vereisten
Hoge beschikbaarheid en gedefinieerde responstijden zijn veelgestelde vereisten voor een embedded systeem en dus ook voor het besturingssysteem en de software. Zo moet bijvoorbeeld de elektronisch gestuurde rem of de airbag bijna onmiddellijk in het millisecondebereik reageren; het overschrijden van de gedefinieerde latentietijd kan niet worden getolereerd. Het eenvoudige en gesloten ontwerp en het gebruik van speciale realtime besturingssystemen maken het mogelijk om de responstijden van het totale systeem al in de ontwikkelingsfase in te schatten.
operationele veiligheid
In tegenstelling tot pc's draaien veel embedded systemen continu. Fouten en storingen, zoals problemen met elektromagnetische compatibiliteit (EMC), vereisen speciale maatregelen in het embedded systeem om een ​​betrouwbare herstart te garanderen. Microcontrollers zijn daarom uitgerust met een waakhond . Dit zorgt voor een gecontroleerde herstart bij onregelmatigheden in het proces en zorgt zo voor de beschikbaarheid van het embedded systeem zonder tussenkomst van de gebruiker.
Eenheid prijs
De eenheidsprijs is afhankelijk van de ontwikkel- en fabricagekosten. Bij grote productiehoeveelheden wordt dan ook veel energie gestoken in de ontwikkeling voor een optimaal grondstoffenverbruik. Bij kleine aantallen zijn de materiaalkosten minder van belang. Duurdere maar flexibelere componenten (bijvoorbeeld FPGA's ) zullen de ontwikkeltijd verkorten.
Ontwikkelomgeving
Zie Systeemontwerpkit .

Ontwerpproblemen aan de gebruikerskant van embedded systemen

Met het toegenomen gebruik van embedded systemen in auto's, wordt een ander probleem merkbaar: het aantal systemen is zo groot dat de beschikbare ruimte in een auto onvoldoende is en de bekabelingsinspanning toeneemt. Daarom worden meerdere besturingsfuncties gecombineerd in één besturingseenheid ; mogelijk gemaakt door krachtige 32-bits microcontrollers. Geheugenbeveiligingsmechanismen zoals MPU of MMU , die ervoor zorgen dat de afzonderlijke functies elkaar niet kunnen beïnvloeden, zijn over het algemeen nog vrij ongebruikelijk - ook de verspreiding van 8/16 bit-controllersystemen moet niet worden onderschat. In dit marktsegment geldt de stelregel van het minimaliseren van het elektriciteitsverbruik en het minimaliseren van de kosten, en dus het principe van "zo veel als nodig".

verhaal

Het eerste prominente gebruik van een ingebed systeem was dat van de Apollo Guidance Computer , die werd ontwikkeld door Charles Stark Draper samen met hetMIT Instrumentation Laboratory . Elke vlucht naar de maan had twee van deze systemen bij zich, die werden gebruikt voor controle. Het traagheidsgeleidingssysteem werd gebruikt in zowel de commandomodule als de maanmodule (LEM, Lunar Excursion Module).

Aan het begin van het Apollo-project werd dit systeem gezien als een van de meest risicovolle onderdelen van het project.

De eerste embedded systemen werden echter al in de Minuteman- raket gebruikt en in massa geproduceerd. De applicatie was een padzoeksysteem waarmee de raket na eenmalige programmering zelfstandig kon manoeuvreren. Naarmate de prijs daalde, werden de gebruikte geïntegreerde schakelingen geleidelijk opengesteld voor een breder scala aan toepassingen.

Doorslaggevend aan de Minuteman-computer was dat het wayfinding-algoritme later kon worden geprogrammeerd, waardoor de raket veel nauwkeuriger kon worden ingezet. Een ander voordeel was de zelftestfunctie van de raket voor statusvragen en het feit dat grotere hoeveelheden kabels konden worden weggelaten ten gunste van het gewicht.

Zie ook

architecturen

Termen en concepten

literatuur

  • Jürgen Teich, Christian Haubelt: Digitale hardware / softwaresystemen - synthese en optimalisatie . Springer, Berlijn / Heidelberg 2007, ISBN 978-3-540-46822-6 .
  • Joachim Wietzke: Embedded Technologies: Van de driver tot de grafische verbinding . Springer, Berlijn / Heidelberg 2012, ISBN 978-3-642-23995-3
  • Jörg Wiegelmann: Software-ontwikkeling in C voor microprocessors en microcontrollers: C-programmering voor embedded systemen VDE Verlag 2011, ISBN 978-3800732616

web links

Commons : Embedded Systems - Verzameling van afbeeldingen, video's en audiobestanden

Individueel bewijs

  1. Jürgen Quade, Michael Mächtel: Moderne real-time systemen compact: een introductie met embedded Linux. dpunkt-Verl., Heidelberg 2012, ISBN 978-3-89864-830-1 .
  2. Dieter Zöbel: Realtime systemen: basisprincipes en planning. Springer, Berlijn 2008, ISBN 978-3-540-76395-6 , blz. 18.