有關智能汽車MCU功能安全的6個經典問題

在產品中實現(xiàn)安全機制，可防止失效事件導致單點故障或減少殘余故障，并防止故障潛伏。支持功能安全應用的MCU，一定提供了諸多安全機制。以下是NXP總結的有關MCU安全機制的6個經典問題。

Q1: 什么是安全機制? 為什么微控制器需要安全機制?

ISO26262標準里，有安全措施(safety measure)和安全機制(safety mechanism)兩個概念：

Safety Measure：activity or technical solution to avoid or control systematic failures and to detect random hardware failures or control random hardware failures, or mitigate their harmful effects;

Safety mechanism：technical solution implemented by E/E functions or elements, or by other technologies, to detect faults or control failures in order to achieve or maintain a safe state.

Safety measure的概念定義更寬泛，包含safety mechanism的定義范疇，大家時常提及的MCU的安全機制或產品設計中的安全機制，應該是safety mechanism這個概念。

在產品中實現(xiàn)安全機制，可防止失效事件導致單點故障或減少殘余故障，并防止故障潛伏。支持功能安全應用的MCU，一定提供了諸多安全機制，如：ECC/Lockstep/Watchdog/CMU/BIST等。

安全機制必不可少，行業(yè)內還出現(xiàn)支持ASIL B或ASIL D應用的MCU，兩者最核心的差異就在可用安全機制的多少上。

Q2: 有軟件安全機制和硬件安全機制的區(qū)分嗎?

大部分安全機制是要求軟硬件配合完成的，但也有少部分純硬件安全機制或純軟件安全機制。

比如常見的Lockstep安全機制，可認為是一種硬件安全機制，在MCU上此機制的實現(xiàn)基本對用戶應用層軟件透明。

Lockstep鎖步核校驗

• 主核和檢查核都可以從XBAR和緩存陣列讀數(shù)據(jù)
• 只有主核對XBAR和緩存陣列進行寫操作
• 主核和檢查核都可對緩沖控制讀寫數(shù)據(jù)
• 主核的輸出會送到XBAR和RCCU
• 檢查核的輸出只能送到RCCU
• 檢查核位于安全域，物理上與主核隔離

一些基本由用戶軟件自行實現(xiàn)的安全機制，比如CAN通信中的frame Counter，是在多幀傳輸中為了防止楨丟失或者幀錯亂通過應用層軟件對報文進行的編碼或加密，這種安全機制可認為是純軟件的安全機制。

Q3：安全機制與故障容錯時間有關系嗎？

安全機制就是為了在故障容錯時間內，有效檢測故障控制失效影響,并維持系統(tǒng)的安全狀態(tài)。安全機制的設計與使用必須考慮故障容錯時間。目前MCU安全目標對應的故障容錯時間一般為10ms,用戶在使用功能安全MCU時一定要考慮這個時間，并且零部件產品級的故障容錯時間需要大于MCU的FTTI。

再結合實例討論一下SPC5744P 模數(shù)轉換器的安全機制和故障容錯時間的關系。SPC5744P 的ADC提供了自測試模式，通過寄存器配置與操作，某個測試通道可獲取參考電壓與帶隙基準電壓的比值，正常情況下，這個比值應該是一個預期中的固定常量，當參考電壓有波動或者帶隙電壓失效后，通過該自測試可及時發(fā)現(xiàn)問題，提示用戶ADC轉換數(shù)據(jù)已經不可信。

這個自測試的功能就是一條安全機制，使用該安全機制就需要充分考慮故障容錯時間。用戶產品層某個安全相關功能若使用到該ADC，假設對應的安全目標的故障容錯時間為100ms，那么建議用戶必須在100ms以內至少啟用一次SPC5744P提供的這條ADC Self Test，以保證在Delta Time =100ms 時間內，ADC均可認為在正常工作；另外一層意義上講，如果某條安全機制不能在系統(tǒng)故障容錯時間之內檢測到失效事件及影響，這也是沒有意義的安全機制，對用戶的功能安全開發(fā)無實際幫助。



Q4:功能安全的微控制器,應如何選擇安全機制?

在功能安全開發(fā)中，選定一款符合功能安全要求的微控制器，到底需要使用哪些安全機制也是工程師需要重點考慮的問題。原則上，一款ASIL D的微控制器，把MCU自帶的安全機制全部用上，并啟用safety manual 里要求的一些外部機制 均可支持用戶完成ASIL D的功能安全開發(fā)，但理解和實現(xiàn)所有的安全機制，極具挑戰(zhàn)。

這里簡單總結一下，一些基本的安全機制是必須啟用的，如：針對Core的Lockstep、針對RAM/Flash的ECC、針對電源的監(jiān)控、針對時鐘的監(jiān)控(CMU及QA Watchdog)、針對ADC的自測試，以及針對安全機制或寄存器的BIST等。 其他一些安全機制，可視實際使用了MCU什么資源再針對性的選擇相關的安全機制，比如使用了CAN通信，可選擇使用E2E保護機制，這是可以參考MCU Safety Manual及ISO26262-5 附錄D的安全機制列表進行評估。



最后，還得通過量化的FMEDA計算來檢驗是否選擇了足夠的安全機制，原則上能通過FMEDA計算，達到相應的量化指標，即可認為選擇的安全機制已經足夠；若FMEDA計算不達標，說明還需要啟用更多的安全機制。

Q5: 如何保障安全機制本身的安全?

安全機制本身也可能出現(xiàn)失效，這在功能安全里一般被認定為latent fault，不屬于單點失效。SPC5744P是支持ASIL D應用要求的MCU，針對這款MCU內部提供多種安全機制的自測試，常見的有MBIST和LBIST，是針對儲存和邏輯部分的內嵌自測試，BIST一般會在MCU上電后開始自測試，自測試通過MCU才能正常上電，這也是保證上電后MCU安全機制有效可用的一種方式。

NXP為方便用戶進行功能安全開發(fā)，同時提供Coretest和sBoot,這兩套代碼包均包含對部分MCU安全機制的自測試功能實現(xiàn)。

ISO26262同時要求，針對ASILD的應用，其安全機制可以在一次駕駛循環(huán)內測試一次，針對MCU一次上下電，即是一次駕駛循環(huán)。ISO2626這條要求，說明針對安全機制，不用在每個FTTI故障容錯時間內都對安全機制進行測試，這也減輕了軟件開發(fā)工作量。

Q6: AUTOSAR或MCAL是否自帶足夠的安全機制？

AUTOSAR只是一套標準的基礎軟件架構，用戶需要在此基礎上進行二次開發(fā)，加入更多的安全機制才能符合功能安全要求，但AUTOSAR基礎架構部分已支持四大安全機制。



MCAL更沒有提供足夠的安全機制，MCAL只是MCU抽象層的驅動代碼包，提供符合AUTOSAR的各項標準接口函數(shù)，用戶可利用這些功能代碼庫去實現(xiàn)更多的安全機制。

所以，用戶購買了MCAL或者AUTOSAR之后，不代表已經實現(xiàn)了軟件功能安全機制的開發(fā)，還需要功能安全軟件工程師在此基礎上，實現(xiàn)具體的安全機制。