02. V model

Hardware and Software Product Development Life-Cycle

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

Summary of ISO 26262 V Model

每個V代表的總體思想保持不變；首先，您指定安全要求。然后，您將這些需求分配給系統體系結構。最后，您進行測試，集成和驗證。每個V模型過程都與我們在第一課中討論的過程相同。

但是，在硬件和軟件方面還需要采取額外的措施。對于硬件，V模型包括有關硬件體系結構指標和評估隨機硬件故障的部分。這是硬件V模型的更詳細視圖：

在軟件方面，有一個體系結構設計部分以及一個單元設計部分：

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

Architectural Design vs Unit Design/結構和單元設計

軟件體系結構設計是軟件組件的更高層次的視圖。例如，這可能是我們的車道輔助示例中的攝像機ECU。

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

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

Functional Safety Bird's Eye View

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

03. Hardware Failure Metrics

請注意，體系結構指標具有獨立于實現的值，并表示為費率。硬件故障概率度量（PMHF）的絕對單位表示為每10 ^ 9小時的故障數。因此，PMHF本身不是體系結構指標，但與硬件故障指標的討論有關。

硅的磨損是系統性故障，而不是隨機的硬件故障也是有爭議的，因此它可能不被視為隨機硬件故障指標的一部分。

More Details about Hardware Failure Metrics

本質上，這些度量標準著眼于安全機制所涵蓋的硬件故障百分比。安全機制是一些功能，可以在發(fā)生故障時保持車輛安全或檢測到已發(fā)生故障。這意味著在一個安全的系統中，大多數硬件故障都會被檢測到。

例子：如果RAM因紫外線輻射引起位翻轉而發(fā)生故障，則安全機制將需要修復位翻轉，將系統置于安全狀態(tài)，和/或警告驅動程序發(fā)生故障。該標準認為硬件故障是不可避免的。但是，如果它們將要發(fā)生，那么理想情況下，它們不應導致安全問題。ASIL D的單點故障指標大于99％，而ASIL B僅大于90％。換句話說，對于ASIL D，對于特定的安全目標，應該檢測到99％的單點故障或者是安全的。

要計算這些指標，您必須弄清楚哪些硬件故障會導致危險情況，哪些故障不會導致危險情況。該標準實際上將硬件故障分為六類。

Categories of Faults/故障類別

要計算硬件故障指標，您需要將故障分類為六個類別之一。我們將在此處列出它們以供參考，盡管在本課程中我們實際上不會計算硬件故障指標。

單點故障-沒有安全機制來檢測故障的元素中的故障。故障還會導致違反安全目標。例如，沒有安全機制可糾正該錯誤的RAM故障將違反安全目標。

殘留故障-元素具有檢測某些類型故障的安全機制；但是，會出現未設計該機制進行檢測的故障，并且該故障還會導致違反安全目標。例如，RAM可能具有ECC（糾錯碼）機制來修復位翻轉；但是，由于短路而導致發(fā)生不同的故障，并且RAM沒有用于短路的安全機制。

潛在的多點故障-安全機制和駕駛員無法檢測到的多點故障。

感知到的多點故障-駕駛員檢測到的多點故障，因為該故障導致車輛功能受限。例如，駕駛員注意到減少的剎車響應，或者在沒有響應的情況下激活大燈（它們沒有打開）。

檢測到的多點故障-安全機制檢測到的多點故障并使車輛進入安全狀態(tài)

安全故障-不會導致違反安全目標的故障

多點故障的示例可能涉及RAM和ECC(糾錯碼error correction code) 機制。ECC糾正位翻轉。如果由于位翻轉而導致RAM包含故障，則ECC將糾正該翻轉。如果ECC由于軟件錯誤而失敗，則RAM仍將正常工作。如果發(fā)生位翻轉并且ECC失敗，則將存在多點故障，因為將不糾正位翻轉。RAM和ECC都將失敗。

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

Measuring Faults/測量故障

您將如何實際測量故障和失效率？您可以：

• 進行現場測試以測量給定時間內的故障數量

• 使用來自等效或類似系統的現有數據

• 供應商也應提供用于計算這些指標的數據。

請注意，ISO 26262未指定隨機硬件故障的目標。有一個針對硬件故障的概率度量（PMHF），它著眼于每個安全目標的危險，未檢測到的硬件故障。ISO 26262建議僅在沒有數據支持目標的情況下使用PMHF值。這 是一篇有關PMHF和隨機硬件故障的有趣論文。

故障的來源和類型

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

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

04. Programming Languages

Notes about Programming Languages

任何編程語言都會有長處和短處。C ++的一個優(yōu)勢是能夠編寫具有許多輸入輸出操作的高速軟件的能力。另一方面，C ++允許您將浮點數存儲在布爾變量中。而且C ++在運行時錯誤檢查方面沒有提供太多幫助。

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

Software Tools & Software Tool Confidence Level

汽車軟件工程師使用各種工具來幫助開發(fā)軟件。

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

功能安全標準要求您對軟件工具進行資格驗證，以確保它們適合于安全關鍵型應用程序；使用自動化代碼生成和代碼測試的軟件工具變得越來越普遍。例如，如果測試工具有問題，則可能無法檢測到代碼錯誤。

ISO 26262描述了一種度量標準，用于衡量您對工具的信心。該度量標準稱為工具置信度或TCL。

評估置信度需要考慮以下兩點：

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

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

然后，您可以使用TI和TD度量標準來計算工具的置信度級別.ASIL較高的軟件塊需要TCL1，這是最高置信度。TCL3是最低的置信度等級。

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

05. MISRA C++ Lab

MISRA Lab

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

Polyspace Use Case

另外，在您開始實驗之前，請查看此用例，以了解一家汽車公司如何使用Polyspace改善其代碼質量：鏈接至用例 。

安裝MATLAB Polyspace

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

1. 如果您還沒有MathWorks帳戶，請 創(chuàng)建一個新帳戶 。

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

設置實驗室

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

在Windows計算機上：

啟動Polyspace

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

1. 轉到應用程序文件夾

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

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

4. 右鍵單擊“多邊形”，然后選擇“打開”

打開項目文件并運行錯誤查找器

打開項目文件 fileroot/Polyspace/kalmanFilterProject_original.psprj在“多邊形”窗口中 。
單擊“運行錯誤查找器”。MISRA C ++結果應該自動出現。
在分析過程中，您可能會看到一個良性彈出錯誤。您可以單擊以結束錯誤的后臺處理，分析將正常完成。此錯誤不會影響MISRA分析。此錯誤通常不會在Mac上出現，但可能會在Linux和Windows系統上出現。

完成實驗

軟件概述

首次打開多邊形時，該程序將概述軟件的工作方式。以下是需要注意的主要事項：

• “項目瀏覽器”選項卡：顯示Polyspace項目的結構

• 結果列表選項卡：MISRA違規(guī)列表

• 運行錯誤查找器按鈕：檢查代碼是否符合MISRA

• 配置窗口：無需在此處進行任何更改

• 儀表板：顯示錯誤分析的進度

• 輸出摘要：分析的摘要結果

要進行實驗：

• 該實驗室的代碼應該看起來有些熟悉。它是擴展的卡爾曼濾波器。

• 打開.psprj文件后，單擊窗口頂部的“運行錯誤查找器”。

• 分析將運行，您可以在“輸出摘要”選項卡中觀察進度。分析時間相對較短（似乎需要3-4分鐘才能得出平均值）

• “結果列表”選項卡將顯示所有違反MISRA的行為

• 您可以單擊不同的違例，這將在“源”選項卡中打開代碼。

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

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

• 在“結果詳細信息”窗口中，如果單擊問號，則會打開“上下文幫助”窗口。上下文幫助列出了所有MISRA C ++規(guī)則。通讀規(guī)則有助于理解代碼的問題。

每次您想查看代碼是否固定時，都需要再次單擊“運行錯誤查找器”。如果您想一次僅對一個文件運行分析，請轉到：
“項目瀏覽器”選項卡->項目源文件-> src原始

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

06. Software Safety Life-cycle/

Software Safety Requirements, Architecture, Testing and Integration

軟件V圖

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

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

2. 設計架構并將需求分配給架構

3. 軟件測試

4. 軟件整合

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

ISO 26262軟件V模型

開發(fā)軟件體系結構應同時考慮安全性和非安全性要求。軟件安全要求和軟件產品要求不能分為兩種不同的體系結構；軟件體系結構將產品要求和安全要求混合在一起。
架構設計可能涉及多個微控制器或ECU。因此，需要指定軟件接口，數據路徑，過程序列和定時行為。

軟件單元

通常將軟件體系結構進一步細化為稱為單元的較小部分。因此，技術安全要求導致了軟件安全要求，這些要求被進一步細化為軟件安全單元要求。然后，單元需求將導致體系結構的進一步完善。

測試規(guī)格

在V模型的右側，從安全要求中得出測試規(guī)格和測試用例。請記住，V模型具有層次結構級別。當您升級具有更高系統級別的V模型集成軟件時，每個階段都需要進行自己的測試。

07. Software Safety Requirements Lane Departure Warning

Software Safety Requirements - Lane Departure Warning Amplitude Malfunction

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

我們將向您展示從技術安全要求中衍生出來的軟件安全要求的示例。首先，我們將向您展示精致的體系結構，然后解釋我們添加的所有新元素：

Software Architecture Diagram

Software Safety Requirements Derived from Technical Safety Requirement 01

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

這是我們的第一個技術安全要求：

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安全組件分為三個部分。

第一個塊將從基本/主車道輔助功能組件獲得扭矩請求。該第一塊將進行所需的任何預處理。然后，該塊將結果發(fā)送到扭矩限制器塊，該塊將檢查扭矩是否超出允許的最大幅度。如果達到極限，扭矩請求將設置為零。最后，我們將添加第三個塊，該塊準備好將信號傳輸到最終扭矩生成器。

這是新的軟件安全要求：

將這些新軟件安全要求與新系統架構圖進行比較。

讓我們看一下第二項技術安全要求。

可以使用稱為End2End（E2E）協議的協議來解決此要求。在本課結束時，我們將在標有“免受干擾的自由-通信”的部分中討論該協議。

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

Software Safety Requirements Derived from Technical Safety Requirement 03

為了解決停用要求，我們將添加一個錯誤檢測塊，作為對關閉車道保持系統的額外檢查。每個軟件模塊將輸出有關是否發(fā)生錯誤的信號。該信號將與實際扭矩請求一起發(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:

這是技術安全要求編號04的軟件安全要求：

Software Safety Requirements Derived from Technical Safety Requirement 05

以下是內存測試的典型軟件安全要求：

Final Project

在最終項目中，您將需要記錄此頁面上顯示的信息。該信息將包含在“軟件安全要求和體系結構幫助”文檔中。

08. Other Sources of Software Safety Requirements

至此，您已經擁有完成最終項目所需的所有信息。本課程的其余部分重點介紹軟件安全要求的一些最重要來源。
許多軟件安全要求直接來自于技術安全要求。但是，除了技術安全要求之外，還有其他軟件安全要求的來源：

• 確保軟件健壯性和質量的要求

• 確保不受干擾的要求

下圖顯示了軟件安全要求的三個來源：

如果不是汽車功能安全方面的頭號錯誤源，那么軟件錯誤是一個非常重要的錯誤源。您對安全性至關重要的軟件了解得越多，您的軟件安全性要求就會越好。

軟件魯棒性和質量

09. Freedom from Interference - Spatial

Mechanisms for Ensuring Freedom From Spatial Interference/空間

有一些通用的機制可確保不受空間干擾，例如內存保護單元和相關數據的雙重存儲。

MPU是一種預防方法，因為它可以阻止元素訪問不應訪問的內存?？梢詫PU進行編程，以設置軟件元素之間的正確讀取，寫入和執(zhí)行權限。

相關數據的雙重存儲（例如帶2的補碼）是一種檢測方法。使用2的補碼，您可以檢測到數據已更改并且不再有效。但是您將無法再使用數據。

其他防止內存干擾的機制包括：

• 諸如CRC之類的冗余檢查，以確保數據不會意外更改。

• 具有存儲器錯誤檢測和糾正功能的微控制器

• 允許軟件單元擁有自己的虛擬內存空間的操作系統

提到的一種機制是存儲 的 2補碼 安全相關數據 。2的補碼是表示二進制整數中的負整數的一種方式。

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

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

10. Freedom from Interference - Temporal/時間干擾

解決死鎖

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

免于時間干擾的機制

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

11. Freedom from Interference - Temporal Part 2

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

通信干擾的常見原因

導致通信故障的原因很多。這些原因將在軟件安全分析中或有時在技術安全分析中進行分析：

• 信息重復

• 信息丟失

• 信息延遲

• 信息插入

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

• 信息順序錯誤

• 信息腐敗

確保不受通訊干擾的其他機制

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

• 信息回送

• 信息確認

• I / O引腳的適當配置

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

• 端到端協議

例如，一項技術安全要求是“應確?！?LDW_Torque_Request”信號的數據傳輸的有效性和完整性”。該技術安全要求可以細化為軟件安全要求，即數據應由End2End機制保護。

端到端保護協議的示例規(guī)范

端到端協議示例

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

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

在“軟件安全要求車道偏離警告”的概念中，我們已經討論過可以通過E2E協議處理技術安全要求02。讓我們更深入地了解此技術要求和相關的軟件安全要求。這是技術安全要求：

這也是軟件安全體系結構

System Software Architecture

可以看到我們?yōu)?LDW Safety 組件的兩個信號增加了E2E Calculation. 我們需要確保當’Processed_LDW_Torque_Request’信號傳送到“ Final EPS Torque Generator”時沒有損壞。E2E Calculation組件將對要傳輸的信號進行計算，并將計算結果附加到信號上。

然后， "Final EPS Torque Generator"組件將運行相同的計算，并比較傳輸前后的結果。如果結果相同，則可以假定數據保持不變。

當“ LDW_Safety_Activation”組件將其信號發(fā)送到“ Final EPS Torque Generator”時，我們將使用相同的機制。

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

14. System Architecture Safety Design Patterns

E-GAS 從何而來

電子氣設計模式最初來自電傳加速驅動系統。最初，汽車上的油門踏板直接與發(fā)動機的節(jié)氣門機械連接。節(jié)氣門調節(jié)進入發(fā)動機的空氣量。

在現代汽車中，油門踏板是一個電子傳感器。踩下油門踏板時，軟件會解釋您要加速多少。然后軟件打開或關閉節(jié)氣門。開發(fā)了E-gas軟件模式來監(jiān)視線控加速系統中的故障。如果汽油發(fā)動機系統出現故障，則2級或3級監(jiān)控功

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

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

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

15. Lesson Summary

從項目定義到軟件和硬件要求的概述

審核編輯 ：李倩