首先，我們還是將汽車軟件放在整車系統下來看。因此，我們會分離出3個層級的集成：
- 軟件組件集成。
- 軟件向硬件集成。
- ECU向整車集成。
1 軟件集成與分支劃分
簡單來說，軟件集成就是創建一個邊界明確、質量可靠的完整軟件包。再擴充一些的話，就是基于源代碼管理工具和分支管理策略，針對不同的單元（如.c或.h文件）逐級進行集成，并將相關的輔助文檔、集成測試、配置文件等配置項進行配置管理。
1.1 “分支”的概念
由于汽車軟件的平臺化需求很高，所以，我們一般會進行“開發分支”和“交付分支”的區分。
- 開發分支側重于維護新特性的上線和通用性技術方案的導入。
- 交付分支則關心的是基于特定項目要求（如標定參數、項目配置參數、bug修復等）的釋放。
二者的區分也可以讓“開發的技術完善性”和“交付的時間及時性”不至于直接沖突和互相干擾。
一般而言，軟件集成的主要任務是識別、確認不同分支之間的公共組件，定義哪些組件應該從一條分支摘取到另一條分支上、哪些組件的變更需要單獨釋放以及哪個軟件基線最終能夠被用于哪個配置的交付上。
1.2 具體的集成
集成的策略取決于項目或平臺釋放的目的，而這又來源于項目的整體考量，所以，集成任務是需要項目經理類角色驅動的。簡要集成流程如圖1所示。
圖1 軟件集成簡要流程
1.2.1 集成輸入
盡管郵件也是一種輸入，但對于繁雜的集成任務來說，通常最好使用ALM工作流類的工具來支撐，或是bug，或是變更，或是新特性需求，都可以通過相關工作項來驅動集成，比如，輸入需求基線、變更范圍、版本規則、工件、上一版本軟件基線、交付日期等。
實際上，良好的集成更多來源于管理。
1.2.2 編譯、測試、打包
集成工程師在任務驅動下，去完成相應的源代碼編譯和相關錯誤清除，并完成必要的接口、資源消耗、冒煙等靜動態集成測試。最后，根據預定規則，完成可執行文件、配置信息、測試報告、架構模型、設計文檔、遺留問題、釋放清單等的打包釋放。此時，一個常規的集成任務就完成了。
1.2.3 軟件配置管理
不管是集成組件選擇，還是文件打包，其實都可以歸屬為配置管理這個大的概念，第3章我們從項目層面解釋了配置管理，這里進入軟件包里看，主要講兩部分。
(1) 軟件版本號
軟件的名字，也就是軟件版本號，這是我們日常交流的主體對象，最基本的邏輯是一個版本號唯一對應一版代碼。
理論上，我們用V1、V2、V3也可以去描述軟件，但為了增加軟件的辨識度、可見性和交流的便利，我們會為軟件版本號增加更多的信息，比如，項目名、車型名、客戶名、硬件類別、芯片類別、架構類別、集成序列號、標定版本號、軟件階段（簽名與否、適用工廠與否、ABCD級別等）等。
(2) 細化的分支概念
我們再細化討論下分支的概念。注意，這是一個邏輯概念，并不真實存在。通俗理解，分支就是把組件的變更放在這個軟件包里，而不是另一個，也就是不同的組件版本組合。
另外，前面我們說過可以把分支大體分為“開發分支”和“交付分支”。進一步地，二者都可以繼續劃分為更細化的分支概念，如圖2所示。
圖2 軟件分支類型
1) 開發分支
“開發分支”可以細分為平臺開發分支、特性開發分支與特定項目開發分支。
- 平臺開發分支
平臺開發分支是我們的平臺化軟件，是平臺開發人員維護的、最具普適性的基礎軟件，是所有其他分支的源頭，所有的變更、修改、提交應該嚴格審慎。如圖3所示。
圖3 平臺開發分支示意圖
- 特性開發分支
特性開發分支一般是，經過普遍分析后，認為有必要導入到平臺的特性開發或復雜bug修復，而且，這樣的變更需要一定的周期和工作量。
為了避免影響到平臺軟件的日常維護，這時就有必要單獨拉出來分支進行開發。在開發過程中，需要定期地將平臺開發分支的變更進行同步，并在新特性釋放后，合入平臺開發分支，以保證平臺開發分支的最新狀態和完整性。如圖4所示。
圖4 特性開發分支示意圖
- 特定項目開發分支
對于特定項目開發分支來說，有些功能或特性的變更需求來源于特定項目，但需要動到平臺開發分支，而由于其特殊性，又不需要永久合入平臺開發分支的平臺軟件里，再加上二者團隊的差異性，這時，就可以單獨拉出來一個分支去完成這部分變更，但最終不會合入平臺軟件，而是合入到交付分支里。如圖5所示。
圖5 特定項目開發分支示意圖
2) 交付分支
那么，“交付分支”也可以繼續分為項目主干分支、項目釋放分支等。
接著看交付分支，交付分支的意義整體在于，既能基于平臺化軟件加速開發，又能保持一定的項目釋放獨特性與靈活性。
- 項目主干分支
對于項目主干分支來說，道理與平臺開發分支類似，對于特定的車型類別或客戶群項目，往往有更相近的需求，可以維護一條項目交付層級的“平臺”軟件。
這條分支由項目團隊精心維護，同時做好與平臺的同步更新，保證其是一條構建和測試成功的“綠色“分支。如圖6所示。
圖6 項目主干分支示意圖
- 項目釋放分支
而對于更多的項目變體，即項目釋放分支，就能夠以這條“綠色”的項目主干分支為交付基礎，而高效地從中摘取軟件基線，并完成自身的配置，比如，傳感器、MCU、零件號等配置參數。如圖7所示。
圖7 項目釋放分支示意圖
值得說明的是，以上僅給出了一種分支拆分的思路，基本邏輯是平臺化和定制化的權衡。實際上，有些產品與項目甚至不需要分支，只在一條分支上開發下去，具體項目需根據軟件的成熟度和復雜性以及變體的多寡等來綜合考慮合適的分支策略。
2 軟件向硬件集成
在完整軟件交付出來之后，我們要做的就是將軟件刷寫到ECU硬件中（具體刷寫方式可能通過OBD口或USB或直接連接芯片針腳，或者通過遠程OTA），這其實就是我們所要講的系統（軟硬件）集成。
理論上講，集成都是通過接口來完成的，系統集成也就是通過軟硬件接口來進行，具體表現就是物理的芯片引腳和邏輯的傳輸數據的軟件接口。如果開發流完整的話，這些接口應該在系統架構的部分進行過定義。
如果把系統集成再細分一些，我們再往上走，會有電路板與機械外殼、接插件、屏幕等的集成，只不過這步集成更多有著機械裝配的意味，落在現實工作里就是打一批樣件了。
當然，我們都知道一套完整的電控系統一般會包含傳感器、ECU和執行器，處于中間的ECU是我們前述兩步集成的結果。但傳感器和執行器往往由外部其他組織提供，如果從系統的視角考慮，我們通過線束支撐的接口來完成這一級別的集成也是必要的。至少，內部開發中經常需要這樣的環境來驗證ECU的功能。
3 ECU向整車集成
整車集成基本是屬于OEM的工作范圍，也是它們的核心競爭力所在。
這一步的系統是從整車來看的，比如，驅動系統、剎車系統、轉向系統、被動安全系統、照明系統、輔助駕駛系統等。
對于某一個電子控制器來說，在所有內部集成和驗證完成后，必不可缺的一步是，在整車環境中完成布置確認、模態分析、傳感信號校驗、電子對手件聯調、產線確認以及EMC、振動、沖擊、水淋、鹽霧、高低溫等一系列的考驗。
對于軟件來說，尤其要考慮對手件聯調，越來越多的電子功能需要多模塊協同，最常見的診斷、通信問題就是該環節頻繁識別出來的。另外，很多在整車層面的屬性性能也是需要在整車環境下進行軟件標定匹配的。在汽車行業里做軟件，要意識到，所有的代碼其實都是最終服務于整車里的表現。
但是，我們也要知道，我們并不期望在整車集成環節解決軟件問題。畢竟，一臺試驗車動輒幾十上百萬，有些試驗甚至是整車破壞性的，整車試驗的成本通常都會比較高。當軟件問題從開發團隊一路逃逸到這個環節時，往往會帶來比較大的成本。
