容许汽车技术融合的故障—鲁棒微控制器:第一部分,故障的特性
发布时间:2008/6/5 0:00:00 访问次数:406
汽车、半导体技术和电子系统正通过“汽车上的芯片”走向融合。然而,这种融合却导致大量新的故障和失效模式,所以,如何使这样的系统更为鲁棒呢?本文将介绍提高汽车微控制系统设计鲁棒性的策略。
目前,汽车电子mcu(微控制器单元)的日子很艰难。
一方面,汽车中50多个mcu的应用涉及安全气囊、刹车、车身控制、引擎控制和线控。人们采用更深(并且常常不成熟)的硅技术来减少成本,并用软件来实现新的功能,所以,对存储器和性能的要求与日俱增。标准化的努力和新的软件架构—如autosar—正驱动汽车电子系统采用越来越强大的cpu,因此,内部总线会因日益增多的外设需求而拥挤不堪。
另一方面,随着复杂性的与日俱增,其结果是故障的数量也越来越多,这些故障包括:
—建模的不确定性
—功能验证的缺陷
—对规范的错误理解
—emc (电磁兼容性)
—串扰
—无法预测的交互作用和误用
—软错误
—恶意的访问
在特殊情况下,硬件故障(系统或随机)会因下列原因而变坏:
—软错误导致的故障率(例如宇宙射线导致的数据丢失)增加;
—耦合效应和干扰越来越重要;
—因模型不精确导致的固有不确定性是新技术应用存在的主要问题。
然而,系统复杂性和第三方ip的使用增加了验证断层和软件故障。如果我们把鲁棒性定义为:即使存在系统、随机或恶意故障也能持续可靠地完成任务的能力,那么,你要如何设计故障—鲁棒的mcu呢?
测量鲁棒性
第一步是对测量鲁棒性采用一致的方法。iec 61508是针对电气/电子/可编程电子安全相关系统的功能安全性国际标准。这种标准引入一种类确定性方法来评价鲁棒性。iec 61508采用主要由安全失效系数(sff)决定的安全完整性水平(sil)来对系统进行分类,安全失效系数等于未检测到的危险危害与已检测到的危险危害加安全危害之比。
对于要求零硬件容错的汽车系统(硬件容错为n意味着n+1故障可能引起安全功能的损失),sil2是最小级别,并且如果sff大于90%就可以达到sil2。例如,防抱死刹车系统(abs)就是要求达到sil2的系统;诸如线控、主动刹车和稳定性控制之类的主动安全系统就要求达到sil3级别(sff大于或等于99%)。
iec 61508-2附录对每一个元器件要考虑的故障和失效模式给出了指南,并包含所推荐的诊断技术,以及针对目标sil根据它们的效力所做的评级。b因子—即共同原因失效概率—所发挥的重要作用之一就是可能成为一种限制因子,特别是在相同的硅片上实现多个功能相等的通道时。
从芯片内部解决安全问题更佳
在汽车上使mcu获得广泛应用的最重要一步就是:把iec 61508标准推广应用到系统级芯片(soc)设计之中。这意味着要在系统级芯片层面采用诸如失效模式和影响分析之类的系统级方法,并利用这种分析所提供的信息好处,实现结构化的方法来增加soc的鲁棒性。
为了满足这种需求,yogitech已经开发了faultrobust这种拥有专利的、基于平台的技术(见下面的微控制器演示文件),其组成部分包括:
—遵循iec 61508标准的设计和确认方法,包括fmea和错误注入(fault injection)方法;
—补足soc子系统的灵活和可配置的硬件ip库;
—基于现有编译器的一组工具套件,用于处理硬件/软件集成和配置流程;
每一个faultrobust ip (frips)可以独立使用,也可以跟其它frip结合使用。
设计和确认方法是该技术的关键点。利用商用eda工具建立的脚本,工具套件(frfmea)可以从安全要求规范(srs,iec 61508定义安全目标所要求的一个文件)及设计数据库(rtl、门级和后端网表)提取信息。这些数据被输入到非常详细的失效模式和影响分析工作表中,然后,根据iec指南考虑故障模式和失效模式。最后,利用嵌入到fmea工作表中的统计公式自动计算安全故障系数及诊断覆盖率。
iec 61508非常推荐在设计、验证和确认过程中集中使用故障建模和故障注入方法。为了适应该目的,frfi工具套件在最底层(三极管,门级)和最高层(模块级)同时执行设计级故障注入。这种工具套件由专有工具和cadence公司的specman工具构成。
该工具自动被链接到frfmea并利用基于算法的操作标准(operational profile),增强故障注入活动的速度。frfi工具套件并不是针对特定的故障模型设计的,但是,能够处理不同的故障模型,如瞬态故障、永久故障和两种故障的组合以及定制故障模型(采用ieee1647“e”语言建模)。
嵌入式存储器(静态、动态ram和非易失性存储器)仍然是最重要模块,人们对其的关注包括:
可靠性、可信性和安全性。现有的解决方案存在许多局限性,如:
—不遵守特定的安全规范;
—在数据路径中的编/解码器会导致访问时间开销;
—因运行代码(特别是错误校正代码(ecc))导致存储器区开销;
—因多种错误而导致保护机制降级;
—可配置性降低;
汽车、半导体技术和电子系统正通过“汽车上的芯片”走向融合。然而,这种融合却导致大量新的故障和失效模式,所以,如何使这样的系统更为鲁棒呢?本文将介绍提高汽车微控制系统设计鲁棒性的策略。
目前,汽车电子mcu(微控制器单元)的日子很艰难。
一方面,汽车中50多个mcu的应用涉及安全气囊、刹车、车身控制、引擎控制和线控。人们采用更深(并且常常不成熟)的硅技术来减少成本,并用软件来实现新的功能,所以,对存储器和性能的要求与日俱增。标准化的努力和新的软件架构—如autosar—正驱动汽车电子系统采用越来越强大的cpu,因此,内部总线会因日益增多的外设需求而拥挤不堪。
另一方面,随着复杂性的与日俱增,其结果是故障的数量也越来越多,这些故障包括:
—建模的不确定性
—功能验证的缺陷
—对规范的错误理解
—emc (电磁兼容性)
—串扰
—无法预测的交互作用和误用
—软错误
—恶意的访问
在特殊情况下,硬件故障(系统或随机)会因下列原因而变坏:
—软错误导致的故障率(例如宇宙射线导致的数据丢失)增加;
—耦合效应和干扰越来越重要;
—因模型不精确导致的固有不确定性是新技术应用存在的主要问题。
然而,系统复杂性和第三方ip的使用增加了验证断层和软件故障。如果我们把鲁棒性定义为:即使存在系统、随机或恶意故障也能持续可靠地完成任务的能力,那么,你要如何设计故障—鲁棒的mcu呢?
测量鲁棒性
第一步是对测量鲁棒性采用一致的方法。iec 61508是针对电气/电子/可编程电子安全相关系统的功能安全性国际标准。这种标准引入一种类确定性方法来评价鲁棒性。iec 61508采用主要由安全失效系数(sff)决定的安全完整性水平(sil)来对系统进行分类,安全失效系数等于未检测到的危险危害与已检测到的危险危害加安全危害之比。
对于要求零硬件容错的汽车系统(硬件容错为n意味着n+1故障可能引起安全功能的损失),sil2是最小级别,并且如果sff大于90%就可以达到sil2。例如,防抱死刹车系统(abs)就是要求达到sil2的系统;诸如线控、主动刹车和稳定性控制之类的主动安全系统就要求达到sil3级别(sff大于或等于99%)。
iec 61508-2附录对每一个元器件要考虑的故障和失效模式给出了指南,并包含所推荐的诊断技术,以及针对目标sil根据它们的效力所做的评级。b因子—即共同原因失效概率—所发挥的重要作用之一就是可能成为一种限制因子,特别是在相同的硅片上实现多个功能相等的通道时。
从芯片内部解决安全问题更佳
在汽车上使mcu获得广泛应用的最重要一步就是:把iec 61508标准推广应用到系统级芯片(soc)设计之中。这意味着要在系统级芯片层面采用诸如失效模式和影响分析之类的系统级方法,并利用这种分析所提供的信息好处,实现结构化的方法来增加soc的鲁棒性。
为了满足这种需求,yogitech已经开发了faultrobust这种拥有专利的、基于平台的技术(见下面的微控制器演示文件),其组成部分包括:
—遵循iec 61508标准的设计和确认方法,包括fmea和错误注入(fault injection)方法;
—补足soc子系统的灵活和可配置的硬件ip库;
—基于现有编译器的一组工具套件,用于处理硬件/软件集成和配置流程;
每一个faultrobust ip (frips)可以独立使用,也可以跟其它frip结合使用。
设计和确认方法是该技术的关键点。利用商用eda工具建立的脚本,工具套件(frfmea)可以从安全要求规范(srs,iec 61508定义安全目标所要求的一个文件)及设计数据库(rtl、门级和后端网表)提取信息。这些数据被输入到非常详细的失效模式和影响分析工作表中,然后,根据iec指南考虑故障模式和失效模式。最后,利用嵌入到fmea工作表中的统计公式自动计算安全故障系数及诊断覆盖率。
iec 61508非常推荐在设计、验证和确认过程中集中使用故障建模和故障注入方法。为了适应该目的,frfi工具套件在最底层(三极管,门级)和最高层(模块级)同时执行设计级故障注入。这种工具套件由专有工具和cadence公司的specman工具构成。
该工具自动被链接到frfmea并利用基于算法的操作标准(operational profile),增强故障注入活动的速度。frfi工具套件并不是针对特定的故障模型设计的,但是,能够处理不同的故障模型,如瞬态故障、永久故障和两种故障的组合以及定制故障模型(采用ieee1647“e”语言建模)。
嵌入式存储器(静态、动态ram和非易失性存储器)仍然是最重要模块,人们对其的关注包括:
可靠性、可信性和安全性。现有的解决方案存在许多局限性,如:
—不遵守特定的安全规范;
—在数据路径中的编/解码器会导致访问时间开销;
—因运行代码(特别是错误校正代码(ecc))导致存储器区开销;
—因多种错误而导致保护机制降级;
—可配置性降低;