面向汽車自動駕駛安全軟件的開發流程*

呂穎 厲健峰 楊斯琦 董小瑜

（1.中國第一汽車股份有限公司智能網聯開發院，長春130013；2.汽車振動噪聲與安全控制綜合技術國家重點實驗室，長春130013）

主題詞：ASPICE 敏捷開發 預期功能安全 軟件開發流程 自動駕駛

縮略語

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 引言

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

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

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

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

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

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

2 汽車安全軟件開發流程定義

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

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

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

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

第2階段（Step-02），軟件架構設計：

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

第3階段（Step-03），軟件敏捷設計：

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

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

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

第5階段（Step-05），軟件單元驗證：

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

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

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

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

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

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

主要工作內容：根據軟件需求進行軟件合格性測試，并進行軟件合格性測試評審。

體現SOTIF分析與開發過程，具體開發活動如圖2所示。

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

3 汽車安全軟件開發流程特點

3.1 雙向追溯性

本軟件開發過程體系具有ASPICE雙向追溯[17]的特點：

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

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

（2）需求變更定位

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

（3）評估評審

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

3.2 敏捷開發與集成

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

（1）以人為核心

敏捷開發注重人員與溝通，只有軟件開發人員與業務人員達到事件的敏捷處理，整個軟件開發過程才能實現敏捷化。

（2）迭代—增量開發

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

（3）測試驅動開發

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

（4）持續集成

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

3.3 軟件層SOTIF開發

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

（1）識別和評估SOTIF潛在功能不足和觸發條件

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

（2）功能修改以減少SOTIF相關風險

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

（3）定義驗證和確認策略

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

（4）驗證已知危害場景

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

（5）驗證未知危害場景

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

4 應用實踐

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

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

（1）潛在的交通狀況：

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

（2）潛在危害：

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

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

（3）觸發事件：

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

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

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

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

5 結束語

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