Hallo Zusammen, Mal wieder das Thema Modbus TCP. Im Rahmen eines Projekts sprechen die SPSen und LT mit diesem Protokoll zueinander. 1.Welche Art von Schutz bereitgestellt werden kann, wenn überhaupt, um Intrusion oder Denial-of-Service-Angriff auf das System zu verhindern. Das Volumen der zu schützenden Daten ist groß und die Ressourcen für den Programmierschutz sind zu klein, um eine Veränderung in der Zukunft zu rechtfertigen. 2. Übertragung einer Änderung vom HMI wird um einigen Sekunden verzögert. Woran könnte es liegen? 3. gibt es eine alternative zu ModbusTCP, das auch offene, kostengünstig und sicher wäre. (hier werde ich noch sehr dankbar wenn jemand mir was zum Literatur empfehlen kann). Mit freundlichen Grüßen. Hecta der Zauberer.
:
Verschoben durch Moderator
1) ist weder als Frage noch als Feststellung verständlich 2)langsame Geräte, hohe Kommunikationslast, schlechtes Netzwerk, kein Change-Driver (polling) 3)Kommt auf den PLC Typ an: B&R PVI, OPC UA, Profinet, ...
Hallo StepG, Vielen Dank für Ihre spontan Antwort. 1. Modbus Protokoll bietet keine Möglichkeit, der Client der Anfrage zu authentifizieren oder zu autorizieren. Deshalb nicht sicher. Die Frage ist wie man die Daten, die von Server geliefert werden, gegen ungerechte Benutzer sichern. 3. wir verwenden Wago Controller: mit ModbusTCP/RTU Protokoll. Diese Protokoll ist nach meinem Wissen das einzige dass einfach und offene ist. Deswegen frage ich, ob es noch was anderen gibt. Lg Hector.
Hector D. schrieb: > 1. Modbus Protokoll bietet keine Möglichkeit, der Client der Anfrage zu > authentifizieren oder zu autorizieren. Deshalb nicht sicher. Die Frage > ist wie man die Daten, die von Server geliefert werden, gegen ungerechte > Benutzer sichern. Nach meinem Wissen gibt es bisher kein Ethernetbasiertes SPS-Protokoll, was gegen die Widrigkeiten des Internets wirklich geschützt ist. Der Schutz basiert im Allgemeinen darauf, das die Netzwerke physikalisch getrennt sind. Am ehesten könntest Du im Bereich der für Personenschutzsysteme (PSS) zugelassenen Baugruppen ('gelbe Klemme') was finden. > 2. Übertragung einer Änderung vom HMI wird um einigen Sekunden > verzögert. Woran könnte es liegen? Kurze Antwort: Es liegt an Eurem System. Längere Anwort: Jees Baugruppe, die zwischen HMI und Endgerät liegt (und natürlich auch das HMI-System bzw. das Endgerät selbst), benötigt eine gewisse Latenz, um die Daten zu übertragen bzw. zu prozessieren. Dazu kommt noch, das sowohl die HMI-Systeme, als auch die Feldebene mit sogennanten 'Zykluszeiten' arbeiten. D.h. ein Ereignis (z.B. ein Knopfdruck) wird innerhalb eines Zyklus registriert und erst im nächsten verarbeitet. Nur am Rande: Ich hatte schon mit Geräten (ich glaube es waren Motorcontroller) zu tun, deren Reaktion über Ethernet langsamer war, als über die serielle Schnittstelle (RS232). Bei Ethernet kamen die Verarbeitungszeiten des Protokollwandlers hinzu. Das ließ sich mit dem Oszilloskop (für die RS232) und Wireshark gut nachweisen.
> Nur am Rande: Ich hatte schon mit Geräten (ich glaube es waren > Motorcontroller) zu tun, deren Reaktion über Ethernet langsamer war, als > über die serielle Schnittstelle (RS232). Bei Ethernet kamen die > Verarbeitungszeiten des Protokollwandlers hinzu. Das ließ sich mit dem > Oszilloskop (für die RS232) und Wireshark gut nachweisen. vielen Dank für Ihre Antwort. wie haben Sie dann diese langsame Reaktionszeit mit Ethernet gelöst? Über rs232? Lg Hector
Clemens schrieb: > > Nur am Rande: Ich hatte schon mit Geräten (ich glaube es waren > Motorcontroller) zu tun, deren Reaktion über Ethernet langsamer war, als > über die serielle Schnittstelle (RS232). Bei Ethernet kamen die > Verarbeitungszeiten des Protokollwandlers hinzu. Das ließ sich mit dem > Oszilloskop (für die RS232) und Wireshark gut nachweisen. Ja, die Umlaufzeiten über ein Netzwerk sind per Definition nicht vorhersehbar, ausser das Netz ist komplett abgeschlossen (und selbst dann hängen die Paketumlaufzeiten auch noch von Anderen Dingen ab). Mal ganz abgesehen vom Protokolloverhead. Es gibt sehr subtile Unterschiede zwischen "denselben" aber auf verschiedenen Transporten ablaufenden Protokollen. Z.B. sind auf seriellen peer-to-peer Transporten laufende Protokolle streng sequentiert, d.h. wenn ein peer nach einer definierten Zeit nicht auf ein Paket geantwortet hat, kann man davon ausgehen, dass das Paket nicht gesehen wurde. Diese Logik funktioniert in heterogenen Netzwerken nicht mehr. Wenn also ein Peer drei Mal in ein Timeout gelaufen ist und ein Paket drei Mal wiederholt, dann ist es nicht unmöglich, dass irgendwann später der peer doch noch drei Mal ACK schickt... was dann dazu führt, dass der Sender plötzlich zwei ACKs nicht mehr zuordnen kann und dann mglw. diese ACKs den nächsten zwei Paketen zuordnet, selbst wenn diese gar nicht gesehen wurden! Da hilft nur eine Sequenznummer, die im ACK wiederholt werden muss und für verschiedene Pakete verschieden ist. Umgekehrt ist bei einem über TCP laufenden Protokoll eine Paket CRC nicht nötig, weil TCP bereits hinreichende Konsistenzchecks auf mehreren Protokollebenen führt. Ein skalierbares Protokoll enthält optionale Sequenzierung und auch optionale CRCs. Ich habe so ein Protokoll in der Entwicklung (state-of-the-art security ist da ebenfalls drin). Es soll am Ende des Tages in die Open Source gehen, ich suche aber noch nach Pilotimplementierern. Bei Interesse bitte PM. Danke, Rüdiger http://www.springer.com/de/book/9783658148492#otherversion=9783658148508
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.