openABK ist die offene Definition einer Schnittstelle zum Datenaustausch und zur Bedienung zwischen Datenloggern und intelligenten Displays. Sie basiert auf einem Client-Server Prinzip.
Darüber hinaus kann diese Schnittstelle auch für weitere Zwecke herangezogen werden. Man könnte z.B. zum Überwachen eines Fahrprofils die aktuellen Daten von einem Datenlogger auslesen und mit dem Sollwert vergleichen und damit anschließend Anweisungen generieren. Auch die Visualisierung von Prozessen ist denkbar.
In fast allen Fällen der Datenerhebung mit einem Datenlogger wird eine Live-Datenanzeige der Messdaten benötigt. Darüber hinaus sollen oft Abläufe des Messvorgangs vom User gesteuert werden können. Hierzu ist eine Interaktion zwischen Logger und Display notwendig. Wie dieser Datenaustausch von statten geht, wird mit openABK erstmalig definiert.
Durch die Definition des Datenaustauschs (nachfolgend auch Protokoll genannt) wird es möglich, Komponenten mehrerer Hersteller zusammen arbeiten zu lassen. Für den Anwender bringt dies Flexibilität und multiple Sourcing, während Lieferanten ihr Produkt aufwerten können, indem es mit openABK vielseitiger eingesetzt werden kann.
Ein von Anfang an offenes Protokoll bringt für alle Teilnehmer insofern Planungssicherheit, indem es von Lieferanten weder proprietär definiert noch unter Verschluss gehalten werden kann.
Die strikte Trennung von Daten und Layout lässt die Pflege von Systemen leichter gestalten.
Ebenso steht ein möglichst geringer Pflegeaufwand der Systemkonfiguration im Vordergrund: Oft ist es notwendig, für eine ganze Flotte nur ein Layout zu pflegen. Dazu müssen neben den Messdaten auch Auskünfte über die Messstellen übertragen werden können.
Zunächst existierte aus Anwender-Sicht der Wunsch nach einer Schnittstelle zum Anzeigen und Bedienen von Messungen mit Datenloggern. 2012 ergriff BMW die Initiative, ein Konzept und dessen Ausarbeitung zu vergeben. In Zusammenarbeit mit BMW, CAETEC, G.i.N., Vector Informatik und EMBU-Sys wurde ein geeignetes Konzept erstellt. Ende 2012 wurde die detaillierte Ausarbeitung als erstes Release von openABK fertiggestellt. Fast zeitgleich bekundeten einige Lieferanten erstes Interesse an openABK für ihre Geräte. 2013 erfolgten die ersten Umsetzungen durch CAETEC, G.i.N. und EMBU-Sys.
Von Anfang an wurde beschlossen, dass openABK, wie der Name schon ausdrückt, offen sein muss. Für das Anwenden, das Verbreiten, die Einsichtnahme und das Kopieren von openABK dürfen keine Lizenzen oder Gebühren verlangt werden. Kein Lieferant darf die Rechte an openABK halten oder dies behaupten. Die spezielle Implementierung von openABK als Geräte-Feature darf hingegen selbstverständlich mit einem Aufpreis versehen sein, da die Implementierung auf das Gerät Aufwand des Lieferanten verursacht.
Für die Koppelung von Datenlogger und Display und oder Eingabegerät stehen mit openABK folgende Merkmale zur Verfügung:
Um den Integrationsaufwand so gering wie möglich zu halten, müssen Geräte nicht alle Merkmale unterstützen.
Die Übertragung der Daten erfolgt über HTTP. Ein Client (z.B. Display oder Eingabegerät) sendet Requests an den Server (z.B. Datenlogger oder Messverstärker).
Die zu sendenden und empfangenden Daten sind in den HTTP-Anfragen und Antworten als JSON-Objekte formatiert (siehe www.json.org). JSON bietet gegenüber XML ein kompakteres Format und es sind die Datentypen Numeric, String und Boolean spezifiziert. Lediglich das Datums-Format musste in openABK eigens definiert werden.
Messwerte werden im einfachsten Fall vom Client durch Polling abgefragt. Als effizientere Alternative bietet openABK mit der gebündelten Übertragung mehrerer Messwerte mittels DAQ-Listen (Data AcQuisition List). Diese werden über das sogenannte Long-Polling-Verfahren ausgetauscht.
Bevor eine Datenübertragung jedoch praxisgerecht erfolgen kann, ist eine Synchronisation zwischen Client und Server notwendig: Um ein Layout auf einem Display generisch zu halten, stellt ein Server eine Aufzählung der verfügbaren Messstellen sowie deren Metadaten bereit. Metadaten sind u.a. die Einheit, der Wertebereich, der Kommentar. Ein Display kann hiermit z.B. Listen automatisch füllen und weitere Anzeigeelemente während der Laufzeit durch User-Interaktion dynamisch belegen.
Sowohl ein Client als auch ein Server können Ereignisse signalisieren. Diese sind in openABK generisch definiert. Spezielle Fälle, die in der Messtechnik häufig vorkommen, sind auf Basis der generischen Definition von openABK vordefiniert. So ist z.B. das Signalisieren einer Grenzwertverletzung in openABK definiert.
Ein Ereignis verdient hier besondere Aufmerksamkeit: Das Ablaufen eines Zyklus einer DAQ-Liste stellt ein Ereignis dar, das der Server dem Client mitteilt. Direkt angeheftet an das Ereignis sind die aktuellen Messwerte der DAQ-Liste.
Unter openABK gibt es zwei Arten der User-Interaktion: Formulare und Dialoge.
Formulare sind wie ihre Pendants auf Papier zu verstehen: Das
Formular bringt das Schema und der User füllt die Felder
entsprechend des Schemas aus. Der Server hält dafür Formulare mit
Eingabefeldern bereit, die auch vorbelegt sein können. Ein Event
des Servers zeigt an, dass Eingaben eines Nutzers für ein Formular
erforderlich sind. Nun kann sich ein Client solch ein Formular laden
und den vom User ausgefüllten Inhalt an den Server zurückgeben - und
zwar als Client-Ereignis.
Sind mehrere Clients im System, so öffnet nur der Client mit der
primären Rolle das Formular.
Auch das von Servern unaufgeforderte Ausfüllen von Formularen durch
Clients ist vorgesehen, etwa das Konfigurieren von Parametern wann
immer der User es will.
Dialoge können je nach Anwendung sehr unterschiedlich ausfallen. Daher kann für sie kein generisches Layout wie bei Formularen angewandt werden. Das Layout sollte daher vom Display stammen, was ja auch der strikten Trennung von Layout und Daten entspricht. Das Öffnen, Schließen und dynamische Inhalte sowie der eigentliche Datenaustausch werden hier über Custom-Events und Custom-Mailboxen bewerkstelligt.
Vor die Kommunikation beginnen kann, muss ein Client die IP-Adresse des gewünschten Servers kennen. Dies kann entweder durch interaktive Eingabe (z.B. Browser) oder durch die Discovery-Funktionalität von openABK erfolgen:
Ein Client sendet UDP-Broadcasts mit eigenen Eckdaten aus und erhält von Servern Antworten mit deren jeweiligen Eckdaten. Zusätzlich können verbindungsrelevante Konfigurations-Einstellungen vom Server mitgeteilt werden, um z.B. in Multi-Client/Multi-Server-Systemen einem Client die Verbindung zum gewünschten Server entsprechend der System-Konfiguration zu zuweisen.
Teil des Konzepts ist die einfache Integration. Diese wird sowohl durch einfache Strukturen als auch durch Bereitstellen von fertigem Code erreicht:
Logger-Kern: In einem Logger
werden üblicherweise die Messdaten von den Schnittstellen eingelesen
und anschließend gespeichert. An dieser Stelle können die aktuellen
Messdaten abgegriffen werden.
HTTP-Server: Meist ist in Loggern
bereits ein Web-Interface und damit ein HTTP-Server enthalten. Ist
dies nicht der Fall, so kann z.B. der Open-Source
Mongoose-Server auf
praktisch allen Plattformen eingesetzt werden.
Wie gelangen die Daten nun vom Logger-Kern zum HTTP-Server? Eine
C++ openABK-Server-Implementierung
filtert openABK HTTP-Requests in einer HTTP-Server-Callback-Routine
und behandelt die Beantwortung relevanter Requests. Die dafür
benötigten Messdaten werden von virtuellen Funktionen aus dem
Logger-Kern abgefragt. Die überschaubare Anzahl dieser virtuellen
Funktionen definieren Sie als Logger-Entwickler beim Erben diverser
Klassen.
Anzeige-Elemente: Bei der
Visualisierung kommen Anzeige-Elemente zum Einsatz, die nicht der
Definition von openABK unterliegen.
HTTP-Client: Für HTTP-Clients gibt
es je nach Plattform unterschiedliche Implementierungen. In der
Regel wird über einen Funktionsaufruf ein Request gesendet und als
Rückgabe erhält man die HTTP-Response. In JavaScript ist dies z.B.
XMLHttpRequest().
Als Brücke zwischen den Anzeige-Elementen und dem HTTP-Client gibt
es im Zuge von openABK Beispielcode in
JavaScript und C++ unter Verwendung von ATL.