代客泊车HAVP功能规范深度拆解：信号、状态机与联调避坑指南

简介这份HAVP代客泊车功能规范文档面向自动驾驶产品经理、泊车算法工程师及功能安全测试人员系统讲解记忆泊车辅助从概念到落地的完整设计逻辑。内容围绕建图、记忆泊入与记忆泊出三大子功能展开涵盖信号需求、状态机与状态迁移条件、功能流程、HUT与APP交互逻辑、性能需求及关联件要求等模块并延伸至感知、决策、执行、交互四层系统架构与远程监控、紧急制动等安全机制可帮助读者理解量产级泊车功能的规范撰写思路与接口定义方法。资源为1个PDF文件压缩包约2.22MB共79页目录层级清晰便于按章节检索。目前已有744人学习下载适合需要参考功能规范模板、梳理状态机与交互逻辑的从业者查阅。1. 代客泊车HAVP功能规范79页文档里到底藏了什么第一次拿到这份《代客泊车HAVP-功能规范》的时候我正蹲在某实验室的工位上啃一个泊车域控制器的联调问题。文档封面写着 V1.0、79 页、未经允许禁止外传翻到第 4 页功能描述一句话就把我拉住了HAVP 是泊车辅助的更高级拓展用户不在车内但要通过手机 APP 保持系统实时激活并监控必要时主动制动。这不是那种“一键泊车”的营销话术而是一份把信号、状态机、交互逻辑、性能指标、关联件要求全部摊开的工程规范。它解决的核心问题是怎么让一台车在用户下车之后自己从 A 点开到 B 点停好或者从 C 点开出来到 D 点全程可监控、可打断、可追责。适合谁看做泊车功能定义的产品经理、写 CAN 矩阵的底层软件工程师、搞 HUT 和 APP 交互的 HMI 开发者以及需要理解 AVP 系统边界的测试工程师。如果你只想知道“记忆泊车怎么用”这份文档可能太硬但如果你要落地一个 HAVP 功能它就是那张不能绕过的底图。2. 信号需求拆解输入输出矩阵怎么读、怎么用2.1 输入信号从 HUT 到 AVP 的控制链路文档第 5 页开始列输入信号第一组就是 HUT 发给 AVP 的 CAN 信号。这里有个细节值得注意SelPrkgFctnCmd这个信号把泊车功能选择做成了枚举0x5 是 Select HAVP Parking0x6 是 Select PAVP Parking。也就是说HAVP 不是孤立功能它和 APA、P2P、探索前进、倒车、PAVP 共用同一个功能选择信号。做集成的时候如果 HUT 侧的状态机没把优先级理清楚很容易出现用户点了 HAVP 但系统还在 P2P 模式里打转的情况。路线命名信号HUT_HAVP_PahNameSet1到Set10一共 10 个每个都是 0x00 到 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 的有效值备注里写了国标 2312。这意味着路线名称支持中文字符编码但长度给得很宽。实际做 HUT 输入框的时候得自己限制字符数不然用户粘贴一大段文本进去CAN 信号截断或者填充规则没对齐AVP 侧收到的名称就是乱码。/* 输入信号结构体片段 - 基于文档第5-15页整理 */ typedef struct { uint8_t SelPrkgFctnCmd; /* 0x0:No Selection, 0x5:Select HAVP Parking */ uint8_t HUT_HAVP_PahNameSet[10][32]; /* 10条路线名称国标2312编码 */ uint8_t HUT_HAVP_Return_Btn; /* 0x0:No Request, 0x1:Request */ uint8_t HUT_HAVP_Path_Delete; /* 0x0:No Request, 0x1-0xA:有效路线号 */ uint8_t HUT_HAVP_Path_Select; /* 用户选择的路线号 */ uint8_t HUT_HAVP_Set_Starting; /* 设置起点按键 */ uint8_t HUT_HAVP_Learning_Set_ParkLot; /* 0x1:Fixed, 0x2:Random */ uint8_t HUT_HAVP_Set_Path_Ending; /* 设置终点按键 */ uint8_t HUT_HAVP_LearningTypeSele; /* 0x1:泊出路径, 0x2:泊入路径 */ uint8_t HUT_HAVP_SelfParLot_Ending; /* 设置当前车位为终点 */ } HAVP_InputFromHUT_t;T-BOX 侧输入信号有四个TBOX_HAVP_Active_Btn、TBOX_HAVP_Path_Select、TBOX_HAVP_Return_Btn、TBOX_HAVP_DevicefailSts。注意TBOX_HAVP_DevicefailSts是 T-BOX 反馈的手机端状态不是 AVP 自己判断的。这意味着手机 APP 的在线状态、蓝牙连接质量、设备故障都会通过 T-BOX 转成 CAN 信号给 AVP。如果 T-BOX 和 AVP 之间的超时策略没定义好用户手机断连了但 AVP 还在跑就是典型的安全缺口。底盘信号这块文档列了 ABS 的车速有效和车速、EPB/ESP 的 EPB 状态和开关、ESP 的制动踏板状态、ECM 的油门踏板开度和有效位、BCM 的门锁和转向灯、SRS 的主驾安全带、EPS 的握手和人工干预反馈。这些信号不是 HAVP 独有的但 HAVP 对它们的有效性要求更高。比如VehSpdVld无效时AVP 必须能判断是传感器故障还是通信丢失而不是简单降级。2.2 输出信号AVP 到 HUT/TBOX 的状态回传输出信号从第 16 页开始第一组是 AVM 相关AVM_CurrSts和HAP_Hmi_Index。AVM 工作状态和视图布局模式这两个信号决定了 HUT 上显示什么画面。做 HMI 的人要注意HAP_Hmi_Index不是随便定的它和 AVM 的视图布局模式绑定切换泊车视角的时候如果索引对不上画面会卡在上一帧。HAVP_WorkSts是核心状态信号发给 HUT 和 TBOX。这个信号的值域文档没在截取部分展开但从状态机章节可以反推它至少覆盖待机、建图中、建图完成、路径匹配中、泊入中、泊出中、暂停、故障、完成。实际联调时HAVP_WorkSts的跳变顺序比值本身更重要HUT 和 APP 都依赖它的迁移来更新 UI。路线信息输出是一组 10 个路线的结构每个路线包含HAVP_Learning_PathNum路线 ID、HAVP_Learning_PathType路线类型、HAVP_Learning_LotType车位类型、HAVP_Path_Status路线状态、HAVP_Path_Learnrate学习进度、HAVP_PahDst路线长度、HAVP_PahNameFeed路线名称反馈。这组信号是 HUT 显示路线列表的数据源。/* 输出信号结构体片段 - 基于文档第16-19页整理 */ typedef struct { uint8_t AVM_CurrSts; /* AVM工作状态 */ uint8_t HAP_Hmi_Index; /* AVM视图布局模式 */ uint8_t HAVP_WorkSts; /* HAVP功能状态 */ struct { uint8_t PathNum; /* 路线ID */ uint8_t PathType; /* 路线类型 */ uint8_t LotType; /* 车位类型: 固定/流动 */ uint8_t PathStatus; /* 路线状态 */ uint8_t Learnrate; /* 学习进度 0-100 */ uint16_t PahDst; /* 路线长度 */ uint8_t PahNameFeed[32]; /* 路线名称反馈 */ } Path[10]; } HAVP_OutputToHUT_TBOX_t;提示输入输出信号表里HUT 和 T-BOX 的接收方都写了 AVP但实际 CAN 矩阵里要区分是直接路由还是网关转发。如果 T-BOX 信号经过网关延迟和丢帧策略要单独定义。3. 状态机与功能流程建图、泊入、泊出怎么串起来3.1 状态描述与迁移条件文档第 32 页开始是状态机。HAVP 的状态不是一条直线而是分层的顶层是功能状态关闭、待机、建图、泊入、泊出、故障每个功能状态下又有子状态。建图状态下系统要处理“等待起点设置”“记录路径中”“等待终点设置”“保存中”这几个子状态。泊入状态下有“路径匹配”“巡航搜索车位”“泊入执行”“完成确认”。状态迁移条件里有几个容易翻车的地方。第一从待机到建图的迁移要求HUT_HAVP_LearningTypeSele先设置好是泊入路径还是泊出路径同时HUT_HAVP_Learning_Set_ParkLot要设置车位类型。如果这两个信号在同一个 CAN 周期到达AVP 侧的处理顺序会影响最终进入哪个建图模式。第二从建图到保存完成的迁移依赖HAVP_Path_Learnrate达到 100%但这个进度是 AVP 自己算的HUT 只是显示。如果 AVP 的进度计算和实际存储不同步用户看到 100% 但路线没存上下次用车就找不到路线。/* 状态迁移伪代码 - 基于文档第32-33页逻辑 */ typedef enum { HAVP_STATE_OFF 0, HAVP_STATE_STANDBY, HAVP_STATE_MAPPING, HAVP_STATE_PARK_IN, HAVP_STATE_PARK_OUT, HAVP_STATE_FAULT } HAVP_State_t; HAVP_State_t HAVP_StateTransition(HAVP_State_t current, HAVP_Event_t event) { switch (current) { case HAVP_STATE_STANDBY: if (event.SelPrkgFctnCmd 0x5 event.LearningTypeSele ! 0) { return HAVP_STATE_MAPPING; /* 进入建图 */ } if (event.SelPrkgFctnCmd 0x5 event.PathSelectValid) { return HAVP_STATE_PARK_IN; /* 进入泊入 */ } break; case HAVP_STATE_MAPPING: if (event.Learnrate 100 event.PathSaved) { return HAVP_STATE_STANDBY; /* 建图完成回待机 */ } if (event.ReturnBtn 0x1) { return HAVP_STATE_STANDBY; /* 用户取消 */ } break; case HAVP_STATE_PARK_IN: if (event.ParkInComplete) { return HAVP_STATE_STANDBY; } if (event.BrakeOverride || event.DeviceFail) { return HAVP_STATE_FAULT; } break; default: break; } return current; }3.2 HUT 交互逻辑车机端要处理哪些用户操作第 37 页开始是 HUT 交互逻辑详述。HUT 是用户和 HAVP 之间的主要界面它要处理的操作包括功能选择、路线列表展示、路线命名、路线删除、路线选择、起点设置、终点设置、车位类型设置、学习类型选择、返回按键。这些操作对应的 CAN 信号在输入信号章节已经列了但交互逻辑章节补充了时序要求。比如路线命名用户在中控屏上输入名称后HUT 不是每敲一个字符就发一次 CAN而是等用户确认后再发HUT_HAVP_PahNameSet。如果用户输入的是中文HUT 要先转成国标 2312 编码再填充到 32 字节的信号里。这里有个坑国标 2312 一个汉字占 2 字节32 字节最多 16 个汉字但文档没写超长怎么处理。常见做法是 HUT 侧限制输入长度AVP 侧做截断保护。路线删除和路线选择共用HUT_HAVP_Path_Delete和HUT_HAVP_Path_Select值域都是 0x0 到 0xA。0x0 表示无请求0x1 到 0xA 对应 10 条路线。如果用户删除了第 3 条路线后面的路线会不会前移文档没明说但从输出信号的HAVP_Learning_PathNum是固定 10 个位置来看删除后应该是该位置置空而不是整体前移。HUT 显示的时候要处理空位不能简单按数组下标渲染。3.3 APP 交互逻辑手机端和车机端的分工第 52 页开始是 APP 交互逻辑。APP 和 HUT 最大的区别是APP 可以远程激活但必须保持在线。TBOX_HAVP_Active_Btn是 APP 上的激活按键TBOX_HAVP_Path_Select是 APP 上选择的路线号TBOX_HAVP_Return_Btn是 APP 上的返回按键。这三个信号通过 T-BOX 转 CAN 发给 AVP。APP 还要接收HAVP_WorkSts和路线信息用来显示当前状态和路线列表。这里有个安全设计APP 上的制动操作不是直接发 CAN 信号给 AVP而是通过 T-BOX 走另一条链路。文档在功能描述里写了“必要时可以通过手机 APP 进行制动”但具体是 APP 发指令给 T-BOXT-BOX 再触发制动还是 APP 直接调用车辆的制动接口截取部分没展开。做 APP 的人需要确认这条链路的延迟和可靠性不能假设和 HUT 的制动一样快。注意APP 和 HUT 都能发起返回操作如果两边同时按返回AVP 侧要定义优先级。常见做法是 HUT 优先因为 HUT 在车内响应更快。4. 性能需求与关联件要求那些容易被忽略的硬指标4.1 性能需求响应时间、成功率、边界条件第 60 页开始是性能需求。这部分在截取内容里没有展开具体数值但从功能描述和状态机可以推断几个关键指标。建图成功率用户从 A 点开到 B 点系统要能稳定记录路径不能因为光照变化、地面纹理重复就丢帧。泊入成功率路径匹配后车辆要能沿着记忆路线开到目标车位中途遇到障碍物要能暂停或绕行。泊出成功率从车位出来到 D 点要能处理窄通道、直角弯、坡道。响应时间方面从用户按下 APP 激活按键到 AVP 开始执行延迟要控制在一定范围内。如果 T-BOX 到 AVP 的 CAN 传输加上 AVP 内部状态迁移超过 500ms用户会感觉“按了没反应”。从 AVP 发出制动请求到 ESP 执行延迟要求更严通常要在 100ms 以内。边界条件里文档第 69 页有场景需求和边界条件。典型边界包括路线长度上限、车位宽度下限、通道宽度下限、光照条件、天气条件。这些边界不是拍脑袋定的是建图阶段就要判断的。如果用户在不符合边界条件的场景下建图系统应该拒绝保存而不是存一条用不了的路线。4.2 关联件要求AVP 不是一个人在战斗第 65 页和第 79 页都有“关联件要求”内容可能重复或者分了两部分。关联件包括EPS、ESP、EPB、BCM、ECM、ABS、SRS、TCU、HUT、T-BOX、BLE。每个关联件都要满足一定的接口要求。EPS 要支持握手和人工干预检测。EPS_AvailSts是握手状态EPS_InterferDetd是人工干预反馈。如果驾驶员在 HAVP 运行中转动方向盘EPS 要能检测到并通知 AVPAVP 要立即退出或暂停。ESP 要支持 LSM 运动服务文档里列了LSMSubMTReqAvailable、LSMSubMTReqEcho、LSMSubMTLevelEcho、LSMSubMTLongEcho、Lsm12ComfortAvl、Lsm12EmergencyAvl、Lsm23Avl这些信号。LSM 是纵向运动管理AVP 通过它请求制动ESP 反馈当前控制模式和可用性。BCM 要提供门锁、转向灯、后视镜状态。HAVP 运行中如果检测到车门打开要立即退出。TCU 要提供换挡器位置HAVP 只允许在 P 挡或 N 挡激活。BLE 要提供 T-BOX 和手机之间的连接状态连接断了APP 就失去监控能力AVP 要降级或退出。/* 关联件状态检查片段 - 基于文档第65-79页逻辑 */ typedef struct { uint8_t EPS_AvailSts; /* EPS握手状态 */ uint8_t EPS_InterferDetd; /* 人工干预检测 */ uint8_t EPBSts; /* EPB执行状态 */ uint8_t BrkPedalSts; /* 制动踏板状态 */ uint8_t DrvDoorSts; /* 主驾门状态 */ uint8_t PassengerDoorSts; /* 副驾门状态 */ uint8_t LRDoorSts; /* 左后门状态 */ uint8_t RRDoorSts; /* 右后门状态 */ uint8_t TrunkSts; /* 行李箱状态 */ uint8_t HoodSts; /* 前仓盖状态 */ uint8_t DrvSBR; /* 主驾安全带 */ uint8_t TGS_LEVER; /* 换挡器位置 */ uint8_t TBOX_FunStatus; /* T-BOX AVP功能状态 */ } HAVP_AssociatedParts_t; uint8_t HAVP_CheckAssociatedParts(HAVP_AssociatedParts_t *parts) { if (parts-EPS_AvailSts ! 0x1) return 0; /* EPS未握手 */ if (parts-EPS_InterferDetd 0x1) return 0; /* 人工干预 */ if (parts-DrvDoorSts 0x1) return 0; /* 主驾门开 */ if (parts-PassengerDoorSts 0x1) return 0; /* 副驾门开 */ if (parts-TrunkSts 0x1) return 0; /* 行李箱开 */ if (parts-HoodSts 0x1) return 0; /* 前仓盖开 */ if (parts-DrvSBR 0x1) return 0; /* 主驾安全带未系 */ if (parts-TGS_LEVER ! 0x0 parts-TGS_LEVER ! 0x1) return 0; /* 非P/N挡 */ return 1; }提示关联件检查不是一次性的HAVP 运行中要周期性检查。如果某个关联件状态在运行中变成不满足要立即触发退出流程不能等到下一个状态迁移点。5. 避坑与排查HAVP 联调中最容易翻车的五个点5.1 路线名称乱码国标 2312 编码没对齐现象HUT 上输入的路线名称在 APP 上显示成乱码或者 AVP 侧收到的名称和输入的不一致。原因HUT 侧用 UTF-8 编码发送AVP 侧按国标 2312 解码。或者 HUT 侧填充信号时没有按 32 字节对齐短名称后面没有补 0x00。解决HUT 侧统一用国标 2312 编码填充时不足 32 字节的补 0x00。AVP 侧解码时先找 0x00 截断再转 UTF-8 显示。联调时用 CANoe 抓包直接看信号原始字节确认编码一致。5.2 状态机卡在建图学习进度不到 100%现象用户建图完成后HUT 显示学习进度 99%一直不跳到 100%路线保存不了。原因AVP 侧的学习进度计算依赖视觉里程计和路径长度如果建图过程中有急转弯或者倒车里程计累积误差会导致进度计算偏差。另外如果HAVP_Path_Learnrate的更新周期和 HUT 的读取周期不同步HUT 可能读到旧值。解决AVP 侧在路径终点确认后强制将进度置为 100%不等里程计。HUT 侧用变化沿触发读取而不是周期读取。联调时在 AVP 侧打日志记录每次进度更新的触发条件。5.3 APP 激活失败T-BOX 信号没路由到 AVP现象用户在 APP 上按激活APP 显示已发送但车辆没反应HUT 上 HAVP 状态还是待机。原因T-BOX 到 AVP 的 CAN 信号没有在网关里配置路由或者路由了但周期不对。T-BOX 信号通常是事件触发如果网关按周期转发可能丢事件。解决检查网关路由表确认TBOX_HAVP_Active_Btn是事件触发转发不是周期转发。在 AVP 侧加超时检测如果收到激活信号后一定时间内没有后续操作自动回待机。5.4 泊入中途退出关联件状态误触发现象HAVP 泊入过程中车辆突然退出HUT 显示故障但用户没有做任何操作。原因关联件检查太敏感。比如DrvSBR主驾安全带信号用户下车后安全带是解开状态如果 AVP 在泊入过程中周期性检查这个信号就会误判。实际上 HAVP 运行时用户不在车内主驾安全带本来就应该是解开的。解决区分建图阶段和泊入/泊出阶段的关联件检查项。建图阶段用户在车内检查安全带泊入/泊出阶段用户不在车内不检查安全带但检查车门和仓盖。文档里DrvSBR是输入信号但没写什么时候用需要根据场景细化。5.5 路线匹配失败建图时的起点和泊入时的起点偏差太大现象用户把车开到 A 点附近开启记忆泊车系统提示“未找到匹配路线”。原因建图时记录的 A 点位置和泊入时车辆实际位置偏差超过阈值。视觉建图对起点位置敏感如果 A 点附近有相似场景匹配算法可能找不到正确路线。解决建图时在 A 点做明显标记或者要求用户把车停在 A 点的特定区域内。AVP 侧的匹配算法要设置合理的搜索半径不能太小也不能太大。联调时记录每次匹配的得分分析失败案例的位置偏差。6. 从规范到落地怎么用这份文档验证你的 HAVP 实现这份 79 页的文档最大的价值不是让你照着抄而是给你一套验证清单。我一般会把它拆成三张表信号表、状态表、场景表。信号表用来对 CAN 矩阵状态表用来对状态机实现场景表用来对测试用例。信号表怎么用把输入信号和输出信号分别列出来每个信号标注发送方、接收方、信号名、值域、备注。然后拿你的 CAN 矩阵逐条比对。重点看值域和备注比如SelPrkgFctnCmd的 0x5 是 HAVP0x6 是 PAVP如果你的矩阵里 0x5 是别的功能联调必挂。状态表怎么用把状态描述和迁移条件抄下来画成状态迁移图。然后拿你的代码逐条走查每个迁移条件是否实现迁移时的动作是否执行异常迁移是否处理比如从建图到待机的迁移条件是学习进度 100% 且路径保存成功如果你的代码只判断了进度没判断保存结果就会出现“进度 100% 但路线没存上”的问题。场景表怎么用文档第 69 页的场景需求和边界条件加上第 76 页的典型使用场景可以整理成测试用例。典型场景包括固定车位泊入、流动车位泊入、泊出、建图取消、泊入中途人工干预、APP 断连、关联件故障。每个场景要覆盖正常流程和异常流程。# 验证脚本片段 - 用CANoe或类似工具的回放数据做自动化检查 import can import cantools db cantools.database.load_file(havp.dbc) bus can.interface.Bus(vector, channel0, bitrate500000) # 检查HAVP_WorkSts的状态迁移是否合法 valid_transitions { 0x0: [0x1], # OFF - STANDBY 0x1: [0x2, 0x3, 0x4, 0x5], # STANDBY - MAPPING/PARK_IN/PARK_OUT/FAULT 0x2: [0x1, 0x5], # MAPPING - STANDBY/FAULT 0x3: [0x1, 0x5], # PARK_IN - STANDBY/FAULT 0x4: [0x1, 0x5], # PARK_OUT - STANDBY/FAULT 0x5: [0x1], # FAULT - STANDBY } last_state None for msg in bus: if msg.arbitration_id db.get_message_by_name(HAVP_Status).frame_id: decoded db.decode_message(msg.arbitration_id, msg.data) current_state decoded[HAVP_WorkSts] if last_state is not None: if current_state not in valid_transitions.get(last_state, []): print(f非法迁移: {hex(last_state)} - {hex(current_state)}) last_state current_state这个脚本的逻辑是从 CAN 总线上实时读取HAVP_WorkSts每收到一帧就检查当前状态是否在上一个状态的合法迁移列表里。如果出现非法迁移打印出来。参数说明valid_transitions字典根据文档第 32 页的状态迁移条件整理db.get_message_by_name里的消息名要换成你 DBC 里的实际名称。跑测试用例的时候把这个脚本挂在后台跑完一轮看有没有非法迁移。还有一个技巧用文档里的性能需求做压力测试。比如建图成功率你可以让测试车在同一路段反复建图 50 次统计成功次数。泊入成功率在同一车位反复泊入 100 次统计成功次数和平均耗时。这些数据比单次演示有说服力。从那以后我每次拿到新的功能规范都先做三件事把信号表导进 DBC 比对把状态表画成迁移图走查代码把场景表拆成测试用例跑一轮。这份 HAVP 文档我前后翻了不下十遍每次都能发现之前漏掉的细节。希望帮到你。本文还有配套的精品资源点击获取