為了保證軟件（應(yīng)用層和底層）開發(fā)的質(zhì)量和效率，當(dāng)前成熟的ECU軟件開發(fā)都會(huì)采用V流程形式。

所有工程過程（即：系統(tǒng)工程和軟件工程）是按照“V” 字模型原理進(jìn)行組織：左邊的每個(gè)過程是與右邊的過程正好相對應(yīng)。因此，過程 SWE.3 “軟件詳細(xì)設(shè)計(jì)與單元構(gòu)建” 與 SWE.4 “軟件單元驗(yàn)證”是分離的。

V流程來源于軟件開發(fā)過程中一個(gè)稱為快速應(yīng)用開發(fā)的模型，由于該模型的構(gòu)圖形似字母V，所以俗稱V模型。V模型是軟件開發(fā)、測試中最重要的一種模型，其大體可劃分為幾個(gè)不同的階段步驟，即功能需求、功能開發(fā)、軟件開發(fā)、軟件集成測試、功能集成測試、整車集成測試（系統(tǒng)合格性測試），如上圖所示。左邊為需求分析和設(shè)計(jì)開發(fā)的過程，右邊則為針對左邊的測試驗(yàn)證。

從系統(tǒng)需求到軟件需求，再到軟件的釋放，需要工具對其進(jìn)行管理，以達(dá)到可追溯，可記錄的目的，目前市場主流的工具含有 Door,ClearCase,GIT,SDOM 等，同時(shí)也有公司自己研發(fā)的一些流程工具。這些工具的運(yùn)作方式都遵循需求，研發(fā)，測試的V流程。

在架構(gòu)設(shè)計(jì)過程中，需要使用EA架構(gòu)設(shè)計(jì)工具，isolar等AUTOSAR配置工具。

軟件實(shí)現(xiàn)過程中，需要使用到Matlab等模型開發(fā)工具。

軟件組件集成過程中需要使用到編譯工具。

軟件組件測試過程中需要使用到Tessy等測試工具。

一、軟件開發(fā)v流程的實(shí)施

1. 系統(tǒng)需求分析

這部分為系統(tǒng)需求。需要系統(tǒng)工程師完成。

基于項(xiàng)目的整體需求，以及軟硬件整體定義，對系統(tǒng)邏輯架構(gòu)進(jìn)行整體定義，這部分工作包括：硬件功能定義，控制器與其他控制器通信定義，軟件簡要功能定義。這個(gè)過程并不會(huì)對具體的技術(shù)實(shí)現(xiàn)做出定義。

通常會(huì)使用Doors等流程軟件定義系統(tǒng)需求。

2. 軟件需求分析

這部分為軟件需求，需要系統(tǒng)工程師完成。

系統(tǒng)工程師根據(jù)系統(tǒng)相關(guān)方需求說明書、軟硬件接口文件、變更通知書等輸入，梳理定義軟件研發(fā)需求說明書，包括操作系統(tǒng)需求、電源管理策略、傳感器讀取，執(zhí)行器控制、信號特性需求、存儲服務(wù)、通信服務(wù)，網(wǎng)絡(luò)管理、故障診斷、標(biāo)定、程序升級等功能需求和非功能需求。

根據(jù)項(xiàng)目規(guī)劃，制定軟件開發(fā)計(jì)劃。

軟件需求分析建立需求追蹤矩陣，將軟件需求映射到系統(tǒng)需求，確保軟件要實(shí)現(xiàn)的系統(tǒng)需求全部覆蓋，為了完成這個(gè)功能，通常我們也是使用Doors等流程軟件完成。

成功實(shí)施這個(gè)過程的結(jié)果如下：

1) 定義了系統(tǒng)中分配給軟件要素的軟件需求及其接口；

2) 將軟件需求進(jìn)行分類，并分析了其正確性和可驗(yàn)證性；

3) 分析了軟件需求對運(yùn)行環(huán)境的影響；

4) 定義了軟件需求實(shí)現(xiàn)的優(yōu)先級；

5) 根據(jù)需要更新了軟件需求；

6) 在系統(tǒng)需求與軟件需求之間、在系統(tǒng)架構(gòu)設(shè)計(jì)與軟件需求之間建立了一致性和雙向可追溯性；

7) 從成本、進(jìn)度和技術(shù)影響來評估軟件需求；

8) 約定了軟件需求，并與所有受影響方溝通。

3. 軟件架構(gòu)設(shè)計(jì)

這部分為軟件架構(gòu)，需要架構(gòu)工程師完成。

為了建立清晰的、結(jié)構(gòu)化的軟件設(shè)計(jì)，應(yīng)該統(tǒng)一分配軟件需求，然后完成軟件架構(gòu)設(shè)計(jì)。根據(jù)系統(tǒng)相關(guān)需求、軟硬件接口表、軟件需求確定軟件架構(gòu)。將每條軟件需求合理分配到軟件模塊中，定義每個(gè)軟件模塊的輸入輸出接口、動(dòng)態(tài)行為、資源消耗目標(biāo)等，評估多種軟件架構(gòu)的優(yōu)缺點(diǎn)等。

架構(gòu)工程師需要使用EA等架構(gòu)軟件畫出整個(gè)控制器軟件所有模塊的輸入輸出接口、以及內(nèi)部動(dòng)態(tài)行為。

如果項(xiàng)目基于AUTOSAR開發(fā)，需要架構(gòu)工程師配置應(yīng)用層的所有組件，并輸出每個(gè)組件的ARXML描述文件。

一般來說，還需要架構(gòu)工程師輸出架構(gòu)文檔。

成功實(shí)施這個(gè)過程的結(jié)果如下：

1) 定義了識別軟件要素的軟件架構(gòu)設(shè)計(jì)；

2) 將軟件需求分配給軟件的要素

3) 定義了每個(gè)軟件要素的接口

4) 定義了軟件要素的動(dòng)態(tài)行為和資源消耗目標(biāo)

5) 建立了軟件需求與軟件架構(gòu)設(shè)計(jì)之間的一致性和雙向可追溯性

6) 約定了軟件架構(gòu)設(shè)計(jì)，并與所有受影響方溝通。

4. 軟件單元設(shè)計(jì)和軟件實(shí)現(xiàn)

這部分為軟件單元設(shè)計(jì)，需要軟件開發(fā)工程師完成。

在此階段，需要對每個(gè)組件內(nèi)部的算法邏輯進(jìn)行詳細(xì)的內(nèi)部設(shè)計(jì)。組件功能的詳細(xì)設(shè)計(jì)需要與軟件需求建立有效的對應(yīng)關(guān)系。

如果是算法邏輯編碼，建議使用Matlab進(jìn)行模型開發(fā)，如果是接近底層的復(fù)雜驅(qū)動(dòng)，一般是使用手寫代碼。

如果項(xiàng)目使用AUTOSAR架構(gòu)，使用模型開發(fā)時(shí)需要導(dǎo)入arxml生成模型框架進(jìn)行開發(fā)，使用手寫代碼進(jìn)行開發(fā)時(shí)需要使用AUTOSAR工具生成的組件代碼框架進(jìn)行開發(fā)。

需要將代碼經(jīng)過多次代碼審查和優(yōu)化之后，將最終版本上傳至代碼庫，以實(shí)現(xiàn)最佳的可靠性和性能。

成功實(shí)施這個(gè)過程的結(jié)果如下：

1) 開發(fā)了描述軟件單元的詳細(xì)設(shè)計(jì)；

2) 定義了各軟件單元的接口；

3) 定義了軟件單元的動(dòng)態(tài)行為；

4) 建立了軟件需求與軟件單元之間的一致性和雙向可追溯性；建立了軟件架構(gòu)設(shè)計(jì)與軟件詳細(xì)設(shè)計(jì)之間的一致性和雙向可追溯性；建立了軟件詳細(xì)設(shè)計(jì)與軟件單元之間一致性和雙向可追溯性；

5) 約定了軟件詳細(xì)設(shè)計(jì)及該設(shè)計(jì)與軟件架構(gòu)設(shè)計(jì)的關(guān)系，并和所有受影響

方溝通；

6) 生成了軟件詳細(xì)設(shè)計(jì)所定義的軟件單元。

6. 軟件單元測試

當(dāng)進(jìn)行單元測試通過后，將會(huì)將軟件編譯成ECU可執(zhí)行的文件，比如Hex格式的文件，將其刷寫到ECU進(jìn)行集成測試（或稱HIL測試），如果只是測試底層軟件，那么一般只需要額外的硬件負(fù)載箱支持就行，比如用負(fù)載箱來模擬一些傳感器信號輸入，或制造一些執(zhí)行器的短路和開路故障；如果測試包括應(yīng)用層軟件，那么就還需要物理模型支持才行，比如電機(jī)控制就需要電機(jī)的物理模型，變速箱控制可能就需要整個(gè)動(dòng)力傳動(dòng)系統(tǒng)的模型才行。

這部分為組件單元測試，一般需要軟件開發(fā)工程師完成，也可以讓測試工程師完成。

單元測試與軟件單元設(shè)計(jì)對應(yīng)。

單元測試是根據(jù)軟件單元設(shè)計(jì)，進(jìn)行代碼級別上進(jìn)行的測試。

單元測試一般可以通過Matlab和Tessy等工具進(jìn)行。

成功實(shí)施這個(gè)過程的結(jié)果如下：

1) 制訂了包括回歸策略在內(nèi)的軟件單元驗(yàn)證策略，以驗(yàn)證軟件單元；

2) 根據(jù)軟件單元驗(yàn)證策略，制訂了軟件單元驗(yàn)證準(zhǔn)則，以適于提供軟件單元符合軟件詳細(xì)設(shè)計(jì)及非功能性軟件需求的證據(jù)；

3) 根據(jù)軟件單元驗(yàn)證策略及軟件單元驗(yàn)證準(zhǔn)則，驗(yàn)證了軟件單元并記錄了結(jié)果；

4) 建立了軟件單元、驗(yàn)證準(zhǔn)則及驗(yàn)證結(jié)果之間的雙向可追溯性和一致性；

5) 總結(jié)了單元驗(yàn)證結(jié)果，并與所有受影響方溝通。

7. 軟件集成測試

這部分為集成測試，需要測試工程師完成。

集成測試與軟件需求對應(yīng)。

集成測試將各個(gè)組成部分整合入一個(gè)軟件系統(tǒng)中之后，最后進(jìn)行軟件的集成測試。根據(jù)定義的需求，測試相應(yīng)的功能是否滿足軟件需求。

成功實(shí)施本過程的結(jié)果如下：

1) 制訂了與項(xiàng)目計(jì)劃、發(fā)布計(jì)劃和軟件架構(gòu)設(shè)計(jì)相一致的軟件集成策略，以集成軟件項(xiàng)；

2) 制訂了包括軟件回歸測試策略在內(nèi)的軟件集成測試策略，以測試軟件單元之間和軟件項(xiàng)之間的交互；

3) 根據(jù)軟件集成測試策略，開發(fā)了軟件集成測試規(guī)范，以適于提供集成的軟件項(xiàng)符合軟件架構(gòu)設(shè)計(jì)（包括軟件單元之間和軟件項(xiàng)之間的接口）的證據(jù)；

4) 根據(jù)集成策略集成了軟件單元和軟件項(xiàng)直至完整的集成軟件；

5) 根據(jù)軟件集成測試策略和發(fā)布計(jì)劃，選擇了軟件集成測試規(guī)范中的測試用例；

6) 使用選定的測試用例測試了集成的軟件項(xiàng)，并記錄了測試結(jié)果；

7) 建立了軟件架構(gòu)設(shè)計(jì)要素與軟件集成測試規(guī)范中的測試用例之間的一致性和雙向可追溯性，并建立了測試用例與測試結(jié)果之間的一致性和雙向可追溯性；

8) 總結(jié)了軟件集成測試結(jié)果，并與所有受影響方溝通。

8. 軟件系統(tǒng)測試

這部分為系統(tǒng)測試，需要測試工程師完成。

系統(tǒng)測試與系統(tǒng)需求對應(yīng)。

因?yàn)檐浖o各個(gè)ECU提供了相應(yīng)的功能，因此在集成測試中，需要將軟件燒錄至硬件中。然后ECU要與其他電子系統(tǒng)組件集成起來，比如傳感器和執(zhí)行器。在接下來的系統(tǒng)綜合測試中，對所有系統(tǒng)設(shè)備的交互響應(yīng)進(jìn)行評估。

成功實(shí)施本過程的結(jié)果如下：

1) 制訂了與項(xiàng)目計(jì)劃和發(fā)布計(jì)劃相一致的包括回歸測試策略在內(nèi)的軟件合格性測試策略，以測試集成軟件；

2) 根據(jù)軟件合格性測試策略，開發(fā)了集成軟件的軟件合格性測試規(guī)范，以適于提供符合軟件需求的證據(jù)；

3) 根據(jù)軟件合格性測試策略和發(fā)布計(jì)劃，選擇了軟件合格性測試規(guī)范中的測試用例；

4) 使用選定的測試用例測試了集成軟件，并記錄了軟件合格性測試結(jié)果；

5) 建立了軟件需求與軟件合格性測試規(guī)范中的測試用例之間的一致性和雙向可追溯性，建立了測試用例與測試結(jié)果之間的一致性和雙向的可追溯性；

6) 總結(jié)了軟件合格性測試結(jié)果，并與所有受影響方溝通。

二、軟件開發(fā)中的術(shù)語

下圖描述了在工程過程中一致使用的要素、組件、軟件單元和項(xiàng)之間的關(guān)系。

架構(gòu)包括架構(gòu)“要素”，可以被進(jìn)一步分解到各合適層級上的架構(gòu)子“要素”。軟件“組件”是軟件架構(gòu)的最低層級的“要素”，以定義最終的詳細(xì)設(shè)計(jì)。一個(gè)軟件“組件”可包含一個(gè)或多個(gè)軟件“單元”。

在 V 模型右邊的“項(xiàng)”對應(yīng)到左邊的“要素”（如：軟件“項(xiàng)”可以是對象文件、庫或可執(zhí)行形式）。這可以是 1:1 或 m:n 的關(guān)系，如：一個(gè)項(xiàng)可表示超過一個(gè)架構(gòu)“要素”。

三、軟件開發(fā)中的追溯性和一致性

追溯性和一致性在 Automotive SPICE 3.1 PAM 是通過兩個(gè)單獨(dú)的基本實(shí)踐來提出。追溯性指的是在工作產(chǎn)品之間存在引用或鏈接，由此可以進(jìn)一步支持覆蓋率、影響分析、需求實(shí)施狀態(tài)跟蹤等。相反，一致性關(guān)注內(nèi)容和語義。

此外，雙向可追溯性可被明確地定義在測試用例和測試結(jié)果之間 、變更請求和受這些變更請求影響的工作產(chǎn)品之間 、雙向可追溯性和一致性的概覽見下圖所示。