原創內容，如若喜歡，轉載時請在開篇處註明出處

　　車輛網領域有個關鍵ECU——TBOX，本文圍繞TBOX的FOTA升級業務展開。主要講如何通過CANoe的模擬程式實現自動化測試， 驗證TBOX在FOTA業務過程中作為一個診斷儀刷寫整車其它ECU的流程以及業務邏輯處理的正確性。通常情況下，主機廠都採用實車測試的方式驗證FOTA業務。但是實車測試對對手件的穩定性有很高要求，在整車專案開發的很長週期內，整車上的所有的ECU都處於開發階段，我們前期是無法開展TBOX的FOTA功能的驗證工作的，所以模擬測試就勢在必行了。閒話少講 切入正題。

　　一、業務需求拆分

　　FOTA（Firmware Over-The-Air）, 關鍵行為拆分為兩點：下載 and 安裝。

無論實測測試亦或模擬測試，“下載”這個過程都是一樣的，並且“下載”不必需依賴於實車，也不依賴於對手件。所以需要模擬的部分集中在車內網路。主要問題就是解決車內ECU的模擬，匯流排網路節點建模，ECU邏輯實現。　

　　二、物理組網環境

　　分析實車與模擬的差異，先列出脫離實車後組網模型上的必需件。12V B+供電源，業務觸發的必需件ECU（根據TBOX的功能設計可確定必需存在的ECU），模擬裝置CANoe, 工作站PC

　　實車測試組網示意圖：

　　模擬測試組網示意圖：

　　對比可以看到，模擬的測試方案新接入了電源，除了必需存在的主機外，其餘的ECU(EPS,PEPS,BCM,ACU,TCU等)全由{PC+CANoe}模擬實現。

　　三、測試方案選擇

　　例如，此處被測TBOX的FOTA安裝過程，業務設計是基於UDS協議實現的刷寫，通過CAN匯流排傳輸資料。所以此處FOTA安裝的本質是程式設計模式下的診斷寫入過程。（延伸：個人認為通過Ethernet匯流排傳輸資料，是車聯網+智慧駕駛未來發展的必然趨勢，它可以更高效的傳輸，承載龐大的資料量，相對較低的成本）

我們透析需求，實際上就需要做一件事：程式設計實現車內行為模擬。抽絲剝繭，層層深挖下來又是兩點需求

1、車內通訊訊號的模擬

2、診斷的請求與應答（被刷寫ECU的應用層業務邏輯封裝）

重點講第2點，前面講過FOTA安裝過程中TBOX扮演了診斷儀的角色，所以實現第2點的需求時，需滿足單對單的物理定址請求，單對多的廣播式功能定址請求。

我的設計思路是建立兩條鏈路，分別支援物理定址，功能定址。接下來是選擇從哪一層去實現，不同層應用的協議不一樣，其實現的複雜程度也不一樣。舉個例子，要建一個Client與Server進行網路通訊，如果你對底層比較清晰，可以直接採用套接字實現。否則你可以選擇較上層的協議去實現。

CAN匯流排的通訊也是符合OSI模型，見下圖：

分析優缺點：

　　從物理層切入實現，需兼顧幀格式的問題，包含多幀分包傳輸，流控策略，連續幀拆分與組裝等麻煩事情，在保證資料正確性上要寫過多邏輯。且對ISO11898有比較深的瞭解。 整體框架和邏輯簡單，可擴充套件性差。 

　　從傳輸層切入實現，託管了資料處理的細節，ECU間的耦合度低，是比較好的選擇。不過框架設計會複雜一些。

具體實現方案：基於CANoe的CanTp建模庫，在CAN上實現了傳輸協議ISO/DIS 15765–2，控制傳輸大量資料，支援多通道併發。模擬整車上支援OTA的節點，每個節點都可通過兩個連線(物理定址-Connection 1 和 功能定址-Connection 2)，使用OSEK TP節點層DLL與診斷儀通訊，在同一連線上在同一時間可以傳送和接收資料。模擬FOTA刷寫流程。

通訊模型與系統框架：　

CAPL程式碼具體實現，詳見下一篇