軟件安全分析是汽車系統(tǒng)安全審查的一部分，其目的在于減少車輛使用中由軟件缺陷引起的風(fēng)險。ISO26262-6第7節(jié)要求對車輛ECU的軟件體系結(jié)構(gòu)進(jìn)行特定的安全導(dǎo)向分析，以實(shí)現(xiàn)以下四個目標(biāo)：

證明軟件能夠提供特定的安全相關(guān)功能和屬性；

辨識和確認(rèn)軟件的安全相關(guān)部分；

支持安全機(jī)制以及驗(yàn)證這些安全機(jī)制；

檢測可能違反所需干擾自由度的故障模式。

隨著軟件數(shù)量的爆炸性增長，錯誤發(fā)生的概率也在增加。這意味著不再可能分析每個給定軟件系統(tǒng)的狀態(tài)，并確定其中是否存在相關(guān)的錯誤。相反，通過分析一些特定特征，如復(fù)雜性、代碼靜態(tài)檢查等，可以估計軟件中錯誤的數(shù)量概率。然而，ISO 26262-6第7節(jié)也要求對某些類型的錯誤，在架構(gòu)級（即車輛功能層面）進(jìn)行全面分析。下文介紹了一種基于此要求發(fā)展的方法。

軟件安全分析中的一個主要挑戰(zhàn)是，作為一個系統(tǒng)，軟件的狀態(tài)數(shù)量比硬件多得多。事實(shí)上，無法對所有狀態(tài)進(jìn)行分析，并以合理的方式確定哪些狀態(tài)應(yīng)該優(yōu)先考慮。因此，我們的研究使用了一些系統(tǒng)安全分析方法的概念，如“指導(dǎo)詞”和“故障模式”，作為標(biāo)準(zhǔn)表示。

除此之外，有些人提出了以軟件為重點(diǎn)的安全分析方法，例如：

Petri網(wǎng)分析；

失效傳播轉(zhuǎn)化符號FPTN；

軟件關(guān)鍵性分析；

軟件FMEA；

軟件故障模式、影響和關(guān)鍵性分析（SFMECA）。

然而，F(xiàn)PTN更多的是一種標(biāo)記技術(shù)，不能進(jìn)行詳盡的分析。Petri網(wǎng)分析適用于基礎(chǔ)軟件。軟件FMEA和SFMECA用于應(yīng)用層軟件，但隨著軟件復(fù)雜性的增加，需要投入更多的努力。軟件臨界性分析和SHARD關(guān)注數(shù)據(jù)流。SHARD提出的數(shù)據(jù)流概念在我們的背景下非常有價值，它在以下方法中有所運(yùn)用，但使用的順序和抽象層次不同。這些方法從整個架構(gòu)層面開始分析，自上而下研究輸入輸出信號和相關(guān)的故障模式。它們假設(shè)存在一個固定的前端架構(gòu)，不會隨著時間顯著變化。

然而，在現(xiàn)代軟件開發(fā)中，架構(gòu)基本上是不斷變化的。對于沃爾沃汽車而言，敏捷團(tuán)隊擁有稱為軟件包的架構(gòu)組件（見圖1）。與ECU級別的架構(gòu)決策相比，軟件包內(nèi)部的架構(gòu)決策更加緊急，并且相對穩(wěn)定的時間更短。緊急的架構(gòu)變化阻礙了自上而下的分析，因?yàn)樾盘枲顟B(tài)可能在過程中發(fā)生變化，使得分析結(jié)果無效。另外，在我們的案例中，基礎(chǔ)軟件和部分應(yīng)用軟件是由供應(yīng)商提供的，因此無法進(jìn)行自上而下的分析。

圖1 沃爾沃汽車ECU軟件概述

對于ISO 26262-6的合規(guī)性，應(yīng)用軟件的復(fù)雜性、對客戶需求的敏感性、多地點(diǎn)開發(fā)以及迫切的架構(gòu)變更等因素迫使我們構(gòu)建一種全新的軟件安全分析方法。然而，這種方法是專門針對以Simulink模型作為軟件單元開發(fā)的應(yīng)用軟件而設(shè)計的。這個方法并不適用于手寫代碼和基礎(chǔ)軟件。相對于Simulink模型，手寫代碼的開發(fā)限制較少（例如，可能不強(qiáng)制遵循嚴(yán)格的編碼標(biāo)準(zhǔn)），并且與其他文件和函數(shù)之間的耦合更為密切。因此，在分析不夠清晰的數(shù)據(jù)流時，可能需要投入更多的工作量，這對于開發(fā)來說可能是難以接受的。

  1. 研究方法

在研究過程中，關(guān)鍵的決定之一是首先識別軟件中存在的所有錯誤類型。由于錯誤種類繁多，確定哪些類型需要進(jìn)行面向安全的軟件分析，以及哪些錯誤會影響軟件安全分析的目標(biāo)實(shí)現(xiàn)是至關(guān)重要的。為了處理這種情況，通常會采用行動研究方法：成立一個由各領(lǐng)域?qū)＜医M成的參考小組，在行動研究周期內(nèi)進(jìn)行反復(fù)迭代。該小組成員包括軟件工程技術(shù)領(lǐng)導(dǎo)、軟件安全技術(shù)專家、高級安全工程師、軟件開發(fā)首席工程師、軟件架構(gòu)師、高級軟件開發(fā)人員以及負(fù)責(zé)開發(fā)車輛安全關(guān)鍵功能的產(chǎn)品負(fù)責(zé)人。其任務(wù)涵蓋以下方面：

根據(jù)特定的軟件開發(fā)流程和工作產(chǎn)物，識別可能存在于應(yīng)用軟件中的所有錯誤類型；

針對已識別的錯誤類型，調(diào)查和記錄當(dāng)前的解決方法；

為尚未發(fā)現(xiàn)的錯誤類型指定預(yù)設(shè)解決方法；

審查面向安全的軟件分析方法的開發(fā)。

沃爾沃為尚未發(fā)現(xiàn)的錯誤類型提出了初步的解決方法，并設(shè)計了面向安全的軟件分析方法的框架。通過參考小組在行動研究周期中對這些提議的質(zhì)疑和批判性討論，初步結(jié)果得到了進(jìn)一步的完善。在大約一年半的時間內(nèi)，軟件安全分析方法逐漸具體化。隨后，該方法被應(yīng)用于沃爾沃某一大型ECU內(nèi)部的應(yīng)用軟件，這一過程中對分析方法進(jìn)行了更多的調(diào)整。應(yīng)用該方法的軟件包括大約200個Simulink模型（生成約80萬行代碼），由12個敏捷團(tuán)隊開發(fā)。

 2. 軟件安全分析方法

這個分析方法由兩個主要部分組成。首先是對軟件開發(fā)過程的評估，使用一套實(shí)用且有效的方法來檢測整個開發(fā)鏈中的錯誤。這些方法能夠識別和消除大部分開發(fā)階段的軟件錯誤。這個過程被稱為通用軟件安全分析，明確包含了對軟件錯誤進(jìn)行概率性檢測的性質(zhì)，因?yàn)椴⒎撬熊浖顟B(tài)都可以被檢查。但這確保了通過可用的方法和工具將整體軟件錯誤的可能性降至最低。

第二部分是面向安全的架構(gòu)級別的軟件分析，旨在消除在通用分析中可能被忽略但可能對安全目標(biāo)實(shí)現(xiàn)不利的錯誤。架構(gòu)級別的安全分析與軟件工程保持同步，與通用分析同時進(jìn)行。這兩種分析通常使用自動化檢查、基于度量的更正、同行評審和自動化測試等方法來輔助進(jìn)行分析。

通用軟件安全分析識別了開發(fā)鏈中的錯誤，并提供了解決方案。表格中記錄了我們產(chǎn)品的這類調(diào)查結(jié)果。如果某一類錯誤可能影響到四個安全目標(biāo)中的任何一個，就需要進(jìn)行額外的面向安全的分析。這些錯誤類型在表格中以粗體顯示。它們會定期進(jìn)行評估和更新（例如，每年一次）。負(fù)責(zé)軟件安全的專家應(yīng)確保表格中的信息保持最新。

表1 汽車軟件確定的錯誤和解決辦法

 3. 架構(gòu)級別面向安全的軟件分析

這個面向安全的分析旨在識別由需求錯誤說明、錯誤分配、不正確的信號接口以及錯誤的功能調(diào)用導(dǎo)致的錯誤（在表1中以粗體顯示）。整個分析分為兩個階段：

第一階段：

第一階段的分析針對Simulink模型展開。每次，一個敏捷團(tuán)隊選擇一個Simulink模塊，并在軟件安全專家的支持下進(jìn)行分析。

研討會啟動：產(chǎn)品負(fù)責(zé)人與敏捷團(tuán)隊和軟件安全專家組織研討會。假設(shè)團(tuán)隊已有關(guān)于給定模型的故障模式以及每個故障模式對應(yīng)的車輛級安全級別（CLs）的正確信息。然而，這個分析的目標(biāo)之一是驗(yàn)證和糾正這一假設(shè)。

車輛級安全級別（CLs）定義：CLs定義如下：

CL1：如果車輛級后果未違反安全目標(biāo)，則分類為CL1。如果模型只包含CL1，則模型本身被歸類為CL1。

CL2：如果車輛級后果違反安全目標(biāo)，但有安全機(jī)制避免該后果，則分類為CL2。如果模型包含CL2和CL1，則模型本身被歸類為CL2。

CL3：如果車輛級后果違反安全目標(biāo)且沒有任何安全機(jī)制，則分類為CL3，模型本身被歸類為CL3。

第二階段：

第二階段的實(shí)體是應(yīng)用軟件，由軟件架構(gòu)師在軟件安全專家的支持下進(jìn)行分析，并利用第一階段的結(jié)果。

以上是對第一和第二階段的概述。接下來會有詳細(xì)的逐步描述。（圖2顯示了第一和第二階段的概貌）

圖2 階段1和階段2概述

階段 一：由敏捷團(tuán)隊在安全專家的支持下進(jìn)行：

了解模型功能：對模型實(shí)現(xiàn)的功能有所了解。

確定故障模式：根據(jù)模型的輸出信號和功能調(diào)用來確定故障模式。

確定車輛級后果：基于團(tuán)隊知識確定每個故障模式的車輛級后果。

分類車輛級后果：

如果車輛級后果不違反安全目標(biāo)，則分類為CL1。

如果車輛級后果違反安全目標(biāo)，但存在安全機(jī)制避免此后果，則分類為CL2，并記錄相應(yīng)的安全機(jī)制。

如果車輛級后果違反安全目標(biāo)且沒有任何安全機(jī)制，則分類為CL3。若輸出信號或功能調(diào)用是CL3，則進(jìn)行不適當(dāng)設(shè)計的檢測。

確認(rèn)CL3部分：

確認(rèn)具有CL3故障模式的模型在架構(gòu)描述中是否有相應(yīng)的ASIL等級分類。若無，則存在不適當(dāng)?shù)脑O(shè)計。

確認(rèn)具有CL3故障模式的模型是否有相應(yīng)ASIL分類的故障模式需求。若無，則存在不適當(dāng)?shù)脑O(shè)計。

記錄故障模式和信號：

對于至少有一個CL2或CL3的模型，記錄所有故障模式、輸出信號（函數(shù)調(diào)用）、車輛級后果、CLs和ASIL級別的名稱。

確定CL3故障的原因：

根據(jù)團(tuán)隊知識確定并記錄CL3故障的原因，將原因按CL1、CL2或CL3分類。原因可以是輸入信號、觸發(fā)器、代碼開關(guān)、配置和其他錯誤類型。

記錄補(bǔ)充知識：記錄團(tuán)隊認(rèn)為完成第1階段所需的補(bǔ)充知識。

在第1階段完成后，所有標(biāo)記為CL3的模型應(yīng)與系統(tǒng)安全工程師共享，以確認(rèn)危害分析中的相應(yīng)ASIL等級。ASIL等級應(yīng)與第5點(diǎn)下第一個條目中的信息一起記錄。

在這個過程中，引導(dǎo)詞被用于系統(tǒng)地表示設(shè)計意圖的可能偏差，并確定可能的后果。這些詞用于識別弱點(diǎn)、故障和故障。分析工程師應(yīng)在安全專家的協(xié)助下選擇適當(dāng)?shù)囊龑?dǎo)詞，取決于所檢查功能、行為、屬性、接口和數(shù)據(jù)的特征。表2提供了第1階段分析結(jié)果的樣本。第2階段的分析將使用第1階段的結(jié)果來確認(rèn)CL2模型的安全機(jī)制，并評估安全相關(guān)軟件的抗干擾性。

表2 Simulink模型分析的示例結(jié)果 

階段 二：由軟件架構(gòu)師在安全專家的支持下進(jìn)行：

確認(rèn)軟件的CL2部分：

檢查第1階段中所有與CL2相關(guān)的模型及其安全機(jī)制。

確認(rèn)目標(biāo)軟件版本中是否包含安全機(jī)制，評估其充分性。如果安全機(jī)制不完整，則存在不合適的設(shè)計，需要指定適當(dāng)?shù)能浖?系統(tǒng)集成測試。

確認(rèn)功能的分區(qū)合理性：

檢查軟件架構(gòu)中的所有模型，確認(rèn)各功能的分區(qū)是否合理。

確認(rèn)具有給定ASIL等級的模型是否分配給具有相同或更高ASIL等級的軟件分區(qū)。若分配不合理，則存在不適當(dāng)?shù)姆峙洹?/span>

如果不同ASIL等級的模型分配到同一分區(qū)，請在架構(gòu)描述中確認(rèn)這些模型是根據(jù)最高ASIL開發(fā)標(biāo)準(zhǔn)設(shè)計的。

故障模式傳播檢查：

檢查從較低ASIL分區(qū)到較高分區(qū)的故障模式傳播。

確認(rèn)所有CL3輸入信號是否都來自CL3模型。若存在不一致的規(guī)范，則檢測到緊急架構(gòu)和合理架構(gòu)之間的不一致性。

接口信號的ASIL分類確認(rèn)：

根據(jù)階段1的分析結(jié)果，確認(rèn)應(yīng)用軟件的接口信號是否具有正確的ASIL分類。

建議團(tuán)隊在每個項目增量期間執(zhí)行第1階段。在某些敏捷方法中，每個增量可能為8到12周。第2階段應(yīng)在每次產(chǎn)品發(fā)布之前執(zhí)行，前提是明確不會發(fā)生進(jìn)一步的功能更改。這有助于確保系統(tǒng)的安全性和穩(wěn)定性在發(fā)布前得到充分考慮和驗(yàn)證。

  4. 總結(jié)

這個方法之所以被視為經(jīng)濟(jì)上可行的連續(xù)安全分析方法，主要原因如下：

自動化與集成：軟件安全的通用分析方法大部分是自動化的，并且與軟件開發(fā)環(huán)境集成。一旦部署并建立（如表1所示），定期審查和更新信息就變得簡單。這意味著團(tuán)隊可以輕松地保持對安全分析的持續(xù)性。

持續(xù)性的知識和文件：一旦進(jìn)行了以安全為導(dǎo)向的分析，團(tuán)隊將會積累足夠的知識和文件。這些文件可以根據(jù)輸出信號的變化和相應(yīng)信息（例如故障模式、車輛級后果等）進(jìn)行更新和評估。文檔可能采用Excel表格或者基于瀏覽器的半自動方式。

關(guān)注安全目標(biāo)違反的錯誤：面向安全的軟件分析有助于關(guān)注直接違反安全目標(biāo)的錯誤。它不僅僅是自動檢查，更關(guān)注于了解模型實(shí)現(xiàn)了哪些功能、模型之間的相互影響，以及模型與架構(gòu)決策的一致性。這可以幫助避免可能對功能安全構(gòu)成威脅的意外設(shè)計決策。

增強(qiáng)團(tuán)隊意識和知識面：這種分析增強(qiáng)了團(tuán)隊對模型在車輛級功能中作用的認(rèn)識。它拓展了團(tuán)隊成員的知識面，使他們能夠做出更明智的設(shè)計決策。

持續(xù)改進(jìn)：使用此方法帶來了關(guān)于改進(jìn)的反饋。主要集中在提高自動化程度、集成到軟件開發(fā)環(huán)境中以減少技術(shù)管理工作的方面。

總的來說，這種分析方法不僅有助于持續(xù)性地進(jìn)行安全分析，還提高了團(tuán)隊的意識水平和設(shè)計決策的智慧。通過減少手動工作和持續(xù)改進(jìn)，它也促進(jìn)了更高效的技術(shù)管理。