引擎故障代碼簡介（一）

現在許多汽車維修也都進步到所謂電腦診斷功能了，連目前機車噴油也有。
但這個東西不是今天才出現的，早在有ECU(Electric Control Unit）時就有了。
而美國也把這一部份納入工業規範，這一部份您查SAE 標準都有。
所以，國內也有許多公司在專門做車用診斷系統，不管軟體或硬體都有人作。
但您覺得作這個很難嗎？！我想應該跟我搞USB 去作那個HID 或是MSDC（隨身碟）
一樣，就看您要不要拿著規格書K 而已。



在此我們就簡單的介紹一下這一種所謂的汽車診斷故障代碼。
當然現在有很多人會稱他為所謂的OBD II(On Board Daignostic II ），
而這個觀念最早是來自GM（美國通用汽車之ECU ，GM 不叫ECU 而稱為EMS
(Engine Management System）。）後來，就被引進SAE 成為規範，隨後大家就跟著
遵循這樣子的規範。從技術來講：就是把ECU中的UART 把一些MCU 看到的問題點，
給儲存起來與傳輸出來而已。
早期電腦技術沒有那麼發達，這些規範有些是有點過氣了，但他的精髓卻被一直延伸。
甚至更被發揚光大了，從原來單純的引擎控制延伸到車上的許多電裝部品等等。
您一定要搶著說CAN(Control Area Network） Bus 嗎？！...先不急嘛！
我們得先瞭解歷史才知道人家為什麼會這麼定義的嘛！
首先，早期電子技術沒那麼好，MCU 有的串列通訊UART，就得要阿彌陀佛了。
但偏偏車用電子使用環境又特別惡劣，所以人家就把簡單的UART轉成RS 485再用。
這就成了這一類產品觀念的基礎：所以關於車用診斷系統的第一代就是採用RS485 定義
的：SAE J1708 ：Serial Data Communications Between Microcomputer Systems
in Heavy-Duty Vehicle Applications。他就是定義了我們一般所謂通訊協定系統中的
第七層：最底層Physical Layer 那一層了。
而至於在於通訊協定的資料格式（Data Layer），那就藉由另一個規範：SAE J1587 ：
Electronic Data Interchange Between Microcomputer Systems in Heavy-Duty
Vehicle Applications 來定義了。...
或是 SAE J1922 : Powertrain Control Interface for Electronic Controls Used in
Medium- and Heavy-Duty Diesel On-Highway Vehicle Applications
當然啊，目前這些規範大概都被另一個比較受人矚目的CAN Bus 規範所替代了。
這一個規範就是： SAE J1939 ：Recommended Practice for a Serial Control
and Communications Vehicle Network.
反正嘛，現在不管您要搞什麼標準品，大概都有一大堆規範書讓您K不完的啦。
然後，只要您照著這些規範書的內容作，大概也都可以搞出一些名堂的。
好了，回到主題：我們要談的主題是：引擎故障代碼，其實應該稱為：
"診斷故障代碼"(Diagnostic Trouble Code)才對，因為目前車用電子涵蓋範圍
比較廣了，診斷器所提供的資訊就不一定侷限在引擎而已。
我們就以目前國內機車的例子為例：

我們就可以看到這一系列的維修手冊上的故障代碼圖表。您不要以為這些故障代碼多有
學問，我說過：這些東西也輪不到您自個兒愛怎麼定義，就怎麼定義的！因為很簡單，
人家既然要搞診斷器的，也不喜歡您動不動就亂搞一通，誰哪有那麼多時間更新這些
東西？！...而上圖中的那個故障代碼為：Pxxxx 指的就是Powertrain 動力系統的。
指的是跟引擎控制相關的...如果是跟底盤有關的就是Cxxxx(Chassis)。
這一部份的定義在SAE J2012 ：Diagnostic Trouble Code Definitions 可以參考的。
所以您就可林林種種的搞一大堆碼的讓大家看起來，似乎就是有那麼有學問的就可以了。
----
但其實，如果這個東西是在我們3C 產品裡面的話，那鐵定也沒啥商機了，
我說過：搞3C 產品就是越快越好...所以『一個產品，一個工』，就給他用力的搞下去。
但車用電子可不行，您說：您拿個1~2 KBytes ROM Size 的MCU就搞起來，
然後寫程式也沒啥系統觀念，您今天搞控制器，批哩趴啦的把人家產品需求從第一行
寫到最後一行就可以交差了事？！好了，您今天搞個簡單的點火控制器，
那明天您又要加個噴油控制器功能...然後再來又要您加個迴授控制，再來又要這個
診斷故障碼處理...結果，搞得了一個產品，卻搞不了第二個...Why ?! 因為一開始
就從來沒有系統整合規劃，最後就是搞死自己，我們台灣開發電子產品的標準思維。
---
那您一定會Challenge 我的看法，覺得我應該舉個比較實際的例子。
好，我舉一個最基本，最簡單的例子：
診斷故障代碼：P0120 Throttle/Pedal Position Sensor/Switch "A" Circuit...
這個故障代碼指的是TPS（油門感測器）故障，但實際上其實跟TPS 有關的代碼有
P0121 :Throttle/Pedal Position Sensor/Switch "A" Circuit Range/Performance
P0122:Throttle/Pedal Position Sensor/Switch "A" Circuit Low
P0123:Throttle/Pedal Position Sensor/Switch "A" Circuit High
P0124:Throttle/Pedal Position Sensor/Switch "A" Circuit Intermittent
那一個比較嚴重？！那這彼此之間的定義之差異化為何？！
我們若只是會遵循規範搞診斷器，那也沒啥好說的，反正您就把這些規範書的內容，
建在資料庫裡，當讀到引擎控制器給您什麼碼，您就把他Show 出來就好了。
知其然，就不必知所以然了。
如果是我們要搞控制器的話，就不得不去瞭解一下這些基本定義的來龍去脈了。
TPS 油門感測器是引擎控制最重要的感應部品之一，他是用來偵測駕駛者的引擎
操作特性...他是利用了一個可變電阻來感應油門位置。就跟我們一般電子控制搞
VR 可變電阻旋扭一樣，但我們在一般電子控制上，大部分也都沒太留意這一種
感應器的特性，但若裝在車子上，可就不一樣了...您就得去想：在程式韌體上，
該如何定義、或診斷判斷出他是故障的？！而當有故障時，又要保持車子還可以開！
還有：當使用操作久了之後，會不會產生誤差問題？！譬如：基本零點偏移跑掉了？！
那要不要作自我校正？！又該如何校正？！之後才如何顯示故障代碼？！
 ...
每次我跟別人講這些時，都會開玩笑的比喻說：老師上課時，都會拿著課本教學生說：
現在引擎控制都會採用許多感應器...再利用這些感應器作迴授控制，算出精準的
噴油量或點火進角...＠％＃＄...劈里啪啦講了一大堆，我們都懂，反正這個東西的學問
都大同小異的，不但課本上這樣子教，網路上一大堆資料，也都是這樣子。
然後呢？！實務上碰到上述問題時該怎麼作？！---- 沒有！不知道。
結果，上完課之後，大家都懂，但大家都不會作這些。....
怎樣？！這個東西只要用十個手指頭就會寫程式？！
『一個產品，一個工』，那您打算如何開發一棵引擎專用的控制器呢？！
這裡面有太多的學問了，所以世界上專業的引擎控制器專業廠也是用手指頭可以數得出
有幾家而已吧。
（待續）