OPC war ursprünglich definiert worden, um die immer wiederkehrende Aufgabenstellung der Anbindung von PC-basierten Applikationen – vor allem Scada- (Supervisory Control and Data Acquisition) und HMI- (Human Machine Interface) Systeme – an die Prozessperipherie einheitlich zu lösen. Im Mai 1995 traf sich dazu erstmalig die neu gegründete OPC Task Force. Mitte 1996 wurde die OPC Foundation gegründet und die erste OPC-Spezifikation, Data Access 1.0, veröffentlicht. Heute, zehn Jahre später, ist OPC ein weltweit gültiger Standard für den Daten- und Informationsaustausch von Softwarekomponenten. Mit über 7.500 OPC-Produkten und millionenfachen Installationen in den allen Industriezweigen kann man die OPC-Initiative als vollen Erfolg werten. Längst wird OPC nicht nur anstelle proprietärer Kommunikationstreiber zur Anbindung von Scada-Systemen und Visualisierungsprogrammen an die Prozessperipherie eingesetzt. Prozessleitsysteme, PC-basierte Steuerungen und MES-Systeme sind heute ohne OPC-Schnittstelle nicht denkbar. Über die OPC-Schnittstelle werden nicht mehr nur Prozessdaten oder einzelne Parameter übertragen; ganze Warenwirtschaftsdokumente, Parametersätze, Steuerungssequenzen, Videosignale oder Antriebsprogramme werden über OPC transportiert. OPC Data Access (DA) liegt heute bereits in der Version 3.0 vor. Daneben existieren eine Vielzahl weiterer Spezifikationen wie Alarms & Events (AE), Historical Data Access (HDA), Batch, Data eXchange (DX) sowie weitere Spezifikationen, die branchen- und aufgabenspezifische Problemstellungen berücksichtigen. OPC goes XML and Web Services Die Wurzeln von OPC sind eng verknüpft mit Microsofts Windows-Betriebssystem. Die ursprüngliche Bedeutung von OPC, OLE for Process Control, kommt von der Microsoft OLE-Technologie der 90er Jahre. OLE wurde schon bald durch das Component Object Model (Com) und Distributed Com abgelöst. Seit der Standardisierung von XML im Jahr 1998 wurden neue Web Service Technologien entwickelt, wie z.B. das Simple Object Access Protocol (SOAP), Universal Description, Discovery and Integration (UDDI), oder die Web Service Description Language (WSDL). 2002 brachte Microsoft sein neues .Net Framework auf den Markt, welches konsequent auf XML, SOAP und Web Services setzt. Auch die OPC Foundation hat sehr früh die Bedeutung von XML und Web Services erkannt. Seit 2003 existiert mit der OPC XML-DA-Spezifikation neben der klassischen DCom-basierten OPC-Technologie eine zweite, Web Service-basierte Möglichkeit, wie Applikationen hersteller- und plattformunabhängig kommunizieren können. Spätestens seit diesem Schritt passte die ursprüngliche Bedeutung OLE for Process Control nicht mehr. So steht OPC heute für Openess, Productivity and Collaboration und gibt weniger den Zusammenhang zu einer bestimmten Basistechnologie, als vielmehr die Kennzeichen der offenen, interoperablen und produktiven OPC-Schnittstelle wieder. DCom DA oder XML-DA oder beides? Mit der Definition plattformunabhängiger OPC-Spezifikationen hat sich die OPC-Foundation nicht von Microsoft abgekoppelt, sehr wohl aber neue Möglichkeiten geschaffen, einfach mit Linux-/Unix-Systemen oder embedded Steuerungen auf anderen Plattformen zu kommunizieren oder OPC-Verbindungen über das Internet zu realisieren. Doch hat die Plattformunabhängigkeit und Internetfähigkeit auch ihren Preis: Vergleichsmessungen, die bei der Softing AG in München durchgeführt wurden, haben gezeigt, dass die XML basierte OPC-Kommunikation um den Faktor drei bis sechs langsamer ist, als der über DCom direkt gekoppelte OPC-Datenaustausch. Hersteller eines OPC-Clients oder Servers können heute ganz einfach zwischen Com/DCom oder Web Services als Basistechnologie für ihr Produkt wählen, je nachdem, ob Plattformunabhängigkeit, Internetfähigkeit oder Performance bedeutsam sind. Plattformunabhängigkeit war beispielsweise für die Firma Loytec electronics GmbH in Österreich das Entscheidungskriterium für OPC XML-DA in ihrem Produkt L-OPC. L-OPC ist ein LON Router für LONMark-Netzwerke, der auf dem Linux-ähnlichen Betriebssystem RTEM läuft. Auf Basis der Softing OPC Toolbox wurde für L-OPC ein embedded XML-DA Server unter RTEM entwickelt. Ein weiteres Beispiel für OPC auf Nicht-Windows Betriebssystemen ist der OPC XML-DA Server für Linux, der von der Firma Ensico in Ljubljana, Slowenien, entwickelt wurde. Der OPC XML-DA Server wird heute als Teil eines Energie Management-Systems von SNC-Lavalin zur Überwachung von 126 Remote Terminal Units mit ca. 30.000 Datenpunkten eingesetzt. Ein zunehmender Trend zu einer Doppelstrategie ist heute bei Herstellern von OPC-Produkten festzustellen: Bisher auf DCom basierende OPC-Server werden um eine XML-DA Server-Schnittstelle erweitert. Dies schränkt auf der einen Seite nicht die hoch performante Kommunikation über Com/DCom ein, eröffnet aber auf der anderen Seite Möglichkeiten der Fernwartung und Fernbedienung über XML-DA über das Internet. Voraussetzung für diese Doppelstrategie ist eine OPC-Technologie, die gleichzeitig DCom und Web Services unterstützt, wie es in der OPC Toolbox C++ implementiert ist. Die nächste OPC Generation Unified Architecture Seit zwei Jahren arbeitet die OPC Foundation an der neuen OPC Unified Architecture (UA) Spezifikation. OPC UA definiert eine Interoperabilitäts-Plattform und vereinheitlicht die Verwendung unterschiedlicher OPC-Server und -clients (DA, AE, HDA, …) für den vertikalen und horizontalen Datenaustausch. Die OPC UA-Arbeitsgruppe verfolgt zwei Ziele: 1 dass existierende OPC-Produkte unterschiedlicher Kategorien (DA, AE, HDA) noch besser miteinander kombiniert werden können und 2 dass die Einsatzmöglichkeiten und der Nutzen der einzelnen OPC-Spezifikationen erweitert werden. Die Verbesserung der Kombinationsmöglichkeiten unterschiedlicher Kategorien von OPC-Servern ist wünschenswert, da heute immer häufiger sowohl DA-, AE- und auch HDA -Server gleichzeitig in Projekten anzutreffen sind. Die OPC UA-Arbeitsgruppe entschied sich, ein Modell zu definieren, das die verschiedenen Facetten der existierenden OPC-Spezifikationen kombiniert, und einen Satz von Diensten festzulegen, die auf einem einzigen, integrierten Datenmodell ausgeführt werden. Diese Dienste haben ganz ähnliche Fähigkeiten, wie die der existierenden OPC-Schnittstellen DA, AE und HDA, aber in einer vereinheitlichten (unified) Art und Weise. Das integrierte Datenmodell soll ermöglichen, dass viele hierarchische Namensräume verbunden werden können zu einem ganzen Informations- bzw. Daten-Pool. Weiter wird ein einheitlicher Mechanismus definiert, um sämtliche Datenquellen, d.h. Server, aufzufinden und zu verbinden. OPC UA nutzt die aktuellste Web Services-(WS) Technologie inklusive einige der neuesten WS-Standards. Ein Teil dieser Standards, z.B. die WS-Policy, ermöglicht dass OPC UA Clients und Server untereinander zur Laufzeit aushandeln, welche Protokolle und Kodierungen unterstützt werden. Dies stellt die Nutzung der bestmöglichen Kommunikation bei gleichzeitig höchstem Maß an Interoperabilität sicher. OPC UA verwendet auch das WS-Eventing, um echte Callback Funktionen zu unterstützen, wie sie in Com-Interfaces eingesetzt werden sowie \“polled refresh\“, wie es mit XML-DA eingeführt wurde. Um den Performance-Nachteil Web Service-basierter Kommunikation gegenüber DCom-basiertem Datenaustausch zu beseitigen, definiert die OPC UA Arbeitsgruppe ein binäres XML-Protokoll. Dadurch werden OPC UA-Applikationen in Zukunft eine zu DCom vergleichbare Durchsatz-Performance erreichen. Bild 4 erläutert, wie die OPC DA, AE, HDA und OPC Commands Funktionalität auf den OPC Unified Architecture Basis-Diensten aufsetzen und diese zugleich das Fundament für weitere Funktionalität bilden, die für bestimmte Einsatzfälle benötigt wird. OPC UA Spezifikation und Roadmap Die OPC UA-Spezifikation besteht aus 13 Teilen. Die Teile eins bis sieben bilden die Kernspezifikation, die den Adressraum und die UA Services definieren. Die Teile acht bis 13 definieren die einzelnen OPC-Spezifikationen, wie sie bereits für DCom existieren. Bild 5 gibt einen Überblick über die Inhalte aller 13 Spezifikationsteile. Teil eins \“Konzept\“ und Teil vier \“Services\“ sind als Release Candidate bereits verfügbar. Die Fertigstellung der Spezifikationen wird Mitte diesen Jahres erwartet. Beispielimplementierungen sind bis Ende 2006 geplant. Mit ersten OPC UA-Produkten ist in 2007 zu rechnen. Der Weg zu OPC UA Der Erfolg von OPC UA wird wesentlich davon abhängen, wie die immensen Investitionen in heute verfügbare OPC-Produkte auch in Zukunft geschützt werden. Von Anfang an verfolgt die OPC Foundation daher eine Migrationsstrategie in Form von UA \“Wrappern\“. Ein UA Wrapper ist eine Art Schale um ein existierendes DCom OPC-Produkt, welches die Kommunikation mit den zukünftigen OPC UA-Produkten ermöglicht. UA Wrapper sollen zukünftig sowohl einem DCom OPC Client ermöglichen, auf einen OPC UA Server zuzugreifen, als auch einem DCom OPC Server von OPC UA Clients angesprochen zu werden. Existierende OPC-Produkte, die heute im Feld installiert sind, müssen nicht modifiziert werden. Sollen Hersteller von OPC-Produkten warten, bis OPC UA komplett verfügbar ist? Der \“Komponenten\“-basierte Ansatz von OPC wird auf unbestimmte Zeit seine Gültigkeit haben. Mehr als 7500 OPC Produkte und viele Millionen installierter Systeme werden weiter verwendet werden. Um sein Produkt über OPC in die Automatisierungslandschaft zu integrieren, kann bzw. muss in den nächsten zwei bis drei Jahren nach wie vor der \“klassische\“ DCom Ansatz implementiert werden. DCom basierte OPC Produkte und Web Service basierte OPC UA Produkte werden in den nächsten Jahren koexistieren. Auch weiterhin werden für den prozessnahen Bereich DCom-basierte OPC Produkte entwickelt werden. Diese werden zunehmend von OPC UA Implementierungen für den embedded Bereich und für die MES und ERP Ebene ergänzt (nicht abgelöst!). OPC UA Wrapper ermöglichen die problemlose Kombination der neuen OPC UA Komponenten mit der nach wie vor wachsenden installierten Basis DCom basierter OPC Produkte. So wird es möglich sein, die Daten bereits existierender Produkte, die bisher nur innerhalb des Firmennetzwerks eingesetzt wurden, in Informationen umzuwandeln und diese über Firewallgrenzen hinweg zur Verfügung zu stellen. Herstellerfirmen werden auch in Zukunft für die Implementierung von OPC-Komponenten auf Toolkits zurückgreifen. Zukünftig wird entscheidend sein, dass Architektur und Implementierung solcher Toolkits Herstellern eine problemlose Migration der entwickelten Komponenten in die zukünftige Web Service basierte OPC UA Welt ermöglichen. Kasten: OPC-Toolbox Die OPC-Toolbox von Softing ist eine Familie von OPC-Toolkits für die einfache und schnelle Entwicklung leistungsfähiger OPC-Clients und -server für Windows, Windows CE, .Net, Linux und anderen embedded Betriebssystemen. Weltweit werden OPC-Produkte auf Basis der OPC-Toolbox in Zig-Tausend Installationen in der Fertigungsindustrie, Prozess- und Gebäudeautomatisierung sowie in Windows CE- oder Linux-basierten Anwendungen im embedded Bereich eingesetzt. Die OPC Toolbox der Firma Softing unterstützt neben DA, AE, HDA und DX auch bereits den XML und Web Services basierenden Ansatz. Schon heute ermöglichen die Softing OPC Produkte die Kommunikation über Internet, wie es in der UA-Spezifikation vorgesehen ist. OPC Entwicklungen auf Basis der DCom Toolkits können innerhalb einem halben Tags um Web Services und XML-DA erweitert werden. Softing wird seine OPC Toolbox in 2006 um kompatible OPC UA Toolkits erweitern. Hannover Messe: Halle 9, Stand A35
Softing Industrial Automation GmbH
