Cross-Plattform-Middleware Hardwarezugriff leicht gemacht

Bild 1: Neben standardisierten Programmierschnittstellen bietet das »Kontron EAPI« auch ein eigenes GUI, mit dem sich nicht nur beispielsweise Temperatur und Taktrate auslesen, sondern auch Zielwerte setzen lassen.
Bild 1: Neben standardisierten Programmierschnittstellen bietet das »Kontron EAPI« auch ein eigenes GUI, mit dem sich nicht nur beispielsweise Temperatur und Taktrate auslesen, sondern auch Zielwerte setzen lassen.

Embedded-Applikationen greifen im Gegensatz zu »normalen« Anwendungsprogrammen oft auf fundamentale Hardwarefunktionen zurück. Dadurch entsteht erheblicher hardwarenaher Entwicklungsaufwand. Hinzu kommt, dass sich die Befehlsaufrufe für diese Hardwarefunktionen von Board zu Board erheblich unterscheiden können. Eine standardisierte Cross-Plattform-Middleware kann die Entwicklungsaufwendungen signifikant reduzieren.

Entwickler von Embedded-Anwendungen stehen vor einer ganzen Reihe von Herausforderungen, die es hardwarenah umzusetzen gilt. Hierbei sind nicht alle Funktionen so standardisiert, wie der Zugriff auf PCI-Express-Schnittstellen. Beispiele sind Initialisierungsfunktionen für die jeweilige Embedded-Plattform - ob Motherboard, Computer-on-Module (COM), System-Host-Board (SHB) oder kompletter Box-PC - oder die Konfiguration des Speicherzugriffs, die Ansprache der über I²C oder GPIO angebundenen Speicherbausteine und die Festlegung der Funktionsweise des Watchdogs.

Aber auch GUI-orientierte Funktionen wie die Backlight-Steuerung von LCD-Panels sind genauso wenig standardisiert, wie beispielsweise die Bereitstellung grundlegender Systeminformationen (CPU, Speicher, HDD, Akku, etc.), Temperatur- und Spannungsanzeigen, CPU-Leistung und Temperaturkontrolle. Kaum weniger als hundert Funktionen sind überschlägig also immer individuell auszulegen.

Eine Vielzahl dieser Anbindungen sind dabei tief in die jeweiligen Anwendungen eingebettet: Ein über I²C-Bus angeschlossener Not-Aus-Schalter kann beispielsweise - je nach Sicherheitskonzept - ganz unterschiedliche Funktionen auslösen. Eine Temperaturüberschreitung kann je nach Anwendung das Hochfahren des Lüfterstroms oder aber die Heruntertaktung der CPU-Leistung bewirken. Ein Watchdog-Signal kann ein ganzes System rebooten oder aber nur einen spezifischen Thread neu starten.

Was ist jedoch die Konsequenz daraus für den Anwendungsentwickler? Er muss seine Anwendung auf jeder neuen Hardware neu validieren, verifizieren und gegebenenfalls umprogrammieren. Das kann auch schon bei kleinsten Änderungen der Embedded-Hardware gelten. Nicht zuletzt deswegen ist die Langzeitverfügbarkeit von Embedded Systemen eine der wichtigsten Anforderungen vieler Entwickler. Doch das ist für viele Anwendungen noch immer deutlich zu kurz gedacht: Maschinenbauer oder Medizingeräteentwickler entwickeln ihre Steuerungen stets weiter, doch viele Basisfunktionen bleiben über Jahrzehnte hinweg erhalten und müssen laufend auf komplett neue Plattformen mit neuen, zumeist erweiterten Funktionen migriert werden.

Wollen die Entwickler beispielsweise wegen Grafikvorteilen auch den Prozessorhersteller wechseln, ist davon auszugehen, dass ein komplett neuer Verifikations- und Validierungsprozess ansteht. Um diesen zu vermeiden, werden neue Plattformen oft nicht einmal evaluiert, wenn die hardwarenahen Funktionen tief in der Anwendung verwurzelt sind und die APIs (Application Programming Interfaces, Programmierschnittstellen) gleichzeitig stark variieren. Letzteres ist übrigens auch ein Grund, weshalb die OEM-Kunden sehr konservativ bei der Wahl der Formfaktoren sind. Zwar ist hier der generische Erweiterungsbus, beispielsweise beim Umstieg von PCI auf PCI-Express, noch immer der vordergründig wichtigere Aspekt, der Aufwand für die knapp hundert weiteren hardwarenahen Funktionen führt jedoch bisweilen auch alleine zu einem Festhalten an bestehenden Formfaktoren.

API unabhängig vom Formfaktor

Aus diesem Grund war es an der Zeit, die APIs zu standardisieren. Mit seinem »Kontron EAPI« (Embedded Application Programming Interface) spezifiziert der Hersteller Kontron eine Cross-Plattform-Middleware, die für alle Formfaktoren in der Angebotspalette des Unternehmens zukünftig einheitlich sein wird.

Im Grunde ist dies von der Spezifikation her keine besonders technisch anspruchsvolle Aufgabe, denn es geht mehr darum, die jeweiligen Datei- und Befehlsnamen zu standardisieren und plattformübergreifend konfliktfrei verfügbar zu machen. Dies kann jedoch nur von einer Stelle aus geschehen, die Zugriff auf alle relevanten Embedded-Formfaktoren hat.

Da unterschiedliche Organisationen für die Standardisierung verschiedener Formfaktoren verantwortlich sind, ist ein unternehmensgetriebener Ansatz ein besserer Ausgangspunkt. Damit soll es erstmals möglich werden, die Anwendungen 1:1 migrieren zu können, ohne die Prozessorboard-nahen Funktionen umprogrammieren zu müssen. Ein Beispiel ist der Funktionsaufruf »EApiStorageAreaWrite«.

Dieser Call schreibt Daten in einen definierten Benutzerdatenbereich (siehe Kasten). Alleine die Standardisierung der APIs macht das EAPI zu einer nützlichen Zusatzfunktion der Kontron-Plattformen, die sich für OEMs bereits bei ihrer zweiten Entwicklung bezahlt machen und die Migrationskosten signifikant reduzieren kann.

unit32_t
EAPI_CALLTYPE
EApiStorageAreaWrite (
      __IN   unit32_t     Id         ,  /* Storage Ares Id */ 
      __IN   unit32_t     Offset   ,  /*  Byte Offset  */
      __IN         void   *pBuffer  , /*  Pointer to Data pBuffer   */
      __IN   unit32_t     ByteCnt   /*   Number of bytes to write */
);
FUNC_DEF 11: EApiStorageAresWrite

Kontron wird zusätzlich bald Schulungsmaterial und Tutorials bereit stellen, die Entwicklern auch den Einstieg bei der ersten Implementierung erleichtern sollen. Durch die Abstraktion über Middleware lässt sich beispielsweise auch das Schreiben in das BIOS zur Hardware hin verändern, was wiederum die Langzeitverfügbarkeit der Anwendung erhöht.

Als Ergänzung zum EAPI steht ein eigenes GUI für alle Plattformen zur Verfügung. Zum einen stellt dieses Referenzdesign anschaulich und konzentriert die vielfältigen Hardwarezugriffsmöglichkeiten über das Programmierschnittstelle dar und erleichtert so die Parametrierung im Live-System, zum anderen bildet es die Codebasis für kundenspezifische Implementierungen. Und schließlich lassen sich die ebenfalls enthaltenen »Remote-Management«-Funktionen über Ethernet auslesen und mit einem Remote-Hardware-Monitoring aufbessern, um die Verfügbarkeit und Lebensdauer der Systeme durch präventive Instandhaltung zu erhöhen.

Alle diese Funktionen finden sich auf sämtlichen neuen Embedded-Plattformen von Kontron, angefangen von COMs über Boards bis hin zu Systemen. Dieser Ansatz kann auch die Evaluierung von neuen Plattformen beschleunigen, denn Interessenten müssen nicht mehr warten, bis ein spezifischer Formfaktor verfügbar ist, sondern können mit dem Board oder Modul (beispielsweise einem Computer-on-Module) starten, das Kontron zuerst - meist zeitgleich mit der Verfügbarkeit des Prozessors - auf den Markt bringt.

Nehmen Kunden dieses Angebot an, könnte sich auch der Entwicklungsdruck bei Kontron ein wenig besser verteilen, denn dann werden nicht zehn verschiedene Plattformen auf einmal nachgefragt. Als Folge sinken die Kosten, wiederum zum Vorteil der Kunden.