Startseite > Embedded > Software > VxWorks 7: Wind River hat aufgeräumt

Echtzeit-Betriebssystem

VxWorks 7: Wind River hat aufgeräumt

14. August 2014, 10:29 Uhr | Joachim Kroll

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Zusätzlicher Mikrokernel: ein »Mini-VxWorks«

Für »Deeply Embedded«-Geräte hat Wind River einen besonders kleinen und schlanken Mikrokernel entwickelt, der von einem seit 2002 bestehenden DSP-Echtzeit-Betriebssystem abgeleitet ist. Dieser Mikrokernel enthält eine Teilmenge der Funktionen des VxWorks-Kernel und benötigt in seiner kleinsten Implementierung mit einer Task nur einen Speicher-Footprint von 2280 Bytes. Laut Wind River eignet sich dieser Mikrokernel z.B. für heterogene Multicore-Architekturen, in denen ein leistungsfähiger »Number Cruncher« und ein kleiner Steuerprozessor stecken. Der Mikrokernel kann dann für den »kleinen« Prozessorkern eingesetzt werden (Bild). Außerdem führt der verringerte Funktionsumfang zu niedrigeren Zertifizierungskosten, falls das Gerät nach einem Standard für funktionale Sicherheit zertifiziert werden soll. Die Boot-Zeit des Mikrokernel beträgt nur 25 µs und sein API ist auch Bestandteil des VxWorks-Kernels, so dass Mikrokernel-Tasks auch unter VxWorks ausgeführt und getestet werden können. Auch wenn nur ein kleineres API im Mikrokernel steckt: Auf harte Echtzeit, Multithreading, Multicore-Unterstützung und Power-Management-Funktionen muss der Entwickler nicht verzichten.

Hypervisor: Von Para- zu Vollvirtualisierung

Der Hypervisor, der bisher ein separates Produkt war, wurde mit Version 7 mit dem VxWorks-Kernel verschmolzen. Das bedeutet, dass keine eigenen Hypervisor-BSPs mehr nötig sind. Überall dort, wo VxWorks läuft, läuft auch der Hypervisor. Auch am Hypervisor selbst hat sich einiges geändert: Er wurde insofern erweitert, als er statt Paravirtualisierung jetzt Vollvirtualisierung ausführt. Virtualisierung bedeutet u.a., dass kritische Aufrufe des Betriebssystems vom Hypervisor abgefangen werden, um Zugriffskonflikte auf die Prozessor-Hardware zu vermeiden. Bei der Paravirtualisierung ist der Hypervisor auf die Kooperation des Gast-Betriebssystems angewiesen, das dazu modifiziert werden muss. Ab sofort sind diese Modifikationen also nicht mehr nötig. Die Kehrseite davon: Der Hypervisor greift jetzt auf Virtualisierungsfunktionen der Prozessoren zu, was die Vorgänge zwar beschleunigt, aber auch die Prozessorauswahl einschränkt. Derzeit werden ARM A7 und A15, PowerPC-e500-Cores und Intel VTx unterstützt. Die VTd-Befehle der Intel-Funktionen (für die Virtualisierung der Prozessor-Peripherie) werden unterstützt, sind aber nicht zwingend erforderlich, damit der Hypervisor funktioniert. Als Gäste kann der Hypervisor VxWorks (auch ältere Versionen), Windows und Linux (Wind River, Kernel.org, Red Hat) bewirten.

Bei sicherheitsrelevanten Systemen kommt die Integration des Hypervisors in VxWorks ins Spiel: Hier bewirtet VxWorks bzw. der Hypervisor sich sozusagen selbst unter Einsatz eines Sicherheits-Schedulers, der die Prozesse zeitlich und örtlich im Speicher sicher voneinander abschottet. Sicherheitskritische Prozesse können auf diese Weise von nicht kritischen Prozessen getrennt werden, was den Aufwand für die Zertifizierung verringert. So genannte Sicherheitsprofile bilden die Grundlage für Zertifizierungen nach verschiedenen Standards (IEC 61508, IEC 50128, DO-178C u.a.). Der Vorteil des Hypervisors bei diesen Zertifizierungen ist, dass durch die Aufteilung in kritische und unkritische Bereiche der Aufwand begrenzt werden kann, weil wirklich nur Kritisches den Zertifizierungsprozess durchlaufen muss.