為了保證軟件（應用層和底層）開發的質量和效率，當前成熟的ECU軟件開發都會采用V流程形式。
所有工程過程（即：系統工程和軟件工程）是按照“V” 字模型原理進行組織：左邊的每個過程是與右邊的過程正好相對應。因此，過程 SWE.3 “軟件詳細設計與單元構建” 與 SWE.4 “軟件單元驗證”是分離的。
V流程來源于軟件開發過程中一個稱為快速應用開發的模型，由于該模型的構圖形似字母V，所以俗稱V模型。V模型是軟件開發、測試中最重要的一種模型，其大體可劃分為幾個不同的階段步驟，即功能需求、功能開發、軟件開發、軟件集成測試、功能集成測試、整車集成測試（系統合格性測試），如上圖所示。左邊為需求分析和設計開發的過程，右邊則為針對左邊的測試驗證。
從系統需求到軟件需求，再到軟件的釋放，需要工具對其進行管理，以達到可追溯，可記錄的目的，目前市場主流的工具含有 Door,ClearCase,GIT,SDOM 等，同時也有公司自己研發的一些流程工具。這些工具的運作方式都遵循需求，研發，測試的V流程。
在架構設計過程中，需要使用EA架構設計工具，isolar等AUTOSAR配置工具。
軟件實現過程中，需要使用到Matlab等模型開發工具。
軟件組件集成過程中需要使用到編譯工具。
軟件組件測試過程中需要使用到Tessy等測試工具。
一、軟件開發v流程的實施
- 系統需求分析
這部分為系統需求。需要系統工程師完成。
基于項目的整體需求，以及軟硬件整體定義，對系統邏輯架構進行整體定義，這部分工作包括：硬件功能定義，控制器與其他控制器通信定義，軟件簡要功能定義。這個過程并不會對具體的技術實現做出定義。
通常會使用Doors等流程軟件定義系統需求。
2. 軟件需求分析
這部分為軟件需求，需要系統工程師完成。
系統工程師根據系統相關方需求說明書、軟硬件接口文件、變更通知書等輸入，梳理定義軟件研發需求說明書，包括操作系統需求、電源管理策略、傳感器讀取，執行器控制、信號特性需求、存儲服務、通信服務，網絡管理、故障診斷、標定、程序升級等功能需求和非功能需求。
根據項目規劃，制定軟件開發計劃。
軟件需求分析建立需求追蹤矩陣，將軟件需求映射到系統需求，確保軟件要實現的系統需求全部覆蓋，為了完成這個功能，通常我們也是使用Doors等流程軟件完成。
成功實施這個過程的結果如下：
1) 定義了系統中分配給軟件要素的軟件需求及其接口；
2) 將軟件需求進行分類，并分析了其正確性和可驗證性；
3) 分析了軟件需求對運行環境的影響；
4) 定義了軟件需求實現的優先級；
5) 根據需要更新了軟件需求；
6) 在系統需求與軟件需求之間、在系統架構設計與軟件需求之間建立了一致性和雙向可追溯性；
7) 從成本、進度和技術影響來評估軟件需求；
8) 約定了軟件需求，并與所有受影響方溝通。
3. 軟件架構設計
這部分為軟件架構，需要架構工程師完成。
為了建立清晰的、結構化的軟件設計，應該統一分配軟件需求，然后完成軟件架構設計。根據系統相關需求、軟硬件接口表、軟件需求確定軟件架構。將每條軟件需求合理分配到軟件模塊中，定義每個軟件模塊的輸入輸出接口、動態行為、資源消耗目標等，評估多種軟件架構的優缺點等。
架構工程師需要使用EA等架構軟件畫出整個控制器軟件所有模塊的輸入輸出接口、以及內部動態行為。
如果項目基于AUTOSAR開發，需要架構工程師配置應用層的所有組件，并輸出每個組件的ARXML描述文件。
一般來說，還需要架構工程師輸出架構文檔。
成功實施這個過程的結果如下：
1) 定義了識別軟件要素的軟件架構設計；
2) 將軟件需求分配給軟件的要素
3) 定義了每個軟件要素的接口
4) 定義了軟件要素的動態行為和資源消耗目標
5) 建立了軟件需求與軟件架構設計之間的一致性和雙向可追溯性
6) 約定了軟件架構設計，并與所有受影響方溝通。
4. 軟件單元設計和軟件實現
這部分為軟件單元設計，需要軟件開發工程師完成。
在此階段，需要對每個組件內部的算法邏輯進行詳細的內部設計。組件功能的詳細設計需要與軟件需求建立有效的對應關系。
如果是算法邏輯編碼，建議使用Matlab進行模型開發，如果是接近底層的復雜驅動，一般是使用手寫代碼。
如果項目使用AUTOSAR架構，使用模型開發時需要導入arxml生成模型框架進行開發，使用手寫代碼進行開發時需要使用AUTOSAR工具生成的組件代碼框架進行開發。
需要將代碼經過多次代碼審查和優化之后，將最終版本上傳至代碼庫，以實現最佳的可靠性和性能。
成功實施這個過程的結果如下：
1) 開發了描述軟件單元的詳細設計；
2) 定義了各軟件單元的接口；
3) 定義了軟件單元的動態行為；
4) 建立了軟件需求與軟件單元之間的一致性和雙向可追溯性；建立了軟件架構設計與軟件詳細設計之間的一致性和雙向可追溯性；建立了軟件詳細設計與軟件單元之間一致性和雙向可追溯性；
5) 約定了軟件詳細設計及該設計與軟件架構設計的關系，并和所有受影響
方溝通；
6) 生成了軟件詳細設計所定義的軟件單元。
6. 軟件單元測試
當進行單元測試通過后，將會將軟件編譯成ECU可執行的文件，比如Hex格式的文件，將其刷寫到ECU進行集成測試（或稱HIL測試），如果只是測試底層軟件，那么一般只需要額外的硬件負載箱支持就行，比如用負載箱來模擬一些傳感器信號輸入，或制造一些執行器的短路和開路故障；如果測試包括應用層軟件，那么就還需要物理模型支持才行，比如電機控制就需要電機的物理模型，變速箱控制可能就需要整個動力傳動系統的模型才行。
這部分為組件單元測試，一般需要軟件開發工程師完成，也可以讓測試工程師完成。
單元測試與軟件單元設計對應。
單元測試是根據軟件單元設計，進行代碼級別上進行的測試。
單元測試一般可以通過Matlab和Tessy等工具進行。
成功實施這個過程的結果如下：
1) 制訂了包括回歸策略在內的軟件單元驗證策略，以驗證軟件單元；
2) 根據軟件單元驗證策略，制訂了軟件單元驗證準則，以適于提供軟件單元符合軟件詳細設計及非功能性軟件需求的證據；
3) 根據軟件單元驗證策略及軟件單元驗證準則，驗證了軟件單元并記錄了結果；
4) 建立了軟件單元、驗證準則及驗證結果之間的雙向可追溯性和一致性；
5) 總結了單元驗證結果，并與所有受影響方溝通。
7. 軟件集成測試
這部分為集成測試，需要測試工程師完成。
集成測試與軟件需求對應。
集成測試將各個組成部分整合入一個軟件系統中之后，最后進行軟件的集成測試。根據定義的需求，測試相應的功能是否滿足軟件需求。
成功實施本過程的結果如下：
1) 制訂了與項目計劃、發布計劃和軟件架構設計相一致的軟件集成策略，以集成軟件項；
2) 制訂了包括軟件回歸測試策略在內的軟件集成測試策略，以測試軟件單元之間和軟件項之間的交互；
3) 根據軟件集成測試策略，開發了軟件集成測試規范，以適于提供集成的軟件項符合軟件架構設計（包括軟件單元之間和軟件項之間的接口）的證據；
4) 根據集成策略集成了軟件單元和軟件項直至完整的集成軟件；
5) 根據軟件集成測試策略和發布計劃，選擇了軟件集成測試規范中的測試用例；
6) 使用選定的測試用例測試了集成的軟件項，并記錄了測試結果；
7) 建立了軟件架構設計要素與軟件集成測試規范中的測試用例之間的一致性和雙向可追溯性，并建立了測試用例與測試結果之間的一致性和雙向可追溯性；
8) 總結了軟件集成測試結果，并與所有受影響方溝通。
8. 軟件系統測試
這部分為系統測試，需要測試工程師完成。
系統測試與系統需求對應。
因為軟件給各個ECU提供了相應的功能，因此在集成測試中，需要將軟件燒錄至硬件中。然后ECU要與其他電子系統組件集成起來，比如傳感器和執行器。在接下來的系統綜合測試中，對所有系統設備的交互響應進行評估。
成功實施本過程的結果如下：
1) 制訂了與項目計劃和發布計劃相一致的包括回歸測試策略在內的軟件合格性測試策略，以測試集成軟件；
2) 根據軟件合格性測試策略，開發了集成軟件的軟件合格性測試規范，以適于提供符合軟件需求的證據；
3) 根據軟件合格性測試策略和發布計劃，選擇了軟件合格性測試規范中的測試用例；
4) 使用選定的測試用例測試了集成軟件，并記錄了軟件合格性測試結果；
5) 建立了軟件需求與軟件合格性測試規范中的測試用例之間的一致性和雙向可追溯性，建立了測試用例與測試結果之間的一致性和雙向的可追溯性；
6) 總結了軟件合格性測試結果，并與所有受影響方溝通。
二、軟件開發中的術語
下圖描述了在工程過程中一致使用的要素、組件、軟件單元和項之間的關系。
架構包括架構“要素”，可以被進一步分解到各合適層級上的架構子“要素”。軟件“組件”是軟件架構的最低層級的“要素”，以定義最終的詳細設計。一個軟件“組件”可包含一個或多個軟件“單元”。
在 V 模型右邊的“項”對應到左邊的“要素”（如：軟件“項”可以是對象文件、庫或可執行形式）。這可以是 1:1 或 m:n 的關系，如：一個項可表示超過一個架構“要素”。
三、軟件開發中的追溯性和一致性
追溯性和一致性在 Automotive SPICE 3.1 PAM 是通過兩個單獨的基本實踐來提出。追溯性指的是在工作產品之間存在引用或鏈接，由此可以進一步支持覆蓋率、影響分析、需求實施狀態跟蹤等。相反，一致性關注內容和語義。
此外，雙向可追溯性可被明確地定義在測試用例和測試結果之間 、變更請求和受這些變更請求影響的工作產品之間 、雙向可追溯性和一致性的概覽見下圖所示。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
