智能汽车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之后,不代表已经实现了软件功能安全机制的开发,还需要功能安全软件工程师在此基础上,实现具体的安全机制。

继续阅读
恩智浦处理器为下一代电动车辆和自动驾驶车辆提供高性能和安全性

全新的NXP S32S微处理器将安全地管理车辆的加速、制动和转向安全系统,无论是在驾驶员的直接控制下,还是在车辆自动驾驶时均可实现。

恩智浦5V 8位微控制器S08P家族又添新丁!为智能工业量身定制的8位MCU

恩智浦5V 8位微控制器S08P家族又添新丁!全新推出的20-TSSOP和8-SOIC两种小封装器件拥有强悍的ESD性能,进一步降低设计的物料成本,适用于各种尺寸受限的工业与物联网控制的应用。

恩智浦智能门锁方案,加速中国智能门锁市场产品转型升级

在2018中国电子信息博览会(CITE 2018)上,恩智浦推出的众多人工智能及物联网解决方案中,一个智能门锁方案十分吸睛!基于对当前中国住宅门禁市场需求的充分体认,该方案可以一举解决智能门锁产品的所有痛点问题。

恩智浦推出新的安全元件信任锚,保障物联网安全

恩智浦物联网安全解决方案总经理Philippe Dubois表示:“企业现在开始意识到在未来云应用和服务中保证物联网设备和连接安全的重要性,但是他们缺乏集成方面的知识或合适的安全解决方案。A71CH内置所有的技术配置,以满足大众市场对安全性的需求。通过提供一个信任根,来满足物联网市场增长和演进的需求。”

收藏吧 | NXP工程师帮你总结的汽车电子ECU BootLoader开发要点

一方面,随着半导体技术的不断进步(按照摩尔定律),MCU内部集成的逻辑功能外设越来越多,存储器也越来越大;另一方面,消费者对于汽车节能(经济和法规对排放的要求)型、舒适性、互联性、安全性(功能安全和信息安全)的要求越来越高,特别是近年来新能源电动车、车联网和自动驾驶技术的兴起,更大大加速了汽车电子技术的发展。