02. V model

Hardware and Software Product Development Life-Cycle

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

Summary of ISO 26262 V Model

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

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

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

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

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

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

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

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

Functional Safety Bird's Eye View

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

03. Hardware Failure Metrics

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

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

More Details about Hardware Failure Metrics

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

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

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

Categories of Faults/故障類別

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

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

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

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

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

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

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

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

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

Measuring Faults/測量故障

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

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

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

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

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

故障的來源和類型

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

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

04. Programming Languages

Notes about Programming Languages

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

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

Software Tools & Software Tool Confidence Level

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

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

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

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

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

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

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

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

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

05. MISRA C++ Lab

MISRA Lab

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

Polyspace Use Case

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

安裝MATLAB Polyspace

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

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

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

設(shè)置實驗室

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

在Windows計算機上：

啟動Polyspace

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

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

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

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

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

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

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

完成實驗

軟件概述

首次打開多邊形時，該程序?qū)⒏攀鲕浖墓ぷ鞣绞?。以下是需要注意的主要事項?/p>

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

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

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

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

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

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

要進(jìn)行實驗：

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

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

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

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

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

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

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

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

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

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

06. Software Safety Life-cycle/

Software Safety Requirements, Architecture, Testing and Integration

軟件V圖

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

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

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

3. 軟件測試

4. 軟件整合

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

ISO 26262軟件V模型

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

軟件單元

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

測試規(guī)格

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

07. Software Safety Requirements Lane Departure Warning

Software Safety Requirements - Lane Departure Warning Amplitude Malfunction

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

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

Software Architecture Diagram

Software Safety Requirements Derived from Technical Safety Requirement 01

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

這是我們的第一個技術(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安全組件分為三個部分。

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

這是新的軟件安全要求：

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

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

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

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

Software Safety Requirements Derived from Technical Safety Requirement 03

為了解決停用要求，我們將添加一個錯誤檢測塊，作為對關(guān)閉車道保持系統(tǒng)的額外檢查。每個軟件模塊將輸出有關(guān)是否發(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:

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

Software Safety Requirements Derived from Technical Safety Requirement 05

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

Final Project

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

08. Other Sources of Software Safety Requirements

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

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

• 確保不受干擾的要求

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

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

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

09. Freedom from Interference - Spatial

Mechanisms for Ensuring Freedom From Spatial Interference/空間

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

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

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

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

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

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

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

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

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

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

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

解決死鎖

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

免于時間干擾的機制

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

11. Freedom from Interference - Temporal Part 2

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

通信干擾的常見原因

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

• 信息重復(fù)

• 信息丟失

• 信息延遲

• 信息插入

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

• 信息順序錯誤

• 信息腐敗

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

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

• 信息回送

• 信息確認(rèn)

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

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

• 端到端協(xié)議

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

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

端到端協(xié)議示例

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

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

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

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

System Software Architecture

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

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

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

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

14. System Architecture Safety Design Patterns

E-GAS 從何而來

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

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

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

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

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

15. Lesson Summary

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

審核編輯 ：李倩