汽車控制系統的軟體集成---學習小結
軟體集成這個概念我思索很久，說起來簡單也很簡單，要說難得話，也很難。就想用一些通俗的語言與思路去理解這個概念，下面我就講一下自己的理解，希望對你的學習有幫助！
「集成」從何而來？
軟體集成的概念其來源是IT行業，上位機的應用程序的開發，對於車輛控制系統來說，集成的這個概念是隨著車輛控制單元的複雜度的提升，而衍生出來的概念，並以原來IT行業的標準，對其進行定義。以前車輛控制系統的代碼也就幾百行，所以沒有集成的概念，而IT行業代碼複雜程度太大，所以就有了協同開發，也就我們所說的集成。
「集成」定義及分類
集成，顧明思義就是將不同的需求，分塊開發，然後再將開發過的板塊進行糅合，生成新的軟體。具體結構如下圖所示，根據公司以及項目的不同，可能大家理解的集成有以下幾種類型。
一類為代碼類模塊的集成， 一類為應用層模型的集成。這兩類的集成都在對應的集成環境下進行，不同的公司有不同的工具，其實codewarrior就可以理解為一個集成環境，目前我接觸的大多數的大公司都是基於eclipse 平台進行自己個性化的開發，比如利用Perl, Python,進行開發自己的編譯指令，同時也可以嵌套一下QAC的檢查。下面就簡單對兩個概念進行介紹。
代碼類模塊的集成
若此軟體是基於代碼，可以理解為代碼的集成，對於代碼的集成需要考慮以下幾點：
- 系統配置變數分析
一個版本的軟體，通過不同的配置可以應用於不同的客戶，所以在集成的時候，要考慮這個模塊的配置是哪些，系統的配置變數是否符合設計的初衷，若不符合，需要在軟體系統中，重新定義，若缺少，也需要進行增加。
- 代碼模塊輸入變數分析
當完成一個模塊的代碼編寫的時候，進行單元測試，大多對於介面的變數定義都是寫在一個專有的.c或者.h內部，進行單元測試，當進行集成的時候，需要考慮這些輸入變數 ，是否是系統中其它模塊的輸出，若不是，需要進行分析原因
- 代碼模塊的任務調度的定義
每一個代碼模塊包含不同執行周期的task，每一個task都需要在整體軟體系統的os scheduling裡面定義，需要進行考慮。
對這個概念也可以理解為一個蓋房子的過程，如下圖所示，將不同的模塊糅合到一起
應用層模型的集成
此類集成多用於應用層，尤其是Autosar架構，OSEK架構等， 當一個軟體不是有一個公司完成的情況下尤其適用 。例如當前很多國產廠商做控制單元，都是買的外國公司的底層及OS層，自己開發應用層，這樣開發的應用層，大多都是基於模型的開發。每個公司僅僅關注自己的演算法就可以，然後按照Autosar的架構進行打包，主機廠進行各個軟體包進行集成。
對這個集成的描述，大家可以理解為蓋房子。
文章描述的總結如下：
- 代碼的集成，多為軟體工程師的工作。
- 模型的集成，多為系統工程師，控制工程師的工作。
- 代碼集成，關注三個點，輸入輸出變數，系統配置變數，任務Scheduling配置。
- 模型集成，需要遵守一定的模型規則及標準，比如Autosar, OSEK。
- 集成後需要做的工作，模塊功能測試，模塊代碼質量測試，軟體配置測試，軟體系統功能測試，然後釋放軟體，此軟體僅僅包含邏輯部分，不包含代碼部分。
- 集成的工具很多，大多數的大公司都是獨立成章，自己的集成工具。
對於這個問題，我也在知乎上提問了，而且也有幾位大神回復，感興趣的可以參考！
車輛控制系統軟體的集成，大家如何理解這個概念？尤其在寫代碼與做模型的時候，如何去集成？大家的經驗是啥？
若有啥問題，隨時與我聯繫，相互學習！也望大神不吝賜教！
打個廣告，感覺不錯，別忘了點贊，對我與我的專欄加關注呀！ 哈哈哈哈！
推薦閱讀：