Fernwartung über das Internet mit Step7

Fernwartungs-Varianten

DELTALOGIC Support schrieb:

Also, der einfachste Weg ist:

Kunde macht ein Portforwarding (mit dem Begriff sollte der ITler etwas anfangen können) von seinem Internet Gateway Port 102 auf die interne IP-Adresse des MP277 ebenfalls Port 102.

ACHTUNG! In dieser Konstellation ist keinerlei Sicherheit mehr gewährleistet. Um hier auf die Anlage zugreifen zu können, braucht man keinen Benutzer/Passwort, keinen Schlüssel - nur die IP-Adresse und den Port - und die kann man heraus bekommen.

Zum Vergrößern anklicken....

Diesen Tip möchte ich hier nicht so unkommentiert stehenlassen, da in diesem Forum viele absolute SPS-Anfänger mitlesen.

Hier eine Aufstellungen von Fernwartungs-Varianten, die ich nutze:

A) "klassische" Telefon-Einwahl über TS-Adapter mit Simatic TeleService
- keine Anpassungen im Step7-Projekt nötig
- Nachteile: geringe Baudrate, Verbindungskosten, evtl. feste Rückrufnummer

B) Mitglied des fernen Firmennetzwerkes werden über (SSL-)VPN-Zugang
- keine Anpassungen im Step7-Projekt nötig
- Zugangs-Berechtigung durch Kunde-Administrator einfach und voll administrierbar
- Vorteile: hohe Baudrate und keine Verbindungskosten bei DSL-Flatrate
- Nachteil: kostenintensiv, wenn der Kunde noch keine VPN-Zugangslösung hat

C) RemoteDesktop-Verbindung zu einem vor-Ort-PC, der Step7 (...) installiert hat
-- Zugang zum vor-Ort-PC in der Regel über (SSL-)VPN-Verbindung
- keine Anpassungen im Step7-Projekt nötig
- Vorteil: Zugriff auf alle vor Ort vernetzten SPS und Panels einfach möglich
- Vorteil: je nach SPS-Anbindung des vor-Ort-PC ggf. direkte Profibus-Diagnose möglich
- Vorteil: die Step7-Projekte vor Ort sind (immer) aktuell
- Vorteil: der Fernwarte-PC benötigt kein Step7 und kein Step7-Projekt, also quasi jeder PC weltweit nutzbar
- Nachteil: Step7(...)-Lizenz(en) vor Ort nötig
- Nachteil: Programm beobachten in der Regel nicht effektiv (Kommunikation meist zu langsam)
- Nachteil: aufwendige Synchronisation der Step7-Projekte auf vor-Ort-PC und Fernwarte-PC

D) (festes) Port-Forwarding Port 102 in der Kunden-Firewall
- einen "Router" im Step7-Projekt hinzufügen, um Step7 die öffentliche IP-Adresse des Kundenzugangs mitzuteilen
- Vorteile: hohe Baudrate und keine Verbindungskosten bei DSL-Flatrate
- Nachteil: in der Regel keinerlei wirksamer Schutz gegen Fremd-Zugriffe!
- Nachteil: ohne zusätzlichen Aufwand nur eine SPS erreichbar
- Hinweis: ein Ping auf die SPS funktioniert nicht, es antwortet immer die Firewall
- die Ziel-SPS sollte nur während einer vorher verabredeten Fernwartungs-Sitzung mit dem Kunde-Netzwerk verbunden sein
- (Netzwerkkabel die übrige Zeit von der SPS abziehen)

Ich habe zu betreuen
A) 4 Anlagen - Zugang über ISDN und Rückruffunktion
B) ca. 80 Anlagen - Zugang über F5 Networks FirePass
-- 3 Anlagen - Zugang über SonicWALL SSL-VPN 200
C) 2 Anlagen - Zugang über andere SSL-VPN-Verbindungen
D) 6 Anlagen - die Anlagen werden nur für die Dauer der Fernwarte-Sitzung mit dem Kunde-Netzwerk verbunden


Die einfachste Variante D) Port-Forwarding sollte nur eingesetzt werden, wenn es die Gefährdungsanalyse zuläßt und die anderen Varianten nicht wirtschaftlich sind.


Die von mir immer empfohlene Fernwartungs-Variante ist der Fall B) SSL-VPN Zugang
Das kostet zwar einigen Aufwand beim Kunden, ist dann aber die bequemste und sicherste Lösung.

Meine Empfehlung einer VPN-Lösung für größere Firmen
F5 Networks FirePass

kostengünstige VPN-Lösung für kleine Firmen bzw. Einzel-Anlagen
SonicWALL SSL-VPN

z.B. SonicWALL SSL-VPN 200
ca. EUR 900,00 netto inkl. 3 Jahre Garantie + Firmwareupdates + Telefonsupport


Ein paar Aspekte, die bei Fernzugriffen auf SPS-Anlagen unbedingt zu beachten sind:

- Sicherheitsempfehlungen vom "Bundesamt für Sicherheit in der Informationstechnik" (BSI)
IT-Grundschutz-Kataloge (früher: IT-Grundschutzhandbuch)

- Fernwartung/Fernzugriff auf SPS-Anlagen/Maschinen gehört generell in die Gefährdungsanalyse/Risikobewertung der betreffenden Anlage!

- Siemens-Hinweis in den Handbüchern der IE-CPs:
"EG-Hinweis: Die Inbetriebnahme ist so lange untersagt, bis festgestellt wurde, dass die Maschine, in die diese Komponente eingebaut werden soll, den Bestimmungen der Richtlinie 89/392/EWG entspricht."

- Siemens-Hinweis zu "Mögliche Sicherheitslücken bei Standard-IT-Schnittstellen / Unerlaubte Zugriffe unterbinden"
"In verschiedenen SIMATIC-NET Komponenten (...) werden über offene Protokolle und Schnittstellen (...) Funktionen (..) zur Verfügung gestellt. Es kann nicht ausgeschlossen werden, dass diese offenen Protokolle und Schnittstellen durch Dritte unbefugt missbraucht werden können, z.B. für Manipulationen.
Bei Benutzung oben genannter Funktionen und Verwendung dieser offenen Schnittstellen und Protokolle (...) sind daher geeignete Sicherheitsvorkehrungen zu treffen, die den unerlaubten Zugriff auf die Komponenten bzw. das Netzwerk insbesondere aus dem WAN/Internet unterbinden.

Achtung
Wir weisen daher ausdrücklich darauf hin, dass Automatisierungsnetze durch geeignete Netzübergänge (z.B. die bewährten Firewall-Systeme) vom restlichen Firmennetz getrennt werden müssen. Wir übernehmen keine Haftung für Schäden, gleich aus welchem Rechtsgrund, die sich aus der Nichtbeachtung dieses Hinweises ergeben."

- weitere Hinweise siehe Siemens Systemhandbuch Kommunikation mit SIMATIC
Kapitel "2.4 Informationssicherheit in der Automatisierung" -> Schutzmaßnahmen

- Das Zielsystem ist vor Eingriffen unbedingt eindeutig zu identifizieren!
- (durch Bausteinvergleich, ggf. zusätzlich CPU-Passwort, Zielsystem -> Baugruppenzustand, ...)

Die Anlage, die ferngewartet werden soll, ist nicht nur vor unerlaubten Fremdzugriffen zu schützen, sondern der Programmierer, der einen "erlaubten" Fernzugriff vornimmt, muß sich auch selber schützen vor versehentlichem Zugriff auf falsche/fremde SPS-Anlagen.
Der (versehentliche) Zugriff auf falsche/fremde SPS-Anlagen kann verheerende Auswirkungen haben, die bis zum Tod von Menschen führen können!

Es ist also alles zu unternehmen, was die Chance für einen versehentlichen Falschzugriff verringert.
z.B. sind die Zugangsadressen möglichst im Step7-Projekt oder in TeleService fest zu hinterlegen, um Tippfehler beim Verbindungsaufbau zu vermeiden.
Die Ziel-SPS sollten ein CPU-Passwort haben, jede CPU ein anderes Passwort!
(Das CPU-Passwort soll nicht unbedingt den Kunden von der SPS fernhalten, es dient hier mehr der Identifizierung.)

Fernzugriff projektieren bei Variante D) Port-Forwarding in der Kunden-Firewall

DELTALOGIC Support schrieb:

In Step7 tragen Sie in der Hardware Konfiguration der SPS (bzw. des MP) bei Ihnen im Projekt die IP-Adresse des Kunden ein (jetzt wohl 82.176.X.X) und versuchen anschließend die Verbindung aufzubauen als wäre das Gerät lokal im Netzwerk angeschlossen.

ACHTUNG! Die Hardware Parametrierung mit der geänderten IP-Adresse KEINENFALLS in die SPS (bzw. auf das MP) laden, ansonsten ist es nicht mehr ansprechbar und sie müssen es vor Ort wieder umparametrieren.

Zum Vergrößern anklicken....

Dieser Tip ist sachlich nicht ganz richtig (auch wenn er vielleicht funktionieren mag). Außerdem muß die IP-Adresse im Step7-Hardware-Konfig jedesmal angepaßt werden, wenn man abwechselnd mal von fern und mal direkt an der Anlage ist. Hier sind Tippfehler vorprogrammiert.

Um im Step7-Projekt die öffentliche IP-Adresse des Kundenzugangs korrekt und fest zu hinterlegen, muß einfach nur ein Ethernet-Router eingefügt werden (also eine Station, von der Step7 "weiß", daß sie die Pakete zwischen WAN und LAN routen wird).

Ein "Ethernet-Router" ist in Step7/NetPro einfach eine SIMATIC-Station mit 2 Ethernet-Anschlüssen und Routing-Fähigkeit (hier im Beispiel: SIMATIC 300-Station).



Man nehme eine routing-fähige CPU (z.B. CPU 314-1AG13) und 2 Ethernet-CPs (z.B. CP343-1EX11).
(die CPU sollte eine ganz einfache CPU sein, damit Step7 nicht womöglich spezielle Fähigkeiten des Routers interpretiert und nutzen will).
Der eine CP wird mit dem WAN (= Internet) verbunden und erhält die öffentliche IP-Adresse (hier 82.176.x.x),
der andere CP wird mit dem LAN (= Kunde-Firmen-Netzwerk) verbunden und erhält die lokale IP-Adresse des Kunden-Routers
(des Standard-Gateways in deren Firmen-LAN, hier 192.168.10.254).

Die Konfiguration muß und kann natürlich nicht in den realen Router geladen werden, die Station steht hier nur als Stellvertreter für den Firmenrouter/Firewall, um Step7 mitzuteilen, daß da ein Router ist und welche IP-Adressen der hat.

In der Hardware-Konfiguration der SPSen und des MP277 wird in der Regel eingestellt:
(x) Router verwenden, Adresse: 192.168.10.254 (hier im Beispiel)

Hinweis: Am MP277 muß die Konfiguration der Netzwerk-Schnittstelle manuell im Control-Panel vorgenommen werden, sie wird nicht von WinCCflexible eingestellt.

Die PG/PC-Schnittstelle im Programmierer-PC wird für Step7 und WinCCflexible so eingestellt:
S7ONLINE (STEP7) --> TCP/IP -> <name_netzwerkkarte_programmier-pc>

Wenn man nun mal von fern und mal direkt an der Anlage ist und Step7 nicht automatisch den richtigen Weg zur SPS erkennen sollte, dann empfiehlt es sich, noch ein "PG/PC" in NetPro einzufügen und dieses "PG/PC" dem jeweiligen Netzwerk "zuzuordnen", an dem der Programmierer-PC gerade angeschlossen ist (die dicke gelbe Linie im Bild).

Nun sollte es kein Problem sein, auf alle in NetPro dargestellten SPS und Panels zuzugreifen.

Hinweis: WinCCflexible unterstützt erst ab der Ausgabe 2008 einen gerouteten Zugriff auf ein Panel, wenn die erste Strecke vom PG/PC zum Panel vom Typ Ethernet ist (bei den älteren WinCCflexible-Versionen muß die erste Strecke MPI oder Profibus sein, oder ein "PC-Adapter" gauckelt WCf vor, es wäre direkt an MPI oder Profibus angeschlossen).

Nachtrag: Step7-Beispielprojekt zu diesem Beitrag

Step7-Beispielprojekt mit Router-Stellvertreter

Hier das Step7-Beispielprojekt zum Beitrag #15 Fernzugriff projektieren bei Variante D) Port-Forwarding in der Kunden-Firewall
(ohne das MP277 - schon ein leeres WinCCflexible-Projekt ist bekanntlich reichlich 1MB groß ;-) )

Wie kann ich den Router aus dem Beispielprojekt in mein Projekt übernehmen?

1. die Objekte "Router/Firewall [Fa.xyz]" + "Ethernet(LAN)" + "Ethernet(WAN)" ( + "PG/PC") markieren
2. Bearbeiten -> Kopieren (wichtig: alle auf einmal, damit die Verknüpfungen erhalten bleiben)
3. ins eigene Projekt wechseln (in die oberste Ebene vom Projektbaum)
4. Bearbeiten -> Einfügen
5. Nun noch mit HW Konfig die projektspezifischen Einstellungen anpassen:
* "Router/Firewall [Fa.xyz]"
--- den Stationsname "Router/Firewall [Fa.xyz]" in was projektspezifisch-sinnvolles umbenennen
--- CP IE (WAN): die öffentliche IP-Adresse des Kunden eintragen
--- CP IE (LAN): die IP-Adresse des lokalen Standard-Gateway des Kunden eintragen
* "eigene" SPS-Station
--- IE-CP (oder PN-IO-Schnittstelle bei PN/DP-CPUs) mit "Ethernet(LAN)" vernetzen
--- gewünschte IP-Adresse eintragen in IE-CP oder PN-IO-Schnittstelle
--- (x) Router verwenden + IP-Adresse des für die SPS-Station gültigen Standard-Gateway eintragen
* "Ethernet(LAN)" und "Ethernet(WAN)"
--- falls nötig, die S7-Subnetz-IDs ändern mit NetPro
* in NetPro "Alles übersetzen" und die Konfiguration mit NetPro (!) in die "eigene" SPS-Station laden
* bei Bedarf im "PG/PC" die Schnittstellen konfigurieren und parametrieren und das "PG/PC" einem Netz zuordnen

Hinweis 1: HW Konfig lädt die Routing-Tabellen (SDB999) NICHT mit in die SPS-Station, das macht nur NetPro vollständig.
Bei mehreren SPS-Stationen und ggf. mehreren Netzwerken im Projekt sind die Routing-Tabellen aber wichtig.

Hinweis 2: Man sollte sich frühzeitig Gedanken über sinnvolle Stationsnamen machen, weil die Stationsnamen (je nach CPU)
mit in die Station geladen werden. Ändert man später den Stationsname, dann hat man unterschiedliche Systemdaten
(CPU-Konfigurationen) Online<->Projekt.

Hinweis 3: An Panels muß die Konfiguration der Netzwerk-Schnittstelle manuell im Control-Panel vorgenommen werden,
sie wird nicht von WinCCflexible eingestellt.

Hinweis 4: Die tatsächliche Netzwerk-Konfiguration beim Kunden wird sich von diesem Beispiel unterscheiden.
Die zu verwendenden IP-Adressen mit dem Kunden-IT-Administrator absprechen!

Hinweis 5: In der "eigenen" SPS-Station "(x) Router verwenden" bzw. im Panel "Default Gateway":
Wenn keine Gateway-Adresse eingetragen wird, dann können die SPS-Stationen nur im gleichen Netzwerk-Segment miteinander
kommunizieren, die SPS-Stationen bzw. Panele sind aus anderen Netzwerk-Segmenten oder von fern normal nicht erreichbar.
Auf dem Step7-PC kann zwar hilfsweise eine statische Route mit "route add ..." eingerichtet werden, das geht aber nicht über das
Internet.

Hinweis 6: Solange man nur von fern auf die SPS-Station oder Panels beim Kunden zugreifen will, ist es egal, welche IP-Adresse
man bei "CP IE (LAN)" einträgt. Es sieht aber in der Dokumentation besser aus, wenn man da was sinniges einträgt.
Zumindest ist diese Stelle ein guter Merkzettel.

Step7 RFC1006

Hallo DELTALOGIC Support,

leider konnte ich nicht eher auf Ihre Fragen antworten. Ich hoffe, meine späte Antwort ist noch von Interesse.

DELTALOGIC Support schrieb:

Können Sie mir da bitte ein Beispielprojekt schicken?

Zum Vergrößern anklicken....

siehe Posting #22

DELTALOGIC Support schrieb:

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?

Zum Vergrößern anklicken....

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

Hier noch eine ergänzung aus dem Siemens FAQ:
http://support.automation.siemens.c...cslib.csinfo&lang=de&objid=38571711&caller=nl