雖然呆呆翰工作的職稱是軟體工程師，擅長的領域是網頁前後端與資訊基礎建設，然而工作上遇到了專案要開發機車的診斷軟體。車上電子控制器的軟體跟呆呆翰擅長的領域看似沒什麼關聯，但也意外地有不少相似的架構似甚至是通訊協定。難得學到不同領域的新東西，就利用本文紀錄一下方便自己回查，畢竟呆呆翰連駕照都沒有的，更不要說懂車了。
診斷什麼、噴射什麼
對於車完全沒研究的呆呆翰而言，花了一點時間才搞懂到底在診斷什麼。國小的自然課有學過燃燒除了要有燃料之外也要有氧氣：把酒精燈蓋起來會熄滅就因為沒有氧氣可以繼續燃燒。
燃油車的內燃機引擎也是透過燃燒把汽油內的化學能轉換成動能，當然也需要空氣。混合空氣的方式很多，使用文氏管原理不需要微控制器（Microcontroller），這也是最早的現代化汽車 Benz Patent-Motorwagen 可以在 1886 年這個連 Intel 4004 微控制器都還沒誕生的年代被量產的原因。
然而固定比例的油氣混合並不適用於所有環境，在高山空氣稀薄或是含氧量低的環境，就有可能發生車子不好發動或是燃燒不完全的問題。因此包含各種感應器（Sensor）的電子噴射系統（Electronic Fuel Injection，有些人會簡稱 EFI *1或噴射 *2，這裡簡稱電噴）取代了以前的做法。
引擎控制單元（Engine Control Unit 簡稱 ECU）會從各種感應器讀取資料，包含進氣量、含氧量、油門開度…等等，決定噴油嘴要在歧管噴多少汽油混合油氣送進汽缸燃燒，或是直接將汽油噴進引擎汽缸點火做燃燒。
因為 ECU 要讀取各種感應器，每一個感應器都有可能故障、讀不到數值或是連線中斷造成 ECU 沒辦法決定正確的噴油量，這個時候就需要診斷器接上 ECU 來判斷問題了。
環境保護與法規
前面有提到電噴系統會控制噴油，噴油量就會影響空氣與燃料的比例（簡稱空燃比），不好的空燃比例會造成燃燒不完全，燃燒不完全會造成一氧化碳以及各種汙染空氣或是對健康有害的副產物。
為了保護空氣品質，各國政府透過法規規範車輛必須內建車上診斷系統（On-board Diagnostic 簡稱 OBD），要求車子本身就要可以偵測燃燒的問題並在有問題時讓車上儀表板的引擎檢查燈亮起。除了引擎檢查燈亮起之外也規範了診斷器要使用的連接頭（Connector）樣式、接腳（Pinout）之外，也定義的通訊方式與資料傳輸的格式。
最早從法規規範 OBD 的地方是美國加州，台灣則是 2008 年開始規定所有汽車都要配備 OBD ，由交通工具空氣污染物排放標準與其他相關行政命令規範；機車的部分在同一分規範的的六期的環保標準中規範了標準的 OBD 診斷標準，並在 2017 年開始實施。
標準的 OBD 大多是採用自動機工程學會 Society of Auomotive Engineers（簡稱 SAE）或國際標準化組織 International Organization for Standardization（簡稱 ISO）的標準，常用的標準如下：
- SAE J1962: 俗稱 OBD2 的連接頭
- SAE J1979: 各國政府法規規範燃油車要支援的資料標準
- ISO 15765: 車上的 Controller Area Network （簡稱 CAN） 的通訊協定
- ISO 9141: 包含了 K-Line 或 L-Line 的通訊協定
- ISO 14230: 又稱為 KWP2000 的通訊協定，通常搭配 ISO 9141 的 K-Line 使用
- ISO 14229: 又被稱為 UDS 的通訊協定，燃油車或是電車原廠常使用 UDS 診斷或是做調整
與電腦網路架構類似，在 CSS ELECTRONICS 的 OBD2 Explained文章內就有把部分標準對應到 OSI 7 層模型的圖可以用。相較於現今的網路應用有許多 OSI 7 層以上的違建： HTTP 已經到了應用層但上面又有 Web Socket 、 WebRTC 的應用等等，車用網路相對單純的許多。
另外一個要注意的事情是，上述協定只有 J1979 有定義資料格式。以 Web 開發來說，就算你知道對方的服務使用 HTTP 甚至你知道對方依循 REST 的設計風格提供 API ，開發者還是得需要得拿到 API 文件以及裡面資料格式的定義後，才能串接對方的服務。
目前只有 J1979 會定義送什麼資料 ECU 要回應引擎轉速，而 UDS 或 KWP2000 只有規範要下什麼樣的資料 ECU 會把記憶體特定位置的資料送出來，但引擎轉速要放在記憶體的哪個位置就不在 UDS 或 KWP2000 的定義範圍內了，一般來說 ECU 的廠商會定義這些資料。
也因此有些人會把 J1979 的資料稱之為標準，確實他是法規標準的資料，而法規以外車廠自用的資料稱為非標準。畢竟就算法規不要求車輛搭載 OBD，但是車廠也得讓技師知道電噴系統哪個感應器壞掉或是數值不正確需要替換，所以既使是 2017 年六期環保法規以前的機車，還是會有一定程度的診斷功能，只是不支援所謂的標準資料格式。
而電動車沒有被法規要求要支援 J1979 的資料標準，所以現在一個有趣的現象是：油車與油電混合車有標準的方式可以讀取行車資料，但純電車舊有資料標準了，除非你拿到原廠資料或是透過逆向工程讀取行車資料。
通訊協定的概觀
K-Line 的通訊協定可以類似於把 RS232 的序列埠（Serial）接上車子的 ECU 去進行診斷，通訊就是只有診斷器與 ECU，而 ECU 怎麼讀取感應器的資料就是另一回事。
這類的通訊協定通常會需要喚醒，無論是透過一個 5 Buad 的資料做初始化或是傳送 Fast Init 的訊號做初始化，ECU 才會開始回應。若是診斷器有一段時間沒有送出資料則 ECU 會讓這條資料線回去睡覺，要通訊就得重新喚醒。
而 CAN 則會比較接近 RS485 或是匯流排的架構：匯流排上有電噴系統的 ECU 與各種感測器，甚至有終端電阻。你的診斷器接上去也就是一個裝置加入網路。這個網路上也不限定是電噴系統使用，ABS 與儀表也可以透過這條網路讀取車速就簡化車輛部線的複雜度，有些車上娛樂系統也會接上這條網路讀取方線盤上的按鈕狀態。
雖然 CAN 不需要喚醒，但 UDS 走在 CAN 上仍然可能會用到會議（Session）的機制。雖然不像 K-Line 要維持資料線醒著，但還是有可能需要持續送資料維持 Session 不中斷。另外車廠也可能基於各種原因，在一輛車上佈建不只一組 CAN 。
參考資料
1: EFI 除了可以是 Electronic Fuel Injection 的縮寫之外，也可以 Mac 電腦用的 Extensible Firmware Interface 的縮寫，加上 Unified 就變成人電腦都在用的 UEFI 。考慮到兩種在不同的東西同一個網站都簡稱 EFI 很混亂，這裡不採用這個縮寫。
2: 噴射這個字容易跟火箭用的噴射引擎搞混，所以這裡也不採用這個縮寫。
- https://www.youtube.com/watch?v=lFvwys9T2kI
- https://enews.epa.gov.tw/Page/894720A1EB490390/ff5f1018-2642-44f2-a739-50f76cdc047b
- https://www.artc.org.tw/tw/knowledge/articles/3018
- https://www.csselectronics.com/pages/obd2-explained-simple-intro
- https://www.scantool.net/scantool/downloads/101/ecusim_2000-ug.pdf
- https://kvaser.com/software/7330130980146/V2_0_0/kvaser_leaf_light_v2_usersguide.pdf