www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik CAN: Statusnachrichten vs. Ereignisnachrichten


Autor: Se (Gast)
Datum:

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


Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

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

Autor: Gast (Gast)
Datum:

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

Autor: Gast (Gast)
Datum:

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

Autor: JochenZ (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Fabian Scheler (rosepeter)
Datum:

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

Autor: Gast (Gast)
Datum:

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

Autor: Se (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kennt jemand mal ne gute Literatur die erklärt was Ereignisnachrichten 
und Statusnachrichten genau sind?

Autor: Fabian Scheler (rosepeter)
Datum:

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

Autor: Fabian Scheler (rosepeter)
Datum:

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

man sollte dabei aber immer im Auge behalten, dass Kopetz natürlich die 
Time-Triggered Architecture verkaufen möchte.

Ciao, Fabian

Autor: Se (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jo, die hab ich alle schon gelesen. Na gut, das ist wohl schon das beste 
was zu finden ist.

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.