第3章安全需求分析

第3章：安全需求分析——HARA分析、安全目标定义、功能安全概念与技术安全概念

好，咱们进入正题。安全需求分析，说白了就是回答三个问题：系统会出什么危险？危险有多严重？怎么防止它发生？

我在项目里见过太多人一上来就写代码，结果做到一半发现安全需求没理清，推倒重来。嗯，那滋味可不好受。所以这一章，咱们把HARA、安全目标、功能安全概念和技术安全概念这几个硬骨头啃下来。

3.1 HARA分析：危险到底在哪？

HARA，全称是Hazard Analysis and Risk Assessment。翻译过来就是“危险分析与风险评估”。

你想想看，一个系统可能有几百种失效模式。但哪些是真要命的？哪些只是小毛病？HARA就是帮你做这个筛选的。

核心思路：先找出所有可能的危险事件，再评估每个事件的严重度（S）、暴露率（E）和可控性（C）。最后算出ASIL等级。

具体怎么做？我习惯分三步走：

场景分析——列出系统所有可能的运行场景。比如车辆在高速上巡航、在市区拥堵路段走走停停、在雨雪天气下行驶。
危险识别——针对每个场景，问自己：“如果某个功能失效了，会发生什么？” 比如刹车助力失效、转向角度计算错误、传感器输出卡死。
风险评估——给每个危险事件打三个分：S（Severity，严重度）、E（Exposure，暴露率）、C（Controllability，可控性）。

举个例子。我在做EPS（电动助力转向）项目时，遇到过这样一个场景：车辆在高速上行驶，突然转向助力丢失。你想想看，驾驶员需要突然用力打方向，如果反应不过来，后果很严重。

这个场景的评估结果：

S：3（可能危及生命）
E：3（中高暴露率，高速行驶常见）
C：2（驾驶员有一定可控性，但需要时间反应）

查表得出ASIL B。嗯，这个等级意味着需要中等强度的安全措施。

我的小技巧：HARA分析时，别一个人闷头做。拉上系统工程师、软件工程师、测试工程师一起头脑风暴。不同视角能发现你一个人想不到的危险场景。

3.2 安全目标定义：我们要防什么？

HARA分析完了，你手里有一堆危险事件和对应的ASIL等级。下一步就是把这些危险事件“翻译”成安全目标。

安全目标，说白了就是一句话：系统必须避免什么危险情况发生。

比如上面那个EPS的例子，安全目标可以写成：

SG-001：在车辆行驶过程中，EPS系统必须避免非预期的转向助力丢失。
ASIL等级：B
FTI（故障容错时间间隔）：100ms
安全状态：EPS进入降级模式，保留基础助力功能

注意，安全目标要满足几个原则：

可验证——你能设计测试用例来证明它被满足了
无歧义——团队里每个人理解都一样
可追溯——能追溯到HARA里的具体危险事件

我曾经见过一个安全目标写的是“系统应足够安全”。你想想看，什么叫“足够”？这没法验证啊。后来我要求团队必须写清楚：什么条件下、什么时间内、达到什么状态。

避坑指南：安全目标不要写得太宽泛。比如“系统不能失效”，这等于没写。要具体到“在XX故障下，系统在XX时间内进入XX安全状态”。

3.3 功能安全概念：怎么实现安全？

安全目标定好了，接下来就是功能安全概念（FSC）。这一步是把安全目标分解成具体的功能需求。

我习惯用“如果...那么...”的句式来写功能安全概念：

如果检测到转向助力电机电流异常，那么系统应在10ms内切断电机供电，并点亮仪表盘警告灯。
如果车速传感器信号丢失，那么系统应使用轮速传感器信号作为替代，并记录故障码。
如果控制器内部自检发现RAM错误，那么系统应进入安全状态，禁止助力输出。

你看，每个功能安全概念都对应一个安全目标。而且它明确了：谁来检测故障？检测到什么故障？做出什么反应？

这里有个关键点：功能安全概念是系统层面的，不涉及具体硬件或软件实现。它只告诉你“要做什么”，不告诉你“怎么做”。

核心原则：功能安全概念要覆盖所有安全目标。每个安全目标至少有一个功能安全概念来实现它。这叫“全覆盖”。

3.4 技术安全概念：落地到具体实现

功能安全概念是“做什么”，技术安全概念（TSC）就是“怎么做”。这一步，咱们要把系统层面的需求，分解到硬件和软件层面。

举个例子。功能安全概念说“检测到电机电流异常，10ms内切断供电”。技术安全概念就要具体到：

硬件层面：使用一个独立的电流传感器，采样频率不低于1kHz，精度±5%。
软件层面：实现一个电流监控任务，每1ms执行一次，如果连续3次采样值超过阈值，则触发安全动作。
诊断机制：电流传感器本身也需要自检，防止传感器失效导致误判。

技术安全概念通常包含以下内容：

元素	说明	示例
故障检测机制	用什么方法检测故障	电流阈值监控、信号合理性检查
故障响应时间	从故障发生到安全动作的时间	≤10ms
安全状态	故障后系统进入什么状态	降级模式、关闭输出、保持最后状态
诊断覆盖率	诊断能检测到多少比例的故障	≥90%
冗余策略	是否需要冗余设计	双通道比较、三模冗余

我的经验：写技术安全概念时，一定要考虑“诊断本身也会失效”。比如你用一个传感器来检测另一个传感器，那这个诊断传感器坏了怎么办？所以，诊断机制本身也需要诊断。这叫“诊断的诊断”。

3.5 从安全目标到技术安全概念的完整链路

咱们把整个链路串起来，看看一个完整的例子：

HARA结果：车辆高速行驶时，非预期加速导致碰撞风险。ASIL C。

安全目标：SG-002：车辆行驶过程中，必须避免非预期的持续加速。ASIL C，FTI 50ms。

功能安全概念：

FSC-002.1：如果检测到油门踏板位置传感器信号与制动踏板信号冲突（同时踩下），系统应优先响应制动信号。
FSC-002.2：如果检测到加速指令持续超过3秒且车速超过120km/h，系统应限制加速输出。

技术安全概念：

TSC-002.1.1：硬件上，油门踏板传感器采用双冗余设计（主传感器+副传感器），两个传感器信号偏差超过10%时触发故障。
TSC-002.1.2：软件上，每5ms执行一次踏板信号一致性检查，如果发现冲突，立即将节气门开度强制设为0%。
TSC-002.2.1：实现一个看门狗定时器，监控加速指令持续时间。如果超时，触发安全状态。

注意：技术安全概念要写清楚“谁来执行”。是硬件模块？还是软件任务？还是两者配合？我在项目中见过因为分工不明确，硬件以为软件会做，软件以为硬件会做，结果谁都没做。嗯，那后果你懂的。

3.6 本章小结

好，咱们捋一捋这一章的核心：

HARA分析——找出危险，评估风险，定ASIL等级。
安全目标——把危险翻译成“系统必须避免什么”。
功能安全概念——系统层面说“怎么避免”。
技术安全概念——硬件和软件层面说“具体怎么做”。

这四步是一环扣一环的。你想想看，如果HARA没做好，后面的安全目标就是空中楼阁。如果安全目标写得不清楚，功能安全概念就会跑偏。如果功能安全概念太模糊，技术安全概念就没法落地。

我个人习惯，每做完一步，就做一次追溯性检查：HARA里的每个危险事件，是不是都有安全目标覆盖？每个安全目标，是不是都有功能安全概念实现？每个功能安全概念，是不是都分解到了技术安全概念？

下一章，咱们聊聊怎么把这些安全需求用模型来管理。嗯，那才是真正有意思的地方。

📚 课程目录