汽車軟件開發(fā)流程介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 ASPICE框架

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

圖3 ASPICE開發(fā)流程

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

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

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

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

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

3)軟件需求分析

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

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

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

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

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

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

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

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

圖5 安全生命周期概念

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

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

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

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

圖6 功能安全流程

1)項(xiàng)目定義

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

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

1)新能源汽車市場(chǎng)的研究報(bào)告;

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

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

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

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

2)安全周期初始化

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

3)危害分析和風(fēng)險(xiǎn)評(píng)估

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

圖7 危害分析和風(fēng)險(xiǎn)評(píng)估流程

4)功能安全概念

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

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

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

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

圖8 功能安全與 ASPICE

審核編輯：湯梓紅