【汽车芯片功能安全分析与故障注入实践 01】汽车芯片功能安全验证到底验证什么？

作者： Darren H. Chen
方向： 汽车芯片功能安全分析与故障注入实践
Demo： D01_safeic_closed_loop
标签： 汽车芯片、功能安全、SafeIC、故障注入、FIT/DC、FMEDA、VCD

Demo 范围

D01_safeic_closed_loop 用于创建一个最小可复现的汽车芯片 Safe-IC 验证流程骨架。它的作用是把功能安全验证中的"证据流水线"显式化，包括项目 manifest、输入文件包、占位 fault list、alarm list、报告目录以及可执行脚本。

这个 Demo 并不实现 sign-off 级别的功能安全流程，而是定义一个工程基线，后续每个单一功能工具模块都可以消费这套输入、产生对应输出，并逐步形成完整工具链。

1. 为什么要做这件事

汽车芯片功能安全经常被一些高层概念描述，例如 ISO 26262、ASIL、FIT、FMEDA、诊断覆盖率、安全机制和故障注入。这些概念都很重要，但如果只停留在名词层面，就很容易和真正的工程问题脱节。

真正的问题是：

如果芯片内部发生一个随机硬件故障，设计能否检测它、容忍它、屏蔽它，或者证明它不会破坏安全目标？

这个仓库要构建的是一个实用、模块化、可解释的 Safe-IC 实践平台。目标不是复制任何商用工具，而是把功能安全验证流程拆解成小型、可检查、可测试、可演示、可扩展的工具模块。

第一个 Demo 定义基础框架：

text 复制代码

Design structure
+ safety mechanisms
+ operating context
+ fault model
+ fault campaign evidence
+ safety metric roll-up
= functional safety verification evidence

换句话说，功能安全验证不只是仿真。它是一条证据流水线。

2. 功能安全关注的是随机硬件故障，而不只是设计 bug

传统验证关心的是：设计是否正确实现了预期功能。

功能安全问的是另一个问题：

当设计本身已经功能正确时，如果硬件在运行过程中随机失效，会发生什么？

这个区别非常关键，因为系统性缺陷和随机硬件故障的处理方式不同。

系统性缺陷通常通过设计验证、代码审查、lint、CDC、形式验证、仿真、仿真加速、制造测试和硅后验证来处理。随机硬件故障则不同：它们可能发生在产品整个生命周期中，甚至发生在芯片已经出货之后。

因此，对于安全关键芯片，设计中必须包含 安全机制，例如 parity、ECC、lockstep comparison、watchdog、protocol checker、range checker、duplicated logic、triplication 或端到端数据保护。

一个功能安全平台至少要回答三个问题：

哪些地方的故障可能影响安全？

这是结构分析问题。
哪些安全机制覆盖了这些故障？

这是诊断覆盖率问题。
这些安全机制在真实激励下是否真的会响应？

这是故障战役问题。

Laycore SafeIC 将这些问题拆分成一条工具链，而不是隐藏在一个单体可执行程序内部。

3. 两条证据路径：指标估算与故障验证

一个实用的 Safe-IC 流程通常包含两条主要证据路径。

第一条路径是 指标估算。它回答：

text 复制代码

这个设计暴露在多少随机硬件失效风险下？
其中有多少风险被安全机制覆盖？
估算出的 FIT、SPFM、LFM、PMHF 和 DC 数值是多少？

第二条路径是 故障验证。它回答：

text 复制代码

如果在真实运行上下文中注入代表性故障，
哪些故障会被检测，哪些是安全的，哪些是不安全的，哪些仍无法解析？

这两条路径最终必须汇合。只有指标而没有故障证据，结果可能过于乐观；只有故障战役而没有指标汇总，则很难和 ASIL 目标建立联系。

核心闭环如下：
RTL / Netlist
Design Structure Analysis
FIT / DC Estimation
Fault List Generation
Simulation VCD / FSDB
Safety Context Extraction
Fault Campaign
Alarm / Observe Points
Fault Classification
Metric Validation
FMEDA / Safety Report

D01 关注的是在架构层面搭建这个闭环。每个方框后续都可以实现为一个独立命令行工具。

4. 自底向上的安全分析：从晶体管到 Endpoint

芯片规模太大，不能简单把它当作一个扁平黑盒来分析。功能安全分析需要一种方法，把底层硬件元素和高层安全目标连接起来。

一个有用的思维模型是：

text 复制代码

Elementary hardware element
    -> subpart
        -> part
            -> component
                -> system-level safety goal

在硬件分析层面，有三个结构概念特别重要。

4.1 Startpoint

Startpoint 是故障效应开始传播的位置。典型例子包括：

primary input，
state element output，
black-box output，
memory output。

4.2 Endpoint

Endpoint 是故障效应被观察或捕获的位置。典型例子包括：

state element input，
primary output，
black-box input，
memory input。

4.3 Cone

Cone 是 startpoint 和 endpoint 之间的组合逻辑。

这就形成了一个结构模型：
SP
Logic
SP
Logic
EP
EP

为什么这很重要？

因为并不是每个故障都具有相同的安全意义。一个发生在很小、很孤立 cone 中的故障，影响可能较低；而一个发生在高扇出控制路径上的故障，可能影响大量 endpoint，并成为残余风险的主要贡献源。

所以，第一条方法论规则是：

功能安全分析必须先结构化，再数值化。

没有结构，FIT 和 DC 数字就容易脱离真实设计。

5. FIT：衡量随机硬件失效的原始暴露量

FIT 是 Failure In Time 的缩写。1 FIT 表示十亿小时运行时间内发生一次失效。

在一个简化的工程模型中，芯片级 FIT 可以理解为各硬件元素失效暴露量的加权求和：

text 复制代码

FIT_design = sum(FIT_endpoint_i)

每个 endpoint 的贡献可能包括：

text 复制代码

endpoint storage element
+ fan-in combinational cone
+ related startpoints
+ memory or black-box contribution
+ technology / mission profile factors

完整的生产级计算可能涉及工艺相关 lambda 值、mission profile、温度因子、封装数据、永久故障模型和瞬态故障模型。在 Laycore SafeIC 中，第一版实现会刻意从一个简化、可审计的模型开始：

yaml 复制代码

process: MOS.ASIC.STDCELL
mission_profile: passenger_compartment_demo
logic_gate_transient_fit: 1.0e-6
ff_transient_fit: 1.0e-3
sram_bit_transient_fit: 1.0e-6

关键不是把 toy 公式伪装成 sign-off 模型。关键是先把数据路径搭正确：

text 复制代码

design statistics -> endpoint contribution -> metric report -> later replacement by calibrated model

一旦数据路径正确，数学模型可以继续替换和细化。

6. Diagnostic Coverage：衡量有多少风险被覆盖

安全机制并不会消除所有硬件故障。它只能检测、纠正、屏蔽或限制其中一部分故障。

Diagnostic Coverage，即 DC，表示相关故障暴露中被安全机制覆盖的比例。

一个简化形式是：

text 复制代码

DC = covered_fault_exposure / total_fault_exposure

但真实硬件中的覆盖率是结构化的。一个安全机制可能只覆盖 endpoint，也可能覆盖 endpoint 加 cone，也可能覆盖 endpoint、cone 和 startpoint。

例如：

Safety mechanism	Endpoint coverage	Cone coverage	Startpoint coverage	Typical idea
Endpoint parity	high	low	low	检查存储或传输值
Duplicated fan-in cone	high	high	low	比较重新计算得到的逻辑结果
Lockstep-like duplication	high	high	high	比较更大范围的状态迁移
ECC on memory	high	limited	limited	检测或纠正存储器 bit error

这就是为什么 Laycore SafeIC 会用结构化 library 来表达安全机制：

yaml 复制代码

ATD_EP_PARITY_DEMO:
  description: "Endpoint parity demonstration mechanism"
  permanent:
    ep_dc: 0.90
    sp_dc: 0.00
    cone_dc: 0.00
  transient:
    ep_dc: 0.90
    sp_dc: 0.00
    cone_dc: 0.00

DUP_CONE_DEMO:
  description: "Duplicated fan-in cone demonstration mechanism"
  permanent:
    ep_dc: 0.90
    sp_dc: 0.00
    cone_dc: 0.90
  transient:
    ep_dc: 0.90
    sp_dc: 0.00
    cone_dc: 0.90

方法很简单：

text 复制代码

不要给整个设计分配一个神奇的覆盖率数字。
要把覆盖率分配到安全机制实际保护的结构区域上。

7. Fault Campaign：把估算覆盖率转化为行为证据

指标估算是必要的，但还不够。安全机制必须在运行上下文中被测试。

Fault Campaign 会把故障注入到选定的安全关键节点上，并检查安全机制是否检测到了故障。

一个最小故障战役至少需要五类输入：

text 复制代码

1. Design files
2. Simulation context, such as VCD
3. Fault list
4. Alarm list
5. Observe point list or equivalent checking policy

概念数据流如下：
Fault List
Fault Campaign Engine
VCD Safety Context
Design Model
Alarm List
Observe Points
Fault Result Table
Detected
Safe
Unsafe
Unresolved

故障注入必须始终和 golden context 对比。golden context 是同样激励下的无故障行为。

在简化模型中：

text 复制代码

same design
same stimulus
same observation window
one injected fault
compare golden trace vs fault trace
check alarm behavior
classify result

第一版实现不需要专有的并行故障引擎。它只需要把证据模型显式化。

8. 四类核心故障结果

故障战役只有在结果分类清晰时才有价值。

Laycore SafeIC 使用四个顶层类别。

8.1 Detected

故障改变了机器状态或被观察值，并且配置的 alarm 在规定时间内触发。

text 复制代码

state differs from golden
+ alarm fires
= detected

8.2 Safe

故障没有影响安全相关机器状态，或者在产生影响之前被屏蔽。

text 复制代码

state does not differ from golden
or difference is not safety relevant
= safe

8.3 Unsafe

故障改变了安全相关状态或输出，但没有触发 alarm。

text 复制代码

state differs from golden
+ alarm does not fire
= unsafe

8.4 Unresolved

工具无法根据当前证据完成分类。常见原因包括仿真数据缺失、传播到黑盒、未建模的模拟行为、observe point 不足，或者运行上下文不完整。

text 复制代码

state differs or propagation is incomplete
+ evidence is insufficient
= unresolved

一个好的平台不应该隐藏 unresolved fault。它应该解释为什么 unresolved，并给出下一步 debug 建议。

9. 为什么要把平台拆成单一功能工具

商用功能安全工具通常是大型集成系统。这对于生产级 sign-off 流程是合理的，但对于学习、研究、Demo 构建和 IP 沉淀来说，并不是最理想的形态。

Laycore SafeIC 采用另一种架构：

text 复制代码

many small tools
+ stable file schemas
+ reproducible demos
+ composable flow runner

第一批工具包括：

Tool	Responsibility
`layfusa-init`	创建 SafeIC 项目骨架
`layfusa-inputcheck`	检查输入文件包是否完整
`layfusa-bfr`	计算简化 Base FIT Rate
`layfusa-structure`	提取 SP / EP / Cone 结构
`layfusa-dc`	根据安全机制映射计算诊断覆盖率
`layfusa-faultgen`	生成 stuck-at 和 transient fault list
`layfusa-vcdctx`	从 VCD 提取安全上下文
`layfusa-classify`	对故障战役结果进行分类
`layfusa-report`	生成可读报告

设计规则是：

text 复制代码

A tool should be replaceable without changing the rest of the flow.

例如，第一版 layfusa-bfr 可以使用简化 FIT 模型。后续可以替换成经过校准的 IEC 62380-like 或 SN29500-like 模型，同时保持输入输出 schema 不变。

10. 工具架构

平台架构可以分为五层。
Layer 1: Project and Input Layer
Layer 2: Structural Analysis Layer
Layer 3: Metric Layer
Layer 4: Fault Evidence Layer
Layer 5: Report and Benchmark Layer

Layer 1：项目与输入层

这一层用于标准化项目目录并检查必要输入文件。

text 复制代码

layfusa-init
layfusa-inputcheck

Layer 2：结构分析层

这一层把 RTL/netlist 信息转换成可分析的图结构数据。

text 复制代码

layfusa-designstats
layfusa-structure
layfusa-epcont

Layer 3：指标层

这一层估算 FIT、诊断覆盖率和 roll-up 指标。

text 复制代码

layfusa-bfr
layfusa-fitmodel
layfusa-dc
layfusa-dce

Layer 4：故障证据层

这一层创建并执行故障战役。

text 复制代码

layfusa-faultgen
layfusa-vcdctx
layfusa-campaign
layfusa-classify

Layer 5：报告与 Benchmark 层

这一层把原始数据转换为工程证据。

text 复制代码

layfusa-report
layfusa-benchmark

11. 项目 Manifest

项目 manifest 是工具之间的契约。

示例 manifest.yaml：

yaml 复制代码

project:
  name: D01_safeic_closed_loop
  top: toy_counter_safe
  asil_target: D

inputs:
  rtl_filelist: inputs/filelist.f
  clkdef: inputs/clkdef.clk
  vcd: inputs/sim.vcd
  fault_list: inputs/fault.list
  alarm_list: inputs/alarm.list
  observe_points: inputs/observe_points.list

safety:
  failure_modes: inputs/failure_modes.yaml
  safety_mechanisms: inputs/sm_library.yaml
  ep_to_sm_map: inputs/ep_to_sm_map.csv

outputs:
  database: outputs/safeic.sqlite
  report_dir: outputs/reports

manifest 看起来很简单，但它是平台中最重要的部分之一。它让流程可复现。

12. Demo D01：最小闭环项目

第一个 Demo 不计算真实 sign-off 指标。它的任务是创建后续所有 Demo 都会使用的可复现骨架。

text 复制代码

D01_safeic_closed_loop/
  README.md
  manifest.yaml
  run_demo.csh
  run_demo.sh
  inputs/
    rtl/
      toy_counter_safe.v
    filelist.f
    clkdef.clk
    fit_inputs.yaml
    failure_modes.yaml
    sm_library.yaml
    ep_to_sm_map.csv
    fault.list
    alarm.list
    observe_points.list
    sim.vcd
  outputs/
    safeic.sqlite
    reports/
      input_check.md
      flow_summary.md
  notes/
    article_outline.md
    soft_copyright_notes.md
    patent_notes.md

第一个 CLI 命令是：

bash 复制代码

layfusa-init --project D01_safeic_closed_loop --top toy_counter_safe

预期输出：

text 复制代码

[LAYFUSA] project created: D01_safeic_closed_loop
[LAYFUSA] manifest created: manifest.yaml
[LAYFUSA] input directories created
[LAYFUSA] output directories created
[LAYFUSA] next step: layfusa-inputcheck --manifest manifest.yaml

兼容 csh 的版本：

csh 复制代码

#!/bin/csh -f
set PROJECT = D01_safeic_closed_loop
set TOP = toy_counter_safe

layfusa-init --project $PROJECT --top $TOP
layfusa-inputcheck --manifest $PROJECT/manifest.yaml

这部分故意保持基础。安全平台必须先可复现，然后才能复杂化。

13. 方法论：分离估算、证据和报告

一个常见错误是把所有内容混合成一个输出数字。

Laycore SafeIC 将三类 artifact 分开。

13.1 估算类 artifact

这些 artifact 来自结构和指标模型。

text 复制代码

design_stats.json
structure_graph.json
ep_contribution.csv
base_fit_report.csv
dc_report.csv

13.2 证据类 artifact

这些 artifact 来自仿真和故障战役。

text 复制代码

vcd_context.json
fault.list
campaign_result.raw.csv
fault_result.csv
class_summary.csv

13.3 报告类 artifact

这些 artifact 是面向人的交付物。

text 复制代码

metric_summary.md
fault_report.html
fmeda_summary.xlsx
benchmark_score.md

规则是：

text 复制代码

Never let a report become the source of truth.
The database and intermediate machine-readable artifacts are the source of truth.

也就是说，不要让报告成为唯一事实来源。数据库和中间机器可读 artifact 才是事实来源。

14. 数据模型预览

第一版数据库可以使用 SQLite。

最小表结构：

sql 复制代码

CREATE TABLE project (
  id INTEGER PRIMARY KEY,
  name TEXT,
  top TEXT,
  asil_target TEXT
);

CREATE TABLE endpoint (
  id INTEGER PRIMARY KEY,
  path TEXT,
  type TEXT,
  bit_width INTEGER,
  cone_size INTEGER
);

CREATE TABLE safety_mechanism (
  id INTEGER PRIMARY KEY,
  name TEXT,
  ep_dc REAL,
  sp_dc REAL,
  cone_dc REAL
);

CREATE TABLE fault (
  id INTEGER PRIMARY KEY,
  node TEXT,
  fault_type TEXT,
  inject_time INTEGER,
  duration INTEGER
);

CREATE TABLE fault_result (
  id INTEGER PRIMARY KEY,
  fault_id INTEGER,
  result_class TEXT,
  fail_time INTEGER,
  alarm_time INTEGER,
  rationale TEXT
);

这个数据库不只是用来存储。它是可追溯性的基础。

可追溯性很重要，因为安全证据必须回答：

text 复制代码

Which design version?
Which safety mechanism?
Which fault list?
Which stimulus?
Which alarm?
Which result?
Which report?

15. 本文不主张什么

D01 不是 sign-off 流程。

它不主张替代商用功能安全工具，不主张 ISO 26262 认证，不实现生产级 FIT 模型，也不实现高性能并行故障引擎。

它建立的是工程基础：

text 复制代码

clear concepts
clean tool boundaries
stable file schemas
reproducible demo structure
traceable artifacts

这个基础有价值，因为后续能力可以在不改变核心方法论的情况下逐步加入。

16. 总结

功能安全验证不是一个工具命令。它是一个结构化证据系统。

底层方法论是：

text 复制代码

1. Understand the design structure.
2. Identify where random hardware faults can matter.
3. Estimate the raw FIT exposure.
4. Map safety mechanisms to protected structural regions.
5. Estimate diagnostic coverage.
6. Generate representative fault lists.
7. Inject faults under realistic safety context.
8. Classify results as detected, safe, unsafe, or unresolved.
9. Roll the evidence back into safety metrics and FMEDA.
10. Preserve everything as reproducible artifacts.

实践平台从这个方法论出发，并围绕它构建模块化工具链。

第一个工具 layfusa-init 会刻意保持简单。它创建项目骨架，使后续流程具备可复现性。

在安全工程中，可复现性不是便利功能，而是证据的起点。

附录：D01 验收标准

当满足以下条件时，D01 Demo 可以认为完成：

layfusa-init 可以创建标准目录树。
manifest.yaml 可以生成。
run_demo.csh 和 run_demo.sh 可以生成。
占位输入文件可以创建。
layfusa-inputcheck 可以报告哪些输入存在、哪些输入缺失。
outputs/reports/flow_summary.md 可以生成。
项目可以直接提交到 GitHub，作为可复现 Demo。