3. ADAS相关项定义与边界划分

在ISO 26262的语境下，“相关项”（Item）是功能安全活动的起点。它指的是一个能够实现车辆级功能的系统或系统组合，是危害分析与风险评估（HARA）、安全目标制定以及后续安全概念设计的对象。对于Bosch ADAS产品线而言，AEB、ACC、LKA、APA虽然共享摄像头、毫米波雷达、超声波传感器和域控制器等硬件资源，但在相关项定义时不能笼统地合并为一个“ADAS相关项”，而应按照功能边界、控制权限和运行场景分别界定。原因在于：不同功能的危害行为、可控性、暴露率差异显著，若边界划分过粗，会导致安全目标无法精确分配，安全需求也无法追溯到具体功能。

相关项定义的核心要素

一个完整的相关项定义通常包含五个要素：功能描述、系统边界、运行模式、场景约束以及与其他相关项的接口关系。功能描述回答“这个相关项做什么”；系统边界回答“哪些部件、信号和软件属于它，哪些不属于”；运行模式回答“它在什么条件下激活、降级或退出”；场景约束回答“它在哪些道路、天气、交通条件下被允许使用”；接口关系则回答“它从其他系统获取什么、向其他系统输出什么”。这五个要素共同构成后续HARA的输入。

以AEB为例，其功能描述为：在碰撞风险达到阈值时，通过制动系统施加自动减速，以减轻或避免碰撞。系统边界包括前向毫米波雷达、前视摄像头、AEB控制软件、ESC/ESP制动执行器以及仪表警告接口。运行模式分为待机、风险识别、预填充、部分制动、全力制动和退出。场景约束通常限定为城市道路与高速公路的追尾场景，不覆盖行人横穿以外的复杂弱势道路使用者场景（视具体版本而定）。接口关系上，AEB从ESC获取车速与轮速，向ESC发送减速请求，向仪表发送警告信号。

四类典型系统的边界差异

ACC（自适应巡航控制）与AEB共享前向感知链路，但控制权限不同。ACC是纵向速度控制功能，驾驶员设定目标车速和跟车时距，系统通过节气门和制动器维持跟车距离。其系统边界需要额外包含发动机管理系统（EMS）或整车控制器（VCU）的扭矩接口。运行模式包括待机、速度控制、跟车控制、超车辅助和退出。场景约束通常要求车速高于某一阈值（如30 km/h），且驾驶员保持对转向的控制。

LKA（车道保持辅助）则属于横向控制功能，其系统边界包括前视摄像头、电动助力转向系统（EPS）和LKA控制软件。LKA通过向EPS发送转向扭矩请求，使车辆保持在车道内。运行模式包括待机、车道识别、辅助转向和退出。场景约束要求车道线清晰、曲率半径大于某一阈值、驾驶员手扶方向盘。LKA与AEB、ACC的接口关系主要体现在共享摄像头和整车网络，但控制输出分别作用于EPS和制动/动力系统，因此相关项边界必须分开。

APA（自动泊车辅助）的边界最为特殊。它依赖超声波传感器、环视摄像头、泊车控制软件、EPS、制动系统和变速箱控制。APA在低速、封闭或半封闭场景下运行，驾驶员可能位于车内或车外（遥控泊车）。其运行模式包括搜索车位、路径规划、泊车执行和中断退出。由于APA涉及横向与纵向联合控制，且运行速度极低，其危害行为与AEB、ACC、LKA有本质区别，相关项定义时必须单独处理。

边界划分的工程判断

在实际项目中，相关项边界划分常遇到两个典型问题。第一个问题是“共享硬件是否导致相关项合并”。例如AEB和ACC共用前向雷达和摄像头，是否应合并为一个“前向ADAS相关项”？Bosch的工程实践倾向于不合并，理由是两者的安全目标不同：AEB的安全目标是“避免或减轻碰撞”，ACC的安全目标是“维持安全跟车距离且不产生非预期加速”。安全目标不同，意味着安全需求、安全机制和验证方法都不同。共享硬件可以通过接口安全需求（如传感器数据有效性、通信完整性）来覆盖，而不必强行合并相关项。

第二个问题是“APA是否应拆分为搜索相关项和执行相关项”。APA的搜索阶段仅使用超声波和环视摄像头进行车位识别，不涉及车辆控制；执行阶段才涉及EPS、制动和挡位控制。从功能安全角度，搜索阶段的危害行为主要是“误识别车位导致后续危险”，执行阶段的危害行为是“非预期转向或制动”。两者可以合并为一个相关项，但在HARA中应分别分析不同运行模式下的危害事件。若项目采用“一个相关项对应一个安全目标”的简化策略，则建议拆分；若采用“一个相关项多个安全目标”的策略，则合并更高效。

接口关系与安全需求分配

相关项定义完成后，需要明确它与其他系统的接口关系。以AEB为例，其与ESC的接口需要定义：减速请求的数值范围、响应时间、故障降级策略、通信超时处理。这些接口需求会转化为ESC的安全需求，并纳入ESC的相关项定义中。同样，AEB与仪表的接口需要定义警告信号的触发条件、显示优先级和故障提示方式。接口关系不清，是后续安全需求追溯断裂的主要原因之一。

运行模式与场景约束的量化表达

运行模式和场景约束不能只写“高速”“低速”这类模糊描述，而应尽量量化。例如ACC的运行模式可以定义为：待机（车速＜30 km/h或驾驶员未设定）、速度控制（车速≥30 km/h且无前车）、跟车控制（检测到前车且时距设定有效）、超车辅助（驾驶员触发转向灯且相邻车道无车）、退出（驾驶员踩制动或按下取消）。场景约束可以定义为：车道曲率半径＞250 m、能见度＞100 m、无强降雨或大雪。这些量化参数直接决定HARA中暴露率（E）的评估结果，也决定后续测试用例的边界条件。

对于APA，场景约束通常包括：车速＜10 km/h、车位长度＞车长+0.8 m、车位宽度＞车宽+0.6 m、超声波传感器无遮挡、地面平整无积雪。运行模式包括：搜索（车速＜10 km/h且驾驶员按下泊车按钮）、规划（识别到有效车位后计算路径）、执行（驾驶员确认后自动控制）、中断（驾驶员踩制动或打开车门）、退出（泊车完成或超时）。这些量化约束是APA相关项定义中不可或缺的部分，也是后续验证测试的输入条件。

相关项定义与后续安全活动的衔接

相关项定义不是孤立文档，它直接决定HARA的分析范围。AEB的HARA需要覆盖“制动请求丢失”“制动请求过大”“制动请求过小”“误触发制动”等危害行为；ACC的HARA需要覆盖“非预期加速”“跟车距离过近”“退出时无警告”等；LKA的HARA需要覆盖“非预期转向”“转向扭矩过大”“车道识别错误”等；APA的HARA需要覆盖“非预期转向”“非预期制动”“挡位错误”“路径规划错误”等。如果相关项边界划分错误，HARA就会遗漏危害行为，导致安全目标不完整，最终影响整个功能安全论证的可信度。

因此，在Bosch ADAS开发流程中，相关项定义通常由系统架构师、功能安全工程师和产品经理共同评审，确保功能描述、边界、模式、场景和接口五个要素完整且一致。评审通过后，相关项定义作为基线冻结，后续变更需走变更控制流程。这一做法虽然增加了前期工作量，但能显著减少后期安全需求返工和验证失败的风险。