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.
kennt jemand mal ne gute Literatur die erklärt was Ereignisnachrichten und Statusnachrichten genau sind?
> 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
jo, die hab ich alle schon gelesen. Na gut, das ist wohl schon das beste was zu finden ist.
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.