【汽车芯片功能安全分析与故障注入实践 21】Safety Synthesis Readiness：从分析证据到安全综合入口
作者：Darren H. Chen
方向：Automotive Safe-IC / Functional Safety / EDA Automation / ISO 26262 Closure
demo：demos/D21_safety_synthesis_readiness
标签：汽车芯片、功能安全、ISO 26262、Safe-IC、Safety Synthesis、FMEDA、Fault Campaign、EDA Automation、Evidence Closure
01. 本篇定位：安全综合前的工程入口闸门
D01-D20 已经完成了 Safety Analysis、Fault Campaign、FMEDA、Evidence Database 相关主线，核心目标是回答三个问题：
- 芯片设计中哪些结构对随机硬件故障敏感；
- 已有安全机制对这些故障的覆盖能力如何；
- 当前证据是否足以支撑 ISO 26262 closure。
D21 进入新的阶段：Safety Synthesis Readiness。
这一阶段不急着插入安全机制，而是先把前面产生的分析证据、故障注入结果、FMEDA 数据、设计结构信息整理成一个可执行的安全综合入口包。D22、D23、D25 会分别展开 Macro-level Safety Synthesis、Micro-level Safety Synthesis 和 Safety Synthesis Testbench Generation，但 D21 是它们共同的前置工程关口。
可以把 D21 理解成：
把"安全分析结论"转换成"安全综合任务书"。
如果没有 D21，后续安全综合很容易变成孤立的 RTL 修改；有了 D21，安全综合会变成可追踪、可复现、可审查、可回归的工程流程。
02. Safety Synthesis Readiness 的核心含义
Safety Synthesis Readiness 指的是：在执行安全机制插入之前，对设计、证据、规则、目标、约束和输出边界进行系统性检查，确认当前设计已经具备进入 Safety Synthesis 的条件。
它不是简单的 checklist，而是一个工程化转换层：
Safety Analysis Evidence
D21 Safety Synthesis Readiness
Fault Campaign Results
FMEDA Model
Design Snapshot
Safety Requirements
Macro Synthesis Plan
Micro Synthesis Plan
Protection Contract
Readiness Report
Closure Evidence Package
这一层的输出不是单一报告，而是一组可以被后续工具链消费的结构化工件。它既服务于安全机制插入，也服务于后续 post-insertion validation、fault campaign rerun、FMEDA update 和 final closure。
03. 从分析阶段到综合阶段的语义转换
安全分析阶段关注的是"风险在哪里"；安全综合阶段关注的是"保护如何落地"。两者之间存在明显的语义差异。
| 阶段 | 主要问题 | 典型输入 | 典型输出 | 工程关注点 |
|---|---|---|---|---|
| Safety Analysis | 哪些结构贡献 FIT / residual FIT | RTL、netlist、FIT setup、DCE、SM map | FIT report、DC report、fault list | 风险识别 |
| Fault Campaign | 故障是否被检测或传播 | fault list、alarm list、VCD、observe point | detected/safe/unsafe/unresolved 分类 | 覆盖验证 |
| FMEDA | 指标是否满足目标 | part/sub-part、failure mode、SM、DC | SPFM/LFM/PMHF 相关证据 | 指标闭环 |
| Safety Synthesis Readiness | 哪些保护动作可以进入综合 | 分析证据、故障结果、设计约束 | synthesis plan、contract、readiness gate | 工程落地 |
| Safety Synthesis | 安全机制如何插入到设计 | synthesis plan、RTL、约束 | protected RTL、insertion report | 结构修改 |
| Post-insertion Validation | 插入后是否仍满足功能与安全目标 | protected RTL、testbench、fault campaign | validation report、closure package | 最终闭环 |
D21 的关键价值在于：把 D01-D20 的结果转成 D22-D32 可以直接使用的工程输入。
04. D21 在完整 Safe-IC Flow 中的位置
从项目流程看，D21 是分界点。前半段以分析和验证为主，后半段以安全机制插入、验证和 closure 为主。
D22-D32: Safety Synthesis + Validation + Final Closure
D22 Macro-level Safety Synthesis
D23 Micro-level Safety Synthesis
D25 Testbench Generation
D27-D31 Fault Rerun and Metric Update
D32 Final Closure
D21: Synthesis Readiness
Evidence Import
Risk-to-Protection Mapping
Readiness Gate
Synthesis Task Package
D01-D20: Analysis + Fault Campaign + FMEDA + Evidence
D01 Input Package
D02-D04 FIT/DC/Structural Analysis
D05 Evidence Database
D08-D14 Fault Campaign
D15-D20 FMEDA and Closure Gate
因此，D21 不是一个孤立 demo，而是系列进入第二阶段的入口。其工程能力体现在：可以把过去分散在报告、数据库、表格和脚本中的信息压缩成统一的 synthesis readiness model。
05. 关键术语：Protected RTL
Protected RTL 指经过安全机制插入或安全增强后的 RTL。它可能包含：
- endpoint parity；
- endpoint cone duplication；
- startpoint duplication；
- triplication and voter；
- ECC wrapper；
- lockstep interface；
- safety monitor；
- alarm aggregation logic；
- error propagation path；
- fault containment boundary；
- recovery handshake。
Protected RTL 并不只是"多加几段逻辑"。对于汽车芯片功能安全，Protected RTL 必须满足三个维度：
| 维度 | 要求 |
|---|---|
| 功能等价 | 正常场景下功能行为不能被破坏 |
| 安全可观测 | 故障场景下错误能被检测、隔离或上报 |
| 证据可追踪 | 每个插入点能追溯到 safety requirement、failure mode、fault campaign 结果和 FMEDA 指标 |
D21 的任务是判断哪些 RTL 可以进入保护规划，并生成插入前的工程约束。
06. 关键术语：Safety Mechanism Candidate
Safety Mechanism Candidate 是候选安全机制。它不是最终插入结果，而是根据风险、结构、指标目标和实现代价生成的候选方案。
常见候选机制包括：
| 机制类别 | 适用对象 | 典型目标 | 代价 |
|---|---|---|---|
| Parity | control endpoint、状态寄存器、轻量数据路径 | 检测单比特错误 | 低 |
| ECC | memory、宽数据通路、buffer | 检测/纠正数据错误 | 中 |
| Duplication | endpoint cone、关键组合逻辑、接口路径 | 比较两个结果是否一致 | 中 |
| Triplication | 高 ASIL 关键路径、控制状态机 | majority voting | 高 |
| Lockstep | CPU core、safety island、控制子系统 | 系统级比较 | 高 |
| Watchdog / Monitor | 时序行为、协议行为、状态转换 | 行为级异常检测 | 低到中 |
| Alarm Aggregation | 多安全机制输出 | 统一错误上报 | 低 |
D21 不直接决定所有机制，而是把候选机制按证据强度、设计约束、ASIL 目标、插入风险排序。
07. 关键术语：Protection Contract
Protection Contract 是 D21 最重要的输出之一。它描述某个设计对象应该如何被保护，以及后续验证如何确认保护有效。
一个 Protection Contract 通常包含：
| 字段 | 含义 |
|---|---|
| target_object | 被保护对象，例如 instance、endpoint、memory、state register |
| failure_mode | 关联失效模式 |
| safety_goal | 关联安全目标 |
| asil_target | ASIL 目标 |
| current_dc | 当前 diagnostic coverage |
| required_dc | 目标 diagnostic coverage |
| candidate_mechanism | 候选安全机制 |
| insertion_level | macro 或 micro |
| alarm_policy | alarm 输出与聚合策略 |
| validation_plan | 插入后验证计划 |
| evidence_links | 关联证据路径 |
Protection Contract 的价值在于：它把"安全需求"和"RTL 修改"绑定起来。后续任何插入、验证、回归和 waiver，都可以沿着 contract 追踪。
08. Macro-level 与 Micro-level 的准备差异
D21 是 D22 和 D23 的共同入口，但 Macro-level 和 Micro-level 对输入的关注点不同。
| 项目 | Macro-level Safety Synthesis | Micro-level Safety Synthesis |
|---|---|---|
| 插入粒度 | module、instance、subsystem、safety island | endpoint、cone、register、memory、data path |
| 典型机制 | duplication、triplication、lockstep、monitor wrapper | parity、ECC、cone duplication、local checker |
| 结构依赖 | 层次边界、接口协议、clock/reset domain | netlist/RTL cone、startpoint、endpoint、fan-in/fan-out |
| 验证重点 | 系统级一致性、接口行为、alarm contract | 局部检测覆盖、逻辑等价、fault propagation |
| D21 输出 | macro protection plan | micro protection plan |
D21 必须避免把所有问题都交给后续综合工具。安全综合不是盲目插入逻辑，而是以证据驱动的结构化设计变更。
09. Safety Synthesis Readiness 的输入全集
D21 输入可以分为六类：
| 输入类别 | 示例 | 用途 |
|---|---|---|
| Design Snapshot | RTL、filelist、top、clock/reset、blackbox list | 确认设计边界和可综合对象 |
| Safety Analysis Evidence | FIT contribution、DC report、DCE、SM map | 找出风险贡献点和 coverage gap |
| Fault Campaign Evidence | fault outcome、unresolved list、unsafe list、alarm report | 确认安全机制验证结果 |
| FMEDA Model | part/sub-part、failure mode、residual FIT、metrics | 映射到指标目标 |
| Safety Requirements | safety goal、ASIL、FTTI、diagnostic interval | 约束保护策略 |
| Implementation Constraint | area/power/timing budget、naming rule、alarm policy | 控制插入代价和集成风险 |
输入越完整，后续 D22/D23 的自动化程度越高。输入不足时，D21 应输出明确的 blocking issue，而不是生成不可靠的保护计划。
10. Safety Synthesis Readiness 的输出全集
D21 输出不是单个 Markdown 报告，而是一组可进入工程流水线的 artifact。
D21 Inputs
Readiness Analyzer
readiness_report.md
synthesis_readiness.json
macro_synthesis_plan.yaml
micro_synthesis_plan.yaml
protection_contracts.csv
evidence_trace_matrix.csv
blocking_issues.csv
这些输出应满足两类消费场景：
- 人可以读：review、audit、design discussion、safety meeting；
- 工具可以读：自动化脚本、Safety Synthesis engine、regression gate、Evidence Database importer。
11. D21 Demo 的目录规划
本篇对应 demo 建议采用如下目录结构：
text
demos/D21_safety_synthesis_readiness/
├── README.md
├── configs/
│ └── d21_readiness.yaml
├── inputs/
│ ├── design/
│ │ ├── rtl_filelist.f
│ │ ├── design_snapshot.yaml
│ │ └── clock_reset.yaml
│ ├── analysis/
│ │ ├── fit_contribution.csv
│ │ ├── diagnostic_coverage.csv
│ │ ├── dce_map.csv
│ │ └── safety_mechanism_map.csv
│ ├── fault_campaign/
│ │ ├── fault_outcomes.csv
│ │ ├── alarm_report.csv
│ │ └── unresolved_faults.csv
│ ├── fmeda/
│ │ ├── fmeda_parts.csv
│ │ ├── failure_modes.csv
│ │ └── residual_fit.csv
│ └── requirements/
│ ├── safety_goals.yaml
│ └── asil_targets.yaml
├── scripts/
│ ├── run_demo.sh
│ └── run_demo.csh
├── tools/
│ ├── safeic_readiness.py
│ ├── evidence_loader.py
│ ├── protection_planner.py
│ └── report_writer.py
└── outputs/
└── .gitkeep该 demo 不要求真实商业工具环境。它的核心是模拟一个工程团队如何把前序安全分析证据整理成 Safety Synthesis 入口包。
12. Demo README 的建议结构
README.md 需要让读者快速理解 demo 的目标、输入、运行方式和输出，不依赖真实工具名称。
建议 README 结构如下：
markdown
# D21 Safety Synthesis Readiness
## Goal
This demo builds a synthesis-readiness package from safety analysis evidence,
fault campaign results, FMEDA tables, and design constraints.
## Engines
- Safety Analysis Engine
- Macro Safety Synthesis Engine
- Micro Safety Synthesis Engine
- Fault Campaign Engine
- FuSa Evidence Database
- Safe-IC Flow Scripts
## Environment Variables
```bash
export SAFEIC_DEMO_HOME=$PWD
export SAFEIC_PROJECT_ROOT=$SAFEIC_DEMO_HOME
export SAFEIC_EVIDENCE_DB=$SAFEIC_DEMO_HOME/outputs/fusa_evidence.sqlite
export SAFEIC_ANALYSIS_ENGINE=${SAFEIC_ANALYSIS_ENGINE:-analysis-engine}
export SAFEIC_MACRO_SYNTH_ENGINE=${SAFEIC_MACRO_SYNTH_ENGINE:-macro-safety-synth}
export SAFEIC_MICRO_SYNTH_ENGINE=${SAFEIC_MICRO_SYNTH_ENGINE:-micro-safety-synth}
```
## Run
```bash
bash scripts/run_demo.sh
```
or
```csh
csh scripts/run_demo.csh
```
## Outputs
- outputs/readiness_report.md
- outputs/synthesis_readiness.json
- outputs/macro_synthesis_plan.yaml
- outputs/micro_synthesis_plan.yaml
- outputs/protection_contracts.csv
- outputs/evidence_trace_matrix.csv
- outputs/blocking_issues.csvREADME 的重点不是展示真实运行日志，而是把 demo 设计成一个可扩展的工程模板。
13. 可配置环境变量设计
环境变量应体现工具链可替换、路径可配置、输出可归档的原则。
| 环境变量 | 含义 | 示例 |
|---|---|---|
| SAFEIC_DEMO_HOME | demo 根目录 | $PWD |
| SAFEIC_PROJECT_ROOT | 项目根目录 | $SAFEIC_DEMO_HOME |
| SAFEIC_EVIDENCE_DB | 证据数据库路径 | outputs/fusa_evidence.sqlite |
| SAFEIC_ANALYSIS_ENGINE | 分析引擎入口 | analysis-engine |
| SAFEIC_MACRO_SYNTH_ENGINE | 宏级安全综合引擎入口 | macro-safety-synth |
| SAFEIC_MICRO_SYNTH_ENGINE | 微级安全综合引擎入口 | micro-safety-synth |
| SAFEIC_FLOW_MODE | 运行模式 | demo / real |
| SAFEIC_RUN_ID | 本次运行 ID | D21_YYYYMMDD_HHMMSS |
这些变量的设计原则是：脚本不写死工具路径，demo 不绑定具体商业环境，后续切换真实工具时只改环境变量和 adapter。
14. 配置文件 d21_readiness.yaml
D21 的核心配置可以采用 YAML。它既便于人读，也便于工具解析。
yaml
project:
name: toy_safeic_soc
top: toy_safety_top
asil_target: ASIL-D
run_id: D21_safety_synthesis_readiness
design:
filelist: inputs/design/rtl_filelist.f
snapshot: inputs/design/design_snapshot.yaml
clock_reset: inputs/design/clock_reset.yaml
evidence:
fit_contribution: inputs/analysis/fit_contribution.csv
diagnostic_coverage: inputs/analysis/diagnostic_coverage.csv
dce_map: inputs/analysis/dce_map.csv
safety_mechanism_map: inputs/analysis/safety_mechanism_map.csv
fault_outcomes: inputs/fault_campaign/fault_outcomes.csv
unresolved_faults: inputs/fault_campaign/unresolved_faults.csv
fmeda_parts: inputs/fmeda/fmeda_parts.csv
residual_fit: inputs/fmeda/residual_fit.csv
readiness_rules:
min_required_dc:
ASIL-D: 0.90
ASIL-C: 0.85
ASIL-B: 0.75
block_if_unresolved_faults: true
require_alarm_mapping: true
require_traceability: true
outputs:
directory: outputs
report: readiness_report.md
synthesis_model: synthesis_readiness.json配置文件体现了 D21 的工程价值：规则显式化、输入结构化、输出标准化。
15. 证据输入：FIT Contribution
FIT Contribution 用于判断哪些模块、instance 或 failure mode 对整体失效率贡献较高。
示例：
| object | object_type | failure_mode | fit | percentage | recommended_action |
|---|---|---|---|---|---|
| u_ctrl_fsm | instance | control_state_corruption | 12.5 | 18.2% | protect |
| u_safety_timer | instance | timeout_logic_fault | 8.1 | 11.8% | protect |
| u_status_reg | register_group | status_bit_flip | 5.4 | 7.9% | review |
| u_dbg_if | instance | debug_path_fault | 0.7 | 1.0% | waive_candidate |
D21 不只看 FIT 数值，还要结合 ASIL、故障传播路径、是否已有安全机制、是否有 alarm 观测点。
16. 证据输入：Diagnostic Coverage
Diagnostic Coverage 表示某个安全机制对目标故障的诊断覆盖能力。D21 需要把当前 DC 与目标 DC 进行对比。
| target_object | failure_mode | current_dc | required_dc | gap | status |
|---|---|---|---|---|---|
| u_ctrl_fsm | control_state_corruption | 0.62 | 0.90 | 0.28 | BLOCK |
| u_safety_timer | timeout_logic_fault | 0.78 | 0.90 | 0.12 | REVIEW |
| u_status_reg | status_bit_flip | 0.88 | 0.90 | 0.02 | REVIEW |
| u_cfg_reg | config_bit_flip | 0.93 | 0.90 | 0.00 | PASS |
这里的 gap 是后续 Safety Synthesis 的直接驱动力。gap 越大，越需要高强度安全机制；gap 越小，可能只需要局部增强或验证补强。
17. 证据输入：Fault Campaign Outcomes
Fault Campaign 结果提供了最直接的验证证据。D21 需要重点关注 unsafe 和 unresolved。
| outcome | 含义 | D21 处理策略 |
|---|---|---|
| detected | 故障被安全机制检测到 | 可作为已有机制有效证据 |
| safe | 故障未造成危险行为 | 可作为安全分类证据 |
| unsafe | 故障造成危险行为且未被检测 | 必须进入保护计划 |
| unresolved | 证据不足，无法分类 | 默认进入 blocking issue 或 review queue |
示意流程：
detected
safe
unsafe
unresolved
Fault Campaign Result
Outcome
Evidence Accepted
Evidence Accepted with Rationale
Create Protection Candidate
Create Blocking or Review Item
Protection Contract
Review Action
对于 ISO 26262 closure，unresolved 不能被简单忽略。它必须有明确处理动作：补充仿真、增加 observe point、调整 alarm list、更新 fault list、插入安全机制或形成有依据的 waiver。
18. 证据输入：FMEDA Model
FMEDA Model 负责把设计结构、失效模式、安全机制和指标连接起来。
D21 使用 FMEDA Model 主要完成三件事：
- 确认每个保护目标属于哪个 part/sub-part；
- 确认 failure mode 与 safety mechanism 的映射；
- 确认 residual FIT 与最终指标目标之间的差距。
示例：
| part | sub_part | failure_mode | base_fit | current_dc | residual_fit | closure_status |
|---|---|---|---|---|---|---|
| safety_island | control | control_state_corruption | 12.5 | 0.62 | 4.75 | open |
| safety_island | timer | timeout_logic_fault | 8.1 | 0.78 | 1.78 | open |
| soc_top | status | status_bit_flip | 5.4 | 0.88 | 0.65 | review |
| soc_top | config | config_bit_flip | 3.2 | 0.93 | 0.22 | closed |
D21 输出的 synthesis plan 应优先处理 residual FIT 贡献较高且 closure_status 为 open 的对象。
19. 风险到保护策略的映射原则
从 D21 开始，安全设计不再只是"找风险"，而是"风险驱动结构修改"。
建议采用如下映射原则：
| 风险特征 | 推荐机制 | 插入层级 |
|---|---|---|
| 控制状态机错误导致危险输出 | duplication + comparator / triplication | Micro 或 Macro |
| 数据通路单比特错误可传播到 actuator command | parity / ECC / cone duplication | Micro |
| CPU core 执行错误影响安全决策 | lockstep / core duplication | Macro |
| memory 内容错误影响 safety table | ECC / memory wrapper | Micro 或 Macro |
| interface protocol violation | protocol monitor / timeout checker | Macro |
| alarm 信号缺失或未聚合 | alarm aggregator | Macro |
| failure mode 无法被现有 observe point 覆盖 | observe point enhancement | Validation side |
映射过程不应只考虑覆盖率，还要考虑插入代价、时序风险、功耗影响、验证复杂度和安全证据可解释性。
20. Readiness Gate 规则设计
Readiness Gate 是 D21 的判断核心。它把进入 D22/D23 的条件显式化。
| Gate | 检查项 | PASS 条件 | FAIL 影响 |
|---|---|---|---|
| G1 | Design snapshot 完整性 | top/filelist/clock/reset 均存在 | 无法建立设计边界 |
| G2 | Evidence completeness | FIT/DC/fault/FMEDA 关键证据存在 | 无法支撑保护策略 |
| G3 | Traceability | object 到 requirement、failure mode、evidence 可追踪 | 无法形成 closure evidence |
| G4 | DC gap review | 所有 gap 有处理动作 | 风险无法闭环 |
| G5 | Fault outcome review | unsafe/unresolved 均有 action | Fault Campaign 证据不可闭环 |
| G6 | Alarm policy | 插入机制的 alarm 输出有归属 | 后续验证不可观测 |
| G7 | Synthesis feasibility | 插入对象无明显结构阻断 | 后续综合失败风险高 |
| G8 | Validation plan | 每个 contract 有验证策略 | 插入后无法确认有效性 |
Readiness Gate 可以分为 PASS、REVIEW、BLOCK 三种状态。BLOCK 项必须在进入真实安全综合前解决。
21. 工具链架构：从脚本到平台
D21 demo 的工具架构不应只是一个 Python 脚本，而应体现平台化能力。
Output Layer
Readiness Report
Protection Contracts
Synthesis Plans
Trace Matrix
Blocking Issues
Tool Adapter Layer
Safety Analysis Engine Adapter
Macro Safety Synthesis Engine Adapter
Micro Safety Synthesis Engine Adapter
Fault Campaign Engine Adapter
FuSa Evidence Database Adapter
Readiness Core
Evidence Loader
Schema Validator
Traceability Builder
Risk Scorer
Protection Planner
Readiness Gate Engine
Input Layer
Design Snapshot
Safety Analysis Evidence
Fault Campaign Evidence
FMEDA Tables
Safety Requirements
这一架构能体现 Safe-IC Flow Owner 的能力：不是只会运行单点工具，而是能把工具、数据、流程、证据和 closure 组织成平台。
22. Evidence Loader 的设计
Evidence Loader 负责读取不同来源的数据，并统一成内部模型。
输入来源可能包括：
- CSV 报告；
- YAML 配置；
- JSON 中间结果；
- SQLite evidence database；
- 工具输出目录；
- regression artifact；
- 人工 review 表格。
核心设计要点：
| 设计点 | 工程价值 |
|---|---|
| schema version | 支持 demo 迭代和真实项目升级 |
| strict mode | 防止输入字段缺失导致错误计划 |
| relaxed mode | 支持早期探索阶段不完整数据 |
| source hash | 支持证据可追踪 |
| run id | 支持多轮结果对比 |
| normalized object path | 统一 instance/path/register 命名 |
Evidence Loader 的输出应是统一的 object-risk-evidence model，而不是直接把 CSV 拼在一起。
23. Traceability Builder 的设计
Traceability Builder 负责建立证据链。
Safety Requirement
Failure Mode
Design Object
Fault List
Fault Campaign Outcome
Diagnostic Coverage
FMEDA Metric
Protection Contract
Validation Plan
每个节点都要保留来源：
| 节点 | 来源 |
|---|---|
| Safety Requirement | requirements YAML |
| Failure Mode | FMEDA failure mode table |
| Design Object | design snapshot / DCE map |
| Fault List | analysis output / campaign input |
| Campaign Outcome | campaign result |
| Diagnostic Coverage | DC report |
| FMEDA Metric | FMEDA table |
| Protection Contract | D21 planner |
| Validation Plan | D21 rule engine |
Traceability 不是文档装饰，而是 ISO 26262 closure 的基础工程能力。
24. Risk Scorer 的设计
Risk Scorer 用于对保护目标排序。一个实用的评分模型可以由以下因素组成：
| 因素 | 权重方向 |
|---|---|
| FIT contribution | 越高优先级越高 |
| residual FIT | 越高优先级越高 |
| DC gap | 越大优先级越高 |
| unsafe fault count | 越多优先级越高 |
| unresolved fault count | 越多优先级越高 |
| ASIL target | ASIL-D 高于 ASIL-C/B/A |
| design criticality | safety island、control path 优先 |
| implementation cost | 成本越低越容易优先落地 |
| timing risk | 风险越高越需要 review |
| evidence confidence | 证据越弱越需要补强 |
示例评分：
text
risk_score =
0.25 * normalized_fit
+ 0.20 * normalized_residual_fit
+ 0.20 * dc_gap
+ 0.15 * unsafe_fault_ratio
+ 0.10 * unresolved_fault_ratio
+ 0.10 * asil_weight这个公式不是标准要求，而是工程排序策略。实际项目中应根据芯片类型、ASIL 分解策略和组织流程调整权重。
25. Protection Planner 的设计
Protection Planner 根据风险评分和机制规则生成候选保护方案。
memory
state register
control cone
CPU/subsystem
interface
Object Risk Model
Object Type
ECC Candidate
Parity or Duplication Candidate
Cone Duplication Candidate
Lockstep or Macro Duplication
Protocol Monitor Candidate
Cost and Feasibility Check
Protection Contract
Planner 输出不应直接等同于最终设计变更。它是可审查的建议，后续仍需经过设计评审、综合验证、时序评估和 fault campaign rerun。
26. Readiness Report 的内容结构
outputs/readiness_report.md 建议包含以下章节：
- Project summary；
- Input evidence inventory；
- Design snapshot summary；
- Safety requirement summary；
- FIT contribution summary；
- DC gap summary；
- Fault outcome summary；
- FMEDA residual FIT summary；
- Risk ranking；
- Macro synthesis candidates；
- Micro synthesis candidates；
- Blocking issues；
- Review actions；
- Waiver candidates；
- Protection contract overview；
- Evidence trace matrix summary；
- Validation plan；
- Next-step recommendation。
Readiness Report 的读者不只是工具使用者，还包括 design owner、verification owner、safety manager 和 audit reviewer。
27. Synthesis Readiness JSON
synthesis_readiness.json 是机器可读输出，用于后续自动化。
示例结构：
json
{
"project": "toy_safeic_soc",
"run_id": "D21_safety_synthesis_readiness",
"overall_status": "REVIEW",
"summary": {
"design_objects": 128,
"protection_candidates": 12,
"macro_candidates": 3,
"micro_candidates": 9,
"blocking_issues": 2,
"review_items": 5
},
"contracts": [
{
"contract_id": "PSC-0001",
"target_object": "u_ctrl_fsm",
"failure_mode": "control_state_corruption",
"asil_target": "ASIL-D",
"current_dc": 0.62,
"required_dc": 0.90,
"candidate_mechanism": "endpoint_cone_duplication",
"insertion_level": "micro",
"validation_plan": "fault_campaign_rerun"
}
]
}这个 JSON 可以被 D22/D23 直接读取，也可以进入 FuSa Evidence Database。
28. Macro Synthesis Plan
macro_synthesis_plan.yaml 面向 D22。
示例：
yaml
macro_synthesis_plan:
- plan_id: MACRO-001
target_instance: u_cpu_subsystem
mechanism: lockstep_wrapper
reason:
- high residual FIT
- unsafe fault propagation to safety output
- ASIL-D control path
alarm_output: cpu_lockstep_mismatch_alarm
integration_constraints:
clock_domain: clk_main
reset_domain: rst_n
interface_policy: preserve_external_ports
validation:
- functional_regression
- protocol_monitor_check
- fault_campaign_rerunMacro plan 关注层次边界、接口协议、clock/reset、alarm policy 和系统级验证策略。
29. Micro Synthesis Plan
micro_synthesis_plan.yaml 面向 D23。
示例：
yaml
micro_synthesis_plan:
- plan_id: MICRO-001
target_object: u_ctrl_fsm.state_q
object_type: state_register
mechanism: parity_protection
reason:
- diagnostic coverage gap
- unresolved state corruption faults
alarm_output: ctrl_fsm_state_parity_alarm
validation:
- local_equivalence_check
- fault_campaign_rerun
- alarm_observability_check
- plan_id: MICRO-002
target_object: u_cmd_path.endpoint_cone
object_type: endpoint_cone
mechanism: cone_duplication
reason:
- unsafe fault outcome
- high FIT contribution
alarm_output: cmd_path_compare_alarm
validation:
- logic_equivalence_review
- post_insertion_fault_campaignMicro plan 关注细粒度结构：endpoint、startpoint、register group、memory、data path、control cone。
30. Blocking Issues 与 Review Items
D21 必须明确区分 blocking issue 和 review item。
| 类型 | 含义 | 处理方式 |
|---|---|---|
| Blocking Issue | 阻止进入安全综合的硬性问题 | 必须修复 |
| Review Item | 可以进入下一阶段，但需要人工确认 | 设计评审 |
| Waiver Candidate | 可能豁免，但需要证据支撑 | 安全评审 |
| Enhancement Item | 不阻塞，但建议增强 | 后续优化 |
示例：
| issue_id | type | object | description | action |
|---|---|---|---|---|
| BLK-001 | Blocking | u_ctrl_fsm | unsafe faults without alarm mapping | add protection contract |
| BLK-002 | Blocking | u_timer | unresolved faults exceed threshold | rerun campaign or add monitor |
| REV-001 | Review | u_status_reg | small DC gap | review parity insertion |
| WVR-001 | Waiver Candidate | u_dbg_if | low FIT contribution and no safety output propagation | create waiver rationale |
这个分类体现了工程成熟度。成熟工具链不会把所有问题都混成 warning，而是把处理路径显式化。
31. ISO 26262 Closure 视角下的 D21
ISO 26262 closure 不是最后一天生成一份报告，而是从每个阶段持续积累证据。
D21 对 closure 的贡献包括：
| Closure 证据 | D21 贡献 |
|---|---|
| requirement traceability | 建立 requirement 到 protection contract 的链路 |
| safety mechanism rationale | 记录机制选择原因 |
| diagnostic coverage improvement plan | 将 DC gap 转成 synthesis plan |
| fault campaign follow-up | 将 unsafe/unresolved 转成 action |
| FMEDA update basis | 提供 residual FIT 改善依据 |
| verification planning | 为 post-insertion validation 生成计划 |
| review evidence | 输出 blocking/review/waiver 表 |
D21 的本质是把后续安全综合变成可审查的 closure activity，而不是一次孤立设计修改。
32. 与 D22/D23/D25 的衔接
D21 输出决定后续三篇 demo 的输入边界。
| 后续 demo | 使用 D21 输出 | 主要任务 |
|---|---|---|
| D22 Macro-level Safety Synthesis | macro_synthesis_plan.yaml | 在模块/instance/subsystem 层插入保护 |
| D23 Micro-level Safety Synthesis | micro_synthesis_plan.yaml | 在 endpoint/register/cone 层插入保护 |
| D25 Safety Synthesis Testbench Generation | protection_contracts.csv / validation_plan | 为插入后的设计生成验证 testbench |
| D27+ Fault Campaign Rerun | updated protected RTL + fault plan | 重新验证安全机制有效性 |
| D32 Final Closure | evidence_trace_matrix.csv + updated metrics | 汇总最终证据包 |
这使整个系列形成清晰的工程链路：分析、计划、插入、验证、回写、闭环。
33. 安全综合入口的自动化策略
D21 自动化应分成三个层级。
| 层级 | 能力 | 说明 |
|---|---|---|
| L1 文件级自动化 | 自动读取 CSV/YAML/JSON | 适合 demo 和早期流程 |
| L2 数据库级自动化 | 从 FuSa Evidence Database 读取 session | 适合多轮项目管理 |
| L3 平台级自动化 | 与分析、综合、故障注入、回归系统联动 | 适合真实工程平台 |
建议 demo 采用 L1，同时在 README 中保留 L2/L3 扩展接口。这样既能保证开源 demo 可运行，又能体现平台化架构。
34. 工具定制能力的体现
D21 是展示工具定制能力的好位置，因为它位于多类工具之间：
Safety Analysis Engine
D21 Readiness Adapter
Fault Campaign Engine
FuSa Evidence Database
FMEDA Tables
Macro Safety Synthesis Engine
Micro Safety Synthesis Engine
Safety Synthesis Testbench Generator
可定制点包括：
| 定制点 | 价值 |
|---|---|
| 输入 parser | 适配不同项目报告格式 |
| object path normalizer | 解决 RTL/netlist/DB 命名不一致 |
| rule engine | 适配不同客户的 closure policy |
| mechanism selector | 适配不同设计风格和 IP 类型 |
| report template | 适配客户审查格式 |
| database adapter | 支持证据归档和持续回归 |
| command wrapper | 支持不同工具环境 |
这类能力可以直接支撑 Safe-IC Flow Owner 和 EDA Automation Platform Builder 的专家定位。
35. 工程实践中的常见风险
D21 阶段常见风险包括：
| 风险 | 影响 | 建议处理 |
|---|---|---|
| 分析对象和 RTL 对象命名不一致 | contract 无法落地 | 建立 object alias map |
| fault outcome 缺少 failure mode 映射 | 无法进入 FMEDA | 增加 outcome normalization |
| DC gap 无 action | closure 断链 | 强制生成 blocking issue |
| alarm policy 不统一 | 插入后不可观测 | 定义 alarm naming and aggregation rule |
| 只看 FIT 不看传播路径 | 保护目标偏差 | 引入 fault propagation evidence |
| 只看 coverage 不看实现代价 | 插入后 timing/area 风险高 | 加入 cost model |
| 只生成报告不生成机器可读数据 | 后续自动化断裂 | 输出 JSON/YAML/CSV |
这些问题不是工具命令层面的错误，而是流程架构层面的风险。D21 正是为了解决这些风险。
36. D21 Demo 的运行脚本设计
scripts/run_demo.sh 可以采用如下结构：
bash
#!/usr/bin/env bash
set -euo pipefail
export SAFEIC_DEMO_HOME=${SAFEIC_DEMO_HOME:-$(pwd)}
export SAFEIC_PROJECT_ROOT=${SAFEIC_PROJECT_ROOT:-$SAFEIC_DEMO_HOME}
export SAFEIC_EVIDENCE_DB=${SAFEIC_EVIDENCE_DB:-$SAFEIC_DEMO_HOME/outputs/fusa_evidence.sqlite}
export SAFEIC_FLOW_MODE=${SAFEIC_FLOW_MODE:-demo}
export SAFEIC_RUN_ID=${SAFEIC_RUN_ID:-D21_safety_synthesis_readiness}
python3 tools/safeic_readiness.py \
--config configs/d21_readiness.yaml \
--output-dir outputs \
--run-id "$SAFEIC_RUN_ID"为兼容老工程环境，也可以提供 csh 版本：
csh
#!/bin/csh -f
if (! $?SAFEIC_DEMO_HOME) then
setenv SAFEIC_DEMO_HOME `pwd`
endif
if (! $?SAFEIC_PROJECT_ROOT) then
setenv SAFEIC_PROJECT_ROOT $SAFEIC_DEMO_HOME
endif
if (! $?SAFEIC_EVIDENCE_DB) then
setenv SAFEIC_EVIDENCE_DB $SAFEIC_DEMO_HOME/outputs/fusa_evidence.sqlite
endif
if (! $?SAFEIC_FLOW_MODE) then
setenv SAFEIC_FLOW_MODE demo
endif
if (! $?SAFEIC_RUN_ID) then
setenv SAFEIC_RUN_ID D21_safety_synthesis_readiness
endif
python3 tools/safeic_readiness.py \
--config configs/d21_readiness.yaml \
--output-dir outputs \
--run-id "$SAFEIC_RUN_ID"脚本重点是可配置、可复用、可迁移，而不是绑定某个固定安装路径。
37. Demo 输出示例：Readiness Summary
最终 report 可以包含类似摘要：
| Metric | Value |
|---|---|
| design objects scanned | 128 |
| safety requirements loaded | 16 |
| failure modes loaded | 24 |
| fault outcomes loaded | 1200 |
| unsafe faults | 37 |
| unresolved faults | 58 |
| protection candidates | 12 |
| macro candidates | 3 |
| micro candidates | 9 |
| blocking issues | 2 |
| review items | 5 |
| overall readiness | REVIEW |
这个摘要可以作为 regression dashboard 的输入，也可以作为 GitHub README 中的展示结果。
38. Demo 输出示例：Evidence Trace Matrix
evidence_trace_matrix.csv 是最有价值的输出之一。
| requirement | failure_mode | object | fault_evidence | dc_evidence | fmeda_evidence | contract | validation |
|---|---|---|---|---|---|---|---|
| SG-CTRL-001 | control_state_corruption | u_ctrl_fsm | FC-0007 | DC-0012 | FM-0003 | PSC-0001 | rerun_campaign |
| SG-TMR-001 | timeout_logic_fault | u_safety_timer | FC-0041 | DC-0017 | FM-0008 | PSC-0002 | monitor_check |
| SG-CFG-001 | config_bit_flip | u_cfg_reg | FC-0089 | DC-0021 | FM-0011 | PSC-0003 | waiver_review |
这张表把工具结果变成可审查证据。对于功能安全项目，这类 trace matrix 比单独展示某次工具运行更有价值。
39. 从 D21 到真实项目落地
真实项目中的 D21 通常需要接入更多复杂因素：
- 多 clock domain；
- 多 reset scheme；
- blackbox IP；
- third-party IP；
- encrypted RTL；
- design hierarchy flattening；
- RTL/netlist name mismatch；
- ECO 版本变更；
- multiple mission profiles；
- multi-session evidence database；
- distributed fault campaign；
- regression farm；
- safety manager review；
- audit evidence export。
因此，D21 的 demo 应保持小而完整，真实项目扩展则应通过 adapter 和 schema 完成，而不是把所有复杂逻辑写死在脚本中。
40. 本篇小结
D21 的核心不是运行某个安全综合命令，而是建立 Safety Synthesis 的入口工程模型。
它将前序 Safety Analysis、Fault Campaign、FMEDA 和 Evidence Database 的结果整理成：
- readiness report；
- synthesis readiness JSON；
- macro synthesis plan；
- micro synthesis plan；
- protection contracts；
- evidence trace matrix；
- blocking issue list。
通过 D21，后续 D22/D23 的安全机制插入不再是局部 RTL 修改，而是有证据、有规则、有 traceability、有 validation plan 的工程活动。
对于汽车芯片功能安全平台建设，D21 是从"分析型工具链"走向"闭环型 Safe-IC 自动化平台"的关键转折点。