聊聊汽車功能安全軟件開發(fā)相關內容

01

軟件開發(fā)模型

為了更好了解軟件及其功能安全開發(fā)過程，我們首先來聊聊軟件開發(fā)模型。不管是ISO 26262，Aspice還是System Engineering，其開發(fā)過程都基于V模型，可以說V模型是汽車工程師必修內容。 ?

對于功能安全而言，軟件功能安全開發(fā)V模型屬于ISO 26262第6部分內容，是系統(tǒng)開發(fā)大的V模型中軟件開發(fā)部分，緊接著第4部分系統(tǒng)開發(fā)內容。整個軟件開發(fā)V模型始于需求開發(fā)，然后架構設計，詳細實現，最后完成集成和驗證。左側V從需求到設計，右側V從集成到測試驗證，具體如下圖所示: ?

這里順便聊一下現在討論比較多的ASPICE，后續(xù)找機會我們細聊。ASPICE 全稱“Automotive Software Process Improvement and Capacity Determination”，即汽車軟件過程改進及能力評定，于2005年由歐洲主要汽車制造商共同制定，旨在通過規(guī)范汽車零部件供應商軟件開發(fā)流程，并對其開發(fā)項目進行評估認證，從而改善汽車軟件的質量，具體開發(fā)流程如下圖所示: ?
?

可以明顯看出，ASPICE開發(fā)模型也包括系統(tǒng)和軟件開發(fā)V模型并附加相應支持和管理過程。它和ISO 26262開發(fā)模型及主要工作輸出產物基本類似，它們的底層邏輯都是通過對開發(fā)過程進行約束，認為過程基本決定結果，只要開發(fā)流程滿足需求，則在該流程下開發(fā)出來的產品或軟件的質量也能夠得到保障。 ?

目前ASPICE在歐洲應用比較多，歐洲大部分OEM都對供應商軟件開發(fā)能力有所要求，例如目前達到Level 2級別。但這幾年國內對ASPICE討論很多，很多OEM放棄了ASPICE開發(fā)，很多人認為ASPICE只是徒勞增加開發(fā)工作量，延長項目周期，并不一定改善軟件質量，尤其基于單個項目的開發(fā)能力評估并不能反映在其他項目的應用情況。 ?

我個人觀點如下: ?

1

規(guī)范及流程的存在是為統(tǒng)一標準，為讓大部分普通工程師在其約束下也能夠開發(fā)出一流產品，保證產品質量一致性。

2

條條大路通羅馬，只要企業(yè)內部開發(fā)流程完善，并不一定完全按照ISO 26262，ASPICE等規(guī)范進行開發(fā)，規(guī)范的存在也只是提供指導，幫助企業(yè)建立及完善自己的開發(fā)流程。研發(fā)流程的存在雖然短期會增加研發(fā)工作量，但長遠來看絕對利大于弊。

3

企業(yè)研發(fā)流程的制定需要結合企業(yè)規(guī)模，內部組織結構，企業(yè)文化多種因素考量，選擇適合自身發(fā)展的開發(fā)流程。

4

規(guī)范及流程必須合理有效且能夠付諸于實踐。盡可能利用相應的開發(fā)，管理工具鏈，加速流程的應用和管理。例如，ASPICE和ISO 26262要求開發(fā)需求，軟/硬件，測試用例之間的可追溯性，如果沒有強大的開發(fā)工具鏈支持，其工作量巨大，且可用性也差。

5

考慮到成本及可行性，對企業(yè)開發(fā)能力的評估也只能采取樣本認證，即對其開發(fā)流程和具體樣本項目進行評估，無法覆蓋企業(yè)所有項目，這是所有認證的共性問題。而企業(yè)是否能夠堅持標準，應用于所有開發(fā)項目，取決于企業(yè)自身的堅持，我相信我們還有很長的路要走！

02

什么是軟件安全需求？

功能安全軟件開發(fā)始于需求開發(fā)，即軟件安全需求(Software Safety Requirement, SWSR)，而SWSR源于分配至軟件組件的TSR，是軟件相關的TSR在軟件層面的進一步細化。

SWSR定義相對比較簡單，但需要注意的是，很多朋友認為只要定義軟件相關安全機制就足夠了，其實除此之外，SWSR還包含和安全機制無關的SWSR，它是保證功能安全的基礎或支持內容，SWSR一般來講:?

軟件安全需求SWSR?= 安全機制無關的軟件安全需求 + 軟件安全機制?

安全機制無關的軟件安全需求包括:?

1

使標稱功能可以安全執(zhí)行的功能等。

例如:?軟件安全運行相關基礎軟件，包括操作系統(tǒng)，時鐘，運行模式等。

2

在生產、運行、服務和報廢過程中與車載測試和非車載測試相關的功能。

例如:?車載通信、密鑰管理或閃存數據安全檢測等，或OBD II相關內容，包括故障存儲，讀取，清除等。

3

允許在生產和服務過程中對軟件進行修改的功能。

例如:?可配置性數據或標定數據，以滿足多車型軟件復用或者升級。

4

軟硬件接口規(guī)范要求。

例如:?I/O接口，通訊等信號安全需求。

5

對軟件功能和特性的要求，包括對錯誤輸入的魯棒性、不同功能之間的獨立性或免于干擾、或軟件的容錯能力。

例如:?FFI中軟件分區(qū)。 ?

軟件安全機制包括:

1

?與應用軟件本身、基礎軟件或操作系統(tǒng)失效探測、指示和減輕有關的自檢或監(jiān)控功能。

例如:?應用層軟件程序流監(jiān)控，輸入，輸出合理性檢測等; 基礎軟件自檢等。

2

與安全相關硬件要素故障探測、指示和減輕相關的功能。

例如:?涉及基礎軟件相關安全機制，包括控制單元電源，時鐘，內存等硬件要素故障信息探測，指示和控制。

3

使系統(tǒng)達到或維持安全狀態(tài)或降級狀態(tài)的功能。

例如: 錯誤管理，安全狀態(tài)等。

怎么從TSR得到SWSR呢？

SWSR屬于由軟件相關的TSR細化得到軟件層面安全需求，只要在系統(tǒng)開發(fā)階段有效識別出軟件相關的TSR，SWSR導出相對比較容易。 ?

具體來說，根據分配至軟件組件的TSR，對其進行進一步安全分析或直接根據經驗，導出更為詳細的SWSR，需要注意的是: ?

1

在實際操作中，除安全機制相關的SWSR外，還需要根據適用性，充分考慮上述提到的非安全機制相關SWSR，尤其是軟硬件接口規(guī)范和FFI免于干擾的安全需求，它們是保證軟件功能安全重要內容。

2

FFI免于干擾的安全需求多和基礎軟件相關，部分屬于安全機制。在實際操作中，一般會將SWSR分為應用層軟件安全相關和基礎軟件相關的安全需求，便于后續(xù)獨立開發(fā)。

軟件需求書寫實踐原則

軟件需求作為后續(xù)軟件開發(fā)的重要輸入，其質量很大程度上決定了軟件開發(fā)質量，所以寫好需求是門技術，需要對系統(tǒng)及Stakeholder需求有充分的理解，這也是為什么近幾年需求的定義和管理越來越收到企業(yè)重視的原因。

鑒于此，接下來我們聊一下軟件需求書寫實踐原則，具體包括以下內容：

層次化。

需求不可分解，不要將兩個要求合二為一，保持需求細化。

應該使每個要求表述盡可能完整和準確，無歧義，無冗余，不要輸入可能使開發(fā)人員感到困惑的不合理的額外信息

除了需求本身，可以添加規(guī)則或示例、范圍陳述或目標進行補充。

需求定義軟件該做什么，而不是不該做什么。

有必要在文檔中記錄所有假設。

需求可驗證性。

需求可追溯性。

網絡上有很多需求文檔書寫模板，包括RUP版本，Volere版本，ISO版本，SERU版本等，大家直接關鍵詞搜索即可，在此不再贅述。

審核編輯：劉清