2. 相关项定义：功能、边界、假设、依赖关系
好，咱们正式开始做HARA的第一步——相关项定义。这一步说白了，就是搞清楚你手里到底是个什么东西。
我见过不少工程师，一上来就急着分析危害，结果做到一半发现连系统边界都没划清楚。嗯，这就像你还没画好靶子就开始射箭，白费力气。
2.1 什么是相关项？
ISO 26262里说的“相关项”，就是你正在开发的那个系统。它可能是一个完整的ECU，也可能是一个传感器、一个执行器，甚至是一套软件功能。
我个人习惯把相关项想象成一个“黑盒子”。我们不需要一开始就钻进盒子里看细节，而是先搞清楚：
- 这个盒子是干什么的？——功能
- 这个盒子的边界在哪？——边界
- 我们假设盒子外面是什么？——假设
- 这个盒子依赖谁？——依赖关系
举个例子。我几年前做过一个电动助力转向系统。相关项就是“EPS控制器+电机+扭矩传感器”这个组合。它的功能是提供转向助力，边界是方向盘到齿条之间的所有部件，假设是驾驶员会正常操作方向盘，依赖关系是它需要整车供电和CAN总线信号。
2.2 功能定义：说清楚它到底干什么
功能定义要具体，不能太笼统。比如“提供转向助力”就太宽泛了。我建议写成：
- 根据驾驶员输入的方向盘扭矩，计算并输出电机助力扭矩
- 在车速低于30km/h时提供最大助力
- 在车速高于100km/h时减少助力以保持稳定
你看，这样写出来，后面做HARA时就能直接对应到具体的失效场景。
2.3 边界定义：划清你的地盘
边界定义是新手最容易忽略的。我曾经在一个项目里，团队花了三周时间争论一个故障到底算不算系统内部的问题。后来发现，是因为边界没划清楚。
边界包括：
- 物理边界： 硬件接口、连接器、线束
- 逻辑边界： 信号范围、数据格式、通信协议
- 时间边界： 响应时间、采样周期、超时阈值
- 环境边界： 温度范围、振动等级、EMC要求
举个例子，一个制动系统的边界可能是：
| 边界类型 | 具体描述 |
|---|---|
| 物理边界 | 制动踏板位置传感器到制动卡钳之间的所有部件 |
| 逻辑边界 | CAN总线上的制动请求信号，范围0-100% |
| 时间边界 | 从接收到制动请求到输出制动压力，响应时间≤100ms |
| 环境边界 | 工作温度-40°C到125°C，防护等级IP67 |
2.4 假设：承认你不知道的事
做相关项定义时，我们不可能知道所有事情。所以需要明确假设。假设不是随便写的，它会影响后续的安全分析。
常见的假设包括：
- 驾驶员会按照用户手册操作
- 其他系统会提供正确的输入信号
- 环境条件在规定的范围内
- 维护和保养按照要求进行
2.5 依赖关系：谁是你的上下游
依赖关系决定了你的系统在整车环境中的位置。我习惯画一张简单的依赖图，标出：
- 输入依赖： 你的系统需要从谁那里获取信息？
- 输出依赖： 你的系统给谁提供信息？
- 资源依赖： 需要电源、通信、冷却等资源吗？
- 时序依赖： 某个信号必须在特定时间窗口内到达吗？
举个例子，一个自适应巡航系统的依赖关系：
| 依赖类型 | 依赖对象 | 说明 |
|---|---|---|
| 输入依赖 | 前向雷达、车速传感器 | 提供目标车辆距离和自车速度 |
| 输出依赖 | 发动机ECU、制动系统 | 请求加速或减速 |
| 资源依赖 | 12V电源、CAN总线 | 供电和通信 |
| 时序依赖 | 雷达数据更新周期≤50ms | 否则无法及时响应 |
2.6 实战中的常见坑
我做了这么多年功能安全，总结几个相关项定义时容易踩的坑：
- 坑一：功能定义太抽象。 比如“提高驾驶舒适性”，这没法做HARA。要写成“在颠簸路面时主动调节悬架阻尼”。
- 坑二：边界划得太窄。 只考虑控制器本身，忽略了传感器和执行器。结果分析时发现故障发生在传感器端，但边界没包含。
- 坑三：假设写得太随意。 把关键的安全责任推给了假设。比如“假设其他系统永远不会失效”，这明显不合理。
- 坑四：依赖关系漏了。 忘了考虑电源波动或通信延迟，结果在实车测试时才发现问题。
我的经验： 相关项定义不是一次性的工作。随着项目推进，你会发现新的边界、新的依赖。我建议在项目初期先做一个初步定义，然后在系统设计阶段再细化一次。别想着一步到位，那不太现实。
2.7 小结
相关项定义是整个HARA的基础。你花在这里的时间，后面都会加倍还给你。功能要具体，边界要清晰，假设要合理，依赖要完整。做到这四点，后面的危害分析就会顺畅很多。
下一章，咱们聊聊怎么识别危害。嗯，那才是真正烧脑的部分。