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