Entwurf, Errichtung und Management von Datennetzen, LU

Transkript

1 Entwurf, Errichtung und Management von Datennetzen, LU Gruppe 6: OPC- Server/Client unter Linux Teammitglieder: Name Matrikelnummer Studienkennzahl Flemon Ghobrial Christoph Gratzer Thomas Pani OPC Server/Client unter Linux Seite 1 von 15 EEMD

2 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 Beschreibung Probleme Testaufbau Links Referenzen (alle Links waren am 30.1 abrufbar) Weiterführende Literatur OPC Server/Client unter Linux Seite 2 von 15 EEMD

3 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. OPC Server/Client unter Linux Seite 3 von 15 EEMD

4 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: 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 OPC Server/Client unter Linux Seite 4 von 15 EEMD

5 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). OPC Server/Client unter Linux Seite 5 von 15 EEMD

6 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): OPC Server/Client unter Linux Seite 6 von 15 EEMD

7 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. OPC Server/Client unter Linux Seite 7 von 15 EEMD

8 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: Schema bei Einsatz von j- Interop: interop.org/img/figure1.gif 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 OPC Server/Client unter Linux Seite 8 von 15 EEMD

9 Ü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 OPC Server/Client unter Linux Seite 9 von 15 EEMD

10 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 Server Toolkit (für Schnellimplementationen, nicht alle Features werden mitgeliefert) Server Toolkit (Alle Features sind vorhanden, mit Source Code) 1250$ 1250$ 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/Client unter Linux Seite 10 von 15 EEMD

11 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 OPC Server/Client unter Linux Seite 11 von 15 EEMD

12 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 /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 OPC Server/Client unter Linux Seite 12 von 15 EEMD

13 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: OPC Server/Client unter Linux Seite 13 von 15 EEMD

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

15 Links Referenzen (alle Links waren am 30.1 abrufbar) [1] [2] [3] [4] drivers/opc- simulation- server.aspx [5] [6] interop.org/ [7] opc- lib/ [8] desktop- tools/index.aspx [9] [10] [11] Weiterführende Literatur Weitere Frameworks 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. Informationen über den OPC- Zugriff mit.net OPC Tools and Techniques Free OPC Software OPC Client Programming with Java ocuments/dasummary/dataaccessovw.html Erklärung von OPC Data Access OPC Server/Client unter Linux Seite 15 von 15 EEMD