HSI — Hardware-Software Interface 文档

ISO 26262 把硬件设计(Part 5)和软件设计(Part 6)拆成两本独立标准,两侧靠 HSI 这份文档对接。Part 4(系统)给出 TSC,Part 5 写硬件需求规范、Part 6 写软件需求规范,HSI 把两侧的约束精确锁定下来:寄存器在哪个地址、中断号是几号、配置写一次就 lock、错误位读后写清。任意一方单方面改动而不同步,另一方 build 出来就和硬件对不上。

工程实务上,系统架构师拟初稿、硬件和软件 lead 联审,三方签字才进版本控制。变更走 6 步 CCB 流程(见 §5)。Part 4-6.4.6 明确写"HSI shall be jointly agreed by system, hardware and software development"——这是车规审计员引用频次最高的条款之一。

Part 6 Clause 6.4.6 + Part 4 Annex B 一起规定 HSI 必须涵盖 5 类信息。任一类缺失都不算合规 HSI,审计员会逐类问"⑤ 安全机制在哪一页?"

5 类内容速览:

第 ⑤ 类是审计员重点查的部分——必须每项标注 ASIL 等级 + SW 响应路径。

下面是一份典型 800V 主驱 ECU 的 HSI 节选,覆盖 ADC 同步采样、PWM 死区、Fault IRQ、ECC、WDT、Lockstep 状态六大类。每行有唯一 ID + ASIL + verification status,实际项目单 ECU 量级 200-500 行。

工程要点:

• ADC SYNC = PWM_CC0:采样窗对齐 PWM 中点 $\pm 0.5\mu s$,确保电流采样不踩开关瞬态。SW 不可运行时改 sync 源,校验回读 ≠ 写值 → 进 SafeState。
• PWM 死区 $1.5\ \mu s$ @ 100 MHz:写保护,lock 后写 → HardFault;CRC 入 calib 区,启动验校。
• Fault IRQ vector 24:latency 必须 < $10\mu s$,NMI 级 priority 0;ISR 直接拉 GATE_OFF,不进调度器。
• RAM ECC DERR_STA:双 bit 错(unrecoverable)立刻进 SafeState;单 bit 计数 + 日志,周期阈值触发降级。
• WDT 喂狗 0x55AA / 0xAA55 序列:windowed key,早 / 晚都 reset,迫使 SW 用主循环喂狗而非中断里。
• Lockstep SMU_CTRL.SS:HW 置 1 = 已切 SafeState,SW 只读不参与状态机决策——避免软件再误清错误位。

实际项目 HSI 单条目还要附:verification method(static review / functional test / fault injection)、owner(HW / SW / Sys 三方某人)、status(open / verified / waived)、linked TSR(追溯到 TSC 哪一条)。

200-500 行 + 每行 6-8 列 + 双向追溯到 TSC / SW SR / 测试用例 + 三方签字时间戳——Excel 维护不到一个月就崩。ASIL D 项目必须用受控工具:

判断阈值:HSI 行数 > 50 或 ASIL ≥ C 或 OEM-Tier1 协同必装 DOORS / Polarion / Codebeamer 之一。

任何一方提出 HSI 改动都走 6 步——CCB(Change Control Board)是审批节点。紧急改动允许 24 小时 cycle,但三方签字一项都不能省。

审计员最爱问的问题:"上次 v1.4 改了什么?三方都谁签的?触发了哪些回归?"——所以 changelog 必须可追溯。

实战中 ASIL D 项目 Confirmation Review 阶段被打回的 HSI 缺陷,Top 5:

• HSI 缺 ⑤ 安全机制类。只列了 HW resources 和 config,没标 Lockstep / SMU / SafeState 入口——直接被 Confirmation reviewer 退回。
• 三方签字过期。半年内有人离职 / 换岗,但 HSI 没重签——等于无 owner,审计员判定未签 = 未交付。
• 变更没走 CCB。改了 IRQ priority 但只在 commit log 提了一句,SW 团队不知道——回归测试漏掉 → 集成阶段才发现 latency 超标。
• 追溯断链。HSI 条目改了但对应的 TSR / SW SR / 测试用例没同步——FMEDA 重算时拉不出依赖。
• HSI 写在代码注释里而不是文档。常见于"工程师懒"的小公司——SW 把寄存器宏注释成 HSI、然后版本控制只追代码不追 HSI——OEM 审计立刻判 "no controlled HSI"。

HSI 不孤立存在,输入是 TSC + HSI 初稿,输出影响 Part 5/6 全套设计。下游影响范围:

• TSC(Part 4 输出)→ HSI 是 TSC 的技术实例化。TSC 改"扭矩超 5% 进 SafeState",HSI 要落到具体 IRQ / 寄存器。
• HW SR(Part 5)→ HSI ① ② ④ 直接对硬件需求生成约束。硬件设计师按 HSI 选 SoC、定 ADC 通道、画 PCB。
• SW SR(Part 6)→ HSI ② ③ ⑤ 是软件驱动的输入。SW lead 必须每条 HSI 都映射到 driver 实现。
• FMEDA(Part 5)→ ④ Diagnostics 项决定 DC 数值——HSI 改 → FMEDA 重算 SPFM/LFM。
• Safety Validation(Part 4)→ HSI ⑤ Safety mech 每条都要 fault injection 测试覆盖。

结论:改 HSI 一条,至少有 5 个下游 work product 要同步。这就是为什么 CCB 流程不能省。

不同 ASIL 项目对 HSI 严格度要求不同:

ASIL D 项目 HSI 改一条 → CCB → SIA → 三方 Review → FMEDA 重算 → 回归测试 → release note,平均 cycle 5-7 工作日。