今天我們先聊硬件安全需求，硬件安全設計以及硬件安全機制相關的內容，硬件架構度量及隨機失效的評估，我們下一篇單獨聊。 ? 正式聊之前，為便于理解，先說明以下幾點:

1

功能安全研究范圍為電子電氣系統，即E/E系統，所以這里的硬件特指控制器硬件，包括控制器I/O接口，控制器芯片等，非傳統的機械硬件。

2

硬件同樣存在系統失效，即由于人為設計疏忽導致的失效，需要對設計過程進行相應約束，包括開發流程，方法，測試驗證等，保證硬件安全。

3

ISO 26262中基于概率論的定量危害分析僅限適用于硬件部分，因為只有硬件存在隨機失效，并符合概率分布原理。

4

硬件開發和系統，軟件開發一樣，都基于V模型，但有兩個過程區分于傳統V模型開發流程，即概率論定量分析，包括硬件架構度量和隨機硬件失效的評估。

01

什么是硬件安全需求？

功能安全硬件開發始于需求，即硬件安全需求(Hardware Safety Requirement, HWSR)，而HWSR源于分配至硬件組件的TSR，是硬件相關的TSR在硬件層面的進一步細化。

HWSR包括哪些內容呢？一般來講:?

硬件安全需求HWSR?= 安全機制無關的硬件安全需求 + 硬件安全機制?

安全機制無關的硬件安全需求包括:?

1

硬件架構度量及隨機硬件失效目標值要求，一般根據可以直接查表即可確定。

例如:?SPFM，LFM，PMHF等，這部分會在硬件架構度量及失效評估中闡述。

2

為避免特定行為的硬件安全要求。

例如:一個特定傳感器不應有不穩定輸出。

3

分配給硬件的預期功能要求。

例如:?控制器必須能夠外部reset。

4

定義線束或接插件的設計措施的要求。

例如:?線束或插件最大電流需求。 ?

硬件安全機制包括:

1

針對內部硬件要素(包括傳感器，控制器和執行器)失效的安全機制。

例如:?看門狗，比較器，雙核鎖步 (dual-core lockstep)，傳感及執行器診斷等。

2

針對外部相關要素失效的容忍能力的安全機制。

例如:?ECU 的輸入開路時，要求 ECU 應具備的功能表現。

3

針對內外部要素失效對應安全機制的響應特性需求。

例如:?安全機制中定義的硬件元器件的故障響應時間要符合ISO 26262-4:2018, 6.4.2中要求的故障容錯時間間隔以及多點故障探測時間間隔。

怎么從TSR得到HSR呢？

HWSR屬于由硬件相關的TSR細化得到硬件層面安全需求，只要在系統開發階段有效識別出硬件相關的TSR，HWSR導出相對比較容易。 ? 具體來說，根據硬件相關TSR，對其進行安全分析或直接根據經驗，分別針對組成HWSR的三個部分進行分析：

為避免硬件內部失效措施

為避免外部相關失效對應的內部措施

為避免硬件隨機失效的概率度量要求

將其作為HWSR即可，具體見下圖:

02

硬件安全設計

硬件安全設計主要包括兩個方面:

硬件安全架構設計

硬件安全詳細設計

硬件安全架構和詳細設計均基于HWSR，硬件安全架構的設計旨在描述硬件組件以及其彼此的相互關系，更重要的是將硬件架構相關的HWSR，尤其是安全機制應用于硬件架構，為后續硬件詳細設計提供基礎。

硬件安全機制是硬件安全設計中最核心的內容，我們會在第三部分單獨闡述。除此之外，ISO 26262-5:2018第7部分還對硬件安全架構和詳細實現設計提出了相關約束，主要包括:

對硬件安全架構設計而言:

硬件架構應能夠承載HWSR。

HWSR應該被分配至硬件架構中的組件。

不同或非ASIL等級硬件組件開發需滿足以下原則之一:

─ 按最高ASIL等級

─ 要素共存FFI

對硬件安全要求和實施之間的可追溯性。

為避免系統失效, 硬件架構應具有下述特性:

─? 模塊化; ─ ?適當的粒度水平;及

─??簡單性。

在硬件架構設計時，應考慮安全相關硬件組件失效的非功能性原因，例如: 溫度、振動、水、灰塵、電磁干擾、來自硬件架構的其他硬件組件或其所在環境的串擾。

對硬件詳細實現設計而言:

為了避免常見的設計缺陷, 可運用相關的經驗總結。

在硬件詳細設計時, 應考慮安全相關硬件元器件失效的非功能性原因, 可包括以下的影響因素:溫度、振動、水、灰塵、電磁干擾、噪聲因素、來自硬件組件的其他硬件元器件或其所在環境的串擾。

硬件詳細設計中, 硬件元器件的運行條件應符合它們的環境和運行限制規范。

應考慮魯棒性設計原則。

03

硬件安全機制

硬件相關安全機制是組成HWSR最重要組成部分，是硬件安全設計最重要的體現，也是功能安全ISO 26262中最晦澀難懂的內容之一。

ISO?26262-5:2018附錄D中列出了控制器硬件可能存在的故障，對應的安全措施及覆蓋率，為后續硬件概率度量提供了基礎，基本上涵蓋了硬件通用的安全機制，強烈建議多看幾遍。

一般來講，一個E/E系統中硬件主要包括:?傳感器(D.9)，繼電器/連接件(D.3)，Digital輸入/輸出(D.5)，Analog輸入/輸出(D.5)，總線(D.6)，處理器(D.4)，時鐘(D.8)，執行器(D.10)，具體如下圖所示:?

由于內容過多，我們接下來以其中最重要的硬件之一，即處理器(D.4)為例，介紹處理器相關的硬件安全機制。 ? 處理器(CPU)是微控制器(MCU)的核心，是負責讀取指令，對指令譯碼并執行指令的核心部件，ISO 26262-5:2018附錄D中，處理器相關的安全機制及診斷覆蓋率如下所示:?

CPU主要由運算器，控制器，寄存器組成，所以針對處理器的安全機制也主要針對這三大部分。由于表格里的處理器相關安全機制分類存在一定重疊，且不是很好理解，個人將其進行總結分類如下:?

自檢

硬件冗余

看門狗

程序流監控

自檢??

根據自檢方法，自檢安全機制一般可以分為:?

軟件自檢

對安全相關路徑中的使用到的指令，利用預先設置好或自動生成的數據或代碼，對物理存儲(例如，數據和地址寄存器)或運算器及控制器(例如，指令解碼器)，或者它們兩者進行檢測。

硬件自檢

在控制單元內部集成專用自檢硬件，最常見的就是內建自測試(BIST)，通過在芯片設計中加入額外自測試電路，測試時從外部施加控制信號，運行內部自測試硬件和軟件，檢查電路缺陷或故障，是防止故障潛伏的重要安全機制。

BIST一般僅在處理單元初始化或者下電時運行，所以不能覆蓋瞬態故障，根據其自檢時間一般可以分為:

1

Online Self-test: 在車輛啟動時間限制內盡可能多地進行測試。

2

Offline Self-test: 車輛停機或診斷測試，最大的測試覆蓋率，車輛斷電時沒有時間限制。

3

Periodic Self-test: 車輛在正常操作模式下，進行的診斷測試。

而根據其自檢的內容，BIST又可以分為:

1

MBIST(Memory?Built-In Self?Test):?對memory，包括RAM或ROM，進行讀寫測試操作，判斷Memory是否有制造缺陷，屬于內存相關的安全機制。

2

LBIST(Logic Built-In Self Test):?對芯片內邏輯電路進行自檢，屬于處理器相關安全機制。

其中，LBIST是硬件自檢非常重要的安全機制，其工作原理如下圖所示:

具體來講，首先利用測試生成器，生成測試向量，然后將測試向量輸入被測試電路，最后BIST控制器將測試電路輸出結果和預存的結果進行對比，一旦二者存在差異，則表明被測試電路存在故障。

硬件冗余

硬件冗余是處理器或控制器最重要的安全機制之一，根據硬件冗余的形式，控制器硬件冗余一般可以分為以下兩大類: ?

雙(多)MCU硬件冗余

使用兩個相同或不同類型的MCU，進行硬件冗余，二者相互獨立，構成主，副功能鏈路，其中一個MCU負責功能實現，另外一個對功能安全要求較高的MCU負責功能安全需求實現，二者輸出結果進行相互比較并控制安全輸出。 ? 優點在于: 物理復制安全相關和非安全相關的功能與特性，避免相關失效魯棒性高，可以實現Fail Operational 系統架構，當其中一個MCU失效后，另外一個MCU可以實現全部或部分功能，維持系統繼續運行，多用于高級輔助和自動駕駛控制系統。 ?

缺點在于:?配置復雜，成本高，再加上軟件同步及PCB空間增加等因素，會給帶來巨大的挑戰和障礙。

示例:?雙控制單元EPS控制系統。

來源: Freescale

單MCU硬件冗余

單MCU硬件冗余一般采用CPU冗余，形成雙(多)核MCU，并采用雙核鎖步技術(Dual Core LockStep)。

雙核: 兩個相同的核鏡像，90°旋轉，隔離設計，間距100um。

鎖步: 兩個核運行相同程序并嚴格同步，一個輸入延遲，另外一個輸出延遲，延遲時間一般為2-3個時鐘周期，計算結果利用比較邏輯模塊進行比較，檢測到任何不一致時，就會發現其中一個核存在故障，但不會確定是哪個核故障。

雙核鎖步是一種綜合性的硬件安全機制，可以有效覆蓋CPU執行指令，設計電路等相關失效，具體如下圖所示:

在E-Gas三層功能安全架構中，第二層，即功能監控層可以采用雙核鎖步安全機制，并且功能安全相關和非相關的軟件可以進行分區，使用不同的硬件資源(例如,不同的 RAM、ROM 存儲范圍)可提高診斷覆蓋率。 ?

示例: 雙核鎖步(Dual core Lookstep)EPS控制系統。

來源: Freescale

其中，MCU采取雙核鎖步模式，并且存在獨立的監控單元，工作于低功耗模式，對雙核MCU進行電源管理和安全監控。

看門狗?

看門狗定時器 (WDT) 是一種定時器，用于監視微控制器 (MCU)程序，查看它們是否失控或停止運行，充當監視MCU 操作的“看門狗”。

MCU正常工作的時候，每隔一段時間輸出一個信號到喂狗端，給WDT清零，如果超過規定的時間不喂狗，WDT就會給出一個復位信號到MCU，使MCU復位。

看門狗基本類型及主要特點如下圖所示:

對于功能安全而言，主要采用硬件看門狗作為安全機制。根據其實現復雜度，它可以工作于不同模式:

計時模式(Time out mode)

時間窗模式(Window mode)

問答模式(Q&A mode)

從上往下，其可靠度和復雜度依次上升。

除此之外，還必須注意以下幾點:

看門狗必須在系統初始化中進行測試，避免看門狗自身故障。

看門狗輸入為喂狗(kicking the dog/service the dog)，必須在特定的時間或時間窗內喂狗，否則會觸發相應Reset端或功能降級。

程序流監控?

程序流監控的實現的本質是看門狗，用于檢查程序是否按照預期的執行順序執行。如果監控實體以不正確的順序執行，或在規定的截止時間或時間窗內沒有被執行就出現不正確的程序流。

具體應用過程中，可以在功能安全相關的一個或多個監測實體中按照程序預期的執行順序設置一個或多個Checkpoint，如果在特定的時間限制內，Checkpoint沒有被依次執行，則會觸發相應的復位或錯誤處理機制。

需要注意的是:

1

在ISO 26262-5:2018附錄D中，將看門狗和程序流監控這部分安全機制歸為時鐘(D.8)故障的安全機制，但它們還是主要應用于處理器(D.4)，所以本文將其歸類到處理器相關的硬件安全機制。

2

實際應用中，程序流監控一般直接包含于看門狗安全機制，例如AUTOSAR中看門狗管理器WdgM，可以實現周期性，非周期性以及邏輯監控。

3

硬件相關安全機制很多并不是單獨存在的，例如，看門狗安全機制可以和其他硬件安全機制相互結合使用，利用看門狗問答模式(Q&A mode)可以將程序流監控和功能安全相關的CPU指令測試安全機制相結合，對監控單元提出的問題各自提供部分答案，實現對功能安全控制硬件的有效監控。

審核編輯：劉清