Embedded Systems

Für einen effizienten und zuverlässigen Betrieb von Embedded Systems ist die optimale Abstimmung von Hardware, Software und Systemarchitektur entscheidend.

Embedded Systems sind allgegenwärtig, einigie sichtbar, die Meisten im Verborgenen. Ob die Klimaanlage im Auto, die Steuerung in der Kaffeemaschine, oder die Ansteuerung des Lifts, am besten wird ihre Existenz nicht bemerkt und ihre Funktion als natürlich gegeben wahrgenommen. Im Unterschied zum Personal Computer (PC) dient das Embedded System normalerweise nur einem einzigen vordefinierten Zweck. Die Anforderungen daran sind aber ungleich höher als bei einem PC, der für vieles ein Bisschen, aber für fast nichts wirklich geeignet ist. Die Anforderungen können sich z.B über kurze Latenzzeiten oder auch Energieeffizienz erstrecken.

Das Design eines Embedded Systems beinhaltet neben der Hardware, dem Betriebssystem und der Embedded Applikation oft auch die serverseitige Software in der Cloud. Um ein solches Projekt in vernüntiger Zeit und Kosten fertigstellen zu können, bedarf es viel Erfahrung bei der Architektur, der Implementierung und insbesondere bei der Wahl des Hardware- und Software-Ökosystems.

Seit Jahren dominiert die ARM Architektur das Hardwareökosystem bei den Embedded Systems. Da die ARM-Prozessoren (ARM-CPU) resp. System on a Chip (ARM-SoC) in Lizenz gefertigt werden, sind sie in allerlei Variationen verfügbar, vom stromsparenden Klein- bis zum mächtigen Multicore-System. Als Newcomer kündigt sich die von einem breit abgestützen Firmenkonsortium unterstützte RISC-V Architektur an, welche zumindest in der Instruction Set Architecture (ISA) den Openssource-Gedanke in die Hardware überträgt und von Grund auf für anwendungsspezifische Erweiterungen ausgelegt ist.

Neben einigen spezialisierten Betriebssystemen wie RTOS (Echtzeitbetriebssystem) dominiert GNU/Linux das Software-Ökosystem bei den Embedded Systems. Um dessen grossen Funktionsumfang erfolgreich zu nutzen und in eigene Produkte zu integrieren, sind Erfahrung und Detailkenntnisse fast unerlässlich. So kann die Qualität der Subkomponenten (vor allem Treiber) stark varieren und eine nötige Verbesserung oder Portierung zu unerwünschtem Mehraufwand während der Entwicklung oder Wartung führen. Dies kann nur mit einer sorgfältigen Überprüfung des gesamten Software-Packetes, in diesem Zusammenhang Board Suppor Package (BSP) genannt, verhindert werden.

Bei Bedarf kann die gewählte Plattform bis ins Detail optimiert werden. Dies kann z.B. durch den Einsatz von SIMD-Instruktionen, CUDA-Cores (GPU) oder FPGAs geschenen. Häufig spricht man in diesem Zusammenhang auch von HW/SW Codesign.

Ist eine Benutzerinteraktion erforderlich, empfehlen sich QT für einfachere, das Anroid Open Source Project (AOSP) für grössere Projekte.