|
Latenzzeit
Bei jedem System sollte man als Entwickler die Grenzen kennen. Schauen Sie nur, wie intensiv und aufwändig Fahrwerke getestet werden, obwohl es ESP gibt. Und genau das ist beim
CAN-Bus gar nicht so einfach. Für hoch priorisierte Botschaften geht das noch, aber wie lange warten besonders niedrig priorisierte auf ihren Platz im Bus? Wie viele weitere Annahmen
braucht man, um das einigermaßen abschätzen zu können?
Das ist das Feld der Statistik. Denn z.B. die Anzahl von zusätzlichen Stopfbits hängt von der Datenfolge ab. Schlimmer aber ist tatsächlich die niedrige Priorität. Dabei kann in der
Wartezeit ein Teilnehmer eventuell sogar zwei Botschaften absetzen, wenn beide höhere Priorität haben und zwischendurch ebensolche von anderen Teilnehmern anstehen. Erst wenn
sozusagen die letzte wichtigere Botschaft durch ist, kann man die Wartezeit als sogenannte Latenzzeit annehmen, die Verzögerung zwischen Bereitschaft und tatsächlichem
Ausführungsbeginn.
Latenzzeit Zeit zwischen dem Senden eines und dem Empfangen der anderen
Teilnehmer |
Auch die Statistik braucht in diesem Fall eine Menge Variablen, z.B. alle Botschaften, deren Priorisierung und Länge. Dabei sind zusätzlich die zyklisch auftretenden wichtig, weil die
niedriger priorisierte zwischen deren Pausen einen Zugriff erhalten muss. Im Grunde muss es dann noch eine angenommene Wahrscheinlichkeit für die Häufigkeit des Versendens jeder
einzelnen Botschaft geben.
Timeout Die Durchführung kann in der vorgegebenen Zeit nicht beendet werden. |
Wer dann nicht mindestens einen Faktor für mögliche Teilausfälle und daraus resultierenden Wiederholungszeiten annimmt, rechnet an der Praxis vorbei. Und wenn die Berechnung
endlich möglich wurde, müsste sie eigentlich eine Höchstbegrenzung für das Netz ergeben, mit der es der Hersteller vor einer Überforderung durch nachträglich angeschlossene Geräte
schützen sollte.
Da taucht ein weiterer Vorteil eines CAN-Bus-Systems auf. Man kann nämlich die ganzen Daten einer entsprechend entwickelten Software geben und die rechnet entweder oder testet
die verschiedensten Szenarien durch. Am Ende weiß man, wo die Grenzen sind und erhält zudem noch eine Datenbasis für die nächste CAN-Bus-Applikation, ganz zu schweigen von
möglichen Standards und z.B. grafikunterstützten Eingabemöglichkeiten.
Eindeutig komplexer wird die Sache besonders bei schnellen Netzen, wenn die Verarbeitung innerhalb von Controller und Transceiver und zwischen den beiden nicht Schritt hält. Was hat
man ihnen in einer vom Anwender häufig nicht zu beeinflussenden Protokollschicht alles für Aufgaben zugedacht, weswegen jetzt das Netz nicht seinen Möglichkeiten entsprechend
genutzt wird.
Jitter Zeitliche Abweichung der Latenzzeiten
|
CAN-Bus | je nach Priorität |
FlexRay-Norm | 0,5 - 10 µs (0,0000005 - 0,00001 s) |
FlexRay-Praxis | 1 - 3 µs (0,000001 - 0,000003 s) |
|
|