Sps + opc ua

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 https 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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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. :ROFLMAO:
 
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. :ROFLMAO:
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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!
 
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?
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zuletzt bearbeitet:
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ß
 
Zurück
Oben