Die ARM-Prozessortechnologie, wie sie in Tablet-PCs und Smartphones zum Einsatz kommt, findet auch große Nachfrage bei den Anwendern von Embedded-Computer-Technologie. Mit den neuen Prozessoren lassen sich nämlich auch sehr effiziente neue Embedded-Designs entwickeln. Anwendungsbereiche reichen vom robusten Handheld-Gerät für die Logistik bis hin zum schlanken stationären Multi-Touch-GUI für Geräte, Maschinen und Anlagen unterschiedlichster Art. All diese Applikationen profitieren von der attraktiven Grafik und Leistung, die bei einer sehr geringen Leistungsaufnahme im unteren einstelligen Wattbereich geboten wird. Jede ARM-Core-Variante hat jedoch ein individuell zusammengestelltes Featureset. Prozessoren, die auf dem gleichen Core wie beispielsweise ARM Cortex A9 oder A8 basieren, sind also je nach Hersteller ganz unterschiedlich ausgelegt. Das ist vorteilhaft für die Differenzierung der jeweiligen Lösungen. Eine Applikation, die für den Freescale-i.MX6-Prozessor geschrieben wurde, lässt sich aber nicht ohne Weiteres auf einem Nvidia-Tegra-3-Prozessor oder gar Ti Sitara AM3874 nutzen. Eine höhere Skalierbarkeit über Prozessorgenerationen hinweg wäre aber für viele Embedded-Applikationen wünschenswert. Möglich wird das aber nur, wenn man weitestgehend identische Building Blocks benutzt. Für Applikationsentwickler wichtige Building Blocks sind dabei insbesondere der homogene Betriebssystem- und Treiber-Support.
Identische Building Blocks stehen jedoch nicht automatisch zur Verfügung, denn der Betriebssystem-Support fällt bei ARM deutlich heterogener aus als es bei x86er-Prozessoren der Fall ist. Betrachtet man die Frage nach der Wahl des Betriebssystems, so stehen zwar auch bei ARM zwei wesentliche Alternativen zur Auswahl: Windows oder Linux/Android. Und die Entscheidungskriterien für das eine oder andere OS sind vergleichbar mit denen bei der x86er-Technologie. Allerdings muss man die Entscheidung unter verschärften Bedingungen treffen, da in der Summe der Support bei ARM noch vergleichsweise kleiner als bei der x86er-Technologie ist. Doch was bedeutet das konkret? Unterstützt Windows den gewünschten ARM-Prozessor, so bringt dieses OS immer auch Lizenzkosten mit sich. Dies allerdings gepaart mit dem Vorteil, dass es ein klar definiertes OS ist, das an einer zentralen Stelle gepflegt wird. Nachteilig kann sein, dass bei Windows wenige Softwareteile als Open Source zur Verfügung stehen. Somit ist Windows - abgesehen von den individuellen Konfigurationsmöglichkeiten - nur an wenigen Stellen in Eigenregie anpassbar.
OS-Supportfrage geklärt
Auf der anderen Seite gibt es für solche Aufgaben einen gut definierten Support und die IP-Inhaber bieten kommerzielle Anpassungsdienste an - so auch Hardwareanbieter, die ein eigenes Windows-BSP für ARM entwickelt haben und für dieses auch individuelle Kundenwünsche realisieren. Eine solche Lösung ist für viele Kunden, die aus der Windows-Welt kommen, interessant, da hier die eingearbeiteten Experten schnell zu einem Ergebnis kommen. Beim alternativen Linux/Android entstehen keine Lizenzkosten. Dafür gibt es ohne Serviceverträge aber auch keine Unterstützung. Kostenlos ist Linux deshalb aber nicht unbedingt. Linux kann nämlich zu Folgekosten führen, wenn eine ehedem verfügbare Funktion nicht mehr „automatisch“ von der Community für den kommenden Kernel kostenlos angepasst wird. Das kann öfter passieren als man denkt: Die Open Source Community arbeitet nämlich überwiegend nach dem Eigenbedarf. Jeder entwickelt für seine Hardware nur das, was er gerade braucht. Sobald es funktioniert, ist man aber nur noch bedingt daran interessiert, es auch für andere oder kommende Kernel anzupassen. Der offizielle Linux-Kernel entwickelt sich aber ständig weiter. Deshalb ist es gut möglich, dass die zuvor entwickelten Pakete zukünftig nicht mehr passen.
Vor- und Nachteile der Vielfalt
Hinzu kommt die Vielfalt an Linux-Varianten, die Vor- und Nachteil zugleich ist. Variierende Linux-Distributionen haben oft nur minimale, aber dafür entscheidende Unterschiede. Perfekt kann sein, dass die individuelle Distribution exakt das abdeckt, was man braucht. Das hat gleichzeitig aber auch Auswirkungen: Software-Pakete - also auch Treiber - können zu mancher Linux-Variante nicht passen. Hier kann es also zu Problemen kommen. Entweder läuft das Software-Paket gar nicht oder das Software-Paket ist dafür nicht getestet. Letzteres kann unter Umständen zu nur schwer erkennbarem Fehlverhalten führen, das mitunter erst spät im Produktiveinsatz im Feld entdeckt wird. Das kann man bei professionellen Embedded-Applikationen nicht dulden. Deshalb ist es wichtig, darauf zu achten, für welchen Kernel und welche Linux-Variante ein Treiber freigegeben wurde. BSP-Hersteller wie Kontron beschreiben deshalb genau, für welche Kernel-Versionen die BSPs entwickelt und getestet wurden. Kunden, die einen anderen Kernel bevorzugen, sollten passende Entwicklungs- und Testdienstleistungen einplanen und gegebenenfalls zukaufen.Aber ganz gleich, welches OS man letztlich einsetzt; eines gilt für sowohl Windows wie Linux: Je spezifischer die Geräte und SoCs, umso mehr individueller Entwicklungsaufwand ist notwendig.
Mainstream bedeutet Zukunftssicherheit
Im Umkehrschluss gilt aber auch: Je weiter eine Komponente verbreitet ist, desto wahrscheinlicher ist es, dass sie langfristig auch über mehrere OS-Varianten hinweg gepflegt werden. Je mehr fertige Mainstream-Building-Blocks man also einsetzen kann, desto zukunftssicherer ist die Gesamtlösung.Die Verwendung von ARM-Prozessortechnologie ist derzeit jedoch insbesondere bei extrem spezialisierten Geräten gegeben, die sehr viel individuelle Softwareentwicklung erfordert haben. Vergleichsweise gering ist derzeit jedoch die Verbreitung in Applikationen, die auf generischere Konfigurationen setzen, wie sie auch bei x86er-Embedded-Computer-Technologie zum Einsatz kommt. Anwender wollen dies aber umsetzen. Beispielsweise smarte Multitouch-GUIs für HMIs. Deshalb wurde es erforderlich, dass ein Computer-on-Module-Standard entwickelt wurde, den Entwickler als hoch integrierten applikationsfertigen Mainstream-Building-Block nutzen können.
SMARC hat OS-Support bereits integriert
Mit der SMARC-Computer-on-Module-Spezifikation der SGET wurde ein solcher Computer-on-Module-Standard geschaffen. Eine Systemkonfiguration, die auf dem SMARC-Standard als Mindestanforderung basiert, erhält dabei bereits ohne Zutun des OEM-Kunden höchsten OS-Support für Embedded-Devices, da alle Standardschnittstellen bereits im BSP-Support der SMARC-Module-Hersteller unterstützt werden. Zudem entwickelt die Module-Community auch Design-Guides für Carrierboards. Dies hilft auch jedem OEM-Carrierboard-Entwickler bei wichtigen Designentscheidungen. Bei der Auswahl der Peripheriekomponenten sollte man übrigens nicht in erster Linie auf den Preis achten, sondern auf die Verbreitung - ein etwaiger Mehrpreis kann nämlich durch stabile, bereits verfügbare Treiber leicht wettgemacht werden. Bei Computer-on-Modules wie SMARC ist zudem davon auszugehen, dass auch zukünftig vergleichsweise viele OS-Varianten unterstützt werden, da viele Kunden diese Modul einsetzen und damit der Entwicklungsaufwand für die jeweiligen BSP durch viele Anwender getragen wird. Es spricht also auch bei sehr individuellen Anforderungen und dem Wunsch nach einem Full-Custom-Design einiges für den Einsatz von fertigen Building Blocks, wie sie SMARC-Computer-on-Modules darstellen. Welche Mainstream-Building-Blocks das sind, kann man beispielsweise an der Prozessorauswahl ablesen, die Unternehmen wie Kontron unter Abwägung der unterschiedlichen Marktbedürfnisse getroffen haben.
Die optimale Arbeitsteilung
Wie sieht abschließend betrachtet die optimale Zusammenarbeit zwischen Modul-Lieferant und Applikationsentwickler aus? Es sollte eine klare Aufgabenteilung vereinbart werden. Der Hardwarelieferant sollte sich in erster Linie um die Hardware (Modul plus Carrierboard oder Full-Custom-Design), Firmware (BIOS/Bootloader), Treiber und das gesamte Betriebssystem kümmern und der Applikationsentwickler um das GUI/Userinterface, die Steuerungsapplikation und natürlich die wichtigsten Anforderungen des Users. Einigt man sich auf diese generelle Arbeitsteilung und fordert man applikationsfertige Plattformen, gehört auch die Konfiguration des OS-Images zur Aufgabe des Hardwarelieferanten. Und das ist sinnvoll, denn gerade ARM-Plattformen brauchen eine passgenaue Abstimmung des OS, Bootloaders und BSPs.
