ist der CANbus echtzeitfähig ?

[Martin Meier (MMC)]

Hallo zusammen !

Leider hat meine umfangreiche Recherche im Web meine Frage nicht beantworten
können: ist der CANbus echtzeitfähig ?

Würde mich freuen, wenn mir hier jemand weiterhelfen könnte.

Viele Grüsse,
Martin

 

[Rafael Deliano]

ist der CANbus echtzeitfähig ?
Marketingleute ( reden gerne von Echtzeit ) werden immer sagen: ja

Ansonsten:
Wenn er schnell genug für die beabsichtigte Anwendung ist: ja.
Wenn man eine garantierte maximale Reaktionszeit will: hängt nicht
allein vom Bus ab.

MfG JRD

 

[Thomas Mozgan]

Martin Meier (MMC) schrieb:

Leider hat meine umfangreiche Recherche im Web meine Frage
nicht beantworten können: ist der CANbus echtzeitfähig ?

Würde mich freuen, wenn mir hier jemand weiterhelfen könnte.

AFAIR hat CAN mit seiner bitweise Arbitrierung, verschiedene
Prioritaeten fuer seine Nachrichtenpakete.

Nur bei Nachrichten mit der hoechsten 'Prioritaet' (sprich mit den
meisten dominaten Buszustaenden) kann man eine obere Zeitschranke
fuer die Uebertragung garantieren. Die Antwort mit niedriger
Prioritaet kann unbestimmbar verzoegert werden.

Eine der Eigenschaften von echtzeitfaehigen Bussystemen ist die
zeitliche Vorhersehbarkeit. Diese ist bei CANbus nur bei wenig
Datenverkehr/Auslastung und fuer ausgewaehlte Nachrichten moeglich.

Also lautet meine Antwort: NEIN, ausser bei eingeschraenkter Nutzung.

TTCAN (time triggered CAN) ist schon eher echtzeitfaehig:
Siehe z.B. "Evaluation and Comparison of the Real-Time Performance
of CAN and TTCAN" http://www.can.bosch.com/docu/9th_iCC_AG_2003.pdf


servus thomas
Ť
--
Die 4. Österreichische Fan-Convention zum Thema Japanische Popkultur
** AniNite 2004 ** 20.-22.August 2004 ** http://www.aninite.at/ **
Anime & Manga * J-Pop Bar * Cosplay * Videogames * Go * DDR * AMV *
Manga Workshop * Quiz * Trading Cards * Vortraege * Origami * Kyudo *

 

[Tilmann Reh]

Thomas Mozgan schrieb:

Leider hat meine umfangreiche Recherche im Web meine Frage
nicht beantworten können: ist der CANbus echtzeitfähig ?

Würde mich freuen, wenn mir hier jemand weiterhelfen könnte.

AFAIR hat CAN mit seiner bitweise Arbitrierung, verschiedene
Prioritaeten fuer seine Nachrichtenpakete.

Nur bei Nachrichten mit der hoechsten 'Prioritaet' (sprich mit den
meisten dominanten Buszustaenden) kann man eine obere Zeitschranke
fuer die Uebertragung garantieren. Die Antwort mit niedriger
Prioritaet kann unbestimmbar verzoegert werden.

Nein, denn es hängt erstmal davon ab, wie die Buszugriffe
grundsätzlich geregelt sind, d.h. vom übergelagerten Protokoll.

Eine der Eigenschaften von echtzeitfaehigen Bussystemen ist die
zeitliche Vorhersehbarkeit. Diese ist bei CANbus nur bei wenig
Datenverkehr/Auslastung und fuer ausgewaehlte Nachrichten moeglich.

Nein, denn z.B. mit einem Master-Slave Protokoll gibt es keine
Kollisionen und damit kann die Datenrate voll ausgeschöpft
werden.

Also lautet meine Antwort: NEIN, ausser bei eingeschraenkter Nutzung.

Das mit der eingeschränkten Nutzung stimmt /fast/, man muß die
Nutzung genau *regeln*. Bei einem Bus, wo jeder Teilnehmer wild
drauf los sendet, wann er will, kann man über die Reaktionszeiten
keine definierten Aussagen machen. Bei einem reinen M/S Protokoll
schon.

Man müßte also erstmal wissen, *was* und *wie* der OP überhaupt
per Feldbus/CAN übermitteln möchte, erst dann kann man Aussagen
zur Echtzeitfähigkeit machen.

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

 

[Martin Meier (MMC)]

Würde mich freuen, wenn mir hier jemand weiterhelfen könnte.

AFAIR hat CAN mit seiner bitweise Arbitrierung, verschiedene
Prioritaeten fuer seine Nachrichtenpakete.

Nur bei Nachrichten mit der hoechsten 'Prioritaet' (sprich mit den
meisten dominaten Buszustaenden) kann man eine obere Zeitschranke
fuer die Uebertragung garantieren. Die Antwort mit niedriger
Prioritaet kann unbestimmbar verzoegert werden.

Eine der Eigenschaften von echtzeitfaehigen Bussystemen ist die
zeitliche Vorhersehbarkeit. Diese ist bei CANbus nur bei wenig
Datenverkehr/Auslastung und fuer ausgewaehlte Nachrichten moeglich.

Also lautet meine Antwort: NEIN, ausser bei eingeschraenkter Nutzung.

TTCAN (time triggered CAN) ist schon eher echtzeitfaehig:
Siehe z.B. "Evaluation and Comparison of the Real-Time Performance
of CAN and TTCAN" http://www.can.bosch.com/docu/9th_iCC_AG_2003.pdf

Vielen Dank für die Antwort, genau das was ich heute (in meiner Klausur)
gebraucht habe.

Viele Grüsse und ein schönes Wochenende,
Martin

 

[Thomas Mozgan]

Tilmann Reh schrieb:

Nur bei Nachrichten mit der hoechsten 'Prioritaet' (sprich mit den
meisten dominanten Buszustaenden) kann man eine obere Zeitschranke
fuer die Uebertragung garantieren. Die Antwort mit niedriger
Prioritaet kann unbestimmbar verzoegert werden.

Nein, denn es hängt erstmal davon ab, wie die Buszugriffe
grundsätzlich geregelt sind, d.h. vom übergelagerten Protokoll.

Hmm, stimmt. Ich habe mein Augenmerk zu sehr auf Zeitlimits bei
Collision/Detection bzw Collision/Avoidance und die Prioritaeten
gelegt.

Eine der Eigenschaften von echtzeitfaehigen Bussystemen ist die
zeitliche Vorhersehbarkeit. Diese ist bei CANbus nur bei wenig
Datenverkehr/Auslastung und fuer ausgewaehlte Nachrichten moeglich.

Nein, denn z.B. mit einem Master-Slave Protokoll gibt es keine
Kollisionen und damit kann die Datenrate voll ausgeschöpft
werden.

Ddas CAN ein Master/Slave ist, habe ich nicht beachtet.
Damit hat man volle Kontrolle ueber den Informationsfluss.

Also lautet meine Antwort: NEIN, ausser bei eingeschraenkter Nutzung.

Das mit der eingeschränkten Nutzung stimmt /fast/, man muß die
Nutzung genau *regeln*. Bei einem Bus, wo jeder Teilnehmer wild
drauf los sendet, wann er will, kann man über die Reaktionszeiten
keine definierten Aussagen machen. Bei einem reinen M/S Protokoll
schon.

Bei periodischen Polling der Slave kann man Zeiten garantieren.
Sind diese Zeiten innerhalb der gewuenschten 'Echtzeitlimits',
ist das Protokoll fuer diese Anwendung echtzeitfaehig.

Man müßte also erstmal wissen, *was* und *wie* der OP überhaupt
per Feldbus/CAN übermitteln möchte, erst dann kann man Aussagen
zur Echtzeitfähigkeit machen.

Hehe, das waere die richtige Antwort auf die Ursprungsfrage.

Als Theoretiker mit nur kleiner praktischer Erfahrung bei
Bussystemen, stolpere ich manchmal ueber einfache Konzepte.

servus thomas
--
Die 4. Österreichische Fan-Convention zum Thema Japanische Popkultur
** AniNite 2004 ** 20.-22.August 2004 ** http://www.aninite.at/ **
Anime & Manga * J-Pop Bar * Cosplay * Videogames * Go * DDR * AMV *
Manga Workshop * Quiz * Trading Cards * Vortraege * Origami * Kyudo *

 

[Tilmann Reh]

Thomas Mozgan schrieb:

Ddas CAN ein Master/Slave ist, habe ich nicht beachtet.
Damit hat man volle Kontrolle ueber den Informationsfluss.

Einklich ist CAN *kein* M/S - man kann aber eins draus machen.

Man müßte also erstmal wissen, *was* und *wie* der OP überhaupt
per Feldbus/CAN übermitteln möchte, erst dann kann man Aussagen
zur Echtzeitfähigkeit machen.

Hehe, das waere die richtige Antwort auf die Ursprungsfrage.

Inzwischen haben wir ja die Antwort. Es war (mal wieder) kein
reales Problem, sondern eine Klausuraufgabe...
(Was ja nicht schlimm ist, aber besser hätte erwähnt werden sollen.)

Zu meiner Studienzeit hat man seine Aufgaben noch nicht im
Usenet von anderen lösen lassen... :-\

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

 

[Hans Zocker]

Hallo,

möchte ja kein Klugscheißer sein, aber Deine Frage kann man nicht
beantworten!?

Du verschweigst eine entscheidene Information: Wie schnell nuss es
denn sein? Echtzeit ist natürlich relativ, deshalb - nenn uns mal
Deine minimale Antwortzeit!

 

[Tilmann Reh]

Hans Zocker schrieb:

möchte ja kein Klugscheißer sein, aber Deine Frage kann man nicht
beantworten!?

Du verschweigst eine entscheidene Information: Wie schnell nuss es
denn sein? Echtzeit ist natürlich relativ, deshalb - nenn uns mal
Deine minimale Antwortzeit!

Echtzeitfähigkeit wird zunächst bedingt dadurch, daß eine maximale
Antwortzeit *garantiert* werden kann - wie groß auch immer die sein
mag, und unabhängig davon, ob das im konkreten Fall reicht.

Also haben wir uns alle auf diese grundsätzliche Frage gestürzt,
mangels genauerer Informationen des OP.

Übrinx hat sich das alles schon erledigt, war "nur" ne Klausuraufgabe...

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

 

[Anastasios -Rehakles- Tsi]

Tilmann Reh wrote:

möchte ja kein Klugscheißer sein, aber Deine Frage kann man nicht
beantworten!?

Du verschweigst eine entscheidene Information: Wie schnell nuss es
denn sein? Echtzeit ist natürlich relativ, deshalb - nenn uns mal
Deine minimale Antwortzeit!


Echtzeitfähigkeit wird zunächst bedingt dadurch, daß eine maximale
Antwortzeit *garantiert* werden kann - wie groß auch immer die sein
mag, und unabhängig davon, ob das im konkreten Fall reicht.

Die Frage kann man vorallem daran festmachen, ob ein Protokoll
Echtzeitfähigkeit von Haus auf garantiert. CAN enthält in der
Protokollspezifikation keine Mechanismen für Echtzeitfähigkeit
beim Buszugriff. Um den Bus echtzeitfähig zu bekommen, muß man
die Applikation mit Aufgaben belasten, die man auch in das Protokoll
hätte aufnehmen können. Zeitsteuerung alleine macht auch keine
Echtzeitfähigkeit. Bestes Beispiel MOST-Bus. Eigentlich TDMA, vom
Protokoll aber ganz klar auf Events ausgelegt.

Bei der Echtzeitfähigkeit spielt auch die Bitrate eine Rolle. Für
die physikalische Übertragung einer CAN-Nachricht bei 100 kBit/s
benötigt man bei max-Stuff-Bits 1,3 ms, bei 1 MBit/s hingegen
130 ľs.

Man kann also Echtzeit an zwei Punkten festmachen:

a) Latenzzeiten in der Datenübertragung aufgrund des Protokolls

b) Signalübertragungszeit aufgrund der physikalischen Ebene

Also haben wir uns alle auf diese grundsätzliche Frage gestürzt,
mangels genauerer Informationen des OP.

Übrinx hat sich das alles schon erledigt, war "nur" ne Klausuraufgabe...

Ich habe solche Klausuraufgaben zu CAN in meinem Studium auch gestellt
bekommen. CAN galt/gilt als echtzeitfähig im Kontext vom "schnell genug
für die Übertragung von Signalen".

Gruß,
Taso

 

[Willi Marquart]

Tilmann Reh <tilmannreh@despammed.com> wrote:

Echtzeitfähigkeit wird zunächst bedingt dadurch, daß eine maximale
Antwortzeit *garantiert* werden kann - wie groß auch immer die sein
mag, und unabhängig davon, ob das im konkreten Fall reicht.

Genau. "Deterministisch" ist da das Zauberwort. Deshalb können z.B.
Token passing als Zugriffsverfahren verwendende Protokolle
echtzeitfähig sein, auf CSMA/CD beruhende sind es mit Gewissheit
nicht.

Gruss Willi

 

[Rolf Bombach]

Willi Marquart wrote:

Echtzeitfähigkeit wird zunächst bedingt dadurch, daß eine maximale
Antwortzeit *garantiert* werden kann - wie groß auch immer die sein
mag, und unabhängig davon, ob das im konkreten Fall reicht.

Genau. "Deterministisch" ist da das Zauberwort. Deshalb können z.B.
Token passing als Zugriffsverfahren verwendende Protokolle
echtzeitfähig sein, auf CSMA/CD beruhende sind es mit Gewissheit
nicht.

Womit allerdings noch nichts über die durchschnittliche
oder typische Antwortzeit gesagt wäre :-]

--
mfg Rolf Bombach

 

[Vinzent 'Gadget' Hoefler]

Rolf Bombach wrote:

Willi Marquart wrote:

Echtzeitfähigkeit wird zunächst bedingt dadurch, daß eine maximale
Antwortzeit *garantiert* werden kann - wie groß auch immer die sein
mag, und unabhängig davon, ob das im konkreten Fall reicht.

Genau. "Deterministisch" ist da das Zauberwort. Deshalb können z.B.
Token passing als Zugriffsverfahren verwendende Protokolle
echtzeitfähig sein, auf CSMA/CD beruhende sind es mit Gewissheit
nicht.

Womit allerdings noch nichts über die durchschnittliche
oder typische Antwortzeit gesagt wäre :-]

Natuerlich nicht. Realtime-Anwendungen basieren fast ausnahmslos auf
Worst-Case-Betrachtungen.


Vinzent.