4. 相关项定义与边界划分
在HARA（危害分析与风险评估）项目中，相关项定义是整个安全生命周期的第一块基石。如果相关项划得太大，会把无关系统拖入分析范围，导致工作量爆炸；如果划得太小，又会遗漏跨系统交互带来的危害，造成安全目标缺失。尤其在跨系统项目中，相关项往往横跨多个ECU、多个供应商甚至多个域控制器，边界划分的清晰程度直接决定了后续HARA的质量。
一、核心原理：相关项不是“零件清单”，而是“功能+边界+接口”的三元组
很多团队在定义相关项时，习惯直接写“某某控制器”或“某某模块”，这其实是一种误区。相关项的本质是实现某一车辆级功能的系统集合，它必须包含三个要素：
- 功能维度：该相关项在整车层面提供什么功能，例如“自适应巡航控制”“自动紧急制动”“车道保持辅助”。
- 边界维度：哪些子系统、传感器、执行器、软件模块被纳入分析范围，哪些被排除在外。
- 接口维度：相关项与外部环境、其他相关项、驾驶员、乘客之间的信号、能量、数据交互关系。
在跨系统项目中，相关项通常不是单一ECU，而是“传感器+域控制器+执行器+通信链路”的组合。例如，AEB相关项可能包含前向毫米波雷达、摄像头、制动域控制器、ESC执行器以及CAN/FlexRay通信链路。此时，相关项定义必须明确这些组件之间的功能分配和接口关系。
二、方法流程：从功能清单到接口矩阵的五步法
结合ISO 26262和工程实践，跨系统项目的相关项定义可以按以下五步推进：
- 功能分解：从整车功能出发，逐层分解到系统功能、子系统功能，识别哪些功能与安全相关。
- 系统边界划定：明确相关项的物理边界、逻辑边界和开发边界，区分“相关项内部”与“外部环境”。
- 接口识别：列出所有输入、输出接口，包括信号接口、能量接口、人机接口、通信接口。
- 接口分类与清单化：按接口类型、方向、安全相关性进行分类，形成接口清单。
- 评审与冻结：组织系统、软件、硬件、测试、供应商多方评审，冻结相关项定义基线。
其中，系统边界的划定最容易产生争议。建议采用“功能责任归属”原则：如果一个组件直接参与实现相关项的安全功能，或者其失效会直接影响相关项的安全目标，就应纳入边界；如果只是提供非安全相关的辅助信息，则可以排除，但必须在接口清单中标注。
三、跨系统接口清单：用矩阵把“谁给谁什么”说清楚
接口清单是相关项定义中最具工程价值的交付物。它不仅是HARA的输入，也是后续系统设计、集成测试和供应商管理的依据。下表给出一个跨系统AEB相关项的接口清单示例：
| 接口编号 | 接口名称 | 方向 | 类型 | 安全相关 | 说明 |
|---|---|---|---|---|---|
| IF-01 | 目标距离/速度信号 | 雷达→域控 | CAN信号 | 是 | 用于碰撞时间计算 |
| IF-02 | 目标分类信号 | 摄像头→域控 | 以太网 | 是 | 用于区分车辆/行人 |
| IF-03 | 制动减速度请求 | 域控→ESC | CAN信号 | 是 | 触发主动制动 |
| IF-04 | 驾驶员制动意图 | 制动踏板→域控 | 硬线/PWM | 是 | 用于驾驶员接管判断 |
| IF-05 | 仪表报警显示 | 域控→仪表 | CAN信号 | 否 | 提示驾驶员系统状态 |
| IF-06 | 诊断故障码 | 域控→诊断仪 | UDS | 否 | 售后诊断使用 |
接口清单必须与系统边界图一一对应。任何一条接口，如果跨越了相关项边界，就必须在边界图中明确标出，并说明其安全相关性。
四、可视化：相关项边界与接口关系图
下图展示了一个跨系统AEB相关项的边界划分与接口关系。图中虚线框内为相关项内部，虚线框外为外部环境和其他相关项，箭头表示接口方向。
五、案例与误区复盘
某主机厂在开发L2级辅助驾驶相关项时，最初将相关项定义为“域控制器软件”，结果在HARA评审时发现：雷达的目标误识别会导致AEB误触发，但雷达供应商不在相关项边界内，导致危害分析无法闭环。后来团队重新定义相关项为“雷达+摄像头+域控制器+ESC+通信链路”的系统组合，并补充了12条跨系统接口，才使HARA完整覆盖了所有危害场景。
常见误区二：边界划得过于宽松，把整车所有系统都纳入。这会导致HARA失去焦点，建议以“安全功能责任链”为边界依据。
常见误区三：接口清单只列信号，不列能量和人机接口。驾驶员接管、踏板力、报警显示同样是安全相关接口，必须纳入。
相关项定义与边界划分不是一次性的文档工作，而是贯穿HARA、系统设计、测试验证的基线。只有把“分析什么、边界在哪、与谁交互”这三个问题回答清楚，跨系统项目的功能安全分析才能真正落地。