范围：做集成，不卖停车硬件
这里的停车管理，是把既有或第三方停车系统接入建筑平台。我们不提供道闸、出票机、支付终端、车牌识别相机或车位传感器。停车厂商继续对其设备、交易与质保负责。我们的工作，是把车位占用、道闸状态、进出事件与设备故障带入建筑运营视图，再与照明、通风、门禁和报表建立联系。边界清楚，责任就清楚，客户也可以继续使用已经采购的停车系统。若正在规划新系统，我们可以先定义接口要求。接口清单在停车厂商与建筑团队开工前确认。一份书面接口清单，也是防止日后出现“集成已包含在别人包里”这类说法的明确屏障。这份清晰让日后更换停车厂商成为可能，也应体现在图纸、点表与维保合同中。
- 集成既有或第三方停车系统
- 道闸、出票机与相机由停车厂商负责
- 可在采购前定义接口要求
- 责任边界写入范围说明
数据与接口
停车系统的数据接口各不相同。较老的系统提供道闸开启、满位牌或报警的无源干接点；较新的系统提供软件 API、数据库导出或 Modbus/BACnet 网关。集成应从数据清单开始：需要哪些点、刷新频率多少、每个点由谁负责。车位与楼层计数、进出事件、支付状态与故障码都是常见对象。时间同步比看上去更重要：进出事件与视频监控差两分钟，事故复核就会变得困难。每个点都需要名称、单位、质量标记与可追溯来源。数据清单应区分实时状态与历史记录，因为两者通常走不同路径，延迟与保留规则也不同。若厂商不愿提供接口说明，这场谈判应发生在签合同之前，而不是在第一次故障之后。
- 接口工作开始前先确认数据清单
- API、数据库导出、Modbus、BACnet 或干接点
- 与视频、门禁记录保持时间同步
- 每个点都有名称、单位、质量标记与来源
占用计数与引导
计数可靠之后，平台可以驱动引导：剩余车位牌、楼层指示、分区显示屏与应用视图。引导逻辑应带滞回，避免牌面在阈值附近反复跳变，并在计数失效时提供降级策略。充电车位状态可以在充电桩上报时显示。历史利用率支持车位分配、价格策略与非营业时段准入的决策。平台可以比较工作日与周末模式，找出长期满位的分区，并显示车辆停留时长。这些是运营洞察，不替代停车运营方自己的收费系统。显示一个无法验证的车位，比不显示更糟，因为司机在第二次被误导后就不再信任系统。计数陈旧时，应显示中性提示，而不是最后一个已知数字。计数应在运营第一天用人工盘点结果校准，并在任何传感器施工后再次校准。
- 剩余车位牌与楼层指示
- 用滞回避免阈值附近反复跳变
- 充电桩上报时显示充电车位状态
- 按分区与时段分析利用率
照明、通风与 CO 控制
停车事件与建筑其他系统连接后才有更大价值。车辆进入地下层，可以触发该区域的照明场景与通风级数；道闸故障可以生成设施告警，并把运维人员指向最近的摄像机；出场事件可以关联对应的门禁记录。通风应跟随 CO 与占用数据，而不是固定定时，并具备分级风机转速与明确的换气时段。典型分级控制的一级阈值在 20 至 30 ppm 之间，更高报警值在 50 ppm 以上，但实际数值必须来自车库通风设计与当地要求。消防与排烟仍由消防系统负责，停车集成不得延迟或覆盖生命安全序列。
- 入场事件触发分区照明与通风
- 道闸故障路由到设施告警与视频
- CO 与占用数据驱动通风级数
- 消防与排烟不进入 BAS 控制序列
门禁、充电与支付边界
门禁与支付是必须尽早划清的边界。停车系统拥有票据、费率、优惠核销与支付；建筑平台可以接收状态与事件用于关联，但不应成为交易系统。若同一张凭证既开大堂门又开道闸，门禁系统与停车系统之间需要明确关系，包括其中一方离线时的行为。充电桩增加第二层商业关系：充电运营商拥有会话与计费，建筑平台可以限制园区需量或把充电移向发电时段。每条边界都应写明记录系统、数据方向与降级行为。这些地方的含糊，通常由司机在道闸前发现，而那是解决问题最不方便的地点。
- 停车系统仍是交易系统
- 门禁与停车的凭证关系明确
- 充电会话与计费归充电运营商
- 每条边界都写明记录系统与降级方式
报表与运营
停车报表应回答运营问题：各分区有多满、什么时候满、满了多久、引导出错的频率如何。平台可以记录车位占用、进出计数、道闸故障与设备停机时间。在接口允许时，可以与停车运营方的交易总额做核对，但核对是检查，不是计费系统。告警应按设备与位置归组，超出集成范围的故障要有通往停车厂商的清晰路径。每月一次利用率与故障复盘，通常比一块没人看的实时大屏更有价值。复盘还应用实际到场车辆检验引导逻辑，因为午夜准确的技术，在早高峰仍可能出错。趋势数据应保留到足以比较季节，而不只是比较几周。
- 按分区统计占用与停留趋势
- 记录道闸故障与设备停机
- 仅在接口允许时做核对
- 超出范围的故障路由给停车厂商
交付、测试与厂商边界
交付从接口勘查与测试计划开始。每个点都要对着停车系统验证，包括正常值、断线、重启与数据陈旧。引导牌要在阈值附近检查，而不是只看中间值。通风联动要用模拟 CO 信号与消防模式分别测试，因为这两种条件不能冲突。交付内容包括数据清单、点位映射、API 或寄存器文档、告警路由，以及两家厂商的升级联系方式。与停车厂商安排一次联合测试是值得的，因为多数集成问题其实是责任归属问题，而不是协议问题。支持协议应写明道闸、计数器或网关故障时谁先响应，以及厂商到场前建筑团队该做什么。
- 先做接口勘查并约定联合测试计划
- 逐点验证，包括断线与陈旧数据
- 通风同时按 CO 与消防模式测试
- 写明升级联系人与第一响应方
停车集成功能与失效检查
14 行| 功能 | 来源系统 | 典型接口 | 平台作用 | 需检查的失效 |
|---|---|---|---|---|
| 车位与分区占用 | 停车传感器或计数器 | API、Modbus、干接点 | 趋势、引导与报表 | 重启后的计数漂移 |
| 道闸状态 | 道闸控制器 | 干接点或 API | 监视并生成故障告警 | 状态卡在开启或关闭 |
| 进出事件 | 停车系统 | API 或数据库导出 | 关联视频与门禁 | 事件时间与视频不一致 |
| 支付与出票状态 | 停车系统 | API | 仅读取状态，不处理交易 | 误以为平台可以收款 |
| 剩余车位牌 | 显示屏控制器 | API 或继电器 | 驱动引导逻辑 | 阈值附近牌面跳变 |
| 充电车位状态 | 充电桩系统 | API 或 Modbus | 显示可用状态 | 占用车位被显示为空闲 |
| 设备故障 | 停车厂商系统 | API 或干接点 | 把告警路由给责任厂商 | 告警没有责任方 |
| 车牌识别事件 | 停车系统 | API | 仅做关联与记录 | 车牌数据无规则留存 |
| 照明联动 | BAS | 本地 I/O 或现场总线 | 进出场触发分区场景 | 最后一辆车离场后灯仍亮 |
| 通风与 CO 联动 | CO 传感器与 BAS | 本地 I/O 或 Modbus | 分级风机与换气 | 级数卡死或换气被关闭 |
| 门禁关联 | 门禁系统 | API 或事件导出 | 关联车辆与凭证事件 | 道闸故障后凭证仍然有效 |
| 利用率报表 | 全部停车数据源 | 平台数据模型 | 按分区与时段统计 | 报表建立在陈旧计数上 |
| 时间同步 | 停车系统与 BAS | 网络时间或协议 | 保证事件还原一致 | 厂商升级后时钟漂移 |
| 厂商升级路径 | 双方厂商 | 支持协议 | 把故障路由给正确团队 | 双方都不接单 |
项目图景
3 张图片
常见问题
01你们提供道闸或出票机吗？
不提供。我们只做集成与监视，道闸、出票机、支付终端与车牌识别相机由停车专业厂商供货并负责，设备责任与质保因此集中在同一方。这也意味着，只要接口仍然可用，客户日后更换停车厂商时不必连带更换建筑平台。
02既有停车系统能接吗？
取决于它开放的接口。有 API、数据库导出、Modbus 或干接点的系统通常可以；先做接口勘查与数据清单，再判断范围。较老的系统可能需要网关或小型硬件接口，这部分成本应在报价固定之前弄清楚。
03平台可以收款吗？
不可以。支付与交易留在停车系统或其支付服务商，平台只读取状态用于监视与核对。把交易排除在建筑平台之外，也能缩小安全与审计范围，这是优势而不是限制。
04停车能联动照明和通风吗？
可以。车辆进入、分区占用或 CO 浓度可以触发照明场景与通风级数，但逻辑需与电气设计和车库通风要求一起确认。消防模式优先于所有常规序列，两者应一起测试，而不是分开测试。
05能在应用里显示剩余车位吗？
可以，前提是停车系统提供可靠的分区计数。引导逻辑需要滞回与计数失效时的降级策略，避免显示一个无法验证的数字。中性提示胜过自信的错误数字，运维人员也应能看到计数最后一次更新的时间。
06车牌识别包含在内吗？
我们不提供相机。若停车系统通过 API 暴露识别事件，平台可以接收并用于进出关联与记录。车牌数据的保留期限、访问权限与隐私规则，属于停车运营方与建筑数据政策，不能只由集成方决定。
07多个园区的停车能集中管理吗？
可以。各园区保留本地停车系统与本地控制，平台做集中监视、报表与告警路由。各站点的数据模型应从开始就保持一致。只有当同一个点位在各处含义相同时，集中报表才有意义，因此命名与计数规则应放在第一阶段。
下一步
把建筑交给我们。
告诉我们建筑类型、纳入范围的系统，以及你需要的结果。我们会给出通往可用系统的最短路径。