Nach modernen Ansprüchen muss ein Betriebssystem für Embedded-Geräte meist echtzeitfähig sein, Multicore unterstützen und Security-zertifizierbar sein. Hierfür gibt es sogar Lösungen, die flexibel, kostenlos und einfach in der Handhabung sind.

Waren embedded OS früher eher als Starter-Kit für einen Mikrocontroller zu verstehen, so benötigt die Komplexität von aktueller Hard- und Software oft einen „Unterbau“ (OS), der dem von Desktop Systemen oft kaum nachsteht. Dennoch scheinen die Forderungen auf dem Titel ziemlich hoch gegriffen. Dies ist jedoch kein Ausdruck fehlender Kompromissbereitschaft, sondern begründet und realistisch. Im Folgenden soll erläutert werden, was dahintersteckt.

In der Regel wächst die Entwicklung eines Embedded-Systems mit der Zeit. Anfangs geht es darum, möglichst schnell zu einem funktionsfähigen Basis-System zu kommen. Das wird benötigt, um die Hardware testen zu können und als Basis für die weitere Entwicklung. Hier ist es wichtig, ein OS für die vorgesehenen Hardware-Plattform verfügbar zu haben, oder zumindest mit überschaubarem Aufwand produzieren zu können.

Naheliegend werden hier bereits die zu erwartenden Features, die Prozessorarchitektur sowie die Systemkonfiguration berücksichtigt. Zu diesem Zeitpunkt gelingt dies jedoch nur auf einer relativ groben Ebene, da sowohl Hardware als auch Software heutzutage eine hohe technische Komplexität aufweisen. Beispielsweise kann die Dokumentation für einen SoC durchaus mehrere tausend Seiten umfassen. Die Feinheiten erschließen sich dann oft erst während der Entwicklung.

Neben der technischen Betrachtung für das konkrete Projekt spielen auch simple praktische Gesichtspunkte eine Rolle. Welche Erfahrungen hat man mit ähnlichen Systemen bzw. Projekten? Wie aufwendig ist der Einstieg? Unter dem Zeitdruck bei (oft schon verzögertem) Projektbeginn hat man selten die Geduld, umfangreiche Beschaffungsprozesse und Lizenzvereinbarungen für Testzwecke anzustoßen. Man muss hier einen Weg zwischen zwei Extremen finden.

Der Minimalistische Ansatz verfolgt den Aufbau eines möglichst einfachen Systems. Der initiale Aufwand ist hierbei klein, das System zunächst einfach, dadurch auch die Einarbeitung. Allerdings wird es aufwendig (oder gar unmöglich), später eventuelle notwendige Erweiterungen einzubringen. Selbst wenn sich „nur“ eine Schnittstellendefinition ändert und der passende Treiber nicht im Support-Package für das jeweilige Board verfügbar ist, können schon erhebliche Schwierigkeiten auftreten.

Wenn sich gar herausstellt, dass die Performance eines Single-Core Systems nicht ausreicht und man deswegen auf eine Multi-Core Variante aufrüsten muss, ist in vielen Fällen ein kompletter softwareseitiger Neustart angesagt – mit absehbaren Problemen beim Terminplan. Fast noch dramatischer wird es, wenn die benötigen Response-Zeiten nicht stabil einzuhalten sind. Denn es ist nahezu unmöglich, unzureichende Echtzeitfähigkeiten nachzurüsten. Und ein System manuell bezüglich der Response-Zeit „zu optimieren“ braucht es viel Zeit und es bleibt riskant (um nicht zu sagen instabil).

Beim maximalen Ansatz werden In Erwartung möglicher Schwierigkeiten alle denkbaren Notwendigkeiten in Betracht gezogen. Speziell breit aufgestellte Projektkonsortien neigen dazu, Bedenken und Kritik durch weitere Forderungen im Lastenheft „zu bedienen“. Das Ergebnis ist dann ein schwerfälliger Bolide, mit großem Aufwand und Zeitbedarf für die Entwicklung und geringer Flexibilität für Anpassungen und Weiterentwicklungen.

Im Folgenden eine (unvollständige) Liste an Echtzeit-Betriebssysteme, die für verschiedene Mikrocontroller verfügbar sind (in alphabetischer Reihenfolge):

Die Suche nach einem „optimalen“ Weg zwischen den oben gezeigten Extremen erscheint verständlich, bleibt aber ein Kompromiss. Und, egal welche Strategie man letztlich gewählt hat, kommt irgendwann im Laufe der Produktlebenszeit dazu noch die zeitliche Entwicklung. Dies ist wichtig zu berücksichtigen, da Embedded-Systeme oft lange Produktlebenszyklen und Einsatzzeiten haben. Ein paar geläufige Beispiele:

1. Es erscheint eine neue Version des OS. Soweit kein ungewöhnlicher Vorgang, aber speziell bei kommerziellen OS kommt man früher oder später um eine Anpassung nicht herum. Das bedeutet auch eine komplett neue Testung, gegebenenfalls Aufrüstung der Hardware. Sofern das mit einer ohnehin fälligen Produktrevision einhergeht, passt es. Andernfalls entsteht ein nicht unerheblicher und dazu noch sinnloser Aufwand.

2. Das Produkt soll eine Weiterentwicklung erfahren. Hier stößt man leicht an eine gläserne Decke, wenn nämlich die dafür benötigten Features nicht vom OS bereitgestellt werden (können).

3. Ein Nachfolgeprodukt oder eine abgeleitete Variante soll entwickelt werden. Hierbei ist der Rückgriff auf vorhandenes Know-how und vorhandene Technologie sehr vorteilhaft. Ob das klappt, hängt von der Flexibilität des OS ab.

4. Eigentümerwechsel beim OS-Hersteller: Die Lizenzbedingungen und die Lizenzkosten ändern sich. Dadurch ändern sich nicht nur die Kosten an sich, sondern auch die Kostenstruktur und die Roadmap. Im Einzelfall können sich die Lizenzgebühren vervielfachen. Ein Wechsel auf ein anderes OS ist bei einem laufenden Produkt kaum möglich, das weiß auch der Lizenzgeber.

5. Wird eine Qualitäts- oder Sicherheitszertifizierung (für Automotive, Medizintechnik oder Luft- und Raumfahrt) benötigt, ist generell ein großer Aufwand nötig. Bei jeglichen Änderungen fallen Re-Zertifizierungen an. Nachträgliche Zertifizierungen sind oft aus ökonomischen Gründen kaum machbar, bei komplexen Architekturen (wie z.B. bei Linux) auch technisch kaum möglich.

Und nun? Am liebsten möchte man nicht „klein ODER groß“ sondern „klein UND groß“. Das heißt, ein einfaches und kleines System für den Start, das bei Bedarf ausgebaut werden kann. Und ein System, das keinen unerwarteten Ärger macht, weil etwas „nicht geht“. Wie eine solche Skalierung gelingen kann, soll am Beispiel der Entwicklung des Echtzeitbetriebssystem RTEMS (Real Time Executive for Multiprocessor Systems) dargestellt werden.

Ursprünglich wurde RTEMS in den 1980er Jahren vom amerikanischen Militär als Plattform für Echtzeitsysteme entwickelt. Aber bereits nach wenigen Jahren wurde die Software unter Open-Source-Lizenz gestellt und dort weiterentwickelt. Herausragende Merkmale waren von Anfang an die „harte“ Echtzeitfähigkeit sowie der niedrige Ressourcenbedarf bei gleichzeitig hoher Leistung (Memory Footprint derzeit ab ca. 64 KByte). Mittlerweile hat sich eine überwiegend aus professionellen Usern gebildete Community gebildet, zumeist aus Bereichen mit hohem Leistungsanspruch (Raumfahrt, industrielle Anwendungen).

Über die Jahre wurde RTEMS auf eine Vielzahl von Prozessoren portiert und zeitgemäße Schnittstellen hinzugefügt. Derzeit ist RTEMS für 32 und 64 Bit-Systeme, einschl. ARM und AARC64, Power PC und NIOS-2- RISC-V Architekturen u.a. verfügbar. Die lange „Reifezeit“ als Open-Source-Software war wichtig, um sicherzustellen, dass (a) das System technisch und organisatorisch ausgereift ist und (b) das System auf absehbare Zeit weiterentwickelt wird – einfach, weil es schon von einer größeren Zahl professioneller User genutzt wird.

Ein Open-Source Betriebssystem, das überwiegend von professionellen Benutzern getrieben wird, ist zwar noch etwas ungewöhnlich, hat aber eine Reihe von Vorteilen gegenüber kommerziellen Systemen:

Die zuvor erwähnte „gläserne Decke“ existiert hier also nicht bzw. nur in dem Sinne, dass der technische Aufwand im gegebenen Rahmen vertretbar sein muss.

Mit der zunehmenden Verbreitung von Multicore-Systemen für höhere Leistungsfähigkeit steigen die Anforderungen an die Systemarchitektur erheblich. Solange verschiedene Prozesse jeweils einem eigenen Prozessor zugewiesen werden können oder mit einer festen Zuteilung von Rechenkapazität (Hypervisor-Architektur), ist dies noch relativ einfach zu realisieren. Allerdings ist eine solche Lösung hinsichtlich der Nutzung der Rechenleistung nicht flexibel und daher nicht optimal effizient. Hinzukommen, je nach Prozessorarchitektur, mehr oder minder spürbare Umschaltverluste zwischen den Prozessen und die suboptimale Nutzung von Hardware-Beschleunigern (z.B. Cache).

Zur Erreichung einer maximalen Systemperformance wurde in RTEMS das Konzept des Symmetrischen Multiprocessings (SMP) implementiert (gefördert durch die Europäische Raumfahrtagentur ESA). Hierbei wird die Rechenleistung gleichmäßig und in einer Art Selbstorganisation auf die verschiedenen Rechenkerne verteilt. Die Zuhilfenahme einer Reihe von Features ermöglicht die Darstellung eines Echtzeitbetriebssystems mit maximal effektiver Nutzung bzw. Zuteilung der Prozessorressourcen. Derzeit wird dies umgesetzt auf 4- bis 24-Core-Systemen, unter anderem auf QoriQ T4240, GR740, Intel Arria 10, Intel Cyclone V und Xilinx Zynq (auch UltraScale+).

Die für Luft- und Raumfahrt, Medizintechnik, Bahn- und Fahrzeugtechnik und viele andere Branchen notwendige Sicherheitszertifizierung stellt hohe Ansprüche an die Architektur und die Testung von Software. Vor allem ist sie aufwändig und kann ein Mehrfaches des Entwicklungsaufwands verschlingen. Um diesen Prozess zu vereinfachen, wird für RTEMS derzeit ein Qualifizierungs-Toolkit entwickelt. Dieses umfasst die notwendige Dokumentation sowie eine Tool-Chain und Test-Suites für eine automatische Testung. In einem ersten Schritt dient dies zur Zertifizierung für die Europäische Raumfahrt (nach ECSS-Standard), die Tools können aber auch für andere Standards angepasst werden. Da die Tools im öffentlichen Repository verfügbar sein werden, sinkt der Zertifizierungsaufwand erheblich. Ebenso sind die Tools zur Qualitätsverbesserung der Entwicklungsprozesse (auch ohne formale Zertifizierung) sehr nützlich.

Diesen Beitrag lesen Sie auch in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 23/2020 (Download PDF)

Operative und strategische Gesichtspunkte spielen bei Echtzeitbetriebssystemen eine zentrale Rolle, da diese die Erstehungskosten und Pflegekosten eines Produkts maßgeblich beeinflussen. Die Entscheidung für ein Echtzeitbetriebssystem sollte daher nicht nur nach Leistung und primären Kostenfaktoren getroffen werden. Vielmehr sind langfristig wirksame Faktoren wie Skalierbarkeit, Verfügbarkeit und Abhängigkeiten von ebenso großer Bedeutung. Größere Open-Source-Projekte sind diesbezüglich interessante, oft langfristig sogar sicherere Alternativen zu kommerziellen Systemen. Sie erfordern jedoch Engagement und gelegentliches Umdenken hinsichtlich des zugrunde liegenden Geschäftsmodells. Etablierte und nicht zu exotische Systeme auf Open-Source-Basis bieten eine effiziente und sichere Option im Bereich der Echtzeitbetriebssysteme.

* Prof. Dr.-Ing. Matthias Göbel ist Projektleiter bei der embedded brains GmbH in Puchheim bei München.

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.

Ich bin damit einverstanden, dass die Vogel Communications Group GmbH & Co. KG, Max-Planckstr. 7-9, 97082 Würzburg einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von redaktionellen Newslettern nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.

Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.

Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden.

Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://support.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung, Abschnitt Redaktionelle Newsletter.

Softwaretest in Praxis und Forschung

2011-2021: Was hat der Umstieg auf Agilität verändert?

RTEMS für Raumfahrt qualifiziert

Cookie-Manager Impressum Datenschutz AGB Kundencenter Hilfe Mediadaten Autoren

Copyright © 2022 Vogel Communications Group

Diese Webseite ist eine Marke von Vogel Communications Group. Eine Übersicht von allen Produkten und Leistungen finden Sie unter www.vogel.de

Clipdealer; NASA; rti; embedded brains; VCM; J. Untch / Vogel Communications Group GmbH & Co. KG; Entwurf, designed by meplan.; Vogel Communications Group; Volkswagen AG; Markus Spiske - Unsplash.com; gemeinfrei; PLS; TQ Systems; 2022 Doug Ellis Photography; Foundries.io; Pixabay License; iStock f0722lx; Copyright Gesamtbild: Wibu-Systems; Copyright Schlange: iStock, Serhii Yakovliev; MAB Labs / Percepio; Pygears; Lynx Software Technologies ; Green Hills / Copyright (c) 2018 ParabolStudio/Shutterstock. ; Canonical ; Parasoft; Initiative for Applied Artificial Intelligence; © Yingyaipumi - stock.adobe.com; Siemens Software ; Segger; NXP; ordinary042 - stock.adobe.com