Zehn Gründe für OPC UA

1. Abkündigung von COM/DCOM Microsofts Basistechnologie COM bildet die Grundlage für den automatisierten Austausch von Daten zwischen Classic OPC Anwendungen. Die weltweit rasante Ausbreitung des Windows Betriebssystems und der Einzug von Windows Rechnern in die Automatisierung waren ideale Bedingungen für eine schnelle Verbreitung der OPC Technologie. Anfang 2002 bringt die Firma Microsoft ihr neues .NET Framework auf den Markt und kündigt DCOM ab. Dies bedeutet keineswegs, dass DCOM nicht weiterhin in zukünftigen Versionen von Windows Betriebssystemen unterstützt würde doch resultierte daraus, dass die Basistechnologie von Classic OPC nicht mehr weiterentwickelt und damit früher oder später unweigerlich veraltet sein würde. 2. Grenzen von DCOM Mit COM/DCOM führte Microsoft in den 90er-Jahren eine Reihe von Möglichkeiten ein, die schnell von Anwendern geschätzt wurden, sei es im privaten Bereich auf dem Heimcomputer oder im industriellen Bereich auf dem Windows-Rechner als Automatisierungskomponente: Copy & Paste, Drag & Drop, Linking & Embedding. Mit DCOM steht auch die komplette Kommunikationsinfrastruktur mit allen erforderlichen Sicherheitsdiensten wie Authentisierung, Autorisierung oder Verschlüsselung zur Verfügung. DCOM Sicherheitseinstellungen regeln die Befugnisse für den Zugriff auf Daten und Programme auf einem anderen Rechner. Doch gleichzeitig erweisen sich gerade diese DCOM Sicherheitseinstellungen als große Herausforderung für Inbetriebnehmer und Betreiber von Projekten mit rechnerübergreifender OPC Kommunikation. Die Einstellung funktionsfähiger DCOM Einstellungen ist sehr anspruchsvoll und erfordert ein hohes Maß an Spezialwissen. Sehr häufig suchen Inbetriebnehmer und Systemintegratoren den schnellen Erfolg, indem sie auf allen vernetzten OPC Rechnern sehr großzügige Zugriffsrechte vergeben und damit den Schutz vor unerwünschten Zugriffen von außen entfernen. Ein solches Vorgehen kollidiert mit den Sicherheitsanforderungen der IT Abteilungen und riskiert letztendlich Schäden durch Unachtsamkeit oder Sabotage. DCOM Sicherheitseinstellungen sind häufig ein \’Show Stopper\‘ der sonst sehr einfach konfigurierbaren OPC Kommunikationsbeziehungen. 3. Firewall übergreifende OPC Kommunikation Sehr früh sind die Möglichkeiten einer rechnerübergreifenden OPC Kommunikation in Automatisierungsprojekten genutzt worden. An dieser Stelle kommt es zu einer weiteren Begrenzung der Classic OPC Kommunikation durch DCOM: DCOM benötigt mehrere Ports zum Aufbau einer Verbindung, zur Authentisierung, zum Senden von Daten und für einige andere Dienste. Für eine DCOM Kommunikation über eine Firewall müssen eine Vielzahl von Ports in der Firewall geöffnet werden. Jeder geöffnete Port ist ein potenzielles Angriffsziel für Hacker und stellt eine Sicherheitslücke dar. Zur Überwindung dieser DCOM Begrenzung beim Einsatz von Classic OPC Produkten, ist OPC Tunnelling eine anerkannte Strategie. 4. Einsatz von OPC auf Nicht-Windows Plattformen Die \’Allgegenwart\‘ von Microsoft Plattformen in der Industrie mit DCOM als Bestandteil des Betriebssystems war einer der Gründe für die rasante Verbreitung von Classic OPC. Gleichzeitig scheiterten Integrationskonzepte mit OPC in Bereichen, in denen andere Betriebssysteme zum Einsatz kommen. In der IT sind vielfach Unix oder Linux Systeme im Einsatz. Aber auch in der Automatisierung gibt es Branchen, in welchen der Einsatz von Windows als Betriebssystem kategorisch ausgeschlossen wird. Im embedded Bereich spielt Windows mit Ausnahme von Windows CE oder embedded XP praktisch keine Rolle. Komplexe Anwendungen werden hier direkt in Feldgeräte, Steuerungen, Bedien Panels und andere Geräte eingebettet, die mit VxWorks, QNX, embedded Linux, RTOS oder anderen embedded Betriebssystemen ohne DCOM ausgestattet sind. Integrationskonzepte mit OPC scheitern hier, da die für OPC erforderliche Technologiebasis DCOM in den embedded Systemen fehlt. 5. Leistungsfähige OPC Kommunikation über Web Services Mit der 2003 veröffentlichten OPC XML-DA Spezifikation zeigte die OPC Foundation erstmalig einen Weg aus der Abhängigkeit von Windowsplattformen und den Begrenzungen durch DCOM auf. Zahlreiche OPC XML-DA Produkte demonstrieren heute die Möglichkeiten einer Web-Service basierten OPC Technologie. Dabei ist die Datendurchsatzgeschwindigkeit einer XML-DA Kommunikation aber um den Faktor fünf bis sieben geringer als die Datendurchsatzgeschwindigkeit einer DCOM DA Kommunikation. Dies ist für viele Automatisierungsaufgaben deutlich zu wenig. Die Möglichkeiten einer Web-Service basierten OPC Kommunikation sind vielversprechend, gleichzeitig besteht die Notwendigkeit einer viel höheren Datenübertragungs-Performance. 6. Einheitliches Datenmodell Bis heute sind bei Classic OPC drei verschiedene OPC Server – Data Access, Alarms&Events und Historical Data Access erforderlich, um z.B. den aktuellen Wert eines Temperatursensors, das Ereignis einer Temperaturüberschreitung und den historischen Mittelwert der Temperatur zu erfassen. Der Zugriff auf Prozessdaten, Ereignisse und historische Daten auf so unterschiedliche Art und Weise ist für den Anwender sehr zeitaufwändig. Eine Vereinheitlichung der drei Objektmodelle würde zu einer deutlichen Vereinfachung sowohl für Hersteller von OPC Produkten, als auch für Systemintegratoren und Anwender führen. 7. Unterstützung komplexer Datenstrukturen Eines der Haupteinsatzgebiete von OPC ist das Bedienen und Beobachten von Geräten, die über serielle Kommunikationsprotokolle oder Feldbusse vernetzt sind. Für die Konfiguration von Geräten werden Datentypen benötigt, mit welchen komplexere Datenstrukturen inklusive der Bedeutung der Datenstrukturelemente, von einem OPC Client über einen OPC Server an ein Gerät geschrieben werden können. Mit der Complex Data Specification hat die OPC Foundation eine Möglichkeit geschaffen, komplexe Datenstrukturen zu beschreiben. Classic OPC Produkte, wie sie heute am Markt vorzufinden sind, haben jedoch bis auf sehr wenige Ausnahmen die Complex Data Specification nicht implementiert. 8. Prozessdatenkommunikation ohne Datenverlust Data Access wurde ursprünglich definiert, um Client Anwendungen zyklisch den aktuellen Zustand von Prozessdaten mitzuteilen. Störungen in der physikalischen Kommunikationsverbindung zwischen einem OPC Client und einem entfernten OPC Server führen gemäß der Data Access Specification zum Abbruch der Kommunikation. Datenänderungen, die sich während der Kommunikationsstörung ergeben haben, konnten nicht an den OPC Client transferiert werden und sind verloren gegangen. Für die meisten Data Access Projekte, wie z.B. zur Aufzeichnung von Trends, Beobachtung von Prozessen oder zur Prozessvisualisierung sind derlei Datenlücken unkritisch. OPC wird aber zunehmend in Anwendungsgebieten mit kritischeren Anforderungen eingesetzt. So hat sich beispielsweise die OPC Technologie in Branchen wie der Chemie oder Pharmazie etabliert, in welchen Daten lückenlos aufgezeichnet werden müssen. Möglich ist dies, indem Hersteller spezifische Erweiterungen implementiert wurden. Dies sind Verbindungsüberwachungen mit schneller Erkennung von Kommunikationsabbrüchen, automatischer Wiederaufbau nach Verbindungsabbrüchen, Datenpufferung in Data Access Servern, Store&Forward- sowie Redundanzkonzepte. Diese durchaus sinnvolle Erweiterungen sind aber nicht in den Classic OPC Spezifikationen festgelegt, sondern von Hersteller zu Hersteller unterschiedlich realisiert worden. 9. Mehr Schutz vor unautorisiertem Datenzugang Im Zuge des Trends zu immer mehr Ethernet-basierter Kommunikation in der Automatisierung, wachsen Automatisierungsnetzwerke und Office Netzwerke immer mehr zusammen. Dadurch bieten sich neue Möglichkeiten der vertikalen Integration, gleichzeitig bringen derartige Integrationskonzepte neue Sicherheitsrisiken mit sich. OPC wird auch immer häufiger in Fernwartungs- und Fernbedienungskonzepten eingesetzt. Auch hier sind erhöhte Anforderungen an die Sicherheit der Anlagen vor unerwünschten Eingriffen von außen zu treffen. Im Zuge der Zunahme von Cyberkriminalität, Spionage und Sabotage spielt IT-Sicherheit heute eine immer bedeutendere Rolle und ist dementsprechend auch beim Einsatz von OPC höhere Anforderungen an die Sicherheit gestellt. Ohne herstellerspezifische Vorkehrungen kann Classic OPC diese Sicherheitsanforderungen nicht erfüllen. 10. Unterstützung von Methodenaufrufen In vielen Anwendungen ist nicht nur das Lesen und Schreiben von Werten wichtig, sondern auch das Abarbeiten von Befehlen wie z.B. das Starten oder Stoppen eines Antriebs oder die Durchführung des Downloads einer Datei auf ein Gerät. Die OPC Commands Specification definiert Möglichkeiten des Ausführens von Kommandos, existiert aber nur als Draftversion und wurde für Classic OPC nicht mehr berücksichtigt. Teil 4 der OPC UA Serie wird sich eingehend mit den OPC UA Spezifikationen beschäftigen. Kasten: OPC Day Europe 2012 Die OPC Foundation führt am 16. Mai 2012 den diesjährigen OPC Day Europe durch. Dieser findet bei Endress+Hauser in Reinach in der Schweiz statt und setzt einen Fokus auf die Verwendung von OPC UA in der Prozessautomatisierung.