Offenes Anzeige-Bedien-Konzept

1. Vortrag auf MessTec& Sensor Masters 2013 erstellt durch: Offenes Anzeige-Bedien-Konzept Anbindung von Display und Eingabegeräten an Daten-Logger

2. Inhalt • Definition, Motivation, Historie • Warum offene Schnittstelle? • Merkmale • Plug and Play • Datenübertragung • Ereigniss-Steuerung • Zusammenfassung der Vorteile • Hardware

3. Was ist openABK? • Schnittstelle füra) Datenaustausch undb) Bedienung • Bindeglied zwischena) Datenloggern, Messverstärkern undb) Displays, Eingabegeräten

4. Motivation • Live-Daten-Anzeige von Messdaten • Bedienen von Testabläufen • Zusammenstellung von Systemen aus Komponenten verschiedener Hersteller • Keine Rechte am Protokoll durch einen Komponenten-Hersteller (Planungssicherheit) • Trennung von Daten und Layout • Angestrebt als offener Standard

5. Historie • Aus Anwender-Sicht: Wunsch nach offener Schnittstelle zum Anzeigen und Bedienen • Initiative von BMW: 2012 Finanzierung für die Ausarbeitung einer offenen Schnittstelle • Zusammenarbeit BMW, Caetec, G.I.N., Vector, EMBU-Sys für erstes Release openABK 2012 • Erstes Interesse bei Komponenten-Herstellern 2012 • Erste Umsetzungen durch G.I.N., Caetec, EMBU-Sys 1Quartal 2013

6. Offenes Interface • Keine Lizenzen/Gebühren • Keine Rechte am Protokoll durch einen Komponenten-Hersteller (Planungssicherheit) • Weitere Komponenten-Hersteller willkommen • Angestrebt als offener Standard • Anschubfinanzierung durch BMW an einem offenen Interface ist Signal für Interesse an Second-Source-Möglichkeiten

7. Anzeigen und Bedienen Display Daten HTTP Logger Streckeneingabe Eingabe Ereignisse JSON Grenzwertanzeige Farben • Anzeigen • Bedienen • Multi-Logger-fähig • Multi-Display-fähig • Multi-Plattform Zykluszeit Dialoge Discovery Textmeldung Mailboxen AJAX • Offen von Anfang an Strings Browser

8. Merkmale • Datenübertragung Live • Bedienen von Abläufen z.B. Trigger • Datentypen String, Fließkomma, Bool, Datum • Plattform-unabhängig (z.B. Linux, Windows, .NET, MFC, Qt, Java-Script auf Browser…) • Multi-Server und Multi-Client • Robuster Unterbau HTTP, JSON • Ereignisse z.B. Taster, Start der Messung • Discovery (gegenseitiges Finden)

9. Discovery (Finden von Geräten) • Client kann alle Server im Netzwerk findenClient sendet UDPbroadcast mit seinen Kennwerten • Server antwortet auf den Broadcast (UDP)Vermerk in der Antwort, falls Client beim Server bekannt ist • => Multi-Client, Multi-Server möglich • Clients im Betrieb austauschbar

10. Datenübertragung • Übertragung der Werte in DAQ-Listen (Data Acquisition List) • Einstellbare Zykluszeiten • Datentypen: Numerisch, String, Bool, Datum • Codierung: JSON über HTTP • Ablauf: Long-Polling-Verfahren

11. Typisches Szenario  Daten Server Client Anfrage der Variablen Abfrage Metadaten Anlegen einer DAQ-Liste Long-Polling Anzeige der Messwerte Rückgabe der Variablen-Liste Rückgabe Metadaten Ablegen der DAQ-Liste Wenn Zyklus der DAQ abgelaufen, Rückgabe der Messwerte

12. Mailboxen • Ähnlich zu den Messdaten • Zum Datenaustausch und Synchronisieren von Abläufen zw. Server und Client • Keine Namenskollisionen mit Messdaten

13. Variablen und Mailboxen Server Client Abfragen (auch ohne DAQ) Variablen (Messwerte) Setzen Mailboxen (Handshake) Separates Halten von Variablen und Mailboxen verhindert Namenskonflikte

14. Ereignisse • Server-Ereignisse an Clientsz.B. Grenzwertüberschreitung • Client-Ereignisse an Serverz.B. Trigger-Taste am Eingabegerät gedrückt • Generische Ereignis-Verteilung und Reflexionz.B. Trigger-Taste an Server, Server reflektiert an andere Clients

15. Ereignisse  Funktionsweise Server Client Long-Polling Wenn Zyklus der DAQ abgelaufen Rückgabe der Messwerte … oder andere DAQ abgelaufen … oder Ereignis eingetroffen Anzeige der Messwerte … und der Ereignisse Auswertung der Ereignisse

16. Dialoge u. Ereignisse  Beispiel Client User Server Ereignis „Messung beendet“Start Datenübertr. WLAN Fortschritt 0..100% … Ende Datenübertragung Öffnen Dialog„Streckeneingabe/ Datenübertragung“Ereignis„Start Datenübertragung“ Zeigt Fortschritt an Schließt Dialog Auswahl WLANO.K.sieht Fortschritt erledigt 100%?

17. Client-Ereignisse  Tasten Server Client 1 Client 2 Empfang„Enter von Client 1“ Ausfiltern Tastendruck „Enter“ Empfang „Enter von Client 1“ Verarbeitung von „Enter“ Ereignis-Empfang Auswertung durch Script Verarbeitung durch Script? nein ja Auslösen einer Aktion

18. Vorteile des Konzepts

19. Schneller ans Ziel • Einfaches Konzept: Client-Server-Architektur über HTTP • Logger  Klassenbibliothek C++ • Display  Beispiel-Software JS, C++ • Spezifikation fertiggestellt • Offen Planungssicherheit

20. Mitwirkende Spezialisten • Schlüssiges und praxisorientiertes Konzept dank kompetenten Mitwirkenden • BMW • G.I.N. • Caetec • Vector Informatik • EMBU-Sys

21. Hardware Desktop Caetec EMBU-TAB 10/7 EMBU-TAB 7..10“ G.I.N EMBU-CANDICE 4..7 weitere weitere weitere… openABK

22. EMBU-CANDICE • SmartDisplay, sonnenlichtlesbar • Größen 4,3“, 7“ • Performante Grafik  GPU • CAN, Ethernet, USB, IR • Touch, Tasten • Lautsprecher, Mikro • Windows™ Embedded Compact • Low-power 4W typ

23. ABK auf Displays Desktop EMBU-TAB 10/7 EMBU-TAB 7 - 10 EMBU-CANDICE 7, 8 x x 7, 8 x x EC x <tbc> Windows™ EMBU-Chart Browser

24. Vielen Dank für Ihre Aufmerksamkeit Ihre EMBU-Sys MESTEC GmbH