呂穎 厲健峰 楊斯琦 董小瑜

（1.中國第一汽車股份有限公司智能網(wǎng)聯(lián)開發(fā)院，長(zhǎng)春130013；2.汽車振動(dòng)噪聲與安全控制綜合技術(shù)國家重點(diǎn)實(shí)驗(yàn)室，長(zhǎng)春130013）

主題詞：ASPICE 敏捷開發(fā) 預(yù)期功能安全 軟件開發(fā)流程 自動(dòng)駕駛

縮略語

SOTIF Safety Of The Intended Functionality

ASPICE Automotive Software Process Improvement and Capacity Determination

CMMI Capability Maturity Model Integration

ASD Adaptive Software Development

FTA Fault Tree Analysis

HiL Hardware in the Loop

1 引言

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

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

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

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

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

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

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

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

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

第1階段（Step-01），軟件需求分析：

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

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

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

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

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

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

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

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

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

第6階段（Step-06），軟件敏捷集成：

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

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

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

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

主要工作內(nèi)容：根據(jù)軟件需求進(jìn)行軟件合格性測(cè)試，并進(jìn)行軟件合格性測(cè)試評(píng)審。

體現(xiàn)SOTIF分析與開發(fā)過程，具體開發(fā)活動(dòng)如圖2所示。

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

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

3.1 雙向追溯性

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

（1）縱向/橫向雙向追溯性

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

（2）需求變更定位

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

（3）評(píng)估評(píng)審

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

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

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

（1）以人為核心

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

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

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

（3）測(cè)試驅(qū)動(dòng)開發(fā)

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

（4）持續(xù)集成

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

3.3 軟件層SOTIF開發(fā)

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

（1）識(shí)別和評(píng)估SOTIF潛在功能不足和觸發(fā)條件

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

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

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

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

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

（4）驗(yàn)證已知危害場(chǎng)景

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

（5）驗(yàn)證未知危害場(chǎng)景

為評(píng)估未知危害場(chǎng)景下的潛在風(fēng)險(xiǎn)，應(yīng)設(shè)計(jì)測(cè)試用例進(jìn)行風(fēng)險(xiǎn)測(cè)試，識(shí)別系統(tǒng)設(shè)計(jì)可能觸發(fā)危險(xiǎn)的運(yùn)行情況，減少未知危險(xiǎn)區(qū)域，以驗(yàn)證目標(biāo)是否滿足安全接受準(zhǔn)則為評(píng)判依據(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)方案選型不合理，缺乏有效評(píng)審評(píng)估，導(dǎo)致系統(tǒng)方案選型與主流方案存在偏差，導(dǎo)致開發(fā)后期無法閉環(huán)控制，產(chǎn)生空間車位泊車精度不足等系列問題，項(xiàng)目后期難以解決。特別是由于軟件開發(fā)系統(tǒng)功能需求規(guī)范不完善，在軟件開發(fā)過程中反復(fù)修改需求，導(dǎo)致軟件開發(fā)效率不高的問題。通過該流程的制定與實(shí)施，健全整個(gè)軟件項(xiàng)目開發(fā)測(cè)試團(tuán)隊(duì)的軟件開發(fā)流程體系，開展軟件開發(fā)過程管控，完善軟件質(zhì)量管理和微流程規(guī)范化工作，制定軟件開發(fā)規(guī)范和要求文檔模板40個(gè)，嚴(yán)控評(píng)審把關(guān)，有效保證軟件開發(fā)各個(gè)環(huán)節(jié)的規(guī)范化與標(biāo)準(zhǔn)化，質(zhì)量問題明顯減少，效率明顯提升。

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

（1）潛在的交通狀況：

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

（2）潛在危害：

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

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

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

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

不必要的緊急制動(dòng)引發(fā)的后側(cè)碰撞需要降低嚴(yán)重度，此SOTIF相關(guān)風(fēng)險(xiǎn)不可接受。為降低后碰的嚴(yán)重度，功能改進(jìn)方向?yàn)閷?duì)限制制動(dòng)介入的時(shí)長(zhǎng)或強(qiáng)度。

（4）改善后的功能描述：

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

5 結(jié)束語

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