在汽車軟件開發中，軟件開發流程是軟件工程的核心，因為它們為軟件開發實踐“提供了一個骨架并確保了它的嚴謹性”。軟件開發的流程包含“階段”“活動”和“任務”三個要素，它們規定了參與者需要完成的工作。不同的參與者在軟件開發過程中扮演著不同的角色，例如軟件設計者、軟件架構師、項目經理或質量經理等。

軟件開發流程是分階段的，每個階段關注了軟件開發的特定部分內容。總體上看，一般的軟件開發工作分為如下階段：

(1)需求工程(requirements engineering)：該階段用于創建有關軟件功能的設想并將設想分解為多個需求(關于“應該實現什么”的碎片化信息)。

(2)軟件分析(software analysis)：該階段用于執行系統分析，做出關于將功能分配到系統中不同部分的高層級邏輯決策。

(3)軟件架構設計(software architecting)：該階段軟件架構師將描述軟件及其組件的高層設計，并將這些組件分配至相應的計算節點(ECU)。

(4)軟件設計(software design)：該階段用于軟件各組件的詳細設計。

(5)實施(implementation)：在該階段用相關的編程語言實施組件的設計。

(6)測試(testing)：該階段，軟件以多種方式被測試，例如單元測試或組件測試等。

基于V模式的開發流程

現代軟件開發范式認為，設計、實施和測試的迭代進行是最好的實踐，因此上述階段通常是并行完成的，具體到汽車行業，則普遍采用V模式開發。該流程的特點是無論進行開發、編程或測試，總是在同一環境下工作，開發過程的每一步都可以得到驗證。使用這一方法最直接的效果就是加速和簡化了開發流程，這樣，技術人員可以快速地把自己的思想變成現實并可以盡早消除錯誤。

V模式的開發流程如圖1所示，包括：功能設計及控制方案設計——快速控制原型——代碼自動生成——硬件在環仿真——系統集成測試/標定，構成了從功能設計、軟件編程、可靠性測試到標定的汽車電控系統開發一體化解決方案。其中的每一個開發步驟都在計算機輔助控制系統設計工具的支持下，大大加快了開發的速度，并且整個過程建立在一個完整的開發環境中，實現了各個步驟間快速、平滑的過渡。

圖1 V模式的開發流程

V模式開發流程的具體步驟包括：

(1) 需求定義與功能設計。根據系統的功能要求在MATLAB/Simulink等環境下進行圖形化建模，建立控制器模型和被控對象模型，并進行離線仿真和分析。這一過程也稱為模型在回路(model in the loop，MIL)。

(2) 快速控制原型(rapid control prototype，RCP)。建立實時仿真模型，并下載到原型系統中，接入實際被控對象進行測試，以驗證控制系統軟硬件方案的可行性。

(3) 目標代碼生成。采用產品代碼生成軟件對模型進行轉換，自動生成產品代碼。這個過程可以針對特定ECU進行代碼優化。

(4) 硬件在環(hardware in the loop，HIL)。采用真實控制器，被控對象或者系統運行環境部分采用實際物體、部分采用仿真模型來模擬，進行整個系統的仿真測試。

(5) 測試與標定。用于在系統集成中對ECU進行標定和測試，在便利的情況下對ECU進行必要的參數調整。

V模式的開發方式相對于傳統ECU的開發過程有許多優點，它是一種基于模型的開發過程，所有控制策略與發動機仿真模型都是利用框圖化的基本模塊建立起來的。

首先由系統工程師進行功能的開發和建模，并進行系統設計，生產快速原型;接著需要軟件工程師進行軟件開發，將建好的模型轉換成機器代碼，并將其寫入ECU;隨后由軟件工程師和硬件工程師依次進行軟件測試、系統測試、標定及功能測試;最后需要匹配工程師在真實的汽車上對ECU測試，并將出現的問題反饋給開發部門重新修改，反復進行。

在整個ECU開發過程中，開發工具起到重要的作用。目前廣泛采用自動代碼生成技術可把框圖模型直接生成可執行的代碼，在專門設計的硬件平臺上對控制功能及發動機進行仿真。同時模型化的控制算法也可直接生成目標ECU代碼。V模式的開發方式大大縮短了ECU的開發周期，節約了開發成本，并能保證代碼的高質量和控制系統的可靠性，同時為未來新的控制功能設計提供了圖形化的接口平臺。

基于ASPICE的開發流程

ASPICE，全稱“Automotive Software Process Improvement and Capacity Determination” ，汽車軟件過程改進及能力評定，在當前的汽車行業中有著十分廣泛的應用，主要就是對軟件開發團隊所具備的研發能力水平進行評價的一種模型框架。這一評價模型及框架最早出現在2005年，是由歐洲的二十多家主要的汽車制造商共同制定并且發布的，其主要目的就是在汽車零部件廠進行軟件開發流程的過程中給予其適當指導，從而使汽車軟件研發質量可以得到有效改善，使汽車軟件開發可以得到滿意效果，并且這一模型框架在實際實踐中的應用也越來越廣泛。

圖2 ASPICE框架

在Aspice體系中依據企業在管理上的細致程度及嚴謹程度上所存在的差異，對于企業軟件研發能力可以以六個不同級別實行劃分，分別為從零級到五級，級別越高也就表示在項目研發過程中有意外情況發生的可能性也就越低，對于相應的項目及產品，企業也就有著更強的掌控能力，也就更有能力生產高質量產品交付于客戶。零級所表示的就是企業在項目研發方面處于比較混亂的一種狀態;一級表示企業可以將有關的產品研發工作完成，然而缺乏合理的管理，成功率比較小，在項目研發過程中有很多的不確定性因素存在，對于項目研發缺乏應有的掌控能力，無法確保可以按時進行高質量產品交付;二級表示企業不但能夠將相關產品研發工作完成，還能夠提前制定科學嚴謹的完善工作計劃，且可以依據工作計劃實施項目監控及管理工作，使各個方面的項目都得以有序開展及落實;三級表示企業不但可以有效落實相關的項目管理，且能夠在過往項目中積累有關經驗教訓，使公司內部的知識資產及標準工作流程形成，為今后項目落實提供指導與參考，并且有利于企業管理的進一步改善;四級所表示的就是在項目研發過程中融合統計學知識及技術，對于項目中的各種數據實行統計分析，并且將其應用到今后的項目管理中，對于項目結果實行預測，且可以依據預測結果實時調整項目，以保證項目目標的更好完成;五級所表示的就是企業可以依據商業目標需求，對于項目研發過程主動進行調整，在改革管理方面具有較強管理能力，可以根據對于過程中的量化分析，確定明確改進目標，且對于改進結果可以實行有效地量化監控及分析。

圖3 ASPICE開發流程

依據上文中對Aspice體系的分析，可以以Aspice體系為基礎進行汽車軟件開發流程的設計，使汽車軟件的開發得以更合理進行，從而使汽車軟件開發可以獲得比較滿意的成果，其具體流程如下：

1)汽車軟件開發需求的獲取及分析

在進行軟件開發設計之前，需要軟件開發企業及開發設計人員由客戶處得到客戶需求，并且要確定這些需求能夠被正確理解，對于這些經過定義的客戶需求，將其轉變成為系統需求，主要作用就是對系統設計進行指導。

2)系統架構設計

構建合理的系統架構，確定將哪些需求向哪些系統要素進行分配，且依據定義標準對所設計的相關系統架構進行評估。

3)軟件需求分析

對于系統需求中的有關部分，將其轉變成為軟件需求。

4)軟件架構設計

在這一環節需要注意以下幾點內容：對于軟件體系結構進行定義，對軟件元素進行確定;將軟件需求向軟件元素進行分配;對每個軟件元素接口進行定義;對于軟件元素中的動態行為以及資源消耗目標實行定義;在軟件需求及軟件架構設計間構建一致性以及雙向可追溯性;對于軟件架構設計所有相關方均達成一致并且進行溝通。

功能安全開發流程

隨著世界范圍內汽車電氣化不斷深入，車輛的集成度和復雜性越來越高，為了保證復雜系統下汽車的安全性，國際標準化組織 ISO 針對汽車功能安全發布了 《道路車輛功能安全標準———ISO26262》標準，旨在提高汽車的安全性。

ISO26262 標準體系由 9 個子標準組成，第 1 部分為專用詞定義，其余 8 個部分分別為: 功能安全管理、概念階段、系統開發、硬件開發、軟件開發、生產和運行、相關支持、ASIL導向和安全導向分析。其中的第 4、5、6 部分，兼容汽車電子常用 “V”模型開發流程，見圖4。

圖4 ISO26262 標準體系

安全生命周期是 ISO26262 定義的一個重要概念，完整的一個周期需包括 3 個階段: 概念階段、開發階段和量產階段，見圖 5。ISO26262 覆蓋了從對象構思、設計、開發、生產直到使用壽命結束的整個生命周期，每個階段都分別有相應的子標準來管理。在產品開發流程之外，并行地進行以功能安全作為開發對象覆蓋整個生命周期的功能安全流程，這是 ISO26262 一個重要的和核心的概念。

圖5 安全生命周期概念

功能完整性等級 ASIL：在 ISO26262 中所有影響系統功能安全的風險都應該被辨別和確認，對于所有可能影響功能安全的風險，需要執行風險辨別和持續安全改進，風險評估的主要手段是確定 “功能安全完整等級”，可以通過 3 個指標: “嚴重性”，“發生概率”，以 及 “可控性”，來進行量化評估，作為后續階段流程的輸入。嚴重性: S0 ～ S3，代表對駕駛員及乘客可能造成傷害的級別; S0 代表沒有傷害，S3 則代表致命傷害。發生率: E0 ～ E4，代表這個風險在實際應用環境中發生的概率; E0 代表不可能發生，E4 代表常見的。可控性: C0 ～ C3，代表這個風險發生后人員依舊采取措施控制并避免傷害的能力; C0 是總是可控， C3 代表很難或無法控制。在上面 3 個參數確定了以后，可以參考 ISO26262 的 ASIL分級矩陣來確定每個風險的 ASIL 等級。其中，QM 代表不需要特別的功能安全流程，只需要正常的質量管理就可以。

部分危害事件的ASIL的評級以及為其分配的安全目標如表1所述

ASIL 級別 A、B、C、D，越高代表著風險越大，該風險越不可容忍。在開發中一些常用的降低風險的手段有: 質保體系(文檔化，流程，認證) 、校驗方法 (方法設計，測試) 、安全驗證分析 (失效分析，故障樹分析，失效率) 以及可靠性分析(工具，零件，人員) 。

ISO 26262-3 到 26262-10 給出了一個功能安全的流程，如圖6 所示，從概念階段到產品開發，再到 SOP 后階段。如果對于研發公司來說，SOP后階段可以不考慮。

圖6 功能安全流程

1)項目定義

項目定義的主要作用是定義和描述該系統，主要包括對該系統的初始架構、操作模式以及該系統的主要功能的描述。

在進行功能安全項目定義之前，研發人員可以參考一些以下文檔，以對系統有一個初步的、充分的了解。主要包括：

1)新能源汽車市場的研究報告;

2)相關產品的設計報告;

3)電池和電池管理系統的技術報告;

4)BMS相關的法律、法規和標準，例如QC/T 897-2011等文檔。

除此之外還需明確，此BMS是為總質量不超過3.5t的電動汽車設計的;且該車輛應該行駛在常規的場景，包括高速公路，城市道路，鄉村道路等。通常情況下極端環境下如溫度低于-40的情況下，該車輛是不適宜的。需要供應商提供電池的信息參數，例如電池額定容量，充放電截止電壓，標準充放電工作電流等。此外，還需要與電池供應商確定好電池的安全的工作電壓、溫度以及電流工作區間，以便后期開發過程設定電池的故障閾值。

2)安全周期初始化

安全生命初始化的作用主要是為了區分該項目的初始狀態，是一個新的開發項目還是對現有項目的修改。如果說是一個新的開發項目，那么概念階段的開發將繼續從后面的危害分析和風險評估進行;如果說是一個對現有項目的修改，應該進行系統修改的影響分析，以識別和描述適用于該系統或其環境的預期修改，并評估這些修改的影響。對系統或環境的修改主要可以考慮：a) 操作情況和操作模式;b) 與環境的接口;c) 系統的安裝特性，如車輛內的位置、車輛配置;d) 周圍環境，包括溫度，海拔，濕度，振動和電磁干擾等的變化。通過以上幾個角度的分析，形成對現有系統的修改分析報告，再進行相關的功能安全活動。

3)危害分析和風險評估

危害分析和風險評估(Hazard analysis and risk assessment， HARA)的作用是通過系統性分析，對危害事件進行評估，從而規避不合理的風險。HARA的主要流程如圖7所示。HARA過程中首先需要做的是基于系統定義中得到的BMS的主要功能得出失效功能(Malfunction， MF)。此過程可以借助頭腦風暴的形式確定該系統的失效功能，缺點是可能存在遺漏的情況。目前較為常見的方式借鑒HAZOP分析中的“關鍵字”法進行失效功能的確定。通過“主功能+關鍵字”的形式，可以有效地得到該系統的失效功能并進行后續的HARA分析。常見的關鍵字包括“Loss”，“More”，“Less”，“Reverse”，“Unintended”，“Stuck”等。

圖7 危害分析和風險評估流程

4)功能安全概念

如果說概念階段的項目定義、安全目標等安全活動與傳統的開發流程相差甚遠，研發人員對其較為陌生的話，那么功能安全需求則顯得相對友好。在功能安全活動中，功能安全需求(Functional Safety Requirement, FSR)是從安全目標推導出來的，實際上，我們可以將其等價于“用戶安全需求”，根據定義好的需求，我們便可以進行后續的系統，軟件與硬件階段的設計。

按照“檢測信號-確認故障-進入安全狀態”的方式進行推導。

ISO 26262中規定，每一個安全目標下至少有一個FSR，且FSR是可以共用于多個安全目標的。作為功能安全中一個重要的屬性，FSR的ASIL等級是繼承自該需求所屬的安全目標的，如果該FSR屬于多個安全目標，那么FSR的ASIL等級取多個安全目標的ASIL等級的最高值。如果說某一FSR可以分解為兩個獨立的需求，那么相應的ASIL等級也會進行分解，從而可以降低后續活動中該條需求的開發與驗證難度。

借助V 字型開發流程，可以將功能安全過程與ASPICE 結合起來，如圖8 所示，這對產品開發有很大的幫助。

圖8 功能安全與 ASPICE

審核編輯：湯梓紅