# Sps + opc ua



## pvbrowser (13 November 2011)

Gibt es inzwischen eigentlich
SPS'en mit eigebautem OPC UA Server?

Wenn ja, unterstützen die das http oder das binäre OPC UA Protokoll oder beides?


----------



## MasterOhh (13 November 2011)

Auf Beckhoff SPSen kann der TwinCAT OPC UA Server installiert werden.

http://www.beckhoff.com/default.asp?press/pr1608.htm


----------



## pvbrowser (15 November 2011)

dann bin ich mal gespannt,
ob man dieses Jahr in Nürnberg auch was von anderen Herstellern zu sehen bekommt.


----------



## Dr. OPC (15 November 2011)

> Wenn ja, unterstützen die das http oder das binäre OPC UA Protokoll oder beides?



Das hängt von der entsprechenden SPS ab, zwingend vorgeschrieben ist laut UA-Spec das binäre OPC UA Protokoll. Das ist für die meisten SPSen (aus Performance-Gründen) auch das Sinnvollste. Zusätzlich ist es "erlaubt" auch das http (XML/SOAP) Protokoll zu unterstützen allerdings gibt es das derzeit bei der OPC Foundation NUR in dem sogenannten ".NET-UA-Stack" (nicht im C-Stack und auch nicht im Java-Stack) und das würde bedeuten dass auf der SPS .NET laufen muss.

Interessant ist für SPSen (und auch für andere Applikationen) das sogenannte "Hybrid-Protokoll". Dabei wird http*s* als Transport verwendet und der Daten-Inhalt ist UA-Binary (also kein XML/SOAP). Dieses "Hybrid-Protokoll" vereint somit zwei Welten und ist nur minimal langsamer als "reines" UA-Binary. Man braucht kein .NET und keine (auf embedded Systemen meist sehr langsamen) XML-Parser, diese Hybrid-Variante läuft über Port 80 und ist für die Kommunikation in Standard-IT-Infrastrukturen (Enterprise-Systeme, MES, ERP) gedacht. Auch diese Hybrid-Variante ist noch nicht in allen UA-Stacks realisiert, es wird somit noch etwas dauern bis es auch in Produkte rein kommt. Die meisten Produkte sind mit (nur) UA-Binary erstmal glücklich.



> dann bin ich mal gespannt, ob man dieses Jahr in Nürnberg auch was von anderen Herstellern zu sehen bekommt.



Da bin ich auch mal gespannt ! Letztes Jahr gab es neben Beckhoff auch schon BoschRexroth und KW-Software sowie Logicals zu sehen. Ich hoffe ABB, Phönix, B&R und Mitsubishi zeigen dieses Jahr ihre UA-fähigen SPSen. Auch bei Siemens würde ich mal nachfragen.



> Gibt es inzwischen eigentlich SPS'en mit eigebautem OPC UA Server?



Noch spannender finde ich die Frage ob/wann es SPSen mit eingebautem OPC Client gibt (zusätzlich zum UA-Server natürlich)? Die Kooperation der OPC Foundation mit PLCopen hat da schon was in der Pipeline. Wenn es UA-Clients/Server in den SPSen gibt, könnte man "herstellerübergreifend" eine SPS-zu-SPS Querkommunikation machen, direkt aus der SPS mit einem Funktionsbaustein-Aufruf. Oder die SPS holt sich "selbsständig" über OPC UA die nächsten Auftragsdaten aus der Datenbank.


----------



## pvbrowser (16 November 2011)

Dr. OPC schrieb:


> Zusätzlich ist es "erlaubt" auch das http (XML/SOAP) Protokoll zu unterstützen ...



Ist das eigentlich identisch mit dem schon länger verfügbaren OPC XML-DA ?
Oder ist OPC XML-DA anders als das XML/SOAP Protokoll von UA?


----------



## Dr. OPC (16 November 2011)

Das ist was völlig anderes.

Das OPC XML DA ist eine (http/SOAP) Version von OPC DA3. Hat also (nur) die Funktionalität von DataAccess3 und definiert ein XML Schema für die Daten. OPC XML DA hat sich nur schwer am Markt durchgesetzt, es konnte zwar über Port 80 die Firewalls überwinden und war somit einfacher in IT Netze integrierbar als DCOM, aber es war auch richtig langsam. Das Problem ist das SPSen und andere "embedded Geräte" sich sehr schwer tun die (aufwendigen) String-Operationen durchzuführen, denn XML ist ja nichts anderes als Text.

OPC UA kann funktional alles was die "alten" OPC Schnittstellen (DA,AE,HDA) zusammen konnten und noch mehr. UA hat abstrakte Dienste definiert und die sind (erstmal) unabhängig vom Transport. Es gibt derzeit verschiedene sogenannte "Protokoll-Bindings". Das Wichtigste ist UA-Binary, ein eigens entwickeltes, hoch optimiertes, binäres Protokoll auf TCP-Basis. Weiterhin gibt es andere Protokoll-Bindings unter anderem eine http/SOAP Variante und die Hybrid Variante (Ua-Binary über https). 

Das Problem bei diesen drei Varianten ist nun dass sich Client und Server ja erstmal einig sein müssen welches Protokoll sie nun miteinander sprechen wollen. Weiterhin problematisch ist dass man von einen (schwachen) embedded Gerät oder einem kleinen intelligenten Sensor schlecht verlangen kann eine aufwendiges XML/SOAP Protokoll zu unterstützen und die ganze Rechenpower dafür zu verbraten. Daher ist UA-Binary "vorgeschrieben" und es wird erwartet das ALLE Produkte das (mindestens) unterstützen. Daher ist UA-Binary auch in allen UA-Stacks (C, .NET und Java) implementiert und funktioniert vollkompatibel miteinander. Die http/SOAP Variante macht aus meiner Sicht keinen Sinn und wird vermutlich langfristig aussterben. Die Hybrid-Variante kann in bestimmten Anwendungsszenarien Sinn machen (z.B. von einem MES System zu einem ERP System) aber wenn eine Applikation auf Prozessdaten von kleinen Geräten zugreifen will dann sollte sie UA-Binary nehmen, denn die große Masse der Geräte wird (nur) UA-Binary unterstützen (da sie technisch keine andere Chance haben). In Zukunft mag es mehr Geräte geben (die werden ja immer leistungsstärker) die dann zusätzlich auch das Hybrid-Protokoll unterstützen, man braucht ja nur die ohnehin vorhandenen UA-Binary Daten nehmen und in ein https Telegram reinstecken. Viele SPSen habe ja auch heute schon Webserver integriert und somit sind die http/https Stacks schon vorhanden.


----------



## Opezeh (1 Dezember 2011)

Und hat jemand was Neues auf der Messe gefunden? 
Ich konnte am OPC Foundation Stand ein sehr informatives Gespräch mit Herrn Steinkrauß führen.
Er meinte, dass man bei Siemens Druck machen solle bzgl. OPC Server direkt auf der SPS. Je mehr Anfragen es gibt, desto eher wird sich Siemens darum kümmern.

Man könne sogar noch einen Schritt weiter gehen, sodass man nur noch "Bausteine" (von z.B. einer Klimaanlage) vom Hersteller bekommt und diese dann ohne großen Aufwand in die SPS integriert kann. Diese kann man dann auch sofort in seine Visualisierung ziehen.
Aber ganz hab ich das jetzt im Nachhinein auch nicht verstanden.


----------



## Michael.Uray (2 Dezember 2011)

Opezeh schrieb:


> Man könne sogar noch einen Schritt weiter gehen, sodass man nur noch "Bausteine" (von z.B. einer Klimaanlage) vom Hersteller bekommt und diese dann ohne großen Aufwand in die SPS integriert kann. Diese kann man dann auch sofort in seine Visualisierung ziehen.
> Aber ganz hab ich das jetzt im Nachhinein auch nicht verstanden.


Vielleicht hat er hier FDT/DTM gemeint?
http://www.br-automation.com/cps/rde/xchg/br-automation_com/hs.xsl/news_14261_DEU_HTML.htm
http://de.wikipedia.org/wiki/FDT/DTM

Auf den SG4 CPUs von B&R ist es übrigens auch möglich, einen OPC UA Server darauf laufen zu lassen.


----------



## daflodedeing (6 Dezember 2011)

Hallo zusammen,

ich hätte eine (hoffentlich) einfache Frage zu OPC UA: Es ist also quasi möglich mit einem herkömmlichen PC (als OPC UA Client) mit einer beispielsweise Beckhoff-SPS (als OPC UA Server) in Echtzeit (?) zu kommunizieren und I/O Variablen und sonstige Variablen zu setzen und zu lesen? Brauche ich dafür zusätztliche Hardware? 

Besten Dank.


----------



## MasterOhh (6 Dezember 2011)

Ich würde mal sagen, genau das ist der Sinn und Zweck von OPC oder?

Sind PC und SPS im selben Netzwerk oder über Internet / VPN mit einander verbunden sein, sollte das funktionieren.

Was die Echtzeit betrifft, ist das ganz klar eine Frage wie du Echtzeit definierts. Also ein klares JAIN!


----------



## daflodedeing (6 Dezember 2011)

Ja, klar. Ich wollte nur sicher gehen ob ich das auch richtig verstanden habe, da ich noch relativ neu in dem Thema bin. Weitere Frage:

Falls die SPS der Server sein soll , muss darauf Windows Embedded laufen oder?


----------



## MasterOhh (6 Dezember 2011)

Den OPC UA Server von Beckhoff gibt es für Windows Embedded Standard und für Windows CE.
Aber diese Infos gibt es eigentlich direkt bei Beckhoff zu lesen : http://www.beckhoff.de/default.asp?twincat/twincat_opc_ua_server.htm?id=5110182366


----------



## daflodedeing (6 Dezember 2011)

danke für den link. Aber um das richtig zu verstehen, damit auf der SPS OPC UA Server läuft, muss darauf win embedded laufen??


----------



## daflodedeing (6 Dezember 2011)

Hi nochmal,

ich versuch mein Anliegen mal etwas detallierter darzulegen:

Ich  will auf einer SPS über einen herkömmlichen Win PC Variablen eines  Funktionsbausteins oder einer Funktion setzen und sehen was dabei  rauskommt, sprich ich will den FB oder die Funktion testen (Unit Test).
Die  Kommunikation hätte ich gerne über OPC UA realisiert; das ganze sollte  aber von der Steuerung unabhängig sein, da ja nicht auf jeder Steuerung  ein OPC UA Server laufen kann. Deshalb muss die Steuerung der OPC UA  Client sein und der PC der Server. Sehe ich das richtig? Ich hoffe ihr  könnt nachvollziehen was ich meine.


----------



## Dr. OPC (6 Dezember 2011)

> Aber um das richtig zu verstehen, damit auf der SPS OPC UA Server  läuft, muss darauf win embedded laufen??


OPC UA (und das ist gerade der Vorteil von UA im Gegensatz zu dem  "alten" COM/DCOM OPC) kann auf JEDEM Betriebssystem laufen. Beim  Beckhoff ist das "zufällig" WinCE oder Windows embedded, aber bei  anderen Herstellern ist es Linux, Linux embedded oder QNX oder vxWorks,  oder sonst was. Es wird also prinzipiell kein Windows-Betriebssystem  benötigt und auch kein VPN oder irgendwelche Tunnel, OPC UA setzt auf  TCP auf und bringt alles selber mit u.a. auch Security.



> Was die Echtzeit betrifft, ist das ganz klar eine Frage wie du  Echtzeit definierts. Also ein klares JAIN!


OPC UA ist im Sinne von "Deterministik" sicher nicht hart echtzeitfähig,  es verwendet ganz normales TCP/IP und benötigt keine spezielle Hardware  (im Gegensatz zu beispielsweise Profinet). Also harte Echtzeit geht nicht,  allerdings gibt des Prioritäten für bestimmte Nachrichten, die ein UA  Server dann "bevorzugt" bearbeiten kann.



> Man könne sogar noch einen Schritt weiter gehen, sodass man nur  noch  "Bausteine" (von z.B. einer Klimaanlage) vom Hersteller bekommt  und  diese dann ohne großen Aufwand in die SPS integriert kann. Diese  kann  man dann auch sofort in seine Visualisierung ziehen.
> Aber ganz hab ich das jetzt im Nachhinein auch nicht verstanden.


Ich denke damit war PLCopen (IEC 61131) gemeint. Der SPS Programmierer  schreibt z.B. einen Funktionsbaustein (mit Ein und Ausgangsdaten und  einem InstanzDB) dadurch wird (quasi automatisch) ein OPC UA ObjektTyp  erzeugt. Beim Aufruf dieses FBs werden nun Instanzen von diesem Typ  erzeugt. Im OPC UA Server sieht das UA-Objekt dann genauso aus wie es in  der SPS deklariert wurde. Wenn nun ind der SPS (IEC61131)  Bausteinbibliotheken verwendet werden, so sehen die dazugehörigen OPC UA  Items auch immer gleich aus. Ein HMI/SCADA System könnte nun passende  Grafische-Objekte enthalten (Faceplates) die genau zu den  Bausteinbibliotheken passen. Das Erstellen von Bildern im HMI wird  dadurch stark vereinfacht. 
Beispiel: Ein standardisierter Motor-Baustein in der SPS (also ein FB  mit An/Aus, Drehzahl, recht/links Lauf, Hand/Automatik, Solldrehzahl,  etc.) wird automatisch zu einem OPC UA Knoten (MotorTyp). Dazu passend  gibt es ein Motor-Faceplate im HMI System. Nun wird nur noch EINMAL das  Faceplate mit dem UA-Knoten verknüpft und dann sind alle 20 Motoren  (Instanzen), die von der SPS gesteuert werden automatisch im HMI  eingebunden und können angezeigt werden.


----------



## daflodedeing (6 Dezember 2011)

Hi,

danke für die Antwort; also läuft der TwinCat OPC UA Server auf den gängigen Beckhoff Steuerungen?


----------



## Dr. OPC (7 Dezember 2011)

Ja, der UA Server läuft überal dort wo auch TwinCat läuft.


----------



## daflodedeing (8 Dezember 2011)

Hi,

und es ist durch OPC auch möglich Variablen eines FBs oder einer Funktion von außen zu setzen?

gruß


----------



## daflodedeing (11 Januar 2012)

Hallo,

für Beckhoff - SPSen kann man ja direkt einen OPC-UA-Server kaufen. Ist es auch möglich diesen selbst zu realisieren bzw. wie hoch ist der Aufwand dafür einzuschätzen? Ich habe gelesen das OPC UA auch beliebig skalierbar ist und man so auch einen "schlanken" Server aufsetzen könnte, nur mit den Diensten die man auch braucht.


Gruß


----------



## pvbrowser (11 Januar 2012)

Man wird wohl ein OPC UA Toolkit benötigen.
http://www.opcconnect.com/uakit.php

So ohne weiteres kommt man wohl nicht an die Spezifikationen heran.
Selber Programmieren ist also eher nicht möglich.


----------



## daflodedeing (11 Januar 2012)

ok. Mit Spezifikation meinst du aber jetzt nicht die Spezifikation von OPC UA, sondern die Spezifikation von Beckhoff oder?

gruß


----------



## pvbrowser (11 Januar 2012)

Es geht schon um die OPC UA Specs.
Die sind nämlich nur für Mitglieder der Foundation zugänglich.

Siehe:
http://www.opcconnect.com/uakit.php
"The UA           specification documents are only available to OPC Foundation           members"


----------



## daflodedeing (11 Januar 2012)

ok.Klar soweit. Aber gesetzt den Fall ich käme an die Spezifikationen ran, wie aufwendig wäre es dann einen OPC UA Server aufzusetzen, der z.B. Data Access anbietet. Der Server ist ja skalierbar.


----------



## pvbrowser (11 Januar 2012)

daflodedeing schrieb:


> Aber gesetzt den Fall ich käme an die Spezifikationen ran, wie aufwendig wäre es dann einen OPC UA Server aufzusetzen, der z.B. Data Access anbietet. Der Server ist ja skalierbar.



Keine Ahnung.
Ich habe einen OPC XML-DA selber programmiert,
auf Basis von libxml2, csoap und nanohttp.
Das war recht einfach.

Wie stark sich das http basierte OPC UA von OPC XML-DA unterscheidet, weiss ich eben nicht.
Aber das sollte machbar sein, da man den Telegrammverkehr ja einfach beobachten kann.

Das binäre OPC UA Protokoll wird dagegen eine härtere Nuss sein (nicht unbedingt wenn Du die Spec. hast).
Den Paketrahmen des binären OPC UA kann man noch mit Wireshark dekodieren.
Aber wie die Nutzlast genau kodiert ist, ist eine ganz andere Frage.

Na ja, Die wollen erst mal Lizenzen verkaufen


----------



## Dr. OPC (11 Januar 2012)

> Aber gesetzt den Fall ich käme an die Spezifikationen ran, wie aufwendig  wäre es dann einen OPC UA Server aufzusetzen, der z.B. Data Access  anbietet. Der Server ist ja skalierbar.



Das ist grundsätzlich möglich, ABER zu einem UA Server gehört die Server Applikation, die zwar skalierbar ist aber selbst ein recht "kleiner" UA Server der (nur) Data Access kann muss auch erst mal implementiert werden. Zusätzlich brauchst du den sogenannten UA-Stack, das ist die Komponente die das Protokoll implementiert, encoder/decoder der Nachrichten, Security, Plattform Adaption. Wenn du den nicht nur selber schreiben willst sondern auch so dass er kompatibel mit dem UA-Stack der OPC Foundation (den alle anderen verwenden) ist, dann ist das auch eine mächtige Aufgabe.

Ich will dich keinesfalls entmutigen, nur der deutlich einfachere Weg ist:
1) Mitglied in der OPC Foundation werden und den UA Stack von dort bekommen
2) oder bei einem kommerziellen Anbieter (Unified Automation, Softing, etc.) ein Toolkit kaufen

Bei 2) hast du den Vorteil dass a) der UA Stack (und eine einjährige Mitgliedschaft) dabei ist und b) vor allem auch schon ca. 90% der Server-Applikation schon fertig dabei ist und c) auch Support dabei ist. Nachteil: das ist nicht kostenlos.


----------



## opcua (11 Januar 2012)

Also wenn man alles selber programmiert, kommt noch darauf an, in welcher Programmiersprache, kann man schon mit einem Jahr rechnen. Also nur um DataAccess anzubieten. Möchte man die Software später noch erweitern, so sollte man mindestens zwei Jahre einplanen (nur um DataAccess anzubieten). OPC UA ist schon ganz schön mächtig geworden, leistet aber auch unglaublich viel 

Aber was Dr. OPC schon sagt, ist richtig. Man kann sich vielleicht auch an Unified Automation wenden, die verkaufen SDKs ohne das man gleich Mitglied in der Foundation sein  muss.


----------



## daflodedeing (4 März 2012)

*Benötigt ein OPC UA Server ein Betriebssystem?*

Hallo zusammen,

ist es möglich einen OPC UA Server auf nahezu jeder SPS einzusetzen?

oder gibt es ca einschränkungen , wenn ja welche

gruß


----------



## Dr. OPC (4 März 2012)

> ist es möglich einen OPC UA Server auf nahezu jeder SPS einzusetzen?



Ich würde sagen JA. Die Frage ist ob der Hersteller der SPS einen OPC Server dafür anbietet oder nicht. Aber "technisch" möglich, ist das auf JEDER SPS und sogar auf noch viel "kleineren" Geräten.

Die OPC Foundation hat den UA-Stack (absichtlich) in ANSI C entwickeln lassen, damit man (nur) einen C Compiler braucht, weiterhin ist der Stack so entwickelt dass er minimal nur einen Task (Thread) benötigt und die größe des Speichers, die er allociert ist über zig verschiedene Schalter einstellbar und vor allem (nach oben) begrenzbar. Gerade für SPSen ist es wichtig das ein Prozess, der eben dem Echtzeit-SPS-Prozess, läuft, nicht unvorhersehbar Speicher oder andere Ressourcen  verbraucht. Der Stack ist völlig unabhängig vom Betriebssystem und besitzt einen Platformlayer (MIT-Lizenz), der entsprechend angepasst werden muss. Dadurch kann der UA Stack auf JEDES Betriebssystem portiert werden und auf jedem noch so kleinen Gerät laufen. Platformlayer gibt es bei der OPC Foundation nur für Windows. Kommerzielle Anbieter liefern heute PLs für Linux, Unix, vxWorks, QNX, INtime, Euros, WinCE, Android, etc. (die sind dann natürlich nicht mehr unter MIT-Lizenz).

Die eher nicht-technische Frage ist wie lange man noch warten muss bis alle SPS-Hersteller solche UA-Server auf ihren SPSen anbieten? Der Markt von Drittanbietern, die es beim alten OPC zu Duzenden gab, fehlt hier. Alleine für die S7 gab es von Deltalogic/Softing, Matrikon, Kepware, etc. Anbieter von OPC Servern. Für OPC UA gilt: Es kann eigentlich nur der SPS Hersteller einen UA Server "vernünftig" in seine SPS integrieren. Somit entsteht wenig "Konkurrenzdruck" von außen. Nun verwenden aber viele SPSen die selbe Laufzeitumgebung (z.B. Codesys), und hier wäre eine gute Stelle um einen UA Server zu integrieren, dann profitieren gleicht mehrere SPSen davon.


----------



## Dr. OPC (4 März 2012)

> *Benötigt ein OPC UA Server ein Betriebssystem?*


Diese Frage kann man mit einem NEIN beantworten. OPC UA braucht TCP/IP, eine Möglichkeit Speicher zu allocieren und einen Timer. Allerdings muss man dann den UA Stack vermutlich selber implementieren, mit etwas Pech muss man auch TCP selber machen, ist natürlich alles möglich.

Es gibt da bereits eine Firma die diesen "steinigen" Weg gegangen ist und nun nach ca. 1,5 Jahren einen UA Server auf einem Microcontroller laufen lassen kann, also OHNE Betriebssystem (natürlich ohne die ganzen schicken Features von UA wie Security, Alarme, History und mit Einschränkungen hinsichtlich der unterstützten UA-Profile). http://www.embeddedlabs.com/


----------

