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

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

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

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

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

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

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

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

基于V模式的開發(fā)流程

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

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

圖1 V模式的開發(fā)流程

V模式開發(fā)流程的具體步驟包括：

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

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

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

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

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

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

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

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

基于ASPICE的開發(fā)流程

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

圖2 ASPICE框架

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

圖3 ASPICE開發(fā)流程

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

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

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

2)系統(tǒng)架構設計

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

3)軟件需求分析

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

4)軟件架構設計

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

功能安全開發(fā)流程

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

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

圖4 ISO26262 標準體系

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

圖5 安全生命周期概念

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

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

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

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

圖6 功能安全流程

1)項目定義

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

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

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

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

3)電池和電池管理系統(tǒng)的技術報告;

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

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

2)安全周期初始化

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

3)危害分析和風險評估

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

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

4)功能安全概念

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

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

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

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

圖8 功能安全與 ASPICE

審核編輯：湯梓紅