下圖是一個(gè)抽象出來的控制模型。駕駛員通過方向盤、踏板和換擋桿等給出期望（W*）操控汽車。這一系列實(shí)實(shí)在在、看得見摸得著的期望被轉(zhuǎn)化為抽象的電子信號（W）進(jìn)入電控單元。隨后電控單元通過比較駕駛員期望（W）和傳感器傳回的當(dāng)前實(shí)際值（R）進(jìn)行對比。若對比發(fā)現(xiàn)，期望與現(xiàn)實(shí)存在差距，電控單元中的軟件程序會通過邏輯計(jì)算給出指令（U）操控執(zhí)行器做出響應(yīng)（Y）?？刂茖ο笤趫?zhí)行器的動作和環(huán)境的影響（Z）下，開始做出駕駛員期待的反應(yīng)（X）。這一反應(yīng)（X）又會通過傳感器監(jiān)控、感知，當(dāng)前狀態(tài)（R）將再次返回電控單元完成控制閉合回路。


（控制模型）

聽起來十分復(fù)雜抽象，這里舉一個(gè)剎車輔助系統(tǒng)的例子來說明。

緊急剎車時(shí)，如果駕駛員腳力不足或反應(yīng)較慢，沒有及時(shí)將剎車完全踩死、踩滿會導(dǎo)致剎車系統(tǒng)無法全力工作，在這種情況下這套系統(tǒng)就將被激活。在駕駛員剎車踏板輸入不變的前提下，自動提高制動力使汽車更快減速。

例如，行車中遇到緊急情況，駕駛員抬起油門后，快速用力地踩下剎車踏板期望汽車迅速減速（W*）。剎車踏板通過采集踏板值變化率、踏板受力等信號（W）得到駕駛員踩剎車踏板的輕重、緩急等信息，理解駕駛員意圖。W作為電子信號傳入相應(yīng)的電控單元中。同樣傳入電控單元的還有傳感器的實(shí)時(shí)測量數(shù)據(jù)（R），例如當(dāng)前輪胎轉(zhuǎn)速或車速。若軟件通過比較發(fā)現(xiàn)，當(dāng)前輪速高、車速快、減速度不足，駕駛員踩下的剎車踏板深度不足以讓剎車系統(tǒng)發(fā)揮出最大功能，最終得出液壓制動系統(tǒng)需要進(jìn)一步剎車的結(jié)論（U）。


（電子控制單元）

位于輪胎附近的制動卡鉗接到指令（U）開始工作讓輪胎轉(zhuǎn)速變慢。結(jié)果由于路面結(jié)冰的影響（Z）車輪在強(qiáng)制動力的作用下開始抱死打滑，一系列制動工作沒有讓汽車達(dá)到預(yù)期的減速效果。傳感器將發(fā)生的這一切以電子信號的形式通過通信線束（R）實(shí)時(shí)傳回電控單元。軟件邏輯將因此激活防抱死系統(tǒng)ABS，操控制動系統(tǒng)做出響應(yīng)并不斷接受傳感器的控制反饋，最終達(dá)到讓汽車減速這一駕駛員期望。

這一次次的控制，在電控單元中以10ms甚至更快的速度循環(huán)進(jìn)行著。


（電子控制單元及其剖面圖）

以上是一個(gè)十分簡單的電控例子，只有一個(gè)電控單元參與其中。而現(xiàn)如今許多復(fù)雜的汽車功能常常需要由多個(gè)電控單元、多個(gè)傳感器聯(lián)合控制才能實(shí)現(xiàn)。

例如自適應(yīng)定速巡航功能ACC，駕駛員通過設(shè)定期望巡航速度、與前車保持的期望距離等實(shí)現(xiàn)駕駛輔助系統(tǒng)一定程度上接管汽車的功能。這一功能就需要多個(gè)電控單元協(xié)作完成并且通過總線讓它們隨時(shí)保持通信聯(lián)系。ACC控制器、雷達(dá)控制器、發(fā)動機(jī)控制器、ESP控制器、變速箱控制器、人機(jī)交互控制器以及數(shù)不清的傳感器和執(zhí)行器都將參與其中。

可以說，軟件和硬件系統(tǒng)相互合作，共同為汽車創(chuàng)造出一個(gè)個(gè)新的功能奇跡。

2、軟件系統(tǒng)的出現(xiàn)

急劇攀升的軟件代碼量、龐雜的總線通信導(dǎo)致汽車電子系統(tǒng)日漸復(fù)雜。

根據(jù)ADAC（全德汽車俱樂部，德國最大的交通協(xié)會）統(tǒng)計(jì)，德國2004年有40%的車輛故障最終歸咎于軟件問題或電子部件故障。為此，必須在保證電子系統(tǒng)整體可控的前提下研發(fā)新功能，軟件工程師絕不能容忍自己迷失在親手創(chuàng)建的龐大系統(tǒng)中。

正如汽車行業(yè)的那句老話：Divide et Impera！維基百科對應(yīng)的中文詞條將它翻譯為“分而治之”。德語將這句拉丁語翻譯為Teile und beherssche！，直譯中文是拆解和掌控。

首先，如上圖所示將電子系統(tǒng)研發(fā)拆解為軟件系統(tǒng)、硬件系統(tǒng)、傳感器和執(zhí)行器研發(fā)四大部分，經(jīng)過V模型流程研發(fā)，最終再次集成。這個(gè)V模型涵蓋了從系統(tǒng)層面到軟件層面以及集成后的功能測試和系統(tǒng)測試等流程，是當(dāng)今汽車行業(yè)廣泛應(yīng)用的開發(fā)流程。因?yàn)槠湫螤钊缱帜竀而因此得名。

下面將以下圖所示的軟件系統(tǒng)開發(fā)為例，分步驟介紹V模型。

1、分析終端客戶需求、定義邏輯系統(tǒng)架構(gòu)

這一步是根據(jù)終端客戶的需求以及法規(guī)需求定義出整車軟件系統(tǒng)的邏輯架構(gòu)。其中包含各大功能塊的定義，功能塊接口定義和功能塊之間的通信定義。這一步僅考慮滿足原始需求，不會涉及任何技術(shù)層面的具體分析。

2、分析邏輯系統(tǒng)架構(gòu)需求、定義技術(shù)層面系統(tǒng)架構(gòu)

邏輯系統(tǒng)架構(gòu)為定義具體的技術(shù)層面系統(tǒng)架構(gòu)提供了基礎(chǔ)。在這一步中開始討論具體的技術(shù)問題，哪些功能將通過軟件實(shí)現(xiàn)、軟件塊分裝在哪些電子控制單元以及電控單元之間采用什么通信協(xié)議等等。軟件系統(tǒng)初現(xiàn)雛形。

3、分析軟件需求、定義軟件架構(gòu)

這里開始具體到電控單元中對于軟件本身的需求分析。根據(jù)需求，定義出合適的軟件架構(gòu)。同時(shí)，還要考慮電控單元存儲資源的最優(yōu)使用、為滿足安全法規(guī)的冗余系統(tǒng)設(shè)計(jì)等等。這里，會把軟件進(jìn)一步細(xì)分為更小的軟件部件，定義各個(gè)部件之間的接口、分層和邊界。

4、定義軟件部件

針對每個(gè)軟件部件會繼續(xù)定義出需求。這里的需求集中在功能層面，尚不考慮具體的軟件實(shí)現(xiàn)方式等。

5、設(shè)計(jì)、實(shí)現(xiàn)及測試軟件部件

依據(jù)具體的需求，工程師開始分別搭建不同的軟件部件。在前面一系列的拆解、分析和定義后，終于抵達(dá)了軟件最核心最具體的世界——代碼。與人們熟知的程序員直接寫代碼稍有區(qū)別，傳統(tǒng)的汽車軟件研發(fā)采用的是基于模型開發(fā)。

如下圖所示，邏輯運(yùn)算通過模型的方式表達(dá)出來，相比于代碼更加直觀，便于日后的標(biāo)定工作和維護(hù)。在一個(gè)電控單元中，有上千個(gè)這樣的功能函數(shù)，如下圖所示的功能模型組合到一起，會形成一份上萬頁的文件。這份文件是接下來所有流程的基礎(chǔ)。

當(dāng)然這套模型只是工程師之間便于交流的高級語言，最終它們會被人工或計(jì)算機(jī)轉(zhuǎn)為代碼進(jìn)入控制器中工作。

早年間，模型到代碼中間的轉(zhuǎn)換工作由人工完成。這造成的問題是，代碼無法統(tǒng)一化和標(biāo)準(zhǔn)化。面對一個(gè)軟件邏輯模型，程序員可以用多種方法完成代碼編譯工作，達(dá)到同樣的功能效果。

但是，代碼運(yùn)行所占用的硬件資源或嚴(yán)謹(jǐn)度會大不相同。因此，近年來轉(zhuǎn)碼工作逐漸被機(jī)器取代。軟件工程師事先定義標(biāo)準(zhǔn)的編譯規(guī)范，保證最終代碼統(tǒng)一和標(biāo)準(zhǔn)。

每一個(gè)軟件部件完成后，要進(jìn)行相應(yīng)的軟件測試。這里還不會聚焦功能層面的測試，僅僅針對軟件本身。

例如軟件中是否因設(shè)計(jì)不當(dāng)產(chǎn)生死循環(huán)、每個(gè)信號定義的范圍是否恰當(dāng)、會不會造成溢出錯誤或者會不會出現(xiàn)除以零的運(yùn)算情況等等。針對這些，工程師要事先定義測試方案，由計(jì)算機(jī)進(jìn)行全方位全覆蓋的軟件邏輯測試。例如，對于if, else語句需要把每一種可能的情況都測試檢查到。