4. 硬件安全需求分析与导出：从TSR到HSR的分解、安全机制分配、硬件安全需求规格撰写要点
好，咱们进入第四讲。前面我们聊了ASIL等级、安全目标，那都是顶层的东西。今天要讲的，是真正把安全目标落地到硬件设计上的关键一步——从TSR到HSR的分解。
说白了，TSR（Technical Safety Requirement）是系统层面提的需求，它告诉你“要做什么”。而HSR（Hardware Safety Requirement）是硬件层面要实现的，它告诉你“具体怎么做”。这个转化过程，我见过太多人栽跟头了。
4.1 从TSR到HSR：不只是翻译，是再创造
很多人觉得，把TSR里的“系统应检测传感器故障”改成“硬件应检测传感器故障”就是HSR了。错！这完全是两个维度的事。
我举个例子。TSR可能写：“当主电源失效时，系统应在10ms内切换到备用电源。”到了硬件层面，你得考虑：用什么电路检测主电源失效？比较器？ADC？切换用MOSFET还是继电器？切换瞬间会不会有毛刺？备用电源的容量够撑多久？这些，TSR里一个字都不会提。
核心原则：HSR必须包含可验证的硬件实现细节。每个HSR都要能对应到具体的电路模块、引脚、时序或寄存器。
我个人习惯，在做TSR到HSR分解时，会先列一张映射表。左边是TSR编号和内容，右边是分解出的HSR编号和内容，中间写上“分解理由”。这样评审的时候，别人一眼就能看出你的思路。
| TSR ID | TSR内容（系统级） | 分解理由 | HSR ID | HSR内容（硬件级） |
|---|---|---|---|---|
| TSR-01 | 当主电源失效时，系统应在10ms内切换到备用电源 | 需要具体检测电路和切换电路 | HSR-01 | 硬件应使用窗口比较器监测主电源电压，当低于9V时触发中断 |
| TSR-01 | 同上 | 切换动作需要明确执行器 | HSR-02 | 硬件应使用背靠背MOSFET实现电源切换，切换时间≤5ms |
| TSR-01 | 同上 | 备用电源需要监控 | HSR-03 | 硬件应每100ms检测备用电源电压，低于10.5V时上报故障 |
你看，一个TSR拆成了三个HSR。每个HSR都指向了具体的电路行为。这才是合格的分解。
4.2 安全机制分配：把责任落实到每个模块
HSR分解完了，接下来就是分配安全机制。安全机制是什么？就是用来检测故障、防止故障、或者控制故障影响的那些硬件手段。
常见的硬件安全机制包括：
- 诊断覆盖：比如RAM的ECC、CPU的LBIST、ADC的测试信号注入
- 冗余：双路采样、三取二表决
- 监控：看门狗、电压监控、时钟监控
- 故障响应：安全状态切换、故障指示灯、故障码存储
分配的时候，我建议你画一张安全机制分配矩阵。横轴是硬件模块（电源、MCU、传感器接口、通信接口等），纵轴是故障类型（单点故障、潜伏故障、共因失效）。每个交叉点写上对应的安全机制。
我的经验：分配安全机制时，别贪多。不是每个模块都要上ECC+双冗余+看门狗。先做FMEDA分析，找出最关键的故障点，把资源用在刀刃上。我曾经见过一个项目，在非安全相关的LED驱动上花了大量精力做诊断，结果主安全路径反而覆盖不足。得不偿失。
4.3 硬件安全需求规格的撰写要点
好，到了最实操的部分——怎么写HSR文档。ISO 26262-5里对HSR有明确要求，但标准不会告诉你具体怎么写才清晰。我来分享几个要点。
4.3.1 每个HSR必须包含的要素
- 唯一编号：比如HSR-MCU-001，方便追溯
- 描述：一句话说清楚需求是什么
- ASIL等级：继承自TSR的ASIL分解结果
- 安全状态：当这个需求不满足时，系统应该进入什么状态
- 故障容错时间间隔（FTTI）：从故障发生到安全状态生效的最大时间
- 验证方法：怎么证明这个需求实现了（测试、分析、仿真？）
举个例子：
HSR-PWR-005 | ASIL D
描述：硬件应在主电源电压低于9V且持续超过2ms时，触发MCU的NMI中断。
安全状态：MCU进入安全关闭序列，切断所有执行器电源。
FTTI：10ms（从电压跌落开始计算）
验证方法：注入电压斜坡，用示波器测量NMI引脚时序。你看，这样写出来，测试工程师拿到手就知道怎么测，设计工程师也知道怎么画电路。不会产生歧义。
4.3.2 避免模糊用语
我审过很多HSR，最怕看到“应尽可能”、“必要时”、“适当”这类词。什么叫“尽可能”？什么叫“必要时”？每个人理解都不一样。
举个例子：
- ❌ 错误写法：“硬件应尽可能检测传感器短路故障。”
- ✅ 正确写法：“硬件应通过上拉电阻和ADC采样，检测传感器输出是否低于0.5V（短路到GND）或高于4.8V（短路到电源），检测周期≤10ms。”
量化！量化！量化！重要的事情说三遍。
4.3.3 追溯性不能丢
每个HSR必须能追溯到它的源头TSR。反过来，每个TSR也必须能查到它分解出了哪些HSR。这是功能安全评审的必查项。我建议在HSR文档里专门加一列“上游TSR编号”，同时在TSR文档里加一列“下游HSR编号”。双向追溯，不留死角。
4.4 知识体系总览
下面这张图，我把从TSR到HSR的完整流程画了出来。你可以把它当作本章的思维导图。
4.5 避坑指南
最后，我分享几个真实踩过的坑，希望能帮你省点时间。
我曾经犯过的错：在一个ASIL D的项目里，我把所有HSR都写成了“硬件应检测XX故障并上报”。结果评审时被问：“上报给谁？通过什么接口？上报的数据格式是什么？”我当场哑口无言。从那以后，我每个HSR都会明确“检测→判断→上报→响应”的完整链路。
还有一个常见问题：HSR写得太细，把具体电路方案都定死了。比如“硬件应使用LM393比较器检测电压”。万一后面发现LM393买不到，或者有更好的方案，你就得走变更流程。我建议只写功能需求和性能指标，具体实现留给设计工程师去选。比如写成“硬件应使用滞回比较器检测电压，阈值9V±2%，滞回宽度0.5V”。这样既明确了需求，又保留了设计自由度。
嗯，今天就到这里。记住一句话：好的HSR，是让拿到它的人不需要再回来问你“这是什么意思”。