【汽车芯片功能安全分析与故障注入实践 04】IEC 62380 与 SN29500：FIT 模型如何工程化落地？

作者：Darren H. Chen
方向：汽车芯片功能安全分析与故障注入实践
Demo：D04_fit_standard_models
标签：汽车芯片功能安全FIT模型IEC62380SN29500Mission Profile

Demo 说明

D04_fit_standard_models的目标是把 FIT 模型从“标准条文”转化为可配置、可审计、可替换的工程模块。

对应的通用工具名称为：

safeic-fitmodel

本 Demo 不追求一开始完整实现所有标准细节，而是先建立一个清晰的工程框架：

reliability input data + design statistics + model resolver + FIT computation + verbose report = explainable FIT model engine

1. 为什么 FIT 模型需要工程化

在功能安全分析中，FIT 不是一个孤立数字。

它依赖很多输入：

工艺类型 单元类型 晶体管数量或 memory bit 数量 温度条件 mission profile 制造年份 封装假设 永久故障模型 瞬态故障模型

如果这些输入都硬编码在脚本里，后续会出现严重问题：

不同项目无法复用 不同模型无法对比 参数来源不可追溯 报告结果难以审查 商用工具对比困难

因此，FIT 模型要工程化，就必须把模型、参数、设计统计和报告分离。

2. IEC 62380 与 SN29500 的工程差异

从工程使用角度看，可以把两类模型理解为不同的 FIT 计算策略。

这里不需要一开始实现标准的全部细节。对于实践平台，第一阶段更重要的是：

模型接口统一 输入参数显式 计算过程可展开 输出报告可审查

后续如果需要更高精度，可以逐步替换模型内部实现。

3. FIT 模型的四层输入

一个可维护的 FIT 模型输入可以拆成四层。

3.1 Design Statistics

设计规模统计，例如：

{"stdcell_gate_count":1200,"sequential_count":96,"memory_bits":2048,"analog_block_count":0,"blackbox_count":1}

3.2 Technology Data

工艺和 lambda 参数，例如：

process:default:MOS.ASIC.STDCELLlambda:MOS.ASIC.STDCELL:permanent_per_gate:1.0e-6transient_per_gate:1.0e-6MOS.STD.SRAM:permanent_per_bit:1.7e-7transient_per_bit:1.0e-6

3.3 Mission Profile

使用场景，例如：

mission_profile:name:passenger_compartmenttemperature_ja:65active_ratio:0.80dormant_ratio:0.20

3.4 Model Configuration

选择模型：

fit_model:standard:simplified_iec62380include_transient:trueinclude_permanent:trueverbose:true

这四层分开后，模型才可复用、可替换、可对比。

4. FIT 模型引擎的内部架构

safeic-fitmodel不应该写成一个长脚本，而应该分成几个清晰组件。

其中：

5. 为什么需要 verbose report

FIT 计算最怕只输出一个总数。

例如：

Total FIT = 0.128

这个结果单独看意义不大。工程师更需要知道：

stdcell 贡献多少？ sequential 贡献多少？ memory 贡献多少？ permanent 和 transient 分别是多少？ 用了哪个 lambda？ 用了哪个 temperature factor？ 用了哪个 mission profile？

因此，safeic-fitmodel必须输出 verbose report。

示例：

FIT Model: simplified_iec62380 Top: toy_soc Stage: rtl Mission Profile: passenger_compartment TemperatureJA: 65 Breakdown: - STD Cell permanent FIT: 0.0012 - FF transient FIT: 0.0960 - SRAM transient FIT: 0.0020 - Total permanent FIT: 0.0012 - Total transient FIT: 0.0980

verbose report 的作用是让计算结果可以被审查，而不是只被相信。

6. 模型不应和设计绑定

一个常见错误是把 FIT 参数写进设计脚本里。

这会导致：

换设计时要改脚本 换标准时要改代码 换 mission profile 时结果不可追溯

更好的做法是：

design_stats.json：描述设计 technology.yaml：描述工艺和 lambda mission_profile.yaml：描述使用条件 model_config.yaml：描述计算模型

这样同一个设计可以跑不同模型：

safeic-fitmodel--modelsimplified_iec62380 safeic-fitmodel--modelsimplified_sn29500

输出可以对比：

fit_compare.csv

这就是 Demo D04 的关键价值。

7. FIT 模型与 DC 模型的关系

FIT 模型回答的是：

随机硬件故障风险有多大？

DC 模型回答的是：

这些风险中有多少被安全机制覆盖？

两者必须分开。

如果把 FIT 和 DC 混在一起，后续很难判断是失效率模型问题，还是安全机制覆盖率问题。

因此：

D04 只负责 FIT 模型工程化 D08 才负责 Diagnostic Coverage Engine

8. Demo 输出文件设计

D04_fit_standard_models的建议目录：

D04_fit_standard_models/ README.md run_demo.csh run_demo.sh inputs/ design_stats.json technology.yaml mission_profile.yaml model_config_iec.yaml model_config_sn.yaml outputs/ fit_model_iec_detail.csv fit_model_sn_detail.csv fit_model_compare.csv verbose_fit_iec.md verbose_fit_sn.md scripts/ safeic_fitmodel.py

输出的fit_model_compare.csv可以类似：

model,total_permanent_fit,total_transient_fit,total_fit simplified_iec62380,0.0012,0.0980,0.0992 simplified_sn29500,0.0010,0.0950,0.0960

这为后续商用工具对比提供基础。

9. 方法论：先建立模型接口，再追求模型精度

在实际工程中，很容易陷入一个误区：一开始就追求完整实现标准模型。

这会导致项目启动很慢，而且很难验证框架是否合理。

更稳妥的方法是：

第一步：建立模型输入输出接口 第二步：实现 simplified model 第三步：输出 verbose report 第四步：用 toy design 验证数据流 第五步：逐步替换为更精确模型

这种方法的优势是：

工具架构先稳定 Demo 可以尽早跑通 文章可以持续发布 软著材料可以提前沉淀 专利交底书可以围绕方法闭环展开

10. 方法论总结

FIT 模型不是一个公式，而是一个工程系统。

它至少包含：

设计规模统计 工艺与 lambda 数据 温度与 mission profile 模型选择 永久故障计算 瞬态故障计算 分项贡献报告 详细计算追溯

D04_fit_standard_models的价值是把这些内容拆成清晰、可配置、可对比的工程模块。

后续的D05_arch_rtl_netlist_flow会继续解决另一个问题：

同一个设计在 architecture、RTL、netlist 三个阶段，FIT 输入和统计结果如何保持一致？

只有解决了这个问题，FIT 模型才能真正进入完整设计流程。