做開(kāi)發(fā)也是如此，除了需要高效的編碼能力，同樣也離不開(kāi)編程思維的指導。作為剛剛進(jìn)入汽車(chē)電子行業(yè)的開(kāi)發(fā)小白，本篇博文將總結最近學(xué)習到的汽車(chē)軟件行業(yè)開(kāi)發(fā)思維：V模型。
1、V模型概述
汽車(chē)軟件開(kāi)發(fā)過(guò)程中的V模型對行業(yè)內開(kāi)發(fā)者早已是司空見(jiàn)慣的模型，是由瀑布模型演變而來(lái)的，也是目前汽車(chē)行業(yè)運用最廣的軟件開(kāi)發(fā)模型。由于該模型的構圖形似字母V，所以俗稱(chēng)V模型。V模型核心思想是通過(guò)A-SPICE流程（汽車(chē)產(chǎn)業(yè)的軟件流程改進(jìn)和能力測定標準）來(lái)支持和管理整個(gè)開(kāi)發(fā)流程，從需求到源代碼的每個(gè)過(guò)程都有相應的測試。
V模型大體可劃分為幾個(gè)不同的階段步驟即：功能需求、功能開(kāi)發(fā)、軟件開(kāi)發(fā)、軟件集成測試、功能集成測試、整車(chē)集成測試（系統合格性測試），如下圖所示，左邊為需求分析和設計開(kāi)發(fā)的過(guò)程，右邊則為針對左邊的測試驗證，左邊的每個(gè)過(guò)程是與右邊的過(guò)程正好相對應。
2、V模型實(shí)施
2.1、系統需求分析
系統需求需要系統工程師完成。
基于項目的整體需求，以及軟硬件整體定義，對系統邏輯架構進(jìn)行整體定義，這部分工作包括：硬件功能定義，控制器與其他控制器通信定義，軟件簡(jiǎn)要功能定義。這個(gè)過(guò)程并不會(huì )對具體的技術(shù)實(shí)現做出定義。
2.2、軟件需求分析
軟件需求需要系統工程師完成。
系統工程師根據系統相關(guān)方需求說(shuō)明書(shū)、軟硬件接口文件、變更通知書(shū)等輸入，梳理定義軟件研發(fā)需求說(shuō)明書(shū)，包括操作系統需求、電源管理策略、傳感器讀取，執行器控制、信號特性需求、存儲服務(wù)、通信服務(wù)，網(wǎng)絡(luò )管理、故障診斷、標定、程序升級等功能需求和非功能需求。
根據項目規劃，制定軟件開(kāi)發(fā)計劃。
軟件需求分析建立需求追蹤矩陣，將軟件需求映射到系統需求，確保軟件要實(shí)現的系統需求全部覆蓋。
成功實(shí)施這個(gè)過(guò)程的結果如下：
- 定義系統中分配給軟件要素的軟件需求及其接口；
- 將軟件需求進(jìn)行分類(lèi)，并分析了其正確性和可驗證性；
- 分析軟件需求對運行環(huán)境的影響；
- 定義軟件需求實(shí)現的優(yōu)先級；
- 根據需要更新了軟件需求；
- 在系統需求與軟件需求之間、在系統架構設計與軟件需求之間建立了一致性和雙向可追溯性；
- 從成本、進(jìn)度和技術(shù)影響來(lái)評估軟件需求；
- 約定了軟件需求，并與所有受影響方溝通。
2.3、軟件架構設計
軟件架構需要架構工程師完成。
為了建立清晰的、結構化的軟件設計，應該統一分配軟件需求，然后完成軟件架構設計。根據系統相關(guān)需求、軟硬件接口表、軟件需求確定軟件架構。將每條軟件需求合理分配到軟件模塊中，定義每個(gè)軟件模塊的輸入輸出接口、動(dòng)態(tài)行為、資源消耗目標等，評估多種軟件架構的優(yōu)缺點(diǎn)等。
架構工程師需要使用EA等架構軟件畫(huà)出整個(gè)控制器軟件所有模塊的輸入輸出接口、以及內部動(dòng)態(tài)行為。
如果項目基于A(yíng)UTOSAR開(kāi)發(fā)，需要架構工程師配置應用層的所有組件，并輸出每個(gè)組件的ARXML描述文件。
一般來(lái)說(shuō)，還需要架構工程師輸出架構文檔。
成功實(shí)施這個(gè)過(guò)程的結果如下：
- 定義了識別軟件要素的軟件架構設計；
- 將軟件需求分配給軟件的要素；
- 定義每個(gè)軟件要素的接口；
- 定義軟件要素的動(dòng)態(tài)行為和資源消耗目標；
- 建立軟件需求與軟件架構設計之間的一致性和雙向可追溯性；
- 約定軟件架構設計，并與所有受影響方溝通。
2.4、軟件單元設計和軟件實(shí)現
軟件單元設計需要軟件開(kāi)發(fā)工程師完成。
在此階段，需要對每個(gè)組件內部的算法邏輯進(jìn)行詳細的內部設計。組件功能的詳細設計需要與軟件需求建立有效的對應關(guān)系。
如果是算法邏輯編碼，建議使用Matlab進(jìn)行模型開(kāi)發(fā)，如果是接近底層的復雜驅動(dòng)，一般是使用手寫(xiě)代碼。
如果項目使用AUTOSAR架構，使用模型開(kāi)發(fā)時(shí)需要導入arxml生成模型框架進(jìn)行開(kāi)發(fā)，使用手寫(xiě)代碼進(jìn)行開(kāi)發(fā)時(shí)需要使用AUTOSAR工具生成的組件代碼框架進(jìn)行開(kāi)發(fā)。
需要將代碼經(jīng)過(guò)多次代碼審查和優(yōu)化之后，將最終版本上傳至代碼庫，以實(shí)現最佳的可靠性和性能。
成功實(shí)施這個(gè)過(guò)程的結果如下：
- 開(kāi)發(fā)描述軟件單元的詳細設計；
- 定義各軟件單元的接口；
- 定義軟件單元的動(dòng)態(tài)行為；
- 建立軟件需求與軟件單元之間的一致性和雙向可追溯性；建立軟件架構設計與軟件詳細設計之間的一致性和雙向可追溯性；建立軟件詳細設計與軟件單元之間一致性和雙向可追溯性；
- 約定軟件詳細設計及該設計與軟件架構設計的關(guān)系，并和所有受影響方溝通；
- 生成軟件詳細設計所定義的軟件單元。
2.5、軟件單元測試
組件單元測試一般需要軟件開(kāi)發(fā)工程師完成，也可以讓測試工程師完成。
當進(jìn)行單元測試通過(guò)后，將會(huì )將軟件編譯成ECU可執行的文件，比如Hex格式的文件，將其刷寫(xiě)到ECU進(jìn)行集成測試（或稱(chēng)HIL測試），如果只是測試底層軟件，那么一般只需要額外的硬件負載箱支持就行，比如用負載箱來(lái)模擬一些傳感器信號輸入，或制造一些執行器的短路和開(kāi)路故障；如果測試包括應用層軟件，那么就還需要物理模型支持才行，比如電機控制就需要電機的物理模型，變速箱控制可能就 需要整個(gè)動(dòng)力傳動(dòng)系統的模型才行。
單元測試與軟件單元設計對應。
單元測試是根據軟件單元設計，進(jìn)行代碼級別上進(jìn)行的測試。
單元測試一般可以通過(guò)Matlab和Tessy等工具進(jìn)行。
成功實(shí)施這個(gè)過(guò)程的結果如下：
- 制訂包括回歸策略在內的軟件單元驗證策略，以驗證軟件單元；
- 根據軟件單元驗證策略，制訂軟件單元驗證準則，以適于提供軟件單元符合軟件詳細設計及非功能性軟件需求的證據；
- 根據軟件單元驗證策略及軟件單元驗證準則，驗證軟件單元并記錄了結果；
- 建立軟件單元、驗證準則及驗證結果之間的雙向可追溯性和一致性；
- 總結單元驗證結果，并與所有受影響方溝通。
2.6、軟件集成測試
集成測試需要測試工程師完成。
集成測試與軟件需求對應。
集成測試將各個(gè)組成部分整合入一個(gè)軟件系統中之后，最后進(jìn)行軟件的集成測試。根據定義的需求，測試相應的功能是否滿(mǎn)足軟件需求。
成功實(shí)施本過(guò)程的結果如下：
- 制訂與項目計劃、發(fā)布計劃和軟件架構設計相一致的軟件集成策略，以集成軟件項；
- 制訂包括軟件回歸測試策略在內的軟件集成測試策略，以測試軟件單元之間和軟件項之間的交互；
- 根據軟件集成測試策略，開(kāi)發(fā)了軟件集成測試規范，以適于提供集成的軟件項符合軟件架構設計（包括軟件單元之間和軟件項之間的接口）的證據；
- 根據集成策略集成了軟件單元和軟件項直至完整的集成軟件；
- 根據軟件集成測試策略和發(fā)布計劃，選擇了軟件集成測試規范中的測試用例；
- 使用選定的測試用例測試了集成的軟件項，并記錄了測試結果；
- 建立軟件架構設計要素與軟件集成測試規范中的測試用例之間的一致性和雙向可追溯性，并建立了測試用例與測試結果之間的一致性和雙向可追溯性；
- 總結軟件集成測試結果，并與所有受影響方溝通。
2.7、軟件系統測試
系統測試需要測試工程師完成。
系統測試與系統需求對應。
因為軟件給各個(gè)ECU提供了相應的功能，因此在集成測試中，需要將軟件燒錄至硬件中。然后ECU要與其他電子系統組件集成起來(lái)，比如傳感器和執行器。在接下來(lái)的系統綜合測試中，對所有系統設備的交互響應進(jìn)行評估。
成功實(shí)施本過(guò)程的結果如下：
- 制訂與項目計劃和發(fā)布計劃相一致的包括回歸測試策略在內的軟件合格性測試策略，以測試集成軟件；
- 根據軟件合格性測試策略，開(kāi)發(fā)集成軟件的軟件合格性測試規范，以適于提供符合軟件需求的證據；
- 根據軟件合格性測試策略和發(fā)布計劃，選擇了軟件合格性測試規范中的測試用例；
- 使用選定的測試用例測試了集成軟件，并記錄軟件合格性測試結果；
- 建立軟件需求與軟件合格性測試規范中的測試用例之間的一致性和雙向可追溯性，建立測試用例與測試結果之間的一致性和雙向的可追溯性；
- 總結軟件合格性測試結果，并與所有受影響方溝通。
3、V模型的追溯性和一致性要求
汽車(chē)軟件開(kāi)發(fā)的過(guò)程中有嚴格的追溯性和一致性要求，每個(gè)階段的過(guò)程要求、使用的工具方法和人員要求，前一階段的輸出交付物作為下一階段輸入，在每個(gè)階段完成后對交付物進(jìn)行驗證，在軟件集成后在最后階段進(jìn)行確認與軟件需求的一致性。概覽如下圖所示：
4、V模型面臨的挑戰
特斯拉人工智能總監Andrej Karparthy在他的一篇技術(shù)博客中提出構建軟件2.0技術(shù)棧的觀(guān)點(diǎn)，代碼正在從軟件 1.0（由人類(lèi)編寫(xiě)的代碼）過(guò)渡到軟件 2.0（由優(yōu)化編寫(xiě)的代碼，以神經(jīng)網(wǎng)絡(luò )訓練的形式編寫(xiě)）。
軟件1.0 是我們熟悉的V模型，它是用 Python、C++、C等語(yǔ)言書(shū)寫(xiě)的。它包括程序員對計算機的明確說(shuō)明，通過(guò)編寫(xiě)每行代碼，程序員會(huì )用一些可取的行為識別程序空間中的特定點(diǎn)。
軟件1.0的工程方法遵循以下4個(gè)步驟：
-
確定要解決的問(wèn)題，即需求；
-
把需求進(jìn)行分解；
-
為每個(gè)分解的需求設計軟件；
-
逐級測試，集成并部署軟件。
軟件2.0時(shí)代正在逐漸到來(lái)，目前AI算法大量應用于自然語(yǔ)言識別、行為分析、決策協(xié)助、身份識別等不涉及公眾安全的領(lǐng)域，也在自動(dòng)駕駛、醫療診斷等安全領(lǐng)域也在逐步應用。對于安全關(guān)鍵系統，系統工程方法學(xué)是否還適合軟件2.0時(shí)代，功能安全標準如IEC61508、ISO26262、EN50128不同行業(yè)安全軟件開(kāi)發(fā)所遵循的標準，是否還能指導軟件2.0的開(kāi)發(fā)實(shí)踐，下面從開(kāi)發(fā)過(guò)程、軟件需求、開(kāi)發(fā)工具三個(gè)方面談?wù)勏敕ā?/span>
軟件1.0的開(kāi)發(fā)生命周期模型按照系統工程V模型的方式開(kāi)發(fā)，從上到下是瀑布式的，規定每個(gè)階段的過(guò)程要求、使用的工具方法和人員要求，前一階段的輸出交付物作為下一階段輸入，在每個(gè)階段完成后對交付物進(jìn)行驗證，在軟件集成后在最后階段進(jìn)行確認與軟件需求的一致性。在實(shí)際應用中，設計實(shí)現階段和測試階段，會(huì )規劃小版本之間的迭代，從整體過(guò)程來(lái)看還是V模型。
軟件2.0的開(kāi)發(fā)模型始于數據，可以劃分為數據管理、模型訓練、模型驗證、模型部署，這四個(gè)階段不斷往復迭代，不是一次性完成的。
數據管理：先建立所需數據集的要求，通過(guò)對數據的分析確定數據收集、增強和預處理的需求，收集什么數據，如何收集數據，如何解決樣本數不足，收集成本過(guò)高的問(wèn)題，如何對收集的數據清洗預處理。
模型訓練：選擇所使用的模型，構建損失函數作為訓練誤差的衡量標準，訓練的目的是產(chǎn)生一個(gè)最小化該誤差的模型。需要制定一個(gè)合適的數據拆分策略，用于訓練模型、驗證模型、測試模型的比例。
模型驗證：針對數據管理階段產(chǎn)生的獨立于訓練數據集的驗證數據集，通過(guò)測試評估訓練模型的性能。
模型部署：使用驗證過(guò)的模型的系統將被集成，將經(jīng)過(guò)驗證的ML模型與使用傳統軟件工程方法開(kāi)發(fā)和驗證的系統組件進(jìn)行整合，對其運行進(jìn)行監控，并通過(guò)在線(xiàn)維護或在線(xiàn)學(xué)習進(jìn)行更新。
4.2、軟件2.0新的軟件需求：數據集
既然軟件2.0的系統行為主要由數據集決定，系統是否符合其預期功能，很大程度上取決于數據集的質(zhì)量。要證明數據集對于軟件的預期功能在系統的操作環(huán)境下是足夠的，對于認證來(lái)說(shuō)是非常大的挑戰。與軟件1.0的需求對比，有以下不同：
- 確定軟件需求不是在需求階段，而是在軟件開(kāi)發(fā)階段，對軟件設計實(shí)現的輸入將不是軟件的功能需求，而是訓練過(guò)程的輸出。如一個(gè)神經(jīng)網(wǎng)絡(luò )架構、權重和偏差。
- 需求和設計實(shí)現不具備可追溯性，神經(jīng)網(wǎng)絡(luò )結構和權重不能追溯到開(kāi)發(fā)它們的軟件需求，追溯不到描述預期屬性的需求文件，也追溯不到訓練數據集。
- 安全軟件的驗證方法不再適合數據集及訓練模型，人類(lèi)已無(wú)法理解，無(wú)法實(shí)現人工審查和分析，傳統軟件基于需求的測試方法也無(wú)法進(jìn)行。例如，功能安全軟件的測試用例采用的等價(jià)類(lèi)生成分析，由于常規規模的神經(jīng)網(wǎng)絡(luò )的高度復雜和非線(xiàn)性特征，不適用于模型的實(shí)施。要確定神經(jīng)網(wǎng)絡(luò )模型算法的等價(jià)類(lèi)是不可能的。
ISO26262 軟件單元測試用例生成推薦方法
- 數據集的屬性與軟件需求保證屬性存在差異，傳統軟件需求的完整性，清晰性，精確性，無(wú)歧義性，可驗證性，可測試性，可維護性，可擴展性 這些屬性的含義需要重新定義。
- 網(wǎng)絡(luò )權重作為參數數據項，在本質(zhì)上與傳統的數據配置文件不同，依據已有配置參數修改流程而套用網(wǎng)絡(luò )權重，存在很大偏差。
4.3、軟件2.0開(kāi)發(fā)工具鏈
傳統軟件開(kāi)發(fā)中已建立完善的工具鏈用于支持開(kāi)發(fā)，集成開(kāi)發(fā)環(huán)境，編輯器，編譯器，調試器，git集成，單元測試，集成測試工具，在功能安全軟件工具的鑒定中，根據工具對軟件安全性影響的不同，劃分為不同的級別，例如ISO26262-8對軟件工具的TCL1、TCL2和TCL3分級。在軟件2.0中，也可以按照類(lèi)似的分類(lèi)對工具進(jìn)行分級，但目前還沒(méi)有完善的開(kāi)發(fā)工具鏈和如何對工具鑒定的標準。
從軟件領(lǐng)域的發(fā)展來(lái)看，軟件2.0所占的規模越來(lái)越大，已出現機器自動(dòng)生成的代碼，當這類(lèi)軟件應用于安全關(guān)鍵系統時(shí)，有可能徹底改變既有軟件的開(kāi)發(fā)模式，需要識別與現有標準的差異，安全關(guān)鍵領(lǐng)域如航空航天、鐵路、汽車(chē)標準，采用協(xié)作的方式在不同領(lǐng)域之間獲取經(jīng)驗；對應用軟件2.0產(chǎn)品的鑒定也不再是一次性的，與軟件2.0生命周期類(lèi)似，是一個(gè)迭代的過(guò)程，評估系統運行性能表現是重要環(huán)節；軟件的變更會(huì )更加頻繁，如智能網(wǎng)聯(lián)汽車(chē)的OTA功能，對軟件變更的評估，應考慮其服務(wù)期限、運行設計域差異、產(chǎn)品異常行為記錄報告等所有既有數據記錄。
轉自汽車(chē)電子與軟件
