2011年12月23日 星期五

引擎故障代碼簡介(一)

現在許多汽車維修也都進步到所謂電腦診斷功能了,連目前機車噴油也有。
但這個東西不是今天才出現的,早在有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 可變電阻旋扭一樣,但我們在一般電子控制上,大部分也都沒太留意這一種
感應器的特性,但若裝在車子上,可就不一樣了...您就得去想:在程式韌體上,
該如何定義、或診斷判斷出他是故障的?!而當有故障時,又要保持車子還可以開!
還有:當使用操作久了之後,會不會產生誤差問題?!譬如:基本零點偏移跑掉了?!
那要不要作自我校正?!又該如何校正?!之後才如何顯示故障代碼?!
 ...
每次我跟別人講這些時,都會開玩笑的比喻說:老師上課時,都會拿著課本教學生說:
現在引擎控制都會採用許多感應器...再利用這些感應器作迴授控制,算出精準的
噴油量或點火進角...@%#$...劈里啪啦講了一大堆,我們都懂,反正這個東西的學問
都大同小異的,不但課本上這樣子教,網路上一大堆資料,也都是這樣子。
然後呢?!實務上碰到上述問題時該怎麼作?!---- 沒有!不知道。
結果,上完課之後,大家都懂,但大家都不會作這些。....
怎樣?!這個東西只要用十個手指頭就會寫程式?!
『一個產品,一個工』,那您打算如何開發一棵引擎專用的控制器呢?!
這裡面有太多的學問了,所以世界上專業的引擎控制器專業廠也是用手指頭可以數得出
有幾家而已吧。
(待續)

2 則留言:

  1. 我高中畢業要當完兵後也做了幾年汽修,後來是覺得太累又沒冷氣吹才改行學電子 :D ,我自己覺得修車並沒有比學寫程式要簡單,寫程式只要擁有邏輯能力就很快可以上手,但是修車需要長期經驗的累積並付出相當大的勞力才有出師的一天.
     
    歐洲車幾乎都是使用bosch的噴射供油系統,我當年接觸的主要是vw與audi車系,vw集團20幾年前就已經有自己專用的車輛診斷電腦了,但是在台灣的師父只會在故障代碼燈亮起時把診斷電腦接上去看一下,通常是怠速馬達或是含氧感知器或是流量感知氣的故障代碼,然後就是叫學徒拿除炭劑把接點清一清或是直接換新的,但是車輛控制常常是互相牽連的,不見得出了故障代碼就是那個零件壞,而師父不可能拿原廠技術手冊教學徒要依照標準流程依序拆裝做檢查,因為他們也從來就看不懂那些東西,至於學校老師那更是連見都沒見過,學校能學到的也只是噴射引擎的原理而已.
     
    其實現在去修車跟去醫院看病一樣,都是要靠運氣的,祖上積德遇到有經驗的師父聽音辨位藥到病除,運氣不好就是零件東換西換了一堆花了一大筆錢最後還是百病叢生,我到現在開的還是將近20年前化油器的車,捨不得換新車的某種原因就是因為對老一輩的修車師父來說,化油器才是他們最熟悉的.
     
    未來的車輛,不只是引擎控制系統還包含整台車一定要做到像電子產業一樣的模組化,車廠技師不可能像我們一樣遇到bug還用ICE去單步執行除錯,因為車主就在旁邊等著馬上要有車開,才不想去聽車廠接待解釋是什麼壞掉而沒辦法當天修好的不啦不啦的理由,理想上最好是設計到診斷電腦能夠準確無誤的直接指名是哪個模組壞了,怠速馬達壞了換,引擎壞了換引擎,變速箱壞了直接換整顆,這樣大家都省事 :D

    回覆刪除
    回覆
    1. 非常感謝您的經驗分享。
      不管是車輛或其他交通工具,走向智慧型的裝置一定會是個趨勢。
      搞電子技術或是修車、修引擎都是基本功夫,未來技術還是會走向系統整合的。
      同樣的道理:未來技術會在哪?!商機就會在哪。
      如果只是懂得基本功夫,而不懂得系統應用的話,這樣子的技術與生存之道
      還不夠的...
      想想我們每天寫程式,搞電子產品,作的如果只是表面功夫,那跟修車師傅
      有何不同?!講難聽一點:人家修車師傅在經驗累積之後,十年後人家可以
      開修車廠賴以維生,幫路上小姐拖故障車,修個車~幾千塊可以收。
      但您寫程式十年後...您怎麼養活自己?!搞不好,修車的比寫程式人少,
      市場需求大,人家比您還搶手呢!--- 這是最現實的問題。 :))

      刪除