4. 协同感知系统需求分析

协同感知系统的需求分析不是把“车、路、云要能互相看见”写成一句口号，而是要把多源感知、通信链路、时间同步、融合决策与量产约束，转化为可验证、可追溯、可分配的工程条目。它上承系统目标与法规预期，下接架构设计、接口定义、测试用例与量产验收，是协同感知从概念走向可交付系统的第一道“防错闸门”。

一、需求获取：从利益相关方到工程条目

协同感知的需求来源远比单车感知复杂，至少包括整车厂、路侧设备商、云控平台、通信运营商、交通管理部门、安全认证机构与最终用户。需求获取应围绕“谁在什么条件下需要什么协同能力”展开，而不是直接跳到传感器选型。

• 功能需求：如“在交叉口盲区，路侧感知应通过V2X向车辆提供遮挡目标的位置与速度”。
• 性能需求：如端到端时延≤100ms、目标位置误差≤1.5m、漏检率≤5%。
• 接口需求：如BSM/RSM/SPAT消息格式、坐标系、时间戳精度、数据频率。
• 约束需求：如算力上限、功耗、防护等级、量产成本、法规频段。
• 安全需求：如通信完整性、身份认证、功能安全ASIL等级、预期功能安全SOTIF边界。

获取手段可采用访谈、现场跟车、事故案例分析、法规解读、竞品拆解与场景走查。关键是把模糊表述转化为带条件、带阈值、带验证方式的条目。例如“尽量快”应改写为“在RSU覆盖范围内，目标检测到发送的时延不超过80ms，置信度≥95%”。

二、场景定义：用运行设计域约束协同边界

协同感知的失效往往不是算法本身，而是场景边界没有定义清楚。场景定义应覆盖正常场景、边缘场景与故障场景，并明确ODD（运行设计域）。

场景定义要避免“只写理想工况”。建议采用“场景卡片”方式：每个场景记录道路拓扑、交通参与者、天气光照、通信条件、预期协同行为与失败判据。场景卡片可直接映射为测试用例，形成需求到验证的桥梁。

三、用例建模：把协同行为拆成可执行交互

用例建模用于描述系统与外部角色之间的交互序列。协同感知的典型角色包括主车、远车、路侧单元、云控平台与驾驶员/自动驾驶系统。用例应包含前置条件、触发事件、主成功场景、备选场景与后置条件。

用例：交叉口盲区协同预警
角色：主车OBU、路侧RSU、云控平台
前置条件：主车进入RSU覆盖范围，通信链路正常
触发事件：RSU检测到被遮挡行人/车辆
主流程：
1. RSU融合路侧感知结果，生成RSM消息
2. 云控平台校验时空一致性并广播
3. 主车OBU接收并解析目标信息
4. 融合模块将协同目标与本地感知关联
5. 决策模块判断碰撞风险并触发预警
备选流程：
3a. 通信丢包 → 主车降级为本地感知
4a. 目标关联失败 → 标记不确定，不触发强预警
后置条件：预警发出或系统进入安全降级状态

用例建模的价值在于暴露接口与时序问题。例如“时间戳对齐”若未在用例中定义，后续融合就会出现“旧目标被当成新目标”的严重错误。因此，用例中应显式标注时间同步、坐标系转换与置信度传递要求。

四、需求可测试性与追溯性管理

可测试性要求每条需求都能回答三个问题：测什么、怎么测、判据是什么。无法测试的需求应被拆分或删除。追溯性则要求需求与设计、代码、测试用例、缺陷、变更之间建立双向链接。

• 需求ID：如REQ-CP-001，唯一且不可复用。
• 来源：法规、客户、场景卡片、事故报告或内部目标。
• 验证方法：仿真、台架、封闭场地、开放道路、数据分析。
• 追溯矩阵：需求→架构→接口→测试用例→测试结果。
• 变更影响：任一需求变更应自动识别受影响的测试与发布基线。

五、常见误区与复盘

误区一：把需求写成技术方案。“使用激光雷达+摄像头融合”是设计选择，不是需求。需求应描述“需要达到什么能力”，而非“必须用什么器件”。

误区二：场景定义过宽。“所有路口”等于没有定义。应明确路口类型、交通流、通信覆盖与天气条件。

误区三：追溯链断裂。测试用例与需求无关联，导致变更后无法评估影响，量产验证时出现“测了很多，但不知道覆盖了哪条需求”。

误区四：忽略降级与故障。协同感知系统必须具备通信中断、时间失步、目标冲突时的安全降级策略，否则量产阶段会面临严重安全风险。

综上，协同感知需求分析应形成“获取—定义—建模—验证—追溯”的闭环。需求获取保证来源完整，场景定义约束系统边界，用例建模暴露交互与时序问题，可测试性与追溯性管理则确保每条需求在量产验证中都有据可查、有法可测、有责可追。只有把需求分析做扎实，后续的架构设计、测试验证与量产放行才不会建立在流沙之上。