Embedded Linux Echtzeit mit Linux

Anbieter zum Thema

Linutronix GmbH

MicroConsult Academy GmbH

emlix GmbH

Mit Linux können Systeme mit harten Echtzeit-Anforderungen einfach umgesetzt werden. Doch welcher Ansatz ist der richtige? Und welche Latenzzeiten können damit erreicht werden?

Linux ist aufgrund der hohen Anzahl unterstützter CPU Architekturen, der nahezu unendlichen Anzahl von Treibern und der guten Portierbarkeit und Skalierbarkeit eines der leistungsfähigsten Embedded Betriebssysteme unserer Zeit. Auch Systeme mit Anforderungen an harte Echtzeit können mit Linux einfach umgesetzt werden.

Für Echtzeit mit Linux gibt es unterschiedliche Varianten und Ansätze. Doch welcher Ansatz ist der richtige? Und welche Latenzzeiten können damit erreicht werden? Dieser Artikel stellt unterschiedliche Technologien vor, mit denen harte Echtzeitfähigkeit unter Linux erreicht werden kann. Weiterhin wird aufgezeigt, welcher Jitter und welche Latenzzeiten mit diesen Technologien erreicht werden können.

Bildergalerie

Bildergalerie mit 14 Bildern

Verfügbare Technologien für Echtzeit-Linux

Grundsätzlich gibt es zwei Ansätze, um Linux echtzeitfähig zu machen: Mikrokernel-Ansatz und In-Kernel Ansatz. Im Mikrokernel Ansatz werden alle Echtzeitaufgaben in einem eigenen RTOS gehandhabt, Linux wird innerhalb dieses RTOS als niederpriore Task geschedult. Genaugenommen muss hier also nicht von Echtzeit mit Linux, sondern vielmehr von Echtzeit neben Linux gesprochen werden. Der sogenannte In-Kernel Ansatz verfolgt das Ziel, Linux an sich echtzeitfähig zu machen (ohne darunterliegenden Mikrokernel). Im Folgenden sollen verschiedene Vertreter dieser Ansätze vorgestellt werden.

RTAI: Realtime Application Interface

Das Realtime Application Interface (RTAI) ist eine Entwicklung der Technischen Universität Mailand und entstand unter der Schirmherrschaft von Professor Paolo Mantegazza. RTAI ist ein klassischer Vertreter des Mikrokernel Ansatzes. Oberstes Designziel von RTAI ist und war es, die kleinstmöglichen Latenzzeiten auf einer gegebenen Hardwareplattform zu erzielen. Dieses Designziel bedingt diverse Ein-schränkungen für RTAI Applikationen. Weiterhin wird nur eine recht kleine Anzahl an Zielplattformen unterstützt (derzeit x86, x86_64 und diverse ARM Plattformen). In der Praxis finden sich kaum noch neue Projekte, die auf RTAI aufsetzen. Bild 1 in der Bildergalerie zeigt den prinzipiellen Aufbau von RTAI.

SEMINAR-TIPP

Embedded-Linux-Woche

In den Kursen der Embedded-Linux-Woche führen unsere Referenten Sie Schritt für Schritt in die Linux-Welt ein. Fortgeschrittene können sich im Seminarangebot "Echtzeit-Linux und Systemprogrammierung" vom einfachen Embedded-Linux-User zum systemnahen Echtzeit-Entwickler weiterbilden. In nur fünf Tagen erarbeiten Sie sich fundiertes Fachwissen um den Linux-Kernel, Prozessverwaltung, Tracing, Ressoucenverwaltung, Hardware-Anbindung und vieles mehr, so dass Sie sich schon bald als waschechten Linux-Experten bezeichnen können!

Weitere Details und Termine

Ergebnisse Xenomai

Bild 4 in der Bildergalerie zeigt die Reaktionszeit auf das Event im Kernel. Bild 5 stellt die Latenzzeiten für eine Applikation dar, die auf das Event wartet. Der Worst-Case liegt bei knapp unter 100 Mikrosekunden.

Ergebnisse PREEMPT_RT

Bild 6 + 7 in der Bildergalerie zeigen die Reaktionszeiten im Kernel unter PREEMPT_RT. Durch Isolieren eines Cores lässt sich der Worst-Case noch etwas verbessern.

Bei den Messungen für die Applikation schneidet PREEMPT_RT etwas besser ab als Xenomai. Der Worst-Case liegt bei etwas über 90 Mikrosekunden.

Durch Isolieren eines Cores lässt sich das Ergebnis auf 80 Mikrosekunden verbessern: Nun ist der Vergleich der Reaktionszeiten im Kernel nicht ganz fair, denn bei Xenomai sprechen wir hier ja von einem Mikrokernel und nicht vom Linux Kernel. Denn genaugenommen arbeiten wir den Code ja nicht im Linux Kontext ab (wie es bei Xenomai der Fall ist). Daher wurde für PREEMPT_RT noch eine weitere Messung durchgeführt: Das Abarbeiten des kritischen Codepfades im FIQ Kontext (den viele ARM basierte SOCs bieten). Der FIQ lebt in seiner „eigenen Welt“, es ist aber möglich einen FIQ Handler aus Linux heraus zu registrieren!

Bild 10 zeigt die Ergebnisse einer FIQ basierten Lösung (basierend auf einem PREEMPT_RT Kernel). Der Worst-Case ließ sich hier auf 30 Mikrosekunden verbessern! Dieser einzelne „Ausreißer“ lässt sich mit großer Wahrscheinlichkeit auf ein Hardwareproblem zurückführen. Auf anderen Plattformen konnten mit diesem Ansatz Reaktionszeiten von < 10 Mikrosekunden erreicht werden!

Harte Echtzeit beim Einsatz von Containern und Hypervisors

Bei einer Virtualisierung werden alle Ressourcen, die ein System benötigt, vom Hypervisor zur Verfügung gestellt. Nicht vorhandene Hardware oder Zugriffe auf eine Hardware aus der virtuellen Maschine heraus werden per Software nachgebildet. Eine virtuelle Maschine ist hier immer ein Paket aus Betriebssystem und Anwendungscode, das in der virtuellen Umgebung, also im User Space, läuft. Mit Hilfe eines Emulators kann dem Paket sogar eine andere Hardware Architektur als physikalisch vorhanden vorgegaukelt werden. Den typischen Aufbau zeigt Bild 11.

Beim Container-Ansatz wird auf die virtuelle Maschine, das Vorgaukeln einer eigenen Hardware und eines eigenen Betriebssystems, verzichtet. Das Betriebssystem ist für alle Container identisch, alle Container teilen sich die gleiche Hardware. Die Separierung der einzelnen Container erfolgt über spezielle Funktionen des Betriebssystems (unter Linux sind dies zum Beispiel CGROUPS und Namespaces). Das macht die Container schlank, das heißt, sie benötigen nicht viel zusätzlichen Code zu Ihrer eigentlichen Aufgabe. Innerhalb eines Containers befindet sich die Anwendung (oft nur eine einzige, kleine Applikation) und die dafür benötigten Libs und Frameworks. Eine Nutzung von Containern entkoppelt die Applikation von der Infrastruktur und bietet damit eine Portabilität, die heute mit Cloud zentrierten Ansätzen erwartet wird. Bild 12 zeigt den typischen Aufbau.

Bildergalerie

Bildergalerie mit 14 Bildern

Container und VM sind in der IT Welt entstanden, um die dortigen Anforderungen zu lösen. Mit der VM wurde es möglich, mehr als nur eine Applikation pro Rechner/Server laufen zu lassen. Und in dem Maße, wie eine Anwendung von einem einzigen, großen monolithischen Block zu einer Sammlung von kleinen Anwendungen wurde, stieg der Einsatz und Nutzen der Container Technologie.

Hypervisor-Einsatz und Echtzeit-Latenzzeiten

Kombiniert man diese CPUs mit einem geeigneten Hypervisor, lassen sich auch die spezifischen Anforderungen der Automatisierung damit abdecken. Mit eine der wichtigsten technischen Anforderungen an eine Steuerung ist die Echtzeitfähigkeit. Der Open Source Realtime Hypervisor Jailhouse, ein Typ I Vertreter, eignet sich hervorragend. Die Echtzeitfähigkeit im Gastsystem wird nahezu nicht beeinträchtigt, der Einfluss liegt im Bereich von < 3 µs. Jailhouse erlaubt beliebige Kombinationen von Linux, anderen Betriebssystemen, bare metal Applikationen und Zuordnung von CPUs zu einem Betriebssystem.

Wenn der Hypervisor nicht eingreifen muss, wie es bei Jailhouse der Fall ist, wenn das Echtzeitbetriebssystem in einer sauber konfigurierten VM läuft und damit auch auf einer oder mehreren nur dem RTOS zugeordneten CPUs, dann sollte das zu Ergebnissen führen, die nahezu optimal sind. Und in der Tat zeigen unsere Messungen, dass auf einem x86 System der Unterschied in der Latenz zwischen einem echtzeitfähigen Linux in der root cell und in der VM nur gut 1 µs beträgt (siehe Bild 13).

Container-Einsatz und Echtzeit-Latenzzeiten

Bleibt die Frage, ob Container die Echtzeit und die Performance Anforderungen industrieller Anwendungen erfüllen können. Die Bilder 14 und 15 zeigen, dass der Unterschied im Echtzeitverhalten einer Anwendung zwischen einer Ausführung nativ auf dem Betriebssystem und der im Container praktisch vernachlässigbar ist.

Alle Messungen wurden bei 100% CPU Last innerhalb und außerhalb der Container durchgeführt. Hierzu wurde, wie bei den vorhergehenden Messungen, das Tool hackbench eingesetzt. Ebenso wurden die Netzwerkschnitstelle sowie weitere Schnittstellen (CAN, Disk) mit voller Last beaufschlagt.

Leistungsmerkmale wie CPU Pinning bleiben auch mit Containern verfügbar. Und ein „falsch“ konfigurierter Container (beispielsweise eine Limitierung der maximalen CPU Last) hat keine Auswirkungen auf das Verhalten der RT Task.

Fazit: Hervorragende Echtzeit-Eigenschaften mit Linux

Linux besitzt mit der passenden Erweiterung hervorragende Echtzeiteigenschaften. Aufgrund der hohen Akzeptanz in der Entwicklergemeinde und der einfachen Handhabbarkeit hat sich hierfür der sogenannte PREEMPT_RT Ansatz als Standard etabliert. Die Latenzzeiten dieses In-Kernel Ansatzes sind auf Applikationsebene vergleichbar mit denen von Mikrokerneln (wie Xenomai). Die Mikrokernel können lediglich im Kernel bessere Latenzen erreichen, wobei hier zu berücksichtigen ist, dass hier nicht im Linux Kontext gearbeitet wird, sondern im Mikrokernel (und somit auch mit dessen Restriktionen und API). Wer bereit ist, für bessere Latenzzeiten Restriktionen in Kauf zu nehmen, kann auf ARM basierten Systemen auch mit einer FIQ Lösung und PREEMPT_RT arbeiten. Hiermit sind teilweise Latenzzeiten unter 10 Mikrosekunden zu möglich.

PREEMPT_RT bietet in Summe den besten Tradeoff aus geringen Latenzzeiten und einfacher Handhabbarkeit. Weiterhin ist zu beachten, dass Organisationen wie das OSADL die Qualität des PREEMPT_RT Ansatzes kontinuierlich prüfen.

Eine weitere gute Nachricht ist die Tatsache, dass die Linux Foundation das RTL Projekt ins Leben gerufen hat, das die Integration in den Linux Mainlinekernel über die nächsten Jahre finanziert und vorantreibt. Diese Tatsachen geben dem Anwender zusätzliche Planungssicherheit für zukünftige Projekte und die Pflege bestehender Produkte.

* Jan Altenberg ist Senior Open Source Consultant bei OSADL.

* Heinz Egger ist Geschäftsführer der linutronix GmbH in Uhldingen-Mühlhofen.

(ID:44317182)