Hallo,
wir haben an der Uni ein Gemeinschaftsprojekt, in dem sechs Cortex M3
Boards per Ethernet miteinander kommunizieren sollen. Bisher konnten wir
den uip-Stack in unser Projekt integrieren und wir können auch ein paar
Daten per UDP austauschen.
So richtig kommen wir jetzt aber nicht auf der Anwendungsschicht weiter
(OSI 5-7?). Um Zyklisch Prozessdaten auszutauschen scheinen uns die
Protokolle wie http, ftp oder smtp nicht geeignet.
Was für Protokolle werden in der Praxis im embedded-Bereich in der
Anwendungsschicht eingesetzt?
Wir wollen folgendes tun:
- Zyklischer Austausch von Prozessdaten (kleinere Datenmenge, Zustände
Ausgänge, ...)
- Gezielte Abfrage von Daten
- Kommandos
- Ändern von Konfigurationsdaten
Gibt es ein Protokoll, dass diese Fälle oben abdeckt?
Werden üblicherweise verschiedene Protokolle eingesetzt?
Was setzt die Praxis ein?
Grüße
Steinhans
an der Uni haben wir ein paar CortexM3-Entwicklungsboard mit Ether
Hi,
es gibt Ethernet-basierte Feldbusse. EtherCAT, PROFINET, EtherNet/IP
usw. Dazu eine Zulieferindustrie, die Protokollstacks verkauft. Fuer
Uniprojekte lassen sich vielleicht Academic-Lizenzen heraushandeln.
Je nach Groesse Eurer Spatzen koennten das aber unangemessene Kanonen
sein; wenn die Geraete nur ein bisschen miteinander reden sollen, koennt
Ihr auch selbst was zusammenschustern. Ich empfehle jedoch, zumindest
mal grob zu gucken, wie o.g. Feldbusse funktionieren, damit Ihr schon
mal seht, auf was man alles achten muss.
Hallo Konrad,
danke! Das sind Protokolle, die wir auch gesehen haben. Es scheint, als
sind diese stark in der SPS-Welt verbereitet.
Ist das auch ein Standard, der im Embedded-Bereicht genutzt wird?
Zum selbst zusammenschustern: Irgendwie kann ich mir nicht vorstellen,
dass in professionellen Projekten etwas selbst zusammengeschustert wird.
Ich kann mir aber auch nicht vorstellen, dass überall die
"SPS"-Protokolle genutzt werden.
Gibt es noch andere Ideen?
Grüße
Steinhans
Steinhans schrieb:> Was setzt die Praxis ein?
Ich kann nicht für Embedded sprechen, aber für professionelles Netzwerk-
Equipment. Das verwendet zumindest für die Abfrage und teilweise auch
für die Konfiguration SNMP.
Allerdings hat SNMP den Ruf, nahezu keine Sicherheit zu bieten. Das soll
mit SNMPv3 zwar besser geworden sein, aber als ich das letzte Mal mit
derartigen Geräten zu tun hatte, war SNMPv3 noch kaum irgendwo
implementiert.
Allerdings scheinen Komponenten/Netzwerke für Prozeßsteuerung Sicherheit
eher nicht ernst zu nehmen. Man siehe dazu die Sicherheitslücken in
SCADA Systemen allgemein und die Extrembeispiele Stuxnet & Co im
speziellen. Wenn ihr euer Netzwerk ohne Security baut, dann wäret ihr
zumindest in guter^Wgroßer Gesellschaft.
Wenn ihr fähig & willens seit, eigene Protokolle aufzusetzen, dann macht
das ruhig. Dabei kann man eine Menge lernen. Als Basis würde ich SSL/TLS
empfehlen. Mit eigenen Zertifikaten.
Steinhans schrieb:> Wir wollen folgendes tun:> - Zyklischer Austausch von Prozessdaten (kleinere Datenmenge, Zustände> Ausgänge, ...)> - Gezielte Abfrage von Daten> - Kommandos> - Ändern von Konfigurationsdaten
Das ist genau das, wofür die "SPS-Protokolle" geschrieben wurden.
EtherCAT und Profinet werden normalerweise über ASICs realisiert,
Ethernet/IP, Powerlink und Modbus/TCP funktionieren auch mit einem
normalen Ethernet-Controller.
Von Modbus/TCP gibt es auch freie Versionen, bisher aber nur für ARM7
(STR71) und Coldfire (MCF523x).
http://www.freemodbus.org/
Sollte sich aber portieren lassen.
Steinhans schrieb:> Wir wollen folgendes tun:> - Zyklischer Austausch von Prozessdaten (kleinere Datenmenge, Zustände> Ausgänge, ...)> - Gezielte Abfrage von Daten> - Kommandos> - Ändern von Konfigurationsdaten>> Gibt es ein Protokoll, dass diese Fälle oben abdeckt?> Werden üblicherweise verschiedene Protokolle eingesetzt?
Klingt ziemlich nach PROFINET. Die TU-Dresden hat einen Softwarestack
implementiert, der ein PROFINET-IO Gerät emuliert, genannt /generic
device/ [0].
PROFINET macht es so, dass alles über raw ethernet frames mit eigener
Protokoll-ID gesendet wird, ausser azyklische Daten (also deine
"gezielte Abfrage von Daten") welche über UDP laufen.
Im Zweifelsfall einfach mal in die PROFINET-IO Spec schauen.
[0] http://www.inf.tu-dresden.de/index.php?node_id=3602&ln=de
GB schrieb:> Von Modbus/TCP gibt es auch freie Versionen, bisher aber nur für ARM7> (STR71) und Coldfire (MCF523x).
nuja ... modbus TCP ist nicht schlimm ..
wenn man modbus RTU hat... das in einen TCP rahmen werfen geht recht
einfach
alternativ aus der IoT ecke gibts noch einiges ..
http://postscapes.com/internet-of-things-protocols
Steinhans schrieb:> Ich kann mir aber auch nicht vorstellen, dass überall die> "SPS"-Protokolle genutzt werden.
Du hast Ethernet vorgegeben.
Die Industrie benötigt häufig Realtime-Ethernet. Die Protokolle wurden
schon aufgezählt.
Steinhans schrieb:> Zum selbst zusammenschustern: Irgendwie kann ich mir nicht vorstellen,> dass in professionellen Projekten etwas selbst zusammengeschustert wird.
Aber klar doch. Je nach Firma läuft der Prozess unterschiedlich
formalisiert ab, aber am Ende sitzt da einer, schustert sich was
zusammen und guckt, ob es die Anforderungen erfüllt. Das Hauptziel
lautet "Time To Market". Wenn es dann hinreichend funktioniert, wird es
spezifiziert, standardisiert und gehofft, dass alle anderen mitziehen.
Funktioniert es dann doch nicht ausreichend (oder wird vom Markt nicht
angenommen), verschwindet das Protokoll mit der Zeit ganz leise wieder.
Die Protokolle, die dann noch übrig bleiben, sind die, die du siehst.
;-)
Natuerlich schustert man sich selbst ein Protokol zusammen. Wenn :
-man hat sich die bestehenden Protokolle angeschaut und die
passen/gefallen nicht in einem oder mehreren Punkten.
- man benoetigt einen Betriebszustand/Mode, der nicht kompatibel zum
naechsten moeglichen Protokoll ist.
- Dritte Hardware gibt schon ein Protokoll vor.
Man sollte einfach begruenden koennen weshalb man selbst etwas gemacht
hat.
Siebzehn Für Fuenfzehn schrieb:> Natuerlich schustert man sich selbst ein Protokol zusammen. Wenn :> -man hat sich die bestehenden Protokolle angeschaut und die> passen/gefallen nicht in einem oder mehreren Punkten.> - man benoetigt einen Betriebszustand/Mode, der nicht kompatibel zum> naechsten moeglichen Protokoll ist.> - Dritte Hardware gibt schon ein Protokoll vor.
- "Wir werden doch nicht fuer die paar Parameter einen ganzen
Protokollstack zukaufen. Parameter: ach, 256 reichen, da nehmen wir ein
Byte. Und sind alles Integers. So! Schon fertig!".
kurz darauf:
- "ach, mit dem Bootloader reden... da nehmen wir halt das oberste Bit
der Parameternummer fuer, sonst muesste in den Bootloader noch unsere
ID-Generierung rein"
- "hupps, doch mehr Parameter. Na dann heisst ID=126, dass der Integer
die lange PArameternummer enthaelt und implizit das naechste Paket den
Parameterwert".
- ...
(das passiert natuerlich nie)
