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

01

軟件開發(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è)計(jì)，詳細(xì)實(shí)現(xiàn)，最后完成集成和驗(yàn)證。左側(cè)V從需求到設(shè)計(jì)，右側(cè)V從集成到測試驗(yàn)證，具體如下圖所示: ?

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

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

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

我個人觀點(diǎn)如下: ?

1

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

2

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

3

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

4

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

5

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

02

什么是軟件安全需求？

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

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

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

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

1

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

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

2

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

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

3

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

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

4

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

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

5

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

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

軟件安全機(jī)制包括:

1

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

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

2

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

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

3

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

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

怎么從TSR得到SWSR呢？

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

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

1

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

2

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

軟件需求書寫實(shí)踐原則

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

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

層次化。

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

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

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

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

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

需求可驗(yàn)證性。

需求可追溯性。

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

審核編輯：劉清