02. V model

Hardware and Software Product Development Life-Cycle

讓我們概述一下硬件和軟件產(chǎn)品的開(kāi)發(fā)周期。V模型將硬件和軟件分為自己的微型V：

Summary of ISO 26262 V Model

每個(gè)V代表的總體思想保持不變；首先，您指定安全要求。然后，您將這些需求分配給系統(tǒng)體系結(jié)構(gòu)。最后，您進(jìn)行測(cè)試，集成和驗(yàn)證。每個(gè)V模型過(guò)程都與我們?cè)诘谝徽n中討論的過(guò)程相同。

但是，在硬件和軟件方面還需要采取額外的措施。對(duì)于硬件，V模型包括有關(guān)硬件體系結(jié)構(gòu)指標(biāo)和評(píng)估隨機(jī)硬件故障的部分。這是硬件V模型的更詳細(xì)視圖：

在軟件方面，有一個(gè)體系結(jié)構(gòu)設(shè)計(jì)部分以及一個(gè)單元設(shè)計(jì)部分：

在本課程中，我們將討論隨機(jī)的硬件故障以及如何制定軟件安全要求。

Architectural Design vs Unit Design/結(jié)構(gòu)和單元設(shè)計(jì)

軟件體系結(jié)構(gòu)設(shè)計(jì)是軟件組件的更高層次的視圖。例如，這可能是我們的車(chē)道輔助示例中的攝像機(jī)ECU。

單元是軟件體系結(jié)構(gòu)的一小部分。一個(gè)單元可以是一個(gè)軟件驅(qū)動(dòng)程序，用于從攝像機(jī)傳感器讀取原始數(shù)據(jù)。關(guān)于什么屬于建筑設(shè)計(jì)部分而不是單元設(shè)計(jì)部分，沒(méi)有硬性規(guī)定。通常，功能安全可以是一個(gè)反復(fù)的過(guò)程，在該過(guò)程中，開(kāi)發(fā)V模型的新部分可能會(huì)導(dǎo)致前一部分的更改，反之亦然。

在下圖中，您可以看到功能安全項(xiàng)目中涉及的內(nèi)容的一般概述。您可以看到V模型的步驟已垂直延伸。通常，一個(gè)項(xiàng)目將具有多個(gè)系統(tǒng)和子系統(tǒng)。子系統(tǒng)將具有自己的軟件和硬件要求。這些子系統(tǒng)需要集成到更大的系統(tǒng)中：

Functional Safety Bird's Eye View

請(qǐng)注意，由于需要開(kāi)發(fā)定制軟件和硬件，因此此處描述的“上下文”開(kāi)發(fā)可能變得不切實(shí)際。為了緩解這種情況，一種常用的方法是“上下文安全元素”（SEooC），該方法考慮使用標(biāo)準(zhǔn)安全硬件和軟件組件來(lái)解決功能安全實(shí)施問(wèn)題。您可能會(huì)喜歡這篇有趣的論文，描述了SEooC的一種實(shí)用方法。

03. Hardware Failure Metrics

請(qǐng)注意，體系結(jié)構(gòu)指標(biāo)具有獨(dú)立于實(shí)現(xiàn)的值，并表示為費(fèi)率。硬件故障概率度量（PMHF）的絕對(duì)單位表示為每10 ^ 9小時(shí)的故障數(shù)。因此，PMHF本身不是體系結(jié)構(gòu)指標(biāo)，但與硬件故障指標(biāo)的討論有關(guān)。

硅的磨損是系統(tǒng)性故障，而不是隨機(jī)的硬件故障也是有爭(zhēng)議的，因此它可能不被視為隨機(jī)硬件故障指標(biāo)的一部分。

More Details about Hardware Failure Metrics

本質(zhì)上，這些度量標(biāo)準(zhǔn)著眼于安全機(jī)制所涵蓋的硬件故障百分比。安全機(jī)制是一些功能，可以在發(fā)生故障時(shí)保持車(chē)輛安全或檢測(cè)到已發(fā)生故障。這意味著在一個(gè)安全的系統(tǒng)中，大多數(shù)硬件故障都會(huì)被檢測(cè)到。

例子：如果RAM因紫外線(xiàn)輻射引起位翻轉(zhuǎn)而發(fā)生故障，則安全機(jī)制將需要修復(fù)位翻轉(zhuǎn)，將系統(tǒng)置于安全狀態(tài)，和/或警告驅(qū)動(dòng)程序發(fā)生故障。該標(biāo)準(zhǔn)認(rèn)為硬件故障是不可避免的。但是，如果它們將要發(fā)生，那么理想情況下，它們不應(yīng)導(dǎo)致安全問(wèn)題。ASIL D的單點(diǎn)故障指標(biāo)大于99％，而ASIL B僅大于90％。換句話(huà)說(shuō)，對(duì)于ASIL D，對(duì)于特定的安全目標(biāo)，應(yīng)該檢測(cè)到99％的單點(diǎn)故障或者是安全的。

要計(jì)算這些指標(biāo)，您必須弄清楚哪些硬件故障會(huì)導(dǎo)致危險(xiǎn)情況，哪些故障不會(huì)導(dǎo)致危險(xiǎn)情況。該標(biāo)準(zhǔn)實(shí)際上將硬件故障分為六類(lèi)。

Categories of Faults/故障類(lèi)別

要計(jì)算硬件故障指標(biāo)，您需要將故障分類(lèi)為六個(gè)類(lèi)別之一。我們將在此處列出它們以供參考，盡管在本課程中我們實(shí)際上不會(huì)計(jì)算硬件故障指標(biāo)。

單點(diǎn)故障-沒(méi)有安全機(jī)制來(lái)檢測(cè)故障的元素中的故障。故障還會(huì)導(dǎo)致違反安全目標(biāo)。例如，沒(méi)有安全機(jī)制可糾正該錯(cuò)誤的RAM故障將違反安全目標(biāo)。

殘留故障-元素具有檢測(cè)某些類(lèi)型故障的安全機(jī)制；但是，會(huì)出現(xiàn)未設(shè)計(jì)該機(jī)制進(jìn)行檢測(cè)的故障，并且該故障還會(huì)導(dǎo)致違反安全目標(biāo)。例如，RAM可能具有ECC（糾錯(cuò)碼）機(jī)制來(lái)修復(fù)位翻轉(zhuǎn)；但是，由于短路而導(dǎo)致發(fā)生不同的故障，并且RAM沒(méi)有用于短路的安全機(jī)制。

潛在的多點(diǎn)故障-安全機(jī)制和駕駛員無(wú)法檢測(cè)到的多點(diǎn)故障。

感知到的多點(diǎn)故障-駕駛員檢測(cè)到的多點(diǎn)故障，因?yàn)樵摴收蠈?dǎo)致車(chē)輛功能受限。例如，駕駛員注意到減少的剎車(chē)響應(yīng)，或者在沒(méi)有響應(yīng)的情況下激活大燈（它們沒(méi)有打開(kāi)）。

檢測(cè)到的多點(diǎn)故障-安全機(jī)制檢測(cè)到的多點(diǎn)故障并使車(chē)輛進(jìn)入安全狀態(tài)

安全故障-不會(huì)導(dǎo)致違反安全目標(biāo)的故障

多點(diǎn)故障的示例可能涉及RAM和ECC(糾錯(cuò)碼error correction code) 機(jī)制。ECC糾正位翻轉(zhuǎn)。如果由于位翻轉(zhuǎn)而導(dǎo)致RAM包含故障，則ECC將糾正該翻轉(zhuǎn)。如果ECC由于軟件錯(cuò)誤而失敗，則RAM仍將正常工作。如果發(fā)生位翻轉(zhuǎn)并且ECC失敗，則將存在多點(diǎn)故障，因?yàn)閷⒉患m正位翻轉(zhuǎn)。RAM和ECC都將失敗。

循環(huán)冗余校驗(yàn)（CRC）將檢測(cè)到ECC機(jī)制中的故障。沒(méi)有CRC，該故障將不會(huì)被發(fā)現(xiàn)，因此是潛在的。使用CRC，該故障將成為檢測(cè)到的多點(diǎn)故障。如果像警告燈一樣告知駕駛員有關(guān)故障，則這是可感知的多點(diǎn)故障。

Measuring Faults/測(cè)量故障

您將如何實(shí)際測(cè)量故障和失效率？您可以：

• 進(jìn)行現(xiàn)場(chǎng)測(cè)試以測(cè)量給定時(shí)間內(nèi)的故障數(shù)量

• 使用來(lái)自等效或類(lèi)似系統(tǒng)的現(xiàn)有數(shù)據(jù)

• 供應(yīng)商也應(yīng)提供用于計(jì)算這些指標(biāo)的數(shù)據(jù)。

請(qǐng)注意，ISO 26262未指定隨機(jī)硬件故障的目標(biāo)。有一個(gè)針對(duì)硬件故障的概率度量（PMHF），它著眼于每個(gè)安全目標(biāo)的危險(xiǎn)，未檢測(cè)到的硬件故障。ISO 26262建議僅在沒(méi)有數(shù)據(jù)支持目標(biāo)的情況下使用PMHF值。這 是一篇有關(guān)PMHF和隨機(jī)硬件故障的有趣論文。

故障的來(lái)源和類(lèi)型

電阻器并不是唯一會(huì)發(fā)生故障的硬件組件。還需要考慮整個(gè)處理單元。

硬件寄存器 ，內(nèi)部RAM，控制器邏輯以及其他組件可能會(huì)發(fā)生故障。所有這些故障都需要滿(mǎn)足安全要求，然后分配給體系結(jié)構(gòu)并記錄在安全概念中。安全概念將討論如何檢測(cè)或避免這些故障。

04. Programming Languages

Notes about Programming Languages

任何編程語(yǔ)言都會(huì)有長(zhǎng)處和短處。C ++的一個(gè)優(yōu)勢(shì)是能夠編寫(xiě)具有許多輸入輸出操作的高速軟件的能力。另一方面，C ++允許您將浮點(diǎn)數(shù)存儲(chǔ)在布爾變量中。而且C ++在運(yùn)行時(shí)錯(cuò)誤檢查方面沒(méi)有提供太多幫助。

MISRA C ++標(biāo)準(zhǔn)討論了適用于安全關(guān)鍵型應(yīng)用程序的C ++子集。該標(biāo)準(zhǔn)包含一組有關(guān)如何在汽車(chē)應(yīng)用中使用C ++語(yǔ)言的規(guī)則。

Software Tools & Software Tool Confidence Level

汽車(chē)軟件工程師使用各種工具來(lái)幫助開(kāi)發(fā)軟件。

編譯器是軟件工具的一個(gè)示例。其他示例包括版本控制軟件，測(cè)試工具，自動(dòng)生成代碼的圖形建模工具以及有助于確保MISRA遵從性的工具。

功能安全標(biāo)準(zhǔn)要求您對(duì)軟件工具進(jìn)行資格驗(yàn)證，以確保它們適合于安全關(guān)鍵型應(yīng)用程序；使用自動(dòng)化代碼生成和代碼測(cè)試的軟件工具變得越來(lái)越普遍。例如，如果測(cè)試工具有問(wèn)題，則可能無(wú)法檢測(cè)到代碼錯(cuò)誤。

ISO 26262描述了一種度量標(biāo)準(zhǔn)，用于衡量您對(duì)工具的信心。該度量標(biāo)準(zhǔn)稱(chēng)為工具置信度或TCL。

評(píng)估置信度需要考慮以下兩點(diǎn)：

• 工具影響（TI）-工具本身是否可能發(fā)生故障并違反安全目標(biāo)

• 工具錯(cuò)誤檢測(cè)能力（TD）-如果工具發(fā)生故障，是檢測(cè)到還是停止了故障

然后，您可以使用TI和TD度量標(biāo)準(zhǔn)來(lái)計(jì)算工具的置信度級(jí)別.ASIL較高的軟件塊需要TCL1，這是最高置信度。TCL3是最低的置信度等級(jí)。

具有TCL2和3等級(jí)的低置信度工具需要進(jìn)行鑒定。合格包括通過(guò)嚴(yán)格的測(cè)試來(lái)運(yùn)行該工具，以證明它不會(huì)引起任何錯(cuò)誤。軟件工具供應(yīng)商提供了鑒定工具包，可幫助您在自己的環(huán)境中測(cè)試他們的工具。

05. MISRA C++ Lab

MISRA Lab

MISRA C ++標(biāo)準(zhǔn)
MISRA C ++標(biāo)準(zhǔn) 定義的C的子集++撥出對(duì)安全關(guān)鍵AUTOMATIVE應(yīng)用程序。該標(biāo)準(zhǔn)包括數(shù)百條有關(guān)在開(kāi)發(fā)汽車(chē)軟件時(shí)如何使用C ++語(yǔ)言的規(guī)則。
通常，軟件工程師會(huì)使用代碼合規(guī)性檢查包來(lái)確保其代碼符合標(biāo)準(zhǔn)。在本實(shí)驗(yàn)中，您將收到有效的C ++ Kalman過(guò)濾器代碼，其中包含許多MISRA違規(guī)行為。您的工作將是修復(fù)錯(cuò)誤，并使代碼盡可能接近合規(guī)性。
MathWorks 為您提供了MISRA合規(guī)性檢查軟件的試用版，該軟件稱(chēng)為 Polyspace 。Polyspace是業(yè)界用于編寫(xiě)與MISRA兼容的C ++代碼的最常用軟件程序之一。該程序是稱(chēng)為MATLAB的較大的數(shù)學(xué)和工程工具套件的一部分。
這是有關(guān)MATLAB及其在工程和科學(xué)中的用法的視頻。

Polyspace Use Case

另外，在您開(kāi)始實(shí)驗(yàn)之前，請(qǐng)查看此用例，以了解一家汽車(chē)公司如何使用Polyspace改善其代碼質(zhì)量：鏈接至用例 。

安裝MATLAB Polyspace

由于 的支持 MathWorks ，MATLAB和Polyspace的免費(fèi)下載許可證是
在課程期間可用。

1. 如果您還沒(méi)有MathWorks帳戶(hù)，請(qǐng) 創(chuàng)建一個(gè)新帳戶(hù) 。

2. 在此處訪(fǎng)問(wèn)MATLAB的免費(fèi)許可證：下載鏈接 。
   如果您在安裝MATLAB時(shí)遇到問(wèn)題，請(qǐng)?jiān)凇爸R(shí)”或“功能安全性”項(xiàng)目通道的“學(xué)生中心”中搜索或發(fā)布您的問(wèn)題。請(qǐng)?zhí)峁┠?a target="_blank">操作系統(tǒng)以及錯(cuò)誤之前采取的步驟的列表。錯(cuò)誤的屏幕截圖通常也很有幫助。
   您可以在 上找到MATLAB的系統(tǒng)要求 MathWorks網(wǎng)站 。

設(shè)置實(shí)驗(yàn)室

安裝MATLAB Polyspace之后，就可以開(kāi)始實(shí)驗(yàn)了。在此頁(yè)面的底部，您將看到一個(gè)鏈接，上面顯示“支持材料：適用于Udacity的Psprj”。下載并解壓縮該文件夾。
在文本編輯器中，打開(kāi)fileroot / Polyspace / kalmanFilterProject_original.psprj。您將在第13-18行，第34-39行和第45行看到包含路徑。應(yīng)將它們替換為本地文件夾的相應(yīng)路徑。保存并退出文本編輯器。
例如，
在Mac上：

在Windows計(jì)算機(jī)上：

啟動(dòng)Polyspace

使用快捷方式啟動(dòng)Polyspace
matlabroot/polyspace/bin/polyspace.exe
其中matlabroot是MATLAB安裝目錄（通常稱(chēng)為MATLAB / r2017a）
在Mac上，您還可以通過(guò)以下方式啟動(dòng)該程序：

1. 轉(zhuǎn)到應(yīng)用程序文件夾

2. 右鍵單擊“ MATLAB_R2017a”，然后選擇“顯示包裝內(nèi)容”

3. 單擊polyspace文件夾，然后單擊bin文件夾（polyspace-> bin）

4. 右鍵單擊“多邊形”，然后選擇“打開(kāi)”

打開(kāi)項(xiàng)目文件并運(yùn)行錯(cuò)誤查找器

打開(kāi)項(xiàng)目文件 fileroot/Polyspace/kalmanFilterProject_original.psprj在“多邊形”窗口中 。
單擊“運(yùn)行錯(cuò)誤查找器”。MISRA C ++結(jié)果應(yīng)該自動(dòng)出現(xiàn)。
在分析過(guò)程中，您可能會(huì)看到一個(gè)良性彈出錯(cuò)誤。您可以單擊以結(jié)束錯(cuò)誤的后臺(tái)處理，分析將正常完成。此錯(cuò)誤不會(huì)影響MISRA分析。此錯(cuò)誤通常不會(huì)在Mac上出現(xiàn)，但可能會(huì)在Linux和Windows系統(tǒng)上出現(xiàn)。

完成實(shí)驗(yàn)

軟件概述

首次打開(kāi)多邊形時(shí)，該程序?qū)⒏攀鲕浖墓ぷ鞣绞健Ｒ韵率切枰⒁獾闹饕马?xiàng)：

• “項(xiàng)目瀏覽器”選項(xiàng)卡：顯示Polyspace項(xiàng)目的結(jié)構(gòu)

• 結(jié)果列表選項(xiàng)卡：MISRA違規(guī)列表

• 運(yùn)行錯(cuò)誤查找器按鈕：檢查代碼是否符合MISRA

• 配置窗口：無(wú)需在此處進(jìn)行任何更改

• 儀表板：顯示錯(cuò)誤分析的進(jìn)度

• 輸出摘要：分析的摘要結(jié)果

要進(jìn)行實(shí)驗(yàn)：

• 該實(shí)驗(yàn)室的代碼應(yīng)該看起來(lái)有些熟悉。它是擴(kuò)展的卡爾曼濾波器。

• 打開(kāi).psprj文件后，單擊窗口頂部的“運(yùn)行錯(cuò)誤查找器”。

• 分析將運(yùn)行，您可以在“輸出摘要”選項(xiàng)卡中觀察進(jìn)度。分析時(shí)間相對(duì)較短（似乎需要3-4分鐘才能得出平均值）

• “結(jié)果列表”選項(xiàng)卡將顯示所有違反MISRA的行為

• 您可以單擊不同的違例，這將在“源”選項(xiàng)卡中打開(kāi)代碼。

• 如果右鍵單擊違規(guī)，則可以選擇在編輯器中打開(kāi)代碼：“打開(kāi)編輯器”。然后，您可以編輯并保存代碼以解決違規(guī)問(wèn)題。

• 在“源”選項(xiàng)卡中，您也可以滾動(dòng)查看代碼以查看有違規(guī)的地方。違規(guī)行為用紫色三角形標(biāo)記，單擊三角形將突出顯示違規(guī)行為。

• 在“結(jié)果詳細(xì)信息”窗口中，如果單擊問(wèn)號(hào)，則會(huì)打開(kāi)“上下文幫助”窗口。上下文幫助列出了所有MISRA C ++規(guī)則。通讀規(guī)則有助于理解代碼的問(wèn)題。

每次您想查看代碼是否固定時(shí)，都需要再次單擊“運(yùn)行錯(cuò)誤查找器”。如果您想一次僅對(duì)一個(gè)文件運(yùn)行分析，請(qǐng)轉(zhuǎn)到：
“項(xiàng)目瀏覽器”選項(xiàng)卡->項(xiàng)目源文件-> src原始

然后右鍵單擊要從分析中排除的文件，然后選擇“排除文件”。您會(huì)注意到，“ main.cpp”已從分析中排除，因此您只需關(guān)注卡爾曼過(guò)濾器代碼即可。

06. Software Safety Life-cycle/

Software Safety Requirements, Architecture, Testing and Integration

軟件V圖

在視頻中，我們簡(jiǎn)化了軟件安全性V模型，以顯示軟件安全性生命周期涉及與功能安全性分析其他級(jí)別相同的四個(gè)步驟：

1. 規(guī)定安全要求

2. 設(shè)計(jì)架構(gòu)并將需求分配給架構(gòu)

3. 軟件測(cè)試

4. 軟件整合

這是軟件安全生命周期的稍微詳細(xì)的版本：

ISO 26262軟件V模型

開(kāi)發(fā)軟件體系結(jié)構(gòu)應(yīng)同時(shí)考慮安全性和非安全性要求。軟件安全要求和軟件產(chǎn)品要求不能分為兩種不同的體系結(jié)構(gòu)；軟件體系結(jié)構(gòu)將產(chǎn)品要求和安全要求混合在一起。
架構(gòu)設(shè)計(jì)可能涉及多個(gè)微控制器或ECU。因此，需要指定軟件接口，數(shù)據(jù)路徑，過(guò)程序列和定時(shí)行為。

軟件單元

通常將軟件體系結(jié)構(gòu)進(jìn)一步細(xì)化為稱(chēng)為單元的較小部分。因此，技術(shù)安全要求導(dǎo)致了軟件安全要求，這些要求被進(jìn)一步細(xì)化為軟件安全單元要求。然后，單元需求將導(dǎo)致體系結(jié)構(gòu)的進(jìn)一步完善。

測(cè)試規(guī)格

在V模型的右側(cè)，從安全要求中得出測(cè)試規(guī)格和測(cè)試用例。請(qǐng)記住，V模型具有層次結(jié)構(gòu)級(jí)別。當(dāng)您升級(jí)具有更高系統(tǒng)級(jí)別的V模型集成軟件時(shí)，每個(gè)階段都需要進(jìn)行自己的測(cè)試。

07. Software Safety Requirements Lane Departure Warning

Software Safety Requirements - Lane Departure Warning Amplitude Malfunction

就本模塊而言，我們不希望您得出軟件安全要求。但是下面的示例應(yīng)該使您了解如何從技術(shù)安全要求中得出軟件安全要求。這些示例還顯示了技術(shù)要求和軟件要求之間的主要區(qū)別；軟件要求比技術(shù)要求更為具體。軟件要求指定了變量名稱(chēng)，信號(hào)路徑以及軟件協(xié)議和機(jī)制。軟件工程師應(yīng)該能夠根據(jù)軟件需求和軟件體系結(jié)構(gòu)編寫(xiě)程序。

我們將向您展示從技術(shù)安全要求中衍生出來(lái)的軟件安全要求的示例。首先，我們將向您展示精致的體系結(jié)構(gòu)，然后解釋我們添加的所有新元素：

Software Architecture Diagram

Software Safety Requirements Derived from Technical Safety Requirement 01

讓我們一次查看一下我們的技術(shù)安全要求，并得出軟件安全要求。當(dāng)我們解釋新功能時(shí)，您可能需要參考此圖。

這是我們的第一個(gè)技術(shù)安全要求：

ID	Technical Safety Requirement	ASIL	Fault Tolerant Time Interval	Allocation to Architecture	Safe State
TechnicalSafetyRequirement_01	The LDW safety component shall ensure that the amplitude of the LDW_Torque_Request sent to the Final Electronic Power Steering Torque component is below Max_Torque_Amplitude	C	50ms	LDW Safety	LDW torque output is set to zero

我們將把LDW安全組件分為三個(gè)部分。

第一個(gè)塊將從基本/主車(chē)道輔助功能組件獲得扭矩請(qǐng)求。該第一塊將進(jìn)行所需的任何預(yù)處理。然后，該塊將結(jié)果發(fā)送到扭矩限制器塊，該塊將檢查扭矩是否超出允許的最大幅度。如果達(dá)到極限，扭矩請(qǐng)求將設(shè)置為零。最后，我們將添加第三個(gè)塊，該塊準(zhǔn)備好將信號(hào)傳輸?shù)阶罱K扭矩生成器。

這是新的軟件安全要求：

將這些新軟件安全要求與新系統(tǒng)架構(gòu)圖進(jìn)行比較。

讓我們看一下第二項(xiàng)技術(shù)安全要求。

可以使用稱(chēng)為End2End（E2E）協(xié)議的協(xié)議來(lái)解決此要求。在本課結(jié)束時(shí)，我們將在標(biāo)有“免受干擾的自由-通信”的部分中討論該協(xié)議。

以下是從技術(shù)安全要求02衍生的軟件安全要求：

Software Safety Requirements Derived from Technical Safety Requirement 03

為了解決停用要求，我們將添加一個(gè)錯(cuò)誤檢測(cè)塊，作為對(duì)關(guān)閉車(chē)道保持系統(tǒng)的額外檢查。每個(gè)軟件模塊將輸出有關(guān)是否發(fā)生錯(cuò)誤的信號(hào)。該信號(hào)將與實(shí)際扭矩請(qǐng)求一起發(fā)送到“ Final EPS Torque Generator”塊。

這是新的軟件安全要求：

Software Safety Requirements Derived from Technical Safety Requirement 04

Our fourth technical safety requirement discusses sending an error signal to the car display ECU:

這是技術(shù)安全要求編號(hào)04的軟件安全要求：

Software Safety Requirements Derived from Technical Safety Requirement 05

以下是內(nèi)存測(cè)試的典型軟件安全要求：

Final Project

在最終項(xiàng)目中，您將需要記錄此頁(yè)面上顯示的信息。該信息將包含在“軟件安全要求和體系結(jié)構(gòu)幫助”文檔中。

08. Other Sources of Software Safety Requirements

至此，您已經(jīng)擁有完成最終項(xiàng)目所需的所有信息。本課程的其余部分重點(diǎn)介紹軟件安全要求的一些最重要來(lái)源。
許多軟件安全要求直接來(lái)自于技術(shù)安全要求。但是，除了技術(shù)安全要求之外，還有其他軟件安全要求的來(lái)源：

• 確保軟件健壯性和質(zhì)量的要求

• 確保不受干擾的要求

下圖顯示了軟件安全要求的三個(gè)來(lái)源：

如果不是汽車(chē)功能安全方面的頭號(hào)錯(cuò)誤源，那么軟件錯(cuò)誤是一個(gè)非常重要的錯(cuò)誤源。您對(duì)安全性至關(guān)重要的軟件了解得越多，您的軟件安全性要求就會(huì)越好。

軟件魯棒性和質(zhì)量

09. Freedom from Interference - Spatial

Mechanisms for Ensuring Freedom From Spatial Interference/空間

有一些通用的機(jī)制可確保不受空間干擾，例如內(nèi)存保護(hù)單元和相關(guān)數(shù)據(jù)的雙重存儲(chǔ)。

MPU是一種預(yù)防方法，因?yàn)樗梢宰柚乖卦L(fǎng)問(wèn)不應(yīng)訪(fǎng)問(wèn)的內(nèi)存。可以對(duì)MPU進(jìn)行編程，以設(shè)置軟件元素之間的正確讀取，寫(xiě)入和執(zhí)行權(quán)限。

相關(guān)數(shù)據(jù)的雙重存儲(chǔ)（例如帶2的補(bǔ)碼）是一種檢測(cè)方法。使用2的補(bǔ)碼，您可以檢測(cè)到數(shù)據(jù)已更改并且不再有效。但是您將無(wú)法再使用數(shù)據(jù)。

其他防止內(nèi)存干擾的機(jī)制包括：

• 諸如CRC之類(lèi)的冗余檢查，以確保數(shù)據(jù)不會(huì)意外更改。

• 具有存儲(chǔ)器錯(cuò)誤檢測(cè)和糾正功能的微控制器

• 允許軟件單元擁有自己的虛擬內(nèi)存空間的操作系統(tǒng)

提到的一種機(jī)制是存儲(chǔ) 的 2補(bǔ)碼 安全相關(guān)數(shù)據(jù) 。2的補(bǔ)碼是表示二進(jìn)制整數(shù)中的負(fù)整數(shù)的一種方式。

CRC （循環(huán)冗余校驗(yàn)）是，以檢查是否在數(shù)據(jù)傳輸期間已經(jīng)改變的一種方式。它們的工作方式是在數(shù)據(jù)上添加一個(gè)值，然后確保該值在傳輸過(guò)程中沒(méi)有改變。

請(qǐng)注意，要解決死鎖，禁用將阻止進(jìn)程搶占的OS中斷效率低下，并且可能會(huì)損害總體響應(yīng)時(shí)間和系統(tǒng)延遲。替代方案是由實(shí)時(shí)操作系統(tǒng)（RTOS）提供的功能，它是 優(yōu)先級(jí)上限 。

10. Freedom from Interference - Temporal/時(shí)間干擾

解決死鎖

有多種避免死鎖的算法，包括稱(chēng)為禁用中斷的措施。啟用中斷后，一個(gè)進(jìn)程可以中斷另一進(jìn)程。因此，在我們的示例中，線(xiàn)程1需要資源B并試圖獲取A。但是線(xiàn)程2繼續(xù)中斷線(xiàn)程1來(lái)獲取A。禁用中斷將允許線(xiàn)程一獲取A。

免于時(shí)間干擾的機(jī)制

避免時(shí)間干擾的機(jī)制包括循環(huán)執(zhí)行調(diào)度，基于固定優(yōu)先級(jí)的調(diào)度，時(shí)間觸發(fā)的調(diào)度，處理器執(zhí)行時(shí)間的監(jiān)視，程序序列監(jiān)視和到達(dá)速率監(jiān)視。

11. Freedom from Interference - Temporal Part 2

13. Freedom from Interference - Communication/通信干擾

通信干擾的常見(jiàn)原因

導(dǎo)致通信故障的原因很多。這些原因?qū)⒃谲浖踩治鲋谢蛴袝r(shí)在技術(shù)安全分析中進(jìn)行分析：

• 信息重復(fù)

• 信息丟失

• 信息延遲

• 信息插入

• 偽裝或不正確的信息尋址

• 信息順序錯(cuò)誤

• 信息腐敗

確保不受通訊干擾的其他機(jī)制

有一些避免通信干擾的措施。這些機(jī)制可用于定義有助于避免通信故障的軟件安全要求。確保不受干擾的機(jī)制包括：

• 信息回送

• 信息確認(rèn)

• I / O引腳的適當(dāng)配置

• 優(yōu)先公交仲裁

• 端到端協(xié)議

例如，一項(xiàng)技術(shù)安全要求是“應(yīng)確保“ LDW_Torque_Request”信號(hào)的數(shù)據(jù)傳輸?shù)挠行院屯暾浴薄Ｔ摷夹g(shù)安全要求可以細(xì)化為軟件安全要求，即數(shù)據(jù)應(yīng)由End2End機(jī)制保護(hù)。

端到端保護(hù)協(xié)議的示例規(guī)范

端到端協(xié)議示例

該機(jī)制涉及在傳輸數(shù)據(jù)時(shí)添加兩個(gè)額外的數(shù)據(jù)字節(jié)，稱(chēng)為CRC（循環(huán)冗余校驗(yàn)）和SQC（序列計(jì)數(shù)器）。要計(jì)算CRC，您可以對(duì)要傳輸?shù)臄?shù)據(jù)運(yùn)行數(shù)學(xué)公式。然后，您可以在傳輸之前將CRC結(jié)果附加到數(shù)據(jù)上。接收到數(shù)據(jù)后，將再次對(duì)數(shù)據(jù)集運(yùn)行數(shù)學(xué)公式。數(shù)據(jù)附帶的CRC和接收端計(jì)算出的CRC應(yīng)該相同；否則，數(shù)據(jù)數(shù)據(jù)可能已在傳輸中損壞。
SQC只是一個(gè)與數(shù)據(jù)一起發(fā)送的計(jì)數(shù)器。這樣，接收者可以確保消息沒(méi)有丟失。

車(chē)道偏離警告（LDW）的E2E軟件安全要求

在“軟件安全要求車(chē)道偏離警告”的概念中，我們已經(jīng)討論過(guò)可以通過(guò)E2E協(xié)議處理技術(shù)安全要求02。讓我們更深入地了解此技術(shù)要求和相關(guān)的軟件安全要求。這是技術(shù)安全要求：

這也是軟件安全體系結(jié)構(gòu)

System Software Architecture

可以看到我們?yōu)?LDW Safety 組件的兩個(gè)信號(hào)增加了E2E Calculation. 我們需要確保當(dāng)’Processed_LDW_Torque_Request’信號(hào)傳送到“ Final EPS Torque Generator”時(shí)沒(méi)有損壞。E2E Calculation組件將對(duì)要傳輸?shù)男盘?hào)進(jìn)行計(jì)算，并將計(jì)算結(jié)果附加到信號(hào)上。

然后， "Final EPS Torque Generator"組件將運(yùn)行相同的計(jì)算，并比較傳輸前后的結(jié)果。如果結(jié)果相同，則可以假定數(shù)據(jù)保持不變。

當(dāng)“ LDW_Safety_Activation”組件將其信號(hào)發(fā)送到“ Final EPS Torque Generator”時(shí)，我們將使用相同的機(jī)制。

因此，這里再次是軟件安全要求：

14. System Architecture Safety Design Patterns

E-GAS 從何而來(lái)

電子氣設(shè)計(jì)模式最初來(lái)自電傳加速驅(qū)動(dòng)系統(tǒng)。最初，汽車(chē)上的油門(mén)踏板直接與發(fā)動(dòng)機(jī)的節(jié)氣門(mén)機(jī)械連接。節(jié)氣門(mén)調(diào)節(jié)進(jìn)入發(fā)動(dòng)機(jī)的空氣量。

在現(xiàn)代汽車(chē)中，油門(mén)踏板是一個(gè)電子傳感器。踩下油門(mén)踏板時(shí)，軟件會(huì)解釋您要加速多少。然后軟件打開(kāi)或關(guān)閉節(jié)氣門(mén)。開(kāi)發(fā)了E-gas軟件模式來(lái)監(jiān)視線(xiàn)控加速系統(tǒng)中的故障。如果汽油發(fā)動(dòng)機(jī)系統(tǒng)出現(xiàn)故障，則2級(jí)或3級(jí)監(jiān)控功

軟件分區(qū)和安全監(jiān)控

安全監(jiān)控和軟件分區(qū)是通常用設(shè)計(jì)模式解決的軟件機(jī)制。

對(duì)于安全監(jiān)控，有一些特定的模式，例如已說(shuō)明的E-GAS概念。對(duì)于軟件分區(qū)，一種模式是使用稱(chēng)為MPU的硬件功能以及雙數(shù)據(jù)存儲(chǔ)。

15. Lesson Summary

從項(xiàng)目定義到軟件和硬件要求的概述

審核編輯 ：李倩