Eingebettetes Linux und Entwicklungsmethoden

Die Entwicklung von Software für Embedded Systems unterscheidet sich meist von der Entwicklung herkömmlicher Anwender- oder Serversoftware. Zwar ist dies nicht immer der Fall, aber in der Regel müssen spezielle Hardware-Anforderungen und Anwendungsfälle berücksichtigt werden und oft unterliegt die Software speziellen Sicherheits- oder Echtzeitanforderungen.

In der Vergangenheit wurde auf Embedded Systems häufig gar kein formelles Betriebssystem eingesetzt, sondern eine problem- und hardwarespezifische Treibersoftware in C oder Assembler (oder anderen, plattformspezifischen Sprachen) geschrieben. Doch auch in diesem Bereich gilt noch das Mooresche Gesetz und aufgrund der rasanten Entwicklung sind heute zu erschwinglichen Preisen Embedded Platforms erhältlich, die vor einigen Jahren mit ihrer Leistungsfähigkeit zur Oberklasse der PC-Systeme gehört hätten. Zugleich werden auch diese Systeme immer komplexer und Detailaspekte wie etwa das Energiemanagement immer wichtiger. Weiterhin verkürzt sich gerade im Consumer-Bereich die zur Verfügung stehende Entwicklungszeit.

Sobald das Embedded System eine gewisse Komplexität überschreitet, ist daher gerade für kleine Firmen der Einsatz einer eigenen, meist monolithisch gewachsenen und schwer anzupassenden, In-House-Entwicklung als Basis nicht mehr praktikabel. In Anbetracht der steigenden Leistungsfähigkeit der Hardware braucht heutzutage auch hier auf den flexiblen Unterbau eines Betriebssystems nicht mehr verzichtet zu werden.

Im Gegensatz zum Betriebssystemmarkt im Desktop- und Serverbereich, herrscht bei den Eingebetteten Systemen seit jeher eine rege Konkurrenz mit diversen Alternativen. Neben den klassischen Marktführern für Echtzeit-Betriebsysteme, VxWorks und QNX Neutrino, existiert eine schier unüberschaubare Auswahl an anwendungs- oder gar herstellerspezifischen Betriebsystemen, wie etwa Symbian für Mobiltelefone und Handhelts. Auch Microsoft hat mit Windows CE nicht die selben Erfolge wie in den anderen Bereichen feiern können.

Aufgrund diverser Vorteile hat sich statt dessen Linux als offene Software-Plattform für dedizierte Geräte etabliert. Die VDC Research Group führt seit 2004 jährlich eine repräsentative Umfrage zu den im Embedded Bereich eingesetzten Betriebssystemen durch. Schon im ersten Jahr führte Linux als Plattform mit 15,5% vor dem ursprünglichen Marktführer VxWorks (10,3%), damals nur übertroffen von Systemen ohne formelles Betriebssystem. Im Bericht von 2008 ist der Anteil auf 18% angestiegen, Tendenz sowohl bei Linux als auch anderen Open Source Plattformen steigend.

Wie schwer die Einteilung von Technologien in starre Kategorien fällt, sieht man schon im Desktop- und Serverbereich: Ein moderner Desktop-Rechner hat mit den landläufig installierten Diensten die fließende Grenze zum Server häufig schon überschritten. Im weit gefassten Embedded Bereich fällt diese Differenzierung noch schwerer und auch hier ist der Übergang zu anderen Kategorien, insbesondere den Appliances (Serversysteme mit dedizierter Funktionalität) und den Thin Clients (Clientsysteme mit eingeschränkter Hardware), fließend.

Es gibt verschiedene Ansätze zur genaueren Definition von Embedded Systems bzw. dem Embedded Development, die jedoch teilweise anderen Definitionen oder der Realität widersprechen. Prinzipiell lässt sich ein Embedded System aufgrund einer oder mehrerer der folgenden Merkmale identifizieren:

Wie bereits erwähnt sind dies nur Anhaltspunkte und Interpretationssache; so bestehen z. B. Vertreter einer sehr engen Auslegung der Definition darauf, dass ein Embedded System in keiner Weise vom Anwender erweiterbar ist. Damit würden jedoch moderne Mobiltelefone oder gar Handhelts nicht mehr als Embedded Systems gelten, eine Interpretation die der allgemeinen Wahrnehmung widerspricht. Auf der anderen Seite erfüllen auch andere Systeme wie z. B. Supercomputer und Nettops (ganz zu schweigen von den bereits erwähnten Appliances und Thin Clients) viele der Kriterien, werden jedoch definitiv nicht zu den Embedded Systems gezählt.

Der Hauptgrund für die Vieldeutigkeit des Begriffs liegt in der geschichtlichen Entwicklung begründet: Ursprünglich wurden als Embedded Development nur die direkte Programmierung einer Hardware bezeichnet. Mit der Zeit wurden die Embedded Platforms leistungsfähiger und näherten sich in Funktionsumfang den PC-Systemen an, während bei diesen wiederum Aspekte der Embedded Platforms (z. B. Energieeffizienz) an Wichtigkeit gewannen. Jörn Engel, Entwickler von LogFS, fasst die Situation treffend zusammen: „Ein Entwickler meint mit einem Embedded System zu arbeiten, wenn es für ihn aussieht wie ein anderes Embedded System mit dem er zuvor schon einmal gearbeitet hat.“

Verbreitet ist die Klassifikationen von Embedded Systems anhand zweier Merkmale: Dem Grad der Benutzerinteraktion und der Größe (im Sinne von verfügbarer Hardware) des Systems.

In Bezug auf die Benutzerinteraktion kann man grob zwischen drei Typen von Embedded Systems unterscheiden:

In der Praxis jedoch ist zur Unterscheidung meist nur relevant, ob das System mit einer grafischen Benutzeroberfläche ausgestattet ist bzw. direkte Benutzerinteraktion vorsieht. Geräten ohne direkte Interaktion sehen häufig nur eine serielle Schnittstelle oder ein Web-Interface zur Konfiguration vor.

Weiterhin spielt häufig die verfügbare Hardware eine Rolle. Anhand der drei Kriterien CPU, RAM und ROM (heutzutage meist EEPROMs oder Flash-Speicher) lassen sich hier grob vier Kategorien erkennen. Die Kriterien sind mit der fortschreitenden Entwicklung der Technik zwar ständigen Änderungen unterworfen, lassen sich aber folgendermaßen abschätzen:

Je nach Größe des Systems müssen unterschiedliche Abstriche an die Software gemacht werden. Auf sehr kleinen Embedded Systems lässt sich z. B. nur bedingt das 32-Bit-Betriebssystem Linux installieren. Es gab zwar mehrere Ansätze, Linux auf 16-Bit-CPUs zu portieren (unter Anderem das Embeddable Linux Kernel Subset), diese waren jedoch weder von Erfolg gekrönt noch in Anbetracht der Preisunterschiede zu 32-Bit-CPUs sonderlich sinnvoll. Für CPUs ohne MMU existiert die Variante uClinux, die seit der Version 2.6 auch Bestandteil des Kernels ist. Auch Portierungen von Linux auf weniger als 4 MiB ROM sind eher umständlich (wenn auch nicht unmöglich, wie z. B. picotux mit nur 2 MiB ROM zeigt).

Wie bereits erwähnt kann es zwar durchaus vorkommen, dass im Inneren des Embedded Systems ein alltägliches x86-System steckt. Doch meist bringt die Entwicklung eines Embedded Systems Hardware-bedingte Unterschiede oder Einschränkungen im Vergleich zur normalen Softwareentwicklung: