功能安全的架构设计做了五篇，后台一直有人留言问一些特别工程化的问题：安全机制到底怎么选，ASIL分解是不是就是算术题，SPFM、LFM这些指标怎么算才靠谱，软件里怎么做到真正的隔离。说实话这些才是架构设计里真正卡脖子的地方，前面几篇把概念、流程、安全概念梳理清楚了，这篇就把它们往实处落，聊一聊我在实际项目中怎么把这些东西从纸面变成能过评审、能上线跑的设计。
1. 从安全需求到架构落地的完整链条：先理清两条映射线
1.1 架构设计不是画结构图，是搭一条需求传递链
做功能安全架构设计，很多人一开始就打开画图工具，开始堆方块、画连线。我见过不少团队这样干，结果画出来的图漂漂亮亮，评审的时候却经不起问，问一句“这个安全需求对应哪个模块”就答不上来。所以我现在带项目，第一件事永远是先理清需求的传递链。
这条链在ISO 26262里其实写得很清楚：项定义（Item Definition）做完HARA，得到安全目标，然后往下发展出功能安全概念（FSC），再细化成技术安全概念（TSC），最后拆出硬件安全需求（HSR）和软件安全需求（SSR）。架构设计就是TSC的载体，它一边承接上面传来的安全需求，一边又把安全需求分配到具体的硬件电路、软件模块和通信链路上。
架构设计里存在两条映射线，大家做的时候要分清。一条是纵向的“安全目标到安全机制”的映射，也就是traceability：哪个安全目标由哪几个安全机制来保障，每个安全机制的检测对象、响应动作、覆盖范围是什么，必须一一对应。另一条是横向的“系统架构到硬件架构、软件架构”的分解：系统层的架构决策要分解到硬件和软件两个领域，两边各自承担一部分安全需求。
我在项目里习惯先做一张“安全机制分配表”，而不是先画图。把每个安全目标拉成一行，然后横向展开：这个安全目标相关的故障是什么，用什么传感器或模块来监测，监测到之后怎么反应，落到哪个硬件元件和哪个软件组件里，ASIL等级是多少。这张表做完，架构图自然就出来了。反过来，如果你发现某张架构图上有些模块在表里找不到归宿，说明这些模块很可能是白画的，或者是安全需求没拆干净。
1.2 架构设计输入输出：忽略安全机制自身的失效是通病
功能安全架构设计的输入，不仅仅是FSC和系统边界定义。我实际做的时候，输入通常还包括：初始架构方案、硬件资源预算（尤其MCU算力、RAM、Flash占用）、通信矩阵、供电方案、机械接口约束，以及上一步安全分析（FMEA、FTA）的初步结论。输出则是TSC文档、HSR和SSR（每条需求都带ASIL和追溯关系）、安全机制清单、FMEDA分析结果、安全验证计划，还有更新的架构图。
这里有一个特别容易被忽略、但审核员每次都盯的地方：安全机制自身的安全性。举个例子，你设计了一个看门狗来监控主芯片的程序运行状态，那看门狗芯片自己失效了怎么办？看门狗芯片如果因为供电故障直接不工作，主芯片跑飞了也没人管，整个安全链就断了。所以在架构阶段，每个安全机制都要追问一句“你自己出故障了，谁兜底”。
处理方式一般是三类：一是安全机制自带诊断，比如window看门狗对上下窗口都有检测能力，如果窗口边界异常也能发现一部分自身问题；二是上电时做BIST（Built-In Self Test）或运行中做周期自检，确认看门狗功能本身是好的；三是在更上层设计独立的“二道防线”，比如除了看门狗，再有一个独立的硬件监控电路做路径冗余。这层的设计缺陷，后期很难补，因为它在原理图阶段就定型了。
做架构评审的时候，我常拿一个标准问团队：把某个安全机制从设计里移除，剩下的安全链还有没有冗余？如果答案是“裸奔”，那这个机制自身就必须有充分的诊断措施。
2. 安全机制设计的三个关键词：充足、有效、及时
2.1 安全机制的四种形态与选择逻辑
安全机制的分类有很多种分法，我习惯按作用方式分成四类，这样设计的时候不容易漏。
第一类是故障检测类。看门狗、CRC校验、ECC内存保护、程序流监控（Function Call Monitor）、信号范围检查、报文超时检查，都属于这一类。它们的共同点是“发现问题”，本身不直接让系统变安全。
第二类是故障响应类。检测到故障之后做什么，是进入安全降级模式、切换到备份通道、维持安全状态，还是直接请求整车下电。这类机制决定了故障发生后的系统行为，设计的时候要和整车层面、执行器层面一起确认，不能只看ECU内部。
第三类是冗余类。硬件双通道、双传感器交叉验证、多样冗余软件、信息冗余（比如关键报文发两遍），这些是“让故障不导致最终危害”的手段。冗余不是简单复制，后面聊ASIL分解的时候会展开。
第四类是故障抑制类。比如电源过压钳位、限流保护、物理隔离和屏蔽，目的是不让故障的能量或影响扩散到其他安全相关部分。
具体选择的时候，我遵循的原则是“一个安全目标一到两条安全链”。不是说机制越多越好，每加一个机制，就多一份机制自身失效的风险，多一份FMEDA里的工作量，多一份BOM成本。关键是要把每个机制对应到具体的安全目标上，判断它是不是真的覆盖了某个失效模式。给传感器信号做范围检查，能覆盖传感器短路到电源、短路到地这类故障，但覆盖不了传感器灵敏度漂移。这个判断要靠在FMEA阶段把失效模式列全，否则安全机制看着一大堆，实际覆盖率低下。
用一个生活化的类比：安全机制设计就像小区安防，不是摄像头装得越多越安全，而是要确认每个可能的入侵路径都有对应的监控和响应方案，同时监控头自己坏了得能被发现。
2.2 FTTI、FDTI、FRTI的时间预算：架构阶段的硬约束
“及时”这两个字在功能安全里经常被低估。一个安全目标对应一个FTTI（Fault Tolerant Time Interval，故障容错时间间隔），就是故障发生后，到系统可能违反安全目标之前，留给系统响应的时间窗口。在这个窗口里，系统要完成故障检测（FDTI，Fault Detection Time Interval）和故障响应（FRTI，Fault Reaction Time Interval），进入安全状态。
这个时间预算必须在架构设计阶段就算清楚。我实际项目中的一个例子，一个电机控制器的电流传感器故障，安全目标要求故障后100ms内系统必须进入安全状态。然后我拆时间预算：
| 时间环节 | 分配时间 | 说明 |
|---|---|---|
| 信号采样周期 | 5ms | 电流采样，周期决定数据新鲜度 |
| FDTI故障检测时间 | 40ms | 诊断算法两轮采样确认，排除噪声误判 |
| FRTI故障响应时间 | 45ms | 关断驱动、响应请求、状态切换 |
| 合计 | 90ms | 留10ms余量给不确定性 |
这里有个细节：FDTI和FRTI加起来必须小于FTTI。很多工程师算完刚好压线，觉得没问题，但实际跑起来可能超时。因为FDTI里包含的不只是检测算法的时间，还有任务调度的抖动、中断阻塞、通信传输时间。所以我给自己定了一条经验法则：预算最好只占FTTI的70%~80%，留足余量。如果预算超了，解决思路有三个：加快检测（缩短采样周期、提高诊断任务优先级）、缩短响应路径（减少降级动作的中间环节）、或者回到上一层，重新审视安全目标的定义和整车层面可接受的行为。
时间预算在架构评审中是硬约束，不是参考值。如果这个表格在架构阶段没做出来，后面代码写完了再想优化，基本只能靠调优先级和中断，空间很有限。
2.3 安全机制自身的诊断和覆盖率：别把覆盖率当100%
安全机制自身会失效，这个问题上一节提过，但这里必须不断强调，尤其是覆盖率。
FMEDA里每个安全机制都有一个“诊断覆盖率”参数，这个参数的含义是：在目标元件的所有失效模式中，能被这个安全机制检测到的比例。这个数字不是拍脑袋定的，更不是默认100%。实际的覆盖率取决于检测方法的有效性，比如：
- 用ADC做电压监控，覆盖率受限于ADC分辨率、采样频率和监控阈值的设定。
- 用软件做RAM测试，覆盖率受限于测试算法（March C+、走步等）对不同故障模式的检测能力。
- 用看门狗监控程序流，覆盖率受限于监控粒度，是只监控主循环周期，还是能监控到关键函数的执行顺序。
我见过一个项目，安全机制清单里有一整排“看门狗覆盖程序跑飞：覆盖率90%”，但实际程序流监控只监控了主循环节拍，函数级跳转错误完全没有覆盖，结果FMEDA算出来的SPFM虚高。后来把覆盖率改成30%重算，指标直接不达标，整个架构推到重来。
所以我的经验是：在FMEDA表格里，覆盖率一律要写覆盖率来源。要么来自标准文献的推荐值，要么来自故障注入测试的实测值，要么来自设计原理的推导（比如安全检测机制可以检测出哪些具体故障模式）。没有来源的覆盖率，评审时一律按最保守值处理。
3. ASIL分解：会做算术，更要会证明独立性
3.1 ASIL分解的本质：用独立冗余换严格等级，而不是把风险劈成两半
ASIL分解是功能安全架构里被误解最多的一个概念。最常见的错误说法是“ASIL D的需求，拆给两个模块，每个按ASIL B做就行，两个B加起来等于D”。这句话只对了表面。
先说说为什么能分解。从一个硬件随机失效的视角来看，如果整个系统有两个冗余通道，且两个通道完全独立，那么只有当两个通道都失效时，系统才会违反安全目标。两个独立通道同时失效的概率，从数学上是各自失效概率的乘积关系，而不是相加关系。所以每个单独通道的安全完整性等级可以降低，但整个系统仍然能保持原有的安全水平。
但注意，这个数学结论有一个严格的前提：独立性。两个通道如果共用一路电源、共用同一个晶振、共用同一个软件需求文档、共用同一个工具链，那它们根本不是“独立”的，而是一个共同原因可以同时击穿两条通道。这就是为什么ASIL分解不能只做算术，更要提供独立性论证。
从系统性失效的角度看，数学乘积更是靠不住的。两个软件版本如果出自同一个规格书、同一个程序员、同一个编译器，那很可能犯一模一样的错。比如一个需求写“当车速超过120km/h时降低电机扭矩”，两个开发人员都把这个条件理解成“当车速不低于120km/h时降低电机扭矩”，那这两条路径的冗余就等于零。所以做软件ASIL分解的时候，多样性（diversity）设计是核心，而不能只是“复制一份改改变量名”。
3.2 分解对照表与工程落地前提
ASIL分解的对照表本身很简单：
| 原始ASIL | 可分解为 |
|---|---|
| ASIL D | C(D) + A(D) 或 B(D) + B(D) |
| ASIL C | B(C) + A(C) |
| ASIL B | A(B) + A(B) |
| ASIL A | QM(A) + QM(A) |
注意括号里的标注必须保留。比如原ASIL D分解出的两个ASIL B，要写B(D)，写的是“由D分解得到的B”，而不是“普通的B”。这会影响到后续的安全需求分配、硬件随机失效量化指标和软件开发的流程要求。评审的时候如果括号丢了，审核员会直接开不符合项，因为需求的来源不透明了。
工程落地时，光有分解表和独立性拍胸脯是不够的，必须有文档化的证据。我在项目里一般要求做两类文档：一是独立性论证表，针对每个被分解的安全目标，列出两条路径在物理资源、电气资源、信号路径、执行机制上的独立性；二是CCF（Common Cause Failure，共因失效）分析检查表，逐项检查是否存在可能同时影响两条路径的共同原因，比如共享时钟、共享供电、共享复位电路、共享软件需求、共享开发工具。
只有这两类文档都能充分回答，ASIL分解才能正式生效。否则的话，哪怕你分解表写得再漂亮，本质上也只是一个自我安慰。
3.3 软件ASIL分解：先回答四个问题再动手
软件层面的ASIL分解在ISO 26262中是允许的，但实操中我发现很多项目做得勉强，因为软件“多样性冗余”的代价极高。
在做软件分解之前，我要求团队先回答四个问题：
第一，两条软件路径在运行时真的隔离吗？这个隔离包括时间隔离和空间隔离。如果两条路径跑在同一个CPU上，一个路径上的任务死循环卡死，会不会把另一个路径饿死？RAM被一个路径写脏，会不会破坏另一个路径的数据？必须有MPU/MMU的强制隔离，加上调度表的约束，不能只靠“编程约定”。
第二，两条路径的设计足够多样吗？比如一条路径用传统的PI控制器，另一条路径用不同原理的算法；或者两条路径用不同的方程/查表方式。如果共用同一个需求规格但由不同团队实现，也要考虑需求误解是否具有传染性。
第三，两条路径的失效模式是否真的独立？比如两条路径都在同一个内存区域里存放常量表，那一个内存破坏事件，很可能同时影响两条路径的查表计算。
第四，额外的多样性开发成本值得吗？在真实的项目里，软件ASIL分解往往意味着一套完整的备份软件，代码量翻倍、测试翻倍、维护翻倍，而ASIL D降为B(D)的收益可能并不足以覆盖这些成本。
我做过的项目里，软件ASIL分解真正成功的，通常只有两种情况：一种是安全目标本身要求两个独立冗余通道（比如双MCU架构里的两个独立软件版本），分解是顺水推舟；另一种是有现成的第二套算法库可以复用。否则，大多数情况下，还是老老实实单路径高ASIL开发，少做梦、多降险。
4. 硬件量化指标：SPFM、LFM、PMHF怎么算，怎么防不达标
4.1 三个指标的物理意义与目标值
硬件架构这块，ISO 26262给了一个“能不能过评审”的量化标尺，就是SPFM、LFM和PMHF。这三个指标分别对应三种不同的失效类型。
SPFM（Single-Point Fault Metric，单点故障度量）衡量的是“单点故障”：某个硬件失效一旦发生，不经过任何其他条件，直接违反安全目标，而且没有安全机制能检测或控制它。这类故障是最危险的，所以SPFM目标值定得很高。
LFM（Latent Fault Metric，潜在故障度量）衡量的是“潜伏故障”：某个硬件失效发生后，系统暂时还能工作，但它已经存在了，如果在这段时间里又出现第二个故障，就可能导致违反安全目标。这种故障能不能在潜伏期被定期检查发现，决定了LFM的高低。
PMHF（Probabilistic Metric for Random Hardware Failures，随机硬件失效概率度量）是从整个系统概率维度来算的：所有安全相关的随机硬件失效，最终平均每小时的失效概率是多少。
| ASIL | SPFM目标 | LFM目标 | PMHF目标 |
|---|---|---|---|
| ASIL B | ≥ 90% | ≥ 60% | < 100 FIT |
| ASIL C | ≥ 97% | ≥ 80% | < 100 FIT |
| ASIL D | ≥ 99% | ≥ 90% | < 10 FIT |
FIT单位可能不直观。1 FIT等于10亿个设备小时里发生1次失效。假设一个部件是100 FIT，按每辆车一年运行2000小时估算，一万辆车里每年大概有2个这样的部件会失效。这个单位就是把很小很小的概率放大成一个整数来比较，方便做工程判断。
4.2 FMEDA和SPFM/LFM的手算实例
FMEDA是计算这些指标的主要方法，全称是Failure Mode Effects and Diagnostic Analysis。简单说就是把每个元件的每一种失效模式列出来，标上失效率、失效模式占比、有哪些安全机制来覆盖，然后计算覆盖率，最后汇总成系统级指标。
拿一个简化的电源监控链路举个例子，假设它承担ASIL D的安全功能，目标SPFM ≥ 99%。
监控芯片的总失效率λ是100 FIT，其中安全相关失效占80%，也就是80 FIT。安全机制的诊断覆盖率DC是90%。那么：
- 剩余没有被安全机制覆盖的残余故障：λ_RF = 80 FIT × (1 - 0.9) = 8 FIT
- 假设没有单点故障，SPF = 0
- SPFM = 1 - (SPF + RF) / 安全相关失效 = 1 - 8 / 80 = 90%
这个结果距离ASIL D要求的99%差了很远。怎么改进？
有两条路。一是提高诊断覆盖率。如果加了BIST自检，覆盖率提升到95%，RF = 80 × 0.05 = 4 FIT，SPFM = 95%，还是不够99%。要达标的话，需要把残余故障压到80 × 0.01 = 0.8 FIT以下，也就是说覆盖率要到99%以上，这在实际电路里非常难做到。
第二条路是换用失效率更低的芯片，并增加额外独立的安全机制。把监控芯片总失效率降到40 FIT，安全相关失效32 FIT，再叠加一个副监控路径使得原来暴露的残余故障有50%被二次覆盖，那残余的就是32 × 0.1 × 0.5 = 1.6 FIT，SPFM = 1 - 1.6 / 32 = 95%。还是差一点。这就是为什么ASIL D的99%在很多硬件方案里都不是白来的。
我在实操中总结的经验是：SPFM不是靠单一机制堆出来的，而是靠“元件本身低失效率 + 多级安全机制链条 + 机制自身高覆盖率”三个条件同时满足。哪个缺了，指标就难看。
4.3 PMHF的计算方法与重复覆盖陷阱
PMHF的计算比SPFM/LFM更宏观一些，它把所有硬件的随机失效概率汇总成一个数字。
一个标准的PMHF分解式长这样（用FIT作单位）：
PMHF = Σ(单点故障失效率 + 残余故障失效率) + Σ(潜在故障失效率 × 暴露时间系数) + Σ(多点/级联故障的失效率)
潜在故障不能直接按全失效率计入，因为它只在潜伏期内有效。如果周期性自检每20秒做一次，那潜在故障的暴露时间系数近似是10秒，换算成小时等于10/3600 ≈ 0.00278小时。所以一个潜伏失效率100 FIT的故障，对PMHF的贡献只有0.278 FIT左右。这也是LFM比较难以达到但PMHF可能达标的原因之一。
这里有个常见的坑：重复覆盖。FMEDA表格里，同一个元件的某个失效模式被写了两个安全机制，而计算的时候把两个机制的覆盖率简单相加。比如安全机制A覆盖率80%，安全机制B覆盖率60%，最后填了140%——这是不可能的。正确做法是：如果两个安全机制串联（A检测完B再检测），总覆盖率 = 1 - (1 - 0.8) × (1 - 0.6) = 92%；如果是并联（A或B任一能检测），总覆盖率 = max(0.8, 0.6) 或按实际冗余逻辑算。FMEDA里搞不清这一点，PMHF算出来虚低，看起来“达标了”，但真实故障场景下系统并没有那么安全。
架构评审时我一般会随机抽几个FMEDA行，问团队：这个失效模式的加数逻辑是什么，覆盖率哪里来的，暴露时间系数怎么定的。回答不了就证明计算人员也没有吃透模型，这份报告基本就不能信了。
5. 软件架构的安全落地：隔离、分区、组件鉴定
5.1 干扰自由：时间和空间隔离必须由机制保证，不能靠自觉
软件架构的安全设计，核心词是“Freedom from Interference”，也就是干扰自由。它的意思是：不同ASIL等级的软件组件放在同一个芯片上运行时，高ASIL的组件不能因为低ASIL组件出问题而受到牵连。
这句话说起来容易，落在架构上就是两个隔离维度。
空间隔离：每个软件分区要有独立的地址空间，通过MPU（Memory Protection Unit）或者MMU来强制隔离。低ASIL任务不能写高ASIL任务的内存区域，哪怕程序指针跑飞也不行。这里我特别强调“由硬件强制隔离，而非编程规范”。很多团队依赖“我们规定不允许跨模块访问”，但那只是纸面约束。程序指针一旦跑飞，什么规范都不管用，只有MMU/MPU的异常机制能把非法访问拒之门外。
时间隔离：高ASIL任务必须按时执行，不能被低ASIL任务卡死。实操中常用固定周期的分区调度表（Schedule Table），每个分区在自己的时间窗口内运行，窗口切换由硬件定时器触发。同时还要做WCET（最坏执行时间）分析，证明高ASIL任务在自己的窗口内一定能跑完。
我自己踩过的一个坑是：一个低ASIL的故障诊断模块，在某个异常输入下进入了某个很少执行的慢路径，CPU时间被吃掉了两倍于预算，导致高ASIL任务的截止时间差点被突破。后来加了超时看门狗才兜住，但最根本的修复是给诊断模块的执行时间设上限，超了就把它挂起，而不是让它贪吃CPU。
5.2 软件分区常用安全机制：E2E保护、程序流监控、RAM测试
软件层安全机制里，最常见也最实用的几类我先列一下：
E2E保护（End-to-End Protection）：适用于跨ECU或跨进程通信。对关键报文做CRC校验、序列号递增、超时监控、数据有效位检查。这里要注意，ASIL等级不同，E2E保护库的配置也不同，长度和校验方式都跟着变。不要自己手搓CRC多项式或者自由发挥，直接复用标准库，否则和网关消息定义对不上，报税会从测试阶段一路报到量产。
程序流监控（Function Call Monitoring）：监控关键函数的执行顺序和执行时间，可以检测到程序跑飞、跳转到错误分支、循环异常等故障。这个机制的覆盖率取决于监控点的密度，只监控主循环节拍是最弱的，最好能在安全相关关键函数前后都埋探针。
RAM自检和Flash校验：RAM用March C等算法做上电测试和周期测试，Flash用CRC校验或双Bank机制确保代码完整性。
信号合理性检查：对传感器信号做范围、斜率、一致性交叉检查。比如油门踏板信号通常有两个通道，两个通道的电压比例关系固定，检查这个比例就可以覆盖单通道漂移故障。
这些机制放在架构图上的时候，我要强调一点：每个软件安全机制必须有明确的触发条件、响应动作和对接口口。比如E2E检测到校验错误之后，是丢弃报文、使用上一帧数据、还是进入降级模式？这个必须在软件架构设计文档里写清楚，否则到实现阶段，开发人员只能自己拍脑袋。
5.3 软件组件鉴定：复用第三方软件时的保命手段
软件组件鉴定（Software Component Qualification）这个话题，凡是做功能安全的都会遇到，因为几乎没有项目是从零开始写所有代码，总要复用OS、通信栈、诊断协议栈这类第三方组件。
ISO 26262里的做法是：如果这个组件本身没有按照你的目标ASIL等级开发，你可以通过“软件组件鉴定”来补充证据，证明它在你的目标硬件和使用场景下能满足安全需求。也就是说，你不是直接拿供应商的声明当结论，而是在自己的系统里做一次有针对性的验证。
软件组件鉴定报告通常包含几个部分：鉴定计划（界定范围、测试策略、使用场景）、测试报告（功能测试、鲁棒性测试、资源消耗测试、故障注入测试）、评估结论（是否可用于目标ASIL等级以及有哪些遗留风险）。
实操建议是：动辄要求供应商提供全套ISO 26262流程文档不一定现实，重点要落在“组件失效是否会影响安全目标”这个判断上。一个日志打印组件，它出问题顶多是日志丢了几条，你根本不用做鉴定；但一个内核调度器，它出问题整个系统的“及时性”就崩了，这个必须认真做。
故障注入测试在组件鉴定里尤其关键。在我的项目里，做OS调度器的鉴定时，会系统地往内存、寄存器、任务状态里注入错误，观察调度器能不能在指定时间内完成异常处理并恢复关键任务调度。故障注入没有一个还测一个，数据全部记录到鉴定报告里，作为“这个组件在本系统中可满足目标ASIL要求”的核心论据。
6. 架构评审中的高频问题与避坑经验
6.1 架构评审常见问题速查表
评了几十次功能安全架构，我把高频问题整理成了一张速查表，分享出来供大家对照自查：
| 评审中发现的问题 | 根因分析 | 应对建议 |
|---|---|---|
| 安全机制列了一堆，但覆盖率偏低 | 只堆机制数量，没做FMEDA量化 | 先算指标，指标不过再补机制，而不是反着来 |
| ASIL分解后需求直接丢了括号标注 | 需求管理工具没有来源字段 | 需求工具里加“ASIL来源”必填字段 |
| FTTI和FDTI/FRTI时间对不上 | 架构设计走在时间预算之前 | 把时间预算表作为架构设计输入文档约束 |
| 安全机制没有自身诊断设计 | 只盯着主安全链，忽略机制自身失效率 | FMEDA中机制自身失效率单列，覆盖率要有依据 |
| 软件分区只在文档里写，运行时无强制隔离 | 早期没确认MCU是否支持MMU/MPU | 芯片选型阶段就把隔离能力列为硬性要求 |
| PMHF计算里同一个失效被两个机制重复覆盖 | FMEDA表格建模逻辑不清 | 明确每个机制的覆盖对象，重复覆盖按串联公式折算 |
| 备选方案对比缺失，评审无法判断架构决策合理性 | 只画了最终方案，没记录过程 | 架构文档强制包含“已放弃方案及理由”章节 |
这张表里，我最想提醒的是最后一行的备选方案对比。很多项目负责人觉得“我们最终方案是合理的就行，为什么还要写我放弃的方案”。实际上审核员看备选方案章节，看的正是设计团队是不是真正权衡过风险。哪怕你只是简单写了两行“方案A因为成本高放弃，方案B因为诊断覆盖率不足放弃，最终选C”，都比一个字不写强得多。
6.2 架构评审中我必问团队的三件事
第一件事，画一条完整的安全链时序图。从传感器故障发生开始，到检测、确认、降级、进入安全状态，每一步的时限和ASIL等级标出来。这条时序图比任何架构图都更能暴露设计缺陷。
第二件事，现场说明FMEDA中每一条覆盖率数据的来源。说不上来就重新算，这是功能安全工程师的基本功，不能拿“工具就是这样生成的”敷衍。
第三件事，验证一遍“方案已放弃的记录”。看看早期有没有认真比较过双通道和非双通道、独立监控芯片和软件监控、分区调度和裸跑轮询等备选方案。没有对比记录的本质，是设计决策还没有被真正审视过。
6.3 架构设计的三个独门心得
第一个心得，架构评审不要只评“现状”，还要评“未来变化代价”。比如你现在设计的架构，如果后续ASIL等级从B升到D（比如BMS项目加了一个新的安全目标），哪些模块需要推翻重做？这个问题的答案直接决定架构的扩展性。好的架构设计会在芯片选型时预留隔离资源和算力余量。
第二个心得，架构设计文档里除了“设计内容”，一定要有“设计边界”。比如时间预算表里要写明“本设计假设传感器信号刷新周期不大于10ms”，如果这个假设破了，整个时间链都要重新核算。设计边界写清楚了，后面任何接口变更都有据可依，不用整个团队开会对“这个参数变了到底影响多大”争论半天。
第三个心得，架构设计阶段就要把安全验证方法想好。每个安全机制对应到验证阶段用什么方法确认，是故障注入、软件在环仿真还是实车测试。如果你在架构阶段就发现某个安全机制在后期几乎无法验证，那就趁早换方案。等到代码写完再来想验证，等于给项目埋雷。
功能安全架构做到这个份上，说穿了就是把“安全”这两个抽象的字，翻译成一张张可以算、可以测、可以追的工程表格和决定。真正让一个架构方案成熟的，不是某个公式用得多熟练，也不是文档模板套得多标准，而是在项目初期就把独立性问题、时间预算、FMEDA覆盖率、隔离能力这些硬约束想清楚，在评审会上能理直气壮地解释“为什么这里要双通道”“为什么这个机制够了”“为什么ASIL分解站得住”。
我个人在做架构评估时，最看重的其实是一个信号：团队能不能在架构评审会上，不需要看PPT就能通盘讲清楚整个安全链的来龙去脉。能讲清楚，架构大概率是扎实的；讲不清楚，哪怕指标都达标了，也只是纸面上的达标。做功能安全架构，最终求的是一份系统性的明白，而不是几个数字的体面。
