TIA S7-1500 http-basierte Schnittstellen mit https am Horizont

Semo

Level-2
Beiträge
133
Reaktionspunkte
51
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

wir erhalten in letzter Zeit immer mehr Anfragen mit Kunden-Schnittstellen, welche informationen per http-post/get austauschen.
Die Informationen werden mal als html/XML oder json (teils REST) ausgetauscht.

Bei größeren Projekten haben wir dies immer auf einem Rechner als Gateway realisiert, da dieser sowieso vorhanden war. (Eigene SW oder RT)
Nun kommen aber immer mehr kleinere Projekte Richtung kleine S7-1500sp oder gar S7-1200 daher.

Die Schnittstellen auf der SPS direkt umzusetzen ist erstmal kein Problem, solange es wirklich nur HTTP ist.
In einem Projekt hat sich nun ergeben, dass eigentlich HTTPS gemeint war.

Dies wurde nun erst einmal geblockt, bzw. wird geklärt, da wir glücklicherweise noch nicht in der Realisierung angekommen sind.

So weit so gut.
Mir stellt sich nun jedoch die Frage, was eigentlich passiert wenn in diesen kleinen Projekten der Kunde seine Seite auf HTTPS umstellt.
Aus IT-Sicht kann des ja sowohl ein nötiger Schritt sein und vom Aufwand zu überschauen.

Auf der S7 sehe ich auf Anhieb aber keine Möglichkeit, mal eben SSL Verschlüsselung zu integrieren, solange dies nicht mit Bordmitteln ermöglicht wird.
Außerdem sehe ich hier eine unötige Diskusion auf uns zu kommen, da der Unterschied zwischen HTTP/HTTPS für die meisten sicher nicht gewaltig erscheint.
Übersehe ich hier eventuell etwas?

Falls nicht, wie geht ihr damit um?


Gruß Semo
 
Siemens stellt die Funktion für https über tls bereit, in dieser Bibliothek:

Die Bibliothek auch für CPs gilt, könnte hier sogar unabhängig der Steuerung gearbeitet werden.

Habt ihr schon mal die Wirtschaftlichkeit überprüft, euch ein Edge Device mit den Schaltkasten zu hängen. Zb ein Iot2050 der dann den https Kram erledigt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Siemens stellt die Funktion für https über tls bereit, in dieser Bibliothek:

Die Bibliothek auch für CPs gilt, könnte hier sogar unabhängig der Steuerung gearbeitet werden.

Habt ihr schon mal die Wirtschaftlichkeit überprüft, euch ein Edge Device mit den Schaltkasten zu hängen. Zb ein Iot2050 der dann den https Kram erledigt?
Das https in der LCOM habe ich glatt übersehen. :unsure:Dann kann ich mir ja theoretisch nen Test-Server aufsetzen um das zu testen.

Thema Wirtschaftlichkeit ist so eine Sache. Wenn wir nen IPC/Server/VM dabei haben bräuchten wir es halt nicht. Und grade wenn in einem Projekt jeder Cent umgedreht wird, müsste man rechtfertigen, wozu jetzt der Rechner da ist. Imho würde das ab und an auch beim Kunden schwierig werden. (IT/OT/IPSec)
Ist bei uns halt auch bei so gut wie jedem Projekt anders. (Vertrieb vs. Kundenvorgaben vs. Konstruktion) :geek:
 
Wenn es mit der Bib geht, wäre es ja natürlich top!

Ansonsten wäre wohl die Idee sich mal mit edge devices zu beschäftigen auch eine Option, natürlich muss sich da wieder jemand reinfuchsen bis die Person sich gut genug auskennt, könnte aber helfen den unterschiedlichen Projektanforderungen flexible Lösungen anbieten zu können ohne das sich das Hauptgerüst ändert. Muss ja kein edge device von Siemens unbedingt sein.
 
Hallo Zusammen,

Das doch aus meiner Sicht gar nicht so einfache Händling mit den Zertifikaten ist in diesem Siemens FAQ recht gut beschrieben. https://cache.industry.siemens.com/...3879_Telegram_PushNotification_DOC_V10_de.pdf

Wichtig ist unbedingt die aktuellste CPU Firmware installieren ( auch wenn es das eigene Tia nicht kann) ich habe es bei unter 2.9 leider noch nicht geschafft auf einer 1500er eine Verbindung zu bekommen.
Was es noch zu erzählen gibt der Verbindungsaufbau dauert bei allen unter 1518 ungefähr 300ms was je nach Anwendung doch recht lang sein kann.

Gruß Tia
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...
Was es noch zu erzählen gibt der Verbindungsaufbau dauert bei allen unter 1518 ungefähr 300ms was je nach Anwendung doch recht lang sein kann.
...
300ms? Uff, das wäre tatsächlich nen KO Punkt bei den meisten Entscheidungsstellen.
Hab ab nächster Woche mal ne kleine 1500sp+CP da.
Werde das Testen und berichten.
 
Hallo Semo,

Je nachdem wie lange der Time Out auf der Gegenseite kannst du die Verbindung aufbauen und dann offen halten. Aber ohne Telegramme läufst du meist nach 10sec in einen Time Out.

Gruß Tia
 
Wenn es mit der Bib geht, wäre es ja natürlich top!

Ansonsten wäre wohl die Idee sich mal mit edge devices zu beschäftigen auch eine Option, natürlich muss sich da wieder jemand reinfuchsen bis die Person sich gut genug auskennt, könnte aber helfen den unterschiedlichen Projektanforderungen flexible Lösungen anbieten zu können ohne das sich das Hauptgerüst ändert. Muss ja kein edge device von Siemens unbedingt sein.

Ich würde hier auch IoT-Gateways den Vorzug geben.
REST, JSON, MQTT macht auf einer S7 nicht wirklich Spaß.
Da sind dann IoT-Gateways mit Node RED die deutlich bessere Wahl.
Da kannst du die Daten holen und dann per S7-Protokoll oder OPC UA mit der S7 austauschen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Semo,

Je nachdem wie lange der Time Out auf der Gegenseite kannst du die Verbindung aufbauen und dann offen halten. Aber ohne Telegramme läufst du meist nach 10sec in einen Time Out.

Gruß Tia
Das geht in einigen Fällen evtl. aber die Leute gelesene Spec mit Rest hatte sogar ne Anforderung die Verbindung nicht offen zu lassen.

Ich verstehe allerdings auch nicht, wo die Verzögerung herkommen soll.
Es sei denn, der erfolgreiche Aufbau wird zu spät erkannt. Warum das auf dem CPUs unterschiedlich lange dauern soll weil mir nicht einfallen. Die Verbindung ist ja nach wie vor TCP und das funktioniert nach meinen Erfahrungen nur auf der 1507S schneller als auf allen anderen, wenn man den die Interne 'virtuelle' Schnittstelle mit dem IPC nutzt.

Einen Unterschied selbst zwischen 1511 und 1518 habe ich bisher noch nie feststellen können.
Bin mal gespannt was da passiert.
 
Hallo Semo,

Frage hast du HTTP oder HTTPS benutzt?
Ich würde den Grund mal im Bereich der Leistungsfähigkeit der CPUs ansiedeln. Soweit ich weiß ist ja auch der Hauptgrund warum die neuen 1516 und 1515 nun einen 2ten Core bekommen haben.

Gruß Tia
 
Habe jetzt erste Tests machen können.
Erstmal ganz simpel mit dem eigenen Siemens Webserver per LHTTP_Get und _Post.
Mit https hat auf die schnelle gar nichts geklappt.
Bekomme immer einen 16#8601 (Verweis auf den internen TSEND_C mit 16#80C5 (Verbindung durch den Kommunikationspartner abgebaut. / LSAP des remoten Verbindungspartners nicht freigegeben).
Hab ich mal auf morgen geschoben und erstmal per http weitergetestet.

Da habe auch ein interessantes Problem.
Ohne jeden Fehler (Done/RCode=200) bekomme ich ab und an nur die erste Zeile (im Beispiel 19 Zeichen) in das responseData Array kopiert.
Zur Laufzeit dauert ein Durchlauf mit Fehler (19 Zeichen) ca. 105 ms, einr ohne Fehler (ca. 3700 Zeichen) dauerte gut 165 ms.

Das Opfer ist eine S7-1514SP-F-2PN mit einer mittleren Zykluszeit von 0,8 ms.

Bin mal gespannt ob ich https morgen zum laufen bekomme, bevor der Mock-Server läuft. :unsure:
 
Da habe auch ein interessantes Problem.
Ohne jeden Fehler (Done/RCode=200) bekomme ich ab und an nur die erste Zeile (im Beispiel 19 Zeichen) in das responseData Array kopiert.
Ich habe mir die Bibliothek noch nicht angeschaut. Hört sich aber so an, als ob sie mit fragmentierten Blöcken Probleme hat. Bei TCP Kommunikation wird nicht zwingend alles auf einmal übetragen.
 
Hallo Semo,

Hast du dich an die Anleitung vom Post #5 von mir zum Import der Zertifikate gehalten? Wenn du hier irgendwo nur ein Bisschen abweichst ist es leider vorbei.

Gruß Tia
Ja habe ich soweit Schnittmengen vorhanden umgesetzt.
Warum nicht 1zu1? Versuch mal ein Zertifikat zu importieren (Vertrauenswürdige...), was er in anderer Form schon hat (Geräte).
Habe eben einmal einen Quertest mit "http(s)://www.google.de/" gemacht. Zertifikat ließ sich importieren, DNS-Auflösung ließ sich mit http erfolgreich testen, aber bei https erhalte ich ausnahmslos 16#80C5er im TCON Teil des LHTTP_GET/TSEND_C. Im tls teil, habe ich so ziemlich jede Kombination getestet. Es sollte eigentlich schon funktionieren, wenn nur das CA von google als serverCert referenziert und die Validierung aus ist.


Ich habe mir die Bibliothek noch nicht angeschaut. Hört sich aber so an, als ob sie mit fragmentierten Blöcken Probleme hat. Bei TCP Kommunikation wird nicht zwingend alles auf einmal übetragen.
Das ist auf jeden Fall ne Möglichkeit, der ich nachgehen werde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Semo,

Frage hast du HTTP oder HTTPS benutzt?
Ich würde den Grund mal im Bereich der Leistungsfähigkeit der CPUs ansiedeln. Soweit ich weiß ist ja auch der Hauptgrund warum die neuen 1516 und 1515 nun einen 2ten Core bekommen haben.

Gruß Tia
Grade neben her was angeschoben.
Unsere S7-1507S (Leistung der 1518), hat mit der gleichen SW- auf einer externen Schnittstelle ähnliche Werte.
Bei der internen Schnittstelle (Runtime-IF zum IPC) sieht des ganz anders aus.
Zykluszeit bei < 0,5 ms
Die "Leistungsklasse" der CPU scheint also weniger Einfluss auf die Kommunikationsdauer zu haben.
Je nach eingestellter max. Kommunikationslast und dem Gesamtzyklus skaliert die Dauer sicherlich.
Die Wahl des Interface, bzw. die Kommunikationszeit an sich, haut hier mit einer ordentlichen Pauschale rein.

Ne 1511 hab ich noch nicht angeschlossen, denke aber das, es sich dadurch Bestätigen lässt.

Vorerst ist mein Problem aber doch erstmal die verschlüsselte Kommunikation, da aus Theorie nun Gewissheit wurde...
 
Zurück
Oben