CAN-Bus-Charakterisierung mit dem Oszilloskop Arbitrierung unter der Lupe

Der symmetrische CAN-Bus, der häufig in Kraftfahrzeugen zur Steuerung des Antriebs und weiterer Kraftfahrzeugelemente eingesetzt wird, basiert auf der asynchronen Übertragung von Datenpaketen. Dadurch kollidieren Pakete häufig, was wiederum Meldungen niedrigerer Priorität ausbremsen kann. Dem sollte ein Arbitrierprozess abhelfen, was jedoch nicht immer klappt.

Die asymmetrische Übertragung läuft über zahlreiche Knoten. Pakete kollidieren genau dann, wenn zwei Knoten gleichzeitig senden wollen. Treten solche Kollisionen auf, kann es Verzögerungen bei der Übertragung von Meldungen niedrigerer Priorität geben. Dies ist der Fall, obwohl es einen Arbitrierprozess auf Bit-Ebene gibt, der bestimmt, welche CAN-Meldung die höchste Priorität hat. Weiterhin können bei hoher Buslast Fehler auf dem CAN-Bus auftreten.

Bild 1 verdeutlicht die Funktionsweise der Arbitrierung auf Bit-Ebene. Wenn zwei oder mehr Knoten gleichzeitig oder fast gleichzeitig mit dem Senden eines Datenpakets beginnen, bestimmt die Arbitrierung, welches Datenpaket die höchste Priorität hat und daher weiter übertragen werden soll. Wenn der Low-Pegel am symmetrischen CAN-Bus als dominant interpretiert wird, verhalten sich mehrere Knoten wie ein logisches UND (»wired AND«).

Bei einem dominanten »Low« werden niedrige Pegel als logische Nullen interpretiert und hohe Pegel als logische Einsen. Sind alle übertragenen Bits »High« (Eins), herrscht auf dem Bus hoher Pegel. Ist mindestens eins von mehreren übertragene Bits »Low« (Null), so zieht es den Bus in den dominanten Zustand, also auf »Low«. Deshalb setzt sich immer der Knoten mit der niedrigsten Frame-ID bei der Arbitrierung durch. Im abgebildeten Beispiel hat Knoten 2 eine geringere Frame-ID als die Knoten 1 und 3, oder anders gesagt: Die Frame-ID von Knoten 2 fängt mit mehr Nullen an, die den Bus länger auf »Low« halten als die Datenpakete der Knoten 1 und 3. Daher wird sich immer Knoten 2 (mit der niedrigsten Frame-ID) gegen Knoten 1 und 3 (mit höherer Frame-ID) bei der Arbitrierung durchsetzen.

Sendende Knoten senden nicht nur Bits, sondern prüfen auch kurz vor Ende jeder Bitzeit (etwa bei 75% der Bitzeit) den Pegel auf dem Bus. Senden sie selbst eine Eins, lesen aber eine Null vom Bus, wissen sie, dass es einen oder mehrere andere Knoten geben muss, die ihnen gegenüber Vorrang haben. Im dargestellten Beispiel sendet Knoten 1 für das Bit 6 eine Eins, liest dann aber eine Null vom Bus. Also überlässt Knoten 1 ab dem Bit 5 die Kontrolle über den Bus den anderen sendenden Knoten. Knoten 1 muss nun warten, bis der aktuell gesendete Frame fertig übertragen ist, bevor er einen zweiten Versuch unternehmen kann, seine Daten zu senden.

Nachteile der Arbitrierung

Arbitrierung auf Bit-Ebene funktioniert gut, sie hat aber bei asynchronen seriellen Bussen wie etwa dem CAN-Bus den Nachteil, dass entscheidende Kommunikationspakete oft nur verzögert gesendet werden können. Wenn zudem die Buslast hoch ist (der Prozentsatz der Zeit, in der tatsächlich gesendet wird, im Verhältnis zur Gesamtzeit einschließlich Wartephasen), steigt die Zahl der Buskollisionen. Das erhöht theoretisch sowohl die Bitfehlerrate (BER) als auch die Fehlererholungszeit. Automobil¬ingenieure streben daher an, die Last am CAN-Bus möglichst unter 30% zu halten. Weil die Bordelektronik heutiger Kraftfahrzeuge aber immer komplexer wird, wird bei Kfz-Datennetzen teilweise zu CAN-FD übergegangen (das verringert die Buslast) oder zum zeitgetriggerten/synchronen FlexRay-Bus, wo Arbitrierung und Buslast kein Thema mehr sind.

Wie sieht Arbitrierung denn aus? Bild 1 zeigt die allgemeine Situation. Die rote Kurve zeigt den Logik¬pegel auf dem symmetrischen CAN-Bus. Eine Eins ist »High«, eine Null ist »Low«, es gibt nichts dazwischen, darüber und darunter. Der Bus sieht aus wie auf einem Logik- oder einem Protokollanalysator. Auf einem Oszilloskop aber bietet sich ein ganz anderes Bild.

Bild 2 zeigt die Aufzeichnung eines CAN-Bus-Frames auf einem Oszilloskop mit einer sehr hohen Signalaktualisierungsrate. Das Oszilloskop wurde so eingestellt, dass es auf ein bestimmtes Datenpaket triggert und dann die Symbole auf dem Bus mit Hilfe einer .dbc-Datei dekodiert, die dieses spezielle CAN-Datennetz beschreibt. Das Datenpaket, auf welches das Oszilloskop im Beispiel triggert, heißt »Brake_Torque« (Bremsmoment) und trägt die Frame-ID 0x211 (HEX) beziehungsweise 0010 0001 0001 (binär). Bei der Übertragung dieses Frames trat Arbitrierung auf. Das sieht man daran, dass am Beginn des Datenpakets Pegel unterhalb des normalen Low-Pegels vorkommen. Die Erklärung dieser »tiefen Low-Bits« ist am Ende des Frames zu finden.

Am Ende jedes Frames sollten alle Knoten mit einem Bestätigungsbit den fehlerfreien Empfang des gerade übertragenen Frames bestätigen. Ziehen alle Knoten gleichzeitig den Bus auf einen dominanten Low-Pegel, ziehen sie mehr Strom aus dem Bus, als es ein einzelner Knoten könnte. Daher geht der Bus auf einen niedrigeren Pegel herunter, quasi auf ein »Low-Low«. Das gleiche Phänomen tritt am Anfang des Frames auf, wenn mehr als ein Knoten den Zugang zum Bus übernehmen will. Betrachtet man die Messung genau, erkennt man drei verschiedene Low-Pegel am Anfang des Frames. Das bedeutet, dass mindestens drei Knoten versucht haben, Zugang zum Bus zu bekommen – letztlich aber gewinnt immer die Meldung »Brake_Torque«, auf die wir in diesem Beispiel triggern und die wir darstellen möchten. Nach wenigen der höchstwertigen Bits des ID-Feldes übernimmt die Frame-ID 0x211 die Kontrolle über den Bus. Dann liegt der Pegel des dominanten Low auf dem Wert, den Frame-ID 0x211 allein erzeugen kann (also auf einem normalen Low-Pegel). Wie häufig aber tritt Arbitrierung bei dieser speziellen Meldung »Brake_Torque« auf?

Triggerung auf Arbitrierung

Um die Häufigkeit der Arbitrierung zu ermitteln, muss das Oszilloskop so eingestellt werden, dass es ausschließlich auf die Meldung »Brake_Torque« triggert, und zwar nur dann, wenn zusätzlich Arbitrierung vorliegt. Das Oszilloskop muss somit Ereignisse ausfiltern können, bei denen dies nicht auftritt. Mit einem Oszilloskop, das über eine CAN-Trigger- und -Dekodieroption verfügt, lässt sich recht einfach auf Frame-ID 0x211 triggern. Viele Oszilloskope auf dem Markt verfügen heute über eine solche Funktion. Das Triggern ist sogar noch einfacher, wenn das Oszilloskop eine .dbc-Datei importieren kann. Dann ist es möglich, symbolisch auf den CAN-Bus zu triggern, also auf einem höheren Abstraktionsniveau. Über diese erweiterte Funktion verfügen nur wenige Oszilloskope auf dem Markt. Bietet ein Gerät diese Funktion, kann der Anwender den Namen der betreffenden Meldung aus einer Liste auswählen, in der alle gültigen Meldungen vordefiniert verzeichnet sind, und braucht keine Bit-Strings einzugeben. Auf die Kombination zu triggern, also auf den Frame 0x211 oder die Meldung »Brake_Torque« und zwar nur dann, wenn zusätzlich Arbitrierung auftritt, das geht mit den allermeisten verfügbaren Oszilloskopen entweder überhaupt nicht oder nur mit großem Aufwand. Verfügt ein Oszilloskop allerdings über einen Zonentrigger, dann ist diese Art des Triggerns nicht nur möglich, sondern sogar ausgesprochen einfach.

Das Beispiel in Bild 3 zeigt, wie das Oszilloskop nur dann auf die Meldung »Brake_Torque« reagiert, wenn zusätzlich Arbitrierung auftritt. Dazu wird erst auf die Meldung getriggert. Danach wird der Trigger so modifiziert, dass auf dem kapazitiven Touchscreen des Oszilloskops ein Rechteck über den Low-Low-Bits am Anfang des Frames liegt (siehe den gelb schraffierten Kasten unten links auf dem Bildschirm des Oszilloskops). In den Eigenschaften des Kastens wird angegeben: 
»must intersect«.

Beim genaueren Betrachten der ersten paar Bits des Frames wird deutlich, dass die dominanten Low-Pegel stets tiefer liegen als die normalen Low-Pegel. Damit triggert das Oszilloskop nicht auf Frames ohne Arbitrierung (denn bei diesen sind die betreffenden Bits ja auf normalem Low-Pegel). Es ist auch möglich, ausschließlich auf die Meldung zu triggern, wenn keine Arbitrierung auftritt. Auch dafür wird der Zonentrigger verwendet, in dessen Eigenschaften nun aber »must not intersect« eintragen wird. Wiederum filtert der gleiche Zonentrigger die arbitrierten Bits aus, zeigt dann aber nur Frames mit nicht-arbitrierten ID-Bits.

Nachdem das Oszilloskop, nun so konfiguriert ist, dass es selektiv auf bestimmte Meldungen triggert (hier »Brake_Torque«) wenn zusätzlich Arbitrierung auftritt, geht es nun darum, wie mit segmentiertem Speicher die Häufigkeit der Arbitrierung bestimmt wird. Viele heutige Oszilloskope verfügen über eine solchen Speicher, er heißt bei verschiedenen Herstellern nur immer wieder anders (beispielweise segmentierbarer Speicher, Sequenz¬modus, FastFrame, History Mode etc.).

Häufigkeit aus segmentiertem Speicher

Angenommen, es steht ein Oszilloskop mit einem extrem tiefen Speicher zur Verfügung, dann ließe sich die Häufigkeit der Arbitrierung ganz einfach bestimmen: Der CAN-Bus würde einfach ganz lang am Stück aufgezeichnet werden. Danach ließe sich die Aufzeichnung visuell auf arbitrierte Bits in einem bestimmten Frame prüfen und die Zeiten zwischen den einzelnen Vorkommnissen messen. Das wäre sehr zeitaufwendig, außerdem wäre ein High-Performance-Oszilloskop mit vielen hundert Megabyte Datenspeicher notwendig. Es geht aber auch0 einfacher.

Eine Daueraufzeichnung übertragener CAN-Daten nutzt den Datenspeicher eines Oszilloskops denkbar ineffizient. Die bessere Methode ist, den Speicher zu segmentieren. Das Oszilloskop kann beispielsweise so eingestellt werden, dass es selektiv den Frame oder die Meldung aufzeichnet, die von Interesse ist. Für jedes einzelne (und jedes folgende) entsprechende Ereignis braucht das Oszilloskop nur wenig Speicher. Auf diese Weise kann es mit relativ wenig Speicher verhältnismäßig lange aufzeichnen.

Bild 4 zeigt die Aufzeichnung von hundert aufeinanderfolgenden Ereignissen, bei denen die Meldung »Brake_Torque« übertragen wurde und Arbitrierung vorgekommen ist. Der Zonentrigger erfasst die Arbitrierbits. Das Symbollistenfenster in der oberen Hälfte des Bildschirms zeigt die Zeit zwischen den einzelnen Ereignissen. Dieses Fenster könnte auch so eingestellt werden, dass es die absolute Zeit zwischen dem aktuellen und dem ersten Ereignis anzeigt. Durch alle aufgezeichneten Frames kann der Entwickler durchscrollen und jede gespeicherte Messkurve einzeln beurteilen.

In der Liste der hundert aufeinanderfolgenden »Brake_Torque«-Meldungen mit Arbitrierung trat der letzte gespeicherte Frame (Segment 100) fast fünf Sekunden nach dem ersten auf (Segment 1). Wäre diese Aufzeichnung nicht segmentiert durchgeführt worden, sondern kontinuierlich, wäre ein Oszilloskop mit einem Speicher von über 300 Millionen Punkten erforderlich gewesen. Sinnvoll ist also ein Oszilloskop mit hoher Signalaktualisierungsrate, damit es auch ein seltenes Auftreten der Arbitrierung erfassen kann, Triggerung auf CAN-Frames/Meldungen, einem Zonentrigger, um Frames mit Arbitrierung von solchen ohne zu unterscheiden, sowie segmentierbarer Speicher mit präzisen Zeitstempeln, damit es das wiederholte Auftreten von Frames oder Meldungen mit Arbitrierung selektiv erfassen kann.

Über die Autoren:

Johnnie Hancock ist Produktmanager im Geschäftsbereich Oszilloskope und Florian Stadler ist Applikationsingenieur im technischen Support, beide bei Agilent Technologies.