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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 ASPICE框架

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

圖3 ASPICE開發(fā)流程

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

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

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

2)系統(tǒng)架構(gòu)設(shè)計

構(gòu)建合理的系統(tǒng)架構(gòu)，確定將哪些需求向哪些系統(tǒng)要素進行分配，且依據(jù)定義標(biāo)準(zhǔn)對所設(shè)計的相關(guān)系統(tǒng)架構(gòu)進行評估。

3)軟件需求分析

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

4)軟件架構(gòu)設(shè)計

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

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

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

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

圖4 ISO26262 標(biāo)準(zhǔn)體系

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

圖5 安全生命周期概念

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

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

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

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

圖6 功能安全流程

1)項目定義

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

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

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

2)相關(guān)產(chǎn)品的設(shè)計報告;

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

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

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

2)安全周期初始化

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

3)危害分析和風(fēng)險評估

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

圖7 危害分析和風(fēng)險評估流程

4)功能安全概念

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

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

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

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

圖8 功能安全與 ASPICE

審核編輯：湯梓紅