域架构下的功能安全思考-电子发烧友网

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

整车区域架构

新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的安全等级不可分解。当控制器出现故障时，通过安全关断路径来释放卡钳驱动电机，进入安全状态。

近光灯和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)三个方面做到免于干扰。

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

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

欢迎转载！

转载须署名联合电子并注明来自联合电子微信！！

分享给朋友或朋友圈请随意！！