Da CAN kommplett ereignisgesteuert arbeitet, sind zwangsläufig alle
Nachrichten Ereignisnachrichten.
Aber es gibt ja im Automobil auch Statusnachrichten, die regelmäßig über
den Bus flitzen. WIe ist das bei denen mit der Dringlichkeit? Müssten
diese dann nicht immer eine höhere Prio bekommen als die
Ereignisnachrichten?
Welche Art Nachrichten sind wichtiger? Ein Status über den Tankinhalt
kann ja auch nicht einfach so den Vorrang gegenüber einem Bremsbefehl
erlangen.
Andererseits sind Regelungen auf Statusnachrichten angewiesen und
brauchen diese ohne viel Verzögerung. OK, Regelungen ist nix für CAN.
Mir fällt grad kein Beispiel ein.
Also wenn jemand dort bissl Insider ist, und man einen Tipp springen
lassen könnte...
wör supper
Das hat nichts mit CAN zu tun. Das hängt alles vom Protokoll ab.
CANOPEN zb sollte zyklische Nachrichten schicken können.
Und CAN ist keineswegs für Regelungen ungeeignet.
Vielleicht solltest du dir über die Begriffe nicht so viele Gedanken
machen. In CAN sind erst mal alles nur Nachrichten. Die ID bestimmt,
welche Priorität die Nachricht hat (das ist wichtig, wenn zwei
Nachrichten zur gleichen!! Zeit senden wollen).
Das mit deinen Status oder Ereignisnachrichten kannst du dann in deiner
Applikation regeln. Die beiden Begriffe kann man, denke ich, auch nicht
ganz trennen. Der Status des Bremspedal kann ja auch als Bremssignal
gedeutet werden. Insgesamt legt man den CAN-Bus so aus, dass im
Nominalfall max. Buslast/Busauslastung auftreten und dann hofft man,
dass dadurch auch die Notfälle, wenn zufällig mal mehr Nachrichten
gesendet werden noch im Rahmen bleiben.
Das ganze wird normalerweise umfangreich getestet, bevor ein Fahrzeug
frei gegeben wird.
Für Regelungen ist CAN auf jeden Fall geeignet. Je nach Anforderung. Man
muss halt mit dem Jitter (Zeitverzug bei Sendewunsch, wenn noch eine
Nachricht auf dem Bus zu Ende gesendet wird und/oder eine höher
priorisiert Nachricht zuvor gesendet wird) in der konkreten Aufgabe
zurecht kommen.
Der Gast.
ups...hab ich mal nicht die Vorschau benutzt und gleich den ersten
Fehler gefunden. Das muss heissen, dass man den Bus auf max. 50%
Busauslastung auslegt. Den Antriebs-CAN wahrscheinlich sogar weniger.
Guten Abend,
nicht ohne Grund haben Oberklassefahrzeuge 5 CAN-Busse damit die Buslast
nicht zu hoch wird.
Für Regelungen lässt man in den Nutzdaten noch ein Messagecounter (z.B.4
Bit) mitlaufen, wenn da mal ne zyklische Botschaft ausbleibt, kann die
Regelung darauf reagieren (extrapolieren).
Wichtige Botschaften werden mit einer XOR-Checksumme und ganz wichtige
Botschaften zusätzlich mit einer CRC-Checksumme abgesichert. Wer jetzt
nachgerechnet hat: von den 8Byte Nutzdaten gehen 2,5Byte zur
Botschaftsabsicherung verloren :-(
Ereignisnachrichten werden im Automotive-Bereich glaub eh nicht so oft
verwendet (zumindest, was ich bisher gesehen hab). Da wird der
Bremspedalstatus alle 10ms gesendet, obwohl nicht gebremst wird.
Flexray soll die Nachteile von CAN lösen und kommt so langsam auch in
Fahrzeugen in Serie.
Gruss
Jochen
Dem CAN-Bus ist es völlig wurscht, wie Du die Nachrichten bezeichnest.
Er kennt keine Ereignisnachrichten oder Statusnachrichten.
Das sind dann höhere Schichten über dem CAN-Bus, die den Nachrichten
eine bestimmte Bedeutung zuordnen.
Der Vorteil des CAN ist, man kann jeder Nachricht eine Priorität geben
und damit deren Aussendung garantieren.
Der Nachteil des CAN ist, man kann ihn mit hochpriorisierten Nachrichten
dichtmachen.
Jede hochpriorisierte Nachricht muß also einen genügend langen
Zeitschlitz lassen, damit die anderen auch drankommen. Die Zeitschlitze
werden mit abnehmender Priorität immer größer.
Man muß also ein CAN-Netzwerk planen und kann nicht darauf vertrauen,
daß alle Nachrichten schon irgendwie ankommen werden.
Peter
Hallo zusammen,
da gebe ich doch auch mal meinen Senf dazu
> Das mit deinen Status oder Ereignisnachrichten kannst du dann in deiner> Applikation regeln. Die beiden Begriffe kann man, denke ich, auch nicht> ganz trennen.
doch diese beiden Begriffe kann man trennen. Ereignisnachrichten tragen
Ereignissemantik, Zustandsnachrichten nicht. In ereignisgesteuerten
Systemen dürfen Ereignisse unter keinen Umständen verloren gehen, das
könnte (je nach Ereignis) zum Systemausfall führen. Das interessante an
Ereignisnachrichten ist auch, dass mit ihnen auch ein Kontrollfluss
verbunden (teilweise auch bidirektional) ist, wohingegen
Zustandsnachrichten nur mit einem Datenfluss verknüpft (ausschließlich
unidirektional) sind .
So richtig Sinn macht diese Diskussion aber erst, wenn man das
Kontrollparadigma auf den jeweiligen Knoten mit in Betracht zieht, so
macht es z.B. nur begrenzt Sinn Ereignisnachrichten an einen
zeitgesteuerten Knoten zu schicken.
> Dem CAN-Bus ist es völlig wurscht, wie Du die Nachrichten bezeichnest.> Er kennt keine Ereignisnachrichten oder Statusnachrichten.> Das sind dann höhere Schichten über dem CAN-Bus, die den Nachrichten> eine bestimmte Bedeutung zuordnen.
ack
> Der Vorteil des CAN ist, man kann jeder Nachricht eine Priorität geben> und damit deren Aussendung garantieren.> Der Nachteil des CAN ist, man kann ihn mit hochpriorisierten Nachrichten> dichtmachen.> Jede hochpriorisierte Nachricht muß also einen genügend langen> Zeitschlitz lassen, damit die anderen auch drankommen. Die Zeitschlitze> werden mit abnehmender Priorität immer größer.>> Man muß also ein CAN-Netzwerk planen und kann nicht darauf vertrauen,> daß alle Nachrichten schon irgendwie ankommen werden.
ack - eben das macht die Arbitierung halt etwas schwieriger, man muss
immer das komplette (evtl. komplexe) System betrachten (inkl. der
einzelnen Systemkomponenten selbst), sobald sich eine Komponente ändert,
muss ich das erneut tun (Stichwort End-to-End-Timing).
Zeitgesteuerte Kommunikationssysteme (TDMA, global synchronisierte Uhren
- z.B. TTCAN, FlexRay) sind hier hinsichtlich der Zusammensetzbarkeit
wesentlich besser geeignet: globalen Kommunikations-Schedule aufstellen,
der im Einklang mit der zeitlichen Schnittstelle der Komponenten steht.
Kommt eine neue Komponente hinzu, stellt man den globalen Schedule
erneut auf, ohne die einzelnen Komponenten betrachten zu müssen.
Ciao, Fabian
>Ereignisnachrichten tragen>Ereignissemantik, Zustandsnachrichten nicht. In ereignisgesteuerten>Systemen dürfen Ereignisse unter keinen Umständen verloren gehen, das>könnte (je nach Ereignis) zum Systemausfall führen.
Das ist für die Übertragung aber unwichtig. Du kannst auch Nachrichten,
die eigentlich nur zufällige Änderungen enthalten (Ereignisse) zyklisch
senden. Die möglichen Empfänger wissen dann zumindest, dass der Sender
noch da ist, und die Interpretation des Inhaltes wird dann in deiner
Nachricht durchgeführt.
Neue Nachrichten bei z.B. Flexray einbinden ist auch nicht so einfach.
Man muss nämlich doch jeden Teilnehmer anfassen und ihm den neuen Zyklus
mitteilen (es ändert sich ja die Telegrammlänge, vielleicht wurde auch
die Zykluszeit angepasst). Bei CAN ist das viel einfacher - nach dem
Motto "Eine weitere Botschaft alle 100ms wird schon noch gehen,
hautpsache die ID ist eindeutig." ;-)
der Gast.
> Das ist für die Übertragung aber unwichtig. Du kannst auch Nachrichten,> die eigentlich nur zufällige Änderungen enthalten (Ereignisse) zyklisch> senden. Die möglichen Empfänger wissen dann zumindest, dass der Sender> noch da ist, und die Interpretation des Inhaltes wird dann in deiner> Nachricht durchgeführt.
Für die funktionale Eigenschaft (also Datum kommt von Knoten A zu Knoten
B) einer Übertragung gebe ich dir recht, für die zeitlichen
Eigenschaften nicht, weil dir hier die Arbitrierung einen Strich durch
die Rechnung machen kann.
> Neue Nachrichten bei z.B. Flexray einbinden ist auch nicht so einfach.> Man muss nämlich doch jeden Teilnehmer anfassen und ihm den neuen Zyklus> mitteilen (es ändert sich ja die Telegrammlänge, vielleicht wurde auch> die Zykluszeit angepasst). Bei CAN ist das viel einfacher - nach dem> Motto "Eine weitere Botschaft alle 100ms wird schon noch gehen,> hautpsache die ID ist eindeutig." ;-)
Ich behaupte nicht, dass es "einfach" ist einen globalen
FlexRay-Schedule aufzustellen (im Gegenteil), aber nehmen wir doch mal
folgendes Szenario an: wir haben ein (weitgehend) funktionierendes
System, auf einem Knoten muss aber (aus irgendeinem Grund) eine Änderung
vorgenommen werden, die dazu führt, dass eine Nachricht zu einem anderen
Zeitpunkt gesendet wird (man kann auf dem betroffenen Knoten sogar
"schneller" werden - also früher senden), zusammen mit der Arbitrierung
kann dies unter Umständen dazu kommen, dass die zeitlichen Verhältnisse
auf dem CAN-Bus total kippen und irgendwo im System wird wegen der
daraus resultierenden Delays bei der Übertragung anderer Nachrichten
eine Deadline verpasst.
Das Problem existiert bei zeitgesteuerten Bussystemen einfach nicht,
solange man die zeitliche Schnittstelle der einzelnen Knoten garantieren
kann - ok, ändert sich die, hat man auch hier Aufwand.
Das Problem, dass man bei CAN also hat, ist gewisse Knoten an bestimmten
Zeitpunkten vom Senden abzuhalten, damit den Bus zu blockieren
... hm, ich merke gerade, dass ich die ganze Zeit argumentiere, dass es
mit CAN schwierig ist, zeitliche Garantien für die Übertragungszeit
abzugeben, was mit der ursprünglichen Diskussion Ereignisnachricht vs.
Zustandsnachricht relativ wenig zu tun hat. Man kann durchaus
Zustandsnachrichten über CAN übertragen, aber man tut sich halt schwer
die zeitliche Akkuratheit zu garantieren.
Na gut, sei's drum - dann wünsche ich mal noch eine gute Nacht!
Ciao, Fabian
> kennt jemand mal ne gute Literatur die erklärt was Ereignisnachrichten> und Statusnachrichten genau sind?
ich würde folgendes empfehlen:
Kopetz, Real-Time Systems, Design Principles for Distributed Embedded
Applications
Obermaisser, Event-Triggered and Time-Triggered Control Paradigms
Kopetz, Event-Triggered versus Time-Triggered Real-Time Systems
http://www.vmars.tuwien.ac.at/php/pserver/extern/docdetail.php?DID=566&viewmode=paper
man sollte dabei aber immer im Auge behalten, dass Kopetz natürlich die
Time-Triggered Architecture verkaufen möchte.
Ciao, Fabian
