安全机制分配原则:自上而下的分配方法

安全机制怎么分?这是个好问题。很多工程师一上来就盯着某个具体电路,想着「这里加个看门狗,那里加个ECC」。嗯,这样做往往出问题。我个人的习惯是——先看全局,再往下拆。

说白了,安全机制的分配必须遵循自上而下的原则。你想想看,如果连安全目标都没搞清楚,就开始往模块里塞机制,最后很可能出现两种情况:要么机制堆得太多,成本爆炸;要么关键路径漏了,审核被怼。

从安全目标到技术安全概念

这个过程其实就三步:

  1. 安全目标(SG)——车辆级别的危害,比如「刹车时不能意外加速」。
  2. 功能安全概念(FSC)——系统层面的应对策略,比如「检测到加速踏板和刹车同时踩下时,优先执行刹车」。
  3. 技术安全概念(TSC)——技术实现方案,比如「通过CAN总线监控踏板信号,并在VCU中实现仲裁逻辑」。

我在项目中遇到过一种典型错误:团队直接从SG跳到TSC,跳过了FSC。结果呢?技术方案做完了,才发现系统架构根本支撑不了那个安全机制。返工,全是泪。

核心原则:安全机制分配必须逐层映射,不能跳级。每一层都要问自己——「这个机制到底在防什么?」

分配矩阵的构建

分配矩阵,说白了就是一张表。它把安全目标、功能安全概念、技术安全概念、安全机制、ASIL等级全部串起来。我习惯用Excel做,但更推荐用专门的工具(比如PREEvision或Medini),因为后期变更管理会轻松很多。

下面是一个典型的分配矩阵结构:

安全目标 (SG) ASIL 功能安全概念 (FSC) 技术安全概念 (TSC) 安全机制 分配的ASIL
SG-01: 防止非预期加速 ASIL D FSC-01: 监控踏板信号一致性 TSC-01: 踏板信号冗余采集与比较 SM-01: 双通道ADC采样+软件比较 ASIL D
SG-02: 防止转向失控 ASIL C FSC-02: 转向扭矩监控 TSC-02: 扭矩传感器自检 SM-02: 传感器在线诊断(OSC) ASIL C
SG-03: 防止制动失效 ASIL D FSC-03: 制动冗余路径 TSC-03: 液压与线控双路径 SM-03: 路径切换监控 ASIL D

小技巧:分配矩阵里,每一行都要能追溯到上一层的安全目标。如果某个安全机制找不到对应的SG,那它大概率是多余的。我曾经帮一个团队砍掉了30%的安全机制,就是因为它们在矩阵里「无根可循」。

自上而下的分配方法——具体怎么做?

我总结了一个四步法,你可以直接拿来用:

  1. 第一步:列出所有安全目标——从HARA报告里拿,别自己编。
  2. 第二步:为每个SG定义功能安全概念——问自己「系统层面怎么防这个危害?」
  3. 第三步:将FSC分解为技术安全概念——这时候才涉及具体硬件和软件。
  4. 第四步:为每个TSC分配安全机制——注意,一个TSC可能需要多个安全机制来覆盖。

嗯,这里要注意:分配过程中,ASIL等级是向下传递的。SG是ASIL D,那它下面的FSC、TSC、安全机制至少也得是ASIL D。除非你做了ASIL裁剪——这个我们后面章节会细讲。

避坑指南:我曾经见过一个项目,SG是ASIL D,但分配下去的安全机制只做到了ASIL B。理由是「我们觉得够用了」。结果审核时直接被开了严重不符合项。记住:ASIL等级不是你觉得,而是证据说了算。

分配矩阵的构建流程(SVG图)

下面这张图展示了从安全目标到安全机制的完整分配流程。你可以把它贴在工位上,每次做分配时对照着走一遍。

安全机制自上而下分配流程 安全机制自上而下分配流程 安全目标 (SG) 功能安全概念 (FSC) 技术安全概念 (TSC) 安全机制 (SM) ASIL等级传递 SG: ASIL D ↓ 向下传递 FSC/TSC/SM: ≥ ASIL D 常见问题 • 跳级分配 • ASIL等级不匹配

分配矩阵的构建步骤

构建分配矩阵,我建议按这个顺序来:

  • 步骤1:确定安全目标清单——从HARA中提取,确保每个SG都有唯一的ID。
  • 步骤2:为每个SG定义FSC——一个SG可能对应多个FSC,别怕多。
  • 步骤3:将FSC分解为TSC——这时候要开始考虑具体的技术实现。
  • 步骤4:为每个TSC分配安全机制——注意,一个TSC可能需要多个安全机制来覆盖不同的故障模式。
  • 步骤5:填写ASIL等级——确保每一层的ASIL都不低于上一层的SG。
  • 步骤6:交叉检查——看看有没有遗漏的故障模式,有没有冗余的机制。

我的经验:分配矩阵建好后,至少做两轮评审。第一轮让系统工程师看,第二轮让安全工程师看。两拨人关注的点不一样,能发现不同的问题。

常见错误与避坑

做安全机制分配时,我见过最多的坑有三个:

  • 坑1:跳级分配——直接从SG跳到安全机制,跳过了FSC和TSC。结果机制和系统架构对不上。
  • 坑2:ASIL等级不一致——SG是ASIL D,但分配下去的安全机制只做到了ASIL B。审核时直接红牌。
  • 坑3:矩阵不完整——只写了安全机制,没写对应的故障模式或诊断覆盖率。评审时别人看不懂。

我曾经踩过的坑:有一次做EPS项目,我分配了一个安全机制「扭矩传感器自检」,但没写清楚这个自检覆盖哪些故障模式。结果测试团队不知道怎么验证,最后只能补测,浪费了两周时间。从那以后,我要求每个安全机制必须附带故障模式清单和诊断覆盖率目标。

小结

安全机制分配,说白了就是一层层往下拆。从安全目标到功能安全概念,再到技术安全概念,最后落到具体的安全机制。分配矩阵就是你的地图,别让它有空白。