Click here to load reader

Entwurf,)Errichtungund) …1]isteineGPL6lizensierteJava6BibliothekfürSCADA6Systeme.SCADA („supervisorycontrolanddataacquisition“)beschreibt$einComputersystemzur$ OPCServer/Client$unter$Linux$Seite$9von$15#

  • View
    216

  • Download
    2

Embed Size (px)

Text of Entwurf,)Errichtungund) …1]isteineGPL6lizensierteJava6BibliothekfürSCADA6Systeme.SCADA...

  • OPC Server/Client unter Linux Seite 1 von 15 EEMD

    Entwurf, Errichtung und Management von Datennetzen, LU

    Gruppe 6: OPC-Server/Client unter Linux

    Teammitglieder:

    Name Matrikelnummer Studienkennzahl Flemon Ghobrial 0725999 033534 Christoph Gratzer 0726416 033534 Thomas Pani 0726415 033534

  • OPC Server/Client unter Linux Seite 2 von 15 EEMD

    Inhalt Allgemein .............................................................................................................................. 3

    Recherche.............................................................................................................................. 3

    Was ist berhaupt OPC? ................................................................................................ 3

    Wie funktioniert der Datenaustausch mit OPC?............................................................ 4

    Wie funktioniert OPC? ................................................................................................... 4

    OPC Data Access ............................................................................................................ 5

    OPC Unified Architecture............................................................................................... 6

    j-Interop ......................................................................................................................... 7

    OpenSCADA Framework /Utgard Projekt ...................................................................... 8

    OPC Server unter Linux .................................................................................................. 9

    Implementierung des plattformunabhngigen OPC-Clients ............................................... 10

    Beschreibung ............................................................................................................... 10

    Probleme...................................................................................................................... 11

    Testaufbau ................................................................................................................... 12

    Links .................................................................................................................................... 15

    Referenzen (alle Links waren am 30.1 abrufbar) ......................................................... 15

    Weiterfhrende Literatur ............................................................................................ 15

  • OPC Server/Client unter Linux Seite 3 von 15 EEMD

    Allgemein Gleich nach der Themenvergabe begannen wir mit der Arbeit in Form einer Recherchephase. Dazu haben wir ein Onlinedokument erstellt und in diesem alle gefundenen Links zum Thema OPC eingetragen. Da wir OPC bis dahin noch nicht kannten, erstellen wir auerdem eine kleine Zusammenfassung der Frage Was ist berhaupt OPC?.

    Im nchsten Schritt suchten wir nach Mglichkeiten der OPC Implementierung unter Java. Dabei stieen wir auf verschiedene Bibliotheken: OPC Unified Architecture [5], J-Interop [6], OpenScada [1],

    Bei der ersten bungsbesprechung prsentierten wir dann unsere Ergebnisse. Dabei legten wir uns auf OPC Unified Architecture [5] als Untersuchungsframework fest. Wir sollten die Referenzimplementierung testen und eine Feature Implementierung erstellen. Da es danach Probleme mit dem Quellcode gab (OPC Unified Architecture ist in einer geschlossenen Testphase und darf nur von Komitee Mitgliedern eingesetzt werden, fr uns wurde keine Ausnahme gemacht), mussten wir uns eine andere Mglichkeit suchen.

    Als neue Testimplementierung haben wir uns fr das OpenScada/Utgard Framework [1] entschieden. Auerdem haben wir schnell gemerkt, dass ein OPC Server unter Linux mit dem derzeit blichen DCOM-Zugriff faktisch unmglich ist (zumindest im Rahmen dieser bung, siehe Punkt OPC Server unter Linux). Deshalb haben wir uns auf die Implementierung eines OPC Testclients konzentriert. Fr den Testaufbau haben wir uns auerdem fr einen Windows OPC Server Simulator entschieden (Matrikon OPC Simulation Server [4]).

    Mit diesem Testclient implementierten wir verschiedene Abfragemglichkeiten fr Daten von einem OPC Server. Diese Arbeiten waren Anfang Jnner abgeschlossen. In diesem Dokument werden nun die einzelnen Schritte/Erkenntnisse dieser Studie nher beschrieben.

    Recherche

    Was ist berhaupt OPC?

    1994 grndete eine Gruppe von Herstellern (die einem breiten Spektrum angehrten) die OPC Founcation. Ziel war die Entwicklung einer Server/Client Spezifikation, die herstellerbergreifend funktioniert. Die erste Spezifikation wurde Data Access Specification 1.0a genannt und 1996 verffentlicht. Mit dieser Spezifikation war es leicht und schnell mglich, kompatible Server/Clients zu schreiben.

    OPC hie ursprnglich OLE for Process Control; jetzt wird es nur mehr als OPC bezeichnet. Der Name bezeichnet eine standardisierte Software-Schnittstelle, die es ermglicht Daten zwischen Anwendungen unterschiedlicher Hersteller der Automatisierungstechnik zu auszutauschen. Heute wird OPC berall dort eingesetzt, wo es Sensoren, Regler und Steuerungen ein gemeinsames Netzwerk bilden.

  • OPC Server/Client unter Linux Seite 4 von 15 EEMD

    Bevor es OPC gab, war der dieser Datenaustausch eine sehr schwierige Sache. Jeder Hersteller hatte unterschiedliche Implementierungen und Besonderheiten. Fr eine Verbindung waren genaue Kenntnisse der Kommunikationsmglichkeiten und Schnittstellen der verschiedenen Gerte ntig. Auer dem enormen Fachwissen, waren aber auch Erweiterungen und Anpassungen bei diesen Systemen nur sehr schwer mglich.

    Wie funktioniert der Datenaustausch mit OPC?

    OPC abstrahiert nun diesen Vorgang. Das heit, dass beide Seiten OPC konforme Treiber schreiben und durch diese Kapselung eine Verbindung zwischen den zwei Seiten aufgebaut werden kann. Dadurch knnen Implementierungen und Anpassungen komplexer Systeme viel einfacher geschaffen werden.

    OPC basiert dabei auf einer Server/Client Architektur. Das heit, dass die Seite, die Daten zur Verfgung stellt, als Server fungiert. Die Daten liest der Server von Systemen mit meist proprietren Schnittstellen, kapselt sie in OPC-Objekte und macht sie fr Client-Zugriffe lesbar. Ein oder mehrere Clients knnen dann auf die per OPC freigegebenen Daten zugreifen und diese weiterverarbeiten (Statistiken erstellen, Grafische Anzeigen, Auswertungen, ).

    Zugriff von mehreren OPC Clients auf OPC Server von verschiedenen Herstellern:

    http://www.kepware.com/web_images/OPCClientServer1.gif

    Wie funktioniert OPC?

    Auf der Serverseite werden die OPC Daten gekapselt. Danach erfolgt die Kommunikation zu den Clients ber die DCOM Schnittstelle. Diese wurde von Microsoft entwickelt, um den Zugriff auf COM-Objekte auch ber Netzwerk zu ermglichen. Die Abkrzung bedeutet Distributed Component Model. DCOM ist darauf optimiert, die bertragungs- bzw. Zugriffsgeschwindigkeit nicht durch unntigen Verwaltungsoverhead zu bremsen. Auerdem ist es damit mglich, die Daten aus dem gleichen Adressraum, von einem fremden Prozess

  • OPC Server/Client unter Linux Seite 5 von 15 EEMD

    oder von einem entfernten Rechner zu beziehen. Fr die Verbindung zu entfernten Rechnern wird TCP verwendet.

    Der OPC Server holt sich die Daten von Sensoren, Reglern oder Steuerungen ber einen proprietren Controller (dieser ist ber einen Bus an die Gerte angeschlossen). Ein Treiber dient dazu, den proprietren Controller anzuspreichen, und die ausgelesenen Daten ber eine wohldefinierte Schnittstelle dem Server zur Verfgung zu stellen. Diese Daten werden nun vom Server verarbeitet und als OPC Objekte gekapselt. Der OPC Client kann nun auf ber ein normales Datennetzwerk auf diese Daten zugreifen. Anschlieend kann er nun diese Daten auswerten bwz. weiterverarbeiten.

    Auer der normalen Client fordert Daten vom Server-Lsung, gibt es auch noch weiter Mglichkeiten des Zugriffs:

    OPC Aggregation: Ein OPC Client kann auf mehrere OPC Server zugreifen (zum Beispiel als berwachungsstation).

    OPC Tunnelling: Ein OPC Client stellt eine Verbindung zum OPC Server ber einen Netzwerktunnel her.

    OPC Bridging: Eine Verbindung zwischen verschiedenen OPC Servern fr den Datenaustausch.

    OPC Data Access

    Einen OPC Server kann man als Zusammenschluss von mehreren Objekten sehen: der Server, Gruppen und die Elemente (items). Das Server-Objekt dient als Container fr die vorhandenen Gruppen und speichert Informationen ber den Server. Das Gruppen-Objekt enthlt ein oder mehrere Elemente (die logisch organisiert sein knnen) und allgemeine Informationen ber die Gruppe. Die Gruppen dienen zur logischen Organisation der Daten. Die Daten knnen gelesen und geschrieben werden. Einzelne Gruppen knnen aktiviert oder deaktiviert werden. Der OPC Client kann auerdem festlegen, in welchem Zeitraum die Abfragen an den Server durchgefhrt werden (Ausnahmen basierende Verbindungen sind auch mglich).

    http://www.kepware.com/web_images/OPCGroup1.gif

  • OPC Server/Client unter Linux Seite 6 von 15 EEMD

    Es gibt zwei Arten von OPC Gruppen: ffentlich (public) und privat (local oder private):

    public: Die Gruppe ist ffentlich und auf mehreren Clients verfgbar. private: Die Gruppe ist lokal fr einen Client und von auen nicht erreichbar.

    Innerhalb einer Gruppe kann ein Client ein oder mehrere OPC Elemente definieren. Jedes Element stellt dabei eine Verbindung zu den Datenquellen innerhalb des Servers dar (OPC Element DataSource). Auf ein Element kann nur indirekt ber eine Gruppe zugegriffen werden, dh. beim Zugriff muss eine solche ev. erstellt werden. Ein Element besteht aus dem Wert, der Qualitt und einem Zeitstempel.

    OPC Unified Architecture

    OPC Unified Architecture (OPC UA) ist die neueste Version der OPC-Spezifikation. Sie wurde von der OPC Foundation 2006 ins Leben gerufen und unterscheidet sich erheblich von ihren Vorgngern. Im Februar 2009 ist die aktuellste Version verffentlicht worden.

    OPC nutzt die COM/DCOM-Schnittstelle und verdankt ihr auch die weite Verbreitung. Dennoch wurde entschieden, fr OPC UA die COM/DCOM-Schnittstelle aufzugeben, da sie erhebliche Nachteile fr Entwickler mit sich brachte, nmlich:

    Das Konfigurieren von DCOM ist unflexibel und bringt Probleme mit sich Konfigurierbare Timeouts sind nicht mglich Da der Quellcode nicht frei ist, ist man an das Windows-Betriebssystem gebunden

    o Entwickler knnen den Quellcode nicht einsehen und knnen Fehlern nicht entgegenwirken

    Es existierte keine ausreichende Sicherheit

    Daher wurde die OPC UA entwickelt, in der diese Nachteile behoben wurden. Der neue Standard implementiert einen neuen Kommunikations-Stack anstelle der COM/DCOM-Schnittstelle, und bringt die folgenden Vorteile:

    OPC-Implementierungen sind in C mglich Verwendung in Embedded-Controllern bis hin zu Mainframes mglich OPC-UA untersttzt nun Multithreading sowie Singlethreading Verwendet nun Sicherheitsprotokolle die den neuesten Standards entsprechen Beidseitiger Heartbeat wurde eingefhrt; dh. Server und Client erkennen, wenn die

    andere Instanz ausfllt und knnen darauf reagieren Verbindungsunterbrechungen fhren dank ausfallssicherer Datenbertragung nicht

    mehr zu Datenverlust OPC-UA untersttzt Redundanz

    Man entschied sich bei der Entwicklung von OPC UA bezglich des logischen Aufbaus fr eine Service Oriented Architecture (SOA):

  • OPC Server/Client unter Linux Seite 7 von 15 EEMD

    http://www.ascolab.com/images/stories/ascolab/pic/png/ua_archtitecture_en512.png

    Bei der Entwicklung von OPC UA hat man ebenfalls an die Implementierung in verschiedenen Programmiersprachen gedacht; derzeit werden kommerzielle und Referenz-APIs zu den Sprachen C, C++ und .NET entwickelt. Der Hauptgedanke ist, performante und plattformunabhngige Implementierungen zu ermglichen. Allerdings wird es noch dauern, bis kostenfreihe und/oder offene Bibliotheken zur Verfgung stehen.

    j-Interop

    Da die Auseinandersetzung mit OPC UA aufgrund mangelnder Verfgbarkeit entsprechender Bibliotheken nicht weitergefhrt werden konnte, betrachteten wir anschlieend die ltere, DCOM-basierte OPC-Spezifikation. Fr den Einsatz unter Linux musste eine plattformunabhngige DCOM-Implementierung gefunden werden; j-Interop bietet eine solche Implementierung:

    Java untersttzt standardmig den Zugriff auf native Methoden/Programme. Dazu wird das Java Native Interface (JNI) eingesetzt. JNI besitzt aber nicht nur Vorteile, sondern auch groe Nachteile. Die Schnittstelle (JNI) ist zwar in Java verfasst, trotzdem muss der Entwickler ber groes Wissen, was die native Komponente betrifft, verfgen. Solche Experten sind schwer zu finden und daher auch sehr teuer. Auerdem sind dadurch Anpassungen nur sehr schwer mglich.

    Ein weiterer Nachteil ist, dass durch den Einsatz von JNI die Plattformunabhngigkeit von Java aufgehoben wird. Die bersetzte Anwendung wird direkt an das Hostsystem gebunden. Wenn man zum Beispiel JNI in einer Windows Umgebung einsetzt und fr den Zugriff eine native DLL (Bibliothek) verwendet, so ist das Programm dann nur unter Windows lauffhig. Fr eine Portierung auf andere Plattformen (im konkreten Fall Linux), msste man zustzlich zum Programm, auch die Bibliothek (DLL) portieren.

  • OPC Server/Client unter Linux Seite 8 von 15 EEMD

    j-Interop [6] adressiert diese Nachteile im Bereich von DCOM und schafft eine plattformunabhngige Lsung, die den Zugriff kapselt und die Entwicklung deutlich erleichert. Es basiert auf MSRPC und ist ein freies, ausschlielich in Java entwickeltes, Framework. Dadurch kann es auch auf Nicht-Windows Systemen eingesetzt werden. Mit j-Interop erstellte Programme laufen ohne Portierung auf verschiedenen Plattformen.

    Im Folgenden zwei Bilder, die den Unterschied zwischen einem Zugriff mit JNI und dem Einsatz von j-Interop aufzeigen.

    Schema bei Einsatz von JNI:

    http://www.j-interop.org/img/figure1.gif

    Schema bei Einsatz von j-Interop:

    http://www.j-interop.org/img/figure2.gif

    OpenSCADA Framework /Utgard Projekt

    OpenSCADA [1] ist eine GPL-lizensierte Java-Bibliothek fr SCADA-Systeme. SCADA (supervisory control and data acquisition) beschreibt ein Computersystem zur

  • OPC Server/Client unter Linux Seite 9 von 15 EEMD

    berwachung und Steuerung industrieller Prozesse und ist im deutschen Sprachraum auch alsberwachung, Steuerung, Datenerfassung (SE) bekannt.

    Im Rahmen von SCADA ist OPC ein hufig eingesetztes Kommunikationsprotokoll. Als solches wird im Rahmen von OpenSCADA auch die plattformunabhngige Java OPC-Client-API Utgard [2] entwickelt.

    Utgard nutzt zur Kommunikation mit dem OPC Server zwar nach wie vor j-Interop, stellt aber eine API auf hherer Ebene bereit. Dadurch entsprechen die Aufrufe den blichen OPC-Objekten (Server-Liste, Baum, Gruppen, Elemente,...); der Programmierer muss sich nicht mit den komplexen DCOM-Aufrufen beschftigen.

    Zur Authentifizierung nutzt Utgard die Java-Bibliothek jCIFS [3], die neben den eigentlichen SMB/CIFS-Funktionen auch eine NTLM-API in reinem Java bereitstellt.

    Schematisch gestaltet sich der Aufbau des verwendeten Software-Stacks also derart:

    OPC Server unter Linux

    Der OPC-Standard war aus mehreren Grnden fr lange Zeit auf Linux Servern nicht umgesetzt:

    Da OPC zur Datenbertragung auf DCOM setzt, die DCOM-Schnittstelle von Microsoft aber zur Windows-Produktreihe entwickelt worden ist, gestaltet sich das Hosten von (D)COM-Objekten auf Linux-Servern sehr komplex.

    Die Treiber, die von OPC-Servern verwendet werden, um den proprietren Datenzugriff durchzufhren, liegen ebenfalls nur als native DLLs vor. Das fhrt zu

  • OPC Server/Client unter Linux Seite 10 von 15 EEMD

    einer hnlichen Problematik wie bei den OPC-Clients; jeder Treiber msste in der fr den Server gewhlten, plattformunabhngigen Sprache neu implementiert werden. Da diese Treiber blicherweise vom Hersteller des proprietren Systems geliefert werden, ist eine einheitliche Portierung unmglich.

    Es gibt einige kommerzielle Server-Systeme, die den Zugriff auf bestimmte Datenquellen unter Linux erlauben, da fr diese speziell neue Treiber entwickelt wurden. Ein Beispiel dafr ist autinityPLC, das den Zugriff auf Siemens Simatic S5 bzw. S7 erlaubt. [11] Eine allgemeine Lsung stellt das aber nicht dar, fr jede bentigte Datenquelle msste zustzlich ein passender Treiber (ev. mit ernstzunehmendem Revere-Engineering-Aufwand) in Auftrag gegeben werden.

    Viele Unternehmen / OPC-Nutzer bevorzugen es deshalb, ihren OPC-Server selbst zu implementieren. Genau hier setzen viele kommerzielle Lsungen an, und bieten Toolkits (meist fr C / C++) an, die sich unter Linux und Windows kompilieren lassen.

    Eine ungefhre Darstellung preislicher Obergrenzen fr solche Toolkits bietet eine Aufstellung auf opcconnect.com: [10]

    Client Toolkit 1250$ Server Toolkit (fr Schnellimplementationen, nicht alle Features werden mitgeliefert)

    1250$

    Server Toolkit (Alle Features sind vorhanden, mit Source Code)

    4500$

    Ein Beispiel fr solche Bibliotheken ist die OPC-Toolbox von Softing. Man erhlt den Source in Form von Bibliotheken gegen Bezahlung und muss sich den OPC-Server selber schreiben. Dies kann man jedoch gleichermaen unter Windows und Linux bewerkstelligen, da die Bibliotheken in der Toolbox fr verschiedene Programmiersprachen (C++, C#, etc.) und ohne plattformspezifische Abhngigkeiten ausgeliefert werden.

    Implementierung des plattformunabhngigen OPC-Clients Zur Implementierung wurde das whrend der Recherche-Phase evaluierte und favorisierte Utgard (welches wiederum auf j-Interop basiert) eingesetzt. Das API von Utgard ist grundstzlich bersichtlich gestaltet. Im Folgenden werden jene Teile der Bibliothek nher beschrieben, deren Verwendung und Zusammenhang nicht unmittelbar verstndlich ist; anschlieend wird auf die konkrete Implementierung eingegangen.

    Beschreibung

    Die Verbindung zum Server wird mittels einer Instanz von ConnectionInformation verwaltet. Da auf einem physischen Host mehrere OPC-Server Instanzen laufen knnen, muss der Ziel-

  • OPC Server/Client unter Linux Seite 11 von 15 EEMD

    OPC-Server mit der CLSID angesprochen werden. Die CLSID ist eine global eindeutige ID (GUID), die ein COM-Objekt identifiziert. Die CLSID eines OPC Servers ist blicherweise in der jeweiligen Dokumentation beschrieben, oder kann beim Hersteller erfragt werden. Soll ein fixer OPC-Server angesprochen werden, so kann diese Information hardcoded im Client-Programm vermerkt werden. Andernfalls stellt Utgard die Klasse ServerList bereit, mittels welcher ber alle OPC-Server am Ziel-Host iteriert werden kann. Dabei wird unter anderem der Programmname und die zugehrige CLSID abgefragt.

    Nach erfolgtem Verbindungsaufbau stehen wahlweise FlatBrowser oder TreeBrowser Objekte zur Verfgung, um den vom OPC-Server publizierten Item-Baum zu durchmustern.

    Soll ein Item ausgelesen werden, stehen zwei grundstzliche Modelle zur verfgung:

    - Expliziter, synchroner Lesezugriff. - Lesezugriff ber Callbacks in einem eigenen Thread.

    In jedem Fall muss zum Auslesen der absolute Pfad des Items bergeben werden. Ist dieser noch nicht bekannt, kann mit den oben erwhnten Browser-Objekten nach dem Item gesucht werden. Beim expliziten Lesezugriff ist zustzlich eine Group zu erstellen, in der das/die zu lesenden Items aufgenommen werden. Anschlieend wird der aktuelle Zustand des Item mit synchronen Aufrufen ausgelesen. Eventuell (je nach Anwendung) muss abschlieend ist die angelegte Group wieder gelscht werden. Beim Lesezugriff mit Callbacks muss manuell keine Group angelegt werden; Utgard erzeugt eine zufllig benannte und lscht sie nach Ende des Lesevorgangs wieder. Fr den eigentlichen Zugriff wird eine konkrete Instanz von AccessBase erzeugt; dabei wird festgelegt in welchen Intervallen der Zugriff erfolgen soll. Auerdem wird ein Callback-Objekt bergeben; eine Beispiel-Implementierung findet sich im beiliegenden Quellcode. Anschlieend kann ber das AccessBase-Objekt ein neuer Lese-Thread gestartet und gestoppt werden; solange dieser Thread luft, wird in den angegebenen Intervallen das Item ausgelesen und die so gewonnene Information dem Callback-Objekt bergeben.

    Probleme

    Whrend der Implementierungsarbeit konnten folgende Unzulnglichkeiten am Utgard-Projekt festgestellt werden:

    Sprliche Dokumentation. Zwar steht fr die Bibliothek eine Javadoc-basierte Dokumentation zur Verfgung [7], diese ist aber in wesentlichen Stellen unvollstndig. Daher konnten selbst fr die kompakte Funktion des implementierten Test-Clients manche Teile nur durch Ausprobieren verwirklicht werden.

    Starke Modularisierung. Durch den modularen Aufbau von Utgard und die Abhngigkeit von j-Interop und jCIFS sind Fehlerquellen nur schwer aufzufinden. Whrend der Implementierung trat frh das Problem auf, dass keine Verbindung zum Test-Server

  • OPC Server/Client unter Linux Seite 12 von 15 EEMD

    aufgebaut werden konnte. Aus der Fehlermeldung konnte aber nicht geschlossen werden, ob der Fehler direkt in der Utgard Bibliothek, im DCOM-Zugriff mit j-Interop, oder in der NTLM-Authentifizierung mit jCIFS lag. Daher entstanden Tests (im beiliegenden Sourcecode die Packages jcifs und jinterop), die nur die jeweilige Kompenente nutzen, um die Fehlerquelle zu isolieren. Sollten in einem ambitionierteren Projekt mehrere derartige Fehler auftreten, knnte das Debugging einen zustzlichen (mglicherweise unerwartet hohen) zeitlichen und/oder budgetren Aufwand bedeuten, der jedenfalls in die Risikobestimmung einflieen muss.

    Testaufbau

    Softwareausstattung.

    Die primre Entwicklung des OPC-Clients wurde unter Ubuntu 9.10 durchgefhrt und anschlieend getestet. Zustzlich wurde der Client-Code auf Windows XP und Mac OS X erfolgreich getestet.

    Auf Client-Seite wurde die aktuelle Version des Sun JDK 6 installiert. [9] Alle anderen Abhngigkeiten sind bereits als JAR-Bibliotheken dem Quellcode beigelegt. Zur Entwicklung wurde die Eclipse IDE verwendet; es sind aber in dieser Hinsicht keine speziellen Anforderungen gegeben (der beiliegende Quellcode ist kann aber direkt als Eclipse-Projekt importiert werden).

    Fr die Tests musste ein OPC-Server zur Verfgung stehen, an den Abfragen gerichtet werden konnten. Zu diesem Zweck wurde der gratis erhltliche MatrikonOPC Simulation Server von Matrikon Inc. verwendet. [8] Das Programm stellt zu diesem Zweck Items in den verschiedenen Datentypen zur Verfgung. Die gelieferten Werte werden dabei nicht von einer Schnittstelle gelesen, sondern zufllig oder ber periodische Funktionen berechnet.

    Verbindungsparameter.

    Die Verbindung wurde ber IPv4/Ethernet getestet; der Matrikon-Simulator lief dabei auf der IP 10.123.123.1/24. Als Account wurde auf dem Windows XP Host ein Benutzer mit Name test und Passwort test angelegt. Die Einstellungen sind auch dem unten angefgten Diagramm zu entnehmen. Sollten sich die Parameter ndern, sind die Konstanten im Quellcode entsprechend anzupassen. (Der Einfachheit und Portabilitt halber wurde auf Konfigurationsdateien und Komandozeilenparameter verzichtet).

    Konfiguration von Windows XP.

    Wie bereits oben erwhnt, funktioniert der DCOM-Zugriff mit j-Interop auf ein mit Standardeinstellungen installiertes, unkonfiguriertes Windows XP nicht. Der Grund dafr ist die von j-Interop/jCIFS verwendete NTLM-Authentifizierung: Unter

  • OPC Server/Client unter Linux Seite 13 von 15 EEMD

    Windows XP ist die Option Einfache Ordnerfreigabe (engl: Simple file sharing) aktiviert, die nur einen ffentlichen Zugriff ber die Guest- und Everyone-Accounts zulsst, und die NTLM-Authentifizierung komplett deaktiviert. Unter Windows XP Home Edition ist die Option immer aktiviert. Diese Windows-Version ist daher als OPC-Server Host gnzlich ungeeignet! Unter den hherwertigen XP Versionen kann die Option wie folgt deaktiviert werden: Man whlt in der Menleiste des Windows Explorer Extras, dann Ordneroptionen. Im sich ffnenden Dialog entfernt man den Haken bei Einfache Dateifreigabe verwenden (empfohlen) und besttigt mit einem Klick auf OK.

    Im Folgenden ein schematische Darstellung des Testaufbaus:

  • OPC Server/Client unter Linux Seite 14 von 15 EEMD

  • OPC Server/Client unter Linux Seite 15 von 15 EEMD

    Links

    Referenzen (alle Links waren am 30.1 abrufbar)

    [1] http://openscada.org/

    [2] http://openscada.org/index.php?option=com_content&task=view&id=26&Itemid=46

    [3] http://jcifs.samba.org/

    [4] http://www.matrikonopc.com/products/opc-drivers/opc-simulation-server.aspx

    [5] http://www.opcfoundation.org/UA/

    [6] http://www.j-interop.org/

    [7] http://openscada.org/download/utgard/0.4.1/api/openscada-opc-lib/

    [8] http://www.matrikonopc.com/products/opc-desktop-tools/index.aspx

    [9] http://java.sun.com/javase/downloads/widget/jdk6.jsp

    [10] http://www.opcconnect.com/source.php

    [11] http://www.autinity.de/EN/leistungen/linux_opc.asp

    Weiterfhrende Literatur

    Weitere Frameworks

    http://openopc.sourceforge.net/ Ein freies OPC-Toolkit fr Python OPC. Grundstzlich ist damit der OPC-Zugriff von Linux mglich, allerdings nicht ber eine plattformbergreifende Bibliothek wie j-Interop, sondern ber einen auf den (Windows-)OPC-Server laufenden Proxy.

    http://www.opcconnect.com/dotnet.php Informationen ber den OPC-Zugriff mit .NET

    OPC Tools and Techniques

    http://www.opcconnect.com/tooltech.php

    http://www.opcconnect.com/freestuf.php Free OPC Software

    http://www.opcconnect.com/java.php OPC Client Programming with Java

    http://itcofe.web.cern.ch/itcofe/Services/OPC/GeneralInformation/Specifications/RelatedDocuments/DASummary/DataAccessOvw.html Erklrung von OPC Data Access