日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機(jī)站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

沃爾沃：敏捷開發(fā)中滿足ISO26262的軟件安全分析

2021-11-22 09:35:05·  來源：汽車ECU開發(fā)  
　
軟件安全分析是整個汽車系統(tǒng)安全審查的一部分。其目的是降低車輛使用過程中由軟件缺陷給車內(nèi)人員帶來的風(fēng)險。ISO26262-6第7節(jié)要求對車輛ECU的軟件體系結(jié)構(gòu)進(jìn)行特
軟件安全分析是整個汽車系統(tǒng)安全審查的一部分。其目的是降低車輛使用過程中由軟件缺陷給車內(nèi)人員帶來的風(fēng)險。ISO26262-6第7節(jié)要求對車輛ECU的軟件體系結(jié)構(gòu)進(jìn)行特定的安全導(dǎo)向分析，以實(shí)現(xiàn)以下四個目標(biāo)：
1、證明軟件可提供指定安全相關(guān)的功能和屬性；
2、識別并確認(rèn)軟件的安全相關(guān)部分；
3、支持安全機(jī)制以及安全機(jī)制的驗(yàn)證；
4、檢測可能違反所需干擾自由度的故障模式。
由于軟件呈爆炸式增長，錯誤發(fā)生的幾率增加。意味著不再可能分析給定軟件系統(tǒng)的每個狀態(tài)，并確定是否存在相關(guān)的錯誤。相反通過分析某些特性，如復(fù)雜性、代碼靜態(tài)檢查等，可以估計(jì)軟件中錯誤數(shù)量的概率。然而，ISO 26262-6第7節(jié)也要求，對于某些類型的錯誤，在架構(gòu)級(車輛功能)層面，應(yīng)該進(jìn)行全面的分析。以下就是基于此發(fā)展的一種方法。
軟件安全分析中的缺陷
進(jìn)行系統(tǒng)安全分析的方法包括以下內(nèi)容：
1、失效模式及影響分析FMEA；
2、故障樹分析；
3、事件樹分析；
4、危險和可操作性分析。
使用這些方法進(jì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)的安全分析方法，如:
1、Petri網(wǎng)分析；
2、失效傳播轉(zhuǎn)化符號FPTN；
3、軟件關(guān)鍵性分析；
4、軟件FMEA
5、軟件故障模式、影響和關(guān)鍵性分析（SFMECA）。
FPTN更多的是一種標(biāo)記技術(shù)，它不能進(jìn)行詳盡的分析。Petri網(wǎng)分析適用于基礎(chǔ)軟件。軟件FMEA和SFMECA是使用應(yīng)用層軟件的，但隨著軟件復(fù)雜性的增加，它們需要付出更多的努力。軟件臨界性分析和SHARD關(guān)注的是數(shù)據(jù)流。在SHARD中提出的數(shù)據(jù)流概念在我們的上下文中很有價值，它在以下的方法中有使用，但使用的順序和抽象層不同。這些方法從整個架構(gòu)層面開始分析，從上到下研究輸入輸出信號和相應(yīng)的故障模式。它們假設(shè)有一個前端架構(gòu)，不會隨著時間發(fā)生顯著的變化。
然而，在現(xiàn)代軟件開發(fā)中，架構(gòu)基本是不斷變化。就沃爾沃汽車而言，敏捷團(tuán)隊(duì)擁有稱為軟件包的架構(gòu)組件（圖 1）。與電子控制單元 (ECU) 級別的架構(gòu)決策相比，軟件包內(nèi)部的架構(gòu)決策是緊急的，后者隨著時間的推移相對穩(wěn)定。緊急架構(gòu)阻止進(jìn)行自上而下的分析，因?yàn)樾盘柕臓顟B(tài)可能會在過程中間發(fā)生變化，從而使結(jié)果無效。此外，在我們的案例中，基礎(chǔ)軟件和部分應(yīng)用軟件由供應(yīng)商采購，因此無法進(jìn)行自上而下的分析。


圖1 沃爾沃汽車ECU軟件概述
應(yīng)用軟件的復(fù)雜性、對客戶的響應(yīng)性、多站點(diǎn)開發(fā)以及緊急架構(gòu)都敦促我們開發(fā)一種新的軟件安全分析方法，以幫助我們遵守ISO 26262-6。然而，這種方法是針對以Simulink模型作為軟件單元開發(fā)的應(yīng)用軟件而設(shè)計(jì)的。該方法不適用于手寫軟件和基礎(chǔ)軟件。與Simulink模型相比，手寫代碼具有較少的開發(fā)限制(例如，非強(qiáng)制性地遵守干凈的編碼標(biāo)準(zhǔn))和更多與其他文件和函數(shù)的耦合。因此，分析不那么清晰的數(shù)據(jù)流需要付出更多的努力，這在開發(fā)中可能是不可承受的。
01、研究方法
研究過程中的一個關(guān)鍵決定是首先識別軟件中的所有錯誤類型，因?yàn)橛捎阱e誤的多樣性，不確定哪些類型應(yīng)該進(jìn)行面向安全的軟件分析。以及哪些錯誤會影響軟件安全分析的目標(biāo)實(shí)現(xiàn)。通常采用行動研究來處理這種情況：成立了一個從業(yè)人員參考小組，在行動研究周期中進(jìn)行迭代。其成員包括一名軟件工程技術(shù)領(lǐng)導(dǎo)，一名軟件安全技術(shù)專家，一名高級安全工程師，一名軟件開發(fā)首席工程師，一名軟件架構(gòu)師，一名高級軟件開發(fā)人員，以及一名負(fù)責(zé)開發(fā)車輛安全關(guān)鍵功能的產(chǎn)品負(fù)責(zé)人。任務(wù)包括以下內(nèi)容：
1．根據(jù)給定的軟件開發(fā)過程和工作產(chǎn)品，識別應(yīng)用軟件中可能發(fā)生的所有類型的錯誤；
2．針對已識別的錯誤類型，調(diào)查并記錄當(dāng)前的解決方法
3．為尚未發(fā)現(xiàn)的錯誤類型指定預(yù)設(shè)解決方法；
4．審查面向安全的軟件分析方法的開發(fā)。
沃爾沃為未發(fā)現(xiàn)的錯誤類型提出了初始的解決方法。他們還設(shè)計(jì)了面向安全的軟件分析方法的框架。并且根據(jù)參考小組在行動研究周期中對這些建議提出的批判性的質(zhì)疑，討論得出了初步的結(jié)果。在大約一年半的時間里，軟件安全分析方法基本上具體化了。之后將該方法應(yīng)用于沃爾沃某大型ECU內(nèi)部應(yīng)用軟件，對分析方法進(jìn)行了更多的調(diào)整。應(yīng)用該方法的軟件有大約200個Simulink模型(產(chǎn)生大約80萬行代碼)，由12個敏捷團(tuán)隊(duì)開發(fā)。
02、軟件安全分析方法
分析方法由兩部分組成。首先是對軟件開發(fā)過程的評估，并采用一套實(shí)用且有效的方法來檢測整個開發(fā)鏈中的錯誤。這些方法可以識別并消除絕大部分開發(fā)階段的軟件錯誤。這個過程被稱為軟件安全的通用分析，它明確地包含了軟件錯誤檢測的概率性質(zhì)，并非所有軟件狀態(tài)都可以檢查。但這確保了通過可用的方法和工具將總體軟件錯誤的可能性降至最低。
第二部分是在架構(gòu)級別的面向安全的軟件分析，以消除可能在通用分析中遺漏的并且可能不利于安全目標(biāo)實(shí)現(xiàn)的錯誤。架構(gòu)級別的安全分析保持與軟件工程保持同步，并且跟通用分析也是同步進(jìn)行的。這兩種分析中通常采用自動化檢查、基于度量的更正、同行評審和自動化測試等方法來輔助分析。
軟件安全的通用分析識別了開發(fā)鏈中的錯誤，并給出解決辦法。表1中記錄了我們產(chǎn)品的此類調(diào)查結(jié)果。如果某類錯誤可能影響四個安全目標(biāo)中的任何一個，則應(yīng)進(jìn)行額外的安全導(dǎo)向分析。這些錯誤類型在表中以粗體顯示。他們會定期評估和更新（例如，一年一次）。負(fù)責(zé)的軟件安全專家應(yīng)確保該表的信息是最新的。

表1 汽車軟件確定的錯誤和解決辦法
03、架構(gòu)級別面向安全的軟件分析
面向安全的分析旨在識別由于需求錯誤說明、錯誤分配、軟件模型之間不正確的信號接口和不正確的功能調(diào)用（表1中以粗體顯示）而導(dǎo)致的錯誤。分析分為兩個階段。第1階段的全部分析是面向Simulink模型。有一個敏捷團(tuán)隊(duì)每次選擇一個Simulink模塊，并在軟件安全專家的支持下進(jìn)行分析。第2階段的分析實(shí)體是應(yīng)用軟件。軟件架構(gòu)師在軟件安全專家的支持下進(jìn)行分析，并使用階段1的結(jié)果。
第1階段開始于產(chǎn)品負(fù)責(zé)人與敏捷團(tuán)隊(duì)和軟件安全專家一起組織一個研討會。假設(shè)團(tuán)隊(duì)已有關(guān)于給定模型的故障模式以及每個故障模式對應(yīng)的車輛級安全級別（CLs）的正確信息。事實(shí)上，這一分析的目標(biāo)之一就是糾正這一假設(shè)。CLs的定義如下：
1．如果車輛級后果未違反安全目標(biāo)，則歸類為CL1。如果模型只有CL1，則模型本身被分類為CL1。
2. 如果車輛級后果違反安全目標(biāo)，但有安全機(jī)制避免該后果，則將其歸類為CL2。如果模型只有CL2和CL1，則模型本身被分類為CL2。
3. 如果車輛級后果違反安全目標(biāo)且沒有任何安全機(jī)制，則將其歸類為CL3，模型本身被分類為CL3。
第1階段和第2階段的概述如圖2所示。下面是逐步詳細(xì)的描述。

圖2 階段1和階段2概述
階段1：由敏捷團(tuán)隊(duì)在安全專家的支持下進(jìn)行
1. 了解模型實(shí)現(xiàn)的功能；
2. 根據(jù)模型的輸出信號和功能調(diào)用確定故障模式；
3. 盡團(tuán)隊(duì)所知，確定每個故障模式的車輛級后果；
4．將每個故障模式的車輛級后果分類為CL1、CL2或CL3。
  • 車輛級后果是否違反安全目標(biāo)？如果沒有，則將結(jié)果分類為CL1。如果是，請轉(zhuǎn)到下一點(diǎn)。
  • 模型外部是否有安全機(jī)制來避免這種后果？如果是，將后果分類為CL2，并參考安全機(jī)制。如果沒有，請轉(zhuǎn)到下一點(diǎn)。
  • 相應(yīng)的輸出信號（功能調(diào)用）是否為CL3？如果是，將其車輛級后果分類為CL3。如果否，則檢測到不合適的設(shè)計(jì)。
5. 確認(rèn)軟件的CL3部分。
  • 具有CL3故障模式的模型在架構(gòu)描述中是否有相應(yīng)的ASIL等級分類？如果否，則檢測到不合適的設(shè)計(jì)。
  • 具有CL3故障模式的模型是否有相應(yīng)ASIL分類的故障模式要求？如果否，則檢測到不合適的設(shè)計(jì)。
6. 對于至少有一個CL2或CL3的模型，應(yīng)該用相應(yīng)的輸出信號(函數(shù)調(diào)用)記錄所有故障模式。
  • 記錄信號(函數(shù)調(diào)用)、故障模式、車輛級后果、CLs和ASIL級別的名稱。
7. 盡團(tuán)隊(duì)所知，確定并記錄CL3故障的原因。
  • 將原因按CL1、CL2或CL3分類。原因可以是輸入信號、觸發(fā)器、代碼開關(guān)、配置和其他錯誤類型。
8.在實(shí)踐時，應(yīng)記錄團(tuán)隊(duì)認(rèn)為完成第 1 階段所需的補(bǔ)齊的知識點(diǎn)。
在第1階段之后，所有標(biāo)記為CL3的模型應(yīng)與系統(tǒng)安全工程師共享，以確認(rèn)危害分析中的相應(yīng)ASIL等級。ASIL等級應(yīng)與表第5點(diǎn)下第一個條目中的信息一起記錄。
引導(dǎo)詞用于系統(tǒng)地表示特定設(shè)計(jì)意圖的可能偏差，并確定可能的后果。引導(dǎo)詞可用于識別弱點(diǎn)、故障和故障。選擇合適的引導(dǎo)詞取決于所檢查功能、行為、屬性、接口和數(shù)據(jù)的特征。分析中應(yīng)使用的指導(dǎo)詞集取決于上下文，因此應(yīng)由分析工程師在安全專家的協(xié)助下選擇。表2中提供了第1階段分析結(jié)果的樣本。分析的第二階段使用第一階段的結(jié)果來確認(rèn)CL2模型的安全機(jī)制，并評估安全相關(guān)軟件的抗干擾性。
表2 Simulink模型分析的示例結(jié)果
階段2：由軟件架構(gòu)師在安全專家支持下進(jìn)行
1. 通過檢查第1階段的所有CL2相關(guān)的模型及其安全機(jī)制，確認(rèn)軟件的CL2部分。
  • 目標(biāo)軟件版本中是否包含安全機(jī)制？如果否，則檢測到不合適的設(shè)計(jì)。如果是，評估安全機(jī)制的充分性；
  • 是否為安全機(jī)制規(guī)定了適當(dāng)?shù)能浖?系統(tǒng)集成測試？如果否，請指定一個。
2.通過檢查軟件架構(gòu)中的所有模型，確認(rèn)各功能的分區(qū)合理性。
  • 具有給定ASIL等級的模型是否分配給具有相同或更高ASIL等級的軟件分區(qū)？如果否，則檢測到不適當(dāng)?shù)姆峙洹?/span>
  • 如果不同ASIL等級的模型分配到同一分區(qū)，請?jiān)诩軜?gòu)描述中確認(rèn)這些模型是根據(jù)最高ASIL開發(fā)標(biāo)準(zhǔn)設(shè)計(jì)的。
3. 檢查從較低ASIL分區(qū)到較高分區(qū)的故障模式傳播。
  • 所有CL3輸入信號是否都來自CL3模型?如果不是，則檢測到緊急架構(gòu)和合理架構(gòu)之間不一致的規(guī)范。
4.根據(jù)階段1分析，確認(rèn)應(yīng)用軟件的接口信號具有正確的ASIL分類。
建議團(tuán)隊(duì)在每個項(xiàng)目增量期間執(zhí)行第1階段。在一些敏捷方法中，每個增量可能是8到12周。第2階段應(yīng)在每次產(chǎn)品發(fā)布之前執(zhí)行，前提是明確不會發(fā)生進(jìn)一步的功能更改。
04、總結(jié)
該方法被認(rèn)為是經(jīng)濟(jì)上可承受的連續(xù)安全分析方法。原因如下：首先，軟件安全的一般分析方法在很大程度上是自動化的，并與軟件開發(fā)環(huán)境集成。一旦部署了這些方法（表1），就很容易定期審查和更新信息。其次，一旦進(jìn)行了以安全為導(dǎo)向的分析，在未來，團(tuán)隊(duì)將擁有足夠的知識和文件，根據(jù)輸出信號的變化及其相應(yīng)信息（故障模式、車輛級后果等）更新評估。文檔可以是Excel表格和基于瀏覽器的半自動方式。
面向安全的軟件分析有助于關(guān)注直接違反安全目標(biāo)的錯誤。這種分析超越了自動檢查，這重點(diǎn)關(guān)注模型實(shí)現(xiàn)了哪些功能，模型間如何相互干預(yù)，以及模型與架構(gòu)決策如何一致。這有助于避免可能危及功能安全的意外設(shè)計(jì)決策。
一般來說，以上的分析需要了解模型在車輛級功能中的作用。以安全為導(dǎo)向的分析增強(qiáng)了敏捷團(tuán)隊(duì)的這種意識，開拓了成員的知識面，使他們能夠做出更明智的設(shè)計(jì)決策。使用此方法過程中也得到了有關(guān)改進(jìn)的反饋，主要提高了自動化程度并集成到軟件開發(fā)環(huán)境中，以減少技術(shù)的管理工作。
來源：整理自外文文獻(xiàn)，侵刪.
分享到：
 
反對 0 舉報(bào) 0 收藏 0 評論 0
滬ICP備11026917號-25