CANoe 的 Trace 視窗裡，0x1A0 08 52 03 ... 這串生資料能顯示成「引擎轉速 850 rpm、水溫 88°C」，靠的就是一個 DBC 檔。它是 CAN 網路的「翻譯字典」——沒有它，匯流排上流動的只是十六進位。看懂 DBC 的結構，就看懂了 CAN 通訊設計的一半。
四層結構：從網路到位元
DBC 由外而內是四層：
| 層 | 是什麼 | 類比 |
|---|---|---|
| Network（網路） | 整個 CAN 叢集 | 一本字典 |
| Node（節點） | 收發訊息的 ECU | 說話的人 |
| Message（訊息） | 一個 CAN 訊框（有 ID、長度、發送節點） | 一句話 |
| Signal（訊號） | 訊息裡的一個物理量（轉速、溫度） | 句子裡的一個詞 |
一個訊息（一個 CAN ID）裡打包多個訊號——8 個位元組（傳統 CAN）要塞下轉速、溫度、狀態旗標好幾樣，於是每個訊號要精確定義「我住在第幾位元、佔幾位元」。
一個訊號的五個必要屬性
以「引擎轉速」為例，DBC 要定義：
- 起始位元（Start Bit）＋長度（Length）：住哪、佔多寬。例如從 bit 16 起佔 16 位元
- 位元組序（Byte Order）：Intel（小端）還是 Motorola（大端）——這是 DBC 最容易出錯的一格（見下）
- 因子（Factor）＋偏移（Offset）：raw 值換算物理值的公式
物理值 = raw × factor + offset。轉速 factor＝0.25 代表 raw 每加 1 等於 0.25 rpm - 最小／最大值：合法範圍
- 單位（Unit）：rpm、°C——顯示用，也是文件的一部分
換算公式是 DBC 的靈魂：ECU 在匯流排上只傳整數（raw），因子與偏移讓同一個 16 位元欄位可以表達「0～16383.75 rpm」這種帶小數的範圍，而不浪費頻寬傳浮點數。
製作 DBC 最常見的四個錯誤
- 位元組序搞反（Intel ↔ Motorola）：訊號值變成亂跳的大數或負數，但格式檢查不會報錯——因為佈局合法，只是解錯了。這是 DBC 除錯第一嫌疑犯
- 訊號重疊：兩個訊號的位元範圍相交，一個變動污染另一個。CANdb 這類編輯器有佈局檢視能一眼看出重疊
- 因子／偏移抄錯：數值差一個數量級或固定偏移——通常在跟實車或規格書對數時才發現
- DLC 與訊號範圍不符：訊息長度不夠放下所有訊號的最高位元
DBC 之外：這個家族還有誰
DBC 是 CAN 的傳統格式（Vector 的 CANdb 格式，事實標準）。往外看：
| 格式 | 用於 | 關係 |
|---|---|---|
| DBC | CAN／CAN FD | 傳統主流 |
| LDF | LIN | LIN 的對應物 |
| ARXML | AUTOSAR 系統描述 | 涵蓋更廣（含乙太網、SOME/IP），AUTOSAR 專案的來源 |
| CDD | UDS 診斷 | 診斷專用（見 UDS 是什麼） |
大型專案裡這些是同一套系統描述的不同切面，工具鏈之間會轉換——但轉換過程正是位元組序、命名、範圍出錯的高發區，值得在流程裡加一道檢查。
給不同角色的實用建議
- 測試工程師：拿到 DBC 先在工具裡載入、對著實車跑一趟，確認訊號值合理——這比讀規格書快得多
- 通訊設計者：訊號佈局要留擴充餘裕，別把 8 位元組塞到滿；命名用得上的規範，後面追溯才順
- 除錯時：值不對先懷疑位元組序，再懷疑因子偏移，最後才懷疑 ECU
下一步
從 DBC／ARXML 資料庫設計、一致性檢查到匯流排通訊驗證，歐特莫夫（Vector Informatik 合作夥伴）協助把通訊矩陣建成可維護的資產。
- 📄 解決方案：車載網路通訊協定解析：掌握 CAN Bus 相容性測試關鍵
- 📬 預約一次現況盤點