Der Inbetriebnahme des Automatisierungssystems schließt sich die Betriebsphase an, in der Informationen aus den Automatisierungsgeräten in überlagerte Applikationen genutzt werden. In diesem Kontext hat sich OPC zum Standard für die systemneutrale Anbindung von verschiedenen Applikationen entwickelt – vom Bediensystem bis zur MES- und ERP-Lösung. Die Kapselung der kommunikationstechnischen Details durch den OPC-Server ist hier sicherlich ein wesentlicher Vorteil; gleichzeitig jedoch eine Herausforderung, da diese Kapselung durch ein Mapping der von einem Feldgerät freigegebenen Prozessdaten auf OPC-Daten erfordert, und die Freiheitsgrade bei der Definition dieser Server-Namespaces inkompatible Abbildungen geradezu herausfordern. Stammen Feldgerät und OPC-Server vom gleichen Anbieter, existiert oft bereits eine gewisse Durchgängigkeit, sodass sich die vom Feldgerät zur Kommunikation freigegebenen Prozessdaten aus dem Applikationsprojekt extrahieren und rechnergestützt direkt zur Konfiguration des Servers nutzen lassen. In besten Falle stimmen dann auch Eigenschaften wie Datentypen und Zugriffsrechte überein.
Kommen hingegen Feldgeräte und OPC-Server unterschiedlicher Hersteller zum Einsatz, so ist der Namespace unter Umständen von Hand zu füllen und auch die erforderlichen Eigenschaften sind händisch anzupassen. Werden zum Beispiel Grenzwerte einer Messgröße benötigt, um Ansprechschwellen für Alarme festzulegen oder das Totband für die Übertragung des Wertes einzustellen, so sind diese von Hand im OPC-Server einzutragen. Die dafür maßgebliche Informationen liegen gemäß Bild 2 jedoch bereits seit der Gerätebestellung logisch an die Messgröße gebunden vor, gegebenenfalls sogar rechnerlesbar. Während der Applikationsentwicklung gehen derartige Zusammenhänge aber in der Regel verloren und sind bei der OPC-Konfiguration erneut herzustellen. Im Rahmen von OPC UA wird versucht, diese Heterogenität einzuschränken, und durch so genannte „Semantic Layer“ Informationsmodelle einzubinden sowie auf diese Weise Vorzugsbelegungen zu definieren. Die Entwicklungen diesbezüglich sind allerdings noch in Gange.
Zum Thema XML lässt sich abschließend sagen: Ebenso wie bei den Geräteherstellern (siehe „XML in der Automation –Teil2“, Computer&AUTOMATION 2007, H. 09, S. 32ff.) ist auch bei den Systemintegratoren die Hoffnung auf einheitliche, über den gesamten Lifecycle nutzbare Sprachen aus politischen, ökonomischen und technischen Gründen nicht umsetzbar. Realisierbar wäre es jedoch, Beziehungen zwischen den verschiedenen Modellen klar zu definieren, um so eine leichtere Zuordnung relevanter Informationsquellen zu ermöglichen. Dies kann als Erweiterung oder Add-on zu bestehenden Lösungen schrittweise erfolgen. Ein geplantes „Wiki der Automation“ unter Mitwirkung einer breiten Anwendergemeinde ist hierfür eine wesentliche Voraussetzung. Günter Herkommer
![]() | Dr. Annerose Braune |
![]() | Prof. Martin Wollschlaeger |