01

軟件開發模型

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

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

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

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

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

我個人觀點如下: ?

1

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

2

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

3

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

4

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

5

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

02

什么是軟件安全需求？

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

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

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

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

1

使標稱功能可以安全執行的功能等。

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

2

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

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

3

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

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

4

軟硬件接口規范要求。

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

5

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

例如:?FFI中軟件分區。 ?

軟件安全機制包括:

1

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

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

2

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

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

3

使系統達到或維持安全狀態或降級狀態的功能。

例如: 錯誤管理，安全狀態等。

怎么從TSR得到SWSR呢？

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

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

1

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

2

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

軟件需求書寫實踐原則

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

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

層次化。

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

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

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

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

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

需求可驗證性。

需求可追溯性。

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

審核編輯：劉清