Step7 RFC1006
Hallo DELTALOGIC Support,
leider konnte ich nicht eher auf Ihre Fragen antworten. Ich hoffe, meine späte Antwort ist noch von Interesse.
Können Sie mir da bitte ein Beispielprojekt schicken?
siehe Posting #22
Warum sollte Step7 in der gezeigten Konstellation die IP Adresse der SPS auf die tatsächlich zugegriffen wird durch die öffentliche IP Adresse der projektierten Router SPS ersetzen?
Kurz:
Step7 verwendet das Routing-Protokoll RFC1006 auf dem ISO-tsap Port 102 (also kein Portforwarding)
Step7 versucht den Verbindungsaufbau auf allen dem aktuell eingestellten PG/PC-Schnittstellen-Typ entsprechenden Netzen
Fall A) im Step7-Projekt ist kein "zugeordnetes" PG/PC vorhanden:
Abhängig von der Einstellung der PG/PC-Schnittstelle sucht Step7 selbständig einen passenden Weg zur Ziel-SPS.
Solange im Projekt nur 1 Netzwerk vom passenden Typ zur PG/PC-Schnittstelle vorhanden ist, ist Step7 klar an welchem Netzwerk es
angeschlossen sein müsste und über welche routingfähigen Stationen die Route zur Ziel-SPS führt.
Wenn mehrere vom Typ her passende Netzwerke im Projekt vorhanden sind, versucht Step7 (zumindest bei Ethernet) nacheinander über
jedes passende Netzwerk mit möglichst wenigen Zwischenstationen eine Verbindung zur Ziel-SPS aufzubauen. Ob vorher eventuell anhand
der Netzwerkmasks und der Subnetz-Anteile der IP-Adresse
der im Step7-PC vorhandenen Netzwerkadapter sowie der IP-Adresse der
Ziel-SPS eine Vorauswahl stattfindet, weiß ich nicht, ist aber denkbar.
In meinem Beispiel wird Step7 zuerst versuchen, die kurze direkte Verbindung über das IE-Netzwerk Ethernet(LAN) zur Ziel-SPS IP-Adresse 192.168.10.1 aufzubauen. Das wird natürlich nicht klappen (Step7 wird höchstens eine andere SPS finden, falls sich im lokalen Netzwerk des Step7-PC zufällig eine SPS mit der gleichen IP wie die der Ziel-SPS befindet!). :-(
Wenn der Step7-PC zufällig auf einem seiner aktiven Netzwerkadapter eine IP-Adresse mit dem gleichen Netzwerksegment wie die lokale IP-Adresse der Ziel-SPS hat (192.168.10.x), dann scheint Step7 davon auszugehen, es wäre an Ethernet(LAN) angeschlossen und versucht den Verbindungsaufbau nur über diesen direkten Weg.
Meistens wird der Step7-PC auf keiner seiner Netzwerkadapter eine zum fernen Ethernet(LAN) passende IP-Adresse haben.
Da der Verbindungsaufbau zur Adresse 192.168.10.1 am Ethernet(LAN) nicht geklappt hat, versucht Step7 als nächstes eine Verbindung über das IE-Netzwerk Ethernet(WAN). Hier sieht Step7, daß da eine routingfähige SPS-Station mit Verbindung zum Zielnetzwerk Ethernet(LAN) vorhanden ist, welche über die IP 82.176.x.x erreichbar ist. Also schickt Step7 seinen Verbindungswunsch an diese Station. Der reale Router mit der IP 82.176.x.x "forwardet" die Pakte zur Ziel-SPS (das ist ja vom Kunden-IT-Administrator so eingerichtet worden, und das hat Step7 von der "SIMATIC"-Station auch so erwartet). Die Ziel-SPS erkennt anhand der im RFC1006-Paketrahmen enthaltenen Subnet-ID und Ziel-Adresse, daß/ob das Paket für sie selber bestimmt ist.
(Es kann sein, das der RFC1006-Rahmen in Wirklichkeit nur ein erweiterter Header ist. So genau kenne ich das RFC1006-Protokoll nicht.)
Übrigens: Falls keine Verbindung zur Ziel-SPS zustande kommt, versucht Step7 den Verbindungsaufbau (zumindest bei TCP/IP) nicht nur über den ausdrücklich bei der PG/PC-Schnittstelle zugeordneten Netzwerkadapter, sondern davon abweichend über alle gerade aktiven Netzwerkadapter (z.B. WLAN oder DFÜ-Adapter).
(Vielleicht überläßt Step7 die Adapterauswahl auch einfach Windows? eher unwahrscheinlich)
Fall B) im Step7-Projekt ist ein dem Ethernet(WAN) "zugeordnetes" PG/PC vorhanden:
Weil Step7 durch das "zugeordnete" PG/PC eindeutig bekannt ist, daß es am Ethernet(WAN) angeschlossen ist, versucht es den Verbindungsaufbau sofort und nur über die Station mit der IP 82.176.x.x
Ich habe mir angewöhnt, immer ein PG/PC ins Step7-Projekt einzufügen, wenn es mehrere Netzwerke vom selben Typ im Projekt gibt.
Dies ist die einzige mir bekannte Möglichkeit, Step7 explizit vorzuschreiben, welchen Weg es zur Ziel-SPS nehmen soll.
IP-Adressen-Wahl für Automatisierungsnetze
Wegen der geforderten Trennung von Automatisierungsnetzen vom restlichen Firmennetz verwende ich niemals die IP-Adressen 192.168.0.x ... 192.168.9.x für meine PLC-Netze. Diese IP-Adressen sind oft schon (oder werden irgendwann einmal) für das Büro-Netzwerk des Kunden verwendet. Ich verwende fast immer IP-Adressen aus dem Bereich 192.168.192.x ... 192.168.199.x für meine PLC-Netze.
Erstens halte ich damit den zeitweise exorbitanten PC-Netzwerktraffik und die öfter vorkommenden Broadcast-Stürme von meinen PLC fern, zweitens ist es dann relativ einfach zu administrieren, wenn Verbindungen zwischen den Netzen benötigt werden, weil z.B. Daten zwischen PLCs und Kunden-PCs (MES, QMS, Archiv-Server, ...) ausgetauscht werden sollen. Für Firewalls sind nur wenige Regeln auf Netzwerk-Adressen-Basis nötig (Zone: Netzwerk 192.168.192.0, Mask 255.255.248.0).
In dieser Zone habe ich ca. 2000 IP-Adressen für PLCs, Panels und andere Automatisierungskomponenten zur Verfügung!
Spezialproblem MP277 / WinCCflexible:
Ich glaube nicht, daß der Projekt-Transfer WinCCflexible -> MP277 funktioniert, wenn man einfach nur im Projekt die öffentliche IP 82.176.x.x direkt in die Hardware-Konfiguration des MP277 einträgt. Normalerweise findet der Transfer über den Port 2308 statt (alternativ Port 50523). Nur wenn WinCCflexible weiß, daß es nicht am selben Netz wie das MP277 angeschlossen ist, dann wird der Transfer über das Protokoll RFC1006 mit Port 102 "getunnelt".
Eventuell geht das:
Im Transfer-Dialog von WinCCflexible gibt es die Option "(x) Routing aktivieren, nächste Station: xxxxxxx" (oder so ähnlich).
Ich weiß aber nicht, ob diese Option bei WCF2008 auch für Ethernet verfügbar ist und ob man da die IP 82.176.x.x direkt eintippen kann. Alternativ könnte/müßte in der Kunden-Firewall zusätzlich zum Port 102 auch noch ein Portforwarding für Port 2308 eingerichtet werden. Der Kunde-Administrator wird sich über die bevorstehende Port-"Inflation" freuen ;-)
Fazit, Credits,
etwas Eigenlob ;-)
Also, ich finde meinen Router-Stellvertreter ziemlich elegant. Er dokumentiert gut die reale Vernetzung und ich kann auf diese Weise jederzeit von fern die Hardware-Konfiguration aus Step7 in die Ziel-SPS laden. Ich habe den Router-Stellvertreter in knapp 10 Projekten eingesetzt. Es funktioniert einfach.
In mehreren Projekten habe ich PLC ohne eigene Ethernet-Schnittstelle mit Ethernet-zu-MPI-Programmieradaptern an Ethernet angeschlossen. Hier füge ich für den Zugriff über Ethernet bzw. Internet eine modifizierte Variante des Router-Stellvertreters in das Step7-Projekt ein (der "CP IE (LAN)" entfällt, die CPU314-MPI-Schnittstelle ist dann mit dem "PLC Network(MPI)" verbunden). Und schon mault Step7 nicht mehr rum: "Die Station ist über Ethernet garnicht erreichbar!".
Obwohl, einen kleinen Schönheitsfehler hat "mein" Router: er sieht aus wie eine SPS und die Schnittstellen werden von NetPro nicht mit den selbst vergebenen Baugruppen-Namen beschriftet ("CP IE (WAN)"), sondern mit den Step7-Kurzbezeichnungen ("CP 343-1").
Ob Siemens eigentlich weiß, wie universell das Objekt-Konzept von Step7 nutzbar ist? ;-) Jedenfalls habe ich diese Konstellation (SIMATIC-Station als Router-Stellvertreter) im Siemens-Support oder in Siemens-Handüchern noch nicht gesehen.
In diesem Forum findet man eine Menge gute Beiträge und Anleitungen zu Netzwerk-spezifischen Problemen:
www.administrator.de - Bereich: Netzwerke und Protokolle
Gute Nacht.
PN/DP
hab es jetzt doch hin bekommen. Keine Ahnung wiso das vorher nicht ging. Warum es überhaupt funktioniert ist mir noch nicht ganz klar. Vermutlich macht Siemens selber in SIMATIC beim Routing an der Stelle intern in Wirklichkeit ein Portforwarding.
?
