DBC のバイトオーダ：Intel と Motorola、開始ビットと換算

DBC は Vector が CAN ネットワーク記述用に導入したプレーンテキストのデータベース形式です。フレーム自体ではなく、その解釈方法を保持します。メッセージは BO_ で ID・名前・DLC・送信ノードを伴って宣言され、信号は SG_ 行としてぶら下がります。CM_ はコメント、BA_ は周期時間 GenMsgCycleTime などの属性、VAL_ は列挙の値表、BO_TX_BU_ は追加の送信ノードです。実ファイルは Windows-1252 や GBK で保存されていることが多く、UTF-8 だけを想定したパーサは信号名やコメントを静かに壊します。信頼できる DBC 読み取りには寛容なエンコーディング判定が欠かせません。

1 行の SG_ には、値を取り出すために必要な情報がほぼ全部入っています。信号名、開始ビット、ビット長、バイトオーダ標識、符号、係数とオフセット、最小値と最大値、単位、受信ノード一覧です。標識は @1（Intel、リトルエンディアン）か @0（Motorola、ビッグエンディアン）のどちらかで、長さの後のマイナス記号は生の整数に符号があり換算前に符号拡張が必要なことを示します。丸括弧が係数とオフセット、角括弧が表示範囲です。それ以外はメタデータで、読みやすさのためにあり、線上のビットは変えません。

SG_ 行を分解する

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

この例は「EngSpeed はビット 3 から 16 ビット、Intel、符号なし、係数 0.25・オフセット 0 で rpm に換算」と読みます。物理量は常に 生値 × 係数 + オフセット で、生の整数を取り出し（必要なら符号拡張し）た後に適用します。開始ビットはペイロード内の位置を指すため、その意味はバイトオーダに依存します。@1 ではバイト 0 の最下位ビットから上位へ、バイト境界をまたいで進み、@0 では開始位置の最上位ビットから下へ次のバイトへ続きます。したがって標識を書き間違えると、単なるバイトスワップではなく全く別の数値になります。

バイトオーダがすべてを変える理由

同じ 16 ビット信号が Intel と Motorola で占めるビットを比較

ビット 3 から始まる 16 ビット信号を考えます。Intel では最初の 5 ビットがバイト 0 の上位側、次の 8 ビットがバイト 1、最後の 3 ビットがバイト 2 の下位側に置かれます。Motorola ではバイト 0 のビット 3 から 0 へ、次にバイト 1 のビット 7 から 0 へ、さらにバイト 2 のビット 7 から 4 へと進みます。どちらも 16 ビットですが、指す物理セルは異なります。データベースを手作業で移すときの最も多い誤りであり、ビューアが生値と物理量を並べて表示すべき理由でもあります。

DBC の主なキーワード

• BO_ —— メッセージ（ID、名前、DLC、送信ノード）
• SG_ —— 信号（開始ビット、長さ、バイトオーダ、符号、換算、単位）
• CM_ —— メッセージ・信号・ノードへのコメント
• BA_ / BA_DEF_ —— 属性値とその定義
• VAL_ —— 0 オフ、1 オンなどのシンボル値表
• BO_TX_BU_ —— メッセージの追加送信ノード

実際のデータベースは汚れています。ID の重複、BA_DEF_ 定義の欠落、非 ASCII のコメント、DLC を超える長さ宣言、混在したエンコーディング。使えるビューアはファイル全体を拒否せず、これらを診断として報告します。有効な 95 パーセントをすぐ使いたいのが現場だからです。CSV や XLSX へ書き出せば信号ごとに 1 行となり、メッセージ ID、名前、開始ビット、長さ、バイトオーダ、係数、オフセット、単位、コメント、値表が並びます。レビュー可能で、次版のデータベースと diff できる成果物になります。