詳解自動駕駛安全軟件開發(fā)流程

1 引言

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

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

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

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

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

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

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

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

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

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

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

第2階段(Step-02)，軟件架構設計：

主要工作內容：識別軟件需求，形成軟件架構設計說明，并進行軟件架構設計評審。

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

主要工作內容：識別軟件敏捷設計需求，形成軟件敏捷設計說明與計劃，并進行軟件敏捷設計評審。

第4階段(Step-04)，軟件詳細設計和單元構建：

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

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

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

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

主要工作內容：完成軟件敏捷集成計劃，形成軟件敏捷集成說明，并進行軟件敏捷集成評審。

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

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

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

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

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

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

3.1 雙向追溯性

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

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

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

(2)需求變更定位

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

(3)評估評審

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

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

將敏捷開發(fā)過程融入軟件開發(fā)端與軟件測試端，軟件敏捷集成與軟件敏捷設計過程同樣具有雙向追溯性，并強調以下關鍵實踐：

(1)以人為核心

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

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

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

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

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

(4)持續(xù)集成

持續(xù)集成的主要思路是為了增加集成測試效率，將軟件開發(fā)過程后期的軟件集成分攤到軟件的全過程靈活進行。

3.3 軟件層SOTIF開發(fā)

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

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

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

(2)功能修改以減少SOTIF相關風險

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

(3)定義驗證和確認策略

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

(4)驗證已知危害場景

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

(5)驗證未知危害場景

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

4 應用實踐

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

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

(1)潛在的交通狀況：

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

(2)潛在危害：

非預期的緊急制動可能致使與后面的車相撞。駕駛員對危害不可控。后車駕駛員對危害的控制取決于兩車之間的距離。

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

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

不必要的緊急制動引發(fā)的后側碰撞需要降低嚴重度，此SOTIF相關風險不可接受。為降低后碰的嚴重度，功能改進方向為對限制制動介入的時長或強度。

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

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

5 結束語

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

審核編輯：湯梓紅