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


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 plattformunabhängigen OPC-‐Clients ............................................... 10

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

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

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

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

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

Weiterführende Literatur ............................................................................................ 15


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 außerdem eine kleine Zusammenfassung der Frage „Was ist überhaupt OPC?“.

Im nächsten Schritt suchten wir nach Möglichkeiten der OPC Implementierung unter Java. Dabei stießen wir auf verschiedene Bibliotheken: OPC Unified Architecture [5], J-‐Interop [6], OpenScada [1], …

Bei der ersten Übungsbesprechung präsentierten 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, für uns wurde keine Ausnahme gemacht), mussten wir uns eine andere Möglichkeit suchen.

Als neue Testimplementierung haben wir uns für das OpenScada/Utgard Framework [1] entschieden. Außerdem haben wir schnell gemerkt, dass ein OPC Server unter Linux mit dem derzeit üblichen DCOM-‐Zugriff faktisch unmöglich ist (zumindest im Rahmen dieser Übung, siehe Punkt „OPC Server unter Linux“). Deshalb haben wir uns auf die Implementierung eines OPC Testclients konzentriert. Für den Testaufbau haben wir uns außerdem für einen Windows OPC Server Simulator entschieden (Matrikon OPC Simulation Server [4]).

Mit diesem Testclient implementierten wir verschiedene Abfragemöglichkeiten für Daten von einem OPC Server. Diese Arbeiten waren Anfang Jänner abgeschlossen. In diesem Dokument werden nun die einzelnen Schritte/Erkenntnisse dieser Studie näher beschrieben.

Recherche

Was ist überhaupt OPC?

1994 gründete eine Gruppe von Herstellern (die einem breiten Spektrum angehörten) die OPC Founcation. Ziel war die Entwicklung einer Server/Client Spezifikation, die herstellerübergreifend funktioniert. Die erste Spezifikation wurde Data Access Specification 1.0a genannt und 1996 veröffentlicht. Mit dieser Spezifikation war es leicht und schnell möglich, kompatible Server/Clients zu schreiben.

OPC hieß ursprünglich „OLE for Process Control“; jetzt wird es nur mehr als OPC bezeichnet. Der Name bezeichnet eine standardisierte Software-‐Schnittstelle, die es ermöglicht 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.


Bevor es OPC gab, war der dieser Datenaustausch eine sehr schwierige Sache. Jeder Hersteller hatte unterschiedliche Implementierungen und Besonderheiten. Für eine Verbindung waren genaue Kenntnisse der Kommunikationsmöglichkeiten und Schnittstellen der verschiedenen Geräte nötig. Außer dem enormen Fachwissen, waren aber auch Erweiterungen und Anpassungen bei diesen Systemen nur sehr schwer möglich.

Wie funktioniert der Datenaustausch mit OPC?

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

OPC basiert dabei auf einer Server/Client Architektur. Das heißt, dass die Seite, die Daten zur Verfügung stellt, als Server fungiert. Die Daten liest der Server von Systemen mit meist proprietären Schnittstellen, kapselt sie in OPC-‐Objekte und macht sie für Client-‐Zugriffe lesbar. Ein oder mehrere Clients können 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 ermöglichen. Die Abkürzung bedeutet Distributed Component Model. DCOM ist darauf optimiert, die Übertragungs-‐ bzw. Zugriffsgeschwindigkeit nicht durch unnötigen Verwaltungsoverhead zu bremsen. Außerdem ist es damit möglich, die Daten aus dem gleichen Adressraum, von einem fremden Prozess


oder von einem entfernten Rechner zu beziehen. Für die Verbindung zu entfernten Rechnern wird TCP verwendet.

Der OPC Server holt sich die Daten von Sensoren, Reglern oder Steuerungen über einen proprietären Controller (dieser ist über einen Bus an die Geräte angeschlossen). Ein Treiber dient dazu, den proprietären Controller anzuspreichen, und die ausgelesenen Daten über eine wohldefinierte Schnittstelle dem Server zur Verfügung 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. Anschließend kann er nun diese Daten auswerten bwz. weiterverarbeiten.

Außer der normalen „Client fordert Daten vom Server“-‐Lösung, gibt es auch noch weiter Möglichkeiten 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 für 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 für die vorhandenen Gruppen und speichert Informationen über den Server. Das Gruppen-‐Objekt enthält ein oder mehrere Elemente (die logisch organisiert sein können) und allgemeine Informationen über die Gruppe. Die Gruppen dienen zur logischen Organisation der Daten. Die Daten können gelesen und geschrieben werden. Einzelne Gruppen können aktiviert oder deaktiviert werden. Der OPC Client kann außerdem festlegen, in welchem Zeitraum die Abfragen an den Server durchgeführt werden (Ausnahmen basierende Verbindungen sind auch möglich).

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


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

• public: Die Gruppe ist öffentlich und auf mehreren Clients verfügbar. • private: Die Gruppe ist lokal für einen Client und von außen 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 Qualität 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 Vorgängern. Im Februar 2009 ist die aktuellste Version veröffentlicht worden.

OPC nutzt die COM/DCOM-‐Schnittstelle und verdankt ihr auch die weite Verbreitung. Dennoch wurde entschieden, für OPC UA die COM/DCOM-‐Schnittstelle aufzugeben, da sie erhebliche Nachteile für Entwickler mit sich brachte, nämlich:

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

o Entwickler können den Quellcode nicht einsehen und können 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 möglich • Verwendung in Embedded-‐Controllern bis hin zu Mainframes möglich • OPC-‐UA unterstützt nun Multithreading sowie Singlethreading • Verwendet nun Sicherheitsprotokolle die den neuesten Standards entsprechen • Beidseitiger Heartbeat wurde eingeführt; dh. Server und Client erkennen, wenn die

andere Instanz ausfällt und können darauf reagieren • Verbindungsunterbrechungen führen dank ausfallssicherer Datenübertragung nicht

mehr zu Datenverlust • OPC-‐UA unterstützt Redundanz

Man entschied sich bei der Entwicklung von OPC UA bezüglich des logischen Aufbaus für eine Service Oriented Architecture (SOA):


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 plattformunabhängige Implementierungen zu ermöglichen. Allerdings wird es noch dauern, bis kostenfreihe und/oder offene Bibliotheken zur Verfügung stehen.

j-Interop

Da die Auseinandersetzung mit OPC UA aufgrund mangelnder Verfügbarkeit entsprechender Bibliotheken nicht weitergeführt werden konnte, betrachteten wir anschließend die ältere, DCOM-‐basierte OPC-‐Spezifikation. Für den Einsatz unter Linux musste eine plattformunabhängige DCOM-‐Implementierung gefunden werden; j-‐Interop bietet eine solche Implementierung:

Java unterstützt standardmäßig den Zugriff auf native Methoden/Programme. Dazu wird das Java Native Interface (JNI) eingesetzt. JNI besitzt aber nicht nur Vorteile, sondern auch große Nachteile. Die Schnittstelle (JNI) ist zwar in Java verfasst, trotzdem muss der Entwickler über großes Wissen, was die native Komponente betrifft, verfügen. Solche Experten sind schwer zu finden und daher auch sehr teuer. Außerdem sind dadurch Anpassungen nur sehr schwer möglich.

Ein weiterer Nachteil ist, dass durch den Einsatz von JNI die Plattformunabhängigkeit von Java aufgehoben wird. Die übersetzte Anwendung wird direkt an das Hostsystem gebunden. Wenn man zum Beispiel JNI in einer Windows Umgebung einsetzt und für den Zugriff eine native DLL (Bibliothek) verwendet, so ist das Programm dann nur unter Windows lauffähig. Für eine Portierung auf andere Plattformen (im konkreten Fall Linux), müsste man zusätzlich zum Programm, auch die Bibliothek (DLL) portieren.


j-‐Interop [6] adressiert diese Nachteile im Bereich von DCOM und schafft eine plattformunabhängige Lösung, die den Zugriff kapselt und die Entwicklung deutlich erleichert. Es basiert auf MSRPC und ist ein freies, ausschließlich 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 für SCADA-‐Systeme. SCADA („supervisory control and data acquisition“) beschreibt ein Computersystem zur


Überwachung und Steuerung industrieller Prozesse und ist im deutschen Sprachraum auch als„Überwachung, Steuerung, Datenerfassung“ (ÜSE) bekannt.

Im Rahmen von SCADA ist OPC ein häufig eingesetztes Kommunikationsprotokoll. Als solches wird im Rahmen von OpenSCADA auch die plattformunabhängige 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 höherer 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 beschäftigen.

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 Gründen für lange Zeit auf Linux Servern nicht umgesetzt:

• Da OPC zur Datenübertragung 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 proprietären Datenzugriff durchzuführen, liegen ebenfalls nur als native DLLs vor. Das führt zu


einer ähnlichen Problematik wie bei den OPC-‐Clients; jeder Treiber müsste in der für den Server gewählten, plattformunabhängigen Sprache neu implementiert werden. Da diese Treiber üblicherweise vom Hersteller des proprietären Systems geliefert werden, ist eine einheitliche Portierung unmöglich.

Es gibt einige kommerzielle Server-‐Systeme, die den Zugriff auf bestimmte Datenquellen unter Linux erlauben, da für diese speziell neue Treiber entwickelt wurden. Ein Beispiel dafür ist „autinityPLC“, das den Zugriff auf Siemens Simatic S5 bzw. S7 erlaubt. [11] Eine allgemeine Lösung stellt das aber nicht dar, für jede benötigte Datenquelle müsste zusätzlich 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 Lösungen an, und bieten Toolkits (meist für C / C++) an, die sich unter Linux und Windows kompilieren lassen.

Eine ungefähre Darstellung preislicher Obergrenzen für solche Toolkits bietet eine Aufstellung auf opcconnect.com: [10]

Client Toolkit 1250$ Server Toolkit (für Schnellimplementationen, nicht alle Features werden mitgeliefert)

1250$

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

4500$

Ein Beispiel für solche Bibliotheken ist die OPC-‐Toolbox von Softing. Man erhält den Source in Form von Bibliotheken gegen Bezahlung und muss sich den OPC-‐Server selber schreiben. Dies kann man jedoch gleichermaßen unter Windows und Linux bewerkstelligen, da die Bibliotheken in der Toolbox für verschiedene Programmiersprachen (C++, C#, etc.) und ohne plattformspezifische Abhängigkeiten ausgeliefert werden.

Implementierung des plattformunabhängigen OPC-Clients Zur Implementierung wurde das während der Recherche-‐Phase evaluierte und favorisierte Utgard (welches wiederum auf j-‐Interop basiert) eingesetzt. Das API von Utgard ist grundsätzlich übersichtlich gestaltet. Im Folgenden werden jene Teile der Bibliothek näher beschrieben, deren Verwendung und Zusammenhang nicht unmittelbar verständlich ist; anschließend 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 können, muss der Ziel-‐


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 zugehörige CLSID abgefragt.

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

Soll ein Item ausgelesen werden, stehen zwei grundsätzliche Modelle zur verfügung:

-‐ 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 erwähnten Browser-‐Objekten nach dem Item gesucht werden. Beim expliziten Lesezugriff ist zusätzlich eine Group zu erstellen, in der das/die zu lesenden Items aufgenommen werden. Anschließend wird der aktuelle Zustand des Item mit synchronen Aufrufen ausgelesen. Eventuell (je nach Anwendung) muss abschließend ist die angelegte Group wieder gelöscht werden. Beim Lesezugriff mit Callbacks muss manuell keine Group angelegt werden; Utgard erzeugt eine zufällig benannte und löscht sie nach Ende des Lesevorgangs wieder. Für den eigentlichen Zugriff wird eine konkrete Instanz von AccessBase erzeugt; dabei wird festgelegt in welchen Intervallen der Zugriff erfolgen soll. Außerdem wird ein Callback-‐Objekt übergeben; eine Beispiel-‐Implementierung findet sich im beiliegenden Quellcode. Anschließend kann über das AccessBase-‐Objekt ein neuer Lese-‐Thread gestartet und gestoppt werden; solange dieser Thread läuft, wird in den angegebenen Intervallen das Item ausgelesen und die so gewonnene Information dem Callback-‐Objekt übergeben.

Probleme

Während der Implementierungsarbeit konnten folgende Unzulänglichkeiten am Utgard-‐Projekt festgestellt werden:

Spärliche Dokumentation. Zwar steht für die Bibliothek eine Javadoc-‐basierte Dokumentation zur Verfügung [7], diese ist aber in wesentlichen Stellen unvollständig. Daher konnten selbst für die kompakte Funktion des implementierten Test-‐Clients manche Teile nur durch Ausprobieren verwirklicht werden.

Starke Modularisierung. Durch den modularen Aufbau von Utgard und die Abhängigkeit von j-‐Interop und jCIFS sind Fehlerquellen nur schwer aufzufinden. Während der Implementierung trat früh das Problem auf, dass keine Verbindung zum Test-‐Server


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, könnte das Debugging einen zusätzlichen (möglicherweise unerwartet hohen) zeitlichen und/oder budgetären Aufwand bedeuten, der jedenfalls in die Risikobestimmung einfließen muss.

Testaufbau

Softwareausstattung.

Die primäre Entwicklung des OPC-‐Clients wurde unter Ubuntu 9.10 durchgeführt und anschließend getestet. Zusätzlich 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 Abhängigkeiten 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).

Für die Tests musste ein OPC-‐Server zur Verfügung stehen, an den Abfragen gerichtet werden konnten. Zu diesem Zweck wurde der gratis erhältliche „MatrikonOPC Simulation Server“ von Matrikon Inc. verwendet. [8] Das Programm stellt zu diesem Zweck Items in den verschiedenen Datentypen zur Verfügung. Die gelieferten Werte werden dabei nicht von einer Schnittstelle gelesen, sondern zufällig 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 angefügten Diagramm zu entnehmen. Sollten sich die Parameter ändern, sind die Konstanten im Quellcode entsprechend anzupassen. (Der Einfachheit und Portabilität halber wurde auf Konfigurationsdateien und Komandozeilenparameter verzichtet).

Konfiguration von Windows XP.

Wie bereits oben erwähnt, funktioniert der DCOM-‐Zugriff mit j-‐Interop auf ein mit Standardeinstellungen installiertes, unkonfiguriertes Windows XP nicht. Der Grund dafür ist die von j-‐Interop/jCIFS verwendete NTLM-‐Authentifizierung: Unter


Windows XP ist die Option „Einfache Ordnerfreigabe“ (engl: „Simple file sharing“) aktiviert, die nur einen öffentlichen Zugriff über die Guest-‐ und Everyone-‐Accounts zulässt, 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 gänzlich ungeeignet! Unter den höherwertigen XP Versionen kann die Option wie folgt deaktiviert werden: Man wählt in der Menüleiste des Windows Explorer „Extras“, dann „Ordneroptionen“. Im sich öffnenden Dialog entfernt man den Haken bei „Einfache Dateifreigabe verwenden (empfohlen)“ und bestätigt mit einem Klick auf „OK“.

Im Folgenden ein schematische Darstellung des Testaufbaus:


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

Weiterführende Literatur

Weitere Frameworks

http://openopc.sourceforge.net/ Ein freies OPC-‐Toolkit für Python OPC. Grundsätzlich ist damit der OPC-‐Zugriff von Linux möglich, allerdings nicht über eine plattformübergreifende 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 Erklärung von OPC Data Access

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

Documents

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