第三篇：通关路线图——硬件开发在功能安全中的完整旅程

原创于 2025-09-03 09:04:29 发布 · 553 阅读

CC 4.0 BY-SA版权

文章标签：

4 篇文章

订阅专栏

如果把实现功能安全比作一次探险，那ISO 26262标准就是我们的探险地图。这张地图详细标注了从哪里出发、路上要经过哪些关卡、以及最终要找到什么样的“宝藏”。

作为硬件工程师，我们不需要独自走完全程，但必须清楚地知道自己的任务在哪一段，以及如何与其他队友（系统工程师、软件工程师）接力。

ISO 26262标准分为12个部分（Part），我们先快速浏览一下这张世界地图，知道几个关键地点就行：

Part 1-3: 起点营地（概念阶段）
- 在这里，大佬们分析车辆可能有哪些危险，制定出最高指令——安全目标（SG），并初步构想出实现它的策略——功能安全概念（FSC）。这是所有故事的开始。
Part 4: 系统设计指挥部
- 这里把初步策略（FSC）转化为更具体、可执行的技术安全需求（TSR） 和系统架构。这里是硬件开发任务的发令枪。我们收到的硬件需求（HSR），就源于这里的输出。
Part 5: 硬件工程师的主战场
- 我们的地盘！ 这里详细规定了如何根据来自指挥部的指令（TSR和架构），设计、实现和验证硬件。是本次探险的核心区域。
Part 6: 软件工程师的主战场
- 我们的邻居。我们设计的硬件（如看门狗、监控芯片）常常是软件实现其安全功能的基石。
Part 8: 后勤与支援中心
- 这里规定了整个探险队都要遵守的流程，比如如何管理物资版本（配置管理）、中途修改计划怎么办（变更管理）、以及最重要的ASIL分解的规则。这些规则贯穿我们工作的始终。

在我们硬件的主战场上，标准为我们规划了一条经典的“V”字形探险路线。这条路线完美诠释了“先设计，后验证”的思想。

（请想象一个巨大的“V”字从左上画到右上）

下降段（设计分解）：

从V的左肩出发（输入）：
- 我们从系统设计指挥部（Part 4）拿到两样东西：技术安全需求（TSR） 和 系统架构图。
- 这就像是拿到了建筑项目的“设计任务书”和“总体规划图”。
向下深入（详细设计）：
- 我们的任务是把“总体规划”变成可施工的“电路图纸”。
- 我们首先制定更详细的硬件安全需求（HSR），比如：“必须使用两个独立的传感器电源”，“必须每秒检测100次处理器心跳”。
- 然后，我们进行详细的硬件设计：画原理图、选元器件、设计PCB布局。这时，ASIL等级直接决定了我们元器件的选型标准和安全机制的设计复杂度。

到达谷底（实现）：

上升段（集成与验证）：

向上攀爬（测试与集成）：
- 我们对制造好的板子进行硬件单元测试，确保每个部分都工作正常。
- 然后，我们把所有部分组装起来，进行硬件集成测试，看看它们在一起能不能和谐工作，是否满足了之前制定的HSR。
- 接着，我们和软件团队的成果汇合，进行硬件-软件集成测试，比如测试看门狗是否能真的重启死机的软件。
回到V的右肩（验证闭环）：
- 最终，我们和整个系统大团队汇合，通过系统测试来证明：我们硬件的工作，完美满足了最初从指挥部拿到的技术安全需求（TSR）。
- 至此，我们成功走完了“V”字峡谷，实现了从需求到验证的完整闭环。