1 引言

自動駕駛汽車開發(fā)越來越重視性能、質(zhì)量和性價比，自動駕駛口碑成為新技術(shù)應(yīng)用取得市場成功的關(guān)鍵，而口碑的建立依賴于相關(guān)軟件開發(fā)流程、周期、時間和質(zhì)量。一家汽車企業(yè)只有擁有或者其軟件開發(fā)供應(yīng)商具有成熟的軟件開發(fā)團(tuán)隊(duì)、軟件開發(fā)流程、可復(fù)用的軟件流程資源庫，才能在日益激烈的自動駕駛產(chǎn)業(yè)競爭中獲得一席之地。

目前，國際上應(yīng)用于汽車行業(yè)的軟件開發(fā)成熟度評估標(biāo)準(zhǔn)主要有能力成熟度模型集成(Capability Ma?turity Model Integration,CMMI)和汽車軟件過程改進(jìn)及能力評定模型框架(Automotive Software Process Im?provement and Capacity Determination,ASPICE)。CMMI擁有全球公認(rèn)的軟件、產(chǎn)品和系統(tǒng)開發(fā)優(yōu)良實(shí)踐過程改進(jìn)模型，能夠幫助組織提升績效，具有普適性，而ASPICE標(biāo)準(zhǔn)基于軟件過程評估國際標(biāo)準(zhǔn)ISO15504，主要針對汽車行業(yè)軟件開發(fā)過程框架，是現(xiàn)今汽車企業(yè)主要依據(jù)的過程評估標(biāo)準(zhǔn)。與典型傳統(tǒng)軟件開發(fā)過程，例如線性瀑布模型相比，以V開發(fā)模式為導(dǎo)向的ASPICE軟件過程域，從客戶需求、系統(tǒng)架構(gòu)、軟件需求、軟件架構(gòu)、軟件詳細(xì)設(shè)計、單元構(gòu)建到測試驗(yàn)證之間都存在一致性與雙向追溯性關(guān)系，從最初的系統(tǒng)需求分析開始，測試人員就參與進(jìn)行對應(yīng)驗(yàn)證標(biāo)準(zhǔn)的設(shè)計，將設(shè)計和測試在項(xiàng)目開始初期就關(guān)聯(lián)起來，在整個軟件開發(fā)生命周期都有著重要的指導(dǎo)意義。

傳統(tǒng)軟件開發(fā)重視業(yè)務(wù)過程和文檔，若軟件開發(fā)人員完全按照設(shè)計文檔進(jìn)行程序開發(fā)，經(jīng)過很長的開發(fā)周期后提交軟件程序，會導(dǎo)致早期錯誤可能要等到開發(fā)過程后期才能發(fā)現(xiàn)，風(fēng)險與修正成本不可控制。敏捷軟件開發(fā)模式強(qiáng)調(diào)溝通，通過各子項(xiàng)目的集成和運(yùn)行，構(gòu)建成上層軟件項(xiàng)目，軟件開發(fā)成員擁有充分的自主權(quán)，可自行尋找最佳工作方式完成工作，不必拘泥于設(shè)計文檔。開發(fā)過程循環(huán)迭代，開發(fā)人員針對前期需求，盡可能早地提交一個完整可獨(dú)立運(yùn)行的源程序，供測試驗(yàn)證，發(fā)現(xiàn)問題后提出需求變更請求，開發(fā)人員再次按照新需求開發(fā)并提交源程序，如此循環(huán)直至軟件從整體構(gòu)架至各個細(xì)節(jié)完全符合需求，從而實(shí)現(xiàn)完美的人機(jī)結(jié)合。

敏捷方法主包括：Scrum方法，自適應(yīng)軟件開發(fā)(Adaptive Software Development，ASD)，水晶方法，以及最重要的極限編程(eXtreme Programming，XP)。Scrum偏重于過程，XP則偏重于實(shí)踐，實(shí)際開發(fā)中，兩者經(jīng)常結(jié)合一起應(yīng)用。

由于汽車自動駕駛軟件的復(fù)雜性與專業(yè)性，一味遵循敏捷開發(fā)，專注市場變化和客戶反饋，會對整個軟件的架構(gòu)、開發(fā)、測試造成很大的波動?？刂撇缓茫瑫沟庙?xiàng)目失控，造成嚴(yán)重的質(zhì)量問題，比如Bug多，架構(gòu)不合理，易用性差，性能不佳等。除此之外，汽車軟件項(xiàng)目開發(fā)周期很長，很難保證開發(fā)的人員不更換，而沒有規(guī)范體系文檔就會造成在交接的過程中出現(xiàn)很大的困難。因此，采取有效方法保證過程質(zhì)量，對于提高產(chǎn)品質(zhì)量具有十分重要的意義。

為滿足自動駕駛車輛的安全性需求，根據(jù)ISO PAS 21448標(biāo)準(zhǔn)，智能駕駛系統(tǒng)本身傳感器/控制器/執(zhí)行器的設(shè)計不足、性能局限在遇到一定的場景觸發(fā)條件(如環(huán)境干擾或人員誤用)時，將可能導(dǎo)致整車級失效危害，進(jìn)而威脅人身安全。究其根本，應(yīng)在軟件開發(fā)階段充分降低預(yù)期功能安全SOTIF危害事件的潛在風(fēng)險、提高軟件安全性能、明確安全邊界。因此，本文在結(jié)合傳統(tǒng)與敏捷開發(fā)流程基礎(chǔ)上，融入SOTIF對部件軟件層級的安全需求與測試驗(yàn)證，合理控制軟件已知/未知風(fēng)險，開發(fā)自動駕駛軟件流程，促進(jìn)自動駕駛車輛系統(tǒng)安全提升和順利發(fā)布。

2 汽車安全軟件開發(fā)流程定義

設(shè)計智能駕駛軟件產(chǎn)品開發(fā)流程如圖1所示。主要由8個階段構(gòu)成，即包括軟件需求分析、軟件架構(gòu)設(shè)計、軟件敏捷設(shè)計、軟件詳細(xì)設(shè)計和單元構(gòu)建、軟件單元驗(yàn)證、軟件敏捷集成、軟件集成和集成測試及軟件合格性測試。增加軟件敏捷設(shè)計與集成活動，以應(yīng)對實(shí)際軟件開發(fā)項(xiàng)目中開發(fā)周期短，軟件需求預(yù)開發(fā)架構(gòu)的問題。

圖1 汽車自動駕駛安全軟件開發(fā)流程

第1階段(Step-01)，軟件需求分析：

主要工作內(nèi)容：根據(jù)項(xiàng)目目標(biāo)與計劃，承接系統(tǒng)需求，SOTIF危害分析與項(xiàng)目內(nèi)各專業(yè)確認(rèn)軟件需求，進(jìn)行需求評審。

第2階段(Step-02)，軟件架構(gòu)設(shè)計：

主要工作內(nèi)容：識別軟件需求，形成軟件架構(gòu)設(shè)計說明，并進(jìn)行軟件架構(gòu)設(shè)計評審。

第3階段(Step-03)，軟件敏捷設(shè)計：

主要工作內(nèi)容：識別軟件敏捷設(shè)計需求，形成軟件敏捷設(shè)計說明與計劃，并進(jìn)行軟件敏捷設(shè)計評審。

第4階段(Step-04)，軟件詳細(xì)設(shè)計和單元構(gòu)建：

主要工作內(nèi)容：結(jié)合敏捷設(shè)計需求，根據(jù)軟件需求和軟件架構(gòu)定義軟件詳細(xì)設(shè)計，包括任務(wù)設(shè)置、調(diào)度機(jī)制、優(yōu)先級、時序、函數(shù)接口關(guān)系、數(shù)據(jù)定義、算法策略說明，根據(jù)軟件詳細(xì)設(shè)計進(jìn)行軟件單元構(gòu)建工作，并進(jìn)行軟件詳細(xì)設(shè)計和單元構(gòu)建評審。

第5階段(Step-05)，軟件單元驗(yàn)證：

主要工作內(nèi)容：完成靜態(tài)檢查，編寫軟件單元測試需求文檔、測試用例，自動或手動進(jìn)行單元測試工作，并進(jìn)行軟件單元測試評審。

第6階段(Step-06)，軟件敏捷集成：

主要工作內(nèi)容：完成軟件敏捷集成計劃，形成軟件敏捷集成說明，并進(jìn)行軟件敏捷集成評審。

第7階段(Step-07)，軟件集成和集成測試：

主要工作內(nèi)容：按照集成計劃，完成軟件單元集成，編寫軟件集成測試需求文檔，自動或手動進(jìn)行集成測試工作，并進(jìn)行軟件集成和集成測試評審。

第8階段(Step-08)，軟件合格性測試：

主要工作內(nèi)容：根據(jù)軟件需求進(jìn)行軟件合格性測試，并進(jìn)行軟件合格性測試評審。 體現(xiàn)SOTIF分析與開發(fā)過程，具體開發(fā)活動如圖2所示。

圖2 汽車自動駕駛安全軟件開發(fā)過程

3 汽車安全軟件開發(fā)流程特點(diǎn)

3.1 雙向追溯性

本軟件開發(fā)過程體系具有ASPICE雙向追溯[的特點(diǎn)：

(1)縱向/橫向雙向追溯性

從上到下的追溯，便于確認(rèn)是否所有需求都執(zhí)行;從左到右的追溯，便于確認(rèn)是否所有需求都被測試;從下到上的追溯，便于發(fā)現(xiàn)哪些需求被錯誤的執(zhí)行或曲解;從右到左的追溯，通過測試的過程發(fā)現(xiàn)問題或者缺陷來源于哪個需求。

(2)需求變更定位 在出現(xiàn)新的需求或者需求變更時，通過快速追溯便于V模型從上到下、從左到右準(zhǔn)確的定位，發(fā)現(xiàn)從設(shè)計到測試整個工程開發(fā)中不同階段需求變更具體位置。 (3)評估評審

通過需求的縱向和橫向的追溯就可以知道該項(xiàng)目是否嚴(yán)格按照ASPICE標(biāo)準(zhǔn)流程執(zhí)行開發(fā)過程。

3.2 敏捷開發(fā)與集成

將敏捷開發(fā)過程融入軟件開發(fā)端與軟件測試端，軟件敏捷集成與軟件敏捷設(shè)計過程同樣具有雙向追溯性，并強(qiáng)調(diào)以下關(guān)鍵實(shí)踐：

(1)以人為核心

敏捷開發(fā)注重人員與溝通，只有軟件開發(fā)人員與業(yè)務(wù)人員達(dá)到事件的敏捷處理，整個軟件開發(fā)過程才能實(shí)現(xiàn)敏捷化。

(2)迭代—增量開發(fā)

整個軟件的開發(fā)過程通過迭代式開發(fā)分成若干階段，開發(fā)人員根據(jù)優(yōu)先級或風(fēng)險高低選擇需求，對程序進(jìn)行增量的設(shè)計和開發(fā)。每次迭代完成對應(yīng)一個經(jīng)過測試的最終產(chǎn)品，開發(fā)團(tuán)隊(duì)通過它獲得更多反饋，再繼續(xù)完善軟件產(chǎn)品。

(3)測試驅(qū)動開發(fā)

基本思想就是在明確要開發(fā)某個功能和在開發(fā)功能代碼之前，先編寫測試用例，思考如何進(jìn)行功能測試，然后編寫相關(guān)的代碼滿足這些測試用例，循環(huán)進(jìn)行功能添加。直到完成全部功能開發(fā)。

(4)持續(xù)集成

持續(xù)集成的主要思路是為了增加集成測試效率，將軟件開發(fā)過程后期的軟件集成分?jǐn)偟杰浖娜^程靈活進(jìn)行。

3.3 軟件層SOTIF開發(fā)

在軟件設(shè)計與測試階段，同步進(jìn)行SOTIF開發(fā)活動，對軟件開發(fā)起到安全約束的作用，對應(yīng)以下5項(xiàng)活動：

(1)識別和評估SOTIF潛在功能不足和觸發(fā)條件

通過規(guī)范與設(shè)計文檔的支撐，進(jìn)一步確認(rèn)軟件設(shè)計不足及性能限制、人員誤用等及其觸發(fā)條件。利用FTA故障樹分析得出導(dǎo)致軟件層面上SOTIF相關(guān)整車級危害觸發(fā)條件，包含感知模塊、算法決策模塊、執(zhí)行模塊及人員的合理可預(yù)見的誤用。確認(rèn)觸發(fā)條件對SOTIF的可接受性，評審評估嚴(yán)重度(S)、可控性(C)以及觸發(fā)條件的概率是否滿足制定的可接受標(biāo)準(zhǔn)。

(2)功能修改以減少SOTIF相關(guān)風(fēng)險

通過已分析得到的軟件層級的設(shè)計不足及性能限制之處，制定針對SOTIF相關(guān)危害的改善措施，包含功能目標(biāo)的更改、軟件設(shè)計限制、改進(jìn)和降級。將改善措施更新進(jìn)入規(guī)范與設(shè)計文檔。如果仍不能充分降低安全風(fēng)險，需要定義接受準(zhǔn)則并考慮相應(yīng)的法規(guī)、該功能在目標(biāo)市場的情況、人員暴露在風(fēng)險下的可接受性。

(3)定義驗(yàn)證和確認(rèn)策略

SOTIF的驗(yàn)證和確認(rèn)過程主要是對未知的不安全場景和已知的不安全場景進(jìn)行探測和轉(zhuǎn)化的過程，針對軟件系統(tǒng)提出驗(yàn)證與確認(rèn)的要求。制定針對已識別SOTIF相關(guān)危害的驗(yàn)證策略，及針對殘余風(fēng)險的確認(rèn)策略，編寫集成測試規(guī)范，并說明所選驗(yàn)證和確認(rèn)方法的基本原理。

(4)驗(yàn)證已知危害場景

針對已識別的SOTIF相關(guān)危害場景，基于所選的驗(yàn)證方法，對軟件算法進(jìn)行模擬仿真驗(yàn)證或硬件在環(huán)(HiL)驗(yàn)證，并進(jìn)行集成測試，最終出具危害場景的驗(yàn)證報告。

(5)驗(yàn)證未知危害場景

為評估未知危害場景下的潛在風(fēng)險，應(yīng)設(shè)計測試用例進(jìn)行風(fēng)險測試，識別系統(tǒng)設(shè)計可能觸發(fā)危險的運(yùn)行情況，減少未知危險區(qū)域，以驗(yàn)證目標(biāo)是否滿足安全接受準(zhǔn)則為評判依據(jù)。

4 應(yīng)用實(shí)踐

隨著我國汽車企業(yè)智能駕駛產(chǎn)品逐步的自主化，由于缺乏經(jīng)驗(yàn)，軟件團(tuán)隊(duì)在實(shí)際項(xiàng)目開發(fā)中曾暴露出多項(xiàng)問題與流程漏洞，以往車型項(xiàng)目中存在過系統(tǒng)方案選型不合理，缺乏有效評審評估，導(dǎo)致系統(tǒng)方案選型與主流方案存在偏差，導(dǎo)致開發(fā)后期無法閉環(huán)控制，產(chǎn)生空間車位泊車精度不足等系列問題，項(xiàng)目后期難以解決。特別是由于軟件開發(fā)系統(tǒng)功能需求規(guī)范不完善，在軟件開發(fā)過程中反復(fù)修改需求，導(dǎo)致軟件開發(fā)效率不高的問題。通過該流程的制定與實(shí)施，健全整個軟件項(xiàng)目開發(fā)測試團(tuán)隊(duì)的軟件開發(fā)流程體系，開展軟件開發(fā)過程管控，完善軟件質(zhì)量管理和微流程規(guī)范化工作，制定軟件開發(fā)規(guī)范和要求文檔模板40個，嚴(yán)控評審把關(guān)，有效保證軟件開發(fā)各個環(huán)節(jié)的規(guī)范化與標(biāo)準(zhǔn)化，質(zhì)量問題明顯減少，效率明顯提升。

通過該流程實(shí)施解決AEB自動剎車輔助系統(tǒng)潛在危害的過程舉例如下：

(1)潛在的交通狀況：

在交通擁堵的路上行駛(如郊區(qū)道路)。

(2)潛在危害：

非預(yù)期的緊急制動可能致使與后面的車相撞。

駕駛員對危害不可控。后車駕駛員對危害的控制取決于兩車之間的距離。

(3)觸發(fā)事件：

特殊道路條件(如：井蓋，管道，飲料罐)可能會生成雷達(dá)回波，有可能被理解為潛在障礙物。

不必要的緊急制動引發(fā)的后側(cè)碰撞需要降低嚴(yán)重度，此SOTIF相關(guān)風(fēng)險不可接受。為降低后碰的嚴(yán)重度，功能改進(jìn)方向?yàn)閷ο拗浦苿咏槿氲臅r長或強(qiáng)度。

(4)改善后的功能描述：

該功能使用雷達(dá)傳感器掃描前方障礙物的距離。若檢測到即將到來的碰撞，則AEB將會觸發(fā)。限制制動介入以減少或防止不需要的緊急制動帶來的碰撞。

5 結(jié)束語

本文結(jié)合ASPICE過程模型與敏捷開發(fā)的各自優(yōu)勢，考慮了SOTIF安全需求，減少了危害事件，提出了一種融入軟件敏捷開發(fā)環(huán)節(jié)的軟件開發(fā)流程，兼顧了傳統(tǒng)汽車軟件開發(fā)控制、流程、文檔和評審的方法，與敏捷開發(fā)的靈活主動、快速迭代的特性，以及安全約束。新制定的面向自動駕駛安全軟件開發(fā)流程是在傳統(tǒng)汽車軟件開發(fā)過程基礎(chǔ)上的一種改進(jìn)和優(yōu)化，合理平衡軟件開發(fā)活動，實(shí)際項(xiàng)目實(shí)施效果證明了新開發(fā)的軟件流程的有效性，對后續(xù)汽車自動駕駛安全軟件的開發(fā)具有指導(dǎo)意義。

審核編輯：郭婷