一、轨道交通共享单车停车桩通信方案概述
大家好，我是老张。在轨道交通领域摸爬滚打了十几年，今天咱们聊聊共享单车停车桩的通信方案。
说实话，这个项目一开始我也有点懵。地铁口、公交站旁边，共享单车乱停乱放，这问题太普遍了。但真正做起来才发现，通信方案才是整个系统的命脉。
1.1 项目背景
先说说为什么会有这个项目。
我记得2019年，上海某地铁站出口，共享单车堆得像小山一样。行人过不去，盲道被堵死，消防通道也占了。那时候我就想，能不能用技术手段解决这个问题？
后来机会来了。某市轨道交通集团找到我们，说要搞一个「共享单车停车桩」项目。说白了，就是在每个地铁站、公交枢纽周边，安装智能停车桩。单车必须停进桩位才能还车，否则继续计费。
这个项目有几个关键点：
- 覆盖范围广：全市几百个站点，每个站点几十个桩位
- 环境复杂：地下站、高架站、露天站，通信条件天差地别
- 实时性要求高：用户扫码、锁车、扣费，必须在秒级完成
- 成本敏感：每个桩位成本要控制在几百元以内
核心痛点：地铁站周边电磁环境极其复杂。列车进出站、信号系统、WiFi热点、手机信号...各种干扰源。通信方案必须扛得住这些干扰。
1.2 系统组成
整个系统分三层，我习惯叫它「端-边-云」架构。
| 层级 | 组件 | 功能 | 通信方式 |
|---|---|---|---|
| 端（终端层） | 停车桩、地磁传感器、锁控板 | 检测单车停放、控制锁具、采集状态 | 蓝牙、LoRa、NB-IoT |
| 边（边缘层） | 站点网关、边缘服务器 | 数据汇聚、本地决策、协议转换 | 4G/5G、有线以太网 |
| 云（云端层） | 业务平台、数据库、运维系统 | 订单管理、数据分析、远程升级 | 互联网、专线 |
你想想看，每个停车桩就是一个嵌入式设备。它要干什么？
- 检测有没有单车停进来（地磁或红外传感器）
- 识别单车ID（蓝牙或NFC）
- 控制锁具开合
- 上报状态到网关
- 接收云端指令
嗯，这里要注意。停车桩本身不能直接连互联网，成本太高。所以需要网关做中转。一个网关管几十个桩位，网关再通过4G或5G连到云端。
我的经验：网关的位置很关键。我曾在某地铁站把网关装在站厅角落，结果信号死活连不上。后来发现，那个位置正好被承重柱和金属屏蔽门挡住了。最后把网关挪到靠近出入口的位置，问题才解决。
1.3 通信需求分析
做通信方案，第一步就是搞清楚需求。我一般会列一个清单，逐条过。
1.3.1 实时性需求
用户扫码还车，从锁车到扣费成功，整个流程不能超过3秒。为什么？
我曾经做过测试，超过5秒用户就开始烦躁，超过10秒就会投诉。所以通信延迟必须控制在1秒以内。
- 停车桩 → 网关：≤200ms
- 网关 → 云端：≤500ms
- 云端处理：≤300ms
1.3.2 可靠性需求
轨道交通场景，通信不能掉链子。我遇到过最头疼的情况：早高峰时段，地铁站出口人山人海，几百辆单车同时还车。这时候通信压力最大。
具体要求：
- 丢包率：≤0.1%
- 可用性：≥99.9%（全年故障时间不超过8.76小时）
- 抗干扰：在-20dBm的干扰环境下仍能正常工作
避坑指南：我曾经在一个项目中，选用了某款LoRa模块，实验室测试一切正常。结果到了现场，地铁列车一进站，通信就中断。后来排查发现，列车牵引系统的谐波干扰正好落在LoRa的工作频段上。从那以后，我每次选型都会先做现场电磁环境测试。
1.3.3 功耗需求
停车桩是电池供电的，不能拉电线。一个桩位要撑多久？至少2年。
算一笔账：
- 电池容量：10000mAh（锂电池）
- 待机电流：50μA
- 工作电流：100mA（通信时）
- 每天通信次数：约50次（每次2秒）
理论续航：10000mAh / (50μA × 24h + 100mA × 50 × 2s / 3600s) ≈ 2.3年
嗯，这只是理论值。实际还要考虑电池自放电、温度影响、老化等因素。所以我一般会留30%的余量。
1.3.4 覆盖需求
一个网关能管多远？这取决于通信方式。
| 通信方式 | 覆盖半径 | 穿透能力 | 典型场景 |
|---|---|---|---|
| 蓝牙5.0 | 10-50米 | 弱 | 露天站、高架站 |
| LoRa | 100-500米 | 强 | 地下站、复杂环境 |
| NB-IoT | 1-3公里 | 较强 | 分散站点、郊区站 |
我个人习惯，地下站优先用LoRa。为什么？因为地下站结构复杂，柱子多、拐角多，蓝牙信号衰减太快。LoRa的扩频技术能穿透多层墙体，覆盖效果更好。
1.3.5 安全性需求
通信安全不能忽视。你想想看，如果有人恶意干扰停车桩通信，导致用户无法还车，那麻烦就大了。
安全要求：
- 数据加密：AES-128或以上
- 身份认证：双向认证，防止伪造桩位
- 防重放攻击：每个数据包带时间戳和序列号
- 固件安全：远程升级必须签名验证
核心观点：通信方案不是选一个技术就完事了。你得综合考虑实时性、可靠性、功耗、覆盖、安全这五个维度。缺一个，系统就可能在关键时刻掉链子。
1.4 我的选型思路
说了这么多，到底怎么选？我一般按这个步骤来：
- 先看环境：地下站还是地面站？有没有金属屏蔽？有没有强干扰源？
- 再看密度：一个站点有多少桩位？密集还是分散？
- 然后算功耗：电池能撑多久？能不能换电池？
- 最后看成本：每个桩位通信模块多少钱？网关多少钱？
举个例子。某地铁站是地下三层结构，站厅层有50个桩位。我建议用LoRa方案。为什么？
- 地下环境，蓝牙信号穿不过三层楼板
- 50个桩位，LoRa一个网关就能覆盖
- LoRa模块功耗低，电池能撑3年以上
- 成本可控，每个桩位通信成本不到50元
如果是露天站，桩位比较分散，我可能会选NB-IoT。直接连基站，不用装网关，省事。
小技巧：选型时别忘了考虑未来扩展。我见过一个项目，初期只装了50个桩位，选了蓝牙方案。结果后来要扩展到200个，蓝牙网关根本扛不住，最后全部换成了LoRa。白白浪费了前期投资。
1.5 本章小结
好了，这一章就聊这么多。总结一下：
- 项目背景：解决地铁站周边共享单车乱停乱放问题
- 系统组成：端-边-云三层架构，停车桩、网关、云端各司其职
- 通信需求：实时性、可靠性、功耗、覆盖、安全，一个都不能少
下一章，我会详细讲讲停车桩的硬件设计，包括主控芯片选型、传感器接口、电源管理这些实战内容。到时候我会分享一些踩过的坑，希望对你有帮助。
我是老张，咱们下章见。