功能安全 Functional Safety

概念解析

定义与起源

术语定义：功能安全(Functional Safety，FuSa)是系统在发生故障时——能进入或保持安全状态——不伤害人、不损坏环境的能力。在汽车领域——ISO 26262定义了功能安全的框架；在工业领域——IEC 61508；在航空领域——DO-254。功能安全的核心不是"让系统不出故障"——是"故障后系统仍然安全"。

对IC设计来说，功能安全意味着：芯片必须内置硬件安全机制(safety mechanism)——在检测到故障时——把系统切换到安全状态(fail-safe)——或者至少通知上层系统(fail-operational)。这些机制包括：双核锁步(DCLS)、ECC/Parity、LBIST、MBIST、时钟监测、电压监测、温度监测。

核心要义

第一，功能安全=故障检测+故障响应。 检测：硬件安全机制周期性检查芯片是否正常工作——LBIST检测逻辑故障、MBIST检测SRAM故障、ECC检测存储器bit翻转、时钟监测检测PLL失锁。响应：检测到故障后——系统必须在FTTI(Fault Tolerant Time Interval，故障容忍时间窗口)内进入安全状态——通常<100ms。

第二，ASIL等级=故障检测覆盖率要求。 ASIL B:单点故障度量(SPFM)≥90%。ASIL D:SPFM≥99%——意味着99%的单点故障必须被安全机制覆盖。这需要：冗余(两个核同时算→结果比较)、ECC(纠正单bit错误)、LBIST(检测逻辑故障)、软件自检。

第三，安全论证(Safety Case)是功能安全的最终交付物。 不是跑一遍FMEDA就完了——你需要用FMEDA+故障注入(fault injection)+故障仿真(fault simulation)证明：你的安全机制覆盖了所有危险故障模式——且覆盖率达到了ASIL等级要求。这是一个完整的论证书。

实践应用

* FMEDA是功能安全的"账本"：记录每个模块的每种故障模式、它的影响(安全相关的?)、被哪个安全机制覆盖——计算SPFM和LFM。 * 故障注入是验证安全机制的手段：故意在网表中注入故障(翻转一个bit)→看安全机制是否检测到→记录检测结果。 * 功能安全=全流程约束：从需求→架构→设计→验证→生产——每个阶段都有功能安全的审查。

实战案例

• 某ADAS芯片的ASIL D之路：初始SPFM=94%——分析后最大的gap是SRAM软错误(无ECC)和逻辑故障(无LBIST)。加ECC→SPFM=97%。加LBIST→99.1%——达标。

• 故障注入暴露了隐蔽gap：FMEDA认为某个故障被watchdog覆盖——但故障注入显示watchdog的timeout窗口内系统已经输出了错误数据——故障不是"安全"的。加硬件比较器后覆盖真正有效。

• 时钟故障漏算的教训：FMEDA只考虑了逻辑和存储器故障——没考虑时钟。PLL失锁后CAN通信完全中断——车辆进入limp mode。补时钟监测后SPFM提升了0.5%。

常见误区

误区一：功能安全=双核锁步。 DCLS只是安全机制的一种。功能安全是系统工程——从需求到验证的完整方法论。

误区二：SPFM达标=安全。 SPFM计算的是随机硬件故障覆盖率——不包括系统性故障(设计bug)。系统性故障需要靠流程(ASPICE、开发流程管理)来保证。

误区三：功能安全=认证机构的事。 功能安全必须内建在芯片设计中——认证机构只是"审计"。芯片设计不能把安全责任推给系统级——因为很多故障模式只在芯片级可检测。