Alle Geräte untereinander kommunizieren lassen: Das ist das Ziel von OPC UA. Auch Auto-ID-Verfahren lassen sich mithilfe von Spezifikationen für den Anwender vereinfachen.

Alle Geräte untereinander kommunizieren lassen: Das ist das Ziel von OPC UA. Auch Auto-ID-Verfahren lassen sich mithilfe von Spezifikationen für den Anwender vereinfachen. Fotolia.com

Getrieben von der Motivation, dass ein akzeptiertes, standardisiertes Kommunikationsinterface zu Auto-ID Geräten die Arbeit von Systemintegratoren deutlich effizienter gestaltet, brachten Harting und Siemens das Thema OPC UA vor gut einem Jahr in einen der Arbeitskreise des AIM Deutschland ein. Gemeinsam mit Vertretern der Branche beschloss der Verband in Kooperation mit der OPC Foundation eine sogenannte Companion Specification für Auto-ID-Geräte zu definieren.

Alles bündeln

Diese Companion Specification führt die unterschiedlichen Auto-ID Technologien auf eine gemeinsame Kommunikations-Schnittstelle beziehungsweise ein gemeinsames Datenmodell zurück. Sprich: alle Methoden, Datenstrukturen, Event-Typen werden definiert. Auch die Spezifikationen lassen sich aufgrund des objektorientierten Ansatzes von OPC UA erweitern. So können Hersteller eigene Änderungen vornehmen und ihre Features beibehalten, aber trotzdem eine breite Kommunikationsbasis nutzen. Beispielsweise beinhalten alle Auto-ID-Technologien eine Scan-Methode, die neue Barcodes oder RFID-Transponder identifiziert. Wie diese Daten dann im Einzelnen interpretiert werden, ist je nach Technologie unterschiedlich, lässt sich aber schnittstellentechnisch dennoch allgemeingültig beschreiben.

Grundsätzlich werden die Ident-Geräte einen OPC-UA-Server bereitstellen, der als Datenquelle dient. Die erfassten IDs lassen sich entweder per Methodenaufruf von einem OPC-UA-Client anfordern (synchrone Kommunikation), oder per Event asynchron an den angemeldeten Client senden. Das Auto-ID-Objektmodell sieht eine Gerätehierarchie vor, deren Startpunkt ein abstraktes ‚Auto-ID-Device‘ bildet. Als Methoden und Eigenschaften bietet dieses Objekt die synchrone Scan-Methode und die Steuerung der asynchronen Event-Schnittstelle mit ‚Scan-Start‘ oder ‚Scan-Stop‘. Hinzu kommen die Device-Management-Funktionen, wie die Abfrage von Gerätetyp, Versionsnummer, Hersteller oder Bezeichnung sowie die Verwaltung der Gerätekonfiguration. Diese wird als Datei abgebildet, sodass sie sich mit Lese- und Schreibbefehlen auf ein Gerät übertragen oder von diesem laden lässt. Das Format der Konfigurationsdatei wird nicht definiert und bleibt somit Hersteller-spezifisch.

Ob RFID, Real Time Location, optische Reader oder der klassische Barcode: OPC UA ermöglicht das Lesen und Kommunizieren aller Auto-ID-Geräte untereinander sowie mit der Leitebene.

Ob RFID, Real Time Location, optische Reader oder der klassische Barcode: OPC UA ermöglicht das Lesen und Kommunizieren aller Auto-ID-Geräte untereinander sowie mit der Leitebene. Harting

Von diesem abstrakten Gerätetyp lassen sich dann die einzelnen Spezialisierungen ableiten. Vorgesehen sind bislang ein ‚Optical-Reader-Device‘, das 1D/2D-Codereader abbildet, ein ‚OCR-Reader-Device‘ für Kameras zur Klarschrifterkennung, ein ‚RFID-Reader-Device‘, das alle RFID-Standards gemeinsam abbilden kann, sowie ein RTLS-Device für Real Time Location Systems. Je nach Ident-Technologie gibt es unterschiedliche Methoden oder Eigenschaften. So liefert beispielsweise das ‚Optical-Reader-Device‘ als Ergebnis seines Scan-Vorgangs auch eine Koordinate, die die Position des 2D-Codes im Bildfeld angibt. RFID-Reader liefern stattdessen zum Beispiel die Signalstärke der Tag-Antwort mit. Lokalisierungssysteme wiederum sollen mit den Scan-Ergebnissen auch eine Geokoordinate übertragen. Bei den Methoden unterstützt beispielsweise ein ‚RFID-Reader-Device‘ zusätzlich die verschiedenen Lese- und Schreiboperationen für RFID-Systeme über Methoden wie ‚Tag-Write‘, ‚Tag-Read‘ oder auch ‚Tag-Lock‘.

Die Darstellung der Scan-Ergebnisse erfolgt über eine Struktur namens ‚Scan-Result‘. Diese stellt die gelesene ID zunächst nur als Byte-Stream dar – also ohne zusätzliche Format-Informationen. Allerdings kann über eine Union auch eine interpretierte Darstellung erfolgen, so beispielsweise für EPC-IDs oder EAN-Codes. Neue Nummernschemata oder -darstellungen werden aber nicht spezifiziert.

Die OPC-UA-Architektur, erweitert um den Companion-Standard für Auto-ID.

Die OPC-UA-Architektur, erweitert um den Companion-Standard für Auto-ID. Siemens

Gleiche Sprache für alle

Für den Systemintegrator oder den Endkunden bedeutet diese Vereinheitlichung der Kommunikations-Schnittstelle, dass er damit deutlich schneller unterschiedliche Auto-ID-Geräte, verschiedene Technologien von unterschiedlichen Herstellern, in eine Infrastruktur einbinden kann. Die Schnittstelle hat also keinen Einfluss mehr auf die Wahl des Auto-ID-Gerätes. Egal ob eine Barcode-, eine RTLS- oder eine RFID-Lösung installiert werden soll, die Schnittstelle zum Gerät wird dem gleichen Standard folgen – jedes Gerät spricht damit die gleiche Sprache. Auch eine Migration beispielsweise von Barcode auf eine RFID-Anwendung oder aber eine Mischinstallation (RFID-Transponder mit aufgedrucktem Barcode) lässt sich so vereinfachen. Gleichzeitig nimmt OPC UA jedoch nicht die Möglichkeit, gerätespezifische Funktionen anzusprechen. Die neue OPC-UA-basierte Schnittstelle beschränkt Auto-ID Geräte also nicht auf den kleinsten gemeinsamen Funktionsumfang.

Zusätzlich werden andere wichtige Aspekte von OPC UA, wie die erhöhte Sicherheit oder die Möglichkeit, Server und Client Funktionalität in einem Gerät zu vereinen, mit integriert.

Die passende Wahl der Gerätehardware lässt sich mit einer einheitlichen Schnittstelle vereinfachen. Dies ist insbesondere für Systemintegratoren interessant, welche je nach Kundenanforderung das für diese Situation beste Gerät verwenden wollen. Sie müssen sich nicht aufwendig in eine andere gerätespezifische Schnittstelle einarbeiten und können bereits existierende Programme oder Schnittstellen zu Backend-Systemen nutzen. Von der SPS-Anbindung bis zur SAP-Schnittstelle lässt sich eine einheitliche Technik verwenden, um mit Auto-ID-Geräten zu interagieren.

Darüber hinaus können mit sogenannten Companion Specifications konkrete Datenmodelle von Gerätegruppen oder artverwandten Anwendungen definiert werden. Hierdurch lässt sich die Verwendung von OPC UA noch einmal optimieren. Diese Spezifikationen beinhalten den wesentlichen Funktionsumfang inklusive der Datentypbeschreibung der einzelnen Variablen, Übergabe- und Rückgabeparameter.

Der Vorteil einer Companion Specification: Je mehr Hersteller dieser Empfehlung folgen und ihre Kommunikations-Schnittstellen entsprechend umsetzen, desto schneller können verschiedene Geräte, auch unterschiedlicher Hersteller, in neue Anwendungen integriert werden. Das spart Zeit und erhöht den Investitionsschutz von Kunden.

Auf der Hannover Messe 2015 präsentieren die OPC Foundation und AIM Deutschland einen ersten Entwurf der Companion Specification. Neben der reinen Vorstellung der Spezifikation ist auf dem OPC-Foundation-Messestand auch eine live Demo mit verschiedenen Auto-ID Geräten – unter anderem mit UHF-RFID-Readern von Harting und Siemens – zu sehen.

Technik im Detail

Babylons Ende: OPC UA

Ein Ansatz, den direkten Austausch von Informationen zu vereinfachen, ist die OPC Unified Architecture (OPC UA). Das Kommunikations-Protokoll gilt als De-facto-Standard in der Automatisierungsbranche. Es arbeitet gegenüber dem Vorgänger OPC vor allem plattform- und programmiersprachenunabhängig sowie sicherer: Das Protokoll verfügt über eine integrierte 128- oder 256-Bit-Verschlüsselung und ermöglicht die Authentifizierung und Autorisierung sowie Datenintegrität durch Signaturen. Und es lässt sich skalieren: Von der cloudbasierten Server- bis zu einer minimalistischen Chip-Implementierung ist alles möglich. Mit dem Protokoll lassen sich RFID-Systeme mit wenigen Datenpunkten genauso vernetzen wie Leitsysteme mit über 100.000 Datenpunkten.

OPC UA folgt einer serviceorientierten Architektur (SOA). Damit lassen sich Dienste zwischen IT-Systemen strukturieren und nutzen. Das Protokoll arbeitet außerdem objektorientiert. Daher bleiben die herstellerspezifischen Eigenschaften der einzelnen Geräte erhalten, ohne den Standard zu verletzen. Sprich: OPC UA definiert, wie kommuniziert wird, aber nicht was. Daher funktioniert es anwendungs- und geräteneutral. Welche Funktionen und Variablen ein Gerät zur Verfügung stellt, wird zur Laufzeit ermittelt, sofern nicht im Vorfeld bekannt. Der Anwender kann das komplette Datenmodell eines Kommunikationsteilnehmers abfragen. Hierbei werden nicht nur Funktionen und Variablen ermittelt, sondern ebenso die verwendeten Datentypen (Metadaten). So lassen sich auch unbekannte Kommunikationsteilnehmer in die Infrastruktur integrieren.

Hannover Messe 2015
Halle 11, Stand C13