第2章：硬件安全需求分析：HARA、安全目标与安全机制分配

各位好，欢迎来到硬件落地的第二讲。

上一章我们聊了功能安全的基本概念和ISO26262的框架。今天要讲的内容，是真正开始动手做硬件安全设计的起点——HARA（危害分析与风险评估）。我个人认为，这一步做得扎实不扎实，直接决定了后续所有工作的质量。说白了，如果连“要防什么”都没搞清楚，后面的安全机制设计就是在瞎忙活。

2.1 HARA：危害分析与风险评估

HARA的全称是Hazard Analysis and Risk Assessment。它的目标很明确：识别系统在故障状态下可能对人员造成的危害，并评估其风险等级。

我刚开始做功能安全时，总觉得HARA就是走个过场，填几张表就完事了。直到有一次，我们忽略了一个看似“低风险”的场景——车辆在高速上突然失去动力辅助转向。结果评审时被客户直接打回，项目延期了两个月。从那以后，我再也不敢轻视HARA了。

2.1.1 HARA的核心三要素

做HARA时，我们需要关注三个核心要素：

  • 危害事件：故障发生后，导致的具体危险情况。比如“刹车踏板信号丢失导致车辆无法制动”。
  • 运行场景：危害发生时的车辆状态和环境。比如“车辆在高速公路上以120km/h行驶”。
  • 可控性：驾驶员或其他人员避免伤害的能力。比如“驾驶员能否在刹车失效时通过手刹或紧急制动停车”。

关键点：HARA不是只分析“故障本身”，而是分析“故障在特定场景下导致的后果”。同一个故障，在不同场景下，风险等级可能完全不同。

2.1.2 ASIL等级的确定

ISO26262通过三个参数来确定ASIL等级：

参数 全称 等级范围 说明
S Severity（严重度） S0~S3 伤害的严重程度，S3为致命伤害
E Exposure（暴露概率） E0~E4 运行场景发生的概率，E4为极高
C Controllability（可控性） C0~C3 驾驶员控制风险的能力，C3为几乎不可控

举个例子：如果某个危害的S=3（致命）、E=4（经常发生）、C=3（几乎不可控），那么它的ASIL等级就是ASIL D——最高等级。如果三个参数中有一个是S0、E0或C0，则等级为QM（质量管理），不需要按功能安全流程开发。

我的经验：在确定E值时，不要只看“这个场景理论上可能发生”，要结合实际的使用数据。比如“车辆在高速上行驶”对大多数用户来说E值很高，但“车辆在无人区夜间行驶”可能E值就低很多。我曾经见过一个项目，把E值定得过高，导致ASIL等级虚高，硬件成本翻了一倍。

2.2 安全目标定义

HARA完成后，我们会得到一组危害事件及其ASIL等级。接下来，需要为每个危害事件定义安全目标（Safety Goal）。

安全目标是一个顶层安全要求，它描述了“系统必须做什么来避免或减轻危害”。它不涉及具体实现，只描述“要达成的安全状态”。

2.2.1 安全目标的格式

我个人习惯用以下格式来写安全目标：

安全目标编号：SG-XXX
描述：当[触发条件]发生时，系统应[执行的动作]，以避免[危害事件]。
ASIL等级：[ASIL A/B/C/D]
安全状态：[描述系统应进入的安全状态]
容错时间间隔（FTTI）：[时间值，单位ms]

举个例子：

安全目标编号：SG-001
描述：当主制动系统失效时，系统应在100ms内激活冗余制动回路，以避免车辆无法制动导致的碰撞。
ASIL等级：ASIL D
安全状态：车辆通过冗余制动回路实现减速至停止。
容错时间间隔（FTTI）：100ms

注意：安全目标中的“容错时间间隔（FTTI）”非常关键。它决定了安全机制的响应速度。如果FTTI定得太短，硬件实现成本会很高；定得太长，又可能无法保证安全。我建议在定义FTTI时，参考实际物理系统的响应时间，比如液压制动系统的建压时间、传感器的采样周期等。

2.3 硬件安全需求导出

安全目标定义好后，我们需要把它分解成具体的硬件安全需求（Hardware Safety Requirements, HSR）。这一步是从“顶层要求”到“具体实现”的桥梁。

硬件安全需求通常包括：

  • 功能需求：硬件模块需要实现什么功能。比如“MCU应能检测制动踏板位置传感器的开路故障”。
  • 性能需求：硬件模块需要达到什么性能指标。比如“故障检测时间应小于10ms”。
  • 诊断覆盖率需求：安全机制需要达到的诊断覆盖率。比如“对制动踏板位置传感器的诊断覆盖率应≥99%”。

2.3.1 需求导出的方法

我常用的方法是自上而下分解：

  1. 从安全目标出发，识别出需要哪些安全机制。
  2. 将安全机制分配到具体的硬件模块（如传感器、MCU、执行器）。
  3. 为每个硬件模块定义具体的需求，包括功能、性能、诊断覆盖率等。

举个例子，对于SG-001（制动冗余），我们可能需要以下硬件安全需求：

需求编号 描述 分配模块 ASIL等级
HSR-001 主制动回路失效时，MCU应在50ms内检测到故障 MCU ASIL D
HSR-002 冗余制动回路应在100ms内激活 执行器驱动 ASIL D
HSR-003 制动踏板位置传感器的诊断覆盖率应≥99% 传感器接口 ASIL D

避坑指南：我曾经在导出需求时，只关注了“功能”而忽略了“性能”。结果硬件设计完成后，发现故障检测时间比FTTI还长，导致安全机制根本来不及响应。所以，性能需求一定要和FTTI对齐。

2.4 安全机制分配

硬件安全需求定义好后，我们需要把安全机制分配到具体的硬件模块上。安全机制就是用来检测故障、控制故障或减轻故障影响的具体方法。

2.4.1 常见的安全机制

在硬件层面，常见的安全机制包括：

  • 冗余设计：比如双MCU、双传感器、双执行器。
  • 诊断机制：比如CRC校验、看门狗、电压监控、电流监控。
  • 故障响应机制：比如故障时切换到安全状态、降级运行、紧急停机。

2.4.2 分配的原则

我个人总结了几条分配原则：

  1. 独立性：安全机制和主功能之间应尽量独立，避免共因失效。比如，不要用同一个电源给主功能和诊断电路供电。
  2. 覆盖率：安全机制的诊断覆盖率要满足ASIL等级的要求。ASIL D通常要求≥99%的诊断覆盖率。
  3. 响应时间：安全机制的响应时间要小于FTTI。
  4. 可测试性：安全机制本身要能被测试，确保它能在需要时正常工作。

注意：安全机制本身也可能失效。比如，看门狗电路如果自己坏了，就无法监控MCU。所以，安全机制也需要被监控。这就是所谓的“诊断的诊断”。

2.5 本章知识体系总览

为了让大家更直观地理解本章的知识结构，我画了一张流程图：

硬件安全需求分析流程 硬件安全需求分析流程 HARA 安全目标定义 硬件安全需求导出 安全机制分配 硬件设计实现 输入 系统定义 运行场景 故障模式 输出 安全目标清单 硬件安全需求 安全机制分配表

嗯，这张图把整个流程串起来了。从HARA开始，到安全目标，再到硬件安全需求，最后到安全机制分配，每一步都环环相扣。你想想看，如果中间任何一步出了问题，后面的硬件设计都会跑偏。

2.6 本章小结

今天的内容信息量不小，我帮你梳理一下核心要点：

  • HARA是安全设计的起点，通过S、E、C三个参数确定ASIL等级。
  • 安全目标是顶层要求，描述“要达成的安全状态”，必须包含FTTI。
  • 硬件安全需求是把安全目标分解到具体硬件模块的功能、性能和诊断覆盖率要求。
  • 安全机制分配是把安全机制落实到硬件模块上，并确保独立性、覆盖率和响应时间。

一句话总结：HARA告诉你“要防什么”，安全目标告诉你“防到什么程度”，硬件安全需求告诉你“怎么防”，安全机制分配告诉你“谁来防”。四步走完，硬件安全设计的基础就扎实了。

← 上一章 📖 返回目录 下一章 →