如何判断停车设备厂商是否适合配合软件联调？

停车软件最怕的不是设备完全不响应，那种问题反而容易定位。麻烦的是设备大多数时候都能用，到了无牌车、跟车、反向通行、离线收费或人工抬杆这些边角场景，系统里的车辆、订单和实际道闸状态开始对不上。

截至2026年7月，GB 17907—2010《机械式停车设备 通用安全要求》和GB/T 26559—2021《机械式停车设备 分类》仍为现行标准。它们能帮助项目确认设备类别和安全要求，却不能替代软件接口验收。设备合规、接口可用、厂商配合，这三件事要分别核实。

一次演示跑通，只能说明这个场景当时能跑

停车项目里的“设备”并不是一个东西。出入口可能有车牌识别相机、道闸、补光灯、显示屏和对讲；车位引导要接探测器、指示灯与网关；自助缴费会牵涉订单、支付和发票；机械式停车设备还有PLC、库位状态、存取车流程与安全联锁。厂商说“我们有接口”，先别急着往下排开发计划，要问清楚它指的是相机识别结果、停车场管理平台接口，还是可以控制设备的本地协议。

这几层差别很大。只拿到云平台查询接口，未必能在现场断网时工作；只拿到相机SDK，收费规则和场内记录还得自己补；拿到开闸接口，也不代表能知道闸杆究竟有没有抬起。联调范围不清，后面出现问题时，硬件、厂商平台和项目软件很容易互相等结果。

比较稳妥的做法，是在报价和排期前画出一张实际连接图：每类设备接到哪里，谁主动发消息，谁保存原始记录，控制命令经过哪一层，网络中断后由谁补数据。图不必做得漂亮，能把边界说清就行。

接口资料要让没参加会议的人也能接

能用于开发的资料，至少应包括接口或协议说明、设备和固件版本对应关系、鉴权方式、数据字典、状态码与故障码、事件示例、控制指令、回调重试规则、测试工具或测试账号，以及版本变更记录。

看文档时，不妨挑一条最常见的“车辆入场”报文往下追。车辆记录的唯一编号是什么，车牌颜色和识别置信度有没有，图片怎样取得，时间由相机还是服务器生成，车道方向怎么区分，同一辆车连续触发两次会不会产生两笔入场记录。字段说明如果只写“状态：0/1/2”，却没有每个值出现的条件，这份文档还不能直接拿来开发。

现场协议使用RS485、TCP、HTTP、MQTT或厂商SDK，本身并不能说明好不好接。真正拉开差距的是：文档与实际报文是否一致，错误能否复现，厂商能否指出某个字段从哪个固件版本开始变化。靠技术人员在群里逐句解释也能暂时接通，但下一次换型号、换人或升级，前面问过的问题通常还会再来一遍。

正常车辆不难，异常车辆和异常订单才见配合能力

联调不能只测“识别车牌—生成订单—缴费—开闸”。停车场每天都会碰到一些不那么标准的情况：无牌车、污损车牌、识别错一位、车辆倒出后再次进入、前车未过闸后车已经触发、固定车过期、同一车牌在多个入口出现、场内缴费后超时离场、支付成功但回调延迟、人工放行以及设备离线期间的进出场。

这些情况不一定都由设备厂商处理，但厂商必须说清自己会产生什么事件。以人工抬杆为例，平台能不能收到开闸原因和操作来源；车辆倒车离开后，相机是否上报反向事件；一笔支付回调重复发送三次，厂商平台会不会重复销账。双方把事件含义说清，软件才能决定是合并、忽略、重算还是交给值班人员处理。

测试时要保留原始图片、原始报文、设备时间、服务器接收时间、车道号、设备编号和最终业务结果。只有平台页面截图，通常解释不了问题发生在哪一层。

开闸能调用，不等于控制已经做完

道闸、车位锁和机械式停车设备都带有现场动作。软件可以发出请求，但不能绕过设备本身的限位、互锁、人员检测、急停和故障保护。特别是机械式停车设备，软件对接的重点应放在任务申请、状态读取、过程反馈和结果确认上，安全控制仍应由符合要求的设备控制系统承担。

一条控制记录至少要分清“请求已接收”“设备允许执行”“正在执行”“执行完成”和“执行失败”。厂商如果只返回一个成功码，软件端无法判断闸杆已经抬起，还是网关仅仅收到了命令。超时重发也要测：同一个开闸请求发两次，是识别为同一任务，还是执行两次；设备故障或安全条件不满足时，返回的是明确原因，还是一直等到软件超时。

这里可以设硬门槛。凡是远程指令可能越过安全联锁、执行结果无法确认、现场手动接管方式不清的设备，不应因为其他项目都跑通就直接上线。

把网断掉、把电重启，再看数据还能不能对上

停车场的设备分散在出入口、地下车库和岗亭，交换机、光纤、蜂窝网络、现场工控机中的任何一处波动，都可能让消息中断。合适的厂商会提前说明本地能保存多少记录，恢复后按什么顺序补传，重复消息怎样识别，设备重启后编号和时间是否保持一致。

一轮有效测试不需要故意把现场折腾得很复杂。断网后让几辆测试车进出，再恢复网络；设备运行中断电重启；把同一回调重复推送；让平台响应变慢；把相机时间调出偏差，再观察补传、去重、重连、校时和告警。最终要核对的不是“数据后来出现了”，而是车辆记录、订单、设备状态和现场实际情况仍然对得上。

今天接好的接口，下次升级还算不算数

不少联调问题并非第一次就有，而是设备换批次或固件升级后才出现。字段改名、枚举值增加、图片地址失效、默认心跳周期改变、SDK只支持旧操作系统，都可能让已经通过的功能重新出错。

因此要看厂商有没有正式版本号、发布说明和兼容策略。升级前能否提供测试版本，少量设备能否先验证，失败后能不能回退，重大变更会提前多久通知，旧接口准备保留多久。回答“正常不会改”不算版本管理；能拿出变更记录，并说明影响哪些型号和接口，才有继续配合的基础。

车牌、图片和操作权限，不能到上线后再补

停车系统通常会处理车牌号码、车辆图片、进出时间、支付记录和操作日志。它们怎样采集、传输、查看、导出和删除，联调阶段就要约定。涉及能够识别到自然人的信息时，还应结合《中华人民共和国个人信息保护法》落实明确目的、最小必要、访问权限和安全措施。

现场重点看几件实事：设备是否长期使用同一默认密码，接口是否加密，密钥能否按项目或设备更换，远程维护账号怎样开通和收回，图片链接会不会永久公开，日志能否查到谁在什么时间做了开闸、改价和手工销账。厂商若要求长期保留高权限远程入口，却说不清账号、日志和责任范围，后续运维风险会很难收住。

群里回复快，不等于问题有人负责到底

软件联调往往横跨硬件、嵌入式、平台、网络和现场施工。销售愿意帮忙传话当然有用，但项目还需要一名能够判断协议和设备行为的技术负责人。问题出现后，谁提供日志，谁复现，哪个版本修复，什么时候回归，最好落到同一份问题记录里。

判断配合能力，可以故意挑一个中等难度的问题走完整个处理过程。看厂商是只回复“我们这边正常”，还是会核对设备编号、固件、时间段和原始报文；修复后是发一句“已经处理”，还是给出版本、变更点和复测条件。前者靠人情维持，后者才适合批量复制。

用一轮小范围联调，给采购决定留下证据

作为软件服务提供方，红数科技更看重真实设备上的小范围联调，而不是再听一轮能力介绍。选一个入口、一个出口和项目里风险最高的一类设备，跑完正常流程，再加入断网、重启、重复回调、识别错误和人工放行。机械式停车设备则要把安全条件不满足、任务取消和现场接管纳入测试。

下面这张表可以直接用于前期尽调，分值不是重点，证据是否完整才是重点。

这轮测试里有几项不宜用总分抵消：远程控制越过安全边界，进出场记录无法形成唯一编号，离线恢复造成车辆或订单错乱，生产版本变更无法追溯，关键账号和操作没有审计记录。任何一项没有解决，都应先停在小范围验证阶段。

合同和验收要写交付物，不只写“配合联调”

“配合软件联调”放在合同里过于宽泛。技术附件可以写得更具体：交付哪一版接口文档和SDK，提供哪些型号的样机与测试环境，异常工况由谁协助复现，接口变更怎样通知，现场支持到什么阶段，停产或替代型号怎样处理。需要厂商平台转发数据的，还要约定服务可用性、数据导出和故障后的补偿方式。

验收也应回到证据。接口版本、设备序列号、固件版本、测试时间、原始报文、问题单、修复版本和复测结果放在一起，才能说明哪套设备在哪些条件下通过。页面能看到车辆，不足以证明软件联调完成；设备状态、车辆记录、订单结果和现场动作能够互相核对，出了异常还能追到责任位置，这才是可交付的结果。

一家停车设备厂商是否适合配合软件联调，答案不会写在产品彩页上。真正有用的信息，藏在一条异常报文能不能解释清楚，一次断网后账和车还能不能对上，一个版本变化能不能提前被看见，以及现场出问题时有没有人把它跟到复测通过。

参考资料

1. 全国标准信息公共服务平台：GB 17907—2010《机械式停车设备 通用安全要求》。
2. 全国标准信息公共服务平台：GB/T 26559—2021《机械式停车设备 分类》。
3. 中国人大网：《中华人民共和国个人信息保护法》。
4. 中共中央、国务院：《关于推动城市高质量发展的意见》，2025年8月。

具体许可、检验、接口与验收要求，应以设备类别、项目所在地规定、合同技术文件、厂商现行资料和现场测试结果为准。