【51CTO.com原創稿件】一段漂浮在內存中的靈魂，通過VCI（Vehicle Communication Interface）序列化為一股帶有動力、智慧、扭矩、穩定算法、啟動渦輪增壓的報文，連接在嶄新的、預備妥當的汽車上——像打扮漂亮的新娘；強大的靈魂注入沉重的汽車，她就閃爍著眸子、心潮澎湃，煥發生機。金屬，在程序員的再創造進程中，能反映出造物主的無上榮光。

[[236799]]

Ivan·項目管理

本期主人公Ivan，從事汽車通信診斷開發。2009年開始步入社會，是一名很低調的程序員，這么多年總結一下，莫不如尚未下線而強行上道的汽車——缺的模塊太多，一邊加油，一邊縫縫補補。每天敲代碼、聽歌、寫文檔、收郵件，加班。直到有一天，他終于厭倦了異鄉孤獨的街燈，收拾了行囊，回到家鄉。2013年底，他加入D有限公司，見到了一直認為縹緲的軟件作用于一臺汽車后產生的神奇變化——在此之前，他從不認為計算機程序和現實可見的事物有什么直接關聯。然而在這里，當Ivan看到一批批汽車自動配置完成，在公路上自由奔馳，真正的服務于人，工業，讓他遙望見自己的初心。

到今天為止，Ivan已經從事近5年的EOL開發工作，汽車在這里下線，帶著輕微的汽油味離開工廠，被物流車發往世界各地。他喜歡輕微的汽油味，喜歡新車干干凈凈的顏色，也喜歡聽尾氣沖擊歧管的清脆聲，當然他最喜歡的，是汽車跟隨指令產生的一系列變化。

汽車通信診斷開發現場試煉考驗

先來了解一些汽車通信開發定義：

·         EOL，End Of Line，一般指汽車下線（即將離開生產線）診斷系統

·         ECU，Electronic Control Unit，電子控制單元，車載電腦等。

·         ABS，Antilock Breaking System，防抱死裝置（一種ECU）

·         ESC，Electronic Stability Controller，車身穩定控制裝置（一種ECU）

·         EMS，Engine Management System，發動機管理系統（一種ECU）

·         CAN，Control Area Network，ISO 11898控制器局域網

·         UDS，Unified Diagnostic Services，統一診斷服務(與CAN的關系可以類比為HTTP與TCP/IP的關系，CAN相當于TCP/IP，UDS相當于HTTP)

真正廣闊的天地，是在生產現場遇到的各種試煉。Ivan記得曾參與某省汽車廠新車項目，當所有設備入廠調試完成，根據各零部件供應商提供的診斷規范（簡稱Spec）要求開發了***版程序，***批測試車輛按計劃下線，當診斷儀通過OBD-II接口接入車輛總線，屏幕密密麻麻的紅色錯誤項告訴他，在當前狀態，系統要改的路尚遠。那是Ivan***個項目，他跟著單位老大哥學習，完全遵照Spec，任何責任都能夠定位（得益于產品質量過硬，Ivan從不懷疑他們的產品、設備存在任何問題）。后來也確實按他所說，所有的問題一經確認，相關責任方就會調集人馬入廠解決，最終的結果不是更換軟硬件就是升級Spec。

EOL開發使Ivan在虛擬的計算機中看到現實汽車馳騁在道路上，內心充滿了成就感。有一段時間，進行ESC（車身穩定系統）、DVT（動態車輛測試）等，需要在DURR轉轂間進行，轉轂間是車間的一個獨立測試工位，一般常見的轉轂間都是DURR生產和提供支持的，車輛在轉轂間里可以在平面上模擬爬坡、顛簸、剎車、加速等等許多復雜力學測試，當時要計算車輛的車重、軸重等等，Ivan的同事龍哥直接用Java計算重力公式G=mg、杠桿原理等生成協議參數，另一邊與DURR工程師擬定通信協議，實現車輛在轉轂間，由診斷儀同時控制車輛和轉轂間協調二者執行測試，當那階段完成時，Ivan看著診斷儀屏幕上車輛運行曲線直逼150Km/h，真心欽佩他龍哥的專業態度，試問高中畢業后，誰還記得重力公式！在這里他也意識到對安全的重視，為防止診斷儀在轉轂外控制轉轂，設備上預置了紅外線接口，通過與另一種設備進行紅外通信、定位，***限度保障在轉轂間工作的工人人身安全（150km/h的速度，哪怕飛出一個螺絲釘也會傷到人）。

當然Ivan也見過追求規范、標準和干凈的實例。在北方某一線城市，Ivan參與其越野車診斷開發工作。呈于領導的故障，有時會得到領導親自下車間跟蹤排查，少了任務的層層委派、信息的層層傳遞，執行效率提高很多。當然，如果他遇到協調多個部門解決問題時，也會遇到互相推脫，有些說不清的責任劃分。記得當時針對某新車型開發檢測系統，當系統接入車輛總線時，他發現DTC（故障碼）完全無法識別，經過核對Spec，定位原因在于該車型安裝的某國產ECU并不完全遵照UDS協議，而是自行設計了一套與任何標準都不兼容的故障碼體系，沒辦法的情況下，Ivan只能針對他們的協議，重新編寫協議實現。

診斷開發注意事項

Ivan在這里經歷很多酸甜苦辣，見過太多傾軋、指責，欣慰的是體驗到工業擴展了技術的實現范疇。那幾年他在北方幾大城市飛來飛去，現場的診斷開發讓他學會了很多：

1.不要過早、過樂觀的估測總線上的情況，你永遠猜不到什么東西掛在了總線上。

2.遵照Spec開發，就算Spec再怎么啰嗦，遵命是***的選擇。

3.掌握英語，是良好理解Spec的基礎。

4.一個問題，哪怕再小，都要及時、清晰的反饋，因為不知道小冰山下面是多大的體量。

5.底層知識，就算很少用到，也應盡量掌握，因為不知道什么奇葩需求，會要改你的底層。

6.對領域的認識（或重定義）是指導開發的目標和方向。

7.解決人的問題比解決技術的問題更急迫，也更具決定性。

許多年過去了，Ivan已經很少做現場的開發，而更多的轉做服務架構、協議實現等。他曾經在某電影中看到自己參與開發檢測系統的汽車，飄揚著旗幟馳騁在非洲荒原，忽然覺得好眼熟，感覺心頭暖暖的，那是青春的一點痕跡吧。

在程序員的再創造進程中，汽車通信診斷開發——帶領程序員走向了現實世界。

如果你也愿意分享你的故事，請聯系小助手（小助手微信號：CTO51shequn）投稿，期待你精彩的故事！

活動進行時>>

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】