„Klein UND groß“: Moderne Anforderungen an ein Embedded OS

Anbieter zum Thema

embedded brains GmbH

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

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.

Ansprüche an ein Embedded-Betriebssystem

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):

Überlegungen zu Lebens- und Einsatzzeiten des Systems

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.

Flexible Skalierung erlaubt schnelle Anpassung

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.

Open-Source Software im professionellen Einsatz

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:

• Jeder Nutzer kann frei entscheiden, welche Version genutzt werden soll;

• es gibt keine Restriktionen, neue Features zu entwickeln; und

• für den Support gibt es verschiedene Anbieter, die (nur) durch wettbewerbsfähige Leistungen bestehen können.

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.

Systeme mit Symmetrischem Multiprocessing (SMP)

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+).

Echzeitbetriebssystem mit Sicherheitszertifzierung

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)

Fazit: Effiziente und sichere Optionen im RTOS-Umfeld

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.

(ID:46981302)