4. 项目定义与边界：如何定义系统边界、功能范围、假设条件、运行场景
做HARA分析，第一步不是急着找危险。你得先把“地盘”画清楚。
我见过不少团队，上来就对着一个模糊的系统猛做HARA，结果分析到一半发现——哎？这个功能到底算不算我们的？那个场景是不是超了？最后返工，浪费时间。
说白了，项目定义与边界就是给整个安全分析画个圈。圈里的事我们管，圈外的事我们不管。这个圈画得清不清晰，直接决定了后续所有工作的质量。
4.1 系统边界：你的“管辖范围”在哪？
系统边界，就是明确你的系统跟外界怎么交互。我个人习惯用“系统边界图”来搞定这件事。
这张图不需要多复杂，但必须回答三个问题：
- 输入是什么？——系统从外界接收哪些信号、能量、物质？
- 输出是什么？——系统对外界产生哪些影响？
- 跟谁交互？——相邻系统、驾驶员、环境、其他车辆？
关键原则：边界要“一刀切”。要么在圈内，要么在圈外。不要有“半在圈内”的模糊地带。
举个例子，我在做电动尾门项目时，系统边界是这样定义的：
- 圈内：尾门控制单元（ECU）、电机、霍尔传感器、门锁执行器、内部线束。
- 圈外：车身CAN网络（只接收信号）、12V蓄电池（只取电）、用户遥控钥匙（只接收RF信号）。
你看，这样一划，后续分析时就知道：CAN总线故障不是我的事，但CAN信号丢了导致尾门误动作，那就是我的事了。
4.2 功能范围：你到底要实现什么？
功能范围，就是列出系统所有要干的事。注意，是“所有”。
我建议用功能清单来管理，格式如下：
| 功能ID | 功能名称 | 功能描述 | 触发条件 | 系统响应 |
|---|---|---|---|---|
| FUNC-01 | 电动开启尾门 | 用户按下尾门开启按钮，尾门自动打开至最大角度 | 车辆静止、P挡、按钮信号有效 | 解锁门锁→驱动电机→角度传感器反馈→停止 |
| FUNC-02 | 电动关闭尾门 | 用户按下尾门关闭按钮，尾门自动关闭并锁止 | 车辆静止、P挡、按钮信号有效 | 驱动电机→角度传感器反馈→门锁锁止 |
| FUNC-03 | 防夹功能 | 尾门关闭过程中检测到障碍物，立即停止并反向运动 | 关闭过程中，电机电流或霍尔信号异常 | 停止电机→反向驱动2秒→停止 |
| FUNC-04 | 手动模式 | 用户手动拉动尾门，电机不参与驱动 | 离合器分离，电机断电 | 无电机响应，仅记录状态 |
我的经验：功能清单一定要让系统工程师、软件工程师、测试工程师一起评审。我曾经吃过亏，漏了一个“应急机械开启”功能，结果HARA分析时没覆盖，最后被客户打回来补做。
4.3 假设条件：那些“我们默认成立”的事
假设条件，说白了就是“我们赌它不会出问题”的事。但ISO 26262要求你把这些赌注写下来，而不是藏在心里。
常见的假设条件包括：
- 外部系统假设：比如“CAN总线通信延迟不超过10ms”、“蓄电池电压始终在9V-16V之间”。
- 环境假设：比如“工作温度范围-40°C~85°C”、“无强电磁干扰超出ISO 11452标准”。
- 用户行为假设：比如“用户不会在尾门开启时强行攀爬”、“用户不会用异物卡住门缝”。
- 维护假设：比如“维修人员按照维修手册操作”、“更换部件使用原厂件”。
避坑指南：我曾经在一个项目中，假设了“用户不会在尾门运动时站在门下方”。结果客户的安全评审直接质疑：“如果用户就是站在下面呢？你的防夹功能能保护他吗？” 我们不得不重新评估，把那个场景加进了HARA。所以，假设条件要“保守”，别把用户想得太聪明。
假设条件需要编号管理，并在后续的安全案例中逐一验证。格式建议：
ASM-01: 假设CAN总线通信延迟 ≤ 10ms
- 验证方式: 通过CAN总线负载测试确认
- 验证结果: 最大延迟8.2ms，满足假设
- 状态: 已验证4.4 运行场景：在什么情况下系统会出事？
运行场景，就是描述“谁、在什么时候、在什么环境下、怎么用这个系统”。这是HARA分析的核心输入之一。
我个人习惯把运行场景拆成四个维度：
- 操作场景：用户怎么操作？正常操作？误操作？恶意操作？
- 环境场景：白天/黑夜？雨天/雪天？高温/低温？
- 车辆场景：静止？行驶？斜坡？负载？
- 故障场景：系统部分失效？通信中断？传感器漂移？
下面这张图展示了运行场景的四个维度如何组合成具体的分析场景：
实际项目中，我会用表格把场景列出来：
| 场景ID | 操作场景 | 环境场景 | 车辆场景 | 故障场景 | 场景描述 |
|---|---|---|---|---|---|
| SC-01 | 正常按下开启按钮 | 白天、干燥路面 | 水平地面、P挡 | 无故障 | 用户正常开启尾门，系统正常工作 |
| SC-02 | 正常按下关闭按钮 | 夜间、小雨 | 水平地面、P挡 | 霍尔传感器漂移 | 尾门关闭过程中传感器信号异常，防夹功能可能误触发或不触发 |
| SC-03 | 误触遥控钥匙 | 白天、停车场 | 水平地面、P挡 | 无故障 | 用户口袋中误触钥匙，尾门意外开启 |
| SC-04 | 手动拉动尾门 | 白天、雪天 | 斜坡、P挡 | 离合器卡滞 | 用户手动关闭尾门，但离合器未完全分离，电机产生阻力 |
我的习惯：场景数量不是越多越好。我一般每个功能至少覆盖3-5个典型场景：1个正常场景、1-2个边界场景、1-2个故障场景。太多了分析不过来，太少了容易漏掉关键危险。
4.5 把这些串起来：项目定义文档
最后，所有这些东西要汇总成一份《项目定义文档》。我建议的目录结构：
- 系统概述——一句话说清楚系统是干什么的。
- 系统边界图——输入、输出、交互接口。
- 功能清单——所有功能的ID、描述、触发条件、响应。
- 假设条件清单——编号、描述、验证方式、状态。
- 运行场景清单——场景ID、四维描述、预期行为。
- 术语表——统一项目中的术语定义，避免歧义。
这份文档不是写完了就锁柜子里的。它要在整个项目周期中活起来——每次需求变更、每次新增功能、每次发现新的运行场景，都要回来更新它。
一句话总结：项目定义与边界，就是给安全分析画一个清晰的圈。圈画好了，后面的HARA分析才能有的放矢，不会跑偏。