TIA Serieninbetriebnahme im TIA-Umfeld / Rollout von Software-Updates

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

ich beschäftige mich seit einiger Zeit mit dem Thema Serieninbetriebnahme im Umfeld von TIA.

Ich habe folgende Konstellation:
Serienmaschine mit CPU 1512SP F und Visu KTP400 Basic 2. Generation. Zudem einige Profinet-Devices inkl. Safety.
Für die gesamte Serie wird nur 1 TIA-Projekt mit 1 projektierten CPU angelegt. Seriengröße aktuell zwischen 3 und 90 Stk.

Jede Maschine benutzt lokal das gleiche 192.168.x.x Netz, mit der Außenwelt wird mittels NAT-Router kommuniziert. Von außen besitzt das Ding nur 1 IP-Adresse, und wir bekommen auch nicht mehr. Die CPU ist über NAT und TCP-Port 102 von außen erreichbar.

Nun zu meinem Problem:
Aktuell häufen sich die Anlagen mit sehr hohen Stückzahlen (> 30) und der Problematik, dass während der Inbetriebnahme häufig Software-Updates (sowohl CPU als auch Panel) ausgerollt werden müssen. Bis dato werden diese Updates auf 2 Arten ausgerollt:
1. der Inbetriebnehmer geht zu jeder Maschine hin, stöpselt sich mit seinem PG an und spielt das Programm ein. Der Nachteil an der Sache ist, dass es vorkommen kann, dass einzelne Stationen vergessen werden und dass der Inbetriebnehmer schon mal 2 Tage in der Anlage unterwegs ist nur für so ein Update. Dass das TIA-Portal manchmal mitten drinnen zickt, wenn man das Netzwerk-Kabel aus- und wieder einstöpselt kommt auch noch dazu.
2. der Inbetriebnehmer hängt sich zentral ins Anlagennetzwerk und gibt die öffentliche IP-Adresse der Maschine jedes mal im TIA-Portal ein wenn er sich online verbindet. Dass TIA typischerweise mindestens 30 Sekunden unbedienbar ist während es die Steuerung online sucht, ist nur ein Nachteil. Dass man nicht bei jedem Kunden ins Anlagennetzwerk kommt steht auf einem anderen Papier. Typisch ist die Online-Verbindung über den NAT-Router auch nicht die schnellste - alles in allem eine zähe Geschichte. Panel einspielen geht auf diesem Weg faktisch gar nicht, da WinCC mittlerweile auch den TCP-Port 102 zum Transfer nutzt - ich bräuchte also eine zweite öffentliche IP-Adresse, was per se nicht geht.

Ich bin nun auf der Suche nach einer Möglichkeit, um solche Updates sinnvoll in Serie ausrollen zu können - am besten automatisch.
Mit dem Automation Tool habe ich schon viel getestet, hier scheitere ich an 2 konkreten Problemen:
a. es ist nur dann sinnvoll einsetzbar, wenn für jedes Gerät hinter dem NAT-Router auch eine öffentliche IP-Adresse vorhanden ist - was ja in meinem Fall ausgeschlossen ist
b. die NAT-Unterstützung ist nur halbherzig gemacht. Es ist nicht möglich, 2 CPUs mit der gleichen IP-Adresse anzulegen, obwohl sie hinter unterschiedlichen NAT-Routern sitzen

Ich hab mir mit Wireshark auch die Mechanismen des Automation Tool genauer angesehen. Prinzipiell ließe es sich austricksen, wenn man die SNMP-Anfragen abfängt und für das Automation Tool befriedigend beantwortet - schön ist das aber nicht.


Kann mir noch jemand einen Denkanstoß geben, wie ich das Ausrollen eleganter bewerkstelligen kann?
Der Inbetriebnehmer ist bei einer solchen Aktion vor Ort und kann sich auch ins Kundennetz einklinken, so dass alle Maschinen miti ihrer "Außenwelt"-IP-Adresse direkt erreichbar sind.

lg


PS: dass man beim automatischen Ausrollen auf Begrifflichkeiten wie Safety und Security Rücksicht nehmen muss, ist mir bewusst und soll hier nicht disktiert werden.

 

[blackpeat]

Interessantes Thema werde ich verfolgen, wir bauen auch Serienanlagen aber machen das immer über die SD Karte.

Weil unterschiedliche Servicetechniker und allen TIA oder die anderen Tools beizubringen nicht klappt. Außerdem ist es etwas einfacher im Handling weil per Mail oder so verschickbar.

Aso laden per Openess könnte gehen, wenn ihr keine Safety drin habt.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Interessantes Thema werde ich verfolgen, wir bauen auch Serienanlagen aber machen das immer über die SD Karte.

Die Variante scheidet leider aus, da auf der Speicherkarte statistische Daten gespeichert werden, die damit verloren gehen. Außerdem verschiebt sich damit ein Gutteil der Arbeit vom Inbetriebnehmer zum Programmierer.

Weil unterschiedliche Servicetechniker und allen TIA oder die anderen Tools beizubringen nicht klappt. Außerdem ist es etwas einfacher im Handling weil per Mail oder so verschickbar.

Das Problem stellt sich bei uns so nicht, da es wirklich nur bei der Inbetriebnahme außer Haus relevant ist, und das sind nur eine Handvoll Leute.

Aso laden per Openess könnte gehen, wenn ihr keine Safety drin habt.

Safety ist ein Thema.
Für Openness fehlt mir aktuell der C#-affine Programmierer. Und im Openness Scripter sind die ganzen Online-Funktionen nicht verfügbar.

 

[ducati]

Panel einspielen geht auf diesem Weg faktisch gar nicht, da WinCC mittlerweile auch den TCP-Port 102 zum Transfer nutzt - ich bräuchte also eine zweite öffentliche IP-Adresse, was per se nicht geht.

Hmm, meine Idee war da mal, den Router mit im TIA-Projekt zu haben (als Dummy, S615 oder sowas)

Dann sollte man ja SPS und Panel in dem unterlagerten Netz erreichen können...

Habs aber noch nicht weiterverfolgt...

Gruß.

 

[Fluffi]

Ich konnte nicht richtig herauslesen ob es jetzt um die Serieninbetriebnahme im eigenen Haus oder um Updates dieser Anlagen beim Kunden geht, aber vor allem wenn es sich um letzteres handelt, ist sicher VPN die Wahl der Dinge. Klar, das kostet dann was, wenn auch heutzutage nicht mehr so viel, aber da muss man sich um NAT, Port Forwarding und Netzwerktricksereien keine Gedanken mehr machen.
Ansonsten könnte man wie hier in einem Beitrag aus dem Forum beschrieben um das Port Problem zu umgehen, den Port vor dem Übertragen der HMI mit netsh auf einen anderen Port umleiten um dann wiederum vom NAT-Router aufs Panel zu kommen. Ist aber auch nicht schön und weit weg von einer Automatisierung.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hmm, meine Idee war da mal, den Router mit im TIA-Projekt zu haben (als Dummy, S615 oder sowas)
Dann sollte man ja SPS und Panel in dem unterlagerten Netz erreichen können...
Habs aber noch nicht weiterverfolgt...
Gruß.

Interessanter Ansatz, aber:
Egal wie sehr ich mich da mit den diversen Router-Modell im Hardware-Katalog spiele, ich schaffe es nicht dass ich beim Online-gehen ein anderes Netzwerk als das LAN der Maschine auswähle. "Routing" funktioniert nur, wenn quasi eine CPU "Gateway" spielt. Dann bin ich halt wieder beim klassischen S7-Routing was mir nicht weiterhilft.

 

[maxder2te]

Ich konnte nicht richtig herauslesen ob es jetzt um die Serieninbetriebnahme im eigenen Haus oder um Updates dieser Anlagen beim Kunden geht, aber vor allem wenn es sich um letzteres handelt, ist sicher VPN die Wahl der Dinge. Klar, das kostet dann was, wenn auch heutzutage nicht mehr so viel, aber da muss man sich um NAT, Port Forwarding und Netzwerktricksereien keine Gedanken mehr machen.

Ja, es geht eher um letzteres. Bei der Erstinbetriebnahme im Haus muss man so oder ran.

Das mit den Kosten sehe ich prinzipiell nicht als Problem. Unser Gateway kommt nicht von Siemens und die Firmware ist bereits VPN-tauglich. Ich kann mich damit auf Layer 2 Ebene mit dem Stationsnetz verbinden, das klappt auch soweit. Ich kann in dieser Situation halt nur genau diese eine Station einspielen.

Es läuft halt darauf hinaus, dass ich pro Station eine VPN-Verbindung anlegen muss und einen Mechanismus bauen muss, der mir der Reihe nach die folgenden Arbeitsschritte durchführt:
1. VPN-Tunnel aufbauen
2. SPS einspielen
3. Visu einspielen
4. VPN-Tunnel abbauen
Das ganze x mal für x Maschinen.

Der Wunsch ist eigentlich (und da kam das Automation Tool ins Spiel), das ganze auf Knopfdruck in Serie und ggf. parallellisiert durchzuführen.

Der VPN-Weg ist halt ein rein serieller und man muss sich entsprechend selbst drum kümmern dass alle Maschinen upgedated werden und das ganze protokollieren. Baut man sich dazu ein Skript und nutzt auch die Skripting-API des Automation Tool oder TIA Openness, wäre diese Weg gangbar. Ich brauche halt eine C#-Entwickler dazu, den ich aktuell nicht habe.

Ansonsten könnte man wie hier in einem Beitrag aus dem Forum beschrieben um das Port Problem zu umgehen, den Port vor dem Übertragen der HMI mit netsh auf einen anderen Port umleiten um dann wiederum vom NAT-Router aufs Panel zu kommen. Ist aber auch nicht schön und weit weg von einer Automatisierung.

Das funktioniert in der Theorie ganz gut und hab ich so auch schon mit einzelnen Panels zum laufen gebracht. Das Automation Tool kann mit dieser Variante gar nicht, da es mit dem Loopback-Adapter nicht klarkommt. Verwendet man zum Umleiten statt dem Loopback-Adapter und netsh einen Router (in meinem Fall hab ich einen solchen als VM mit Debian und iptables aufgebaut), so dass das Automation Tool direkt auf eine Netzwerkkarte zugreifen kann (VMNet), dann klappt das prinzipiell, ist aber krötenlangsam. Der Grund dürfte hier an COTP liegen, die TCP-Pakete werden jeweils vom Router direkt quittiert und dann kommt das Protokoll regelmäßig aus dem Tritt. Ich hab da nicht weiter geforscht, weil ich ohnehin an der ungeschickten NAT-Unterstützung gescheitert bin.

 

[JesperMP]

Die automatische Update von X Anzahl entfernte Steuerungen finde ich problematisch.
Für Safety und Security muss bei jeden Zugang die Erlaubniss von die Kunden eingeholt werden. Ich sehe nicht wie dies mit eine automatische Update kombiniert werden kann.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die automatische Update von X Anzahl entfernte Steuerungen finde ich problematisch.
Für Safety und Security muss bei jeden Zugang die Erlaubniss von die Kunden eingeholt werden. Ich sehe nicht wie dies mit eine automatische Update kombiniert werden kann.

Fürs Protokoll: Es geht hier nicht um Security-Betrachtungen und darum, Gründe zu finden, warum man eine solche Lösung nicht suchen oder finden soll. Solche Diskussionen führe ich mit Kollegen von Siemens oft genug, wenn mir wieder mal jemand erklärt, dass eine fehlende Funktion ein Feature ist bla bla bla bla.......
Das Thema Security ist mir bewusst und soll meine Sorge sein, das muss ich mit meinen Kunde klären. Um in solche Klärungen gehen zu können brauche ich aber zuerst eine funktionierende Lösung.

Zurück zum Thema: ich vergaß wohl in meiner Themenstellung ein paar Informationen anzugeben, ich werde das anschließen gleich noch tun:
a. es geht nicht darum, ein Update "von der Ferne" einzuspielen. Der Inbetriebnehmer ist vor Ort.
b. es geht darum, updates WÄHREND der Inbetriebnahme und VOR der Abnahme auszurollen.
c. es ist selbstverständlich, dass für safety-relevante Dinge zuerst eine komplette Typprüfung durchgeführt wird, bevor hier ein Update ausgerollt wird.

 

[Oest]

Hallo,

wir haben ähnliche Anlagen, mit vielen Siemens CPU und diversen HMI (auch non Siemens).
Bei uns haben alle CPU die gleiche IP. Das umschalten wird in einem programmierten Router gemacht. Der leitet sowohl die PGs als auch die HMIs auf den richtigen Pfad.
Das die gleiche Funktion über Siemens Bordmittel zu erreichen ist, halte ich für ausgeschlossen.
Allerdings muss man trotzdem beim Laden jede (virtuelle) IP einzeln ansprechen.

Eine Möglichkeit, um CPUs "in a row" zu laden, habe ich bisher noch nicht gesehen. Wäre schon eine schöne Sache.
Vielleicht lässt sich Siemens ja überreden, die Möglichkeit im TIA bereitzustellen. Sowas wie erweitertes Laden von GerätEN.

Das Laden der Siemens Panels ist etwas umständlicher. Ich habe das nur hinbekommen, indem ich das KTP als Ethernet Gerät konfiguriert habe, und dann über erweitertes Laden direkt auf die Panel IP geladen. Dazu muss noch der Port 5002 zusätzlich zum 102 frei sein.
Wireshark hat noch einen Port ausgespuckt den ich vergessen habe, aber bisher habe ich nicht herausgefunden, wozu der nötig ist.

 

[maxder2te]

Hallo,

wir haben ähnliche Anlagen, mit vielen Siemens CPU und diversen HMI (auch non Siemens).
Bei uns haben alle CPU die gleiche IP. Das umschalten wird in einem programmierten Router gemacht. Der leitet sowohl die PGs als auch die HMIs auf den richtigen Pfad.
Das die gleiche Funktion über Siemens Bordmittel zu erreichen ist, halte ich für ausgeschlossen.
Allerdings muss man trotzdem beim Laden jede (virtuelle) IP einzeln ansprechen.

Eine Möglichkeit, um CPUs "in a row" zu laden, habe ich bisher noch nicht gesehen. Wäre schon eine schöne Sache.
Vielleicht lässt sich Siemens ja überreden, die Möglichkeit im TIA bereitzustellen. Sowas wie erweitertes Laden von GerätEN.

Das Laden der Siemens Panels ist etwas umständlicher. Ich habe das nur hinbekommen, indem ich das KTP als Ethernet Gerät konfiguriert habe, und dann über erweitertes Laden direkt auf die Panel IP geladen. Dazu muss noch der Port 5002 zusätzlich zum 102 frei sein.
Wireshark hat noch einen Port ausgespuckt den ich vergessen habe, aber bisher habe ich nicht herausgefunden, wozu der nötig ist.

Danke, das ist ein erfrischender Beitrag und eine typischer Ernüchterung im Siemens-S7 Umfeld.
Unsere Kollegen im Embedded Echtzeit-Linux Bereich haben's da echt schön. Der startet sein Skript und rollt alles per SSH massenhaft aus.........

Eine Möglichkeit, um CPUs "in a row" zu laden, habe ich bisher noch nicht gesehen. Wäre schon eine schöne Sache.
Vielleicht lässt sich Siemens ja überreden, die Möglichkeit im TIA bereitzustellen. Sowas wie erweitertes Laden von GerätEN.

Das kann ich mir ehrlich gesagt nicht vorstellen. Da wird Siemens sicher auf das Konzept "mehrfach verwendbare Profinet-IO-Systeme" hinweisen.
Das wäre zwar technisch machbar, ist für uns aber so nicht handlebar.

Das Laden der Siemens Panels ist etwas umständlicher. Ich habe das nur hinbekommen, indem ich das KTP als Ethernet Gerät konfiguriert habe, und dann über erweitertes Laden direkt auf die Panel IP geladen. Dazu muss noch der Port 5002 zusätzlich zum 102 frei sein.
Wireshark hat noch einen Port ausgespuckt den ich vergessen habe, aber bisher habe ich nicht herausgefunden, wozu der nötig ist.

Gehe ich recht in der Annahme, dass das Panel nach außen (also vor dem Router) eine eigene IP-Adresse besitzt?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke, das ist ein erfrischender Beitrag und eine typischer Ernüchterung im Siemens-S7 Umfeld.
Unsere Kollegen im Embedded Echtzeit-Linux Bereich haben's da echt schön. Der startet sein Skript und rollt alles per SSH massenhaft aus.........

Die Skripte unter Linux schreiben sich aber auch nicht von selbst. Und so wie du schreibst, sind in TIA-Openess die Funktionen die du benötigst vorhanden, dir fehlt aber das Wissen um das anzuwenden. Das ist dann aber kein Siemens-Problem.

 

[maxder2te]

Die Skripte unter Linux schreiben sich aber auch nicht von selbst. Und so wie du schreibst, sind in TIA-Openess die Funktionen die du benötigst vorhanden, dir fehlt aber das Wissen um das anzuwenden. Das ist dann aber kein Siemens-Problem.

Naja, einen Ansatzpunkt für das Spiel "bashen wir den TE wegen seiner Inkompetenz" wird man in diesem Forum immer finden, zumindest immer dann wenn er was von Siemens möchte.....
Hast du was nützliches zum Thema, dann nur raus damit

 

[Thomas_v2.1]

Wenn den automatisierten Download aber nur die Openess-Schnittstelle anbietet, dann wirst du wohl nicht darum herumkommen diese auch zu verwenden. Es muss ja nicht C# sein, Vb.Net wäre auch möglich. Ich habe so etwas bei Step7 mit der Kommandoschnittstelle schon gelöst, aber bei Step7 Classic war vieles einfacher.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn den automatisierten Download aber nur die Openess-Schnittstelle anbietet, dann wirst du wohl nicht darum herumkommen diese auch zu verwenden. Es muss ja nicht C# sein, Vb.Net wäre auch möglich. Ich habe so etwas bei Step7 mit der Kommandoschnittstelle schon gelöst, aber bei Step7 Classic war vieles einfacher.

jaja: "früher war alles einfacher".

Ich fins nur schade: Siemens bietet ein Automation Tool an, welches genau das kann was ich will. Nur weil irgendein Produktmanager oder ein Automotive-Kunde da ein "Feature" rein reklamiert hat, das mein IP-Anwendung verhindert, ists unbrauchbar. Es würde aber reichen, im Quellcode von diesem Tool aus

if (isUnique(device.ipAddr)) { .... }

auf

if ((isBehindNatRouter(device) && isUnique(natRouter.ipAddr)) || (isUnique(device.ipAddr))) { .... }

zu machen, und dann wären wir alle glücklich.

Nein, Siemens baut eine OpenNess-API, für die man einen Informatik-Abschluss benötigt, um zu irgendwas zu kommen. Nachdem faktisch niemand den Mist verwendet, lassen wir uns einen OpenNess-Skripter für die dummen SPS-Programmierer einfallen, mit dem man etwas skripten kann. Weil man aber keinen Entwicklungsaufwand in eine vernünftige Skript-Engine stecken will, setzt man nur 12% der Funktionalität der vollständige API in die Skript-Engine um und verkauft das als "Für die meisten Anwendungen ausreichend".

dann wirst du wohl nicht darum herumkommen diese auch zu verwenden

Ich erinnere mich an dieser Stelle noch gut an einen Herrenn auf der SPS in Nürnberg, den ich kurz nach Erscheinen der Sinamics S120 ein bisschen technisch auf den Zahl gefühlt hab, und er ist irgendwann ans Ende seines Wissens gekommen und hat mir lapidar geantwortet: "Diese Funktion wird schon noch rein kommen. Bald wird ihnen der Kunde ohnehin diese Antriebe vorschreiben, dann werden sie ohnehin nicht darum herumkommen, sich damit auseinanderzusetzen".
Gegen solche Aussagen bin ich halt wahnsinnig empfindlich.


Also nochmal:
Bitte konstruktiv diskutieren, ich bin für konstruktive Vorschläge offen.
Wenn Openness die einzige Möglichkeit ist, sowas umzusetzen, dann werde ich mich um einen Mitarbeiter mit C#-Kenntnissen umsehen müssen.
Mir wäre es halt lieber, wenn noch andere Wege aufgezeigt werden.
Und ich bin halt verwöhnt, wenn man von Linux kommt, wo jedes Programm alle Funktionen als Kommandozeilenparameter zur Verfügung stellt und man mit bash sehr schnell ans Ziel kommt - und dann einfach den Kommandoverlauf in ein Skript kopiert.....

 

[Thomas_v2.1]

Mit gefällt Openess auch nicht, aber was will man machen. Ich habe mir schon einmal überlegt eine Python Schnittstelle drumherum zu bauen die auch ohne erst groß C#-Projekte zu erstellen für Kleinigkeiten verwendbar ist. Für deinen Anwendungsfall reicht ja ein einfaches Projekt öffnen und Download, da lasse dir doch eine kleine Konsolenanwendung von jemanden schreiben der genau diese zwei Dinge macht.

Das mit den IP-Adressen sehe ich als kleineres Problem an und ist garantiert lösbar, sei es mit dem Portproxy, oder was ich auch schon einmal gemacht habe, ist im Anlagennetz einen SSH-Server zu haben, auf dem PG einen Loopbackadapter mit der IP-Adresse der SPS und dann über einen SSH-Tunnel (unter Windows mit Putty) Port 102 durch den Tunnel zu schicken. Da lässt sich auf Client-Seite angeben zu welcher Zieladresse das aus dem Tunnel wieder "herauskommt". Alles skriptbar ggf. über Batch oder Powershell.

 

[Glon]

Ich weiß nicht ob es schon gesagt wurde, aber das Simatic Automation Tool unterstützt ab Version 4 in der Advanced Variante Geräte hinter NAT Routern.

https://support.industry.siemens.co...nd-wartung-von-simatic-geräten?dti=0&lc=de-DE

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich weiß nicht ob es schon gesagt wurde, aber das Simatic Automation Tool unterstützt ab Version 4 in der Advanced Variante Geräte hinter NAT Routern.

https://support.industry.siemens.co...nd-wartung-von-simatic-geräten?dti=0&lc=de-DE

Wurde schon.

Mit dem Automation Tool habe ich schon viel getestet, hier scheitere ich an 2 konkreten Problemen:
a. es ist nur dann sinnvoll einsetzbar, wenn für jedes Gerät hinter dem NAT-Router auch eine öffentliche IP-Adresse vorhanden ist - was ja in meinem Fall ausgeschlossen ist
b. die NAT-Unterstützung ist nur halbherzig gemacht. Es ist nicht möglich, 2 CPUs mit der gleichen IP-Adresse anzulegen, obwohl sie hinter unterschiedlichen NAT-Routern sitzen

Ich hab mir mit Wireshark auch die Mechanismen des Automation Tool genauer angesehen. Prinzipiell ließe es sich austricksen, wenn man die SNMP-Anfragen abfängt und für das Automation Tool befriedigend beantwortet - schön ist das aber nicht.

Danke für nichts.

 

[Glon]

Okay dann Entschuldigung.

Ich dachte V4 ist noch relativ neu (19.08.2020) und du hattest vll. noch eine alte Variante getestet.

Dann noch gutes gelingen!

 

[ducati]

Wir haben da früher auch schon mit Portmappern etc. Sachen gebaut... Grundsätzlich ist das aber auch alles mit Vorsicht zu genießen. Habens auch schon Leute geschafft, die falsche SPS zu laden

Oder ne VPN-Verbindung zum falschen Werk aufzubauen

Machnmal ists auch einfach besser, durchs Werk zu laufen und einzeln zu Laden. Oder halt nen eigenen Automaisierungsnetz aufzubauen...

Gruß.