國內汽車診斷行業現狀

題目有些太大了，哈哈！不過就是想寫這個，大題目小文章吧。也寫不長，分幾個方面寫寫我的觀察和體會。

 

1、市場。

　　小衆。幾年前聽四大四小裏面四大之一的一位資深客戶講，全國搞乘用車診斷軟件（非數據）開發的也不過120人左右，不大可能超過150人。

　　主機廠（整車廠）通常會把VCI（俗稱診斷儀）的軟硬件業務跟其它部件同樣：外包。並且也像其它供應商那樣：分A、Ｂ兩點，互爲競爭、備份關係——所謂供應商相爭主機廠得利。能夠簡單地類比：主機廠跟供應商的關係，就像貴得聯想都不敢想跟處理器、硬盤、內存廠家之間的關係。

　　診斷這塊分售前和售後，不過業內不這麼稱呼：售前的叫EOL，End of Line，產線末端，產線指總裝線；售後的就叫後市場。診斷上的問題，通常量產前的EOL階段ECU供應商本身就搞定了，診斷廠家能作的基本是外圍整合業務，好比寫寫配置、配配鑰匙之類；售後階段，成天跟診斷儀打交道的人，就是銷售店了。

　　國內有幾家主機廠？一個大的主機廠也不過幾百家店，自家店配個一兩套診斷儀就能夠了，因此你能賣多少診斷儀？

 

2、行業標準。

　　起碼在診斷上K線通訊基本被淘汰；如今絕大部分是CAN，可是CAN也好多年了；其它高級通訊協議通常只用在高檔車上。這是通訊方面。通訊嘛，不止用來作診斷的。因此真正算起來，UDS/J2534-PassThru/D-PDU/ODX/OTX這些纔算診斷。作ECU的，實現UDS就能夠了，其它幾個是給診斷儀/診斷軟件定的標準。

　　ISO 15765 DoCAN，Diagnostic on CAN，傳輸層和網絡層協議，在CAN的基礎上制定了流控與多幀的規則。這個是通訊與診斷的橋樑，也是基礎。

　　ISO 14229 UDS是診斷儀和ECU都遵照的標準，規定了診斷指令在各通訊協議上的指令格式、診斷服務定義和時序要求。這個作小車診斷是基礎必備，都得實現，沒得講。

　　SAE J2534 PassThru，有2004年的-1和2006年的-2兩個版本，以後就沒得更新了。這個協議簡單，一共就不到二十個函數，許多仍是Start/Stop,Read/Write這樣成對出現的。去年查過國內一家知名品牌的診斷儀網店，賣得最貴的也不支持這個標準，下面這幾個就更不用說了。

　　ISO 22900，08年出的framework級別的診斷標準。-2部分規定了Ｄ-DPU API，-3規定了D-Server。這個國際知名品牌基本都支持。

　　ISO 22901，11年出的關於用XML描述診斷數據的標準ODX。之前都是PDF、Excel等格式，混亂不方便機器處理。可是該標準定義的有些寬泛，各廠家或工具在具體表達上有些差別。診斷軟件每每要不得不作一些適配工做才能夠解析，不過好在數據格式統一了。目前正在實質性的普及階段。

　　ISO 13209，12年出的關於用XML描述診斷流程的標準OTX。嚴格說該標準是11年出的，可是11年的-1沒具體內容。一句話：診斷流程圖的XML表示，含HMI。國際市場上也有成熟的工具，可是國內剛開始試用。

　　爲什麼高級標準在國內普及得慢？市場小、細節多實現複雜、投入大應該是主要緣由。 

 

3、安全。

　　這個詞是萬金油，嘿嘿。絕大多數中低端車的CAN報文都是明文傳輸。因此新聞上講黑客黑了人家汽車，又是這又是那的瞎咋呼。要黑什麼纔有水平？一安全認證算法，二線路加密報文的破解。小診斷儀廠家爲何要辛辛苦苦地作逆向？就是抓人家報文而後根據UDS倒推這報文是幹什麼的。有些重要操做得一問一答地認證以後才能作，每次問得還不同，這就叫安全認證。他們爲何拿不到安全認證算法？你想一想主機廠能把這東西隨便給別人嗎？那是他們家的鑰匙！

 

4、開放競爭

　　與計算機互聯網相比，汽車診斷行業，或者就大膽說汽車行業吧，真的是個很保守的行業。主機廠在技術上嚴重依賴供應商，都造成惰性了——反正有供應商幫我解決，出了問題也是供應商的，我頂多有個失察的罪——都是國企或有那啥背景的——可不能出事——安全第一。因此這就是爲何近幾年有那麼多新玩家跳進這個圈子，也造造汽車，不怕不期望靠政府關係補貼前進的主機廠能在技術革新上造成實質性的挑戰？

 

5、研發

　　這個擺脫不了大環境的影響：先把東、西、作、出、來，有問題咱在改。你們都這麼玩，你不玩人家也不跟你玩。因此別說有時間作作基礎工做，就連軟件開發中基本的代碼級測試，有幾家作的？研發投入跟產品質量有個平衡，固然還有其它平衡關係，可是光抱怨差旅費比例大不行，不能光瞅秤桿不看秤砣秤盤。