OPC UA OPC Unified Architecture

Transkript

1 OPC UA OPC Unified Architecture F O U N D A T I O N Mit OPC UA wird der weltweit verbreitete Standard OPC weiterentwickelt und so von seiner Plattformabhängigkeit gelöst. Dieses Dokument gibt einen kurzen Einblick in die Neuerungen und die zukünftige Entwicklung. Autor: René Portmann Dozent: Prof. M. Felser Klasse: E4p Burgdorf, 22.Januar 2007

2 I Inhaltsverzeichnis I INHALTSVERZEICHNIS... II II VORWORT... IV 1 GESCHICHTE OPC Proprietäre Systeme Dynamic Data Exchange OLE WinSEM OPC OPC Unified Architecture MARKT UND EINSATZGEBIETE OPC Einsatzgebiete Übertragbare Daten Verbreitung OPC UA Erweiterungen zu OPC Ausblick auf die Martkeinführung von OPC UA ANWENDUNGS- UND EINSATZMODELLE OPC Basisdienste Informationsmodelle Data Access (DA) Alarms (A&E) Programs (CMD s) Historical Access (HDA) Anwendungsbeispiel TECHNOLOGIE Kommunikationsmodelle Telegramme UA Native XML Web Services INSTALLATIONSTECHNIK Allgemeines Hardware Implementierung ANHANG A: QUELLENVERZEICHNIS Bücher/Spezifikationen/Skripte Webdokumente ANHANG B: ABKÜRZUNGEN UND BEGRIFFSERKLÄRUNGEN Abkürzungen Begriffserklärungen COM/DCOM DDE HMI Interoperabilität OLE SCADA SOAP II René Portmann

3 7.2.8 TCP Web Services XML ANHANG C: DIVERSES Doch ein Zusammenhang zwischen Blackout und Windows-Wurm? III René Portmann

4 II Vorwort OPC, ehemals die Abkürzung für OLE for Process Control, steht heute für Openess, Productivity and Collaboration. Dabei entstanden im Laufe der Zeit eine ganze Reihe von Spezifikationen. Jede Spezifikation ist für ein bestimmtes Einsatzgebiet vorgesehen. Im Jahr 2003 kam der Gedanke auf, die einzelnen OPC Spezifikationen zu vereinheitlichen. Daraus entwickelte sich auch die Bezeichnung OPC UA (Unified Architecture). Gleichzeitig kamen neue Technologien auf den Markt, welche die OPC Foundation, bisher stark auf Microsofts COM/DCOM-Technologie ausgerichtet, versucht zu integrieren und damit die Nachteile der Plattformabhängigkeit aufzuheben. Dies bedeutet gleichzeitig ein Schritt in Richtung Interoperabilität, ein Vorteil der in Zukunft (wie auch schon Heute) nicht zu unterschätzen ist. Dieser Bericht wurde zum Zeitpunkt erfasst, als sich die Arbeiten an den Spezifikationen von OPC UA gerade in der Endphase befanden. Er versucht dieses neue Konzept zu erläutern und die dadurch gewonnen Vorteile mit einigen Vergleichen zu OPC aufzuzeigen IV René Portmann

5 1 Geschichte 1.1 OPC Proprietäre Systeme Seit dem Einsatz von PC s in der Automatisierung werden monolithische Softwareanwendungen nach und nach durch wieder verwendbare Softwarekomponenten abgelöst 1. Es werden dazu verschiedene Software-Module, meist von verschiedenen Lieferanten, zu einem System zusammengeschaltet. Die Module kommunizieren dabei über Schnittstellen untereinander. Zu Beginn (Ende der 80er Jahre) und auch teilweise heute noch werden diese Schnittstellen herstellerspezifisch implementiert. Wird eine neue Komponente in ein solches System integriert, so müssen alle verwendeten Schnittstellen mit kostenintensiver und zeitaufwändiger Programmierung angepasst werden. Es tauchte also die Frage nach standardisierten Schnittstellen auf Dynamic Data Exchange Ein erster Ansatz dazu wurde von Microsoft mit Dynamic Data Exchange, kurz DDE, realisiert. DDE erlaubte es, im laufenden Betrieb Daten unter den Applikationen auszutauschen. Bis anhin war dies nur durch Copy and Paste möglich. So konnten Prozessdaten nun z.b. direkt in Excel oder eigene Applikationen eingelesen und weiterverarbeitet werden. Leider hatte Dynamic Data Exchange aber auch einige gravierende Nachteile. So lief es nicht wirklich robust, es konnte nicht über Netzwerke angewendet werden und seine Bandbreite war ziemlich begrenzt. So versuchten einige Unternehmen, diese Beeinträchtigungen zu beheben und DDE zu verbessern. Die Firma Wonderware z.b. entwickelte eine Version mit der Bezeichnung NetDDE, welche auch über Netzwerke arbeiten konnte und eine erheblich bessere Bandbreite hatte. Diese Version wurde später sogar von Microsoft übernommen. Aber auch andere Firmen entwickelten ihre eigenen DDE-Versionen. Die Firma Rockwell hatte z.b. eine Version namens AdvanceDDE TM. Der Nachteil davon war, dass die Versionen proprietär (herstellerspezifische Implementierungen) und somit kostenpflichtig waren. Hinzu kam, dass die Standardisierung der Schnittstellen nicht mehr garantiert war OLE Mit OLE 2.0 (Object Linking and Embedding) brachte Microsoft 1992 eine Weiterentwicklung von DDE auf den Markt. Die Vorteile von OLE sind seine Flexibilität, Robustheit und sein bessere Performance. Es war also absehbar, dass OLE das DDE verdrängen wird WinSEM Ungefähr zur gleichen Zeit entstand die Gruppierung WinSEM (Windows in Science, Engineering and Manufacturing), welche sich aus Vertretern von Automatisationstechnik sowie der Datenaquisation zusammenstellte [I1]. Microsoft war ebenfalls vertreten und steuerte die Leute zur technischen Unterstützung bei. Ihr Hauptziel war es, mit OLE Echtzeit-Daten zwischen Applikationen auszutauschen. Dabei kam die Idee auf, die Schnittstelle zwischen dem SCADA (Supervisory Control And Data Acquisition) und den Gerätetreibern der Peripherie zu standardisieren. Davon würden beide, die SCADA- und die Equipmentlieferanten profitieren: Der SCADA-Hersteller muss sich nicht um Treiber kümmern während der Equipmentlieferant nur einen Treiber schreiben muss, welcher anschliessend mit allen Windows-Applikationen funktioniert. Daraus entstand der Grundgedanke von OPC, was damals noch als Kürzel für OLE for Process Control stand OPC 1995 entstand daraus die OPC Task Force. In ihr waren die Firmen Fisher-Rousemont, Intellution, Intuitive Technology, Opto22 und Rockwell vertreten. Microsoft lieferte dabei immer noch die technische Unterstützung. Die OPC Task Force stellte sich die Aufgabe, basierend auf der COM/DCOM Technologie von Microsoft, einen Standardzugriff auf Echtzeitdaten unter Windows Betriebssystemen zu erarbeiten. DCOM (Distributed Component Object Model) wurde in Windows NT, auf welchem sich die HMI- (Human Machine Interface) und SCADA-Systemen schnell ausbreiteten, als Weiterführung von OLE entwickelt. 1 Dies wurde vor allem durch Windows 3.0 ermöglicht, welches erlaubte, mehrere Applikationen gleichzeitig laufen zu lassen René Portmann

6 Innerhalb eines Jahres, im August 1996, lag die OPC Specification Version1.0 vor, was die Effizienz der OPC Task Force verdeutlicht. Noch im September desselben Jahres wurde die OPC Foundation gegründet. Es handelt sich dabei um eine Non-Profit-Organisation mit dem Ziel der Weiterentwicklung und Unterstützung des neues Standards. In der Zwischenzeit änderte sich auch die Bedeutung OPC von OLE for Process Control zu Openess, Productivity & Collaboration. Da OPC auf bestehende Standards aufbaut (COM/DCOM) und nicht von Grund auf definiert werden muss, folgten Überarbeitungen und weitere Spezifikationen beinahe Schlag auf Schlag. So wurde bereits im September 1997 eine aktualisierte Version von OPC Specification Version1.0, die Version 1.0A, unter der Bezeichnung Data Access Specification veröffentlicht. Im Oktober 2004 waren nach [B1] insgesamt 11 Spezifikationen freigegeben. In Tab. 1 sind die aktuellen Spezifikationen und ihre Veröffentlichungsdaten aufgelistet. Spezifikation Aktuelle Version Freigabedatum OPC Overview OPC Common OPC Data Access OPC XML Data Access OPC Data Access Automation OPC Alarm and Events OPC Historical Data Access OPC Batch OPC Data exchange OPC Security OPC Complex Data Tab. 1: Aktuelle OPC Spezifikationen und ihre Erscheinungsdaten 1.2 OPC Unified Architecture Wie erwähnt baute OPC bisher auf DCOM auf. DCOM hat aber den Nachteil, das es nicht über Firewalls betrieben werden kann. Es sind also nur stationsübergreifende Verbindungen im einem Intranet möglich, nicht aber über das Internet. Hinzu kommt, dass DCOM an Windows Systeme gebunden ist und nicht auf anderen Plattformen eingesetzt werden kann. Mit OPC XML Data Access wurde eine neue Richtung eingeschlagen. So wird damit die Verwendung von XML (Extensible Markup Language) und Webservices unterstützt. Ziel davon war es, die Abhängigkeit der Spezifikation von der Rechnerplattform und vom Rechnerort aufzuheben. Einzige Voraussetzung bleibt die Verfügbarkeit von HTTP (Hypertext Transfer Protokoll) und XML. Der nächste Schritt war OPC Data exchange. Sie erlaubt, im Gegensatz zu den bisherigen Spezifikationen, eine horizontale Kommunikation, also von Server zu Server. Um nun die Interoperabilität auch für die anderen Spezifiaktionen zu erlangen, hätte die OPC Foundation auch den unvollständigen Ansatz verfolgen können, bestehende Spezifikationen einfach zu Webservices Umgebungen zu migrieren. So wäre analog zur OPC DA aus OPC Alarm & Events einfach OPC XML Alarm & Events entstanden. Da aber noch andere Anforderungen anstanden, entwickelten sich im Jahr 2003 die ersten Visionen von OPC UA. Folgende Gründe sind in [I2] aufgeführt: -COM/DCOM wird von Web Services and SOA (Service Oriented Architecture) verdrängt -OPC Anbieter möchten die verschiedenen Dienste in einem Server zusammenfassen -OPC Anbieter möchten eine Plattform-Unabhängigkeit -Kooperierende Organisationen möchten zuverlässig hochstrukturierte Daten austauschen So entstand eine Spezifikation, welche sich erheblich von ihren Vorgängern unterscheidet. Nach ca. 3 Jahren Spezifikationsarbeit und einem Jahr Prototypimplementierung kam Ende 2006 die erste Version der Unified Architecture heraus. Die Spezifikation besteht, im Gegensatz zu den bestehenden Spezifikationen, aus elf Teilen welche in Tab. 2 aufgelistet sind René Portmann

7 Spezifikation Status Datum Vorraussichtliche s Freigabedatum Part 1 Concepts Released Part 2 Security Released Part 3 Adress Space Released Part 4 Services Released Part 5 Information Model Released Part 6 Mappings Draft Feb 2007 Part 7 Profiles Draft Feb 2007 Part 8 Data Access Released Part 9 Alarms and Conditions Draft Feb 2007 Part 10 Programs Draft Jan 2007 Part 11 Historical Access Draft Dez 2006 Tab. 2: Liste der Parts von OPC UA und ihr jeweiliger Status (Stand ) In Abb. 1 ist die Geschichte von OPC/OPC UA noch einmal chronologisch dargestellt. Anhand der zeitlichen Verhältnisse ist gut ersichtlich, dass mit OPC UA eine völlig neue Richtung eingeschlagen wird. Abb. 1: Chronologische Folge der Entstehung von OPC/OPCUA René Portmann

8 2 Markt und Einsatzgebiete 2.1 OPC Einsatzgebiete Bei der Verwendung von Desktop-Rechnern können OPC Produkte vielseitig eingesetzt werden. Die Haupteinsatzgebiete gehen von der Fertigungs- über die Prozessindustrie bis hin zur Gebäudeautomation. Die OPC-Produkte ersetzen dabei die proprietären Treiber, welche für die vertikale Kommunikation zwischen SCADA- Systemen/Visualisierungsprogrammen und der Prozessperipherie zuständig sind 2. Konkret bedeutet dies, dass die Daten über einen herkömmlichen Feldbus (RS232, Ethernet, CANopen, etc.) in den Rechner eingelesen werden. Die benötigten Daten können anschliessend von Applikationen auf derselben oder auf einer entfernten Station über OPC aus der Feldbusanbindung ausgelesen werden. Zum direkten Steuern ist es auf Grund der beschränkten Performance nur begrenzt einsetzbar Übertragbare Daten Zu Beginn wurden vor allem Prozessdaten und einzelne Parameter übertragen. Inzwischen werden aber ganze Parametersätze, Steuerungssequenzen, Antriebsprogramme oder sogar ganze Warenwirtschaftsdokumente transportiert. Prozessleitsystem, PC basierte Steuerungen und MES-Systeme (Manufacturing Execution Systems) sind heute ohne OPC-Schnittstelle nicht mehr denkbar. Die einzelnen Spezifikationen decken die verschiedenen Bedürfnisse des Marktes sehr breit ab Verbreitung Mit über 7500 zertifizierten (und noch einer grossen Anzahl nicht zertifizierten) OPC Produkten und einigen Millionen installierten Systemen in der ganzen Welt [I3] hat OPC einen sehr hohen Verbreitungsgrad erreicht. Die OPC Foundation selbst besteht inzwischen aus über 430 Mitgliedern [I2]. Hinzu kommen Verbindungen und Kooperationen mit anderen Standardorganisationen wie ISA-95, SAP MIMOSA etc. Anhand dieser Zahlen und Fakten ist ein langfristiges Bestehen von OPC absehbar. 2.2 OPC UA OPC Foundation Mitgliederverteilung Japan 10% Europa 45% China 2% Übrige 7% Abb. 2: Herkunft der Mitglieder der OPC Foundation [I4] Nordamerika 36% Erweiterungen zu OPC OPC UA erweitert die bestehenden Einsatzgebiete vor allem durch die beiden Möglichkeiten, OPC auf Plattformen wie Linux/UNIX laufen zu lassen und über das Internet zu kommunizieren. Die Plattformunabhängigkeit erlaubt einerseits, OPC UA auf einfache Weise direkt in Feldgeräten (z.b. SPS) zu implementieren sofern sie Webservices (XML und HTTP) unterstützen. Andererseits wird damit auch der Weg in High-End- und Leitsysteme geebnet. Der zweite Punkt hebt die Beschränkung von OPC-Verbindungen auf Intranetze auf und ermöglicht so die Verwendung von Daten über das Internet. Ein weiterer Vorteil wird auch die Skalierbarkeit sein. Damit kann OPC UA optimal an die Anwendung angepasst werden: Von kleinen Fabriken bis hin zu komplexen Unternehmenslösungen Ausblick auf die Martkeinführung von OPC UA Da die Spezifikationsarbeiten für OPC UA erst im Jahr 2007 abgeschlossen werden, empfiehlt es sich die nächsten zwei bis drei Jahre mit den herkömmlichen Spezifikationen weiterzuarbeiten. Die bestehenden Systeme können jetzt oder auch später mit UA Wrappern, welche die OPC Foundation zur Verfügung stellt, auf UA Kompatibilität erweitert werden. Damit wird Versionskonflikten vorgebeugt und ein fliessender Übergang (Evolution) von OPC zu OPC UA ermöglicht. 2 Mit OPC Data exchange wird heute auch die horizontale Kommunikation (Server-Server) abgedeckt René Portmann

9 Branchen Einsatzgebiete -Fertigungsindustrie -Prozess- und Verfahrenstechnik -Gebäudeautomation -Bedienen und Beobachten -Visualisieren und Parametrierung -Datenerfassung und bearbeitung -Begrenzt zum Steuern einsetzbar. Dies wird aber stark davon abhängig sein, wie effizient und zuverlässig das Binärprotokoll (UA Native) sein wird Tab. 3: Übersicht über die Branchen und Einsatzgebiete, für die sich OPC UA eignet René Portmann

10 3 Anwendungs- und Einsatzmodelle 3.1 OPC Im Gegensatz zu den bisherigen OPC Spezifikationen, bei denen für jede Spezifikation eigene Dienste definiert wurden, soll bei OPC UA ein einheitliches Set von Diensten für alle Anwendungen definiert werden. Die bisherigen Anwendungen bauen anschliessend auf diesen Diensten auf. Der Vorteil gegenüber dem alten System ist, dass nicht nur die OPC Spezifikationen darauf aufbauen können sondern auch andere Standarde oder eigene Anwendungen damit einfach zu implementieren sind. Dies ist eine wichtiger Teil der Interoperabilität, welche mit OPC UA erreicht werden soll. 3.2 Basisdienste OPC UA stellt insgesamt 9 Basis Service Sets zur Verfügung. Im folgenden sind die einzelnen Sets mit einer kurzen Beschreibung aufgelistet. Mit ihnen können anschliessend die verschiedenen Dienste zusammengestellt werden. In Abb. 3 ist dargestellt wie die Informationsmodelle auf den Basisdiensten aufbauen. In [B2] ist eine Übersicht über die einzelnen Service Sets vorhanden, in [B5] sind sie vollständig beschrieben. Da nicht alle Server alle Service Sets verwenden, kann über ihre Profile abgefragt werden, welche Services sie unterstützen. Profile sind in [B8] definiert. Sie werden hier nicht näher betrachtet. Abb. 3:Die OPC UA Dienste können von OPC Anwendungen aber auch von Anwendungen anderer Standardisierungsorganisationen genutzt werden [B1] SecureChannel Service Set Der Client kann damit die Sicherheitskonfiguration des Servers abzufragen und einen Kommunikationskanal einzurichten, bei dem die Vertraulichkeit und die Vollständigkeit (Integrität) der ausgetauschten Meldungen garantiert ist. Diese Services werden nicht direkt in der UA Applikation implementiert sondern vom verwendeten Kommunikations-Stack zur Verfügung gestellt. Session Service Set Dient zum Erstellen einer anwenderspezifischen Verbindung zu einer Applikation. NodeManagement Service Set Damit können Knoten (Nodes) im Adressraum hinzugefügt, geändert oder gelöscht werden. View Service Set Der Client kann damit durch den Adressraum (oder Teilen davon) browsen, also in der Hierarchie auf und ab navigieren oder Verweisen zwischen Knoten folgen. Es erlaubt dem Client auch die Struktur des Adressraums zu erkunden. Attribute Service Set Diese Services werden vom Client zum Lesen und Schreiben von Werten (Attributen) benötigt. Method Service Set Erlaubt das Aufrufen von Methoden, welche in einem Knoten im Adressraum enthalten sind. MonitoredItem Service Set Mit diesem Dienst kann eingestellt werden, welche Attribute aus dem Adressraum für einen Client auf Wertänderungen überwacht werden sollen René Portmann

11 Subscription Service Set Damit können für MonitoredItems Mitteilungen erzeugt, verändert oder gelöscht werden, welche bei einer Wertänderung des entsprechenden MonitoredItems an den Client gesendet wird. Query Service Set Diese Services erlauben dem Client Knoten nach bestimmten Kriterien aus dem Adressraum auszuwählen 3.3 Informationsmodelle In [B9]-[B12] sind Informationsmodelle definiert, die den meistverbreiteten OPC Standards entsprechen. Sie sind aus den Basisdiensten zusammengestellt und sind von der OPC UA fix vorgegeben. Anhand der Basisdienste können aber auch andere Informationsmodelle zusammengestellt werden, was die Interoperabilität unterstützt Data Access (DA) Data Access, kurz DA, beschreibt die Prozessdatenkommunikation. Dabei ermöglicht der Server den Clients den Zugriff auf verschiedene Datenquellen wie Sensoren, Regler, Positionsgeber etc. So können die Daten gelesen, geschrieben oder einfach nur angezeigt werden. Die Datenquellen und -senken können dazu entweder über direkt am Gerät liegende I/O s oder über serielle Verbindungen und Feldbusse auf entfernten Geräten angeschlossen werden. DA baut auf den Basisdiensten View Service, Query Service, Attribute Service, MonitoredItem Service und Subscription Service auf. Die genau Spezifikation ist in [B9] beschrieben Alarms (A&E) Diese Spezifikation beschreibt, wie Alarme und Meldungen gehandelt werden. Dabei werden nicht Werte sondern Informationen, dass sich etwas ereignet hat, an den Client gesendet. Zum Zeitpunkt als dieses Dokument erstellt wurde, befand sich die Spezifikation [B10] noch in Bearbeitung, weshalb hier nicht weiter darauf eingegangen wird Programs (CMD s) Damit können vom Client Programme und Anwendungen, welche für eine übergreifende Produktion erforderlich sind, aufgerufen und gehandelt werden. In den Basisdiensten steht das Method Service Set zur Verfügung, welches sich z.b. für die Ausführung von Berechnungen oder zum Rücksetzen von Zählern eignet. Programs eignet sich für komplexere Aufgaben wie z.b. den Betrieb und die Bedienung von Batch Prozessen. Dabei werden z.b. Produktionsdaten (Rezepte) an die Anlage gesendet und Kontrollwerte in die Applikation eingelesen. Dazu werden häufig verschiedene Bedientools (Visualisierung, Ablaufsteuerung, etc.) verwendet. OPC UA Programs soll nun die Interoperabilität zwischen den Produkten, die an der Batch-Verarbeitung beteiligt sind, ermöglichen. Der genaue Beschrieb von OPC UA Programs ist in [B11] zu finden Historical Access (HDA) Hiermit wird dem Client der Zugriff auf historische Daten ermöglicht. Er kann diese Daten lesen, schreiben oder ändern. Die Daten können sich in einer Datenbank, in einem Archiv oder in einem anderen Speicher befinden. Die ausführlichen Spezifikationen sind in [B12] zu finden. 3.4 Anwendungsbeispiel Als Beispiel betrachten wir ein Gebäude, in dem wir die Temperaturen, den Druck, die Feuchtigkeit usw. erfassen und teilweise regeln. Ebenfalls sind Brand-, Bewegungs- und Einbruchmelder an die Anlage angeschlossen. Die Daten sollen für eine spätere Auswertung aufgezeichnet werden. Die ganze Anlage läuft über eine Zentrale, kann aber auch über dass Internet oder an abgesetzten Stationen bedient werden. Die Verwendung von Data Access ermöglicht den lesenden und schreibenden Zugriff auf die Mess-/Stellgrösse. Mit Alarms kann die Überwachung von Ereignissen wie Überschreitung von Temperatur- oder Feuchtigkeitsgrenzwerten realisiert werden. Ebenfalls können damit die Brandmelder überwacht, offene Fenster geortet oder Bewegungen in leeren Räumen detektiert werden. Mit Historical Access werden die aktuellen Werte gespeichert. Dadurch können sie einer späteren Auswertung zur Verfügung gestellt werden René Portmann

12 4 Technologie 4.1 Kommunikationsmodelle OPC UA sind Client/Server-Systeme. Jeder Server kann mit mehreren Clients kommunizieren und jeder Client kann auf mehrere Server zugreifen. Applikationen können Server und Client Komponenten haben, was ihnen erlaubt, mit anderen Server/Clients zu interagieren. Der Server stellt seine Daten in einem Adressraum dar, in welchem sie für den Client anhand der Basisservices erreichbar sind. Der Client-Applikation wird dazu ein OPC UA Client API (Application Programming Interface) zur Verfügung gestellt. Diese Schnittstelle erlaubt ihm, über den eingesetzten Kommunikations-Stack Requests zu senden und Responses zu erhalten. Der Server verwendet dazu entsprechend das OPC UA Server API. Die beiden API dienen dazu, die Schnittstellen von der Implementation des Kommunikations-Stacks unabhängig zu halten. Der Adressraum wird aus Knoten, sog. Nodes, gebildet. Über diese Knoten werden die verschiedenen Objekte, ihre Definitionen und ihre Beziehungen untereinander dargestellt. Knoten können Attribute enthalten sowie mit Referenzzeigern auf andere Knoten weisen. Der Aufbau des Adressraums ist stark an der Objektorientierten Programmierung ausgerichtet. Jeder Knoten gehört zu einer Knotenklasse und bildet ein eigenes Objektmodell. Auf dem Client-Server-System aufbauend kann auch ein Publisher-Subscriber-Modell erstellt werden. Mit den Basisdiensten MonitoredItems und Subscriptions können Werte im Adressraum zur Überwachung angemeldet und die entsprechende Mitteilung bei einer Wertänderung angegeben und abonniert werden. Abb. 4: Beispiel der Referenzen in einem Adressraum 4.2 Telegramme Die OPC UA Spezifikation besteht aus 11 Parts. Part 1-7 definieren dabei die Grundspezifikationen, Part 8-11 sind Definitionen von spezifischen Verwendungsarten (Zugriffsarten). Part 1-5 und Part 7 wurden bewusst unabhängig von der Technologie definiert. Damit soll die Spezifikation im Gegensatz zu den OPC Spezifikationen für zukünftige technologische Entwicklungen offen bleiben. In Part 6 ist trotzdem für zwei Kommunikationstechnologien explizit definiert, wie sie zu implementieren sind. Es handelt sich dabei einerseits um UA Native und andererseits um XML Web Services. Ersteres definiert, wie OPC UA für ein einfaches binäres Netzwerkprotokoll wie TCP implementiert wird. Letzteres beschreibt, wie OPC UA Applikationen SOAP verwenden. Anwendung Kodierung Protokoll XML Web Services UA Binary oder XML SOAP/HTTP UA Native UA Binary SOAP/HTTP oder UA TCP Tab. 4: Übersicht über die verwendeten Kommunikationstechnologien (Stand ) [B7] René Portmann

13 4.2.1 UA Native UA Native baut auf vier Schichten auf: -Application Layer -Serialization Layer -Secure Channel Layer -Transport Layer (TCP or SOAP/HTTP) Der Serialization Layer codiert/decodiert die Meldung binär. Dabei erhält die Message einen Message Header und Footer mit Zusatzinformationen wie ServiceID, Länge etc. Dasselbe geschieht beim Secure Channel Layer, welcher darin Angaben über die verwendeten Sicherheitsalgorithmen macht und Daten zur Kontrolle mitsendet. Der Transport Layer fügt anschliessend noch einen Transport Header vor die Message hinzu. Der Transport Layer erlaubt auch, Messages zur Übetragung in kleinere Stücke aufzuteilen und anschliessend wieder zusammenzufügen. UA Binary kann mit einem speziellen Service auch über SOAP/HTTP gesendet werden. Dieses Verfahren ist etwas effizienter als alles in XML zu kodieren. Abb. 5: Darstellung der verschiedenen Layer, welche zur Kodierung in UA Native verwendet werden [B7] XML Web Services Die Web Services erfordern einen Kommunikations-Stack, welcher verschiedene Web Service Spezifikationen unterstützt. Die in OPC UA benötigten Web Service Spezifiaktionen sind in Abb. 6 dargestellt. Abb. 6: Aufbau des XML Web Services Stack [B7] HTTP/HTTPS: HTTP ist das Netzwerkprotokoll, über welches die SOAP Messages übermittelt werden. HTTPS wird für die Übertragung von sicheren Messages und Authentifizierungen verwendet. HTTPS kann aber die Signatur nicht selbst erstellen sondern verwendet dazu WS Security und XML Signature. WS Security/XML Encryption: Sie dienen zur Verschlüsselung von SOAP Messages. WS Adressing: Darin sind verschiedene SOAP Standard Headers definiert, welche zum Vermitteln und Weiterleiten von SOAP Messages verwendet werden. WS Trust/WS Secure Conversation: Sie werden benötigt, um sichere Verbindungskanäle herzustellen wie sie in der OPC UA Spezifikation definiert sind René Portmann

14 5 Installationstechnik 5.1 Allgemeines Für den Einsatz von OPC UA ist eine Installation der Software-Applikationen für den Client und den Server erforderlich. Je nach verwendetem Anschluss der I/O-Geräte ist es evtl. noch nötig, eine Schnittstellenkarte in die Station einzubauen. Dies ist z.b. der Fall, wenn die verteilten Feldgeräte direkt an der Station angeschlossen sind (Abb. 8). Werden die Daten auf einem externen Gerät mit OPC UA Server Funktionalität eingelesen, so reicht eine Ethernet-Verbindung um den Datenzugriff für den Client zu realisieren (Abb. 7). Diese Verbindung kann, im Gegensatz zu OPC, auch über das Internet erfolgen. Abb. 7: Realisierung eines OPC Links über Ethernet [I5] Da OPC UA einen Mechanismus zur Verfügung stellt, welcher angeschlossene OPC Server ausfindig macht und anzeigt, entfällt meist sogar das Eingeben von Adressen. So kann viel administrativer Aufwand erspart werden. Für das Verwenden von einzelnen Daten und Informationen sind die Clients häufig so gestaltet, dass die gewünschten Einträge aus einer Liste oder aus einem Baumverzeichnis (Abb. 8) ausgewählt werden können. Abb. 8: CANOpen PCcard für den Zugriff auf CANOpen Geräte mit OPC [I2] 5.2 Hardware Bei der Anbindung von Geräten muss darauf geachtet werden, dass sie einen zertifizierten OPC UA Server zur Verfügung stellen. Jedes Gerät, welches damit ausgerüstet ist, kann ohne Probleme und ohne viel Aufwand an Applikationen, welche über einen OPC UA Client verfügen, angeschlossen werden. Damit kann den in [B13] beschriebenen Anforderung an die Planung von Client/Server- Systemen entgegengewirkt werden. Heutige Automatisierungsgeräte und -applikationen werden aber meist mit einem solchen Server oder Client 3 geliefert. Dies kommt auch daher, dass die meisten namhaften Firmen der Automatisierungstechnik Mitglied bei der OPC Foundation sind. Eine Liste davon ist unter [I2] zu finden. 5.3 Implementierung Wird kein Server oder Client zur Verfügung gestellt, so steigt der Aufwand für den Einsatz von OPC UA rapide an. In diesem Fall muss selbst eine solche Applikation erstellt werden, was einiges an Kenntnis von Programmierung und den Spezifikationen voraussetzt. Wird die Implementierung mit einem Tool als Unterstützung durchgeführt, so reduzieren sich die Anforderungen ein wenig. Wird jedoch von Grund auf eine solche Applikation implementiert, so lohnt sich der Aufwand für eine einzige Anwendung im Verhältnis zum Nutzen auf keinen Fall. 3 Heute handelt es sich dabei noch um OPC Server und Clients. Es wird aber damit gerechnet, dass OPC UA in absehbarer Zeit OPC ablösen wird René Portmann

15 6 Anhang A: Quellenverzeichnis 6.1 Bücher/Spezifikationen/Skripte [B1] OPC: Grundlagen, Implementierung und Anwendung Iwanitz Frank/Lange Jürgen, Verlag Hüthig, 3.Auflage ISBN X [B2] [B3] [B4] [B5] [B6] [B7] [B8] [B9] [B10] [B11] [B12] [B13] OPC Unified Architecture, Specification Part 1: Concepts Version 1.00, 28 July 2006 OPC Unified Architecture, Specification Part 2: Security Model Version 1.00, 28 July 2006 OPC Unified Architecture, Specification Part 3: Address Space Model Version 1.00, 28 July 2006 OPC Unified Architecture, Specification Part 4: Services Version 1.00, 28 July 2006 OPC Unified Architecture, Specification Part 5: Information Model Version 1.00, 28 July 2006 OPC Unified Architecture, Release Candidate Specification Part 6: Mappings Version 0.93, 1 June 2006 OPC Unified Architecture, Draft Specification Part 7: Profiles Version 1.00, 28 July 2006 OPC Unified Architecture, Specification Part 8: Data Access Version 1.00, 25 September 2006 OPC Unified Architecture, Draft Specification Part 9: Alarms Version 0.62, 26 Mars 2006 OPC Unified Architecture, Release Candidate Specification Part 10: Programs Version 1.00, 17 November 2006 OPC Unified Architecture, Release Candidate Specification Part 11: Historical Access Version 1.00, 31 Octobre 2006 Industrielle Netzwerke, Theoretische Grundlagen Prof. Felser Max, Ausgabe Webdokumente [I1] [I2] [I3] [I4] [I5] [I6] [I7] René Portmann

16 7 Anhang B: Abkürzungen und Begriffserklärungen 7.1 Abkürzungen COM DCOM DDE HMI MES OLE OPC SCADA SOAP TCP UA XML Component Object Model Distributed Component Object Model Dynamic Data Exchange Human Machine-Interface Manufacturing Execution Systems Object Linking and Embedding Früher OLE for Process Control, steht heute Openess, Productivity and Collaboration Supervisory Control and Data Acquisition Simple Object Access Protocol Transmission Control Protocol Unified Architecture Extensible Markup Language 7.2 Begriffserklärungen COM/DCOM DCOM ist eine netzwerkfähige Weiterentwicklung von COM. Es beschreibt ein Objektmodell für das Implementieren verteilter Anwendungen entsprechend dem Client/Server-Paradigma. Durch Schnittstellen bieten DCOM-Objekte ihre Dienste an. Eine Schnittstelle beschreibt eine Gruppe von zusammengehörenden Methoden (Funktionen). Mit der Schnittstellenbeschreibung wird die Syntax und Semantik der angebotenen Dienste definiert DDE DDE beschreibt einen Mechanismus zum Austausch von Daten zwischen Windows-Anwendungen. Wurden Daten vor der Einführung von DDE nur durch manuelles Markieren-Kopieren-Einfügen (Copy & Paste) ausgetauscht, erfolgt bei DDE der Datenaustausch dynamisch. Die zu übertragende Information wird auf ein Item mit beliebigem Datentyp abgebildet. Der Austausch der Daten erfolgt durch die Übertragung von Nachrichten und ist langsam HMI Die Mensch-Maschine-Schnittstelle erlaubt dem Bediener das Bedienen der Maschine, das Beobachten der Anlagenzustände und falls erforderlich das Eingreifen in den Prozess Interoperabilität Interoperabilität ist die Fähigkeit unabhängiger, heterogener Systeme möglichst nahtlos zusammen zu arbeiten, um Informationen auf effiziente und verwertbare Art und Weise auszutauschen bzw. dem Benutzer zur Verfügung zu stellen, ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig sind OLE Object Linking and Embedding ist ein von Microsoft entwickeltes Objektsystem und Protokoll, das die Zusammenarbeit unterschiedlicher (OLE-fähiger) Applikationen und damit die Erstellung heterogener Verbunddokumente ermöglichen soll. Es ist eine Weiterentwicklung von DDE und ergänzt dieses um das Einbetten von Objekten SCADA Unter Supervisory Control and Data Acquisition wird das Konzept zur Überwachung und Steuerung technischer Prozesse verstanden. Der Begriff kann als US-amerikanisches Pendant zum weltweit gängigen und vergleichbaren Konzept HMI verstanden werden René Portmann

17 7.2.7 SOAP Simple Object Access Protocol ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP stützt sich auf die Dienste anderer Standards, XML zur Repräsentation der Daten und Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten zu verwenden TCP Das Transmission Control Protocol ist eine Vereinbarung (Protokoll) darüber, auf welche Art und Weise Daten zwischen Computern ausgetauscht werden sollen. Wird heute von den meisten Computern unterstützt Web Services Das Internet wird im wachsenden Mass für die Kommunikation zwischen Anwendungen genutzt. Die verfügbaren Programmschnittstellen der Anwendungen werden als Web Services bezeichnet XML Extensible Markup Language ist eine Metasprache. Sie ist ein Standard zur Modellierung von halbstrukturierten Daten in Form einer Baumstruktur, der vom World Wide Web Consortium (W3C) definiert wird. XML definiert also Regeln für den Aufbau von Dokumenten, die Daten enthalten, welche zum Teil einer fest vorgegebenen Struktur entsprechen, teilweise aber auch Elemente beinhalten, die diese statische Anforderungen nicht erfüllen. XML als Rahmenkonzept lässt somit offen, ob und wie ein konkretes XML-Dokument automatisiert verarbeitet werden kann René Portmann

18 8 Anhang C: Diverses Hier ist ein interessanter Beitrag aus welcher ein Problem von windowsbasierten Systemen aufgreift und sich Gedanken zu den Auswirkungen auf dem darauf aufgestützten OPC macht. 8.1 Doch ein Zusammenhang zwischen Blackout und Windows-Wurm? Heise spekuliert momentan über einen Zusammenhang zwischen dem flächendenkenden «Blackout» in einigen Gegenden der USA und dem W32/Blaster Wurm. Das ausgefallene Niagara-Kraftwerk gehört zu National Grid USA. Dieser Energieversorger wird als Referenzkunde von Northern Dynamics aufgeführt (Site zurzeit nicht erreichbar). Diese Firma bezeichnet sich als "Home of the OPC Experts" und bietet eine Reihe von Produkten an, die OPC zur Kommunikation mit Kontrollund Steuerungssystemen nutzen. OPC steht für "OLE for Process Control" und setzt auf Microsofts COM/DCOM- Modell auf. Das ist aber genau die Technik mit dem Sicherheitsloch, das der Wurm W32.Blaster ausnutzt. In einem Netz, in dem dieser Wurm aktiv ist, versagt infolge der regelmäßigen Neustarts, die jetzt auch betroffene Endanwender bei ihren PCs beobachten, die DCOM-Kommunikation und damit auch OPC auf ungepatchten Systemen. Entspräche das der Wahrheit, so wäre der W32/Blaster der erste Virus, mit echten Auswirkungen in der realen Welt, sprich außerhalb der IT. Dies wäre insofern interessant, als das die Frage der Sicherheit von IT Installationen eine völlig neue Bedeutung erhalten würde. In Anbetracht der technischen Möglichkeiten ist es eigentlich nur eine Frage der Zeit, bis derartiges passiert. Bis dato verhielten sich die Programmierer von Viren sehr defensiv. Keiner der bekannt gewordenen Viren hatte eine wirklich gefährliche Schadensroutine, was mich immer wieder verwunderte. Auch wenn der W32/Blaster nicht der Auslöser der Stromausfälle war, wird einer der Nachfolger entsprechende Wirkung zeigen. Es bleibt nur zu hoffen, dass nicht erst ein Atomkraftwerk in die Luft fliegen muß, bis die Verantwortlichen das Problem begreifen. Ich vermute allerdings, dass wieder nur dem Programmierer des Wurms die Schuld, für einen Schaden in Trilliardenhöhe, gegeben wird und nicht den Leuten, die unsichere Systeme in die Welt setzen René Portmann