DBC-Byte-Reihenfolge: Intel gegen Motorola, Startbit und Skalierung

DBC ist ein reines Textdatenbankformat, das von Vector zur Beschreibung von CAN-Netzen eingeführt wurde. Es enthält nicht die Frames selbst, sondern deren Interpretation. Eine Botschaft wird mit BO_ deklariert, gefolgt von Identifier, Name, DLC und Senderknoten. Signale hängen daran als SG_-Zeilen; CM_ fügt Kommentare hinzu, BA_ Attribute wie die Zykluszeit GenMsgCycleTime, VAL_ definiert Wertetabellen für Enumerationen und BO_TX_BU_ nennt zusätzliche Sender. Reale Dateien sind häufig in Windows-1252 oder GBK kodiert: Ein Parser, der nur UTF-8 annimmt, beschädigt stillschweigend Signalnamen und Kommentare. Eine tolerante Kodierungserkennung gehört daher zu einer zuverlässigen DBC-Auswertung.

Eine SG_-Zeile enthält fast alles, was zum Extrahieren eines Wertes nötig ist: Signalname, Startbit, Bitlänge, Byte-Reihenfolge-Kennung, Vorzeichen, Faktor und Offset, Minimum und Maximum, Einheit sowie die Liste der Empfänger. Die Kennung ist entweder @1 für Intel (Little-Endian) oder @0 für Motorola (Big-Endian). Ein Minuszeichen hinter der Länge bedeutet, dass die Rohzahl vorzeichenbehaftet ist und vor der Skalierung vorzeichenerweitert werden muss. In den runden Klammern stehen Faktor und Offset, in den eckigen der Anzeigebereich. Alles danach ist Metadatum: Es hilft beim Lesen, ändert aber kein Bit auf der Leitung.

Aufbau einer SG_-Zeile

BO_ 256 EngineData: 8 ECU
 SG_ EngSpeed : 3|16@1+ (0.25,0) [0|16383] "rpm" Dashboard

Das Beispiel bedeutet: Das Signal EngSpeed beginnt bei Bit 3, ist 16 Bit lang, nutzt Intel-Byte-Reihenfolge, ist vorzeichenlos und wird mit Faktor 0,25 und Offset 0 in rpm umgerechnet. Der physikalische Wert ist immer Rohwert × Faktor + Offset, angewendet nachdem die Rohzahl extrahiert und ggf. vorzeichenerweitert wurde. Da das Startbit eine Position innerhalb der Nutzdaten bezeichnet, hängt seine Bedeutung von der Byte-Reihenfolge ab: Bei @1 läuft das Signal vom niederwertigsten Bit von Byte 0 aufwärts über Bytegrenzen hinweg, bei @0 beginnt es beim höchstwertigen Bit der Startposition und läuft abwärts ins nächste Byte. Eine falsche Kennung liefert daher einen völlig anderen Wert, nicht bloß vertauschte Bytes.

Warum die Byte-Reihenfolge alles verändert

Vergleich: dasselbe 16-Bit-Signal in Intel- und Motorola-Layout

Betrachten wir ein 16-Bit-Signal ab Bit 3. Im Intel-Layout liegen die ersten fünf Bits in der oberen Hälfte von Byte 0, die nächsten acht füllen Byte 1 und die letzten drei sitzen in der unteren Hälfte von Byte 2. Im Motorola-Layout belegt das Signal zunächst Byte 0 von Bit 3 abwärts bis Bit 0, springt dann zu Bit 7 von Byte 1 und läuft weiter bis Bit 0, danach folgen die Bits 7 bis 4 von Byte 2. Beide Beschreibungen ergeben 16 Bit, adressieren aber unterschiedliche physikalische Zellen. Das ist die häufigste Fehlerquelle beim händischen Übertragen einer Datenbank — und der Grund, warum ein Betrachter Rohwert und skalierten Wert nebeneinander zeigen sollte.

Häufige DBC-Schlüsselwörter

• BO_ — Botschaft (Identifier, Name, DLC, Sender)
• SG_ — Signal (Startbit, Länge, Byte-Reihenfolge, Vorzeichen, Skalierung, Einheit)
• CM_ — Kommentar zu Botschaft, Signal oder Knoten
• BA_ / BA_DEF_ — Attributwerte und ihre Definitionen
• VAL_ — symbolische Wertetabelle, z. B. 0 Aus, 1 Ein
• BO_TX_BU_ — zusätzliche Senderknoten einer Botschaft

Echte Datenbanken sind unordentlich: doppelte Identifier, fehlende BA_DEF_-Definitionen, nicht-ASCII-Kommentare, Signale, deren deklarierte Länge den DLC überschreitet, sowie Zeilen mit gemischter Kodierung. Ein brauchbarer Betrachter meldet das als Diagnose, statt die ganze Datei zu verweigern, denn meistens werden die gültigen 95 Prozent sofort gebraucht. Der Export nach CSV oder XLSX ergibt dann eine Zeile pro Signal mit Botschafts-ID, Name, Startbit, Länge, Byte-Reihenfolge, Faktor, Offset, Einheit, Kommentar und Wertetabelle — ein prüfbares Artefakt, das sich gegen die nächste Datenbankrevision diffen lässt.