TIA OPCUA oder Profinet?

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen!
Es geht um ein Projekt bei dem ein Datenaustausch zwischen einer Siemens S7 1513 und einer B&R X20 CP1585 realisiert werden soll. Es geht um den Datenaustausch in beide Richtungen. Die Größe der Daten ist erstmal nicht relevant. Es sind 2-3 Bytes Statusmeldungen, sowie einige Integer und Real/Float-Werte. Also nichts was den Rahmen sprengen würde.
Der Maschinenhersteller mit der B&R-Steuerung besteht auf OPCUA, ist dabei auch ziemlich unflexibel, der Anlagenbetreiber mit der Siemens S7 möchte unbedingt Profinet.
Ich bin auch der Meinung, dass die Profinet-Lösung sinnvoller, fehlerunanfälliger, stabiler und zuverlässiger ist. Bei OPCUA habe ich die Befürchtung, dass sich unter Umständen mal der Server aufhängt, dass die Kommunikation einfriert, dass es bei evtl. Programmänderungen, Firmware-Updates etc. Probleme gibt. Noch dazu soll die OPCUA-Verbindung über 2 Firewalls laufen, was zusätzlich Problempotential mit sich bringt, da sich die beiden CPUs in unterschiedlichen IP-Netzen befinden.
Des Weiteren arbeiten die beiden Anlagenteile prozesstechnisch in Echtzeit zusammen. Dadurch bin ich der Meinung, dass es auch unter diesem Gesichtspunkt logischer ist, wenn die CPUs direkt, auf dem kürzesten Weg direkt, zyklisch miteinander kommunizieren.

Wie seht ihr das? Hat jemand weitere Argumente für Profinet oder sieht es vielleicht jemand ganz anders und würde OPCUA bevorzugen? Wenn ja warum? Was wären die Vorteile? Bis nächste Woche muss eine Lösung gefunden werden.

 

[Blockmove]

Was verstehst du unter Echtzeit?
OPC UA ist vergleichsweise langsam.

Profinet macht Probleme mit unterschiedlichen IP-Netzen. Da wäre u.U. ein PN/PN-Koppler sinnvoll bevor man sich netzwerktechnisch verkünstelt.

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Echtzeit wäre ja wohl Profinet IRT… geht das über PN/PN-Koppler?

Unabhängig davon denke ich auch, dass ein PN-Koppler die beste und stabilste Lösung wäre.

 

[KarlMeier]

Wäre das Ganze denn nicht eine Art PN-PN-Koppler? Auf B&R-Seite ist es ein Profinet-Device-Kommunikationsmodul, OHNE IP-Adresse. Die IP-Adresse vergibt ja die Siemens CPU an das B&R-PN-Device-Modul. Den Profinet-Namen konfiguriert man in der B&R-CPU bzw. im AutomationStudio. Die B&R-CPU leitet dann intern die Daten an das PN-Modul, dort werden die Daten an den PN-Master (Siemens S7) übergeben.

https://www.br-automation.com/de-de/produkte/netzwerke-und-feldbus-module/profinet/x20-kommunikationsmodule/x20if10e3-1/

Ja OPCUA ist eher träge. Hatte das auch schonmal im Einsatz. B&R-CPU und S7 sprechen via OPCUA miteinander. Latenz ca. 1-2 Sekunden, eher instabil und öfter mal Ausfälle. Insbesondere bei Programmänderungen.

 

[Richard P.]

... eher instabil und öfter mal Ausfälle. Insbesondere bei Programmänderungen.

Davon kann ich auch ein Lied singen. Der Refrain endet mit einer zusätzlichen CPU als Gateway OPCUA/PN.

 

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Davon kann ich auch ein Lied singen. Der Refrain endet mit einer zusätzlichen CPU als Gateway OPCUA/PN.

Das deckt sich mit meinen Erfahrungen. Meiner Meinung nach ist OPCUA auch nicht die erste Wahl bei der CPU zu CPU-Kommunikation.

Es ist eher dafür gedacht um einen zeitunkritischen Datenaustausch zwischen CPUs und PC-Systemen, Energiemanagementsystemen, Prozessleitsystem etc. zu ermöglichen. Oder eben auch zeitunkritischer Datenaustausch zwischen den CPUs, mit Hinblick auf die vorgenannten End-Aufgaben. Beispielsweise eine CPU die alle Prozessdaten von anderen Steuerungen einsammelt, aufbereitet und dann an ein übergeordnetes System übergibt.

Aber für die Kommunikation einer zusammenhängenden Anlage, wo permanent Daten hin und her geschickt werden, welche für den Prozess und die Weiterbearbeitung relevant sind, sehe ich OPCUA nicht als das Mittel der Wahl.

 

[Blockmove]

Wäre das Ganze denn nicht eine Art PN-PN-Koppler? Auf B&R-Seite ist es ein Profinet-Device-Kommunikationsmodul, OHNE IP-Adresse. Die IP-Adresse vergibt ja die Siemens CPU an das B&R-PN-Device-Modul. Den Profinet-Namen konfiguriert man in der B&R-CPU bzw. im AutomationStudio. Die B&R-CPU leitet dann intern die Daten an das PN-Modul, dort werden die Daten an den PN-Master (Siemens S7) übergeben.

Du hast erwähnt, dass die Steuerungen in unterschiedlichen Netzwerken sind und Firewalls dazwischen sind.
Das macht die Sache mit Profinet nicht gerade einfach.
Profinet ist nicht gedacht für die Kommunikation über Subnetzgrenzen hinweg.
Da hat ein klassischer PN/PN-Koppler eben den Vorteil, dass du eine saubere Trennung der Netzwerke hast.
Jeder hat seine Seite des Kopplers in seinem Netzwerk und es werden nur die benötigten Signale ausgetauscht.
So gesehen eine weitere Firewall.
Setz bei dir den Koppler in Schaltschrank und dann kann sich der BR-Kollege und die IT darum kümmern, wie sie das BR-Netz zu dir in den Schrank bringen.

 

[KarlMeier]

Du hast erwähnt, dass die Steuerungen in unterschiedlichen Netzwerken sind und Firewalls dazwischen sind.
Das macht die Sache mit Profinet nicht gerade einfach.
Profinet ist nicht gedacht für die Kommunikation über Subnetzgrenzen hinweg.
Da hat ein klassischer PN/PN-Koppler eben den Vorteil, dass du eine saubere Trennung der Netzwerke hast.
Jeder hat seine Seite des Kopplers in seinem Netzwerk und es werden nur die benötigten Signale ausgetauscht.
So gesehen eine weitere Firewall.
Setz bei dir den Koppler in Schaltschrank und dann kann sich der BR-Kollege und die IT darum kümmern, wie sie das BR-Netz zu dir in den Schrank bringen.

Was spielen denn die IP-Netze, bei der direkten Kommunikation über PN, für eine Rolle?
Die IP-Adresse der B&R-Steuerung spielt doch überhaupt gar keine Rolle für die Profinet-Kommunikation.
Die B&R-Steuerung arbeitet über die eigenen Netzwerkports via Powerlink/Ethernet mit der eigenen Peripherie, Datenbank etc. Mit diesem Netz hat dann die Siemens-Steuerung überhaupt nichts zu tun. Die S7 arbeitet in ihrem eigenen Netz und holt sich am PN-Modul der B&R-Steuerung, welches im gleichen IP-Bereich arbeitet wie die S7 die Daten ab. Es ist so gesehen ein PN/PN-Koppler, welcher nicht als Standalone-Gerät im Schaltschrank sitzt, sondern als Kommunikationsmodul direkt an der B&R-CPU angeschlossen ist.

Es wäre nur bei OPCUA ein Problem, weil der OPC-Server dann natürlich im IP-Bereich der B&R-Steuerung wäre. Das ist aber bei Profinet nicht so, weil das in der Steuerung wie eine zusätzliche Netzwerkkarte gesehen wird, die eine unabhängige IP-Adresse aus einem ganz anderen Subnet bekommen kann.

Oder sehe ich da irgendetwas falsch? Ich hab das so noch nie genutzt, aber ich wüsste auch nicht warum es anders sein sollte. Was ich noch nicht erwähnt habe… Bei der B&R-Steuerung gibt es mit der OPCUA-Lösung kein PN-Device-Kommunikationsmodul. Die B&R-Steuerung hat auch keinerlei Profinet-Peripherie.

Hab es mal ganz schematisch aufskizziert. Gelb is die Lösung mit PN. Alles andere wäre die Lösung über OPCUA.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was spielen denn die IP-Netze, bei der direkten Kommunikation über PN, für eine Rolle?

Die Frage ist halt wie die Netzwerkverbindung zwischen dem BR PN-Modul und deiner Steuerung zu Stande kommt.
Wenn das über ein Firmennetz mit ein paar Netzwerkkomponenten dazwischen laufen soll, wird es mit Profinet "interessant".
Profinet-Teilnehmer müssen im gleichen IP-Subnetz sein.

 

[KarlMeier]

Die Frage ist halt wie die Netzwerkverbindung zwischen dem BR PN-Modul und deiner Steuerung zu Stande kommt.
Wenn das über ein Firmennetz mit ein paar Netzwerkkomponenten dazwischen laufen soll, wird es mit Profinet "interessant".
Profinet-Teilnehmer müssen im gleichen IP-Subnetz sein.

Die Netzwerkverbindung vom B&R PN-Modul zur S7 kommt mit einem Netzwerkkabel direkt vom B&R-Modul zum S7-Schaltschrank zu Stande. Im S7-Schrank gibt es lediglich einen internen Switch. Das wars…
Leitungslänge ca. 20m

 

[Blockmove]

Die Netzwerkverbindung vom B&R PN-Modul zur S7 kommt mit einem Netzwerkkabel direkt vom B&R-Modul zum S7-Schaltschrank zu Stande. Im S7-Schrank gibt es lediglich einen internen Switch. Das wars…
Leitungslänge ca. 20m

Dann ist's ja simpel

 

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dann ist's ja simpel

Richtig, sehe ich auch so. Der Hersteller der Erweiterungsanlage besteht aber auf OPCUA und da wäre alleine schon der Weg von einer Steuerung zur Anderen um ein vielfaches länger und dazwischen gibt es mehrere Netzwerkgeräte wie Switche und Patchfelder, sowie 2 Firewalls. Das käme zur allgemeinen OPCUA-Problematik noch mit dazu.

 

[Blockmove]

Richtig, sehe ich auch so. Der Hersteller der Erweiterungsanlage besteht aber auf OPCUA und da wäre alleine schon der Weg von einer Steuerung zur Anderen um ein vielfaches länger und dazwischen gibt es mehrere Netzwerkgeräte wie Switche und Patchfelder, sowie 2 Firewalls. Das käme zur allgemeinen OPCUA-Problematik noch mit dazu.

Solange bei dir der OPC UA Server ist, hält sich der aufwand in Grenzen. Wenn man nen Client umsetzen muss, dann ist das Mist.
Klar Geschwindigkeit, Zuverlässigkeit, Fehlersuche ... Alles nicht der Hit.

 

[KarlMeier]

Solange bei dir der OPC UA Server ist, hält sich der aufwand in Grenzen. Wenn man nen Client umsetzen muss, dann ist das Mist.
Klar Geschwindigkeit, Zuverlässigkeit, Fehlersuche ... Alles nicht der Hit.

Ja wenn die S7 Server ist, dann wäre die programmtechnische Umsetzung relativ schnell gemacht. Allerdings nutze ich im Moment kein OPCUA an der S7. Das is natürlich kaum der Rede wert, da die 1513 genug Leistung hat, trotzdem verschlechtert es die Performance wenn ich den Server aktiviere. Und wie von dir erwähnt inkl. der ganzen Probleme die OPCUA mit sich bringt. Beim Datenaustausch mit übergeordneten Systemen sind diese „Probleme“ nicht ganz so relevant. Wenn aber die Produktion stoppt, weil es Probleme mit dem Datenaustausch gibt, dann ist das schon ne andere Hausnummer.

Der OPC-Client Seitens B&R ist relativ einfach umzusetzen. Das hab ich selbst schon gemacht. Damals musste ich aufgrund von Steuerungsmangel eine B&R-Steuerung als dezentrale Peripherie missbrauchen. Der Datenaustausch erfolgte über OPCUA, also genauso wie jetzt im Gespräch wäre, allerdings war die Verbindung damals direkt, ohne irgendwelche Firewalls und alles im gleichen Subnetz. Trotzdem gab es regelmäßig Aussetzer, die Signale froren plötzlich ein, dann hat es sich nach paar Minuten erst wieder gefangen. Dann war die Verbindung wieder getrennt usw. Manchmal half nur ein kompletter Neustart des Clients oder des Servers oder beidem. Das veranlasste mich dann dazu, dass ich auf der B&R ein Notprogramm schreiben musste, welches beim OPCUA-Ausfall die „lebenswichtigen“ Funktionen übernommen hat. Da ging es um Trockenlauf- und Überlaufschutz für verschiedene Wassertanks, Nachfüllung, Ventilsteuerung etc. Also alles nicht im Sinne des Erfinders.

Man kann also zusammenfassend sagen, dass es keine brauchbaren Argumente FÜR OPCUA bei meiner oben beschriebenen Situation, gegenüber der Lösung mit Profinet gibt.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der OPC-Client Seitens B&R ist relativ einfach umzusetzen. Das hab ich selbst schon gemacht. Damals musste ich aufgrund von Steuerungsmangel eine B&R-Steuerung als dezentrale Peripherie missbrauchen. Der Datenaustausch erfolgte über OPCUA, also genauso wie jetzt im Gespräch wäre, allerdings war die Verbindung damals direkt, ohne irgendwelche Firewalls und alles im gleichen Subnetz. Trotzdem gab es regelmäßig Aussetzer, die Signale froren plötzlich ein, dann hat es sich nach paar Minuten erst wieder gefangen. Dann war die Verbindung wieder getrennt usw. Manchmal half nur ein kompletter Neustart des Clients oder des Servers oder beidem.

Das ist ja völlig unakseptabel.
Welche Verbindung besteht zwischen du und dem Lieferanten des B&R-Steuerungssystems? Kunde? Unterlieferant? Ihr sind beide Lieferanten an dieselbe Kunde ?
Ich wurde die Kunde bestimmen ob Profinet oder OPC UA. Und ich wurde die obengenannte Erfahrungen erwähen dass er bewusst ist es gibt einen Risiko.
Und wenn es OPC UA sein muss wurde ich schriftlich erklären dass ich keinen Verantwortlichkeit nehmen wurde.

 

[Richard P.]

... Bei OPCUA habe ich die Befürchtung, dass sich unter Umständen mal der Server aufhängt, dass die Kommunikation einfriert, dass es bei evtl. Programmänderungen, Firmware-Updates etc. Probleme gibt...

Woher kommen deine Befürchtungen eigentlich? Ich war mir in meinem Fall nie ganz sicher, nicht irgend etwas falsch gemacht zu haben. Möglichkeiten, großartig zu testen, gab es später auch nicht.

... Wenn aber die Produktion stoppt, weil es Probleme mit dem Datenaustausch gibt, dann ist das schon ne andere Hausnummer...

So war es auch in meinem Fall. Bei jeder Änderung eines beliebigen Datenbausteins startete der OPCUA-Server neu. Erst nach mehreren -zig(?) Sekunden kam die Kommunikation wieder zustande. Eine viel zu lange Zeitspanne für einen Watchdog, der die Anlage bei Kommunikationsausfall möglichst schnell abschalten sollte. Die Überwachungszeit war bei stehender Kommunikation ohnehin schon grenzwertig. Um die laufende Produktion nicht zu gefährden, musste ich, auf Wunsch und nach gründlicher Klärung mit dem Kunden, vorübergehend die Überwachungszeit sehr hoch setzen, was im Fehlerfall zu hohen Schäden hätte führen können. Später haben wir, wie schon erwähnt, eine zusätzliche S7 verbaut, welche ausschließlich diese lausige OPCUA-Kommunikation übernimmt.

... Man kann also zusammenfassend sagen, dass es keine brauchbaren Argumente FÜR OPCUA bei meiner oben beschriebenen Situation, gegenüber der Lösung mit Profinet gibt.

Aus meiner Sicht ist OPCUA in solchen Fälle das Allerletzte! Vielleicht liegt das Übel aber auch auf Seiten von Siemens. Immerhin entsteht das Problem bei Programmänderungen in der S7, die mit OPCUA eigentlich nichts zu tun haben.

... Der Hersteller der Erweiterungsanlage besteht aber auf OPCUA ...

Eine österreichische Firma mit "A"?

 

[KarlMeier]

Das ist ja völlig unakseptabel.
Welche Verbindung besteht zwischen du und dem Lieferanten des B&R-Steuerungssystems? Kunde? Unterlieferant? Ihr sind beide Lieferanten an dieselbe Kunde ?
Ich wurde die Kunde bestimmen ob Profinet oder OPC UA. Und ich wurde die obengenannte Erfahrungen erwähen dass er bewusst ist es gibt einen Risiko.
Und wenn es OPC UA sein muss wurde ich schriftlich erklären dass ich keinen Verantwortlichkeit nehmen wurde.

Meine Firma ist Kunde und ich bin Errichter/Betreuer der Bestandsanlage und bin für die Anbindung der neuen Anlage zuständig.

 

[KarlMeier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Woher kommen deine Befürchtungen eigentlich? Ich war mir in meinem Fall nie ganz sicher, nicht irgend etwas falsch gemacht zu haben. Möglichkeiten, großartig zu testen, gab es später auch nicht.

Wie gesagt, ich hatte genau diese Konstellation im produktiven Einsatz, wenn auch nur als Übergangslösung. Ich kann es nicht ausschließen, dass man durch verschiedene Parameter das Ganze stabiler machen kann. Die Aktualisierungszeit hatte ich auf 1 sek und auf 5 Sekunden ohne Verbesserung. Recht viel mehr hab ich nicht herumgespielt.

Aus meiner Sicht ist OPCUA in solchen Fälle das Allerletzte! Vielleicht liegt das Übel aber auch auf Seiten von Siemens. Immerhin entsteht das Problem bei Programmänderungen in der S7, die mit OPCUA eigentlich nichts zu tun haben.

Sehe ich genauso. Kann schon sein, dass es an Siemens liegt, aber Fakt ist dass es nicht 100% stabil funktioniert, darum finde ich OPCUA auch ungeeignet für die geplante Anlage.

Eine österreichische Firma mit "A"?

Nein

 

[oliver.tonn]

Echtzeit wäre ja wohl Profinet IRT… geht das über PN/PN-Koppler?

Wieso?
Ich weiß nicht warum sich immer noch das hartnäckige Gerücht hält, dass Echtzeit immer etwas mit schnell zu tun hat.
Echtzeit hat nicht unbedingt etwas mit schnell zu tun und damit würde auch "normales" Profinet eventuell reichen.
Wenn ein System garantiert innerhalb einer bestimmten Zeit die Abarbeitung beendet hat ist das System echtzeifähig. Das kann bei einer Achsregelung tatsächlich eine sehr kleine Zeitspanne im unteren ms Bereich sein, bei einer Temperaturregelung kann Echzeit vorliegen, wenn das System innerhalb von über 100ms reagiert.