車載診斷---閒思

2021年8月3日，上海天氣：陣雨。

明天是兒子一週歲生日，願小傢伙快快樂樂、平平安安的長大。

真應了那句話，在男人這個年紀，時間就真的是一個數字，慌慌張張、匆匆忙忙應對著各種事宜，如同洪流，裹紮著、不由自己的向前走。

也就在此刻，偷得浮生半日閒，真真切切由自己把控。

慣例，分享一段喜歡的文字：

你可以陰鬱，可以懶散，可以不適時的計較，過分敏感，可以有些不知足、暴躁、嫉妒、小氣，但要記得拷問自我，必須追求善良，盡力坦蕩，永遠正直。

希望自己能夠保持所有的炙熱和真實，去慶祝每一個值得坦蕩的日子。

本文分享如下三個方面內容：

DTC故障碼優先順序

OTA刷寫資料傳輸方式

電子電氣架構走勢（HPC和域控制器）

1、DTC故障碼優先順序

對於Supplier，量產級的專案，芯片價格和質量永遠是一對無法逃避的爭論點。原理上為了滿足各種需求，晶片效能越高越好。但是作為公司層面，是為了盈利，追求的芯片價格更低。一般情況下（預研不算）會在滿足所有專案需求前提下，選擇最便宜那款晶片。

而對於車載診斷範疇，當ECU自身程式碼判定DTC對應的故障已經產生，會將該DTC以及DTC Status儲存在ECU記憶體上。有些情況下，ECU掉電非易失記憶體內容分給DTC儲存的空間不是很多的時候，這個時候需要在需求規範中定義DTC的優先順序。

當優先順序級別高的DTC產生時，可以覆蓋低優先順序的DTC。這樣可以實現對車身影響大的DTC可以在晶片記憶體有限的情況下實現寫入操作。

若DTC4判定已經產生，並且在需求規範中優先順序比已經儲存在記憶體中的DTC故障碼高，就會將原有的內容覆蓋。

初步達到要求。

以上是DTC優先順序判定策略。

另外，考慮到HPC以及域控制器引入到車載網路，DTC也帶來了需要變化內容。

如下以域控制器為例：

鑑於域控制器的儲存能力，可以將域控制器下掛的節點產生的DTC記錄在域控制器晶片記憶體上。

2、OTA刷寫資料傳輸方式

全稱“Over-The-Air technology ”，即空中下載技術，透過行動通訊的介面實現對軟體進行遠端管理，傳統的做法到4S店透過整車OBD對相應的ECU進行軟體升級

汽車OTA升級就好比電腦的Windows系統升級，或者也可以理解為手機系統的升級，每次升級都可以得到改善、修復漏洞或者獲得更多的功能、效能提升，又或者是視覺效果的改善，且這種更新是透過聯網後線上檢測、匹配版本、下載新的程式碼到本地進而執行安裝、校驗等程式。

如上圖是自己簡略畫的一個架構圖。OTA是線上升級，因此首先需要一個雲伺服器，車載端需要一個支援無線功能的節點模組（e。g。T-box）。

以下是個人很窄的觀點，歡迎留言補充。

1、首先具備無線功能的車載節點接收雲端以HTTP傳輸協議傳輸資料（本質還是TCP/IP）；

2、將下載的資料在GW儲存，該節點具備FlashManager、Security Manager（保護資料安全）等策略，這裡面有如下注意事項：

A：若具備無線能力的節點儲存夠大，可以將下載的資料全部儲存在該節點；

B：透過無線功能將整車需要升級的APP資料全部下載到具備無線能力的車載節點（e。g。T-box）；

C：若具備無線能力的節點儲存不夠大，可以將資料傳輸給域控制器，來分擔儲存壓力；

D：車載節點內部傳輸協議可以使用UDS協議也可以使用自定義的私有傳輸協議。

3、作為人機互動端，中控屏可以顯示出車身具備升級的可能性以及是否升級的主動權（由駕駛員控制）。

升級安全是OTA的最基礎的要求。車輛上ECU的軟體執行狀況直接會影響到車輛上的人員的生命安全。從升級包製作，釋出，下載，分發，刷寫等環節，OTA需要從雲，網路，車端來保證安全。在雲端透過證書，簽名和加密機制保證升級包的不會隨意被製作和釋出，升級包內容不會被惡意獲取。透過冗餘設計保證整車的功能可靠性，透過安全啟動來保證可信的軟體在ECU上載入啟動執行。

防變磚等異常處理。在OTA傳輸過程中，外界干擾或者其他因素導致刷寫異常或者中斷，車載ECU必須支援軟體回滾、斷點續傳、丟失重傳等處理機制。比如透過A/B分割槽實現軟體回滾。當重新整理軟體不可用或者失敗時，回滾到分割槽中備份的舊軟體版本，保證控制器正常執行。

3、電子電氣架構走勢（HPC和域控制器）

如下是新一代電子電器架構的網路拓撲圖。