HSI Document 写作工程化深度 — 12 章模板 + timing/shared-resource 双向追溯 + 5 反模式

功能安全L1别名 HSI 写作 · HSI Document writing · HW-SW Interface 写作 · Tier-1 to HW vendor 接口契约 · HSI 12 章模板

本质与导读

本质 HSI 是 ISO 26262-4 §6.4.7 强制 work product,Tier-1 系统层与 HW supplier、SW team 三方的硬契约;每条接口必须写死 timing 数字、shared resource 冲突和 fault response,用 shall/should 卡严格度。写宽或漏这三类难点,HW vendor 会按错 spec 流片(失败成本数百万)、SW team 集成时撞资源冲突返工数月。

主线坐标:横轨 · 功能安全(跨站) · ↑ 全景主线

1. HSI 在 ISO 26262 V-cycle 中的位置 + 12 章地图

HSI 是 Tier-1 系统工程师抽 TSC → 给 HW supplier + SW team 看的"翻译文档"。TSC 写"系统应该怎么响应安全事件"(用工程语言),HSI 写"具体到 pin / register / timing / shared resource / 字节级"(用 HW vendor + SW team 能照做的语言)。读者完全不同 — TSC 给 Safety Engineer 看,HSI 给 HW 设计师 + 嵌入式 SW 程序员看。下图把写作 5 阶段 + 12 章模板一次摆开:

HSI 写作流程 + 12 章地图

1.1 5 阶段写作流程

按 V-cycle 系统层 12-18 周分段:

  • ① TSC 抽取(2-3 周)— 从 TSC 把所有"涉及 HW + SW 交互"的条款抽出来。典型 10-30 条原子需求,每条进入 HSI 至少 1 个章节
  • ② HSI v0.1(2-4 周)— 第一稿,Safety Engineer + System Architect 协写。重点写 §3 Functional Interface + §5 Electrical Interface + §6 Timing;粗稿允许 TBD
  • ③ HW Vendor Review(2-4 周)— v0.1 发 driver IC / MCU vendor;vendor 回 "shall provide" vs "cannot guarantee";来回 2-3 轮 close TBD。关键产出:HW vendor 的 commitment letter(每条 shall 一句"我们保证 by datasheet rev X.Y")
  • ④ SW Team Review(1-2 周)— SW team check timing 是否可达 + shared resource 是否会冲突。关键产出:SW team 的 implementation note(每条 timing 给 RTOS 调度方案)
  • ⑤ v1.0 Lock(1 周)— 三方签字 + version control。lock 后任何改动需 ECN(Engineering Change Notice)+ 三方重 review

写作总工时 ~3-4 FTE × 月,中型主驱项目典型。最大风险在 ② → ③ 之间 — Safety Engineer 写得太理想(假设 HW 啥都能做),vendor 拒一半,整个流程返工。

1.2 12 章模板地图(ISO 26262-4 Annex C 改写)

ISO 26262-4 Annex C 给的 HSI 模板原文偏抽象(只列章节标题)。下表是 Bosch / 比亚迪 / 蔚来等 Tier-1 项目实际 HSI 文档抽出来的工程化模板,每章带"写什么 / 长度 / 谁审"3 字段。三大难点章(★ 标记)在 §2-§4 详细展开。

章内容长度谁审
1. Scope & PurposeHSI 覆盖范围 + 引 TSC ID1-2 页Safety Engineer
2. Functional Decomposition把 ECU 拆 HW / SW partition,定每个 SM 在哪边3-5 页System Architect
3. Functional Interface每个 HW-SW 信号 1 行(name / direction / type / SM relation)10-20 页HW vendor + SW team
4. Configuration Interface启动配置(register init / fuse / EEPROM)3-5 页HW vendor
5. Electrical Interface电平 / 阻抗 / drive strength3-5 页HW vendor
6. Timing Interface信号时序 + 中断响应 + WDG window5-10 页SW team + HW vendor
7. Memory Interface寄存器映射 + 字段 access right5-15 页SW team
8. Shared Resource ConflictSPI bus / ADC / DMA / Interrupt 多 SM 抢占矩阵3-5 页HW + SW
9. Fault ResponseHW 失效时 SW 如何反应 + 反过来5-8 页Safety Engineer
10. Test InterfaceDV / PV 阶段如何注入故障 + 观测点3-5 页DV 工程师
11. Diagnostic InterfaceDTC / UDS 报上来的字段3-5 页SW + Tester
12. Document Control版本 / ECN / 三方签字1-2 页Project Manager

典型 HSI 40-80 页(纯文档,不含附录波形图)。比 Safety Manual 写作 长(SM 20-40 页),因为 HSI 既有"接口契约"又有"实现细节"双重职责。

2. §3 Functional Interface 写作 — driver IC 过流端口 worked

§3 是 HSI 最大章(10-20 页),每个 HW-SW 信号 1 行。每行必含 9 字段,缺一个 HW vendor 或 SW team 就有歧义。以 driver IC overcurrent 信号为例:

2.1 9 字段模板

每条 §3 信号必含 9 字段,缺一字段 HW vendor 或 SW team 就有歧义空间。下表把每字段 + 为何不可省 一次列清:

字段例(driver IC nFAULT 信号)为何不可省
Signal NamenFAULT跨文档 unique key
DirectionHW → SW (output from driver IC)决定 SW 是 read or write
Electrical Typeopen-drain, active-low, pull-up 10kΩ to 3.3VHW 设计 + SW debounce 必需
SM Relationimplements mechanism_desat fault report追溯到 SM target
Trigger ConditionVCE > VCE_th (10V) sustained > tBLK (1µs)HW vendor 必照此设阈值
Response Time< 500 ns from fault to nFAULT lowtiming budget 一部分
Latch Behaviorlatched until SW writes RESET bitSW 知道是 sticky 还是 transient
Fault CoverageSC type 1/2/3 (per mechanism_desat)FMEDA DC 直接引此字段
HW Vendor Spec RefDatasheet Table 8.1 row 7vendor 承诺的源

2.2 driver IC nFAULT 完整 worked

下面把 9 字段在 ISO5852S nFAULT 信号上跑完整一遍。这条 worked 可直接复制到 HSI v0.1 文档:

3.4.7 nFAULT (driver IC → MCU fault report)

  Signal name      : nFAULT
  Direction        : HW (ISO5852S U7) → SW (MCU GPIO PA12, EXTI line 12)
  Electrical type  : open-drain, active-low, external 10kΩ pull-up to 3.3V
  SM relation      : implements mechanism_desat (fault report channel)
  Trigger condition: VCE_SAT > 10V (datasheet typ) sustained > t_BLK (1µs typ)
                     OR Vcc UVLO trip OR Vee UVLO trip
  Response time    : nFAULT shall go low ≤ 500 ns from trigger detection
                     (datasheet ISO5852S §6.4 spec)
  Latch behavior   : latched; cleared only by SW asserting RESET pin high → low
                     pulse ≥ 1 µs
  Fault coverage   : SC type 1 (hard turn-on at fault) — DC 99%
                     SC type 2 (load short during ON) — DC 95%
                     SC type 3 (cross-phase) — DC 85% (depends on bus layout)
  HW Vendor spec   : ISO5852S datasheet rev 2.0, §6.4 "FAULT Output Timing",
                     Table 6.1 row 5

  SW Implementation:
    - EXTI 12 falling-edge interrupt priority = 0 (highest)
    - ISR ≤ 50 µs: read latch, store DTC P0C7Bxx, transition to SafeState
    - debounce: NONE (latch is hardware-implemented)

  Fault Response (ref §9.3):
    - SW shall command STO (Safe Torque Off) within 200 µs
    - SW shall NOT auto-recover; RESET requires explicit driver command

写法 tips:

  • "shall" + 具体数字 / 单位,禁 "fast" / "high" / "good" 这种形容词
  • 每条 trigger 引 datasheet 章节号,vendor 不能后续 reinterpret
  • SW Implementation 段写最 minimal(只够 SW team 知道怎么集成),不写 RTOS 实现细节
  • Fault Response 段引 §9 fault response table,不在 §3 重复

2.3 §3 反模式 vs 修法

§3 写错的 5 种最常见模式都是"形容词代数字"或"省略关键字段"。下表把反模式 + 修法 一次列清,review 阶段照表查:

反模式例修法
Direction 模糊"nFAULT 用于 fault 通信"显式 HW → SW 或反向,加 GPIO pin name
无 trigger 阈值"When VCE is high"显式 ">10V sustained >1µs typ" + datasheet ref
无 response time"Quickly""≤ 500 ns from trigger to assertion"
Latch 不明"Will assert""latched; cleared by RESET pulse ≥ 1 µs"
无 vendor spec ref(空)引 datasheet rev + §章节 + Table 行号

3. §6 Timing Interface — Timing Violation End-to-End Traceability

§6 是 HSI 第二难章,任何 safety-critical 信号都有 FTTI(Fault Tolerant Time Interval)预算。FTTI 在 FSR 定 → TSR 拆 → HSI § 落到具体 µs 数字 → HW spec 承诺 → bench test 验。任何一环错链断,FTTI 失效但 paper 看起来合规 — 这是 ISO 26262 评审最常发现的隐性缺陷。

Timing Violation End-to-End Traceability — SG → FSR → TSR → HSI → HW spec → bench

3.1 完整链路 worked(主驱 SG-1 反向扭矩 < 200 ms)

下面把 SG-1 "Unintended torque < 200 ms" 端到端 6 层链跑完。每层都引上一层的 ID + 算 margin,任一断链 = FTTI 失效但 paper 合规:

SG-1 反向扭矩 200ms 端到端 FTTI 追踪链：SG-1 (HARA) → FSR-12 (FSC) → TSR-3.4 (TSC，逐级预算总和 ≤162µs ≪ 200ms，margin ~1234×) → HSI §6.2 逐信号 → HW Spec (ISO5852S datasheet 行号) → Bench Test (3 corner)；每层引上一级 ID + 算 margin

关键:

  • 每个 step 都引上一级的 ID(FSR-12 引 SG-1,TSR-3.4 引 FSR-12,HSI §6.2 引 TSR-3.4)
  • Margin = FTTI / sum(stages)(无量纲比值)必显式算出来。否则 vendor 给 typ 数字,系统级算不出 worst case 是否够(若要时间裕量另记 time headroom = FTTI - sum)
  • bench test 必有 corner conditions,不是只测 25°C nominal

3.2 §6 反模式

§6 写错的根因都是"省略 worst case + 不算 margin"。下表把 5 类典型反模式列清,review 时照查:

反模式后果修法
只写"快速响应"I3 评审 reject — 无法量化给具体 µs 数字 + worst case condition
总和不算 margin系统级超 FTTI 但没人发现margin = FTTI / sum 必显式列
vendor 给 typ 不要 maxcorner 失效必写"max @ +150°C, MIN supply"
没引 bench test ID评审无法 verify每条 timing 引 DV test case ID
ISR latency 不算SW team 自以为快 RTOS 实际不行加 RTOS 调度模型 + worst case 中断阻塞时长

4. §8 Shared Resource Conflict — SPI Bus / ADC 抢占矩阵

§8 是 HSI 最易被忽视的章 — 多个 SM 共享同一物理资源(SPI / ADC / DMA / interrupt line)时如果不显式声明优先级,运行时 race condition 就会出现。Bosch SX2 主驱有公开案例:driver IC SPI 跟 SBC SPI 共用 SPI3,driver fault polling 跟 SBC watchdog reset 抢 bus → driver fault 漏报 2 个周期 → bench 测不出来,量产后偶发熄火。

Shared Resource Conflict Matrix — 5 SMs × 3 buses

4.1 冲突矩阵模板

下面是主驱 ECU 典型 §8 冲突矩阵节选。每条共享资源(SPI3 / ADC1 CH7 / EXTI 12 等)列出所有使用方 + 优先级 + 周期 + 冲突解决策略,让 race condition 在文档阶段就被识别:

资源使用 SM优先级周期冲突解决
SPI3driver IC 故障 pollingP0(最高)1 ms不可被抢
SPI3SBC watchdog resetP110 ms等 driver polling 间隙
SPI3EEPROM diag log writeP3event-driven仅 idle 时
ADC1 CH7母线电压采样(diagnostic_voltage_sensing)P0100 µsDMA 锁通道
ADC1 CH7温度采样(辅 SM)P2100 msDMA 释放后
EXTI 12driver IC nFAULTP0eventNVIC IRQ, priority 0(最高,不被低 IRQ 抢)
EXTI 12SBC fault reportP1event等 EXTI 12 服务完

4.2 §8 必含 5 字段

每条共享资源:

  1. 资源名 + 物理标识(SPI3 / ADC1 CH7 / EXTI 12 / DMA1 stream2)
  2. 所有 SM 列表 + 各 SM 引用 ID(mechanism_desat / diagnostic_*)
  3. 优先级 P0-P3(P0 不可抢,P3 idle only)
  4. 周期或事件触发 + worst case 持续时长
  5. 冲突解决策略(lock / queue / preempt / round-robin)

4.3 §8 反模式

§8 漏掉的根因都是"共享资源未显式 + 形容词代优先级数字"。下表把 5 类反模式按"导致量产 bug 的概率"排序:

反模式后果修法
多 SM 共享但未声明优先级race condition,bench 测不出每条资源必有 P0-P3
周期 / 事件混用没说清DMA 死锁周期 SM 必给周期,事件 SM 必给 worst case 频率
没列 worst case 持续bus 拥塞算不出给 µs 数字 + comment
用 "low priority" 等形容词编译期无法 enforce强制 P0-P3 数字
跨 SM 没 lock / semaphore 设计量产偶发 bug显式写 lock 方案 + RTOS API

5. HSI ↔ FSR/TSR/FMEDA 双向追溯

HSI 不是孤立文档,必与 ISO 26262 work product 链:

HSI section上游(input)下游(consumed by)
§3 Functional Interface 每行 SM RelationTSR-N.M(技术安全需求)FMEDA 表(每个 SM 一行)
§6 TimingFSR FTTI + TSR timing budgetbench DV test case
§8 Shared ResourceTSR independence claimDFA report(common cause)
§9 Fault ResponseTSR safe state definitionSafety Case GSN(detection chain)

双向意味:Polarion / DOORS 里点 HSI section → 跳 TSR;点 TSR → 反查所有引它的 HSI section。审计员从任一端追,断链 = defeater(参 Safety Case GSN authoring §4)。

6. ASIL D HSI Review 6 项 checklist

Tier-1 内部 review 走完这 6 问,HW vendor / SW team review 退回率从 40% 降到 5%。

#问检查动作失败后果
1每条 §3 信号有 9 字段全?grep 缺 SM Relation / response time / vendor ref抽 5 条,缺一 = reject
2每条 §6 timing margin 算出来 ≥ 1.5×?表格列 margin 列,< 1.5× 红色margin < 1.0 = critical defect
3§8 每条共享资源有 P0-P3 + 冲突策略?抽 ADC + SPI + EXTI 3 类各 1 条任一缺 = reject
4§9 Fault Response 每条对应 TSR ID?反查 TSR table断链 = defeater
5HW vendor commit letter 已收到?文档 attach无 letter,vendor 后续可改 spec
6SW team implementation note 已收到?文档 attach无 note,SW 实际不照做

第 5 + 6 项是 ASIL D 特有,B/C 项目可容忍 informal 邮件;D 必正式 letter。

7. 5 个工程陷阱速查

HSI 写作末期出现的陷阱集中在 5 类,根因都是"形容词代数字 + 共享资源不显式 + 版本控失"。下表把陷阱、后果、修法一次摆开,Tier-1 内部 review 阶段对照排查:

#陷阱后果修法
1spec 太宽用形容词("fast" / "high")vendor / SW 自由解读 → 集成失败必数字 + 单位 + 引 datasheet
2timing 无 worst case + corner量产偶发超 FTTI"max @ corner conditions"
3共享资源不显式race condition bench 测不出§8 强制 P0-P3 + lock 策略
4无 fault response 段HW 失效 SW 不知道怎么办§9 每条 fault → SW action 1:1
5版本管理乱(无 ECN)三方拿不同版本§12 + git / Polarion lock

8. 工程交付清单

写完一个 ASIL D HSI 工件包应有:

  • HSI v1.0 markdown / DOCX — 40-80 页 + 三方签字页
  • HW vendor commitment letter — 每条 shall 一句"我们保证 by datasheet rev X.Y"
  • SW team implementation note — 每条 timing 给 RTOS 调度方案 + worst case 中断阻塞
  • HSI ↔ TSR/FMEDA traceability matrix — Polarion / Excel,双向 100% 覆盖
  • Review record — 6 问 checklist 走完,每问签字 + 整改 close
  • ECN process — 任何 lock 后改动必走 ECN(三方重 review)

I3 评审现场典型路径:抽 5 条 §3 signal → 反查 TSR ID → 反查 FMEDA SM 一致 → 抽 timing → 看 margin → 抽 §8 共享资源 → 看 lock 策略。任一断点 = 退回 1-3 月。

缩写表

只列本页专业术语:

缩写全称 / 中文备注
HSIHardware-Software InterfaceISO 26262-4 §6.4.7 强制 work product
TSCTechnical Safety ConceptPart 4 §6,HSI 的上游
FSR / TSRFunctional / Technical Safety RequirementPart 3 / Part 4
FTTIFault Tolerant Time IntervalHazard 到 SafeState 总时长上限
STOSafe Torque Offinverter safe state 之一
SMSafety MechanismISO 26262 安全机制
DCDiagnostic CoverageASIL D ≥ 99%
DCN / ECNEngineering Change Notice版本变更通知
EXTIExternal InterruptSTM32 / NXP MCU 中断线
DMADirect Memory Access共享 ADC / SPI 的 mover
WDGWatchdogSBC / MCU 内置
SBCSystem Basis ChipNXP FS65 / TLF35584 类
DTCDiagnostic Trouble CodeUDS 上报代码
UDSUnified Diagnostic ServicesISO 14229
Polarion / DOORSrequirement management tool双向 trace 工具
AURIXInfineon TC3xx MCU主流主驱 MCU
ISO5852STI 隔离 gate driverdriver IC 例
tBLKBlanking TimeDESAT trip 前忽略时长
VCECollector-Emitter VoltageIGBT / SiC 端电压
UVLOUnder-Voltage Lockoutdriver supply 监

核心要点
  • HSI 是三方契约,不是单方文档 — Safety Engineer 起草,HW vendor + SW team 必 review + commit;否则只是 PDF 摆设
  • 每条 §3 信号 9 字段全,缺一 reject — Direction / Electrical / SM Relation / Trigger / Response / Latch / Coverage / Vendor Ref + SW Impl
  • §6 Timing margin = FTTI / sum(stages)(无量纲比值)必算出来,显式列;ASIL D 推荐 ≥ 1.5× margin
  • §8 共享资源必有 P0-P3 + 冲突策略 — 多 SM 抢同一 SPI / ADC / EXTI 是量产偶发 bug 的 #1 来源
  • HSI ↔ TSR/FMEDA 双向 trace 100% 覆盖 — Polarion 强制 link
  • 5 阶段 SOP 12-18 周 — TSC 抽 → v0.1 → HW review → SW review → v1.0 lock;HW vendor 来回 2-3 轮 close TBD
  • HW vendor commitment letter + SW team implementation note 是 ASIL D 硬要求,不接邮件
  • 5 反模式戒:形容词代数字 / 无 worst case / 共享资源不声明 / 无 fault response / 版本管理乱

Cross-references