TIA Netzweite Eindeutigkeit F-Kommunikations-ID SENDDP/RCVDP bei vernetzen Anlagen

[revilo16]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
ich habe ein Frage zur Eindeutigkeit der F-Kommunikations-ID (Eingang "DP_DP_ID" auf den Bausteinen SENDDP und RCVDP).
In der Siemens Dokumentation ist zu lesen, dass diese netzweit und CPU-weit eindeutig sein muss.
Ich bin nun auf eine Altanlage gestoßen beim dem dies meiner Meinung nach nicht so ist und frage mich ob daher ein Sicherheitsrisiko besteht.

Folgender Aufbau ist gegeben:
Mehrere ähnlichen Maschinen sind im gleichen Subnetz:
Maschine 1 verwendet IP Range: 172.16.11.X
Maschine 2 verwendet IP Range: 172.16.12.X
Maschine 3 verwendet IP Range: 172.16.13.X
Maschine 4 verwendet IP Range: 172.16.14.X
Es eine Switch (172.16.0.1) auf dem alle diese Maschinen zusammen laufen.
Subnetzmaske überall: 255.255.0.0.

Die Maschinen kommunizieren untereinander nicht jedoch alle mit der selben Maschine X im Range 172.16.10.X die auch auf dem Switch ist.
Diese Kommunikation ist jedoch nicht über SENDDP/RCVDP realisiert und beinhaltet keine sicherheitsgerichteten Signale.
Projektiert sind alle Anlagen jeweils in separaten TIA Projekten (Teils V13, Teils V14, Teils V15.1).
Soweit so gut.

Nun zum Knackpunkt:
Die Maschinen 1+2 kommunizieren zusätzlich, über je einen PN/PN Koppler mit jeweils einer weiteren Maschine (A+B) und tauschen darüber sicherheitsgerichtete Signale aus.
Dafür werden die Bausteine SENDDP und RCVDP verwendet. Diese sind in den Maschinen 1+2 aber jeweils gleich beschaltet.
D.h. Maschine 1+2: Eingang "DP_DP_ID" bei SENDDP = 1; Eingang "DP_DP_ID" bei RCVDP = 2.

Das ist, soweit ich die Siemens Anleitung richtig interpretiere nicht richtig?
Was mich jedoch etwas stutzig macht ist das Siemens zur Vermeidung dieses Fehlers folgendes schreibt:
"Die Eindeutigkeit muss bei der Abnahme des Sicherheitsprogramms im Ausdruck des Sicherheitsprogramms überprüft werden."
Wenn ich nun jedoch den Ausdruck von einem Projekt anschaue (eine Maschine) ist die ja Eindeutigkeit gegeben.
Somit wäre aber nur die CPU-weite Eindeutigkeit sichergestellt?
Nur mit dem Wissen von weiteren Anlagen im gleichen Netz scheint, das nicht mehr in Ordnung zu sein?

Sehe ich das soweit richtig und besteht hier Handlungsbedarf?
Die Anlagen laufen so schon seit vielen Jahren. Mich wundert etwas, dass das überhaupt funktioniert.
Auf der anderen Seite wissen die Bausteine ja über die "LADDR" und die HW-Konfig ja über welchen Koppler die sicheren Daten ausgetauscht werden sollen unabhängig der "DP_DP_ID"?
Es wird wahrscheinlich erst ein Problem wenn z.B. ein Koppler getauscht wird und dem die falsche IP / Gerätename zugewiesen wird, oder?
Das Problem ist auch, dass ich das zwar bei Maschine 1+2 anpassen könnte, nicht jedoch bei den Maschinen A+B auf der Gegenseite.
Doch das müsste ja zeitgleich dann auch geschehen.
Ob die Maschinen A+B auch untereinander vernetzt sind, kann ich nicht sagen.
Wenn ja, wäre dort ja das gleich Problem vorhanden und somit ohnehin auf beiden Seiten Handlungsbedarf?

Sorry für den langen Text, aber ich wollte den Zusammenhang genau darstellen und misverständnisse zu vermeinden.
Ich hoffe auf eure Hilfe.

Revilo

 

[Blockmove]

Du hast recht.
Die Konfig sollte so nicht ausgeführt werden.
Beim Tausch der Koppler kann es zu Problemen kommen.
Daher IDs ändern.

 

[revilo16]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok. Dann werde ich das mal in Angriff nehmen. Danke für die schnelle Antwort.

 

[NBerger]

Wie soll das denn gehen in der Praxis:
Da wird eine neue Anlage bestellt, gebaut, geliefert... wie soll ich da beim Kunden diese Netzeindeutigkeit garantieren können. Muss der Kunde dann jede Software von jeder Anlage bereitstellen um diese zu prüfen???
Sowas eskaliert mal ganz schnell!

 

[Blockmove]

Wie soll das denn gehen in der Praxis:
Da wird eine neue Anlage bestellt, gebaut, geliefert... wie soll ich da beim Kunden diese Netzeindeutigkeit garantieren können. Muss der Kunde dann jede Software von jeder Anlage bereitstellen um diese zu prüfen???
Sowas eskaliert mal ganz schnell!

Ja, sowas ist schnell unübersichtlich.
Wenn aber mehrere Maschinen im gleichen Subnetz sind, dann muss da sowieso eine Doku her und einer muss den Hut aufhaben.

 

[revilo16]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das haben ich mich eben auch gefragt. Zumal nicht nur das Subnet gemeint ist.

Siehe:
SIMATIC Industrie Software SIMATIC Safety - Projektieren und Programmieren Programmier- und Bedienhandbuch 05/2021 Kap.:11.7 (S. 391):

* Ein Netz besteht aus einem oder mehreren Subnetzen. "Netzweit" bedeutet, über SubnetzGrenzen hinweg. Bei PROFIBUS umfasst ein Netz alle über PROFIBUS DP erreichbaren Teilnehmer. Bei PROFINET IO umfasst ein Netz alle über RT_Class_1/2/3 (Ethernet/WLAN/Bluetooth, Layer 2) und ggf. RT_Class_UDP (IP, Layer 3) erreichbaren Teilnehmer.

 

[revilo16]

Es könnte ja z.B. auch sein dass ein Kunde selbst im nachhinein 2 Anlagen miteinander vernetzet.
Z.B. für Fernwartung ect.
Da die Teilnehmer in den Anlagen jeweils in 2 verschiedenen Subnetzen sind, denkt der Kunde das ist kein Problem.
Dabei hat doch niemand auf dem Schirm dass die Anlagen dadurch "unsicherer" werden da im Gesamtnetz dann gleiche DP_DP_ID's verwendet werden.

 

[maxder2te]

Wie soll das denn gehen in der Praxis:
Da wird eine neue Anlage bestellt, gebaut, geliefert... wie soll ich da beim Kunden diese Netzeindeutigkeit garantieren können. Muss der Kunde dann jede Software von jeder Anlage bereitstellen um diese zu prüfen???
Sowas eskaliert mal ganz schnell!

Mit den 1500er Steuerungen ist das recht einfach zu lösen.

Die meisten meiner Kunden schreiben Steuerungen mit 2 unabhängigen Ethernet Schnittstellen vor, zum Beispiel 1515F. Am X1 betreibt man isoliert profinet und profisafe, über X2 erfolgt die Vernetzung der Maschinen.

Alternativ kann man jede Maschine über eine Firewall entkoppeln, welche zwar auf Layer 3 transparent ist, aber auf Layer 2 undurchlässig. Das lässt sich im Siemens Universum z.B. mit den Scalance Sc622 lösen. Auch die Entkopplung über VLAN-Switches und eine zentrale Firewall ist möglich.

Viele Firmen sind dafür aber einfach zu geizig, weil man sich da pro Maschine einen Tausender Hardware sparen kann und dafür viel Zeit und Ärger in Dokumentation und Fehlersuche investiert.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit den 1500er Steuerungen ist das recht einfach zu lösen.

Die meisten meiner Kunden schreiben Steuerungen mit 2 unabhängigen Ethernet Schnittstellen vor, zum Beispiel 1515F. Am X1 betreibt man isoliert profinet und profisafe, über X2 erfolgt die Vernetzung der Maschinen.

Auch (oder eigentlich gerade bei) bei getrennten Netzen kannst du das Problem mit den Safety-Verbindungs-IDs haben.
Bin vor 2 Jahren selber über das Thema gestolpert beim Retrofit einer Anlage von Profibus zu Profinet.
2 Profinetkoppler falsch zugeordnet und schon war das Chaos da. Verbindungs-ID war gleich, Konfiguration war gleich -> Alles grün und Not-Halt- und Schutzkreis-Zuordnung passt hinten und vorne nicht.
Dann erstmal einen halben Tag hingesetzt und bei 4 Anlagen eindeutige IDs vergeben.

 

[maxder2te]

Auch (oder eigentlich gerade bei) bei getrennten Netzen kannst du das Problem mit den Safety-Verbindungs-IDs haben.
Bin vor 2 Jahren selber über das Thema gestolpert beim Retrofit einer Anlage von Profibus zu Profinet.
2 Profinetkoppler falsch zugeordnet und schon war das Chaos da. Verbindungs-ID war gleich, Konfiguration war gleich -> Alles grün und Not-Halt- und Schutzkreis-Zuordnung passt hinten und vorne nicht.
Dann erstmal einen halben Tag hingesetzt und bei 4 Anlagen eindeutige IDs vergeben.

Hmm, das über eine ganze Halle eindeutig zu gestalten macht natürlich Sinn, ganz habe ich die Problematik aber nicht verstanden.

Da muss zum Einen beim Zusammenstecken der Profinet - Kabel was schief gegangen sein und außerdem waren wohl die Gerätenamen der Anlagen identisch (was ja auch nicht ratsam ist). Innerhalb einer CPU können IDs ja nur einmalig vergeben werden, sonst meckert der Compiler, oder macht das TIA nicht mehr?

 

[Blockmove]

@maxder2te
Wenn du einen Profinet-Koppler hast, dann kennt TIA die andere Seite nicht.
Du definierst deine Signale und eben die Safety-ID.
Im Prinzip ist vergleichbar, wenn man bei klassischer Verdrahtung die Schnittstellenstecker vertauscht hat.
Klar ist es eine recht exotische und recht seltene exotische Fehlerquelle, aber eben nicht ausgeschlossen.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

@maxder2te
Wenn du einen Profinet-Koppler hast, dann kennt TIA die andere Seite nicht.
Du definierst deine Signale und eben die Safety-ID.
Im Prinzip ist vergleichbar, wenn man bei klassischer Verdrahtung die Schnittstellenstecker vertauscht hat.
Klar ist es eine recht exotische und recht seltene exotische Fehlerquelle, aber eben nicht ausgeschlossen.

Was da schief gehen kann ist mir schon bewusst, aber dein Vergleich hinkt trotzdem.

Wenn ich Anlage A mit Anlage B kopple, außerdem Anlage C mit Anlage D, und dabei die gleichen IDs verwende, dann passiert das von dir beschriebene, wenn wann die Schnittstellen Stecker vertauscht und A mit D verbindet und C mit B. Hier krachts. Aber da muss schon jemand bei der Vergabe der Profinet Gerätenamen schlampig gewesen sein UND die Gerätenamen der Koppler müssen z.B. bei A und C identisch sein. Es sind also mehrere Fehler passiert.
Das sowas in der Praxis nicht zu selten passiert weiß ich aus eigener Erfahrung.

Wenn aber A mit B gekoppelt wird und auch A mit C, dann müssen die IDs A-B und A-C unterschiedlich sein, weil sonst alleine schon der Compiler meckert, zumindest war das in classic noch so. Ein vertauschen der Stecker von B und C kann dann zu keinen Fehlern führen.

Generell trauere ich da Profibus ein kleines bisschen hinterher, der war per se einfach von der Anlagenvernetzung her getrennt, ebenso wie das heute bei Powerlink oder EtherCAT der Fall ist.

 

[Blockmove]

Was da schief gehen kann ist mir schon bewusst, aber dein Vergleich hinkt trotzdem.

Wenn ich Anlage A mit Anlage B kopple, außerdem Anlage C mit Anlage D, und dabei die gleichen IDs verwende, dann passiert das von dir beschriebene, wenn wann die Schnittstellen Stecker vertauscht und A mit D verbindet und C mit B. Hier krachts. Aber da muss schon jemand bei der Vergabe der Profinet Gerätenamen schlampig gewesen sein UND die Gerätenamen der Koppler müssen z.B. bei A und C identisch sein. Es sind also mehrere Fehler passiert.
Das sowas in der Praxis nicht zu selten passiert weiß ich aus eigener Erfahrung.

Wenn aber A mit B gekoppelt wird und auch A mit C, dann müssen die IDs A-B und A-C unterschiedlich sein, weil sonst alleine schon der Compiler meckert, zumindest war das in classic noch so. Ein vertauschen der Stecker von B und C kann dann zu keinen Fehlern führen.

Generell trauere ich da Profibus ein kleines bisschen hinterher, der war per se einfach von der Anlagenvernetzung her getrennt, ebenso wie das heute bei Powerlink oder EtherCAT der Fall ist.

Es passiert wirklich nur, wenn mehrere Fehler zusammentreffen.

Profibus trauere ich nicht hinterher.
Was micht aber nervt, ist dass bei einem 400€ PN/PN-Koppler nicht mal ein simples 2€-Display drauf ist, dass ganz einfach Profinet-Nr, -Name und IP anzeigt. Suche und Identifizierung per Blinktest ...

 

[Thomas_v2.1]

Wenn man sich mal überlegt, dass bei normaler Kommunikation zur S7 mittlerweile TLS Verschlüsselung Standard ist, und dann existiert bei "fehlersicherer" Kommunikation überhaupt keine Überprüfung dass derjenige der der Steuerung Daten schickt überhaupt der richtige ist? Kann sich da jeder als Kommunikaitionsteilnehmer ausgeben oder wie ist das angedacht? Kann davon mal jemand einen Wireshark Mittschnitt anfertigen, damit man sich davon mal ein Bild machen kann um das entsprechend zu bewerten?

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn man sich mal überlegt, dass bei normaler Kommunikation zur S7 mittlerweile TLS Verschlüsselung Standard ist, und dann existiert bei "fehlersicherer" Kommunikation überhaupt keine Überprüfung dass derjenige der der Steuerung Daten schickt überhaupt der richtige ist? Kann sich da jeder als Kommunikaitionsteilnehmer ausgeben oder wie ist das angedacht? Kann davon mal jemand einen Wireshark Mittschnitt anfertigen, damit man sich davon mal ein Bild machen kann um das entsprechend zu bewerten?

Die Geschichte läuft über SFC14/15.
Also ist da schon mal keine Sicherheit da.
Die E/A-Bereiche kannst du dir ja in Steuerung anschauen bzw. bei der 1500er auch tracen.
Wird halt ein besserer Handshake mit CRC und Telegramm-Countern sein.

 

[Wincctia]

Die Geschichte läuft über SFC14/15.
Also ist da schon mal keine Sicherheit da.
Die E/A-Bereiche kannst du dir ja in Steuerung anschauen bzw. bei der 1500er auch tracen.
Wird halt ein besserer Handshake mit CRC und Telegramm-Countern sein.

Das ist glaube ich sogar in der Profisafe Spezifikation beschriebe, habe mir aber noch nich die Mühe gemacht soetwas mal testweise nachzuprogrammieren.


Gruß Tia

 

[maxder2te]

Das ist glaube ich sogar in der Profisafe Spezifikation beschriebe, habe mir aber noch nich die Mühe gemacht soetwas mal testweise nachzuprogrammieren.


Gruß Tia

Ja, ist es.
Mittlerweile schiebt Siemens da alleine in der Hardwarekonfiguration und mit Compiler-Mitteln schon einen ordentlichen Riegel vor, hier Missbrauch zu treiben.
In Classic war das noch recht einfach. DP/DP-Koppler mit einem benutzerdefinierten 6/12 oder 12/6 Modul versehen, fertig. Wasdie Gegenstelle draus gemacht hat war eigentlich egal. Wenn man die Daten da über andere Steuerungen durchgeleitet hat und an der Gegenstelle eine Rockwell-SLC oder ein CoDeSys-Raspi was Protokoll nachgebaut hat, ging das trotzdem......

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe mich da mal kurz eingelesen. So wie ich das verstehe, wird Profisafe als Nutzdaten in den normalen PN-IO Daten transportiert, mit entsprechenden Control/Status Bytes und einer CRC, in die auch die Verbindungs-ID mit einfließt. Also wenn da jemand anderes im Netzwerk Profisafe Telegramme verschickt, dann sollte das die eigene Kommunikation nicht beeinflussen, weil zwischen diesen Partnern überhaupt keine Kommunikationsbeziehung besteht.

Nur gibt es Profisafe Umgebungsanforderungen, und die besagen, dass du das Profisafe Netzwerk vor anderen Netzen trennen/schützen musst. Also einfach ein Netzwerk mit Profisafe Kommunikation mit anderen Netzwerken zusammenschalten, ist meiner Meinung nach nicht zulässig.

 

[Blockmove]

Nur gibt es Profisafe Umgebungsanforderungen, und die besagen, dass du das Profisafe Netzwerk vor anderen Netzen trennen/schützen musst. Also einfach ein Netzwerk mit Profisafe Kommunikation mit anderen Netzwerken zusammenschalten, ist meiner Meinung nach nicht zulässig.

Genauso ist es.
Du als Anlagenersteller bist für die sichere Umsetzung verantworlich.
Da das Protokoll aber ganz einfach nur auf PN-IO (oder auch Profibus) aufsetzt, ist natürlich nix mit Verschlüsselung, Zeritfikaten, ...
Also genau das selbe wie bei PUT/GET

 

[ws1185]

Mit den 1500er Steuerungen ist das recht einfach zu lösen.

Die meisten meiner Kunden schreiben Steuerungen mit 2 unabhängigen Ethernet Schnittstellen vor, zum Beispiel 1515F. Am X1 betreibt man isoliert profinet und profisafe, über X2 erfolgt die Vernetzung der Maschinen.

Alternativ kann man jede Maschine über eine Firewall entkoppeln, welche zwar auf Layer 3 transparent ist, aber auf Layer 2 undurchlässig. Das lässt sich im Siemens Universum z.B. mit den Scalance Sc622 lösen. Auch die Entkopplung über VLAN-Switches und eine zentrale Firewall ist möglich.

Viele Firmen sind dafür aber einfach zu geizig, weil man sich da pro Maschine einen Tausender Hardware sparen kann und dafür viel Zeit und Ärger in Dokumentation und Fehlersuche investiert.

Ein Router wie der Scalance SC622 ist tatsächlich die beste Wahl. Weitere Möglichkeiten zur Netztrennung beschreibt Siemens gut in diesem FAQ:

SIOS

support.industry.siemens.com

Die Entkopplung über VLAN Switche sehe ich skeptisch. Wenn man das sicherheitstechnisch genauer betrachtet, muss man dem VLAN-Switch auch einen Fehler unterstellen. Der Fehler kann an dieser Stelle einfach passieren: entweder durch Fehlkonfiguration oder z.B. nach FW Update (hier gibt es etliche Fehlerszenarien) kann es passieren, dass der Switch auch tatsächlich zwischen den einzelnen Netzen (auf Layer 2) switched und somit keine Trennung mehr zwischen den Netzen besteht. Die Wahrscheinlichkeit, dass das in der Praxis passiert dürfte in den meisten Fällen zwar sehr gering sein. Die individuelle Betrachtung und Bewertung dafür ist - falls überhaupt - nur mit erheblichem Aufwand möglich. Da ist es dann schon einfacher und sicherer, einen passenden Router wie den SC622 einzusetzen.