Hallo zusammen! Ich will ein drive-by-wire System implementieren, dass einen Embedded PC als Hauptsteuergerät verwendet. Hat jemand Erfahrungen mit TTCAN, CANopen oder Flexray gemacht und könnte mir Tipps geben? Wo gibt´s da Probleme? Wie ist die Verfügbarkeit der Hardware? Kosten?? Sandra
CAN ist im allgemeinen nicht als echtzeitfähig anzusehen, da es keine vorhersagbaren Latenzen bei der Übertragung gibt (nicht deterministisch). TTCAN ist eine dahingehende Erweiterung des CAN-Protokolls, kenne ich aber nicht weiter. Flexray ist deterministisch (zumindest im synchronen Übertragungsblock), jedoch AFAIK gibt es noch keine Controller dafür in Stückzahlen - für Normalsterbliche gibts dann vermutlich auch keine Bezugsquellen, da lasse ich mich aber auch gerne korrigieren. Nur so aus Neugierde: was willst du denn darüber ansteuern? Gruß JL
Hi! Danke erstmal für die Antwort.. Zum Bus: erstmal will ich damit Motor, Lenkung und Bremse von einem Modellauto ansteuern. Außerdem will ich "automatisches Bremsen" auf dem Embedded PC implementieren (in Zusammenhang mit Hinderniserkennung). Gruß, Sandra
@J. Lesselich "CAN ist im allgemeinen nicht als echtzeitfähig anzusehen, da es keine vorhersagbaren Latenzen bei der Übertragung gibt" Das stimmt nicht ! Genau deshalb wurde ja CAN entwickelt ! Und deshalb ist CAN in Steuerungen auch so erfolgreich. Der Identifier bestimmt die Priorität einer Nachricht und da die Paketlänge auf 8 Byte begrenzt ist, kommt immer die Nachricht mit der höchsten Priorität nach Ende des laufenden Pakets zum Zug. Du kannst also auf die µs genau ausrechnen, wann Dein Paket beim Empfänger angekommen ist. Der Rest ist dann nur noch eine Sache der Software, d.h. daß der Sender mit der höchsten Priorität genügend Timeslots zur Verfügung stellt, damit auch die weniger priorisierten Nachrichten gesendet werden können. Der CAN-Bus darf also nicht zu 100% dicht sein. Peter
>Du kannst also auf die µs genau ausrechnen, wann Dein Paket beim >Empfänger angekommen ist. Nein, das kannst du nur für Nachrichten mit der höchsten Priorität. Für alle anderen kannst du das nur berechnen falls die Frequenz, mit der alle höherprioren Nachrichten gesendet werden bekannt ist und keine Übertragungsfehler auftreten, die zu einer Wiederholung der verlorengegangenen Nachrichten führen (und zu Verzögerungen durch die Fehlersignalisierung). Tritt sporadisch ein Fehler auf verzögern sich die Übertragungen aller wartenden Nachrichten bis die Nachricht auch wirklich angekommen ist. Dadurch entseht Jitter, der das ganze System nicht deterministisch macht, dann verzögern sich auch die Nachrichten mit höchster Priorität. >Der Rest ist dann nur noch eine Sache der Software, d.h. daß der >Sender mit der höchsten Priorität genügend Timeslots zur Verfügung >stellt, damit auch die weniger priorisierten Nachrichten gesendet >werden können. >Der CAN-Bus darf also nicht zu 100% dicht sein. Nach der Vorgabe ist auch Ethernet echtzeitfähig, eben mit einer bekannten Anzahl Clients, Nachrichten und Routen - aber auch nur genau dann. Steigt bei CAN die Buslast (und das muss nichteinmal an die 100% rangehen) hat nur noch die Nachricht mit dem niedrigsten verwendeten Identifier vorhersehbare Latenzen, das System an sich ist aber weit weg von Echtzeitanforderungen. Bei Flexray werden im synchronen Betrieb fehlerhaft übermittelte Nachrichten beispielsweise nicht wiederholt, es fehlt dann eben bis zur nächsten regulären Übertragung dieser Nachricht ein Datensatz. Gruß JL
Ist in meinen Augen ein wenig Haarspalterei. Wenn man ein solches Kommunikationsnetz aufsetzt überlegt man sich gewöhnlich schon vorher, zu welchem Datenaufkommen es kommen wird und welche Priorisierungen es geben soll. Gleichzeitig begrenzt man in den Clients die Anzahl von Sendungen auf ein vernünftigen Maß, um die Busauslastung in vernünftigen Grenzen zu halten (meine Erfahrung). Man hätte auch diskutieren können, wie man Echtzeit definieren möchte. Für den menschlichen Anwender am PC ist Ethernet echtzeitfähig, wenn er auf eine Webseite nicht länger als meinetwegen 3s warten muss ... Auf dem CAN definiere ich mir wenige extrem wichtige Nachrichten und statte die mit einer ID aus, die dafür sorgt, dass ich sie spätestens nach z.B. 5µs versendet bekomme. Das könnte man dann auch Echtzeit nennen.
@Sandra: Welches Betriebssystem läfut auf denem PC? Würde da auch ein WindowsXP funktionieren? Welche Latenzzeiten beitdet denn WindowsXP? cu
Hallo zusammen, hier entwickelt sich ja eine sehr spannende Diskussion :-) Mir fällt auf, dass es sehr viele unterschiedliche Blickwinkel zum Thema Bussystem und Echtzeit gibt. Ich kann euch aus meiner Erfahrung im Automobilbereich sagen, dass CAN als nicht echtzeitfähig angesehen wird. Gerade bei Fahrdynamik Anwendungen sind grössere Jitter nicht akzeptabel (ich kenne Messungen/Untersuchungen, die bei einem 10ms Raster einen Jitter > Faktor 10 zeigen - auch wenn das nur einzelne Botschaften betrifft). Moderne Regelsysteme im Fahrzeug brauchen verlässlichere Informationen. Dies führt dazu, dass der gute alte CAN Bus durch Flexray abgelöst wird. Das steigende Datenaufkommen trägt ein übriges dazu bei. Die Erfahrung hat gezeigt, dass mehr als 2 unabhängige CANs in einem Steuergerät nicht mehr zu verwalten sind, es sei denn, das SG hat keine weiteren Aufgaben :-) Das bei einer Neuentwicklung auch Untersuchungen zur Buslast und Datenaufkommen gemacht werde ist schon klar. Allerdings ist es in der Praxis so, dass kaum ein Auto dem anderen gleicht. Moderne Oberklasse Fahrzeuge haben in der "Grundausstattung" oft bereits über 70 Steuergeräte verbaut, dazu kommen dann noch diverse Sonderausstattungen, die alle auch irgendwann irgendwie ein paar Daten auf dem Bus versenden möchten. Von Sandras Anforderungen ein Modellauto zu steuern würde ich trotzdem zu CAN raten. Flexray ist momentan noch für Privatpersonen nicht beherrschbar. Das fängt schon bei einfachen Mess- und Analysetools an und geht dann weiter bis zur Bauteileverfügbarkeit. Mir ist bislang noch kein Mikrocontroller mit integriertem Flexray bekannt, der auch wirklich für Endkunden zu kaufen ist. Wenn dann nächstes Jahr die ersten Flexray Fahrzeuge in Serie gehen, werden bestimmt auch die Chiphersteller liefern können :-) Eine weitere Herausforderung wird wahrscheinlich auch das Betriebssystem. Momentan sind die Hersteller noch dabei fleissig an ihren Flexray Integrationen (Stichwort timetriggert) zu hacken. Auch hier darf man gespannt sein :-) Generell sollte sich Sandra fragen, ob in einem Modellauto überhaupt mehrere Steuergeräte vernetzt werden müssen? Oder geht es hier mehr um den Vernetungsgedanken? Ich sehe gerade, dass Sandra an der rwth ist? Gerade dort sollten sich doch noch einige Informationen auftreiben lassen :-) Viele Grüsse Volker
Also, das Betriebssystem ist noch ein weiterer Punkt, der noch nicht entschieden ist, aber derzeit tendiere ich zu RTLinux, da dass an meinem Institut schon benutzt wird und der entsprechende Support da ist.. meine Erfahrungen mit Embedded- Betriebssystemen hält sich leider in Grenzen.. @Volker: Nachdem ich mal einige Preislisten von Flexray angefordert habe, bin ich auch zu dem Schluss gekommen, dass CAN für meine Anwendungen völlig ausreicht.. bzgl. der Anzahl der Steuergeräte: Das Ziel des Ganzen(d.h. meiner Diplomarbeit) ist es, nur einen PC zu haben, der als "Hauptsteuergerät" fungiert. Die Anzahl der Steuergeräte soll also minimiert werden. Ein Fokus der Arbeit liegt auch auf sicherheitskritischen Funktionen. In dem Zusammenhang hatte ich überlegt, PikeOS zu verwenden um die sicherheitskritischen Funktionen bündeln zu können. Nur stellt sich mir im Moment die Frage, inwieweit das jetzt schon Sinn macht, da die Ansteuerung des Autos derzeit die einzige Funktion ist, die ich realisieren will.. das ist also alles noch nicht so ganz klar. Sandra
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.