So lange ist es noch nicht her, dass die eingebettete, Echtzeit-abhängige Entwicklerwelt der Open-Source-Software mit großer Skepsis begegnete; man hielt sie für zu umfangreich, zu langsam, zu riskant und zu teuer. Ihre Echtzeitfähigkeit wurde ebenso angezweifelt wie ihre Portierbarkeit, ihre Sicherheit und ihre Zertifizierungsmöglichkeit. Inzwischen hat ein grundsätzlicher Umdenkprozess stattgefunden: Besonders das Betriebssystem Linux hat das Bastler-Image abgestreift und konnte vor allem die industrielle Branche durch erfolgreiche Referenzprojekte davon überzeugen, dass es an sämtlichen kritischen Stellen im Embedded-Bereich eingesetzt werden kann.
Kraftvolle Kollaboration
Als Folge ständiger Weiterentwicklung und Erweiterung durch Tausende von Entwicklern sowie durch die Verfügbarkeit neuerer Plattformen hat Linux an Beschleunigung gewonnen, die Funktionalität hat sich schrittweise gesteigert, und der typische Kreislauf - Integration, Aufbau, Test, Freigabe - sorgt dafür, dass sich nach wie vor ständig neue Welten erschließen. Offene Echtzeit-Embedded-Systeme sind zum integralen Bestandteil unserer technischen und sozialen Welt geworden, der gemeinschaftliche virtuose Umgang mit Wirtschaftlichkeit und Sicherheit hat Früchte getragen. Die „kraftvolle Form der Kollaboration“, wie sie ein Open-Source-Anhänger definierte, ermöglichte neben Linux auch Firefox, Apache oder Wikipedia.Nach anfänglicher Skepsis hat sich Linux mittlerweile zu einem der bevorzugten Betriebssysteme in Embedded-Systemen entwickelt. Linux unterstützt praktisch sämtliche einschlägigen Prozessorarchitekturen und Hardwaregeräte und liegt damit klar vor seinen Konkurrenten. Das befürchtete Problem der Portierbarkeit von der x86-Architektur wurde rasch zufriedenstellend gelöst; es gibt längst hochentwickelte Lösungen für die ARM- und PowerPC-Prozessoren mit allen Facetten.Hardwarehersteller beschreiten gerne den anscheinend einfachen Weg: Man nehme den Kernel-Source-Code, entwickle die Unterstützung für eigene Hardware und liefere dieses Paket aus. Dieses Verfahren ist zwar nicht sonderlich aufwändig und rasch durchführbar, er reicht aber für die Aufgaben und Vorstellungen industrieller Anwender meist nicht aus. Diese erwarten von Linux die vom Mainline-Kernel gewohnte hohe Qualität, die auch den bekannten Distributionen für PC und Server eine stabile Basis bietet. Vor allem wollen sie sich auf ihre Anwendung konzentrieren, und sich nicht mit der Fehlersuche dicht an der Hardware beschäftigen müssen. Eine Lösung bietet der Mainline-Prozess: Alle drei Monate wird der so genannte Mainline-Kernel veröffentlicht. Über die Maintainer werden neue Funktionen aufgenommen, diskutiert und auf Qualität überprüft. Anschließend folgen Tests und Stabilisierungen. Dieser Weg sollte auch beim Portieren neuer ARM-Hardware in den Kernel eingeschlagen werden, und zwar möglichst in kleinen Schritten: Kernel-Ports mit nur einer Funktion werden zur Diskussion gestellt. Während der Port bei den Entwicklern wächst, finden bereits die ersten Code-Fragmente ihren Weg durch die Revue in die Mainline.
Problemfall Echtzeitfähigkeit
Lange Zeit galt die Echtzeitfähigkeit als Ausschlusskriterium für den Einsatz von Open-Source in Embedded-Systemen. Grundsätzlich sollte festgehalten werden, dass echtes Real-Time-Verhalten häufig gar nicht erforderlich ist. Dennoch wird es angestrebt, um angesichts der langen Lebensdauer vieler Embedded-Systeme sicher zu gehen, dass den möglichen Anforderungen an deterministisches Antwortverhalten auf zeitkritische Events kommender Applikationen und Versionen Rechnung getragen wird. Man hielt es lange für unmöglich, den Kernel eines bereits vorhandenen OS nachträglich mit Echtzeitfähigkeit auszurüsten. Der charakteristische rasche Task- und Kontextwechsel stellt hohe Ansprüche an die korrekte Serialisierung von Zugriffen auf exklusive Ressourcen des Betriebssystems und der Hardware. Andererseits lassen sich dadurch Fehler rascher und zuverlässiger entdecken. Die Folge einer gefundenen Lösung ist eine allgemeine Qualitätsverbesserung des Kernels, die den Systemen auch im „normalen“ Betrieb ohne Echtzeit-Fähigkeit zugutekommt. Ein universelles System mit Echtzeitverhalten erfüllt die hohen Ansprüche, die beispielsweise die Automatisierungsindustrie, die Luft- und Raumfahrttechnik, Finanzdienstleistungen oder Multimediasysteme stellen. Deshalb nahmen die Softwareentwickler nicht nur den Lösungsansatz mit einem Kernel, sondern auch noch eine Alternative mit zwei Kerneln in Angriff. Bei Letzterem übernimmt ein vorangestellter Micro- oder Nano-Kernel die Real-Time-Tasks - die Methode wurde auch schon für DOS und Windows eingesetzt. Erst wenn dieser µ-Kernel in der Warteschleife läuft, erhält der Linux-Kernel Rechenzeit. Allerdings wurden die dafür erforderlichen Anpassungen von Linux nicht in den offiziellen Linux-Kernel aufgenommen. Mittlerweile gibt es einige bewährte Varianten derartiger Dual-Kernel-Systeme, beispielsweise RTAI, Xenomai oder RTLinux/RTCore. Schwieriger war die Entwicklung des Single-Kernel-RT-Linux. Zunächst mussten alle potenziellen Latenzquellen ausgemacht und dafür Umgehungsmechanismen gefunden werden. Zu den größeren Problemen zählte die Prioritätsumkehr: Wenn ein Prozess mit hoher Priorität Zugriff auf eine nur einmal vorhandene Ressource benötigt, diese aber gesperrt ist, weil sie von einem Prozess mit niedrigerer Priorität blockiert wird. Als Lösung kommt die Prioritätsvererbung in Frage, zu der Linus Torvalds jedoch erst 2006 zustimmte. Erst dann konnten die in einem Patch zusammengefassten Echtzeitkomponenten eingebaut werden; diese Linux-Erweiterungen werden als PREEMPT_RT-Patch bezeichnet. Sie ermöglichen erstmals die parallele Echtzeitverarbeitung auf einem einzigen System, weil durch Multicore-Prozessoren mehreren Prozessen die gleiche höchste Priorität zugeordnet werden kann.
Einsatz in sicherheitskritischen Umgebungen
Da das Entwicklungsverfahren von Linux definitionsgemäß nicht zertifiziert ist, ist der Einsatz in sicherheitskritischen Umgebungen nach wie vor noch nicht bis ins letzte Detail gelöst. Dennoch gibt es praktikable Ansätze: Der von einer Reihe von Zertifizierungsverfahren geforderte Nachweis, dass die Software besonders hinsichtlich der Überprüfung (Code Review) und der Fehlerverfolgung (Bug Tracking) in einem vergleichbaren Verfahren entwickelt wurde. Mittlerweile zeigen erfolgreiche Linux-Projekte, beispielsweise in der Verkehrstechnik, dass die Software durchaus und zuverlässig für sicherheitskritische Umgebungen zertifiziert werden kann.
