2020年12月23日，中國汽研成功舉辦《2020第三屆新能源汽車測試評價技術國際論壇》。中國汽研將持續(xù)為大家推送精彩演講實錄，本文為貝騰軟件科技總經(jīng)理劉春曉帶來的《擁抱需求驅(qū)動，新能源汽車功能安全落地一站式最佳落地方法》。

1 背景 

隨著軟件驅(qū)動汽車時代的來臨，不斷增加的功能、系統(tǒng)、安全需求、自動駕駛等，使得軟件復雜性急劇提升，在多場景下，如何確定需求測試的完整性是亟待考慮的。傳統(tǒng)零部件和軟件開發(fā)的區(qū)別在于硬件質(zhì)量瑕疵可通過不良品率ppm量化，生產(chǎn)后的無瑕疵批次硬件依然可用，而軟件開發(fā)發(fā)行后，由于是復制式部署，會影響所有最終產(chǎn)品。功能安全的作用主要體現(xiàn)在防范和監(jiān)控方面。ISO26262于2011年正式頒布，聚焦兩大問題，一是人為失誤等導致系統(tǒng)性失效，二是電子件（硬件）隨機失效，從組織成熟度、流程質(zhì)量和產(chǎn)品質(zhì)量三個維度進行把控，旨在提高汽車電子、電氣產(chǎn)品功能安全。TS16949是針對整個組織的流程認證質(zhì)量體系，ASPICE（汽車軟件過程改進及能力評定）更多的聚焦于軟件的過程品質(zhì)，ISO26262聚焦于產(chǎn)品的安全，在相互穿插支撐整個產(chǎn)品實現(xiàn)的過程中需要一些文檔來約束開發(fā)過程，確保產(chǎn)品吻合當前設計需求。

2 需求工程

ASPICE及功能安全落地的難點在于硬套模板、執(zhí)行力虎頭蛇尾、管理層志愿不足、對流程的理解和執(zhí)行有較大偏差等，理解誤差是開發(fā)過程中不可避免的，這些問題的核心點為需求工程，需求工程的目的是構建全體項目成員對開發(fā)內(nèi)容的共通理解。需求的種類分為功能需求（描述系統(tǒng)的能力，在特定場景下系統(tǒng)的行為以及對于特定的外界激勵如何響應），非功能需求（描述系統(tǒng)與功能無關的特質(zhì)，比如代碼質(zhì)量、可用性、可擴展性、依賴性、可移植性、系統(tǒng)性能、強健性以及系統(tǒng)的開發(fā)成本、期限等），安全需求（源自于軟硬件FMEA、FTA等，規(guī)定系統(tǒng)行為不得導致人身傷害的發(fā)生或者具有嚴重后果的系統(tǒng)故障）。需求獲取方法包括頭腦風暴、問卷、頭腦風暴的悖論、變換視角、類比拆解、抽象建?？焖僭汀⒂美龍D等。

安全需求應當具備的特性包括用詞明確（明確清晰的用詞，一個詞對應于一個概念），小顆粒度（一條需求處理事情的一個方面，一條需求不可細分為多條需求），自一致性（需求之間沒有內(nèi)在邏輯矛盾），可實施性（在工程限定條件之下可以得到實施），可驗證性（定義需求時考慮到需求是否可以被驗證）。

需求的基本屬性（PUID：永久性唯一表記序列號；版本：方便變更管理時的可追溯性；描述：需求的文本表達），功能安全需求應當具有的屬性（類別：安全需求、功能需求、非功能需求；ASIL等級：QM、 A、B、C、 D ；狀態(tài)：建議、已確認、已拒絕、已評審、已實施、已驗證）。

需求的管理貫穿整個系統(tǒng)生命周期。包括有層次有組織的結構：相應于產(chǎn)品（軟件）的設計；完整性：每一層級的需求必須完整地實現(xiàn)其上層級的所有需求；一致性與非冗余性：必須貫穿所有的需求；可維護性：對需求的擴展，增補，刪除進行管理；可追溯性：需求之間，與軟件實現(xiàn)，與測試之間雙向可追溯；配置管理：版本的明確定義與使用，歷史版本可復現(xiàn)，版本的可追溯性。這些要求可以通過需求采集與管理工具輔助進行。

需求需要用文字的方式進行表達，國際需求委員會建議使用模板來表述需求會更加清晰（需求的非形式化語言模板）：

非安全需求和安全需求應該在系統(tǒng)中被隔離（非干擾），保持一定的獨立性， 保證不會因為某一塊的失效而導致安全目標被違反，同時非安全需求作為也需要遵循ISO26262相關要求。

系統(tǒng)和軟件的功能安全產(chǎn)品開發(fā)的主要活動流程：

BMS功能安全需求例子 FSR（功能安全需求）：

BMS技術安全需求分析例子 TSR（技術安全需求）：在FSR的基礎上進一步細化，通過TSR活動定義合理的安全機制來滿足FSR；基于FSR的初步架構，在TSR環(huán)節(jié)部署元素和子元素，構建包含軟硬件的技術架構；TSR需要指定元素的結構，行為，接口及交互。

BMS技術安全需求軟硬件接口定義例子（HSI）：部署完各個元素的交互后，確定軟硬件接口（HSI），為之后的系統(tǒng)集成打下良好的基礎。

3 測試工程

功能安全測試的主要活動為 Verification & Validation + 量化結果。Verification：面向設計的驗證（驗證中間產(chǎn)物，比如設計文檔，測試計劃等；開發(fā)視點，上下工序的執(zhí)行等），Validation：面向需求的驗證（驗證終端產(chǎn)品，如軟件和系統(tǒng)需求等；客戶視點，客戶需求導向）。

軟件單元測試測試方法包括基于需求的測試、接口測試、故障注入測試、等效性測試；測試用例制作包括需求分析、錯誤推測、等價類、邊界值；測試覆蓋率基準包括語句覆蓋、判定覆蓋、MC/DC覆蓋。

軟件集成和測試，集成測試包括測試計劃和執(zhí)行、測試用例生成、集成測試方法集、需求測試；集成測試方法包括基于需求的測試、接口測試、故障注入測試、等效性測試；測試用例制作包括需求分析、錯誤推測、等價類、邊界值；測試覆蓋率基準包括函數(shù)覆蓋、函數(shù)調(diào)用覆蓋。

軟件單元測試的量化評估例子：

基于需求測試，也稱為功能測試，是一種基于軟件單元規(guī)格制定測試用例的質(zhì)量保證（QA）手段。基于需求測試的目的是理解需求所定義的軟件在各種場景下的功能與因果性，通過執(zhí)行測試用例檢查軟件行為是否與軟件規(guī)格一致。

在軟件單元層級，接口測試通過測試接口變量的取值區(qū)間以及邊界值來實施。接口測試的目的是根據(jù)軟件單元的接口規(guī)格，通過測試保障軟件單元接口的強健性。通過等價類分析、邊界值分析進行接口測試。

故障注入測試通過故意導入故障來測試軟件單元中實施的安全措施的有效性。目的是用于確認故障發(fā)生時軟件單元的行為。通過將故障信號注入到被測軟件單元的輸入和定義系統(tǒng)的期待輸出進行故障注入測試。

4 總結

ASPICE流程作為QM基礎，構建企業(yè)標準流程，支持ASIL需求落地；ISO26262標準確保了面向于E/E系統(tǒng)的安全機制實現(xiàn)，在整個產(chǎn)品周期里，不僅包含了開發(fā)流程，也包含了技術的解決方案；需求工程是保證項目成功的關鍵要素，投入越多，總體成本越低，產(chǎn)品質(zhì)量越高；測試工程的自動化是項目提質(zhì)提效的關鍵手段；相對于硬件PPM的評估，衡量軟件質(zhì)量主要靠流程，文檔和數(shù)據(jù)，有效性是重要考量指標；不存在“超人”必殺技，第三方咨詢認證可提供外部智力輔助優(yōu)化項目質(zhì)量，提升產(chǎn)品力，然而企業(yè)內(nèi)在的安全文化及持續(xù)的流程優(yōu)化需求才是競爭力之核心。

返回第一電動網(wǎng)首頁 >