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.
Um hackt zu ergänzen: - Lizenzgebühren für vorhandene Protokolle.
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)
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.