HMI HTML5-Hardware-Kommunikation mit PPS-Messaging

Autor / Redakteur: Andy Gryc * / Franz Graser

HTML5 und seine Hilfstechniken (CSS3, JavaScript, AJAX, JSON usw.) bieten eine nicht proprietäre Lösung für die Entwicklung hochfunktionaler geräteunabhängiger Mensch-Maschine-Schnittstellen.

Firmen zum Thema

Abbildung 1: PPS-Clients und Objekte. Client A ist ein reiner Subscriber, Client B ist ein reiner Publisher, und Client C ist sowohl Publisher als auch Subscriber.
Abbildung 1: PPS-Clients und Objekte. Client A ist ein reiner Subscriber, Client B ist ein reiner Publisher, und Client C ist sowohl Publisher als auch Subscriber.
(Quelle: QNX)

Infotainmentsysteme im Fahrzeug vereinen in sich zahlreiche Geräte und Dienste. Vor dem Hintergrund kurzer Release-Zyklen, enger Budgetvorgaben und der Forderung nach Wiederverwendbarkeit erscheint die Entwicklung von HMIs in nativem C/C++-Code als zu teuer und zeitraubend. HTML5 und seine Hilfstechniken (CSS3, JavaScript, AJA, JSON usw.) bieten eine nicht proprietäre Lösung für die Entwicklung hochfunktionaler geräteunabhängiger HMIs.

Unglücklicherweise sieht HTML5 keinen einfachen Weg für die Kommunikation zwischen der HMI und Low-Level-Komponenten vor. Hier bietet sich Persistent Publish/Subscribe (PPS) als Lösung an. PPS ist ein schlankes, offenes Messaging-Modell mit folgenden Vorteilen:

  • Es bildet eine Brücke zwischen der HTML5-Schicht und den Low-Level-Komponenten.
  • Es kann einfach um neue Geräte und Technologien erweitert werden.
  • Es eignet sich für Anwendungen, die unterschiedliche HMI-Techniken verwenden, wie Elektrobit GUIDE und Qt

PPS – Persistent Publish/Subsribe

PPS ist in QNX als objektbasierter Dienst mit sogenannten Publishers und Subscribers in einer lose gekoppelten Messaging-Architektur implementiert. Jeder PPS-Client kann Publisher, Subscriber oder beides, also sowohl Publisher als auch Subscriber, sein.

PPS-Objekte sind in den Pfadnamensraum des Dateisystems integriert, und das Publizieren erfolgt asynchron. Publisher modifizieren Objekte und ihre Attribute und schreiben sie ins Dateisystem. Wenn ein Publisher ein Objekt ändert, informiert der PPS-Dienst die Clients, die das Objekt abonniert haben (die Subscriber des Objekts). Ein PPS-Client kann mehrere Objekte abonnieren, und PPS-Objekte können mehrere Publisher und Subscriber haben. Publisher können also ein Objekt benutzen, um Informationen an alle Subscriber des Objekts zu kommunizieren.

PPS-Clients müssen wissen, welche PPS-Objekte für sie relevant sind. Als Publisher müssen sie wissen, was sie wann publizieren müssen. Als Subscriber müssen sie wissen, welche Objekte sie abonnieren wollen und welche Objektattribute für sie relevant sind. PPS-Clients nutzen die POSIX-API-Aufrufe open(), read() und write(); sie müssen bestätigen, dass sie die gelesenen Daten interpretieren können, und sie müssen bestimmen, ob ihre Leseoperationen blockierend oder nicht blockierend sein sollen. Eine darüber hinausgehende Fehlerbehandlung oder Pufferverwaltung ist nicht erforderlich.

PPS nutzt die Dienste von Standard-POSIX-Dateisystemen und kann daher mit jeder Programmiersprache und in jeder Anwendungsumgebung benutzt werden. Eine in einer Sprache geschriebene Komponente kann mit Komponenten kommunizieren, die in anderen Sprachen geschrieben sind. Es wird kein spezielles Wissen über die anderen Komponenten benötigt.

Wie der Name „Persistent Publish/Subscribe“ schon impliziert, kann ein PPS-Dienst Daten über Neustarts des Systems hinweg beibehalten. Der Entwickler entscheidet, welche Daten persistent sein sollen, indem er einzelne Attribute als persistent definiert.

Abbildung 2: Die QNX CAR-Plattform mit PPS
Abbildung 2: Die QNX CAR-Plattform mit PPS
(Quelle: QNX)
Während PPS ausgeführt wird, hält es seine Objekte im Arbeitsspeicher. Persistente Objekte werden entweder auf Anforderung oder beim Herunterfahren in einem persistenten Speicher gesichert und beim Hochfahren entweder sofort oder beim ersten Zugriff wiederhergestellt. Für den zugrunde liegenden persistenten Speicher werden ein Dateisystem und ein Speichermedium (Festplatte, NAND- oder NOR-Flash) benötigt.

PPS kann das Hochfahren vereinfachen. Bei vielen Messaging-Modellen benötigt ein Client, der erst nach dem Server aktiv wird, oder der im weiteren Verlauf irgendwann die Verbindung verliert, eine Datenaktualisierung, da sich unterdessen etwas geändert haben könnte. Bei PPS dagegen stellt der Dienst seine persistenten Objekte beim Hochfahren wieder her und behält sie bei. Wenn ein Client startet oder sich erneut verbindet, erhält er einfach durch Lesen dieser Objekte die aktuellen Daten.

(ID:42221258)