目錄
1、V模型概述
2、V模型實施
2.1、系統需求分析
2.2、軟體需求分析
2.3、軟體架構設計
2.4、軟體單元設計和軟體實作
2.5、軟體單元測試
2.6、軟體內建測試
2.7、軟體系統測試
3、V模型的追溯性和一緻性要求
4、V模型面臨的挑戰
4.1、軟體2.0開發過程
4.2、軟體2.0新的軟體需求：資料集
4.3、軟體2.0開發工具鍊
金庸筆下有四大内功心法：《易筋經》、《九陰真經》、《九陽神功》和《神照經》，習武之人，必先修煉至高内功心法，再結合武功絕技，方可獨步武林。
做開發也是如此，除了需要高效的編碼能力，同樣也離不開程式設計思維的指導。作為剛剛進入汽車電子行業的開發小白，本篇博文将總結最近學習到的汽車軟體行業開發思維：V模型。
1、V模型概述
汽車軟體開發過程中的V模型對行業内開發者早已是司空見慣的模型，是由瀑布模型演變而來的，也是目前汽車行業運用最廣的軟體開發模型。由于該模型的構圖形似字母V，是以俗稱V模型。V模型核心思想是通過A-SPICE流程（汽車産業的軟體流程改進和能力測定标準）來支援和管理整個開發流程，從需求到源代碼的每個過程都有相應的測試。
V模型大體可劃分為幾個不同的階段步驟即：功能需求、功能開發、軟體開發、軟體內建測試、功能內建測試、整車內建測試（系統合格性測試），如下圖所示，左邊為需求分析和設計開發的過程，右邊則為針對左邊的測試驗證，左邊的每個過程是與右邊的過程正好相對應。
從系統需求到軟體需求，再到軟體的釋放，需要工具對其進行管理，以達到可追溯，可記錄的目的，目前市場主流的工具含有 Door、ClearCase、GIT、SDOM 等，也有公司自己研發的一些流程工具，當然這些工具的運作方式都遵循V流程的需求、研發和測試要求。
2、V模型實施
2.1、系統需求分析
系統需求需要系統工程師完成。
基于項目的整體需求，以及軟硬體整體定義，對系統邏輯架構進行整體定義，這部分工作包括：硬體功能定義，控制器與其他控制器通信定義，軟體簡要功能定義。這個過程并不會對具體的技術實作做出定義。
2.2、軟體需求分析
軟體需求需要系統工程師完成。
系統工程師根據系統相關方需求說明書、軟硬體接口檔案、變更通知書等輸入，梳理定義軟體研發需求說明書，包括作業系統需求、電源管理政策、傳感器讀取，執行器控制、信号特性需求、存儲服務、通信服務，網絡管理、故障診斷、标定、程式更新等功能需求和非功能需求。
根據項目規劃，制定軟體開發計劃。
軟體需求分析建立需求追蹤矩陣，将軟體需求映射到系統需求，確定軟體要實作的系統需求全部覆寫。
成功實施這個過程的結果如下：
- 定義系統中配置設定給軟體要素的軟體需求及其接口；
- 将軟體需求進行分類，并分析了其正确性和可驗證性；
- 分析軟體需求對運作環境的影響；
- 定義軟體需求實作的優先級；
- 根據需要更新了軟體需求；
- 在系統需求與軟體需求之間、在系統架構設計與軟體需求之間建立了一緻性和雙向可追溯性；
- 從成本、進度和技術影響來評估軟體需求；
- 約定了軟體需求，并與所有受影響方溝通。
2.3、軟體架構設計
軟體架構需要架構工程師完成。
為了建立清晰的、結構化的軟體設計，應該統一配置設定軟體需求，然後完成軟體架構設計。根據系統相關需求、軟硬體接口表、軟體需求确定軟體架構。将每條軟體需求合理配置設定到軟體子產品中，定義每個軟體子產品的輸入輸出接口、動态行為、資源消耗目标等，評估多種軟體架構的優缺點等。
架構工程師需要使用EA等架構軟體畫出整個控制器軟體所有子產品的輸入輸出接口、以及内部動态行為。
如果項目基于AUTOSAR開發，需要架構工程師配置應用層的所有元件，并輸出每個元件的ARXML描述檔案。
一般來說，還需要架構工程師輸出架構文檔。
成功實施這個過程的結果如下：
- 定義了識别軟體要素的軟體架構設計；
- 将軟體需求配置設定給軟體的要素；
- 定義每個軟體要素的接口；
- 定義軟體要素的動态行為和資源消耗目标；
- 建立軟體需求與軟體架構設計之間的一緻性和雙向可追溯性；
- 約定軟體架構設計，并與所有受影響方溝通。
2.4、軟體單元設計和軟體實作
軟體單元設計需要軟體開發工程師完成。
在此階段，需要對每個元件内部的算法邏輯進行詳細的内部設計。元件功能的詳細設計需要與軟體需求建立有效的對應關系。
如果是算法邏輯編碼，建議使用Matlab進行模型開發，如果是接近底層的複雜驅動，一般是使用手寫代碼。
如果項目使用AUTOSAR架構，使用模型開發時需要導入arxml生成模型架構進行開發，使用手寫代碼進行開發時需要使用AUTOSAR工具生成的元件代碼架構進行開發。
需要将代碼經過多次代碼審查和優化之後，将最終版本上傳至代碼庫，以實作最佳的可靠性和性能。
成功實施這個過程的結果如下：
- 開發描述軟體單元的詳細設計；
- 定義各軟體單元的接口；
- 定義軟體單元的動态行為；
- 建立軟體需求與軟體單元之間的一緻性和雙向可追溯性；建立軟體架構設計與軟體詳細設計之間的一緻性和雙向可追溯性；建立軟體詳細設計與軟體單元之間一緻性和雙向可追溯性；
- 約定軟體詳細設計及該設計與軟體架構設計的關系，并和所有受影響方溝通；
- 生成軟體詳細設計所定義的軟體單元。
2.5、軟體單元測試
元件單元測試一般需要軟體開發工程師完成，也可以讓測試工程師完成。
當進行單元測試通過後，将會将軟體編譯成ECU可執行的檔案，比如Hex格式的檔案，将其刷寫到ECU進行內建測試（或稱HIL測試），如果隻是測試底層軟體，那麼一般隻需要額外的硬體負載箱支援就行，比如用負載箱來模拟一些傳感器信号輸入，或制造一些執行器的短路和開路故障；如果測試包括應用層軟體，那麼就還需要實體模型支援才行，比如電機控制就需要電機的實體模型，變速箱控制可能就需要整個動力傳動系統的模型才行。
單元測試與軟體單元設計對應。
單元測試是根據軟體單元設計，進行代碼級别上進行的測試。
單元測試一般可以通過Matlab和Tessy等工具進行。
成功實施這個過程的結果如下：
- 制訂包括回歸政策在内的軟體單元驗證政策，以驗證軟體單元；
- 根據軟體單元驗證政策，制訂軟體單元驗證準則，以适于提供軟體單元符合軟體詳細設計及非功能性軟體需求的證據；
- 根據軟體單元驗證政策及軟體單元驗證準則，驗證軟體單元并記錄了結果；
- 建立軟體單元、驗證準則及驗證結果之間的雙向可追溯性和一緻性；
- 總結單元驗證結果，并與所有受影響方溝通。
2.6、軟體內建測試
內建測試需要測試工程師完成。
內建測試與軟體需求對應。
內建測試将各個組成部分整合入一個軟體系統中之後，最後進行軟體的內建測試。根據定義的需求，測試相應的功能是否滿足軟體需求。
成功實施本過程的結果如下：
- 制訂與項目計劃、釋出計劃和軟體架構設計相一緻的軟體內建政策，以內建軟體項；
- 制訂包括軟體回歸測試政策在内的軟體內建測試政策，以測試軟體單元之間和軟體項之間的互動；
- 根據軟體內建測試政策，開發了軟體內建測試規範，以适于提供內建的軟體項符合軟體架構設計（包括軟體單元之間和軟體項之間的接口）的證據；
- 根據內建政策內建了軟體單元和軟體項直至完整的內建軟體；
- 根據軟體內建測試政策和釋出計劃，選擇了軟體內建測試規範中的測試用例；
- 使用標明的測試用例測試了內建的軟體項，并記錄了測試結果；
- 建立軟體架構設計要素與軟體內建測試規範中的測試用例之間的一緻性和雙向可追溯性，并建立了測試用例與測試結果之間的一緻性和雙向可追溯性；
- 總結軟體內建測試結果，并與所有受影響方溝通。
2.7、軟體系統測試
系統測試需要測試工程師完成。
系統測試與系統需求對應。
因為軟體給各個ECU提供了相應的功能，是以在內建測試中，需要将軟體燒錄至硬體中。然後ECU要與其他電子系統元件內建起來，比如傳感器和執行器。在接下來的系統綜合測試中，對所有系統裝置的互動響應進行評估。
成功實施本過程的結果如下：
- 制訂與項目計劃和釋出計劃相一緻的包括回歸測試政策在内的軟體合格性測試政策，以測試內建軟體；
- 根據軟體合格性測試政策，開發內建軟體的軟體合格性測試規範，以适于提供符合軟體需求的證據；
- 根據軟體合格性測試政策和釋出計劃，選擇了軟體合格性測試規範中的測試用例；
- 使用標明的測試用例測試了內建軟體，并記錄軟體合格性測試結果；
- 建立軟體需求與軟體合格性測試規範中的測試用例之間的一緻性和雙向可追溯性，建立測試用例與測試結果之間的一緻性和雙向的可追溯性；
- 總結軟體合格性測試結果，并與所有受影響方溝通。
3、V模型的追溯性和一緻性要求
汽車軟體開發的過程中有嚴格的追溯性和一緻性要求，每個階段的過程要求、使用的工具方法和人員要求，前一階段的輸出傳遞物作為下一階段輸入，在每個階段完成後對傳遞物進行驗證，在軟體內建後在最後階段進行确認與軟體需求的一緻性。概覽如下圖所示：
4、V模型面臨的挑戰
特斯拉人工智能總監Andrej Karparthy在他的一篇技術部落格中提出建構軟體2.0技術棧的觀點，代碼正在從軟體 1.0（由人類編寫的代碼）過渡到軟體 2.0（由優化編寫的代碼，以神經網絡訓練的形式編寫）。
軟體1.0 是我們熟悉的V模型，它是用 Python、C++、C等語言書寫的。 它包括程式員對計算機的明确說明，通過編寫每行代碼，程式員會用一些可取的行為識别程式空間中的特定點。
軟體1.0的工程方法遵循以下4個步驟：
- 确定要解決的問題，即需求；
- 把需求進行分解；
- 為每個分解的需求設計軟體；
- 逐級測試，內建并部署軟體。
軟體2.0時代正在逐漸到來，目前AI算法大量應用于自然語言識别、行為分析、決策協助、身份識别等不涉及公衆安全的領域，也在自動駕駛、醫療診斷等安全領域也在逐漸應用。對于安全關鍵系統，系統工程方法學是否還适合軟體2.0時代，功能安全标準如IEC61508、ISO26262、EN50128不同行業安全軟體開發所遵循的标準，是否還能指導軟體2.0的開發實踐，下面從開發過程、軟體需求、開發工具三個方面談談想法。
4.1、軟體2.0開發過程
軟體1.0的開發生命周期模型按照系統工程V模型的方式開發，從上到下是瀑布式的，規定每個階段的過程要求、使用的工具方法和人員要求，前一階段的輸出傳遞物作為下一階段輸入，在每個階段完成後對傳遞物進行驗證，在軟體內建後在最後階段進行确認與軟體需求的一緻性。在實際應用中，設計實作階段和測試階段，會規劃小版本之間的疊代，從整體過程來看還是V模型。
在軟體2.0中，軟體的行為需求很大程度上取決于所使用的資料集（datasets），資料集不同于傳統意義上的資料，以往的資料如傳感器資料、系統的參數（如配置參數、校準資料等）或系統使用的資料庫（如導航資料庫、障礙物資料庫等），這些資料可以一定程度上确定系統的行為，但它們并不描述這種行為的邏輯。而機器學習使用的資料集不僅用來提取資訊，而且用來建立模型，用來處理其他資料并确定一個系統的行為，确定安全關鍵系統的需求，等同于軟體需求。當軟體需求階段無法獲得完整的訓練資料集，從V模型來說，後面的架構、設計實作階段也無法開始。
軟體2.0的開發模型始于資料，可以劃分為資料管理、模型訓練、模型驗證、模型部署，這四個階段不斷往複疊代，不是一次性完成的。
- 資料管理：先建立所需資料集的要求，通過對資料的分析确定資料收集、增強和預處理的需求，收集什麼資料，如何收集資料，如何解決樣本數不足，收內建本過高的問題，如何對收集的資料清洗預處理。
- 模型訓練：選擇所使用的模型，建構損失函數作為訓練誤差的衡量标準，訓練的目的是産生一個最小化該誤差的模型。需要制定一個合适的資料拆分政策，用于訓練模型、驗證模型、測試模型的比例。
- 模型驗證：針對資料管理階段産生的獨立于訓練資料集的驗證資料集，通過測試評估訓練模型的性能。
- 模型部署：使用驗證過的模型的系統将被內建，将經過驗證的ML模型與使用傳統軟體工程方法開發和驗證的系統元件進行整合，對其運作進行監控，并通過線上維護或線上學習進行更新。
4.2、軟體2.0新的軟體需求：資料集
既然軟體2.0的系統行為主要由資料集決定，系統是否符合其預期功能，很大程度上取決于資料集的品質。要證明資料集對于軟體的預期功能在系統的操作環境下是足夠的，對于認證來說是非常大的挑戰。與軟體1.0的需求對比，有以下不同：
- 确定軟體需求不是在需求階段，而是在軟體開發階段，對軟體設計實作的輸入将不是軟體的功能需求，而是訓練過程的輸出。如一個神經網絡架構、權重和偏差。
- 需求和設計實作不具備可追溯性，神經網絡結構和權重不能追溯到開發它們的軟體需求，追溯不到描述預期屬性的需求檔案，也追溯不到訓練資料集。
- 安全軟體的驗證方法不再适合資料集及訓練模型，人類已無法了解，無法實作人工審查和分析，傳統軟體基于需求的測試方法也無法進行。例如，功能安全軟體的測試用例采用的等價類生成分析，由于正常規模的神經網絡的高度複雜和非線性特征，不适用于模型的實施。要确定神經網絡模型算法的等價類是不可能的。
ISO26262 軟體單元測試用例生成推薦方法
- 資料集的屬性與軟體需求保證屬性存在差異，傳統軟體需求的完整性，清晰性，精确性，無歧義性，可驗證性，可測試性，可維護性，可擴充性 這些屬性的含義需要重新定義。
- 網絡權重作為參數資料項，在本質上與傳統的資料配置檔案不同，依據已有配置參數修改流程而套用網絡權重，存在很大偏差。
4.3、軟體2.0開發工具鍊
傳統軟體開發中已建立完善的工具鍊用于支援開發，內建開發環境，編輯器，編譯器，調試器，git內建，單元測試，內建測試工具，在功能安全軟體工具的鑒定中，根據工具對軟體安全性影響的不同，劃分為不同的級别，例如ISO26262-8對軟體工具的TCL1、TCL2和TCL3分級。在軟體2.0中，也可以按照類似的分類對工具進行分級，但目前還沒有完善的開發工具鍊和如何對工具鑒定的标準。
從軟體領域的發展來看，軟體2.0所占的規模越來越大，已出現機器自動生成的代碼，當這類軟體應用于安全關鍵系統時，有可能徹底改變既有軟體的開發模式，需要識别與現有标準的差異，安全關鍵領域如航空航天、鐵路、汽車标準，采用協作的方式在不同領域之間擷取經驗；對應用軟體2.0産品的鑒定也不再是一次性的，與軟體2.0生命周期類似，是一個疊代的過程，評估系統運作性能表現是重要環節；軟體的變更會更加頻繁，如智能網聯汽車的OTA功能，對軟體變更的評估，應考慮其服務期限、運作設計域差異、産品異常行為記錄報告等所有既有資料記錄。
參考資料：
1、汽車軟體開發V流程