域架构下的功能安全思考

来源:联合电子

域架构下的功能安全思考_第1张图片

随着整车电子电气架构的发展,功能域控架构向整车集中式区域控制演进。新的区域控制架构下,车身控制模块(BCM),整车控制单元(VCU),热管理系统(TMS)和动力底盘等功能等原本独立的功能域整合到新的区域控制器。同时,区域控制器也集成了二级智能配电功能,真正形成了Power HUB, IO HUB, Data HUB。


域架构下的功能安全思考_第2张图片

整车区域架构

新EEA架构下,功能安全也随之有了新的变化。原来多个不同的控制器来实现整车功能,功能安全目标也是以独立的控制器为主体,结合控制器间的信号交互来共同实现。整车区域架构下,同一个区域控制器中集成车身,动力,底盘控制等功能,有ASIL A/B/C/D四种安全等级安全目标同时出现的情况。这些不同安全目标的实现模块共享控制器的内部软硬件资源,如电源模块,MCU模块和安全关断路径等。

不同功能域对于故障时的响应各有差异。车身类功能安全考虑到系统的鲁棒性,控制器故障后一般进入limphome(跛行)模式;而EPB功能安全等级高,当外部独立看门狗检测到MCU故障,或MCU内部安全监控模块检测到故障,即进入安全状态。

以近光灯和EPB功能为例浅谈区域控制器功能安全设计的一些思考。


从整车安全目标来看,近光灯应避免在行车过程中非预期熄灭,当控制器内部失效后,需要在故障容忍时间间隔(FTTI)内点亮近光灯;EPB最高等级的安全目标应避免在行车过程中非预期的锁死制动卡钳,当控制器内部失效后,需要在FTTI内释放制动卡钳。


系统层面

一方面为了整车的安全性,兼顾系统的鲁棒性,需要收集整车端不同功能和ASIL等级的安全目标,需要考虑不同ASIL等级对于故障的响应,以及对于故障后进入安全状态的可接受度;另一方面从系统架构上进行安全分析,确认安全目标是否可进行ASIL等级分解。


通过合理的功能分配,将左右近光灯布置在两个相互独立的区域控制器中。当某一个控制器内部MCU故障,进入limp home模式点亮近光灯;且当某一个控制器完全失效,另外一个控制器还可以保证其近光灯可以正常点亮,这样近光灯的安全等级分解为ASIL A(B)。

EPB比较特殊,一般分配在两个相互独立的区域控制器中,由于任意一个控制模块锁死了制动卡钳都会违反安全目标,故其最高ASIL D的安全等级不可分解。当控制器出现故障时,通过安全关断路径来释放卡钳驱动电机,进入安全状态。

域架构下的功能安全思考_第3张图片

近光灯和EPB功能安全等级

硬件层面

为了保证区域控制器可以实现最高等级的安全目标,内部共用的硬件模块需要按最高安全等级去开发,如MCU模块,逻辑电源供电模块等。控制器内部低安全等级的功能模块不能影响高安全等级的硬件模块,需要进行相关失效分析,分析不同安全目标共用的电路模块,是否存在共因和级联失效。


当MCU失效后,近光灯和EPB功能不受控。此时,需要安全机制limphome模块点亮近光灯,安全关断路径来关断EPB制动卡钳驱动电路,进入安全状态。且limphome电路不能干扰关断EPB制动卡钳的驱动电路。因此,需要设计独立的limphome电路和安全关断路径电路,这两个硬件电路失效亦不能引起近光灯和EPB功能失效。


软件层面

需要从软件架构层面考虑不同ASIL等级的软件共存问题。近光灯软件模块是ASIL A(B),EPB软件模块是ASIL D。


为了实现ASIL共存,可将近光灯和EPB软件放在两个独立的锁步核运行,从时序和执行 (Timing and execution),内存 (Memory)和信息交换 (Exchange of information)三个方面做到免于干扰。


同时,程序的时间和逻辑监控是必要的,用于探测有缺陷的程序,监控程序的表现和合理性。一般通过外部独立的看门狗进行程序流监控,监控软件是否正确执行,如程序未在指定的时间内执行,或者时钟发生故障。


综上,在区域架构下,功能安全面临更加复杂的架构和多功能融合的挑战,区域控制器需要相互协同,共同实现整车的功能安全目标,提高功能安全开发效率,从而降低功能安全开发的成本。

需要对标样件请联:shbinzer  拆车邦

需要对标样件请联:shbinzer  拆车邦

你可能感兴趣的:(电驱动,驱动电机,800v电驱动,安全架构)