有关智能汽车MCU功能安全的6个经典问题

在产品中实现安全机制，可防止失效事件导致单点故障或减少残余故障，并防止故障潜伏。支持功能安全应用的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这个概念。

在产品中实现安全机制，可防止失效事件导致单点故障或减少残余故障，并防止故障潜伏。支持功能安全应用的MCU，一定提供了诸多安全机制，如：ECC/Lockstep/Watchdog/CMU/BIST等。

安全机制必不可少，行业内还出现支持ASIL B或ASIL D应用的MCU，两者最核心的差异就在可用安全机制的多少上。

Q2: 有软件安全机制和硬件安全机制的区分吗?

大部分安全机制是要求软硬件配合完成的，但也有少部分纯硬件安全机制或纯软件安全机制。

比如常见的Lockstep安全机制，可认为是一种硬件安全机制，在MCU上此机制的实现基本对用户应用层软件透明。

Lockstep锁步核校验

• 主核和检查核都可以从XBAR和缓存阵列读数据
• 只有主核对XBAR和缓存阵列进行写操作
• 主核和检查核都可对缓冲控制读写数据
• 主核的输出会送到XBAR和RCCU
• 检查核的输出只能送到RCCU
• 检查核位于安全域，物理上与主核隔离

一些基本由用户软件自行实现的安全机制，比如CAN通信中的frame Counter，是在多帧传输中为了防止桢丢失或者帧错乱通过应用层软件对报文进行的编码或加密，这种安全机制可认为是纯软件的安全机制。

Q3：安全机制与故障容错时间有关系吗？

安全机制就是为了在故障容错时间内，有效检测故障控制失效影响,并维持系统的安全状态。安全机制的设计与使用必须考虑故障容错时间。目前MCU安全目标对应的故障容错时间一般为10ms,用户在使用功能安全MCU时一定要考虑这个时间，并且零部件产品级的故障容错时间需要大于MCU的FTTI。

再结合实例讨论一下SPC5744P 模数转换器的安全机制和故障容错时间的关系。SPC5744P 的ADC提供了自测试模式，通过寄存器配置与操作，某个测试通道可获取参考电压与带隙基准电压的比值，正常情况下，这个比值应该是一个预期中的固定常量，当参考电压有波动或者带隙电压失效后，通过该自测试可及时发现问题，提示用户ADC转换数据已经不可信。

这个自测试的功能就是一条安全机制，使用该安全机制就需要充分考虑故障容错时间。用户产品层某个安全相关功能若使用到该ADC，假设对应的安全目标的故障容错时间为100ms，那么建议用户必须在100ms以内至少启用一次SPC5744P提供的这条ADC Self Test，以保证在Delta Time =100ms 时间内，ADC均可认为在正常工作；另外一层意义上讲，如果某条安全机制不能在系统故障容错时间之内检测到失效事件及影响，这也是没有意义的安全机制，对用户的功能安全开发无实际帮助。



Q4:功能安全的微控制器,应如何选择安全机制?

在功能安全开发中，选定一款符合功能安全要求的微控制器，到底需要使用哪些安全机制也是工程师需要重点考虑的问题。原则上，一款ASIL D的微控制器，把MCU自带的安全机制全部用上，并启用safety manual 里要求的一些外部机制 均可支持用户完成ASIL D的功能安全开发，但理解和实现所有的安全机制，极具挑战。

这里简单总结一下，一些基本的安全机制是必须启用的，如：针对Core的Lockstep、针对RAM/Flash的ECC、针对电源的监控、针对时钟的监控(CMU及QA Watchdog)、针对ADC的自测试，以及针对安全机制或寄存器的BIST等。 其他一些安全机制，可视实际使用了MCU什么资源再针对性的选择相关的安全机制，比如使用了CAN通信，可选择使用E2E保护机制，这是可以参考MCU Safety Manual及ISO26262-5 附录D的安全机制列表进行评估。



最后，还得通过量化的FMEDA计算来检验是否选择了足够的安全机制，原则上能通过FMEDA计算，达到相应的量化指标，即可认为选择的安全机制已经足够；若FMEDA计算不达标，说明还需要启用更多的安全机制。

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

安全机制本身也可能出现失效，这在功能安全里一般被认定为latent fault，不属于单点失效。SPC5744P是支持ASIL D应用要求的MCU，针对这款MCU内部提供多种安全机制的自测试，常见的有MBIST和LBIST，是针对储存和逻辑部分的内嵌自测试，BIST一般会在MCU上电后开始自测试，自测试通过MCU才能正常上电，这也是保证上电后MCU安全机制有效可用的一种方式。

NXP为方便用户进行功能安全开发，同时提供Coretest和sBoot,这两套代码包均包含对部分MCU安全机制的自测试功能实现。

ISO26262同时要求，针对ASILD的应用，其安全机制可以在一次驾驶循环内测试一次，针对MCU一次上下电，即是一次驾驶循环。ISO2626这条要求，说明针对安全机制，不用在每个FTTI故障容错时间内都对安全机制进行测试，这也减轻了软件开发工作量。

Q6: AUTOSAR或MCAL是否自带足够的安全机制？

AUTOSAR只是一套标准的基础软件架构，用户需要在此基础上进行二次开发，加入更多的安全机制才能符合功能安全要求，但AUTOSAR基础架构部分已支持四大安全机制。



MCAL更没有提供足够的安全机制，MCAL只是MCU抽象层的驱动代码包，提供符合AUTOSAR的各项标准接口函数，用户可利用这些功能代码库去实现更多的安全机制。

所以，用户购买了MCAL或者AUTOSAR之后，不代表已经实现了软件功能安全机制的开发，还需要功能安全软件工程师在此基础上，实现具体的安全机制。