4. 相关项定义与边界划分实战

相关项定义（Item Definition）是 ISO 26262 功能安全开发的起点，也是后续 HARA、安全目标、技术安全需求乃至验证活动的追溯源头。它并非一份简单的产品说明书，而是一份明确“我们要对什么负责、负责到什么程度、与谁交互”的工程契约。本章以 Continental 某款面向 L2+ 智能驾驶的集成式制动 ECU（以下简称 iB-ECU）为例，完整走一遍相关项定义、功能边界划分、接口识别与运行场景描述的过程，并给出可追溯文档的字段结构。

一、先明确“相关项”的粒度

相关项可以是一个系统、一组系统或一个功能。对于 iB-ECU，若把整个制动系统（含踏板、液压执行器、轮速传感器、ESC 模块）都纳入，边界会过于宽泛，导致接口和假设失控；若只取 ECU 硬件，又会遗漏与整车动力学相关的功能分配。工程上通常采用“功能+实现载体”的组合粒度：相关项 = iB-ECU 及其承载的制动控制功能集合，包括基础 ABS/ESC、电子驻车 EPB 控制、以及面向 L2+ 的冗余制动请求执行（如 AEB 减速请求、舒适制动请求）。

需要特别说明的是，iB-ECU 内部集成了两个独立的安全相关处理通道：主通道（Primary）负责常规制动与 ABS/ESC，冗余通道（Secondary）在主通道失效时提供降级制动能力。这一双通道结构直接决定了后续边界划分和接口识别的复杂度。

二、功能边界：用“功能—责任—假设”三要素锁定

功能边界不是画一条线，而是回答三个问题：该功能由谁触发、由谁执行、由谁兜底。以 AEB 减速请求为例：触发方是 ADAS 域控制器（通过私有 CAN 或 FlexRay 发送减速度请求），执行方是 iB-ECU 的冗余通道，兜底方是驾驶员（通过踏板力或 EPB 开关）。因此，AEB 减速功能的相关项边界应包含“请求接收—合理性校验—液压建压—轮缸压力闭环—状态反馈”这一完整链路，但不包含 ADAS 的感知与决策算法。

边界划分的常见陷阱是把“接口协议”当成“功能边界”。例如，iB-ECU 通过 CAN FD 接收 ADAS 请求，CAN 报文格式属于接口定义，而“是否接受该请求、接受后如何降级”属于功能边界。二者必须在文档中分列，否则追溯时会混淆。

三、接口识别：从物理层到信号层逐级展开

接口识别应覆盖能量、信号、材料、人员四个维度。对 iB-ECU 而言，关键接口包括：

• 供电接口：KL30 常电、KL15 点火电，以及冗余通道的独立供电引脚。需记录电压范围（9–16 V 工作，6 V 冷启动）、反接保护、过流阈值。
• 通信接口：CAN FD 与 ADAS 域控交互（请求减速度、请求有效性、心跳）；FlexRay 或 CAN 与整车网关交互（车速、轮速、横摆角速度）；私有 CAN 与 EPB 执行器交互。
• 传感器接口：4 路轮速传感器（电流型或电压型）、主缸压力传感器、踏板行程传感器、横摆角速度/纵向加速度传感器（部分集成于 ECU 内部）。
• 执行器接口：液压泵电机、进液阀/出液阀、EPB 卡钳电机。需记录驱动电流、PWM 频率、诊断反馈方式。
• 人机接口：制动踏板、EPB 开关、仪表报警灯。

每个接口都应标注“安全相关/非安全相关”属性。例如，轮速传感器信号直接参与 ABS 控制，属于安全相关；而仪表报警灯属于安全相关输出（用于提示降级状态），但诊断接口（UDS）通常为非安全相关，除非其写入操作会影响安全参数。

四、运行场景描述：把边界放进真实工况

运行场景描述不是罗列工况名称，而是给出“场景—功能状态—边界条件—预期行为”的对应关系。以下为 iB-ECU 的典型场景示例（示例参数为教学假设，非实测数据）：

场景描述必须与边界假设一致。例如，若假设“驾驶员始终在环”，则 AEB 场景中应说明驾驶员可随时通过踏板覆盖请求；若假设“ADAS 请求具有最高优先级”，则需在边界中明确驾驶员覆盖的优先级低于 ADAS，这直接影响 HARA 中的可控性评估。

五、可追溯文档的字段结构

相关项文档的核心是“可追溯”。建议采用如下字段结构，每个功能、接口、场景都分配唯一 ID，并建立双向链接：

Item: iB-ECU
  Item_ID: ITEM-BRK-001
  Functions:
    - FN-ABS-001: ABS 控制
    - FN-ESC-001: ESC 控制
    - FN-AEB-001: AEB 减速请求执行
    - FN-EPB-001: EPB 控制
  Boundaries:
    - BD-AEB-001: 接收 ADAS 请求至轮缸建压完成
    - BD-EPB-001: EPB 开关至卡钳夹紧
  Interfaces:
    - IF-PWR-001: KL30 主供电
    - IF-CAN-001: CAN FD 与 ADAS
    - IF-SEN-001: 轮速传感器
    - IF-ACT-001: 液压阀驱动
  Scenarios:
    - SC-AEB-001: 高速 AEB 触发
    - SC-DEG-001: 主通道供电丢失
  Assumptions:
    - ASM-001: 驾驶员始终在环
    - ASM-002: ADAS 请求具有合理性校验

文档完成后，应进行一次“边界走查”：随机抽取一个场景，沿接口链路反向追溯，确认每个信号都有明确的来源、去向和安全属性；再正向追溯，确认每个功能都有对应的边界和场景覆盖。走查中发现的缺口，应作为相关项定义的修订项，而不是留到 HARA 阶段再补。

上图把相关项边界、双通道结构、输入输出接口和边界假设放在同一张视图中。左侧黄色为输入接口（ADAS、网关、轮速传感器），右侧红色为输出接口（液压执行器、EPB 卡钳、仪表），中间蓝色虚线框为相关项边界，框内主/冗余通道与承载功能一一对应。底部紫色为供电接口，灰色为边界假设。实际项目中，每个接口和功能都应分配唯一 ID，并与 HARA 中的危害事件建立追溯链接。

完成上述步骤后，iB-ECU 的相关项文档应能回答四个问题：这个相关项包含哪些功能？每个功能的边界在哪里？每个接口的信号从哪里来、到哪里去？每个运行场景下预期行为是什么？只有这四个问题都有明确、可追溯的答案，后续的 HARA 和功能安全概念才有可靠的基础。