engineering mannesmann Rexroth OPC-Server Funktionsbeschreibung Rexroth Indramat DOK-CONTRL-OPC*SERVER*-FK01-DE-P

OPC-Server

Funktionsbeschreibung Rexroth

Indramat

Rexroth

OPC-Server

Funktionsbeschreibung

DOK-CONTRL-OPC*SERVER*-FK01-DE-P

• Zeichnungsnummer: 120-0400-B337-01/DE

Diese Dokumentation dient ....

• zum Vermitteln von Grundkenntnissen

• zum Beschreiben von Eigenschaften und Installation

• als Hilfe zur Programmierung und Inbetriebnahme von OPC Clients

Dokukennzeichnung bisheriger Ausgaben

Stand Bemerkung

120-0400-B337-01/DE 06/00 Erstausgabe

 Rexroth Indramat GmbH, 2000

Weitergabe sowie Vervielfältigung dieser Unterlage, Verwertung und Mitteilung ihres Inhalts wird nicht gestattet, soweit nicht ausdrücklich zugestanden. Zuwiderhandlungen verpflichten zum Schadenersatz. Alle Rechte für den Fall der Patenterteilung oder Gebrauchsmuster- Eintragung vorbehalten. (DIN 34-1)

Änderungen im Inhalt der Dokumentation und Liefermöglichkeiten der Produkte sind vorbehalten.

Rexroth Indramat GmbH

Bgm.-Dr.-Nebel-Str. 2 • D-97816 Lohr a. Main

Telefon 09352/40-0 • Tx 689421 • Fax 09352/40-4885 http://www.rexroth.com/indramat

Abt. ECS2 (TB/CV)

Diese Dokumentation ist auf chlorfrei gebleichtem Papier gedruckt.

Titel

Art der Dokumentation

Dokumentations-Type

interner Ablagevermerk

Zweck der Dokumentation?

Änderungsverlauf

Schutzvermerk

Verbindlichkeit

Herausgeber

Hinweis

Inhaltsverzeichnis

1 Einführung 1-1

1.1 Benutzung dieser Dokumentation ... 1-1 1.2 Grundlagen von OPC... 1-1 Zielsetzung von OPC ... 1-2 OPC DataAccess Server ... 1-3 Custom and Automation Interface ... 1-4 Local and Remote Servers ... 1-5

2 Eigenschaften des Indramat OPC Servers 2-1

2.1 Allgemein... 2-1 2.2 Data Access Custom Interface Standard... 2-2 Interfaces des OPCServer-Objekts ... 2-2 Interfaces von OPCGroup... 2-3 2.3 IOPCServer : GetErrorString... 2-4 2.4 IOPCItemMgt : AddItems ... 2-4 2.5 Installation ... 2-6 Systemvoraussetzungen... 2-6 Dateien und Verzeichnisse ... 2-6 Registrierungen... 2-6 Manuelle Registrierungen ... 2-7 2.6 Kommunikationsarchitektur... 2-8 2.7 Der Indramat Test OPC-Client ... 2-9 Dialog Server List... 2-10 Dialog IOPCServer ... 2-11 Dialog IOPCItemMgt ... 2-12 Dialog IOPCSyncIO ... 2-13 Dialog IOPCAsyncIO2 ... 2-14 Dialog IOPCAsyncIO2 Read Write ... 2-15 Dialog IOPCBrowseServerAddressSpace... 2-16 Dialog IOPCGroupStateMgt... 2-17 2.8 OPC Server Oberfläche ... 2-18 Hauptfenster... 2-18 Fenster mit den Clientverbindungen ... 2-19 Infofenster ... 2-19

3 Entwicklung eines OPC Clients 3-1

3.1 Fehlerbehandlung ... 3-1 HRESULT Fehler ... 3-1 3.2 DCOM-Konfiguration... 3-2 COM Sicherheitsmodell ... 3-2 Deklarative Sicherheit ... 3-2 Standardsicherheit ... 3-3 Komponentenbezogene Sicherheitseinstellungen ... 3-6 Programmgesteuerte Sicherheit ... 3-9 Konfigurationsvorschlag... 3-10 3.3 Testprogramm der OPC-Foundation ... 3-12

4 Literatur 4-1

5 Abbildungsverzeichnis 5-1

6 Index 6-1

7 Kundenbetreuungsstellen - Sales & Service Facilities 7-1

1 Einführung

1.1 Benutzung dieser Dokumentation

Die vorliegende Dokumentation soll folgende Kenntnisse vermitteln:

• Grundkenntnisse über OPC-Schnittstellen (Kapitel 1)

• Spezielle Eigenschaften und Installation des Rexroth Indramat OPC- Servers (Kapitel 2)

• Hinweise für die Programmierung und Inbetriebnahme von OPC- Clients.

Bei Anwendern, deren Ziel es ist , einen OPC-Client selbst zu entwickeln, werden folgende Kenntnisse vorausgesetzt:

• Allgemeine Programmiererfahrung in Visual C++ bzw. Visual Basic.

• Kenntnisse der COM- bzw. DCOM-Programmierung.

• Für die Inbetriebnahme von Remote-Clients ist zusätzliches Know- how über

• DCOM-Sicherheitseinstellungen und die

• Netzwerkkonfiguration des Endanwenders (Maschinenbetreibers) erforderlich.

1.2 Grundlagen von OPC

Die in diesem Kapitel aufgeführten Informationen wurden teilweise den Veröffentlichungen und technischen Spezifikationen der OPC Foundation entnommen. Rexroth Indramat ist Mitglied der OPC Foundation. Aktuelle Informationen über die OPC Foundation sind auf der Web-Seite http://www.opcfoundation.org zu finden.

OPC^TM steht für OLE for Process Control. OLE (Object Linking and Em- bedding) wurde von Microsoft zunächst für die Kommunikation zwischen Softwarekomponenten eingeführt. Heute spricht man von COM (Compo- nent Object Model) bzw. DCOM.

DCOM (Distributed Component Object Model) ist ein Mechanismus zur Kommunikation zwischen Prozessen, die auf verschiedenen Rechnern laufen. DCOM ist bei den Betriebssystemen Windows98^TM, WindowsNT^TM und Windows2000^TM (teilweise auch WindowsCE^TM) verfügbar und nutzt das TCP/IP-Protokoll.

Vorausgesetzte Kenntnisse

Die Abkürzungen

Zielsetzung von OPC

Die Zielsetzung von OPC ist es, eine einheitliche Kommunikationsschnitt- stelle für Prozessdaten aus beliebigen Quellen, wie z.B. SPS- und NC- Steuerungen zu schaffen.

...

OPC Server B OPC Server

A

OPC Server C

Application X

OPC Interface

Application Y OPC Interface

Abb. 1-1: Anwendungen arbeiten mit OPC-Servern verschiedener Hersteller zusammen

Version 1 und 2 der OPC Spezifikation konzentrieren sich auf folgende Daten:

• Online Daten Zugriffe, d.h. leistungsfähiges und flexibles Lesen und Schreiben von Daten zwischen einer Anwendung und einer Prozess- steuerungseinheit.

• Handling von Alarmen und Events, z. B. ein Mechanismus mit dem OPC Clients bei bestimmten Ereignissen und Alarmbedingungen be- nachrichtigt werden.

• Zugriffe auf historische Daten, wie z.B. das Lesen, Verarbeiten und Editieren von Daten einer Logbuchdatenbank.

Funktionalitäten, wie Sicherheitsmechanismen, Alarme und Events sowie historische Daten werden in zukünftigen Versionen der OPC Spezifikation behandelt. Die OPC-Architektur nutzt die Vorteile der COM-Schnittstelle, die einen bequemen Mechanismus liefern, um die Funktionalität von OPC zu erweitern.

Der Anwender (Entwickler von OPC-Client-Anwendungen) erfährt folgen- de Vorteile:

• Um die Kommunikation zur Steuerung zu realisieren ist nur noch ein Minimum an steuerungsspezifischem Knowhow erforderlich.

• Falls eine Anwendung mit unterschiedlichen Steuerungsfabrikaten kommunizieren muss, entfällt der Anpassungsaufwand.

OPC Spezifikationen

Anwendernutzen

OPC DataAccess Server

Vereinfacht dargestellt enthält ein OPC DataAccess Server folgende Ob- jekte:

• den Server,

• die Gruppe, und

• den Item.

Die OPC-Server Objekte beinhalten Informationen über den Server und dienen als Container für OPC-Gruppenobjekte. Die OPC-Gruppenobjekte beinhalten Informationen über sich selbst und stellen Mechanismen für die Verwaltung von OPC Items zur Verfügung.

Die OPC-Gruppen stellen für Clients eine Möglichkeit dar, Daten zu orga- nisieren. Z.B. kann die Gruppe mehrere Items in einer bestimmter Bedie- neranzeige repräsentieren. Daten können gelesen und geschrieben wer- den. Ein OPC-Client kann für jede Gruppe die Datenaktualisierungsrate definieren.

Es gibt zwei Arten von Gruppen:

• Öffentliche (public) Gruppen werden von mehreren Clients genutzt.

• Lokale oder private Gruppen werden nur von einem Client genutzt.

Siehe hierzu die entsprechenden Kapitel in der OPC-Spezifikation.

Innerhalb jeder Gruppe kann der Client ein oder mehr OPC-Items definie- ren. Die OPC-Items stellen die Verbindung zu den Datenquellen innerhalb des Servers her. Ein OPC-Item ist nicht unmittelbar als Objekt durch ei- nen OPC-Client zugänglich. Folglich gibt es keine externe Schnittstelle, die für ein OPC-Item definiert ist. Jeder Zugriff auf OPC-Items läuft über ein OPC-Gruppenobjekt, das die OPC-Items "enthält".

,WHP

*URXS

,WHP ,WHP

Abb. 1-2: Zuordnung von OPC Items zur OPC Group

Mit jedem Item verbunden, ist ein Wert, ein Qualitätsattribut und ein Zeit- stempel. Der Wert ist vom Typ VARIANT, das Qualitätsattribut ist in ähn- licher Form bei Feldbussen bekannt.

Zu baechten ist, dass Items keine Datenquellen sind - sie sind nur Ver- bindungen zu ihnen. Z.B. existieren die Variablen einer PLC-Steuerung unabhängig davon ob ein OPC-Client aktuell darauf zugreift. Ein OPC- Item gibt nur eine Datenadresse an und ist nicht mit der tatsächlichen physischen Datenquelle gleichzusetzen.

OPC Server Objekt

OPC Gruppe

OPC Item

Custom and Automation Interface

OPC Spezifikationen enthalten immer zwei Schnittstellensätze; Custom Interfaces and Automation interface. Dies wird in der nachfolgenden Ab- bildung gezeigt:

&$SSOLFDWLRQ

9%$SSOLFDWLRQ

23&&XVWRP,)

23&$XWRPDWLRQ,)

23&6HUYHU ,Q3URF/RFDO5HPRWH

+DQGOHU 9HQGRU6SHFLILF/RJLF

Abb. 1-3: Custom Schnittstelle und Automation Schnittstelle

Die OPC-Spezifikation legt COM-Schnittstellen fest, nicht deren Imple- mentierung (nicht das "Wie" einer Implementierung). Sie spezifiziert das Schnittstellenverhalten, das Client Anwendungen erwarten.

Sie umfaßt eine Beschreibungen der Architektur und der für diese Archi- tektur geeigneten Schnittstellen. Wie bei allen COM-Anwendungen ist die Architektur von OPC ein Client-Server Modell, in dem die OPC-Server Komponente die OPC-Objekte verwaltet und eine Schnittstelle zu ihnen zur Verfügung stellt.

Eine OPC-Client Anwendung steht mit einem OPC-Server über die spezi- fizierten Custom oder Automation Schnittstelle in Verbindung. OPC- Server müssen die Custom Schnittstelle implementieren. Die Automation Schnittstelle kann wahlweise implementiert werden.

OPC Custom Interface

Local or Remote OPC Server (Shared by many clients)

Local or Remote OPC Server (Shared by many clients)

Server Data Cache Server Data Cache

Physical Device/

DataBase Physical Device/

DataBase DataData OPC Automation

Wrapper OPC Automation

Wrapper VB

Application VB Application

C++

Application C++

Application

Abb. 1-4: Custom Schnittstelle und Automation Schnittstelle

Local and Remote Servers

Man unterscheidet zwischen

• lokalen Servern, die nur den Zugriff lokaler Clients zulassen, und

• remote Servern, auf die auch Clients von entfernten Rechnern über DCOM zugreifen können.

Lokale Server können als prozessinterner Server (sogenannter InProc- oder DLL-Server) oder als prozessexterner Server (sogenannter OutProc- , Lokal- oder Exe-Server) realisiert werden.

Der Out-Proc Server ist eine ausführbare Anwendung. Verbindet sich ein Client mit dem Indramat OPC Server, so wird über den COM Mechanis- mus OPCIndramat.exe automatisch gestartet. Sobald alle Schnittstellen von allen Clients wieder freigeben sind, wird der OPC Server automatisch beendet. Remote Server sind stets Out-Proc Server.

Es können sich mehrere OPC Clients anmelden, jeder Client bekommt eine unabhängige OPC Server Instanz.

Der Out-Proc Server gliedert sich in zwei Teile, erstens die Funktionalität des OPC Server und zweitens die visuelle Darstellung als Programm.

Der Vorteil von Inproc Servern liegt darin, dass für die Datenübergabe zwischen Client und Server keine Prozessgrenzen überwunden werden.

Der Nachteil liegt darin, dass der Server ein Bestandteil des Client ist und bei fehlerhafter Ausführung den Client abstürzen lässt und umgekehrt.

InProc Server besitzen keine Bildschirmausgabe.

Out-Proc Server

InProc Server

2 Eigenschaften des Indramat OPC Servers

2.1 Allgemein

Der Rexroth Indramat OPC Server unterstützt

• Data Access Custom Interface Standard Version 2.03 (July 27, 1999)

• ab Release-Stand 01V01 auch das Data Access Automation Interface Standard Version 2.02 (February 4, 1999).

Das heißt Visual C++ Clients und Visual Basic (ab Release 01V01) kön- nen Prozeßdaten lesen und schreiben.

Eine detaillierte Auflistung, welche optionalen Schnittstellenobjekte unter- stützt werden, finden Sie in Kap.2.2 Data Access Custom Interface Stan- dard.

Hinweis: Bitte beachten Sie, daß die Version 1.0 der OPC-Spezifikation des Data Access Interface in einigen Punkten inkompatibel zur Spezifikation Version 2.0 ist.

Die Interfaces

• Alarms and Events sowie

• Historical Data Access werden vorerst nicht unterstützt.

Rexroth Indramat stellt alle Servertypen zur Verfügung:

• Local InProc Server

• Local OutProc Server

• Remote Server.

Die OPC-Standardfunktionalität umfaßt das Lesen und Schreiben von SPS-Variablen. Der Rexroth Indramat OPC Server bietet darüber hinaus

• Zugriff auf CNC-Variable, CNC-Parameter und Werkzeugdaten,

• Zugriff auf ausgewählte Antriebsdaten und

• Kommandos zum Starten, Stoppen und Download von NC- Programmen.

Eine detaillierte Beschreibung aller verfügbaren Kommandos ist der Do- kumentation des Rexroth Indramat Funktions Interface [3] zu entnehmen.

Der Rexroth Indramat OPC Server wird mit einem Test Client ausgelie- fert, so daß die Kommunikation zur Steuerung jederzeit überprüft werden kann.

Die Datenausgabe des OutProc Servers informiert den Benutzer über den Zustand des OPC Servers.

Unterstützte Interfaces

Verfügbare Servertypen

Sonderfunktionen

Test- und Inbetriebnahmeunterstützung

2.2 Data Access Custom Interface Standard

Die nachfolgenden Tabellen geben an, welche Interfaces der Indramat OPC Server unterstützt. Eine detaillierte Beschreibung ist der OPC- Spezifikation [1] zu entnehmen. Wenn zur Anwendung des Indramat OPC Servers Erläuterungen erforderlich sind, wird in den Tabellen auf die ent- sprechenden Kapitel verwiesen.

Falls die Spalte "optional" keinen Eintrag enthält ist das Interface nicht optional und wird vom Indramat OPC Server unterstützt.

Interfaces des OPCServer-Objekts

Interface Methode optio-

nal

unter- stützt

Bemerkung

AddGroup ja

GetErrorString ja siehe Kap. 2.3

GetGroupByName ja

GetStatus ja

RemoveGroup ja

IOPCServer

CreateGroupEnumerator ja IOPCServer

PublicGroups

ja nein

ja teil- weise

Bei diesem Interface wird nur Eigenschaft „FLAT Space“ unterstützt

QueryOrganization ja

ChangeBrowsePosition wird nicht unterstützt, da nur Eigenschaft FLAT unter- stützt wird.

BrowseOPCItemIDs ja

IOPCBrowseServer AddressSpace

GetItemID BrowseAc- cessPaths

wird nicht unterstützt, da keine AccessPaths unterstützt werden, siehe hier IOPCItemMgt.

Neu in Version 2.0 der OPC Spezifikation QueryAvailableProperties ja

GetItemProperties ja

IOPCItemProperties

LookupItemIDs ja

SetLocaleID Neu in Version 2.0 der OPC Spezifikation

GetLocaleID ja

QueryAvailableLocaleIDs ja

GetErrorString ja siehe Kap. 2.3

IOPCCommon

SetClientName ja

Neu in Version 2.0 der OPC Spezifikation

ConnectPointContainer für die Schnittstelle IOPCShut- down. [1, Kapitel 4.6.2]

EnumConnectionPoints ja IConnectionPoin Con-

tainer

FindConnectionPoint ja

IPersistFile ja nein

Abb. 2-1: Interfaces und Methoden von OPCServer

Interfaces von OPCGroup

Interface Methode optional unter-

stützt

Bemerkung

GetState ja

SetState ja

SetName ja

IOPCGroupStateMgt

CloneGroup ja

IOPCPublicGroup StateMgt

ja nein

Read

Write ^ja

Refresh2 ^ja

Cancel2 ^ja

SetEnable ^ja

IOPCASyncIO2 Neu in Version 2.0 (der OPC Spezifikati- on)

GetEnable ^ja

IOPCAsyncIO ja nein Nur in Version 1.0 der OPC Spezifikation

AddItems ^ja siehe Kap. 2.4

ValidateItems ^ja

RemoveItems ^ja

SetActiveState ^ja

SetClientHandles ^ja

SetDatatypes ^ja

IOPCItemMgt

CreateEnumerator ^ja

IConnectionPoint Container

Neu in Version 2.0 der OPC Spezifikation ConnectPointContainer für die Schnittstelle I- OPCDataCallback. [1, Kapitel 4.6.1]

EnumConnection- Points

ja

FindConnectionPoint ^ja

Read ^ja

IOPCSyncIO

Write ^ja

IDataObject ja nein Nur in Version 1.0 der OPC Spezifikation IEnumOPCItem

Attributes

Next ^ja

Skip ^ja

Reset ^ja

Clone ja

Abb. 2-2: Interfaces und Methoden von OPCGroup

2.3 IOPCServer : GetErrorString

Die Methode GetErrorString ermöglicht das Lesen von COM-, OPC- und Indramat Fehlertexten. Sie wandelt einen HRESULT-Wert in einen Feh- lertext. Die Methode GetErrorString ist auch im Interface IOPCCommon enthalten

HRESULT Werte, die von COM erzeugt werden, werden mit Hilfe der WINAPI Funktion FormatMessage zurückgeliefert. Die Landessprache der Fehlertexte wird von der WindowsNT-Installation vorgegeben.

Fehlertexte von OPC HRESULT Werten werden nur englischsprachig ausgegeben, siehe hier die Konstantendefinitionen in [1] Appendix A.

Indramat Fehlertexte werden mit einem Standardfehlertext zurückgelie- fert.

Für sogenannten Custom Fehlernummern schreibt OPC HRESULT Werte mit dem ITF_FACILITY Flag und Codebereich 0x8000 – 0xFFFF vor.

Indramat Funktions-Interface Fehlernummern [3] werden in diesen Be- reich kodiert. Mit Hilfe von GetErrorString ist es nun möglich diesen HRESULT Wert wieder als Fehlertext zu dekodieren.

2.4 IOPCItemMgt : AddItems

Mit dieser Methode erfolgt die Verknüpfung zwischen Funktions-Interface Befehlen und OPC Server. Im Nachfolgendem werden die Parametern beschrieben, die ein OPC Client übergeben muss.

Ein sogenanntes OPC Item wird mit Hilfe der Struktur OPCITEMDEF definiert:

• szAccessPath wird nicht unterstützt

• szItemID erforderlich, Funktions-Interface Befehl, siehe weiter unten

• bActive erforderlich.

• hClient erforderlich

• dwBlobSize wird nicht unterstützt

• pBlob wird nicht unterstützt

• vtRequestedDataType erforderlich, folgende VARTYPE werden un- terstützt:

VT_EMPTY VT_UI1 VT_I2 VT_I4 VT_R4 VT_R8

VT_BSTR (Basistype „canonical datatype“) COM-Fehler

OPC-Fehler

Fehler des Indramat Funktions Interface

Struktur OPCITEMDEF

Wird VT_EMPTY als Wert für vtRequestedDataType übergeben so wird für die SPS Variabelenanforderung (FI-Befehl PVF) der entsprechende Typ aus der SPS ermittelt und in einen COM Typ umgesetzt (siehe Ta- belle). Falls kein entsprechender Typ vorliegt so wird VT_BSTR zurück- geliefert. Es werden nur eindimensionale Arrays unterstützt. Strukturen können nicht umgesetzt werden, da es hier keinen entsprechenden COM Typ existiert.

SPS Typ COM Typ Array

CHAR VT_UI1 VT_ARRAY | VT_UI1

USINT VT_UI1 VT_ARRAY | VT_UI1

BYTE VT_UI1 VT_ARRAY | VT_UI1

SINT VT_I2 VT_ARRAY | VT_I2

INT VT_I2 VT_ARRAY | VT_I2

WORD VT_I2 VT_ARRAY | VT_I2

UINT VT_I4 VT_ARRAY | VT_I4

DWORD VT_I4 VT_ARRAY | VT_I4

DINT VT_I4 VT_ARRAY | VT_I4

UDINT VT_I4 VT_ARRAY | VT_I4

BOOL VT_BOOL VT_ARRAY | VT_BOOL

REAL VT_R4 VT_ARRAY | VT_R4

Sonst VT_BSTR VT_ARRAY | VT_BSTR

Abb. 2-3: Umsetzung der SPS-Datentypen in der OPC-Schnittstelle

Der zentrale Parameter der Struktur OPCITEMDEF ist szItemID und ent- spricht hier einem Funktions-Interface Befehl, z. B. szItemID =

„00_CC_PVF_int0“, Lesen einer SPS-Variablen mit Namen int0. Es sind folgende Besonderheiten hier zu berücksichtigen:

1. Im Funktions-Interface wird zwischen einem Einzellesebefehl (00_CR_..., 00_BR_..) und einem zyklischen Lesebefehl (00_CC_.., 00__BC_..) unterschieden, diese Unterscheidung entfällt beim OPC Server, d. h. Lesebefehle können mit 00_CR_.., 00_BR.. oder mit 00_CC_..; 00_BC_.. angemeldet werden, hier sollte man sich auf eine Schreibweise entscheiden.

2. Schreibbefehle müssen mit 00_CW_.., 00_BW_.. angemeldet wer- den, da nicht jede Schreibbefehl gleichzeitig auch als Lesebefehl de- finiert ist.

3. Ein Funktions-Interface Befehl kann mehrere Ergebnisse liefern (sie- he z. B. 00_CC_APO_0_1_1 Rückgabewert 1 = Achsbezeichnung, Wert 2 = Positionswert und Wert 3 = Einheit).

Das Ergebnis wird standardmäßig als ein Wert interpretiert und wei- terverarbeitet. Um Wandlungsfehler zu meiden, sollte man als Stan- dard-Item-Typ VT_BSTR verwenden.

4. Bei Befehlen mit mehreren Ergebnissen kann der Rückgabewert in Tabellenform mit Zeilen und Spalten strukturiert sein. Diese Tabelle wird 1:1 umgesetzt, wenn der Client als vtRequestedDataType = VT_ARRAY | VT_BSTR anfordert. Es wird ein zweidimensionales SAFEARRAY erzeugt mit Dimension = 1 als Zeile und Dimension = 2 als Spalte.

5. Einzelwerte von Ergebnissen können mit einer Kommando- erweiterung gezielt ausgelesen werden. Dazu fügt man nach einem Funktions-Interface Befehl die Angabe {Zeile, Spalte} hinzu.

Beispiel: V],WHP,' ÄB&&B$32B^`³

Für die Parametrierung von {Zeile,Spalte} siehe [3], Kapitel ReadGroupItem]

2.5 Installation

Die Installation erfolgt durch Aufruf des Programmes SETUP.EXE auf der Installationsdiskette.

Systemvoraussetzungen

Betriebssystem: NT 4.0 SP5 oder höher. Nur falls keine Zugriffe über DCOM erfolgen, ist NT 4.0 SP3 ausreichend.

Indramat Benutzeroberfläche Version 18V06 SP 1 oder höher.

Dateien und Verzeichnisse

Folgende Dateien und Verzeichnisse werden bei der Installation angelegt:

Verzeichnis Dateiname Bemerkung

OPCIndramat.dll InProc Server

OPCIndramat.exe OutProc bzw. Remote Server

LW:]\winnt\system32 OPCProxy.dll Proxy/Stub DLL für das Marshaling der benutzer- definierten Schnittstellen

LW:]\winnt\system32 OPCComn_ps.dll Proxy/Stub DLL für das Marshaling der benutzer- definierten Schnittstellen

Abb. 2-4: Installierte Dateien

Registrierungen

Die Indramat OPC Server sind selbstregistrierende COM Server. Die Re- gistrierung wird vom Installationsprogramm durchgeführt. Die Indramat OPC Registrierung wird nach der OPC Spezifikation durchgeführt, siehe hier [1, 5] „Installation Issues“. Nach der Installation enthält die System Registry folgende Einträge:

Key Value Bemerkung

+.(<B&/$66(6B5227?23&,QGUDPDW Versionsunabhängige ProgID

+.(<B&/$66(6B5227?23&,QGUDPDW Versionsabhängige ProgID

+.(<B&/$66(6B5227?&/6,'?

^%%)''$')'(&()$'` &/6,'B23&,QGUDPDW

^%%)''$')' (&()$'`

CLSID des OPC Indramat Servers

+.(<B&/$66(6B5227?$SS,'?

^(%&('%)&&)%`

+.(<B&/$66(6B5227?$SS,'?

23&,QGUDPDWH[H

Konfiguration- und Si- cherheitseinstellungen für verteilte COM-Objekte

Abb. 2-5: Einträge in der System Registry

Ein OPC Client kann mit Hilfe der CLSID eine Verbindung zum Server erstellen, OPC schlägt hier eine Clientverbindung über die Komponenten- registrierung vor, siehe dazu [4, Kapitel 7] „OPC Common Definitions and Interfaces“.

Manuelle Registrierungen

Im Service Fall können einzelne Registrierungen manuell erzeugt bzw.

gelöscht werden.

Der InProc Server (hier OPCIndramat.dll) wird mit dem Hilfsprogramm regsvr32.exe registriert. Regsvr32.exe liegt jeder NT-Installation bei und befindet sich im Verzeichnis [LW:]\winnt\system32:

5HJVYURSFLQGUDPDWGOO Löschen der COM Server Registrierung:

5HJVYUXRSFLQGUDPDWGOO

Die Registrierung des OPCIndramat.exe Servers wird durchgeführt, in- dem man den Server mit folgendem Kommandozeilenparameter aufruft::

2SFLQGUDPDW±UHJVHUYHU oder RSFLQGUDPDWUHJVHUYHU

Falls der Server nicht registriert werden kann, so wird ein entsprechender Fehlertext ausgegeben.

Löschen der COM Server Registrierung:

2SFLQGUDPDW±XQUHJVHUYHU oder RSFLQGUDPDWXQUHJVHUYHU Für das Marshaling der benutzerdefinierten Schnittstellen werden zwei Proxy/Stub DLLs (OPCProxy.dll, OPCComn_ps.dll) in das Verzeichnis [LW:]\winnt\system32 installiert und dort registriert.

Diese zwei DLLs sollten folgende Version mindestens haben.

• OPCProxy.dll Version 2,0,0,1

• OPCComn_ps.dll Version 1,0,0,2 Die Version kann wie folgt ausgelesen werden:

1. DLL mit dem Windows Explorer auswählen, 2. Rechte Maustaste

3. Menü Eigenschaften.

4. Dialog Auswahlfeld „Version“

OPC [1, Kapitel 5.1] schlägt vor den OPC Server unter einer Komponen- tenkategorie zu registrieren. Diese Registrierung wird mit Hilfe der COM- CAT.DLL [LW:]\winnt\system32 durchgeführt.

InProc Server

Out-Proc Server

Proxy/Stub Server

Komponentenkategorien

2.6 Kommunikationsarchitektur

Die Kommunikation zur Steuerung erfolgt über das Indramat Funktions- Interface (siehe Abb. 2-6: Indramat Kommunikationsarchitektur). Der OPC Server meldet sich beim Funktions-Interface an, dies kann einige Sekunden dauern. Beim Beenden des Servers wird die Verbindung zum Funktions-Interface wieder geschlossen.

WinHMI

'SRJMKYVEXMSR XSSPW

;-2

GYWXSQIV

VH TEVX] GYWXSQIV

VH TEVX]

1YPXM 4VSXSGSP -RXIVJEGI

34' 7IVZIV (() 7IVZIV

14- 'SQ HVMZIV

*YRGXMSR-RXIVJEGI

&IXVMIFWW]WXIQ ,EVH[EVI

Abb. 2-6: Indramat Kommunikationsarchitektur

Einige Funktionsaufrufe der Indramat-Benutzeroberfläche (z.B. NC- Parameter-Download oder SPS-Programm-Download) erfordern eine exklusive Nutzung der Kommunikationsverbindung zur Steuerung. Wäh- rend der Ausführung dieser Funktionen; wird der OPC Server in Status OPC_STATUS_SUSPENDED gesetzt und die Gruppenkommunikation unterbrochen. Nach Downloadende wird der Server in vorgehenden Zu- stand zurückgesetzt und die Gruppenkommunikation wird wieder erneu- ert.

Hierzu verarbeitet der OPC Server folgende Systemmeldungen: [3; Kapi- tel 3.5]:

• MSG_PCLUPDBEG

• MSG_PCLUPDEND

• MSG_PARUPDBEG

• MSG_PARUPDEND

2.7 Der Indramat Test OPC-Client

Der Indramat OPC Client unterstützt die Funktionen nach der Spezifikati- on [1] und kann zum Test der Kommunikation zur Steuerung verwendet werden. Der Indramat OPC Client ist nur mit englischer Benutzeroberflä- che verfügbar.

Abb. 2-7: Indramat OPC-Client

Der Indramat OPC Client ist so aufgebaut, dass die über die Register- karten aufrufbaren Dialogseiten die Interfaceklassen eines OPC Servers wiedergeben. Die Schaltflächen des Hauptfenster haben folgende Funkti- on:

Schließt den Dialog. Falls noch eine Verbindung mit einem OPC Server besteht, ist dieser Button in einem nicht aktivem Zustand.

Schließt den Dialog, ohne auf eine bestehende Verbindung zu achten.

Dies sollte nur im Notfall durchgeführt werden.

Feste Positionierung des Fenster auf dem Desktop.

Ausgabe von Informationen und Fehlermeldungen während der Pro- grammausführung. HRESULT Fehlermeldungen können über die Metho- de IOPCServer :: GetErrorString (siehe Registerkarte OPCServer) aus- gelesen werden.

OK

Abbrechen

Calibrate Statuszeile Ausgabe aller OPC Servern, die die Spezifikation 2 unterstützen

Einzelne Methoden eins OPC Servers gegliedert nach Schnittstellennamen Unterstützte Ser- verschnittstellen

Auswahl als InProc-, EXE- oder Remote- server

Verbindung zu einem Server

Serverver- bindung trennen

Aktuelle Clientkonfiguration kann geladen oder gesichert werden

Statuszeile

Nach dem Start des Indramat OPC Clients werden in dem Listfeld „Server List Version 2“ alle registrierten OPC Server aufgelistet

Der Anwender kann in diesem Auswahlfeld den Typ des Server auswäh- len:

• InProc DLL-Server

• Local Exe-Server

• Remote Zugriff auf einen OPC Server über DCOM

Falls ein Remote Server ausgewählt wird, wird ein Eingabedialog geöff- net. In diesem Dialog können dann Angaben gemacht werden, hinsicht- lich Remoterechnername (TCP/IP Nummer), Domänename, Benutzer und Passwort.

Nach getroffener Serverauswahl wird mit Connect eine Verbindung zum Server aufgebaut.

Schließt eine bestehende Verbindung. Es ist darauf zu achten, dass alle Gruppenverbindungen vorher beendet wurden (Fehlermeldung).

Hiermit kann man eine Clientkonfiguration abspeichern. Es werden Grup- pen- und Item-Informationen gesichert.

Die unter OPC Save gesicherten Daten werden eingelesen.

Nach Connect werden alle Schnittstellen angezeigt, die der ausgewählte OPC Servers unterstützt.

Server List Version 2

Server Type

Connect

Disconnect

OPC Save

OPC Load

Server Interface

Dialog IOPCServer

Dieser Dialog liefert die Funktionen für die OPC Gruppenverwaltung, die Schaltflächen entsprechen den Methoden der OPC Schnittstellenklasse IOPCServer.

Abb. 2-8: Statusanzeige auf der Registerkarte IOPCServer

Erstellt mit Hilfe des in Abb. 2-9: Dialog Add Group dargestellten Dialogs eine neue Gruppe. Die Aktualisierungsrate wird im Feld "Requested Up- date Rate" in msec eingegeben. Um die Daten zu übernehmen, muß die Schaltfläche AddGroup betätigt werden. Mit der Schaltfläche OK kann zurück zur Statusübersicht gewechselt werden.

Abb. 2-9: Dialog Add Group AddGroup

Methoden von IOPCServer

OPC Server Sta- tusinformationen

Fehlercodes auszulesen.

Zeigt für die angegebene Gruppe die unterstützten Interfaces an.

Aktualisiert die Werte in der Statusanzeige.

Gruppen könne über Mehrfachselektion gelöscht werden. Grüner Zustand zeigt an, dass diese Gruppe löschbar ist, bei rotem Zustand sind noch Items dieser Gruppe angemeldet.

Erzeugt eine tabellarische Übersicht der Eigenschaften aller Gruppen.

Dialog IOPCItemMgt

Abb. 2-10: Dialog zur Verwaltung von OPC-Items

Auflistung aller angemeldeten Gruppen. Um die Methoden von IOPC- ItemMgt ausführen zu können, ist zunächst eine Gruppe mit der Maus über Doppelklick oder Button Select auszuwählen.

Nach einer Auswahl werden in dem Listfeld, hier „Group1“, die Items mit ihren Attributen ausgegeben.

Auswahl einer Gruppe aus der Liste.

Fügt zur ausgewählten Gruppe neue Items hinzu.

Wird nicht unterstützt.

Löscht das in der Itemliste ausgewählte Item.

Wird nicht unterstützt.

Verändert den Datentyp, des in der Item-Liste ausgewählten Items.

GetGroupByName GetStatus RemoveGroup

CreateGroupEnumerator

Group DClick

Listfeld „Gruppennamen“

Select AddItems ValidateItems RemoveItems SetActiveState SetDataTypes Liste aller

angemelde- ten Gruppen

Liste alle angemel- deten Items mit ihren Attributen. Mehr- fachselektion ist möglich.

Beispiel für Methode AddItems

Dialog IOPCSyncIO

Abb. 2-11: Dialog IOPCSyncIO

Auswahl einer Gruppe.

Nach der Auswahl der Items wird die Lesefunktion ausgeführt, das Er- gebnis wird in dem unteren Listfeld angezeigt.

Für jeden selektierten Schreibwert wird ein Eingabedialog geöffnet. Nach der Eingabe werden die Daten zur Steuerung übertragen.

Lesedaten aus dem Server Cache Lesedaten direkt aus der Steuerung Select

Read

Write

OPC_DS_CACHE OPC_DS_DEVICE

Mehrfachauswahl der Items

Ergebnis eines Methodenaufrufes, hier „Read“

Auswahl Cache Daten oder direkte Steuerungsdaten

Dialog IOPCAsyncIO2

Wegen der Komplexität der asynchronen Datenanforderung werden die einzelnen Methoden der Schnittstelle IOPCAsyncIO2 auf mehrere Dialog- seiten verteilt.

Abb. 2-12: Dialog IOPCAsyncIO2

Auswahl einer Gruppe. Nach der Auswahl wird eine Verbindung zum Ser- ver über IOPCDataCallback erstellt bzw. eine bestehende Verbindung visualisiert.

Eine bestehende Verbindung über die Schnittstelle IOPCDataCallback wird hiermit aufgehoben.

Select

Unadvise

Ergebnisdaten einer zyklischen Verbindung

Dialog IOPCAsyncIO2 Read Write

Abb. 2-13: Dialog IOPCAsyncIO2 Read Write Auswahl einer Gruppe.

Nach einer Itemselektion wird die Lesefunktion der Schnittstellenklasse IOPCAsyncIO2 ausgeführt.

Das asynchrone Lesen wird damit abgebrochen.

Nach einer Itemselektion wird die Schreibfunktion der Schnittstellenklasse IOPCAsyncIO2 ausgeführt. Diese Schreibfunktion öffnet für jeden Schreibwert ein Eingabefeld.

Das asynchrone Schreiben wird damit abgebrochen.

Eine bestehende Verbindung über die Schnittstelle IOPCDataCallback wird hiermit beendet.

Select Read

Cancel2 Read Write

Cancel2 Write Unadvise

Dialog IOPCBrowseServerAddressSpace

Abb. 2-14: Dialog IOPCBrowseServerAddressSpace

Dieser Dialog dient zum Suchen von ItemIDs. Das Ergebnis setzt sich aus der UND-Verknüpfung aller Kriterien zusammen.

Data Type: Suche nach einem bestimmten Datentyp. Beispiel VT_BOOL. Defaultwert = VT_EMPTY

Filter Criteria: Textsuche; Unterscheidung Groß- und Kleinschreibung wird nicht unterstützt. Defaultwert = „*“ oder „“.

Access Rights Filter: Suche nach entsprechenden Zugriffsrechten.

Defaultwert = Readable

Filter Types: Auswahl der Browse Arten. Defaultwert = Flat Startet eine Suchanfrage.

Filterkriterien

BrowseOPCItemIDs

Ergebnis der Suche

Filterkriterium Datentyp Filterkriterium für ItemID

Filterkriterium Zugriffs- rechte

Filterkriterium Browse

Dialog IOPCGroupStateMgt

Abb. 2-15: Dialog IOPCGroupStateMgt

Gruppeneigenschaften können hier geändert werden.

Auswahl einer Gruppe.

Folgende Eigenschaften können mit dieser Funktion verändert werden:

• RequestedUpdateRate

• Active

• TimeBias

• PercentDeadband

• LCID

• ClientGroup

Abänderung des Gruppennamens, es muss darauf geachtet werden, dass der Gruppennamen nicht mehrfach vergeben wurde.

Select SetState

SetName

Group Name wird mit SetName geändert.

SetState ändert diese Eigenschaften

2.8 OPC Server Oberfläche

Die Programmoberfläche gliedert sich in drei Teile,

• dem Hauptfenster mit Menü, Toolbar und Statuszeile,

• Fenster mit allen Clientverbindungen als Baumansicht

• das Infofenster.

Abb. 2-16: OPC Server Oberfläche

Hauptfenster

• Exit: Dieser Menüpunkt sollte nur im Notfall aufgerufen werden, z. B.

Client stürzt ab bevor er die Verbindung schließt.

• Toolbar: Anzeigen bzw. ausblenden der Toolbar.

• Status Bar: Anzeigen bzw. ausblenden der Statuszeile

• Trace Output: Öffnet ein Listfeld im unteren Teil des Infofensters. In diesem Listenfeld werden Traceausgaben protokuliert. Um die Tra- ceausgaben zu minimieren, ist eine Gruppe bzw. Client mit der Maus auszuwählen. Die Auswahl ist durch ein blauen Bitmap gekennzeich- net. Es werden nur 100 Ausgaben ins Listfelde abgelegt, danach wird das Feld gelöscht.

• Trace File: Hier gilt das Gleiche wie unter Trace Output, nur die Daten werden in ein File „OPCInfo.txt“ ausgegeben.

• About OPCIndramat: Programm und Copyright Informationen Entspricht hier den Menüpunkten Menü Tool und Menü ?.

Informationsausgaben des Servers Menü File

Menü View

Menü Tool

Menü ? Toolbar Statuszeile

Toolbar Menü

Statuszeile Hauptfenster Baumansicht

aller Clientver- bindungen

Infofenster Client Namen Gruppen

Namen

Fenster mit den Clientverbindungen

Alle Clientdaten werden in einer Baumstruktur ausgegeben, wobei ein Zweig einem OPC Client entspricht. Die Gruppen werden als Blätter un- terhalb des Zweiges angezeigt. In dem obigen Bild sieht man zwei Clients, die sich mit „Indramat OPC Client“ und „OPCTestClient“ ange- meldet haben, der erste Client besitzt drei Gruppen mit den Gruppenna- men „Group1“, „Group2“ und „Group3“.

Die Bitmaps dienen als Zustandsanzeige:

• Grün, aktiver Zustand

• Rot, nichtaktiver Zustand

• Blau, ausgewählter Zweig, mit Doppelklick der Maus

• Gelb mit Ausrufezeichen, suspendierter Zustand, z. B. über Funkti- ons-Interface Systemmeldung SPS-Download.

Infofenster

Das Infofenster gliedert sich in zwei Teilbereiche, die Statusinformation des ausgewählten Servers oder der Gruppe und ein Listfeld für die Tra- ceausgaben. Dieses Listfeld wird nur sichtbar, wenn Menü Trace Output ausgewählt wurde.

3 Entwicklung eines OPC Clients

3.1 Fehlerbehandlung

HRESULT Fehler

OPC Fehler werden als sogenannte HRESULT – Werte vom Server an den Client übergeben. Ein HRESULT – Wert hat folgenden Aufbau:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16

Sev C R Facility

Abb. 3-1: Aufbau der HRESULT-Werte

Sev: Severity Code (00 Erfolgreich, 01 Information, 10 Warnung, 11 Fehler)

C Flag Kundenfehler

R Reserviert

Facility Facility Code, hier gibt es einige Konstanten (siehe [5])

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Code

Abb. 3-2: Aufbau der HRESULT-Werte (Fortsetzung) Code Facility Status Code

Der OPC Server benutzt als Facility Code die Konstante FACILITY_ITF um Fehler anzuzeigen.

Der „Code“ wird in mehrere Bereiche aufgeteilt:

0x0000 – 0x0200 Reservierte Microsoft Codes, OPC 1.0 Fehlercodes 0x0200 – 0x7FFF Reservierte OPC Foundation 0x8000 – 0xFFFF Fehlercodes des OPC Servers Abb. 3-3: Aufteilung der Facility Codes

Der Indramat OPC Server benutzt als Kommunikationsmittel das Indra- mat Funktions Interface, diese Fehler werden nun im OPC Server in HRESULT – Werte konvertiert.

Das Indramat Funktions Interface selbst hat nun das Problem, Fehler eingesetzter Komponenten weiterzuleiten, dies erfolgt an Hand eines er- weiterten Fehlersystems.

Da diese Fehlernummern abhängig von den eingesetzten Komponenten sind, wird ein HRESULT Fehlercode im Indramat OPC Server dynamisch vergeben, dieser liegt im Bereich 0xEEEE – 0xFFFF.

Der eigentliche Fehler kann mit diesem HRESULT – Wert und der Me- thode GetErrorString dann ermittelt werden.

Wenn man sich mit Remote - Verbindung zwischen Client und Server auseinandersetzt, dann muss man sich auch über die Sicherheit einer Verbindung Gedanken machen, da Client und Server auf verschiedenen Rechner zur Ausführung kommen.

Es gibt zwei Sicherheitsmodelle für Client-Server Verbindungen. Der Grund für diese zwei Modelle liegt darin, dass z. B. COM auch auf Sys- temen laufen muss, wo keine entsprechende Sicherheit nach NT existie- ren, z. B. Windows 95 und Windows 98.

COM Sicherheitsmodell

Die Sicherheit unter COM wird in verschiedene Anwendungsbereiche unterteilt:

• Die Aktivierungskontrolle bestimmt, wer die Ausführung von Kompo- nenten starten darf.

• Die Zugriffskontrolle dient nach dem Start einer Komponente zur Steuerung des Zugriffs auf die Objekte der Komponente.

• Die Authentifizierungskontrolle wird verwendet, um die Berechtigun- gen zu einer Netzwerkübertragung sicherzustellen und die Daten vor unautorisierten Betrachtern zu schützen.

• Die Identitätskontrolle legt die Sicherheitsreferenzen fest, unter deren Kontrolle die Komponente ausgeführt werden soll.

Die Sicherheitseinstellungen einer COM – Komponente wird auf zweierlei Weise konfiguriert:

• als deklarative Sicherheitseinstellungen

• als programmgesteuerte Sicherheitseinstellungen.

Deklarative Sicherheit

Deklarative Sicherheitseinstellungen werden in der Registrierung, unab- hängig vom Code der Komponente konfiguriert (Systemadministrator).

Diese Einstellungen werden mit Hilfe eines DCOM – Konfigurationspro- gramm (dcomcnfg.exe) durchgeführt. Der Benutzer muß dafür System- administrator-Rechte besitzen. Folgende Sicherheitseinstellungen können konfiguriert werden: Aktivierung, den Zugriff, die Authentifizierung und den Identitätswechsel.

Hinweis: Aktivierungs- und Identitätssicherheitseinstellungen lassen sich nicht programmgesteuert festlegen, da diese Einstellun- gen vor dem Start der betreffenden Komponente definiert sein müssen.

Diese Informationen lassen sich in zwei Kategorien zuordnen:

• Standardsicherheit betrifft die Sicherheitseinstellungen für alle auf dem lokalen Computer ausführbaren Komponenten.

• Komponentenbezogene Sicherheitseinstellungen gelten nur für eine bestimmte Komponente und die Standardsicherheitseinstellungen werden überschrieben.

Sowohl die Standardsicherheitseinstellungen als auch die komponenten- bezogenen Sicherheitseinstellungen können durch Programmgesteuerte

Standardsicherheit

Mit Start / Ausführen und dcomcnfg.exe wird das DCOM – Konfigurati- onsprogramm gestartet. Nach dem Start wird das Dialogfenster mit der Auflistung aller konfigurierbaren Komponenten dargestellt (siehe Abb. 3- 4: DCOM-Konfigurator: Komponentenliste).

Abb. 3-4: DCOM-Konfigurator: Komponentenliste

Standardeigenschaften

Mit Hilfe der Standardeigenschaften (siehe Abb. 3-5: DCOM-Konfiguartor:

Standardeigenschaften) kann der Administrator die Einstellungen für Au- thentifizierung und Identitätswechsel rechnerweit festlegen.

Abb. 3-5: DCOM-Konfiguartor: Standardeigenschaften

Die Option DCOM (Distributed COM) auf diesem Computer aktivieren ist der Hauptschalter für die DCOM – Einstellungen. Wenn diese Kontroll- kätschen nicht aktiviert ist, werden alle ein- und ausgehenden Fernaufrufe des Computer zurückgewiesen. Bei der Erstinstallation des Systems wird diese Option aktiviert.

Die Standard – Authentifizierungsebene legt die grundlegende Authentifi- zierungsebene dieses Systems fest. Jede Komponente kann diesen Wert überschreiben.

Authentifizierungsebene Beschreibung

Standard Entspricht gegenwärtig der Authentifizierung auf Verbindungsebene

Keine Keine Authentifizierung

Verbinden Der Client wird nur einmal authentifiziert, nämlich wenn er zum ersten mal eine Verbin- dung zum Server erstellt

Anrufen Der Client wird zu Anfang eines jeden Fernaufrufs authentifiziert.

Paket Authentifiziert wird, dass alle empfangenen Daten von dem Client kommen, von dem sie erwartet werden.

Paketintegrität Es werden alle Daten authentifiziert und es wird gewährleistet, dass die Daten während der Übertragung zwischen Client und Server nicht geändert worden sind.

Paket Privacy Sämtliche Parameter, die in Fernaufrufen übergeben werden, werden authentifiziert, ü- berprüft und verschlüsselt

Option DCOM (Distributed COM) auf diesem Computer aktivieren

Authentifizierungsebene

Die Option Standard – Identitätswechselebene legt die grundlegende I- dentitätswechsel – Ebene fest, die Clients auf diesem System ihren Ser- vern gewähren, wobei wiederum vorausgesetzt wird, dass keine Kompo- nente diesen Wert überschreibt.

Aus der Sicht des Clients ist die Identitätsebne Anonym die sicherste Ein- stellung, da die Komponente hier keine Information über den Client erlan- gen kann.

Die Ebene Identifizieren ist als Defaultwert eingestellt.

Standard - Identi- tätswechselebene

Beschreibung

Anonym Der Client ist dem Server gegenüber anonym. Der Server ist nicht in der Lage, die Identifizie- rungsdaten des Clients zu ermitteln und er kann sich deshalb auch nicht für den Client aus- geben.

Identifizieren Der Server kann die Identifizierungsdaten des Clients ermitteln und sich zum Zweck der ACL- Übertragung als Client ausgeben, aber kann nicht als Client auf Systemobjekte zugreifen Darstellen Der Server kann den Sicherheitskontext des Client simulieren, während er stellvertretend für

den Client agiert.

Delegieren Der Server kann den Sicherheitskontext des Client simulieren, während er stellvertretend für den Client andere Server aufruft.

Abb. 3-7: DCOM-Konfigurator - Standardeigenschaften: Identitätswechselebenen

Standardsicherheit

Mit dem Dialog Standardsicherheit werden die Standardzugriffs- und Standardstartberechtigungen rechnerweit konfiguriert.

Abb. 3-8: DCOM-Konfigurator: Dialog Standardsicherheit Identitätswechselebene

genen Einstellungen bereitstellen. Mit Schaltfläche Standard ändern unter Standard – Zugriffsberechtigungen wird eine Liste der Benutzer und Be- nutzergruppen angezeigt, denen explizit eine Berechtigung gewährt oder verweigert werden kann.

Alle Einträge sind in der Systemregistrierung unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole zu finden. Hier sind folgende Werte von Interesse.

HKEY_LM\SOFTWARE\Microsoft\Ole Beschreibung

DefaultLaunchPermission Definiert, wer Komponenten starten darf. Default darf Administrator, Sys- temkonto und der interaktive Benutzer Komponente starten.

DefaultAccessPermission Definiert, wer auf Komponente zugreifen darf. Der Defaultwert ist leer.

LegacyAuthenticationLevel Legt die Standard – Authentifizierungsstufe fest. (Standard oder Verbinden) LegacyImpersonationLevel Legt die Standard – Imitationsstufe fest. Defaultwert ist Identifizieren.

Abb. 3-9: Standard-Sicherheitseinstellungewn in der Systemregistrierungen

Hinweis: Werden Standardeinstellungen verändert, so treten diese erst nach einem Neubooten des Rechners in Kraft.

Komponentenbezogene Sicherheitseinstellungen

Diese Komponentenbezogenen Sicherheitseinstellungen überschreiben die rechnerweiten Standardeinstellungen. Alle diese Eintragungen werden in der Systemregistrierung unter der AppID der Komponenten hinterlegt.

HKEY_CLASS_ROOT\AppID\{AppID-der Komponente}.

Die nachfolgenden vier Werte entsprechen exakt den vier Bereichen des COM – Sicherheitsmodells (Start-, Zugriffs-, Authentifizierungs- und Iden- titätskontrolle).

AppID Werte Beschreibung

LaunchPermission Definiert, wer die Komponente starten darf

AccessPermission Definiert, wer auf die Komponente zugreifen darf.

AuthenticationLevel Legt die Authentifizierungsstufe für die Komponente fest

RunAs Legt Benutzerkonto fest, unter dessen Kontrolle die Kom-

ponente ausgeführt wird.

Abb. 3-10: Komponentenbezogene Sicherheitseinstellungen

Zu den Komponentenbezogenen Sicherheitseinstellungen gelangt man, indem man in der Komponentenliste (aufgerufen über die Registerkarte Anwendungen - siehe Abb. 3-4: DCOM-Konfigurator: Komponentenliste) die Komponente auswählt und die Schaltfläche Eigenschaft drückt. Ein anschließender Klick auf die Registerkarte Sicherheit zeigt den in Abb. 3- 11: DCOM-Konfigurator: Komponentenbezogene Sicherheitseinstellungen dargestellten Dialog.

Abb. 3-11: DCOM-Konfigurator: Komponentenbezogene Sicherheitseinstellungen

Diese Optionen betreffen die Werte AccessPermission und LaunchPer- mission. Die Defaultwerte werden von den Standardberechtigungen über- nommen. Daher dürfen nach einer Erstinstallation nur Administrator, das Systemkonto und der interaktive Benutzer zugreifen.

Für eine anonyme Aktivierung und einen anonymen Zugriff sind fol- gende Werte Benutzer (Jeder) für die Start- und Zugriffsberechtigung und die Authentifizierungsstufe auf die Einstellung Keine (RPC_C_AUTH_LEVEL_NONE) festzulegen.

Unter Identität wird festgelegt, unter wessen Kontrolle die Komponente ausgeführt werden soll.

Auf der Registerkarte Identität stehen drei Optionen zur Definition des Benutzerskontos zur Verfügung: Interaktiver Benutzer, Benutzer, der die Anwendung startet und Dieser Benutzer. Änderungen, die vorgenommen werden, betreffen den Wert RunAs der AppID.

Identität

einstellung der Komponenten eingestellt und dieser Wert wird nicht als RunAs bei der AppID eingetragen. Diese Einstellung bedeutet, dass wäh- rend der Ausführung der Komponente die Sicherheitsreferenzen des Client – Prozesses verwendet werden. Komponenten mit dieser Identität erhalten nicht ganz vollständigen Sicherheitsreferenzen, z. B. können Fernaufrufe zu anderen Computern nicht durchgeführt werden oder der Zugriff auf gemeinsame Dateien im Netzwerk.

Bei der Identitätseinstellung Interaktiver Benutzer wird die Komponente unter der Kontrolle des aktuellen angemeldeten Benutzers ausgeführt.

Drei Probleme ergeben sich, mit dieser Einstellung:

• Ein Benutzer muss sich angemeldet haben, damit die Komponente ausgeführt werden kann.

• Es ist nicht vorweg bekannt, wer sich angemeldet hat.

• Die Komponente „stirbt“, wenn sich der Benutzer während der Aus- führung abmeldet.

Die Option Dieser Benutzer legt fest, dass die Komponente unter der Kontrolle eines speziellen Benutzerskontos ausgeführt werden soll.

Benutzerkonten, die von COM für Anmeldezwecke verwendet werden, muss die spezielle Berechtigung Anmelden als Stapelverarbeitungsauf- trag zugewiesen werden, denn COM ist sonst nicht in der Lage, eine er- folgreiche Anmeldung unter Verwendung des Kontos durchzuführen.

Diese Berechtigung Anmelde als Stapelverarbeitungsauftrag wird mit Hilfe des Benutzermanagers vergeben: Benutzermanager / Richtlinien / Benutzerrechte und aktivieren Weitere Benutzerrechte anzeigen

Abb. 3-12: DCOM-Konfigurator: Komponentenbezogene Identitätseinstellungen

Programmgesteuerte Sicherheit

Programmgesteuerte Sicherheitseinstellungen werden vom Entwickler in eine Komponente integriert.

Das Konfigurieren von Sicherheitseinstellungen in der Registrierung bietet bestimmte Vorteile: Es erfordert keine besonderen Vorkehrungen auf Seiten des Komponentenentwicklers, und es ermöglicht dem Administra- tor größere Flexibilität bei der Konfiguration der Sicherheits-einstellungen.

Für die meisten Komponenten ist ein kombinierter Ansatz die beste Wahl.

CoInitializeSecurity definiert die Standardsicherheitswerte für einen gege- benen Prozess. Falls ein Prozess diese Funktion nicht selbst aufruft, ver- anlasst COM den Aufruf dieser Funktion automatisch, dabei ermittelt COM die Sicherheitseinstellungen aus der Registrierung.

Von der obigen Funktion sind die Parametern dwAuthnLevel und dwImpLevel die zwei wichtigsten Übergabeparametern.

Der Client deklariert im Aufruf von CoInitializeSecurity mit dem Parameter dwAuthnLevel die Standard – Authentifizierungsebne, die er für ausge- hende Aufrufe verwenden möchte. Die von der Komponente im Aufruf von CoInitializeSecurity mit dem Parameter dwAuthnLevel festgelegten Einstellungen definiert die unterste Ebene, auf der Client Aufrufe akzep- tiert werden.

In jeder Verbindung zwischen einem Client und einer Komponente ermit- telt COM die Authentifizierungseinstellung der Parteien und legt die Au- thentifizierungsebene automatisch die höhere der beiden Einstellungen fest, daraus folgt nun: dwAuthnLevel Client >= dwAuthnLevel Server, für ConnectioPoints gelten folgende Einstellungen dwAuthnLevel Client ==

dwAuthnLevel Server.

Ein anonymer Zugriff wird mit folgenden Einstellungen erlaubt: erster Pa- rameter von CoInitializeSecurity wird mit NULL initialisiert und dwAuthnLevel wird auf Flag RPC_C_AUTHN_LEVEL_NONE gesetzt.

Der Client definiert im Aufruf von CoInitializeSecurity mit dem Parameter dwImpLevel die Standard – Identitätswechsel – Ebene, die der Client den Komponenten gewähren möchte. Dieser Wert wird auf Server – Seite nicht verwendet.

Funktion CoInitializeSecurity

aufrufe vom Client zum Server verifiziert werden, sonder auch umgekehrt.

Mit den Interface – Klassen IConnectionPoint und IOPCAsyncIO2 ruft der Server Funktionen des Clients auf.

Wegen dieser Wechselbeziehung, verwendet der Indramat OPC Server CoInitializeSecurity mit folgenden Parametern und toleriert jeden OPC Client Aufruf.

CoInitializeSecurity (NULL, //pVoid

-1, //cAuthSvc

NULL, //asAuthSvc

NULL, //pReserved1

RPC_C_AUTHN_LEVEL_NONE, //dwAuthnLevel

RPC_C_IMP_LEVEL_IMPERSONATE, //dwImpLevel

NULL, //pAuthInfo

EOAC_NONE, //dwCapabilities

NULL); //pvReserved2

Konfigurationsvorschlag

Wie aus den vorangehenden Kapitel ersichtlich ist, ist eine DCOM Konfi- guration sehr komplex, weil man mit der deklarativen und programmge- steuerten Einstellungen, die Sicherheit und damit auch die Kommunikati- on von Client / Server beeinflussen kann.

Hinzukommt, dass eine Diagnose an Hand der COM - HRESULT Wert erschwert wird, denn eine COM - Fehlermeldung kann mehrere Ursachen haben. Aus diesem Grund sollte man sich an die nachfolgende Konfigu- rationsschritten halten, um eine Fehlerdiagnose zu erleichtern.

Windows NT 4.0 und SP 5 oder größer sollte installiert sein. Mit SP 3 können einige Einstellungen nicht durchgeführt werden.

Der Client - und Server - Rechner soll in eine gemeinsame Domäne ein- getragen werden. Auf beiden Rechner ist ein gemeinsamer Benutzer mit dem selben Passwort einzutragen und unter diesem Benutzer soll die Oberfläche Version bzw. der OPC – Server installiert werden.

Auf der Seite des Client ist das Standardübertragungsprotokoll auszutau- schen. Der Standardwert ist UDP/IP und soll auf TCP/IP vertauscht wer- den, in der angezeigten Liste einfach nach oben verschieben (SP 5 oder grö0er). Der Grund für diese Tausch liegt in einem Fehler von Microsoft zwischen DCOM und UDP/IP. Konfigurationsprogramm DCOMCNFG.EXE ist hier zu verwenden.

Diese Einstellungen sind auf der Seite des Clients und des Servers durchzuführen. Nach der Ausführung von DCOMCNFG.EXE ist der OPC Server „OPC Indramat Server Version 1.0“ unter Anwendungen auszu- wählen und auf die Seite Sicherheit zu wechseln. Vorkonfigurierter Benut- zer und Benutzer „Jeder“ sind sowohl bei Benutzerdefinierte – Zugriffsbe- rechtigungen verwenden, als auch unter Benutzerdefinierte Startberechti- gungen verwenden, Benutzerdefinierte Konfigurationsberechtigungen verwenden einzufügen.

im Indramat OPC Server

Windows NT Servicepacks (SP)

Netzwerkkonfiguration

Deklarative Einstellung

Der Indramat OPC Server hat eine tolerante Sicherheitseinstellung ge- genüber einem OPC Client, diese Einstellung muss dann auch im Client bei den ConnectionPoints IOPCDataCallback bzw. IOPCShutdown be- rücksichtigt werden, da sonst eine Schnittstellenverbindung Server / Client über Advise nicht möglich ist, daher sollte der Client CoInitializeSe- curity mit den obigen beschriebenen Einstellungen aufrufen.

Zusammenfassung DCOM Einstellungen

Server Client

Allgemein Domäne Gleiche Domäne Gleiche Domäne

Benutzer manager

Gleicher Benutzer und Passwort eintragen und einloggen

Gleicher Benutzer und Passwort eintragen und einloggen

Benutzer manager

Gast Konto aktivieren Gast Konto aktivieren

Nur Deklarativ dcomcnfg.exe 1 Anwendungen OPC Indramat Server Ver- sion 1 auswählen

2 Allgemein Authentifizieungs stufe auf Kein setzen.

3 Sicherheit Benutzerdefinierte Startbereich- tigungen vewenden: Jeder und eingeloggter Benutzer eintragen

4 Sicherheit Benutzerdefinierte Zugriffsbe- reichtigungen vewenden: Benutzer Jeder und eingeloggter Benutzer eintragen

Deklarativ und Pro- grammgesteuerert

1 Anwendungen OPC Indramat Server Ver- sion 1 auswählen

2 Sicherheit Benutzerdefinierte Startbereich- tigungen vewenden: Benutzer Jeder und eingeloggter Benutzer eintragen

3 Sicherheit Benutzerdefinierte Zugriffsbe- reichtigungen vewenden: Benutzer Jeder und eingeloggter Benutzer eintragen

4 Programmierung:

CoInitializeSecurity(

NULL, -1, NULL, NULL,

RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_IMPERSONATE, NULL,

EOAC_NONE, NULL)

1 Programmierung: Für IOPCDataCallbak und I- OPCShutdown

CoInitializeSecurity(

NULL, -1, NULL, NULL,

RPC_C_AUTHN_LEVEL_N ONE,

RPC_C_IMP_LEVEL_IMPE RSONATE,

NULL, EOAC_NONE, NULL);

2 Programmierung: ver- besserte Anmeldung CoCreateInstanceEx und COSERVERINFO, COAUTHINFO,

COAUTHIDENTITY Struktu- ren

Abb. 3-13: Zusammenfassung der DCOM Einstellungen Programmgesteuerte

Einstellungen

3.3 Testprogramm der OPC-Foundation

Die OPC Foundation liefert ein Programmwerkzeug, um ein bestehende OPC Installation lokal, sowie auch Remote zu überprüfen.

Für diesen Test sind folgende Programme zu installieren bzw. anzuwen- den.

ActxPrxy.dll: [LW]:\winnt\system32, falls diese DLL nicht existiert ist Installationsprogramm Aprxdist.exe aufzurufen.

OPCEnum.exe: [LW]:\winnt\system32 zu installieren und registrieren mit opcenum /regserver.

Enumtest.exe: Konsole Testprogramm für eine bestehende OPC Installation zu überprüfen. An Hand eines Beispiels wird die Anwendung erklärt.

Abb. 3-14: Hauptfenster des Tracemonitors

Versionsabhän- gige Programm Lokaler Test und Ergeb-

Remote Server

Remote Test und Ergeb-

4 Literatur

[1] Data Access Custom Interface Standard Version 2.03 (July 27, 1999); http://www.opcfoundation.org.

[2] Data Access Automation Interface Standard Version 2.02 (Febru- ary 4, 1999); http://www.opcfoundation.org.

[3] System200 Funktions-Interface 04VRS Anwendungsbeschrei- bung,

Rexroth Indramat DOK-CONTRL-FUN*INT*V04-AW01-DE-P [4] OPC Common Definitions and Interfaces;

http://www.opcfoundation.org.

[5] Inside Distributed COM, Microsoft Press ISBN 3-86063-459-3

5 Abbildungsverzeichnis

Abb. 1-1: Anwendungen arbeiten mit OPC-Servern verschiedener Hersteller zusammen 1-2

Abb. 1-2: Zuordnung von OPC Items zur OPC Group 1-3 Abb. 1-3: Custom Schnittstelle und Automation Schnittstelle 1-4 Abb. 1-4: Custom Schnittstelle und Automation Schnittstelle 1-4 Abb. 2-1: Interfaces und Methoden von OPCServer 2-2

Abb. 2-2: Interfaces und Methoden von OPCGroup 2-3

Abb. 2-3: Umsetzung der SPS-Datentypen in der OPC-Schnittstelle 2-5 Abb. 2-4: Installierte Dateien 2-6

Abb. 2-5: Einträge in der System Registry 2-6 Abb. 2-6: Indramat Kommunikationsarchitektur 2-8 Abb. 2-7: Indramat OPC-Client 2-9

Abb. 2-8: Statusanzeige auf der Registerkarte IOPCServer 2-11 Abb. 2-9: Dialog Add Group 2-11

Abb. 2-10: Dialog zur Verwaltung von OPC-Items 2-12 Abb. 2-11: Dialog IOPCSyncIO 2-13

Abb. 2-12: Dialog IOPCAsyncIO2 2-14

Abb. 2-13: Dialog IOPCAsyncIO2 Read Write 2-15 Abb. 2-14: Dialog IOPCBrowseServerAddressSpace 2-16 Abb. 2-15: Dialog IOPCGroupStateMgt 2-17

Abb. 2-16: OPC Server Oberfläche 2-18 Abb. 3-1: Aufbau der HRESULT-Werte 3-1

Abb. 3-2: Aufbau der HRESULT-Werte (Fortsetzung) 3-1 Abb. 3-3: Aufteilung der Facility Codes 3-1

Abb. 3-4: DCOM-Konfigurator: Komponentenliste 3-3 Abb. 3-5: DCOM-Konfiguartor: Standardeigenschaften 3-4 Abb. 3-6: DCOM-Konfigurator - Standardeigenschaften: Mögliche

Authentifizierungsebenen 3-4

Abb. 3-7: DCOM-Konfigurator - Standardeigenschaften:

Identitätswechselebenen 3-5

Abb. 3-8: DCOM-Konfigurator: Dialog Standardsicherheit 3-5 Abb. 3-9: Standard-Sicherheitseinstellungewn in der

Systemregistrierungen 3-6

Abb. 3-10: Komponentenbezogene Sicherheitseinstellungen 3-6 Abb. 3-11: DCOM-Konfigurator: Komponentenbezogene

Sicherheitseinstellungen 3-7

Abb. 3-12: DCOM-Konfigurator: Komponentenbezogene Identitätseinstellungen 3-8

Abb. 3-13: Zusammenfassung der DCOM Einstellungen 3-11 Abb. 3-14: Hauptfenster des Tracemonitors 3-12

6 Index

A

AddItems 2-4

D

Data Access Custom Interface 2-1, 2-2 DCOM 1-1

DCOM-Konfiguration 3-2

F

Fehlerbehandlung 3-1 Funktions-Interface 2-8

G

GetErrorString 2-4

I

Inproc Servern 1-5

K

Kunden- und Automationsschnittstellen 1-4

L

Lokale Server 1-5

O

OPC 1-1

OPC Server 2-18 OPC-Gruppe 1-3 OPC-Item 1-3 OPCITEMDEF 2-4 OPC-Server Objekt 1-3 Out-Proc Server 1-5

R

Remote Server 1-5

T

Test OPC Client 2-9

7 Kundenbetreuungsstellen - Sales & Service Facilities

Deutschland – Germany

from abroad: don’t dial (x) after country code!

Vertriebsgebiet Mitte SALES

Germany Centre Service

Rexroth Indramat GmbH Bgm.-Dr.-Nebel-Str. 2 97816 Lohr am Main Telefon: +49 (0)9352/40-0 Telefax: +49 (0)9352/40-4885

Kompetenz- Zentrum Europa

S E R V I C E

C A L L E N T R Y C E N T E R MO – FR von / from 7 – 18 Tel. +49 (0) 9352 40 50 60

service@indramat.de

S E R V I C E H O T L I N E

MO – FR von / from 17 - 07 + SA / SO Tel.: +49 (0)172 660 04 06

o d e r / o r Tel.: +49 (0)171 333 88 26

S E R V I C E

ERSATZTEILE / SPARES verlängerte Ansprechzeit:

- extended office time -

♦ nur an Werktagen - only on working days -

♦ von 15 -18 Uhr - from 15-18 o'clock - Tel. +49 (0) 93 52/40 42 22

Vertriebsgebiet Süd SALES

Germany South Service

Rexroth Indramat GmbH Ridlerstraße 75 80339 München

Telefon: +49 (0)89/540138-30 Telefax: +49 (0)89/540138-10 indramat.mue@t-online.de

Gebiet Südwest SALES

Germany South-West Service

Mannesmann Rexroth AG Vertrieb Deutschland – VD-BI Geschäftsbereich Rexroth Indramat Regionalzentrum Südwest Ringstrasse 70 / Postfach 1144 70736 Fellbach / 70701 Fellbach Tel.: +49 (0)711/57 61–100 Fax: +49 (0)711/57 61–125

Vertriebsgebiet Ost SALES

Germany East Service

Rexroth Indramat GmbH Beckerstraße 31 09120 Chemnitz

Telefon: +49 (0)371/35 55-0 Telefax: +49 (0)371/35 55-333

Vertriebsgebiet Nord SALES

Germany North Service

Mannesmann Rexroth AG Vertriebsniederlassung Region Nord Gesch.ber. Rexroth Indramat Walsroder Str. 93

30853 Langenhagen

Telefon: +49 (0) 511/72 66 57-0 Telefax: +49 (0) 511/72 66 57-93

Vertriebsgebiet West SALES

Germany West Service

Mannesmann Rexroth AG Vertrieb Deutschland Regionalzentrum West Borsigstrasse 15 D - 40880 Ratingen Telefon: +49 (0)2102/409-0 Telefax: +49 (0)2102/409-406

Vertriebsgebiet Mitte SALES

Germany Centre Service

Mannesmann Rexroth AG Gesch.ber. Rexroth Indramat Lilistraße 14-18

63067 Offenbach

Telefon: +49 (0) 69/82 00 90-0 Telefax: +49 (0) 69/82 00 90-80

Vertriebsgebiet Ost SALES

Germany East Service

Mannesmann Rexroth AG GB Rexroth Indramat GmbH Holzhäuser Str. 122 04299 Leipzig

Telefon: +49 (0)341/86 77-0 Telefax: +49 (0)341/86 77-219

Vertriebsgebiet Nord SALES

Germany North Service

Rexroth Indramat GmbH Kieler Straße 212 22525 Hamburg

Telefon: +49 (0)40/85 31 57-0 Telefax: +49 (0)40/85 31 57-15

Kundendienstniederlassungen in Deutschland - Service agencies in Germany