简介这份《代客泊车HAVP-功能规范》产品文档面向自动驾驶泊车功能开发、测试及产品定义人员系统讲解记忆泊车辅助系统的完整功能逻辑。文档围绕建图、记忆泊入与记忆泊出三大子功能展开涵盖信号需求、状态机与状态迁移条件、功能流程、HUT与APP交互逻辑、性能需求及关联件要求等模块并给出住宅区、商业停车场、机场接送等典型应用场景与远程监控、紧急制动等安全机制。资源为1个PDF文件压缩包约2.22MB共79页目录层级清晰便于按章节查阅。目前已有744人学习下载。读者可从中获取HAVP从路径学习到自动泊车的完整规范定义理解感知、决策、执行、交互四层系统架构与工作原理为功能开发、测试用例设计及交互逻辑评审提供直接参考。1. 代客泊车HAVP功能规范从场端地图到车辆控制的落地拆解代客泊车HAVPHome Automated Valet Parking功能规范本质上是一份约束“车-场-云-人”四方如何协作、在什么条件下允许车辆自主完成泊入泊出、以及每一步失败后如何安全退出的技术契约。它要解决的核心问题是当用户在停车场入口下车后车辆如何在无人驾驶状态下依靠场端感知或车端感知完成低速路径规划、避障、车位识别与精准泊入并在用户召唤时自主驶出。这套规范适合做智能驾驶功能定义、停车场智能化改造、以及车路协同系统集成的从业者。很多人以为HAVP就是“加个自动泊车”但真正落地时功能规范里对定位精度、通信时延、故障降级的要求远比乘用车L2泊车苛刻得多。2. 功能规范先立住HAVP的边界条件与场景定义2.1 为什么HAVP不是“自动泊车”的简单放大乘用车的APA自动泊车辅助依赖超声波雷达和环视摄像头作用距离通常不超过5米车速低于5km/h且驾驶员必须在车内。HAVP把场景拉长到整个停车场范围车辆需要从落客区行驶到目标车位距离可能超过300米途中要经过交叉路口、行人通道、减速带。这意味着功能规范必须重新定义ODD运行设计域场端是否覆盖全场、通信是否稳定、地图是否预先采集、车位是否被占用。我一般会把HAVP的ODD拆成三个维度场端基础设施等级、车端传感器配置、云端调度能力。任何一个维度不达标功能就必须降级或退出。常见做法是在功能规范里先画一张“场景-能力矩阵”。横轴是场景复杂度从空场泊入到高峰时段避让行人纵轴是系统能力从单车智能到车场协同。矩阵里每个格子标注允许的最高车速、最小安全距离、是否允许远程接管。这张表直接决定了后续代码里的状态机分支。2.2 场端与车端的职责划分谁说了算HAVP有两种主流技术路线场端主导和车端主导。场端主导依赖停车场部署的激光雷达或摄像头把全局路径和障碍物信息通过路侧单元发给车辆车辆只负责执行横向纵向控制。车端主导则依赖车辆自身的传感器和算力场端只提供地图和车位状态。功能规范必须明确在通信中断时车辆是继续用最后一次有效路径行驶到安全区还是立即靠边停车。我参与过的一个模拟项目里场端主导方案在通信时延超过200ms时车辆会出现画龙现象。后来在规范里加了一条路径更新周期必须小于100ms且车辆本地必须保留至少3秒的预测轨迹作为兜底。这个参数不是拍脑袋来的是按车辆最大车速1.5m/s、最大减速度2m/s²反推出来的。2.3 最小可行功能规范包含哪些章节一份能落地的HAVP功能规范至少要有术语定义、系统架构、ODD描述、功能状态机、人机交互、故障处理、安全冗余、测试验证。其中功能状态机是核心它要定义从“用户下车”到“泊入完成”再到“召唤驶出”的每一个状态迁移条件。比如“等待场端分配车位”状态超时10秒未收到车位信息应迁移到“请求失败提示用户重新下单”。这些迁移条件必须写成可测试的布尔表达式不能写“系统判断合适时”。3. 把规范拆成状态机用Python跑通HAVP核心流程3.1 状态机设计从落客到泊入的六个状态下面这段代码用Python实现了一个简化的HAVP状态机覆盖落客、路径规划、行驶、泊入、完成、异常退出六个状态。代码里每个状态迁移都对应功能规范里的条件判断。import time from enum import Enum class HAVPState(Enum): DROPOFF 1 # 用户已下车等待场端确认 PLANNING 2 # 场端/车端规划全局路径 DRIVING 3 # 沿路径行驶动态避障 PARKING 4 # 到达车位附近执行泊入 COMPLETED 5 # 泊入完成车辆下电 FAULT 6 # 异常退出请求远程接管 class HAVPContext: def __init__(self): self.state HAVPState.DROPOFF self.retry_count 0 self.last_heartbeat time.time() self.path [] self.target_slot None def transition(self, event): # 心跳超时检测通信中断超过500ms进入故障 if time.time() - self.last_heartbeat 0.5: self.state HAVPState.FAULT return if self.state HAVPState.DROPOFF: if event slot_assigned: self.state HAVPState.PLANNING elif event timeout_10s: self.retry_count 1 if self.retry_count 3: self.state HAVPState.FAULT elif self.state HAVPState.PLANNING: if event path_ready: self.state HAVPState.DRIVING elif event no_path: self.state HAVPState.FAULT elif self.state HAVPState.DRIVING: if event arrive_parking_zone: self.state HAVPState.PARKING elif event obstacle_blocked: # 障碍物持续阻挡超过30秒请求远程协助 self.state HAVPState.FAULT elif self.state HAVPState.PARKING: if event parking_done: self.state HAVPState.COMPLETED elif event parking_failed: self.state HAVPState.FAULT def heartbeat(self): self.last_heartbeat time.time()这段代码的逻辑说明HAVPContext类维护了当前状态、重试次数、心跳时间戳、路径和车位信息。transition方法根据外部事件触发状态迁移同时每次迁移前都检查心跳是否超时。参数说明心跳超时阈值设为0.5秒对应功能规范里“通信中断超过500ms必须进入安全状态”重试次数上限为3次对应“车位分配失败最多重试3次之后转人工”。实际项目中这些参数需要根据停车场网络质量和车辆制动距离标定。3.2 路径规划接口场端地图怎么转成车辆可执行轨迹HAVP功能规范里场端地图通常以车道级拓扑图形式提供包含节点、边、属性限速、单向、坡度。车辆需要把它转成带时间戳的轨迹点序列。下面是一个转换示例输入是场端JSON地图输出是车辆控制模块需要的轨迹数组。import json import math def map_to_trajectory(map_json, start_node, end_node): 将场端车道级地图转换为车辆可执行的轨迹点 map_json: 包含nodes和edges的字典 start_node: 起始节点ID end_node: 目标节点ID nodes {n[id]: n for n in map_json[nodes]} edges map_json[edges] # 简单广度优先搜索找路径实际项目用A*或Dijkstra path_nodes [start_node] current start_node while current ! end_node: for e in edges: if e[from] current: current e[to] path_nodes.append(current) break else: raise ValueError(No path found) # 生成轨迹点默认车速1.5m/s采样间隔0.1秒 trajectory [] t 0.0 speed 1.5 for i in range(len(path_nodes) - 1): n1 nodes[path_nodes[i]] n2 nodes[path_nodes[i1]] dx n2[x] - n1[x] dy n2[y] - n1[y] dist math.sqrt(dx*dx dy*dy) steps max(1, int(dist / (speed * 0.1))) for s in range(steps): ratio s / steps trajectory.append({ t: round(t, 2), x: n1[x] dx * ratio, y: n1[y] dy * ratio, v: speed, heading: math.atan2(dy, dx) }) t 0.1 return trajectory # 示例地图数据 sample_map { nodes: [ {id: A, x: 0, y: 0}, {id: B, x: 10, y: 0}, {id: C, x: 10, y: 10} ], edges: [ {from: A, to: B, speed_limit: 1.5}, {from: B, to: C, speed_limit: 1.0} ] } traj map_to_trajectory(sample_map, A, C) print(f生成{len(traj)}个轨迹点首点{traj[0]}末点{traj[-1]})逻辑说明函数先根据边列表做简单路径搜索然后按固定车速和采样间隔插值出轨迹点。参数说明speed默认1.5m/s对应地下停车场限速采样间隔0.1秒对应控制模块10Hz的接收频率。实际规范里轨迹点还要包含曲率、参考航向角变化率供横向控制器使用。如果场端地图节点间距过大插值步数会增加导致轨迹点过密此时需要做抽稀处理。3.3 安全冗余通信中断和定位丢失的降级策略功能规范必须定义降级策略。下面是一个降级决策的伪代码片段展示如何根据故障等级选择动作。def degradation_action(fault_type, fault_level): 根据故障类型和等级返回降级动作 fault_type: comm通信, loc定位, sensor传感器 fault_level: 1轻微, 2中等, 3严重 actions { (comm, 1): 降低车速至0.5m/s继续行驶, (comm, 2): 靠边停车等待通信恢复, (comm, 3): 立即制动请求远程接管, (loc, 1): 切换至航迹推算限速0.8m/s, (loc, 2): 停车重新初始化定位, (loc, 3): 制动并打开双闪请求远程接管, (sensor, 1): 屏蔽故障传感器降级感知, (sensor, 2): 停车等待传感器恢复, (sensor, 3): 紧急制动请求远程接管 } return actions.get((fault_type, fault_level), 未知故障按最高等级处理)这段代码把故障类型和等级映射到具体动作。参数说明通信故障1级对应丢包率5%10%2级对应10%30%3级对应超过30%或心跳丢失。定位故障1级对应RTK固定解丢失但惯导可用2级对应惯导漂移超限3级对应完全丢失。这些阈值需要在功能规范里明确写死测试时逐条验证。4. 避坑指南HAVP功能规范落地时最容易翻车的五个点4.1 车位分配超时后车辆一直傻等现象用户下车后场端因为车位占用检测模块卡死迟迟不分配车位车辆停在落客区不走后面堵了一排车。原因功能规范里只写了“等待车位分配”没写超时迁移条件。解决在状态机里加硬超时比如10秒未收到车位信息自动重试或退出到人工模式。我一般会在规范里要求所有等待状态都必须有超时参数且超时时间可配置。4.2 通信中断后车辆用过期路径继续行驶现象场端网络闪断车辆还在用3秒前收到的路径行驶结果撞上突然出现的行人。原因规范里没定义路径有效期车辆默认路径一直有效。解决每条路径必须带时间戳和有效期超过500ms未更新就触发降级。同时车辆本地要保留一条“安全停车轨迹”一旦通信丢失就沿这条轨迹靠边。4.3 定位跳变导致泊入时压线现象车辆在车位附近RTK信号被遮挡定位突然跳变0.5米泊入后车轮压到车位线。原因规范里只写了定位精度要求没写跳变检测和滤波策略。解决在功能规范里增加定位质量监控连续3帧位置跳变超过0.3米就切换至视觉里程计或停车重新初始化。泊入阶段限速要降到0.3m/s以下给滤波留出收敛时间。4.4 远程接管请求没有优先级现象多辆车同时请求远程接管后台操作员不知道先处理哪个导致一辆车在通道里停了2分钟。原因规范里没定义接管请求的优先级规则。解决按故障等级、车辆位置、阻塞时间三个维度打分。比如在交叉路口故障的优先级高于在车位里故障的已经阻塞通道超过30秒的优先级最高。这些规则要写成可计算的评分函数。4.5 测试用例只覆盖正常流程现象功能规范写得很全但测试时只跑了“落客-泊入-完成”这一条路上线后各种异常场景全暴露。原因测试用例没有和状态机的每个迁移条件一一对应。解决用状态覆盖法每个状态至少有一个进入事件和一个异常退出事件。比如“行驶中”状态要测试障碍物阻挡、通信中断、定位丢失、行人横穿四种异常。我习惯在规范里附一张状态-事件矩阵测试团队按矩阵逐格打勾。5. 进阶技巧用场景回放验证功能规范的一致性功能规范写完只是第一步真正难的是验证它没有自相矛盾。我常用的方法是场景回放把规范里的每个状态迁移条件翻译成可执行的断言然后用历史路测数据回放看状态机是否会在某些边界条件下进入死锁或振荡。具体做法是先定义一个场景描述文件包含时间戳、车辆状态、场端消息、障碍物位置。然后写一个回放器逐帧喂给状态机记录每次迁移。如果发现某个状态在1秒内迁移超过3次就说明条件设计有振荡需要加滞回或去抖。def replay_scenario(scenario, context): 回放场景检测状态振荡 scenario: 列表每项包含timestamp和event context: HAVPContext实例 transition_log [] for frame in scenario: context.heartbeat() # 模拟心跳更新 context.transition(frame[event]) transition_log.append((frame[timestamp], context.state)) # 检测1秒内迁移超过3次 for i in range(len(transition_log) - 3): window transition_log[i:i4] if window[-1][0] - window[0][0] 1.0: states [w[1] for w in window] if len(set(states)) 2: print(f警告{window[0][0]}秒附近状态振荡状态序列{states}) return transition_log这段代码的逻辑是逐帧驱动状态机记录每次迁移的时间和状态然后滑动窗口检测1秒内是否出现超过2种状态。参数说明窗口大小4帧时间阈值1秒状态种类阈值2。实际项目中这个回放器可以接入路测数据包自动生成振荡报告。我一般会在功能规范评审前跑一遍所有历史场景把振荡点提前修掉。另一个技巧是给每个状态加“最小驻留时间”。比如“泊入”状态至少持续2秒防止因为传感器噪声导致状态反复跳变。这个参数要根据车辆执行机构的响应时间标定不能拍脑袋。最后说一个血泪教训功能规范里的每个参数都要有出处要么来自国标行标要么来自实测标定要么来自仿真分析。我曾经见过一份规范里面写“通信时延小于100ms”问作者为什么是100答“感觉差不多”。后来实测发现在停车场高峰时段4G网络时延能到300ms整个功能直接不可用。所以参数要么写清楚推导过程要么留出可配置接口让集成商根据现场情况调整。希望帮到你。本文还有配套的精品资源点击获取