Hallo, ich habe mal eine eher theoretischere Frage. Und zwar geht es mir darum Verzögerungszeiten für Telegramme zu berechnen. Angenommen jedes Telegramm ist 120 Bit lang und der BUS arbeitet mit einer Baudrate von 100kbit/s. Dann braucht ja ein Telegramm zur Übertragung 4,8ms. Jetzt hat der Bus 4 Teilnehmer, die 4 Telegramme senden wollen. Das Telegramm 1 hat eine Priorität von 1 und eine Abtastzeit von 10ms Telegramm 2: Priorität:3 Abtastzeit: 20ms Telegramm 3: Priorität:4 Abtastzeit: 15ms Telegramm 4 Priorität:2 Abtastzeit: 10ms Ersteinmal zur Funktionsweise, ob ich das richtig verstanden habe. Beim CAN Bus legt man vorher fest, welches Telegramm welche Priorität hat. Entsprechend wird zuerst das Telegramm mit der Priorität 1 gesendet, dann 2... Aber was ist jetzt die Abtastzeit. Ist das das Intervall, in welchem die Teilnehmer die Telegramme senden? Also zuerst wird Telegramm 1 gesendet. Es sind 4,8ms Vergangen. Als nächstes wird Telegramm 4 versendet. Es sind 9.6ms vergangen. Jetzt kommt Telegramm 2 und es sind 14,4 Sekunden vergangen. Jetzt wäre das Telegramm 4 dran. Allerdings liegen schon wieder neue Daten für Telegramm 1 und 4 vor. Wird jetzt wieder das Telegramm 1 gesendet? Oder erst mal das Telegramm 4? Es wäre nett, wenn da jemand mit etwas Erfahrung etwas zu sagen könnte. Ich beschäftige mich erst seit kurzem mit Bussystemen. Gruß
Ralf schrieb: > Beim > CAN Bus legt man vorher fest, welches Telegramm welche Priorität hat. Kann man bei einigen Chips (in der chipeigenen Software) so machen. Das gilt dann aber nur in der Sende-Queue des einzelnen Chips! Auf dem Bus ist es aber grundsätzlich so, daß die CAN-ID die Priorität enthält. Je kleiner die ID, desto höher die Priorität. Kann man gut unter Busarbitration nachlesen; damit wird die Priorität auf dem Bus auch gesteuert. Die CAN-ID beinhaltet im Standard auch keine Adresse, sondern gibt Aufschluß über den Inhalt (und damit implizit über die Priorität) der Nachricht. Man kann das natürlich in der eigenen Software alles umbiegen; auf dem Bus mit dem Transceiver gilt aber die CAN-ID als einziges Kriterium für die Priorität.
Wenn zwei Telegramme um den Bus konkurrieren, wird immer das Telegramm mit der niedrigsten Adresse gesendet. Der Busteilnehmer der unterliegt versucht es danach noch einmal. Bei deinem Entwurf kann man sehen, dass es zu Problemen kommt, da die beiden 10 ms Telegramme praktisch den ganzen Bus belegen. Deshalb sollte in der Praxis die Busauslastung unter 50 % gehalten (CiA Empfehlung, wird bei sorgfältigen Design auch überschritten) werden. In deinem Fall könntest z. B. auf 250 KBit/s gehen.
Wobei immer die Frage ist, ob es wirklich nötig ist, alle 10ms etwas/dasselbe zu versenden.
Ich hab es mal kurz in den Taschenrechner eingegeben, also falls mein Ergebnis nicht stimmt liegt es an der Technik ;-) 100kBit/s = 100.000Bit/s (?) --> 0,000.01s/Bit --> 0,0012s/120Bit --> 1,2ms je Botschaft --> du hast in deinem Beispiel eigentlich noch Luft. Vom Prinzip hast du aber recht, wenn der Bus zu mehr als 100% verplant ist, kommen deine niederwertigen Botschaften nicht mehr/kaum noch durch.
Antworter schrieb: > Vom Prinzip hast du aber recht, wenn der Bus zu mehr als 100% verplant > ist, kommen deine niederwertigen Botschaften nicht mehr/kaum noch durch. Bei mehr als 100% Busauslastung (natürlich nur theoretisch möglich) können auch die höchstprioritären Telegramme nicht (alle) durchkommen. Das ist so nicht verhersagbar. Hängt ja von der Mischung der Anzahl und der Prioritäten der Telegramme ab. Und die 120 bit pro Telegramm kann man wegen dem stuffing auch nicht (pauschal) als fix ansehen; ist ID- und Nutzdatenbyteabhängig. CAN wird im Detail sehr schnell viel komplexer als man ahnt!!!
Danke für die Antworten. Also das Beispiel hat keinen praktischen Hintergrund. Wir haben den CAN Bus nur kurz in der Vorlesung gehabt und auch keine Übungen dazu gehabt. Deswegen versuche ich mich gerade für die anstehende Klausur ein wenig in die Thematik einzuarbeiten. Noch einmal etwas Grundsätzliches. Also beim CAN-Bus muss ich quasi beim Entwurf alle möglichen Telegramme nach Wichtigkeit sortieren und eine Priorität vergeben. Eine dynamische Vergabe derer ist ja nicht möglich, da die Teilnehmer ja nie wissen, was für Prioritäten auftreten können. Nur so kann ja eine Doppelbelegung von Prioritäten vermieden werden. Mal ein hypothetisches Beispiel. Beim Entwurf der KFz Elektronik gebe ich zum Beispiel dem Ereignis "Ich bin wo angefahren, öffne bitte den Airbag" (ausgelöst z.B. durch Beschleunigungssensoren) die höchste Priorität, also 1. Da habe ich zum Beispiel noch einen Tankfüllstandsensor. Das Telegram Tank fast leer kommt also wesentlich weiter hinten in der Prioritätsliste etc. Noch einmal zum Beispiel. @Antwortender du hast Recht, ich habe mich irgendwie im Rechner vertippt. Also noch einmal, der Ablauf, wie ich ihn mir vorstelle:
1 | t/ms Beschreibung |
2 | ------------------------------ |
3 | 0 Start des Systems |
4 | 1,2 Telegramm 1 fertig |
5 | 2,4 Telegramm 4 fertig |
6 | 3,6 Telegramm 2 fertig |
7 | 4,8 Telegramm 3 fertig |
8 | 10 Neue Daten bei 1 und 4 |
9 | 11,2 Telegramm 1 fertig |
10 | 12,4 Telegramm 4 fertig |
11 | 15 Neue Daten bei 3 |
12 | 16,2 Telegramm 3 fertig |
13 | 20 Neue Daten bei 1,2 und 4 |
14 | . |
15 | . |
16 | . |
Kommt das so hin?
Wie kommst du eigentlich auf die angegebenen 4,8 ms Übertragungszeit? Bei den 120 bit bin ich noch bei dir, bei t = 120 bit / (10^5 bit/s) komme ich aber auf 1,2 ms.
Dabei ist noch zu beachten, dass ein Telegramm, das grade gesendet wird immer zu Ende gesendet wird, bevor das nächste eine Chance hat. Das hätte zur Folge, dass dein Airbag nicht auslöst, wenn der Füllstand andauernd gesendet werden würde und der Airbag nicht "dazwischen" kommt.
> Dabei ist noch zu beachten, dass ein Telegramm, das grade gesendet wird > immer zu Ende gesendet wird, bevor das nächste eine Chance hat. Das > hätte zur Folge, dass dein Airbag nicht auslöst, wenn der Füllstand > andauernd gesendet werden würde und der Airbag nicht "dazwischen" kommt. Falsch CAN features an automatic arbitration-free transmission. A CAN message that is transmitted with highest priority will succeed, and the node transmitting the lower priority message will sense this and back off and wait. Quelle: http://en.wikipedia.org/wiki/Controller_area_network
Werner schrieb: >> Dabei ist noch zu beachten, dass ein Telegramm, das grade gesendet wird >> immer zu Ende gesendet wird, bevor das nächste eine Chance hat. > > Falsch Nicht falsch. Die Arbitrierung findet nur während der Übertragung der Identifier statt. Wenn die Arbitrierung abgeschlossen ist, gehört dem Gewinner der Bus, bis er ihn wieder mit "End of Frame" freigibt. Dann warten alle nodes noch die 3 bit "Intermission Frame Space" ab. Danach versuchen alle wieder gleichzeitig, mit "Start of Frame" ihre Nachricht loszuwerden und die Arbitrierung beginnt, während jeder seinen Identifier zur gleichen Zeit sendet, von neuem. Wie sollte der sendende node (oder irgend ein anderer Busteilnehmer) in einer laufenden Übertragung auch sonst merken, daß irgendwer eine Nachricht mit einer höheren Priorität senden will? Die Arbitrierung kann ja nur in der Übertragung der Identifier stattfinden, da dies in einem Frame der einzige "Ort" ist, in dem auf dem Bus die Prioirität einer Nachricht enthalten ist. Jeder node kann innerhalb seines Chips die Priorität ändern, wie er Lust hat. Obwohl er, wenn er als CAN-konform verkauft werden will, auch die Priorisierung nach dem Identifier bieten muß. Zusätze sind immer erlaubt. Aber das gilt nur im Chip. Auf dem Bus gilt uneingeschränkt der Standard. Sonst könnte CAN ja auch gar nicht so funktionieren und wäre nicht so zuverlässig. Die englische Aussage ist an der Stelle vielleicht etwas unglücklich formuliert; es sollte deutlich gemacht werden, daß dies nur in dem Teil gilt, während alle ihre Identifier senden. Und das tun alle zur gleichen Zeit; nur so kann es auch funktionieren.
Sven H. schrieb: > Dabei ist noch zu beachten, dass ein Telegramm, das grade gesendet wird > immer zu Ende gesendet wird, bevor das nächste eine Chance hat. Soweit richtig. > Das hätte zur Folge, dass dein Airbag nicht auslöst, wenn der Füllstand > andauernd gesendet werden würde und der Airbag nicht "dazwischen" kommt. Hier aber nicht mehr. Denn jeder Frame arbitriert neu, d.h. auf den Tankinhalt folgt der höher priorisierte Airbag. Da die Länge des Frames limitiert ist, ist die maximale Verzögerung klar definiert.
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.