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

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

Demo 说明

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

对应的通用工具名称为：

text 复制代码

safeic-fitmodel

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

text 复制代码

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

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

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

它依赖很多输入：

text 复制代码

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

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

text 复制代码

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

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

2. IEC 62380 与 SN29500 的工程差异

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

维度	IEC 62380 思路	SN29500 思路
关注重点	mission profile、温度、工艺、封装等综合影响	reference condition 到 operating condition 的转换
输入复杂度	相对更复杂	相对更结构化
工程实现	需要更多项目参数	适合模型化封装
Demo 处理	simplified_iec62380	simplified_sn29500

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

text 复制代码

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

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

3. FIT 模型的四层输入

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

3.1 Design Statistics

设计规模统计，例如：

json 复制代码

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

3.2 Technology Data

工艺和 lambda 参数，例如：

yaml 复制代码

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

3.3 Mission Profile

使用场景，例如：

yaml 复制代码

mission_profile:
  name: passenger_compartment
  temperature_ja: 65
  active_ratio: 0.80
  dormant_ratio: 0.20

3.4 Model Configuration

选择模型：

yaml 复制代码

fit_model:
  standard: simplified_iec62380
  include_transient: true
  include_permanent: true
  verbose: true

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

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

safeic-fitmodel 不应该写成一个长脚本，而应该分成几个清晰组件。
design_stats.json
safeic-fitmodel
technology.yaml
mission_profile.yaml
model_config.yaml
Model Resolver
Permanent FIT Calculator
Transient FIT Calculator
FIT Breakdown
fit_model_detail.csv
verbose_fit.md
fit_model_result.json

其中：

组件	功能
Input Loader	读取设计规模、工艺、mission profile、模型配置
Model Resolver	根据配置选择 simplified IEC 或 simplified SN 模型
Permanent FIT Calculator	计算永久失效贡献
Transient FIT Calculator	计算瞬态失效贡献
Breakdown Generator	按模块/类型输出贡献
Verbose Reporter	输出详细计算过程

5. 为什么需要 verbose report

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

例如：

text 复制代码

Total FIT = 0.128

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

text 复制代码

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

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

示例：

text 复制代码

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 参数写进设计脚本里。

这会导致：

text 复制代码

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

更好的做法是：

text 复制代码

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

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

bash 复制代码

safeic-fitmodel --model simplified_iec62380
safeic-fitmodel --model simplified_sn29500

输出可以对比：

text 复制代码

fit_compare.csv

这就是 Demo D04 的关键价值。

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

FIT 模型回答的是：

text 复制代码

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

DC 模型回答的是：

text 复制代码

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

两者必须分开。
Design Statistics
FIT Model
Raw Failure Exposure
Safety Mechanism Map
DC Model
Covered / Residual Failure

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

因此：

text 复制代码

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

8. Demo 输出文件设计

D04_fit_standard_models 的建议目录：

text 复制代码

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 可以类似：

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. 方法论：先建立模型接口，再追求模型精度

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

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

更稳妥的方法是：

text 复制代码

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

这种方法的优势是：

text 复制代码

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

10. 方法论总结

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

它至少包含：

text 复制代码

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

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

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

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

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