01

軟件開(kāi)發(fā)模型

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

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

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

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

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

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

1

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

2

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

3

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

4

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

5

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

02

什么是軟件安全需求？

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

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

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

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

1

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

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

2

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

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

3

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

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

4

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

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

5

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

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

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

1

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

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

2

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

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

3

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

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

怎么從TSR得到SWSR呢？

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

具體來(lái)說(shuō)，根據(jù)分配至軟件組件的TSR，對(duì)其進(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í)際操作中，一般會(huì)將SWSR分為應(yīng)用層軟件安全相關(guān)和基礎(chǔ)軟件相關(guān)的安全需求，便于后續(xù)獨(dú)立開(kāi)發(fā)。

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

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

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

層次化。

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

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

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

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

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

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

需求可追溯性。

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

審核編輯：劉清