Interoperabilität für das Internet der Dinge

Eclipse Vorto: Interoperabilität für das IoT

Jochen Scheib, Jeroen Laverman, Marco Wagner, Olaf Weinmann

© iStockphoto / DrAfter

Interoperabilität ist eines der zentralen Themenfelder im Internet der Dinge. Wesentlich ist hierbei das Zusammenwirken der einzelnen vernetzten Komponenten. Eine Kommunikation ist nur dann sinnvoll, wenn die zugrunde liegende Sprache für die beteiligten Einheiten verständlich ist. Technisch gesehen ist dies allerdings durch die Vielfalt der eingesetzten Kommunikationsprotokolle erst einmal nicht gegeben. Dieser Umstand hat zur Folge, dass zwischen den einzelnen Sprachen übersetzt werden muss.

Eclipse Vorto ist ein Open-Source-Projekt, das sich diesem Themenkomplex annimmt und eine technische Möglichkeit zur Beschreibung von anzubindenden Geräten und deren Nachrichten sowie die Definition von relevanten Mappings für Übersetzungen ermöglicht. Dieser Artikel soll einen Überblick über das Projekt geben und anhand zweier detaillierter Beispiele die Anwendungsmöglichkeiten demonstrieren.

Vorto-Komponenten

Bekannt ist, dass die Definition und Standardisierung elektronischer Gerätebeschreibungen Gegenstand von diversen Aktivitäten im Umfeld von Industriekonsortien und Standardisierungsorganisationen ist. Teilweise wird innerhalb gewisser Domänen, teilweise aber auch domänenübergreifend gearbeitet. Eclipse Vorto wählt bewusst einen technologischen Ansatz, der keinen Standard vorschreibt, sondern vielmehr ein hilfreiches Tooling bereitstellt, um smarte Geräte in IoT-Plattformen oder -Applikationen zu integrieren, entsprechende Entwicklungsaufwände zu reduzieren und Interoperabilität zu ermöglichen. Konkret besteht Vorto aus den folgenden drei technischen Komponenten:

  • Vorto-IoT-Toolset
  • Vorto Repository
  • Codegenerator-Infrastruktur

Das IoT-Toolset ist eine gut strukturierte und einfach zu bedienende Eclipse-Applikation, die es dem Benutzer ermöglicht, Gerätebeschreibungen auf Basis der Vorto DSL (Domain Specific Language) zu erstellen. Neben den zu erwartenden Features wie Syntax-Highlighting, Auto Completion, Validation etc. bietet das Toolset eine Integration mit dem Vorto Repository, die das Browsen sowie das Ein- und Auschecken von Gerätebeschreibungen erlaubt. Zusätzlich können sogenannte Codegeneratoren aus dem Toolset heraus gestartet werden.

Vorhandene Gerätebeschreibungen können in dem Vorto Repository verwaltet werden. Das Repository bietet neben einem komfortablen Web-User-Interface zur direkten Bedienung ein REST-API an, das eine technische Integration aller Funktionalitäten in bestehende Lösungen erlaubt. Ein zusätzliches Feature des Repositories erlaubt die Registrierung von Codegeneratoren, die als Mikroservice realisiert sind. Deren Funktionalitäten werden nach der Registrierung durch das Repository angeboten. Dies bedeutet konkret, dass Informationsmodelle mithilfe der registrierten Generatoren in andere Formate überführt und dem User als Download bzw. via REST angeboten werden.

Wesentlich für die Anwendbarkeit der Vorto-Komponenten ist es, dass keinem Verwender ein neues Format „aufgezwungen“ wird. Vorto bietet deshalb Mechanismen, die es erlauben, Codegeneratoren einzubinden. Diese Codegeneratoren können Gerätebeschreibungen im Vorto-Format in andere Formate überführen. Unter „andere Formate“ fallen Programmiersprachen wie zum Beispiel Java, C++ etc. Es sind aber ebenso Formate zur Dokumentation wie Markdown möglich. Genauso können die Modelle aber auch in Formate überführt werden, die durch die erwähnten Standardisierungsorganisationen oder Industriekonsortien festgelegt werden. Letztlich können Verwender ihr bisher gewähltes Format zur Geräteabstraktion beibehalten, trotzdem aber die Features des Vorto-Projekts nutzen (Abb. 1).

Abb. 1: Zusammenspiel der Eclipse-Vorto-Komponenten in Verbindung mit entsprechenden Stakeholdern

Abb. 1: Zusammenspiel der Eclipse-Vorto-Komponenten in Verbindung mit entsprechenden Stakeholdern

Beispiel: Kommunikation im Automotive-Umfeld

In einem aktuell laufenden Forschungsprojekt von Bosch Corporate Research wird Eclipse Vorto dafür genutzt, die Fahrzeug-Cloud-Schnittstelle zu beschreiben. Die für die Kommunikation entscheidenden Daten und Dienste, die an dieser Fahrzeugschnittstelle anliegen, können hierbei mit Vorto abgebildet werden. Hierdurch liegen diese Dienste und Daten in einer maschinenlesbaren Form vor, was eine automatische Weiterverarbeitung stark vereinfacht. Außerdem wird durch die Nutzung einer gemeinsamen Beschreibungssprache die immer noch bestehende Barriere zwischen der (physischen) Fahrzeugwelt und dem (virtuellen) Internet der Dinge aufgebrochen.

Ein Fahrzeug wird aus Sicht der Beschreibung als ein System verstanden, das in einem Information Model abgebildet wird. Die vorhandenen Dienste werden dementsprechend als Function Blocks beschrieben. Ein angebotener Dienst bietet in der Regel ausführbare Prozeduren an. Beispielsweise könnte der Dienst „Standheizung“ eine Prozedur setzeZeitschaltuhr besitzen, um die Standheizung zu einer gegebenen Zeit zu starten. Weiter können Dienste Ereignisse anbieten, die von anderen abonniert werden können. Um das vorgewärmte Fahrzeug anschließend auch benutzen zu können, darf die Batterie nicht leer sein. Die Batterie könnte hierzu einen Dienst anbieten, der es zum einen erlaubt, den aktuellen Ladezustand abzufragen, zum anderen wäre jedoch auch eine Benachrichtigung über einen niedrigen Ladestand hilfreich. Die Beschreibung ist auszugsweise in Listing 1 dargestellt und verwendet exemplarisch die durch W3C Vehicle Data definierten Datentypen BatteryStatus und VehicleCommonDataType.

// File: Vehicle.infomodel
infomodel Vehicle {
  functionblocks {
    Parkheating as ParkHeating
    Battery as Battery
  }
}
// File: Battery.fbmodel
functionblock Battery {
  events {
    ChargingLevelLow {
      batteryStatus as BatteryStatus
    }
  }
  operations {
    getBatteryStatus() returns BatteryStatus
  }
}
// File: BatteryStatus.type
entity BatteryStatus extends VehicleCommonDataType {
  chargeLevel as short  "MUST return battery charge level (Unit: percentage)"
  current as short  "Must return battery current (Unit: amperes)"
  voltage as short  "MUST return battery voltage (Unit: volts)"
}

Um auf Basis der erwähnten Beschreibungen Code für die Kommunikation zu generieren, werden zusätzlich entsprechende Mappings benötigt. Diese beinhalten beispielsweise Informationen zur Adressierung und weitere Protokollspezifika, die von dem entwickelten Codegenerator verwendet werden.

Abb. 2: Darstellung des Demonstrators bestehend aus fahrzeuginternem Steuergerät (ECU), dem Gateway (CCU) und einer externen Applikation

Abb. 2: Darstellung des Demonstrators bestehend aus fahrzeuginternem Steuergerät (ECU), dem Gateway (CCU) und einer externen Applikation

Zur Evaluation des Konzepts wurde ein Demonstrator aufgebaut (Abb. 2), der aus drei Komponenten besteht. Die Electronic Control Unit (ECU) stellt einen Dienst bereit (z.B. Battery), dieser wird über die Connectivity Control Unit (CCU) einer externen Applikation angeboten. Für die fahrzeuginterne Kommunikation wird eine Implementierung von SOME/IP eingesetzt. SOME/IP ist eine speziell für den Automotive-Bereich entwickelte und standardisierte serviceorientierte Middleware. Die externe Kommunikation hin zur Applikation verwendet das aus dem IoT-Umfeld bekannte RESTful-Protokoll CoAP. Hierbei kommt Eclipse Californium zum Einsatz. Ziel des Demonstrators ist es, zu zeigen, dass alle zur Kommunikation benötigten Informationen auf Basis der vorhandenen Vorto-Beschreibung generiert werden können. Auf der CoAP-Seite werden aktuell die auf Eclipse Californium basierten Implementierungen des CoAP-Servers sowie des CoAP-Clients generiert. Für SOME/IP wäre zukünftig die Generierung der Konfigurationsdatei, die u.a. die Beschreibung der Dienste enthält, denkbar. Zuletzt kann die in der CCU vorhandene Mapping-Tabelle, die für das Übersetzen zwischen den beiden Protokollen verwendet wird, aus dem Vorto-Modell und den Mappings für CoAP und SOME/IP generiert werden.

Beispiel: Interoperabilität im Industrie-4.0-Umfeld

In der Automatisierungstechnik spielt die semantische Beschreibung von Maschinen und Feldgeräten eine immer wichtigere Rolle, insbesondere im Kontext der vierten industriellen Revolution und dem Internet der Dinge. Auch bei Bosch Rexroth werden mögliche Einsatzgebiete für semantische Beschreibungen in der Automatisierungstechnik untersucht.

Die Modularisierung von Maschinen ist eine Möglichkeit, die Komplexität zu reduzieren und die Wiederverwendbarkeit von Quellcode zu erhöhen. Gemeinsam mit einer Verteilung der Anwendung auf mehrere Ressourcen lässt sich so eine flexible Steuerungsarchitektur aufbauen. Voraussetzung hierfür ist zum einen eine effiziente Kommunikationsinfrastruktur, die es erlaubt, sowohl lokal als auch über eine Netzwerkinfrastruktur zu kommunizieren. Ebenso wird eine Beschreibung der Schnittstellen benötigt, um eine interoperable Kommunikation zu ermöglichen. Hierzu untersucht Bosch Rexroth im Rahmen verschiedener Projekte unter anderem den Einsatz des Eclipse-Vorto-Toolsets im Zusammenspiel mit in der Automatisierungstechnik etablierten und standardisierten Technologien wie z. B. AutomationML.

Die Darstellung von Produktionssystemen mittels Fähigkeiten (engl. Skills) ermöglicht, das grundlegende technische Potenzial zu beschreiben, das eine Ressource im Produktionssystem zur Verfügung stellt (vgl. Schleipen, Miriam et al.: „AutomationML to describe skills of production plants based on the PPR concept“, 3rd AutomationML user conference, 2014). Ressourcen lassen sich dabei grundlegend in drei Kategorien unterteilen:

  • Mechatronische Systeme, wie beispielsweise eigenständige Produktionssysteme oder Maschinen
  • Mechatronische Maschinenmodule: geschlossene Baugruppen, z. B. ein Greifer
  • Mechatronische Gerätekomponenten, d. h. Feldgeräte (cgl. Scheib, Jochen: „Modulares Engineering als Wegweiser für verteilte intelligente Systeme“, Tagungsband SPS/IPC/Drives, 2014).

Eclipse Vorto bietet eine Möglichkeit, diese Fähigkeiten in einem einfachen und neutralen Format zu hinterlegen. Mittels Vorto können die Dienste einer Ressource, wie das Öffnen bzw. Schließen eines Greifers, als Operations beschrieben werden. Die in Configurations hinterlegten Parameter dienen während der Inbetriebnahme der Konfiguration und Parametrierung der Ressource; die dort hinterlegten Daten sind in der Regel persistent und nicht an den aktuellen Zustand der Ressource gekoppelt. Mittels der als Status konfigurierten Daten und der damit eng gekoppelten Events werden die Zustandsdaten einer Ressource modelliert und definiert. Um die Interoperabilität zwischen mehreren Ressourcen zu gewährleisten, muss die Beschreibung eines Function Blocks möglichst abstrakt sein. Gerätespezifische Fähigkeiten, die sich nicht in einer abstrahierten Weise modellieren lassen, können dann zum Beispiel in einem gerätespezifischen Function Block gekapselt werden.

Mittels der Information Models werden die abstrakten Fähigkeiten einer konkreten Ressource zugeteilt. Eine Ressource besteht dann zumeist aus mehreren Function Blocks, die die Gesamtheit der Fähigkeiten beschreibt. Listing 2 zeigt einen exemplarischen Auszug eines Information Models für einen Parallelgreifer.

// File: Gripper.fbmodel
functionblock Gripper {
  Configuration {
    mandatory maxPressure as double
  }
  status {
    mandatory state as GripperState
    mandatory angle as double
    mandatory pressure as double
  }	
  events {
    stateChanged {
      state as GripperState
      angle as double
    }
  }
  operations {
    open() returns boolean
    close() returns boolean
  }
}
// File: Parallelgreifer.infomodel
infomodel Parallelgreifer {
  functionblocks {
    gripper as Gripper
    control as ModuleControl
}

Eclipse Vorto bietet eine optimale Möglichkeit, Fähigkeiten von Ressourcen zu beschreiben. Es fehlt jedoch an einer Möglichkeit, disziplinübergreifende Informationen abzulegen. Insbesondere können dies weitere Engineering-Daten wie CAD-Zeichnungen, Prozessverhalten sowie Dokumentationen zu einzelnen Ressourcen sein. Aber auch Informationen aus dem Gesamtanlagenkontext, z. B. Einbauort und Betriebsmittelkennung liegen nicht im Fokus von Vorto, sind jedoch für die Entwicklung von Produktionssystemen von hoher Bedeutung. Hierbei hat sich AutomationML in vielen Bereichen der Automatisierungstechnik als Containerformat etabliert. AutomationML ist ein auf dem CAEX-Standard (IEC 62424) basierendes XML-Format zur Beschreibung von Anlagentopologien, Geometrien und Kinematiken (COLLADA), Logik und Verhalten (PLCopen XML) sowie Semantiken auf Basis von Bibliotheken. Die Erweiterbarkeit des Formats ermöglicht die Einbindung der Vorto Information Models und Function Blocks in den Kontext eines Produktionssystems. Mittels definierbarer Klassen (SystemUnitClass) in AutomationML kann eine Ressource umfassend modelliert werden und durch die Einbindung eines Information Models die eigenen Fähigkeiten beschreiben. Die Einbettung erfolgt dabei mittels einer Referenz auf das entsprechende Information Model im lokalen oder öffentlichen Vorto Repository. Referenzen auf von einer bestimmten Ressource verwendete Fremdressourcen können durch eine entsprechende Relation (Interface) in AutomationML modelliert werden. Durch die Instanzhierarchie in AutomationML ist dann eine Modellierung einer vollständigen Fertigungsanlage möglich. In Abbildung 3 ist dies anhand einer Beispielanlage dargestellt.

Abb. 3: Integration eines Eclipse Vorto Information Models in AutomationML

Abb. 3: Integration eines Eclipse Vorto Information Models in AutomationML

Im weiteren Projektverlauf sollen nun die Einsatzmöglichkeiten der Vorto-Codegeneratoren untersucht werden, um einen Kommunikationsrahmen in die SPS-Applikation zu erzeugen und die Vernetzung der Ressourcen zu ermöglichen.

Geschrieben von
Jochen Scheib
Jochen Scheib
Jochen Scheib ist Doktorand im Bereich Softwareentwicklung bei Bosch Rexroth und promoviert im Bereich des modularen Engineerings in der Automatisierungstechnik. Im Rahmen dieser Arbeit, beschäftigt er sich mit semantischen Beschreibungen von Fertigungseinrichtungen.
Jeroen Laverman
Jeroen Laverman
Jeroen Laverman ist Masterand bei der zentralen Forschung und Vorausentwicklung der Robert Bosch GmbH. In seiner Master-Thesis beschäftigt er sich mit Fahrzeug-Cloud-Schnittstellen und verfolgt dabei das Ziel einer hersteller- und modellübergreifenden Beschreibung von Fahrzeugdaten und -funktionen.
Marco Wagner
Marco Wagner
Marco Wagner ist Forschungsingenieur bei der zentralen Forschung und Vorausentwicklung der Robert Bosch GmbH. Hier beschäftigt sich der promovierte Informatiker unter anderem mit Kommunikationstechnologien im Fahrzeug sowie zwischen Fahrzeug und Cloud-Systemen.
Olaf Weinmann
Olaf Weinmann
Olaf Weinmann ist Mitarbeiter der Firma Bosch Software Innovations GmbH. Im Rahmen seiner Tätigkeiten als Projektleiter und Senior Expert ist der promovierte Mathematiker unter anderem für das Open-Source-Projekt Eclipse Vorto verantwortlich, das von Bosch Software Innovations im Jahr 2014 initiiert wurde.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: