總說汽車軟件不同于互聯網軟件，要區別對待，也有很多說法，比如：

汽車軟件的實時性要求更高

汽車軟件的安全性要求更高

汽車軟件與硬件耦合度更高

汽車軟件所用編程語言不同

汽車軟件操作系統不同

汽車軟件的開發環境與工具鏈不同

......

這些都沒錯，但又不怎么對。

一來是，在座艙、智駕、后臺軟件大舉進入以及電子電氣架構不斷演化后，汽車軟件的內涵已經有了比較大的擴展。

二來呢，這些都屬于技術特性，技術差異點只能說明汽車的“軟件”和互聯網的“軟件”，而非“汽車軟件”與“互聯網軟件”。

我們希望能從整體的角度來看汽車軟件，這就引出了今天的話題——集成，它也是汽車軟件獨特性的核心體現。

具體來看，集成可以分為以下5個層次：

將軟件單元集成到一起

將軟件集成到硬件上

將硬件集成到機械殼體上

將ECU集成到子系統中

將子系統集成到整車上

1

第一層：將軟件單元集成到一起

當我們講軟件集成時，軟件自身的集成是其最典型和最狹義的含義。

簡單說，軟件集成就是將經過驗證的軟件單元集成為完整軟件，操作層面的表現為將不同的.c或.h文件以及一些config文件通過集成工具集成構建成軟件包。

當然，由于實際項目的復雜性，集成會作為整個軟件項目管理鏈條的一個環節。

第一，開發工程師接受ALM工作流工具上的缺陷、變更或任務等的驅動，進行本地代碼的修改，之后將代碼push到代碼倉庫，把代碼備好。

第二，集成工程師也最好通過工作流工具接受集成任務，任務中要明確集成的分支策略、交付目的、時間計劃、各單元信息等，而后基于這些輸入要完成軟件的構建。

第三，集成工程師自然也需要對自身工作質量做一個確認，所以要完成靜態或動態集成測試，相關結果可能會包括編譯器的警告信息、代碼掃描結果、資源消耗數據、堆棧分析內容、代碼評審及冒煙測試情況等。

第四，集成工程師將包括可執行文件、測試報告、配置信息、問題清單、releasenotes 等一系列必要材料打包對外發布。

2

第二層：將軟件集成到硬件上

當完整的軟件包就緒后，我們需要將軟件集成到硬件上，準確來說是將軟件刷寫到MCU等芯片里。

理論上講，集成都是通過接口來完成的，軟硬件集成也就是通過軟硬件接口來進行，具體表現就是物理的芯片引腳和邏輯的傳輸數據的軟件接口，具體方法如下：

常規的產線或打樣室刷新的方式基本是通過芯片引腳直接燒錄

如果硬件已經裝在車上了，就可以通過OBD或USB口刷新

非現場則可以通過遠程OTA刷新

另外，如果開發過程比較理想，這些接口應該在系統架構的部分進行過定義。

3

第三層：將硬件集成到機械殼體上

到這里，我們會得到一塊有軟件的電路板。

進一步地，還需要電路板與機械外殼、接插件、屏幕等的集成，只不過這步集成更多有著機械裝配的意味，落在現實工作里就是打一批樣件了，結果就是形成我們所說的ECU或者控制模塊。

由于汽車電子需要面臨各類復雜嚴苛的駕駛環境，所以這部分仍然對軟件功能的發揮有很大影響，很典型的例子是內部傳感器對安裝環境有模態和尺寸要求。

4

第四層：將ECU集成到子系統中

ECU至少需要和一套傳感器及一套執行器一起構成一套具備特定功能的系統，我們姑且稱之為子系統，比如，驅動系統、剎車系統、轉向系統、被動安全系統、照明系統、輔助駕駛系統等。

對于這個層級的集成，操作上就是通過線束連接ECU、傳感器、執行器這三者，并且將ECU固定在整車上。后兩者通常來源于不同組織，所以特定集成的意義就更明確。

至于集成效果，是需要通過在整車環境中完成布置確認、模態分析、傳感信號校驗、電子對手件聯調、子系統功能確認、產線確認以及EMC、振動、沖擊、水淋、鹽霧、高低溫等一系列的考驗的。

對于軟件來說，尤其要考慮對手件聯調，越來越多的電子功能需要多模塊協同，最常見的診斷、通信問題就是該環節頻繁識別出來的。

另外，很多在子系統性能也是需要在整車環境下進行軟件標定匹配的。

5

第五層：將子系統集成到整車上

傳統汽車的各個子系統或者域通常是分離的，相互之間大體隔絕，所以涉及到的是裝配，而非集成這個概念。

但是，電子電氣架構在不斷走向跨子系統、跨域、域融合、中央集中，現在車輛子系統之間的邊界越來越模糊，越來越多的功能特性需要聚焦在更整車、更終端才能得到驗證與確認。

6

寫在最后

整體來說，在汽車行業里做軟件，要意識到，所有的代碼其實都是最終服務于整車里的表現。

另外一點，汽車的多層次集成其實是有歷史原因的，主要是來源于汽車零部件全球模塊化分工及采購這種模式。

這種分工與標準化的好處不言自明，但也增加了很多集成點，集成點多了就會造成溝通協調復雜或者解決方案整合困難等弊端，而這也是我們做汽車軟件要充分考量的。

往長遠看，我們現在從架構層面追求的中央化正在不斷地減少集成點，同樣也就會弱化集成的價值與必要性。