Vom Embedded-Controller bis in die Enterprise-Ebene mit ‚OPC Unified Architecture‘
Machine-to-Machine-Connectivity
Machine-to-Machine (kurz: M2M) steht für den automatisierten Informationsaustausch zwischen Endgeräten, wie Maschinen, Automaten, Fahrzeugen und Containern, untereinander oder mit einer zentralen Leitstelle. Die durchgängige Kommunikation kleinster Embedded-Geräte untereinander sowie zur Enterprise-Ebene stellt in vielen Fällen immer noch eine Herausforderung dar. Häufig werden Embedded-Geräte zunächst mit einer proprietären Kommunikationslösung ausgestattet. Der Hinweis auf die Verwendung von TCP, HTTP, WLAN, GSM oder GPRS im Gerät – als internationaler Standard – ist zu kurz gegriffen. All diese Lösungen stellen nur den Transport-Layer dar, bieten aber noch keine durchgängige Interoperabilität.
Kommunikation setzt ein einheitliches Protokoll voraus. Ein Vergleich aus dem realen Leben soll dies veranschaulichen: Telefoniert ein Japaner mit einem Deutschen, so stellt die Telefoninfrastruktur eine Verbindung her, sodass sich die Teilnehmer hören können. Sprechen beide aber nur in ihrer jeweiligen Landessprache, können sie nicht miteinander kommunizieren. Übertragen auf die Technik, steht die Telefonleitung für das TCP, HTTP oder GSM, während die verschiedenen Landessprachen quasi das überlagerte Protokoll darstellen. Werden unterschiedliche Sprachen bzw. Protokolle genutzt, findet keine Kommunikation statt. Einigen sich die Telefonpartner jedoch auf eine gemeinsame Sprache, z.B. Englisch, kann auch ein inhaltlicher Austausch erfolgen. Verfügen beide Kommunikationspartner zudem über eine weitergehende, qualifizierte Ausbildung für vertragssichere, englische Kommunikation, können Missverständnisse ausgeschlossen werden. Bezogen auf die Gerätekommunikation bedeutet dies: Nur wenn beide Geräte das gleiche Protokoll implementiert haben, kann ein direkter Austausch erfolgen. Handelt es sich um einen internationalen, zertifizierten Standard, so sind direkte Konnektivität und Stabilität beim Datenaustausch garantiert.
Kommunikation setzt einheitliches Protokoll voraus
Viele sehr kleine Embedded-Geräte bieten zwar Connectivity, aber nicht die notwendige Interoperabilität. Dabei ist genau dies häufig der Schlüssel, um ein Gerät schnell in neuen Märkten zu etablieren. Am Beispiel der Home-Automatisierung soll dies verdeutlich werden: Viele intelligente Embedded-Geräte sind bereits im Haushalt vorhanden. Obwohl alle TCP- oder HTTP-fähig sind, kann die Haussteuerung als zentrale Verwaltungseinheit dennoch nicht mit der Waschmaschine oder dem Duschkopf kommunizieren. Die häufig anzutreffende Behauptung: „Unser Gerät benötigt nur ganz einfache Kommunikation“, ist eine Fehleinschätzung, wie das Beispiel eines elektronischen Wasserhahns verdeutlicht: Ein automatisierter Wasseraustritt macht in vielen Anwendungen Sinn: Nicht nur bei der automatischen Gartenbewässerung, sondern auch bei der automatischen Spülung im Hygienebereich, zur Vermeidung von Keimbildung in Rohren und an Wasserhähnen oder zur genauen Regelung und Messung des Wasserdurchflusses für ein verbrauchsgenaues Abrechnungswesen. Die minimal notwendigen Parameter, wie Ein- und Ausschalten des Wasserflusses, sind schnell im kleinsten Controller per HTTP-XML-Webservice implementiert. Damit ist die Version eins fertig. Eine genaue Dokumentation ist notwendig, damit andere Kommunikationspartner, wie die Haussteuerung, mit einem gewissen Entwicklungsaufwand die entsprechenden Anfragen implementieren können. Mit jeder Funktionserweiterung des intelligenten Wasserhahnes muss bei beiden Kommunikationspartnern im Protokoll nachgebessert werden: Soll z. B. auch der Wasserdurchfluss geregelt und gemessen oder die Wassertemperatur richtig gemischt werden, so sind weitere Datenpunkte in neue HTTP-Kommandos zu verpacken. Da nun aber heißer Wasserfluss aus der Ferne (Remote) eingeschaltet werden könnte, darf nicht mehr das einfache, offene TCP- oder HTTP-Protokoll verwendet werden. Die Authentifizierung des Kommunikationspartners und die Verschlüsselung der Daten macht auch in Hinblick auf eine genaue Verbrauchsabrechnung Sinn. Werden diese Sicherheitsaspekte nun in Protokollversion zwei implementiert, so muss das Protokoll der Haussteuerung entsprechend nachgebessert werden.
Skalierbare Zugriffsrechte
Um sich über neue Kommunikationsmöglichkeiten eines Gerätes zu informieren, gibt es, neben dem Studieren der Dokumentation, die Möglichkeit, am intelligenten Gerät selbst abzufragen, welche Datenpunkte und Funktionen es bietet. Diese Auskunft muss natürlich für unterschiedliche Personen verschieden skalierbar und darstellbar sein: Per Authentifizierung soll der Servicetechniker mehr Informationen sehen und im Zugriff haben als der Anwender selber. Dem ERP-System dagegen soll nur der Zugriff auf die Durchflussmenge zur Abrechnung gestattet sein. Diese und weitere Anforderungen in einem eigenen, proprietären Protokollansatz zu erfüllen, ist aufwendig und somit kostenintensiv. Zudem ist die Adaption am Markt eher gering und steht der Verbreitung der eigenen Embedded-Lösung im Weg. International etablierte Protokolle gibt es viele. Da sie – teilweise – historisch gewachsen oder auf ganz spezielle Anwendungen und Branchen zugeschnitten sind, lassen sie sich nicht ohne Weiteres für den eigenen Einsatzbereich nutzen.
Interoperabilität ist das Schlüsselwort
Interoperabilität im Daten- und Informationsaustausch ist die zentrale Mission der OPC-Foundation. Gegründet im Jahr 1996, wurde die erste OPC-Spezifikation im Bereich der Automatisierungsindustrie schnell ein Erfolg, da die Branchenführer erkannten, welchen Aufwand die Anpassung der zahlreichen Herstellerstandards auf individuelle Steuerungs- und Überwachungs-Infrastrukturen verursacht hatte. Heute ist OPC der de-Facto-Standard zur herstellerunabhängigen Kommunikation in der Automatisierungstechnik. Die OPC-Technik der ersten Generation setzte technologisch auf dem Microsoft COM/DCOM-Modell auf, sodass sich bis heute in vielen Köpfen die Vorstellung gehalten hat, dass sie nicht im Embedded-Bereich einsetzbar sei. Die neue OPC-Generation, die OPC Unified Architecture (OPC-UA), ist jedoch bis in die kleinsten Embedded-Controller integrierbar. Da sie nicht speziell auf die Automatisierungswelt zugeschnitten ist, können auch andere Organisationen und Hersteller ihre Informationsmodelle leicht in OPC-UA integrieren. Nach über drei Jahren Spezifikationsarbeit und einem Jahr Prototyp-Implementierung wurde die erste Version der OPC Unified Architecture im Herbst 2006 verabschiedet. OPC-UA ist die neue Technologiegeneration der OPC-Foundation und unterscheidet sich erheblich von ihren Vorgängern: Sie ermöglicht den sicheren, zuverlässigen und herstellerneutralen Transport von Rohdaten und vorverarbeiteten Informationen. In der Automatisierungsbranche ist sie von der Fertigungsebene bis hin zum Produktionsplanungs- oder ERP-System einsetzbar. Mit OPC-UA steht jeder berechtigten Anwendung und jeder autorisierten Person, jede gewünschte Information, zu jeder Zeit und an jedem Ort zur Verfügung. Diese Funktion ist unabhängig davon, von welchem Hersteller die Anwendungen stammen, in welcher Programmiersprache sie entwickelt wurden, oder auf welchem Betriebssystem sie eingesetzt werden. OPC-UA ergänzt den existierenden OPC-Industriestandard um wesentliche Eigenschaften, wie Plattformunabhängigkeit, Skalierbarkeit, Hochverfügbarkeit und Internetfähigkeit. OPC-UA basiert nicht mehr auf DCOM und bildet schon heute die Brücke von der Unternehmensleitebene bis hin zu den kleinsten Embedded-Komponenten, unabhängig vom Betriebssystemen. Das ausgereifte Sicherheitskonzept der OPC-UA-Technologie gewährleistet Schutz vor unberechtigtem Zugriff, Sabotage und Bedienungsfehlern. Es basiert auf WorldwideWeb-Standards und umfasst Möglichkeiten der Benutzerauthentifizierung, Signierung von Nachrichten und Verschlüsselung der übertragenen Nutzdaten. OPC-UA definiert eine robuste Architektur mit zuverlässigen Kommunikationsmechanismen, konfigurierbaren Timeouts, automatischer Fehlererkennung und Recovery-Mechanismen. Die Kommunikationsverbindungen zwischen OPC-UA-Clients und -Servern können überwacht werden. OPC-UA bietet ein vollständiges Instrumentarium, um Datenverlust zu verhindern und hochverfügbare Systeme zu realisieren.
Datenverlust verhindern
Im M2M-Bereich sollte es möglich sein, den verschiedenen Applikationen auf einem Gerät, unterschiedliche Rechte zuweisen zu können: OPC-UA-Anwendungen identifizieren sich über so genannte Software- und Applikationsinstanz-Zertifikate. Mithilfe von Software-Zertifikaten ist es möglich, bestimmten Client-Anwendungen einen erweiterten Zugriff auf Informationen eines OPC-UA-Servers zu geben. Durch Applikationsinstanz-Zertifikate kann sichergestellt werden, dass ein OPC-UA-Server nur mit vorkonfigurierten Clients kommuniziert und der Client nur mit dem richtigen Server spricht. Die Berücksichtigung dieser Zertifikate ist optional, d. h. ein OPC-UA-Server kann auch jedem Client den gleichen Zugriff, abhängig von den Benutzerrechten, gewährleisten. Die Zusammenarbeit mit anderen Standardisierungsorganisationen war von Beginn an wichtig für OPC-UA. Die einfache Erweiterbarkeit durch Informationsmodelle macht OPC-UA sehr interessant für andere Standardisierungsorganisationen. Diese müssen nur noch definieren, welche Informationen ausgetauscht werden sollen, aber nicht mehr, wie dies vor sich geht. Von Beginn der Spezifikation war es eine der wichtigsten Anforderungen, dass OPC-UA, als universelle Kommunikationsplattform und IEC-Standard, eine Basis für andere Standards bildet. Ein Beispiel hierfür ist die Kooperation der OPC-Foundation mit der PLCopen-Organisation, welche die IEC6-1131-3-Steuerungshersteller repräsentiert: Alle namhaften, großen Steuerungshersteller, darunter auch Siemens, Beckhoff und Bosch-Rexroth, gewähren den Zugriff auf ihre Steuerungen per OPC-UA. Ein identisches SPS-Projekt auf den Controllern unterschiedlicher Hersteller wird zur Außenwelt hin in semantisch identischer Weise dargestellt. Die UA-Client-Anwendungen, wie Visualisierungen oder MES/ERP-Systeme, können leicht – und bis auf die Objektebene identisch – mit verschiedenen Steuerungsherstellern kommunizieren. Der Aufwand zur Integration von OPC-UA in das eigene Board ist gering: Die Foundation stellt ihren Mitgliedern kostenlos den OPC-UA-Stack in C/C++, C# und Java zur Verfügung. Auch ohne Mitglied zu werden, kann man über OPC-Dienstleisterfirmen, wie Ascolab, Softing oder Unified Automation, an den Code gelangen und so den ‚C-Stack‘ in kleinste Embedded-Boards integrieren. Neben allen Visualisierungsfirmen haben auch SAP und andere MES-Hersteller die Leistungsfähigkeit von OPC-UA erkannt und in ihre Produkte integriert. Interoperabilität und eine durchgängige, gesicherte, plattformunabhängige Kommunikation von Embedded-Geräten untereinander und zur Enterprise-Ebene ist mit OPC-UA bereits heute Realität.
