硬件开发在V模型里是什么位置？
ISO 26262 Part 5（硬件级产品开发）位于V模型的左侧下半部分 ------在系统级开发（Part 4）之后，与软件开发（Part 6）并行进行。
关键点 ：硬件开发和软件开发是并行 的------在系统阶段把TSR分给硬件和软件之后，两个团队就可以同时开工了。
硬件开发遵循V模型，但有两个关键区别于传统V模型开发流程：
- 概率论定量分析 ：硬件需要计算SPFM、LFM、PMHF等量化指标
- 随机硬件失效评估：硬件会"自然老化"失效，需要量化评估其概率
第一步：从TSR导出HSR------"翻译"和"具象化"
HSR在整个需求链中的位置
功能安全的需求体系从上到下分为四层：
TSR说的是"系统要做什么"，HSR说的是"硬件具体怎么实现" 。
根据ISO 26262-5:2018第6.1节，HSR有三个核心目的：
| 目的 | 大白话 |
|---|---|
| 📌 来源于TSC和系统架构 | 从系统阶段的需求中"翻译"出硬件要做什么 |
| 📌 细化HSI规范 | 把软硬件接口说清楚，硬件和软件别"打架" |
| 📌 验证一致性 | 证明硬件需求跟系统需求对得上 |
从TSR到HSR：一个"翻译"实例
在ISO 26262硬件开发中，HSR的推导过程就是把系统级的TSR"翻译"和"具象化"成硬件工程师能直接干活的需求。
关键原则 ：一个TSR可能衍生出好几个HSR。
TSR说："当检测到主控芯片内部时钟异常时，应在5毫秒内进入安全状态。"
硬件工程师把它"翻译"成HSR：
| HSR编号 | 硬件安全需求 | 关键属性 |
|---|---|---|
| HSR-01 | 硬件需实现一个独立于主时钟的看门狗电路，用于监控主控芯片时钟 | --- |
| HSR-02 | 看门狗电路的溢出时间应小于5毫秒，时间基准误差≤±2% | FTTI ≤ 5ms |
| HSR-03 | 该安全机制对时钟失效模式的诊断覆盖率目标需达到99% | 诊断覆盖率 ≥ 99% |
| HSR-04 | 从检测到失效到触发复位或安全状态切换，总延迟需小于5毫秒 | 响应时间 < 5ms |
一个TSR衍生出4条HSR------每条都具体、可量化、可验证。
HSR的三个核心维度
根据ISO 26262 Part 5和行业实践，HSR需要覆盖三个维度：
| 维度 | 大白话 | 示例 |
|---|---|---|
| 🛡️ 防止硬件内部失效 | "芯片自己别坏" | 看门狗、ECC、电压监控 |
| 🔗 应对外部相关失效 | "外面出事了也别影响我" | 外部短路保护、通信超时处理 |
| 📊 控制随机失效概率 | "硬件老化失效的概率要足够低" | SPFM、LFM、PMHF指标 |
HSR的11个关键特性
一个好的HSR，需要具备以下特性：
| 特性 | 大白话 |
|---|---|
| ✅ 无歧义 | "响应要快"不行，"响应时间<5ms"才行 |
| ✅ 可验证 | 能通过测试或分析来证明它实现了 |
| ✅ 可追溯 | 能追溯到上层的哪一条TSR |
| ✅ 完整 | 覆盖功能失效、瞬态故障、外部干扰、老化失效 |
| ✅ 分配ASIL等级 | 继承TSR的ASIL等级，取最高值 |
HSR不是一次性写出来的 ，它是一个继承加迭代的过程------先基于系统架构设计得到初步硬件架构，做安全分析（FMEA、FTA、DFA），分析出的新需求反过来更新HSR。
第二步：硬件架构设计------"搭骨架"
HSR写完之后，就要开始硬件设计了。硬件设计分为两个层次：
| 层次 | 大白话 | 输出物 |
|---|---|---|
| 硬件架构设计 | "搭骨架"------确定用什么芯片、它们怎么连 | 硬件架构图、模块框图 |
| 硬件详细设计 | "填肉"------画原理图、选元器件、做Layout | 原理图、PCB、BOM |
硬件架构设计 表示所有的硬件组件以及它们彼此的相互关系。从安全的角度来看，架构设计必须能够满足HSR，设计中必须考虑安全机制的存在。
实战：ACC雷达模块的硬件架构设计
以ACC系统的前向雷达模块为例（ASIL-D），设计硬件架构：
Step 1：确定核心组件
| 组件 | 选型考虑 | ASIL等级要求 |
|---|---|---|
| 主控MCU | 需要ASIL-D等级，带锁步核 | D |
| 雷达传感器 | 77GHz毫米波，探测距离≥200m | D |
| 通信接口 | CAN-FD，支持冗余通信 | D |
| 电源管理 | 宽压输入，带过压/欠压保护 | D |
Step 2：部署安全机制
| 安全机制 | 部署位置 | 作用 |
|---|---|---|
| 双核锁步（DCLS） | MCU内部 | 两个CPU核心同步运行，比较输出结果，发现偏差立即报警 |
| 看门狗定时器 | MCU外部独立硬件 | 监控程序是否跑飞 |
| 电压监控器 | 电源管理单元 | 实时监测关键电压，确保稳定供电 |
| 传感器自诊断 | 雷达模块内部 | 上电自检，检测硬件状态 |
Step 3：画出硬件架构图
第三步：芯片选型------怎么挑"安全"的芯片？
芯片选型是硬件开发中最关键的决策之一。ISO 26262-2018版第8部分第13条首次提出了"ASIL认证"的集成电路的概念。
芯片选型的核心考量因素
| 考量因素 | 大白话 | 示例 |
|---|---|---|
| ASIL等级 | 芯片本身支持什么等级？ | ASIL-D、ASIL-B |
| 硬件冗余能力 | 有没有锁步核？有没有双核？ | 英飞凌TC3xx LockStep核 |
| 安全机制 | 有没有看门狗、ECC、BIST？ | 硬件看门狗、内存ECC |
| 诊断覆盖率 | 对故障的检测能力有多强？ | 99%、90%、60% |
| 🔗 工具链支持 | 有没有配套的安全开发工具？ | 编译器认证、调试器支持 |
实战：ACC雷达模块的MCU选型
对于ASIL-D的ACC雷达模块，MCU选型需要考虑：
| 需求 | 选型要求 |
|---|---|
| ASIL等级 | 芯片需支持ASIL-D系统开发 |
| 冗余架构 | 需具备双核锁步（DCLS） 或多处理器架构 |
| 安全机制 | 需集成硬件看门狗、ECC、BIST等安全机制 |
| 诊断覆盖率 | 关键故障的诊断覆盖率需达到99% |
选型原则 ：ASIL等级越高，对硬件冗余的要求就越多。ASIL-D的系统通常需要双MCU 或锁步核设计。
行业实战：地平线HSD 600的硬件安全设计
2026年7月，地平线HSD 600域控制器正式通过UL Solutions的ISO 26262功能安全产品认证，达到ASIL-D等级。
硬件层面的关键设计：
- 电源管理：内置过压/欠压保护、电压监控器
- 计算冗余：采用多核异构架构，关键路径具备冗余设计
- 通信链路：关键通信链路支持冗余和故障检测
关键洞察 ：ASIL-D等级的硬件设计，不是"堆料"，而是系统性地在每一个环节嵌入安全机制------从电源到计算到通信，全覆盖。
硬件开发中容易踩的"坑"
坑1：把HSR写成TSR的"复制粘贴"
❌ 直接把TSR抄过来当HSR
✅ 把TSR"翻译"成硬件能实现的具体需求------加参数、加指标、加诊断覆盖率
坑2：只关注功能，不关注安全机制
❌ "芯片能跑多快、内存有多大"
✅ "芯片有哪些安全机制？看门狗？ECC？锁步核？"
坑3：忘了考虑外部失效
❌ 只关心芯片内部会不会坏
✅ 还要考虑外部短路、电源波动、通信中断等外部失效场景
坑4：选了ASIL-D的芯片，但没验证
❌ "芯片手册上写的是ASIL-D，肯定没问题"
✅ 需要通过硬件要素评估来验证芯片是否符合ASIL要求。