Hallo zusammen, aktuell bearbeite ich ein (mehrjähriges) Projekt, in dem eine Hardware zu entwickeln ist. Sie ist zwischen zwei über Ethernet kommunizierende Geräte zu schalten, um die Datenpakete auslesen und eventuell manipulieren zu können. Dabei stellt sich die Frage, welche Hardware für ein schnellstmögliches Zeitverhalten am Besten geeignet ist. Ich dachte mal, dass ein Programmieren in C auf (allgemein als schnell geltenden) FPGAs möglich und daher naheliegend sei. Jetzt habe ich gelesen, dass hierfür ein Softcore implementiert werden müsste, der stets langsamer als sein Mikrocontroller-Pendant sei. Deshalb müsste ja die Entscheidung stehen: uC in C (Assembler dürfte zu großer Aufwand sein, oder?) oder FPGA in (V)HDL. Kann man vornherein abschätzen, mit welcher Lösung man generell schneller ist, um den Bytecode der Schichten über der PHY-Schicht mit einer vorgegebenen Sequenz zu vergleichen? Im Forum bin ich lediglich auf diesen Beitrag gestoßen (Beitrag ""Hardware Ethernet Sniffer"") und schätze mal, dass sich in der Zeit einiges getan hat. Vlt. hat jemand bereits praktische Erfahrungen gesammelt oder ein Referenzprojekt gesehen. Vielen Dank für eure Hilfe, Tim
µC ungleich FPGA !!! Zwei gänzlich verschiedene Dinge. Warum willst du das in der Hardware realisieren? Hast du schonmal ein Ethernetboard entwickelt? Was für ein Ethernet willst du machen? Weißt du was für Durchsatzraten es da gibt? Hast du schonmal eine Platine mit >8 Layern entwickelt? Sei mir nicht böse aber das klingt mir ein bisschen hochgegriffen für ein Anfängerprojekt. Mach es doch als PC-Software. Da hast du den Arbeitsspeicher und die Geschwindigkeit. Sonst musst dir einen FPGA nehmen (für deine Anforderungen >100€) und dem 2 GB RAM spendieren.
Welche Geschwindigkeit ? Welches Protokoll (TCP/UDP) ?
Bis Gigabit Ethernet würde ich Dir einen normalen PC empfehlen. Dafür gibts auch schon fertige Software wie tcpdump usw. Darüber wird das in der Regel mit FPGAs gemacht. Schau Dir mal die Funktion im Wireshark an mit der Du Filterregeln kompilieren kannst.
Vielen Dank schon mal für die Antworten. Es handelt sich um ein kommerzielles Projekt. Ich mache das also erstens nicht alleine, zweitens könnte Hardware wie FPGA-Boards von Auftragsfertigern übernommen werden. Kosten >100€ für einen Prototypen sind also eingeplant, keine Angst ;-) Es besteht ja bereits eine PC-Lösung: Mit Hilfe eines C++-Programms wird eine Wireshark-Aufzeichnung mit einem Zielszenario abgeglichen - bzw., einfach gesagt, zwei XML-Dateien. Das mag offline ja ganz gut funktionieren - aber das Ziel ist ein Abgleich im laufenden Betrieb. Das heißt: Welche Hardware erfüllt meine Zeitanforderungen? Bisher wird sich auf das Profinet-Protokoll konzentriert, somit würden 100 MBit/s genügen. Der Sniffer soll im Idealfall aber flexibel für andere Protokolle ausgelegt sein. Das heißt, es soll jedes Paket analysierbar sein. Ich sehe die Zeiten von einigen hundert Mikrosekunden zwischen zwei beliebigen Paketen auf einem Nicht-Echtzeitsystem wie PC + Windows 7 als kritisch. Da Profinet für Echtzeit ausgelegt ist, sollte es der Sniffer auch sein. Also, was sind die Möglichkeiten? PC: Es würden sich z.B. Windows CE oder RT Linux anbieten, oder? Hat jemand Erfahrung mit deren Zeitverhalten? Dort stelle ich mir eine Programmumsetzung in C und mit genügend RAM relativ einfach vor. Andere Hardware: Ich erhoffe mir einfach besseres Zeitverhalten. Ich hätte auch gedacht, dass FPGAs mit ihrer Möglichkeit, parallele Architekturen zu synthetisieren, für einen sequentiellen Datenstrom unsinnig wären bzw. Potential verschenken würden. Da andere kommerzielle Sniffer aber auf FPGAs aufbauen (z.B. Owita Flexegen), muss es doch einen Vorteil gegenüber PCs geben? Warum brauche ich eigentlich ganze 2GB RAM? Danke für den Hinweis zu tcpdump und den Filterregeln in Wireshark. Es wäre wirklich ideal, eine bestehende Lösung verwenden zu können, die mir zuverlässig im Life-Betrieb ankommende Paketdaten liefert - Analyse und Filterung will ich selbst übernehmen. Vielleicht würde sogar der uninterpretierte, hexadezimale Code reichen, der auf der Leitung ankommt (der, der in Wireshark auch unten angezeigt wird). Ich befürchte, durch die Vorinterpretation eines anderen Programmes zuviel Zeit zu verlieren...
Bei Profinet gibt es mehrere Varianten. IRT ist so wirklich Echtzeitfähig und da musst Du tatsächlich auf jede Mikrosekunde achten. Aber auch Profinet RT ist durchaus ein bischen Zeitkritisch, aber das hängt vom der gefahrenen Zykluszeit ab. Bis so ein Telegram verarbeitet ist, kann es durchaus ein bischen dauern, ein PC braucht dafür viel zu lange. Die Frage ist, wie kritisch das in Deinem speziellen Fall ist. Für Profinet IRT musst Du ein FPGA verwenden, sonst funktioniert das nicht. Ein FPGA könnte theoretisch das Telegramm einlesen, verarbeiten und direkt wieder aussenden. Die Durchlaufzeit ist dann nur die Zeit durch den Phy und die Verabeitungslogik, also etwa 500 ns. Wenn Du das Telegramm verändern willst, dauert es etwas länger, dann müssen übrigens auch die CRC wieder korrigiert werden. Ein PC wird das Telegramm komplett einlesen, verarbeiten und wieder ausschreiben. Ausserdem ist nicht vorhersagbar, wie lange das dauert. Ich bin nicht sicher, ob Profinet RT auch Zeitsynchronisierung verwendet, die dürfte bei Verwendung eines Windows oder Linux Betriebssystems wohl zum Teufel sein. Gruss Axel
Tim Ruß schrieb: > PC: Es würden sich z.B. Windows CE oder RT Linux anbieten, oder? Hat > jemand Erfahrung mit deren Zeitverhalten? Dort stelle ich mir eine > Programmumsetzung in C und mit genügend RAM relativ einfach vor. x86 ist für harte Echtzeit nicht geeignet. Weißt Du, wie viel k an Segmentcaches etc bei jedem Interrupt gerettet und neu geladen werden müssen? Das ist mit jeder Prozessorgeneration rasant mehr geworden. Schau Dir mal an, was beispielsweise in Layer 4 Switches verbaut ist. Die können beispielsweise auf 8 Gigabit-Ethernets IP-Verbindungen contentabhängig mit Wirespeed filtern und umleiten etc. Für so etwas gibt es spezielle Netzwerkprozessoren, die z.B. spezielle Patternmatching-Hardware haben. Das hier zB: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=P5040&nodeId=018rH325E4DE8AA9A4 ok, das ist absolutes High-End, aber aus dieser Prozessorserie gibts auch kleinere Versionen. Darauf läuft dann z.B. vxWorks, das einzige kommerzielle interplanetare Echtzeitbetriebssystem. Ein anderer bekannter Hersteller von solchen Netzwerkprozessoren ist z.B. Cavium. Das ist nicht PowerPC, sondern MIPS64, aber auch die haben in dieser Richtung einiges an Hardwareunterstützung. http://www.cavium.com/OCTEON_MIPS64.html Wie gesagt, das soll und kann jetzt keine Produktempfehlung sein, soll Dir aber zeigen, was es sonst noch jenseits von PC und Linux/Windows gibt. fchk
Tim Ruß schrieb: > > Ich sehe die Zeiten von einigen hundert Mikrosekunden zwischen zwei > beliebigen Paketen auf einem Nicht-Echtzeitsystem wie PC + Windows 7 als > kritisch. Da Profinet für Echtzeit ausgelegt ist, sollte es der Sniffer > auch sein. Also, was sind die Möglichkeiten? Sind die "einigen hundert Mikrosekunden" die maximale Latenz ? > Vielleicht würde sogar der > uninterpretierte, hexadezimale Code reichen, der auf der Leitung ankommt > (der, der in Wireshark auch unten angezeigt wird). Ich befürchte, durch > die Vorinterpretation eines anderen Programmes zuviel Zeit zu > verlieren... Es gibt raw sockets unter Linux damit lassen sich im Userspace beliebige Pakete empfangen und senden. Damit hätte man schon mal einen Prototypen. Ansonsten wäre die Bridge Funktion im Linux Kernel eine Möglichkeit zum aufbohren: http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
Frank K. schrieb: > Schau Dir mal an, was beispielsweise in Layer 4 Switches verbaut ist. > Die können beispielsweise auf 8 Gigabit-Ethernets IP-Verbindungen > contentabhängig mit Wirespeed filtern und umleiten etc. 32Gbit Backplanes waren vor über 5 Jahren Stand der Technik. Aber der Speed war nur da wenn die TCAM nicht voll war.
Vielen Dank für Anstöße - letztendlich liegt die Entscheidung eh nicht bei mir ;-) Anbei: Die "einige hundert Mikrosekunden" habe ich nur mal schnell aus dem Abstand zweier (beliebiger) Pakete einer Wireshark-Aufzeichnung geschätzt. Mit Ethernet und Profinet im Speziellen beschäftige ich mich erst seit kurzem und habe noch keine Ahnung von den Zeitanforderungen. Im Übrigen genügt jetzt auch RT statt IRT.
Mal eine paar Punkte zum Thema: Profinet RT: - ist nicht synchronisiert. - Profinet Slaves und der Master verfügen über eine Zeitüberwachung der Zyklischen Telegramme, in typischen Anlagen dürfen max zwei Telegramme hintereinander ausfallen - Grob gesagt gibt es pro Slave ein Telegram in jedem Buszyklus, wenn man mal die unzähligen anderen Konfigurationsmöglichkeiten außer acht lässt. (Z.b. Zeitmultiplex und solche Späße) Heist bei 10 Slaves am Bus bei Grund Takt von 1ms 10 Telegramme pro Richtung pro 1ms. Profinet IRT: - ist synchronisiert, dazu wird die Telegrammlaufzeit in den Kabeln regelmäßig gemessen - Der Sniffer muss eine absolut konstante Durchlaufzeit der Telegramme aufweisen. Das wird manchmal auch als 'Cut Through' bezeichnet. Das geht nur mit FPGA oder Spezialprozessoren. - Da beim IRT-Betrieb alle Telegramme zeitlich vorgeplant werden (von der Software am PCs) werden insbesondere die Kabellänge von allen Busteilnehmern geprüft und auf Plausibilität geprüft. D.h. Die maximale Kabellänge von 100m nach Ethernet Standard - entspricht einer Telegrammlaufzeit von etwa 500ns - wird auch geprüft. Jetzt weist Du wie viel Zeit dein Gerät maximal hat um das Telegramm zu empfangen, zu verarbeiten und wieder auszuspucken. Dabei muss für jedes Telegram unabhängig von seiner Länge eine konstante Durchlaufverzögerung eingehalten werden. (Es gibt einen zusätzliches Sicherheitspuffer von etwa 100ns) - Der Jitter beim Durchleiten der Frames sollte höchstens 50ns sein, das ist eigentlich schon zu viel, liegt aber gerade noch im Toleranzbereich von 100ns (Der Master und der Slave Jitter ja auch selbst...) Damit hast du mal so die Grundanforderungen für einen Betrieb in einer industriellen Anlage - Im Entwicklungsbereich kann man da etwas laxer rangehen aber auch hier funktioniert das nur wegen der vielen Toleranzen und Sicherheitspuffer. Falls Ihr nur beobachten wollt, dann wird es einfacher, aber hier gibt es bereits einige Geräte auf dem Markt die das gut können...
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.