2. 泊车场景与需求分析

自动泊车系统能否真正落地，首先取决于对“泊车场景”的理解是否足够细致。泊车不是单一动作，而是一组由环境、车位、车辆状态和驾驶员意图共同约束的复杂任务。若场景分类不清，后续的搜索规划、路径优化和车辆约束建模都会失去边界。本节从场景分类出发，逐步推导用户需求、功能定义与可量化的性能指标，为后续章节的算法设计建立需求基线。

一、常见泊车场景分类

工程上通常从三个维度对泊车场景进行切分：车位形态、通道条件与交互对象。车位形态决定了几何约束，通道条件决定了可操作空间，交互对象则决定了动态风险。

• 按车位形态：平行车位（侧方停车）、垂直车位（倒车入库）、斜列车位（约30°~60°）、机械立体车位、无标线自由车位。
• 按通道条件：单车道窄巷、双向标准通道、地下车库坡道与转弯区、尽头式死胡同、带立柱或消防栓的受限通道。
• 按交互对象：空场景、静态障碍（邻车、立柱、墙）、动态障碍（行人、行驶车辆）、低矮障碍（地锁、锥桶、路沿）。
• 按驾驶员状态：车内泊车、遥控泊车、记忆泊车（学习固定路线后自动复现）。

这些维度组合后，会形成大量细分场景。工程实践中不会穷举所有组合，而是提取“最小可行场景集”作为开发和测试基线，例如：垂直车位+双向通道+邻车压线、平行车位+窄巷+后车逼近、斜列车位+立柱遮挡。

二、用户需求与功能定义

用户对自动泊车的核心诉求可以归纳为四句话：找得到、停得进、停得正、过程安心。“找得到”对应车位检测与识别能力；“停得进”对应可行路径搜索与避障；“停得正”对应最终位姿精度与车身姿态；“过程安心”对应速度平顺、交互清晰、可随时接管。

由此可定义自动泊车系统的功能边界：

1. 车位搜索：在低速行驶中识别可用车位，输出车位类型、尺寸、朝向与置信度。
2. 路径规划：生成从当前位姿到目标位姿的无碰撞轨迹，满足车辆最小转弯半径、轴距、车身尺寸等约束。
3. 运动控制：控制方向盘、油门、制动与挡位，实现低速精准跟踪。
4. 交互与安全：提供状态提示、进度反馈、异常告警与接管机制。

三、性能指标体系

性能指标是需求分析的量化出口。没有指标，就无法判断算法是否达标，也无法设计测试用例。下表给出自动泊车系统常用的核心指标及其工程含义。

这些指标之间存在耦合。例如，追求更小的横向误差可能增加揉库次数，从而拉长泊车时长；追求更快的规划耗时可能牺牲路径平滑度，进而影响控制精度。因此，指标定义必须结合场景优先级进行加权，而不是孤立地追求单项最优。

四、场景—需求—指标的关系图解

下图将本节的核心逻辑串联起来：左侧是场景输入，中间是需求与功能转化，右侧是性能指标输出，底部是约束与反馈回路。它帮助读者理解“场景如何驱动需求，需求如何量化为指标”。

五、案例与误区复盘

案例：垂直车位邻车压线。某车型在标准垂直车位测试中表现良好，但在邻车压线0.3米的场景下频繁失败。复盘发现，车位检测模块仍按标线中心计算车位，而规划模块使用的可行驶区域未扣除邻车实际占用空间。修正方案是：在车位检测输出中增加“有效可泊区域”字段，并在规划前进行二次碰撞校验。该案例说明，场景分类必须细化到“障碍物侵入车位”这一层级，否则需求定义会遗漏关键约束。

常见误区一：把场景分类做成静态清单。场景不是固定不变的，同一车位在白天和夜间、晴天和雨天、空载和满载下的可泊性不同。需求分析应保留环境参数接口，而不是写死场景枚举。

常见误区二：指标定义脱离场景。例如“泊车时长≤45秒”在窄巷平行泊车中可能过于苛刻，而在标准垂直车位中又过于宽松。指标应绑定场景优先级，形成“场景—指标”矩阵。

综上，泊车场景与需求分析是自动泊车工程的起点。场景分类提供输入边界，用户需求提供价值判断，功能定义提供实现范围，性能指标提供验收标准。四者形成闭环后，后续的搜索规划与车辆约束建模才有明确的优化目标与验证依据。