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

軟件開發(fā)模型

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

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

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

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

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

我個人觀點如下: ?

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

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

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

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

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

什么是軟件安全需求？

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

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

軟件安全需求SWSR?= 安全機制無關(guān)的軟件安全需求 + 軟件安全機制?

安全機制無關(guān)的軟件安全需求包括:?

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

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

在生產(chǎn)、運行、服務(wù)和報廢過程中與車載測試和非車載測試相關(guān)的功能。

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

允許在生產(chǎn)和服務(wù)過程中對軟件進行修改的功能。

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

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

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

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

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

軟件安全機制包括:

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

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

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

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

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

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

怎么從TSR得到SWSR呢？

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

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

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

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

軟件需求書寫實踐原則

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

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

層次化。

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

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

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

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

有必要在文檔中記錄所有假設(shè)。

需求可驗證性。