# OPC Server und Client SDK



## vbmab (3 Mai 2011)

Hallo zusammen,

ich bin auf der Suche nach einem OPC Server und Client SDK unter .Net und C#.
Ich habe schon sehr viel nachgelesen. Und bin jetzt einbischen unschlüssig was das richtige für mich ist.

In Frage kommen die Spezifikationen OPC Xi (OPC .Net 3.0) und OPC UA.
Die unterschiede kenne ich. Mich Interessiert, welche Erfahrung Ihr mit den Spezifikationen bereits gemacht habt, besonders mit OPC-UA. 
Was könnt Ihr mir als .Net Entwickler empfehlen? Auf was sollte ich eurer Meinung nach setzen, OPC Xi oder OPC UA?

Habt Ihr auch eine Empfehlung zu einer SDK von einem Anbieter?
Hat einer schon Erfahrung mit Advosol?

Über einige hilfreiche Antworten würde ich mich sehr freuen.

Schöne Grüße
vbmab


----------



## Dr. OPC (3 Mai 2011)

Um das besser beurteilen zu können wäre es hilfreich zu wissen was genau du vor hast. 

Willst du einen Server entwickeln, der in ein vorhandenes System integriert wird? Wenn ja, in was für eins, ist das ein HMI oder ein BDE, welche Art von Daten soll dieser Server anbieten? 

Der Client, den du entwickeln willst, soll der auch in ein vorhandenes System integriert werden und von wem (welchen Servern) soll er Daten bekommen, sind das überwiegend Xi oder UA Server? Ist die Zielplattform ein PC (WinXP/7) oder kann es auch auch ein Panel (mit WinCE) sein?


----------



## vbmab (4 Mai 2011)

Hallo Dr. OPC,

vielen Dank erstmal für die Antwort.

Unser Unternehmen entwickelt Sondermaschinen für verschiedenste Bereiche.

Für die Sondermaschinen werden unteranderem kundenspezifische Software (HMI) entwickelt, wo viel mit externen Teilnehmern wie SPS, spezielle Messgeräte, andere SW, usw. kommuniziert wird. Auch Netzwerkübergreifend.

Wir möchten für diese Zwecke eine standartisierte Schnittstelle verwenden, die uns Arbeit abnimmt.
OPC scheint hier schon das Richtige zu sein. Allerdings fällt es mir gerade schwer die richtige Entscheidung zu treffen welche Spezifikation die Richtige ist. Natürlich unter Berücksichtigung der OPC Entwicklung für die Zukunft.

Wir müssen eigene Clients sowie Server programmieren können.
Fertige, wie z.B. der S7 OPC Server  von Siemens, sollten auch verwendet werden können. Wir müssen ja nicht alles neu programmieren.
Die Zielplattfom ist in den meisten fällen MS-Win (XP sowie 7).
WinCE kommt selbstverständlich auch in frage.

Die Daten sind, z.B. bei einer SPS, digitale E/A oder analoge Messwerte.
String-Daten sind auch wichtig. Wenn möglich auch ganze Strukuren.


Ich hoffe ich konnte Dir jetzt ausreichende Informationen geben.

Schöne Grüße vbmab


----------



## Dr. OPC (5 Mai 2011)

Also OPC UA ist aus meiner Sicht die richtige Technologie für dich. Und zwar aus folgenden Gründen:

Wenn Du ein HMI System entwickelst/erweiterst und Daten von Fremdsystemen vor allem Messgeräten konsumierst, wirst du bei diesen "Geräten" zwangsläufig auf OPC UA Server stoßen. Denn nur OPC UA (und nicht OPC Xi) Server können in diesen Geräten, die z.B. auf vxWorks oder embedded Linux oder noch exotischeren OS laufen, implementiert werden. Deine Datenlieferanten werden also OPC UA Server sein. Wenn du in deinem HMI nun aber einen Xi-Client reinbaust, der .NET(WCF) voraussetzt, kannst du nicht mehr "direkt" mit der nicht-Windows-basierten Gerätewelt kommunizieren, denn OPC UA und OPC Xi sind nicht "protokollkompatibel". Wenn du hier also nicht schon wieder irgendwelche Gateways oder Umsetzer verwenden willst, bleibt dir selbst als "rein-auf-Windows-HMI-System" das auf einem leistungsstarken XP/7 PC mit .NET Framework sitzt, nichts anderes übrig als auch OPC UA zu machen.

Nun ist das auch nicht die schlechteste Wahl denn OPC UA ist der Standard der Zukunft und wird von deutlich mehr Herstellern unterstützt als beispielweise Xi (ausser Emerson und Advosol macht das praktisch niemand). Auf der OPC UA Seite stehen mitlerweile die großen wie Siemens, ABB, Bosch, Phönix, Beckhoff, Mitsubishi, ...  also aus meiner Sicht ist damit OPC UA damit zumindest in Europa als neue Schnittstelle zur SPS gesetzt. Auch die HMI Systeme werden UA unterstützen WinCC mit dem nächsten ServicePack (ging vorher schon mit einem Optionspaket), Iconics Genesys64, Yokogawa und andere werden sicher folgen.

OPC UA ist an sich Sprachunabhängig, es gibt derzeit drei Kommunikationsstacks (C, .NET und Java) alle diese drei UA-Stacks sind "auf dem Kabel" kompatibel. Ein in Java entwickelter OPC UA Client kann also problemlos mit einem in ANSI C programmierten OPC UA Server kommunizieren. Wenn also dein HMI schon in .NET entwickelt ist, spricht nichts dagegen diesen um einen UA Client Kanal zu erweitern. Du nimmst die einfach den .NET Stack der OPC Foundation und kannst loslegen.

Von OPC Xi würde ich die Finger lassen da es (nur) ein "Abklatsch" der alten klassischen OPC Schnittstellen auf WCF-Basis ist. Das mag auf den ersten Blick (funktional) ähnlich aussehen, ist aber ganz anders als ein "echtes" OPC UA das (auch / unter anderem) in .NET programmierbar ist. Die Modellierungen der Daten, die derzeit von vielen anderen organisationen betrieben wird setzt auf OPC UA auf, z.B. FDI, PLCopen, SmartGrid, ISA95, ... erst damit kommt der eigentliche "Mehrwert" von OPC UA erst zustande (Xi bietet hier nichts, da kannst du auch gleich das "alte" OPC weiterbenutzen)

Apropos "altes" OPC, hier muss man natürlich davon ausgehen dass es das noch eine ganze Weile geben wird, nicht jeder ist so schnell wie Siemens  und Beckhoff und hat schon einen UA Server auf dem Markt (der UA Server von Siemens wohnt ja auch immer noch auf einem PC und nicht der S7). Für die "Übergangszeit" der nächsten 5-10 Jahre, werden "alte" OPC Server über sogenannte Wrapper integriert. Sie liefern dann nicht alle schicken Features von UA aber lesen/schreiben/beobachten und ein paar Alarme wird es immerhin geben (mehr konnten die "alten" OPC Server ja nicht). Neue Dinge wie Transaktionssicherheit, feingranulare Zugriffsrechte, verschlüsselte Übertragung, komplexe Datentypen, Redundanz, robuste/fehlertolerante Verbindungen, Auditfunktionalität, ... gibt es halt nur bei OPC UA.


----------



## vbmab (5 Mai 2011)

Super, vielen dank für die ausführliche Antwort.

Ich sehe das auch so. Brauchte halt die Meinung eines Experten.
Die Fragezeichen in meinem Kopf sind auf einmal weg. 

Jetzt muss ich noch ein geeignetes Client und Server Toolkit finden. Hast du dazu auch eine Empfehlung?

Um bei der OPC-Foundation die Sdks zu bekommen muss man Mitglied werden, oder geht das auch anders? Jahresbeitrag für normale Mitglieder 1500$. Ich weis nicht, ob ich das durchkriege????

Wie ist es mit Advosol??? Oder Softing??? Ich glaube Softing ist aber ganz schön teuer.

Sollte am besten ein Anbieter aus Deutschland sein, um Schulungen besuchen zu können.

Kannst du mir auch Beispiele, zum Programmieren von Clients und Server, liefern? Vielleicht ein paar nützliche Links.

Schöne Grüße


----------



## Dr. OPC (6 Mai 2011)

Mit Softing hast du ja schon einen Kandidaten gefunden, Advosol hat im Kern das SDK der OPC Foundation soweit ich weiß, wie übrigens alle kommerziellen .NET SDKs natürlich den .NET-UA-Stack der OPC Foundation enthalten aber auch größtenteils den SDK-Code der OPC Foundation nehmen und einfach weiter verkaufen... Bei den .NET SDKs bekommst du also überall das gleiche, ABER bei den kommerziellen C, C++ und JAVA SDKs gibt es entscheidende Unterschiede, da es sich hier (abgesehen von UA-Stack) um komplette Eigenentwicklungen der entsprechenden Hersteller handelt. Also bei C, C++ und Java immer genau hinschauen und Funktionalität, Doku, Beispiele, Support, etc. vergleichen... Die Messlatte hat aus meiner Sicht www.unifiedautomation.com gelegt, da kommt bisher kein anderer dran. Aber das kannst Du dir selber anschauen, die bieten zum Ausprobieren auch alle SDKs kostenlos zum Download an (leider keins für .NET).

Wenn du für die Clientseite etwas suchst (vor allem auch günstig) dann schaue mal auf der Siemens Support Seite, dort gibt es ein Beispiel eines UA Client in C#. Einfach, super dokumentiert und so weit ich weiss kannst du es sogar "ausschlachten" und selber verwenden. Die Basis ist auch hier der .NET Stack der OPC Foundation aber die clientseitige Schnittstelle ist stark vereinfacht und super zu verwenden, speziell für HMI-Anwendungen. Man kann sich auch super damit in das Thema OPC UA einarbeiten (dann sparst Du Dir auch noch einen Workshop ).

http://support.automation.siemens.com
*Beitrags-ID:*42014088


----------



## vbmab (10 Mai 2011)

Nach langer langer recherche ...
Ich bin noch nicht besonders weiter gekommen.

- Mit Softing komme ich nicht klar. Mir fehlen Beispielanwendungen unter .Net C#. Softing bietet welche nur unter cpp, da kenne ich mich aber nicht aus.
- Advosol hat keinen Client Toolkit.
- Andere wie Terxasoft, Indian... bieten auch nicht das volle Packet an.

Ich habe das Gefühl die Anbieter sind mit den OPC UA Toolkit's noch nicht so weit.

Oder kennt jemand doch einen Anbieter der einen OPC UA Server und Client Toolkit unter .NET C# anbietet?

Kann man die Beispielanwendung von Siemens ausschlachten, anpassen und kommerziell Vertreiben?
Wie komme ich an den Siemens S7 OPC UA Server dran? Nur über die CD?


----------



## vbmab (10 Mai 2011)

Gibt es irgendwo Beispielprojekte unter C# .Net, um zu erfahren, wie man das das Softing OPC UA Toolkit einsetzt.


----------

