Migration
Neue Funktionen und Technologien bzw. die nicht mehr ausreichende Leistungsfähigkeit der bestehenden Hardware/Betriebssystem-Kombination, die Abkündigung von Hard- und Software-Bestandteilen oder auch eine erwünschte Stückkostenreduzierung können eine Migration zu einem neuen System notwendig machen. Linux stellt aufgrund der zahlreichen Vorteile auch hierfür eine Option dar, für die grundsätzlich vier unterschiedlich praktikable Arten von Embedded Linux zur Verfügung stehen. Linux im Eigenbau ist die ursprünglichste, allerdings auch mit erheblichem nicht-differenzierendem Aufwand und hohem Projekt-Risiko verbundene Variante. Freie Linux-Distributionen wie Fedora, OpenSuse oder Debian eignen sich aufgrund der Fokussierung auf x86-CPU-Architektur und -Server häufig nicht für Embedded-Projekte. Von Hardware-Herstellern angebotene Linux-Versionen sind oft nicht aktuell und werden selten über einen längeren Zeitraum gewartet und unterstützt, scheiden damit trotz leichten Einstiegs als Zielplattform oftmals aus. Kommerzielles Linux, wie beispielsweise Wind River Linux, bietet Vorteile wie Offenheit, Source Code, breite Unterstützung und vermeidet zugleich die genannten Nachteile der anderen Varianten (Bild 1). Für welche Variante sich ein Unternehmen auch entscheidet: Eine Migration ist in jedem Fall umfangreich und nicht ganz einfach. Deshalb sollte die Wahl der geeigneten Linux-Variante bewusst und mit Weitblick getroffen werden. Da in einem bestehenden Produkt die Applikation praktisch immer den Mehrwert und damit das Unterscheidungsmerkmal gegenüber dem Mitbewerber darstellt, steht sie an erster Stelle auf der Migrationsliste. Die notwendige Middleware, also die Software, die den Betrieb der Applikation ermöglicht, ist ebenfalls oft mit spezifischen Funktionen angereichert, sodass eine Migration ebenfalls erwogen werden sollte. Allerdings nutzen viele Middleware-Implementierungen Betriebssystem-spezifische Funktionen so intensiv, dass sich eine Migration im Vergleich zu einer Neuimplementierung nicht in allen Fällen rechnet. Prinzipiell gibt es drei praktikable Methoden, Anwendungen auf Linux umzusetzen. In Bild 2 ist beispielhaft das Wind River Professional Services-Migrations-Modell abgebildet. Das Applikations-Redesign ist sicherlich mit dem größten Aufwand verbunden, bietet jedoch am ehesten die Möglichkeit, die Vorteile und Besonderheiten von Linux optimal zu nutzen. Die Portierung von bestehendem Source Code bietet sich an, wenn die verwendete API (z.B. Unix oder Posix) und der innere Aufbau der Anwendung zu Linux ähnlich sind. Für den Source Code, der zu stark mit der bisherigen Betriebssystem-API verwoben ist, sollte entweder eine API-Zwischenschicht, die zwischen bisheriger OS-API und Linux-API vermittelt, eingezogen oder gleich die Applikation samt dem bisherigen Betriebssystem zusammengepackt und auf Linux aufgesetzt werden.
Linux-spezifischer Migrationsaufwand
Daneben gibt es Linux-spezifische Aspekte, die bei der Migration zu beachten sind. Die zusammengehörenden bisherigen RTOS-Tasks wird man in Linux-Threads unterhalb eines oder mehrerer Linux-Prozesse zusammenfassen. Dabei ist die Trennung in Userspace und Kernelspace zu berücksichtigen. Auch der Übergang von einem sehr häufig verwendeten flachen Speichermodell mit physikalischen Adressen in eines mit virtuellen Adressen und durch die MMU geschützten Bereichen wird manche Codeänderung notwendig machen. Die Interprozesskommunikation und -synchronisation sollte – sofern ähnliche Mechanismen verwendet werden – beibehalten werden. Das Linux zugrunde liegende Benutzer- und Dateikonzept ist bei kaum einem anderen RTOS derart ausgeprägt, dass sich auch hier Nachbesserungsbedarf abzeichnet. Gerätetreiber lassen sich nicht wirklich sinnvoll migrieren; hierfür sollte man eine Neuimplementierung einplanen. Beim Hardware-Design ist der Speichermehrbedarf (RAM, Flash) von Linux im Vergleich zu einem RTOS zu berücksichtigen. Neben einer JTAG-Schnittstelle sollte auch je eine serielle und eine Ethernet-Schnittstelle zum leichteren Testen und Fehlerfinden vorhanden sein, zumindest auf dem Entwicklungs-Board.
