1、需求分析阶段的陷阱：需求模糊导致安全目标定义错误
各位工程师朋友，咱们直接切入正题。
需求分析阶段，说白了就是整个功能安全开发的「地基」。地基没打好，后面盖的楼再漂亮也是白搭。我在多个项目里见过，因为需求模糊，安全目标定义从一开始就偏了，结果后期返工成本高得吓人。
1.1 需求模糊的典型表现
先说说我踩过的坑。有一次，客户给的需求文档里写着：「系统应在故障发生时进入安全状态」。你想想看，这句话说了等于没说。什么故障？什么安全状态？进入时间多快？这些都没定义清楚。
常见的模糊表现有这几种：
- 安全目标描述过于笼统：比如「避免危险事件发生」，但没说明具体是哪种危险事件
- ASIL等级分配不合理：凭感觉给等级，没有基于危害分析和风险评估
- 安全状态定义不明确：故障后到底该降级、关断还是维持？
- 容错时间间隔（FTTI）缺失：系统必须在多少毫秒内响应？没人知道
1.2 如何通过ASIL分解澄清需求
ASIL分解，说白了就是把一个高安全等级的需求拆成几个低等级的子需求。这样做的好处是，每个子需求更具体、更容易实现和验证。
我个人习惯用这个思路：
- 先做危害分析和风险评估（HARA）：这是基础，不能跳过
- 确定每个危害事件的ASIL等级：根据严重度、暴露率和可控性
- 考虑ASIL分解的可行性：比如ASIL D可以分解为ASIL C(D) + ASIL A(D)，或者ASIL B(D) + ASIL B(D)
- 明确分解后的安全目标：每个子目标必须独立可验证
举个例子，我之前做过一个线控制动项目。原始安全目标是：「制动系统在单点故障时仍能提供制动力」，ASIL D。这个目标太模糊了，怎么实现？
我们做了ASIL分解：
| 原始安全目标 | ASIL等级 | 分解后子目标 | 分解后ASIL |
|---|---|---|---|
| 制动系统在单点故障时仍能提供制动力 | ASIL D | 主控制器故障时，备份控制器接管制动控制 | ASIL C(D) |
| 电源故障时，备用电源供电至少500ms | ASIL A(D) | ||
| 通信故障时，本地执行器独立工作 | ASIL B(D) |
你看，分解之后每个子目标都清晰多了。开发团队知道该做什么，测试团队也知道该测什么。
1.3 形式化方法：让需求不再模棱两可
形式化方法，听起来很高大上，其实没那么玄乎。它就是用数学语言来描述需求，消除自然语言的歧义。
我建议在关键安全目标上使用形式化方法。比如用线性时序逻辑（LTL）或计算树逻辑（CTL）来描述系统行为。
举个例子，还是那个制动系统。自然语言描述是：「故障发生后，系统应在100ms内进入安全状态」。这句话有歧义：100ms是从故障发生算起，还是从故障检测到算起？
用形式化方法可以写成：
// 使用LTL描述
G (fault_detected -> F[0,100] safe_state)
// 含义：任何时候检测到故障，系统必须在0到100个时间单位内进入安全状态这样写，每个工程师的理解都是一致的。不会出现「我以为你懂了，其实你没懂」的情况。
我在项目中用过一种更实用的方法——状态机描述。把安全行为画成状态机，每个状态、每个转移条件都写清楚。
// 简化的安全状态机
State: NORMAL
- 条件: 无故障
- 动作: 正常制动
State: DEGRADED
- 条件: 主控制器故障
- 动作: 备份控制器接管，输出警告
- 转移: 故障检测后10ms内进入
State: SAFE
- 条件: 双控制器故障
- 动作: 机械备份制动，限速20km/h
- 转移: 故障检测后50ms内进入1.4 避坑指南
我曾经在需求评审会上，因为一个「安全状态」的定义争论了两个小时。后来发现，大家说的根本不是同一个东西。从那以后，我养成了几个习惯：
- 每个安全目标必须包含三个要素：触发条件、系统响应、时间约束
- ASIL分解必须经过团队评审：一个人想容易漏，三个人想才全面
- 关键需求用形式化方法写一遍：哪怕只是画个状态机，也能发现很多隐藏问题
- 需求文档要有版本号和变更记录：我见过因为版本混乱，开发和生产用的需求不一致，最后出了大问题
1.5 总结
需求分析阶段的陷阱，说白了就是「模糊」二字。模糊的需求导致模糊的安全目标，模糊的安全目标导致模糊的设计和测试。最后项目延期、成本超支，甚至产品召回。
我的建议是：
- 做HARA时多花点时间：把每个危害事件都分析透
- ASIL分解要合理：既要满足安全要求，又要考虑实现可行性
- 形式化方法用起来：哪怕只是画个时序图，也比纯文字强
- 需求评审要较真：每个模糊点都要追问到底，直到所有人都理解一致
嗯，这部分内容就到这里。下一章我们聊聊设计阶段的陷阱，那个坑更多，到时候再细说。