www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CANopen vs. Flexray vs. TTCAN auf Embedded PC


Autor: Sandra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: J. Lesselich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sandra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: J. Lesselich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Der Elektrische Reiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sandra: Welches Betriebssystem läfut auf denem PC?
Würde da auch ein WindowsXP funktionieren?
Welche Latenzzeiten beitdet denn WindowsXP?

cu

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sandra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.