智能汽车MCU功能安全,NXP为您总结了6大经典问题

分享到:

在产品中实现安全机制,可防止失效事件导致单点故障或减少残余故障,并防止故障潜伏。支持功能安全应用的MCU,一定提供了诸多安全机制。以下是NXP总结的有关MCU安全机制的6个经典问题。

Q1: 什么是安全机制? 为什么微控制器需要安全机制?

ISO26262标准里,有安全措施(safety measure)和安全机制(safety mechanism)两个概念:

QQ截图20180512012019
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
检查核位于安全域,物理上与主核隔离

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

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

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

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

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

QQ截图20180512012047
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的安全机制列表进行评估。

QQ截图20180512012059
最后,还得通过量化的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基础架构部分已支持四大安全机制。

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

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

继续阅读
汽车电子风起云涌,恩智浦有望成为下一个高通

对于高通追求了两年而未有结果的恩智浦(NASDAQ:NXPI)来说,此时在汽车电子领域兴起的机会也许会助力其成为下一个“高通”。“目前我们在汽车半导体市场居于首位,未来也会争取保持这个优势。”恩智浦半导体资深副总裁兼汽车电子事业部首席技术官Lars Reger对第一财经记者表示,恩智浦的优势在于产品布局的全面性...

国内家电巨头造芯,机会有多大?

自国家成立集成电路产业基金以来,中国的芯片企业层出不穷,很多原本“不搭边”的企业纷纷抢滩 芯片领域 ,一时间芯片成了众人眼中的“香饽饽”。其中既有BAT等互联网巨头,也有小米等手机通讯公司,而这一次,集体入局的是国内传统的 家电巨头 们!

恩智浦FTF:以更大的热情拥抱全球更大的半导体市场

2018年恩智浦未来科技峰会(FTF)在深圳举行,其全球市场销售资深副总裁兼大中华区总裁郑力上来就坦言相告,“两年过去了,恩智浦还是以恩智浦的身份出现在大众面前,虽然和高通分手了,但是我们会以更大的热情拥抱全球更大的半导体市场。”这个幽默的开场赢得了全场热烈的掌声。

蓬勃发展的跨界处理器:恩智浦i.MX RT系列

目前恩智浦在华拥有超过7000名员工,50%的市场营收来自中国,是中国最大的ARM MCU供应商,在中国汽车信息娱乐系统和ePOS市场排名第一。

恩智浦i.MX RT1050遇上RTOS界“大力士”,会擦出什么样的火花?

恩智浦的i.MX RT1050系列跨界处理器一经推出,便刷新了MCU界的多项世界记录,以最高的性能、极为丰富的外设以及极高的性价比,引起了业界的轰动,开创了很多激动人心的MCU新应用领域。