4. 系统级产品开发:技术安全概念(TSC)、系统架构设计、FMEA与FTA在系统层的应用

好,我们进入系统级产品开发。这一章是功能安全落地的核心环节,说白了,就是把上一章的安全目标,变成实实在在的工程设计。

我个人习惯把系统级开发比作「搭骨架」。安全目标定了,你得知道骨架怎么搭,哪些地方要加固,哪些地方要留冗余。技术安全概念(TSC)、系统架构设计,再加上FMEA和FTA这两个分析工具,就是搭骨架的四大件。

核心逻辑: 安全目标(SG)→ 功能安全概念(FSC)→ 技术安全概念(TSC)→ 系统架构设计 → 通过FMEA/FTA验证与优化。

4.1 从功能安全概念到技术安全概念

功能安全概念(FSC)回答的是「系统要做什么来保证安全」。比如「当检测到驾驶员无反应时,系统必须执行最小风险策略(MRM)」。这是功能层面的。

技术安全概念(TSC)则回答「具体怎么实现」。它把FSC里的每个安全措施,分解成具体的技术要求:用什么传感器?信号怎么传输?控制器怎么处理?执行器怎么动作?

我记得有个项目,FSC里写「碰撞前必须锁紧安全带」。听起来简单吧?但到了TSC层面,问题就来了:碰撞信号从哪来?是气囊ECU给的,还是自己算的?信号延迟多少毫秒内算有效?锁紧力多大?要不要考虑误触发?

你看,一个功能要求,能拆出十几个技术细节。这就是TSC的价值。

对比项 功能安全概念(FSC) 技术安全概念(TSC)
抽象层级 功能层 技术实现层
输出形式 安全措施描述 技术需求、接口定义、时序要求
主要受众 系统工程师、功能负责人 软硬件工程师、测试工程师
典型内容 「系统应进入安全状态」 「MCU应在10ms内通过SPI发送关闭指令」

4.2 系统架构设计:安全视角的「分而治之」

系统架构设计,大家都会。但功能安全视角的架构设计,有几个关键点必须注意。

第一,安全分区。 把安全相关功能和非安全相关功能隔离开。我见过一个项目,把ASIL D的刹车控制和信息娱乐系统放在同一个MCU上,没有做足够的内存保护和时间隔离。结果信息娱乐系统死机,把刹车控制也拖垮了。嗯,这显然不行。

第二,独立性。 对于ASIL D的系统,通常需要冗余路径。比如两个独立的传感器、两条独立的通信链路、两个独立的计算通道。它们之间不能有共因失效(CCF)。

第三,安全状态定义。 每个安全机制都要明确:触发条件是什么?进入什么安全状态?退出条件是什么?

我的经验: 架构设计阶段,一定要把「安全机制」当作独立的组件来画。不要把它藏在某个模块里。这样FMEA和FTA分析时,才能清晰地追踪每个安全机制的覆盖范围。

下面这张图,是我常用的系统级安全架构框架,你可以参考一下。

系统级安全架构框架 传感器1(主) ASIL B(D) 传感器2(冗余) ASIL B(D) 通信通道1(CAN/CAN FD) 通信通道2(独立总线) 安全控制器(主核) ASIL D, 锁步核, 硬件安全机制 安全监控(看门狗/比较器) 独立于主核,监控时序与数据 说明:主路径与冗余路径在物理和逻辑上独立,避免共因失效。安全监控独立于主控制器运行。

4.3 系统级FMEA:从「可能出什么错」到「怎么防」

FMEA(失效模式与影响分析)在系统层的应用,我建议把它当作「架构设计的体检」。不是等设计完了再做,而是边设计边做。

系统级FMEA关注的是:组件之间的接口、信号、通信、时序。一个传感器坏了,系统会怎样?一条CAN总线断了,冗余路径能接管吗?

我曾经在一个项目中,FMEA分析发现:当主传感器输出一个无效值(比如超出量程)时,控制器会直接进入安全状态。但问题是,这个「无效值」的判断逻辑,和冗余传感器的判断逻辑共用了一段代码。这就是典型的共因失效。后来我们改了,两个通道的判断逻辑完全独立实现。

避坑指南: 系统级FMEA最容易漏掉的是「时序失效」。比如信号延迟、时钟不同步、看门狗超时设置不合理。这些在静态分析里很难发现,一定要结合时序图来做。

4.4 系统级FTA:用逻辑门追溯根因

FTA(故障树分析)和FMEA是互补的。FMEA是自下而上(从失效模式到影响),FTA是自上而下(从顶事件到根因)。

在系统层,FTA的顶事件通常是「违反安全目标」。比如「车辆意外加速」。然后往下拆:是传感器误报?控制器误判?执行器卡死?还是通信错误?

每个分支都用逻辑门(与门、或门)连接。与门表示「多个条件同时发生才导致顶事件」,或门表示「任何一个条件发生就导致顶事件」。

我建议系统级FTA做到3到4层就够了。再往下,就是硬件和软件的FTA了。系统层FTA的目的是找出「架构层面的薄弱点」。比如某个分支全是或门,说明任何一个单点失效都能导致顶事件,那这个地方就需要加冗余或安全机制。

分析工具 方向 系统层关注点 输出
FMEA 自下而上 组件失效对系统的影响 失效模式清单、安全措施
FTA 自上而下 顶事件的根因组合 故障树、最小割集

4.5 三者如何协同?

你可能会问:TSC、架构、FMEA、FTA,先做哪个?

我的做法是:先有TSC和架构草图,然后做FMEA和FTA,用分析结果反哺TSC和架构,迭代优化。

具体流程:

  1. 起草TSC: 从FSC分解出技术需求。
  2. 画出系统架构: 包括组件、接口、通信路径。
  3. 执行系统级FMEA: 识别每个接口和组件的失效模式。
  4. 执行系统级FTA: 针对关键安全目标,构建故障树。
  5. 对比分析结果: FMEA发现的单点失效,在FTA里是否构成最小割集?
  6. 更新TSC和架构: 增加安全机制,调整冗余策略。
  7. 重复步骤3-6: 直到所有安全目标都被充分覆盖。
关键指标: 系统级FMEA和FTA做完后,你应该能回答:每个安全目标对应的「安全机制覆盖率」是多少?有没有未被覆盖的失效模式?如果有,是加机制,还是接受残余风险?

嗯,这一章内容不少。系统级开发是功能安全落地的第一道关,也是最重要的一道关。TSC定方向,架构搭骨架,FMEA和FTA做体检。三者缺一不可。