4、UWB定位系统架构：整体架构设计、基站与标签角色定义、定位引擎部署模式、系统拓扑结构
这一章，我们来聊聊UWB定位系统的骨架——架构设计。说白了，就是搞清楚“谁负责发信号、谁负责算位置、数据怎么跑”。我见过不少项目，硬件选型没问题，算法也够先进，结果栽在架构上。嗯，咱们从最基础的开始捋。
4.1 系统整体架构：三层模型
我个人习惯把UWB定位系统拆成三层：感知层、网络层、应用层。你想想看，不管多复杂的项目，基本都逃不出这个框。
- 感知层：基站和标签。负责收发UWB脉冲，测量距离或角度。
- 网络层：定位引擎和通信链路。负责把原始测距数据算成坐标。
- 应用层：业务平台。负责展示位置、触发告警、对接MES/WMS。
核心原则：感知层只做测量，不做复杂计算；网络层只做定位解算，不处理业务逻辑；应用层只消费位置数据，不干预底层调度。各层职责清晰，系统才扛得住高并发。
我在一个工厂项目里遇到过，有人把业务逻辑写进了基站固件，结果每次升级业务规则都得爬梯子去换基站。后来全拆开了，清爽多了。
4.2 基站与标签角色定义
很多人以为基站和标签只是“固定 vs 移动”的区别。其实没那么简单。角色定义直接影响功耗、成本和定位精度。
4.2.1 基站（Anchor）
基站是坐标已知的固定节点。它的核心任务有两个：一是和标签做测距通信，二是把测距值上报给定位引擎。基站本身不计算位置，只做“测量员”。
| 参数 | 典型值 | 说明 |
|---|---|---|
| 部署高度 | 2.5m - 4m | 避免遮挡，减少多径 |
| 供电方式 | PoE / 24V DC | 不建议用电池，基站必须持续在线 |
| 坐标标定 | 全站仪 / RTK | 误差控制在±2cm以内 |
| 通信接口 | 以太网 / Wi-Fi / 4G | 优先有线，无线需考虑延迟抖动 |
避坑指南：我曾经在一个仓库里把基站装在了金属货架旁边，结果测距值跳得跟心电图似的。后来才意识到，UWB信号对金属反射极其敏感。基站周围1米内尽量保持空旷，远离金属、混凝土柱、大功率电机。
4.2.2 标签（Tag）
标签是移动端，戴在人或设备上。它的核心任务是发UWB脉冲（或响应基站的轮询），然后通过通信链路把测距结果传出去。标签最怕什么？怕没电。
- 主动式标签：自己发脉冲，基站被动接收。功耗高，但刷新率快（10Hz以上）。适合AGV、天车等需要实时追踪的场景。
- 被动式标签：基站发轮询，标签应答。功耗低，电池能用半年到一年。适合人员定位、资产盘点。
- TOF vs TDOA：TOF标签需要和基站双向通信，TDOA标签只需单向发信号。TDOA标签更省电，但需要基站间严格时间同步。
注意：标签的刷新率不是越高越好。我见过有人把标签设到50Hz，结果一个基站只能带20个标签，系统直接瘫痪。一般场景10Hz足够，高动态场景也别超过20Hz。
4.3 定位引擎部署模式
定位引擎是系统的“大脑”。它接收基站的测距数据，解算出标签坐标。部署模式有三种，我按推荐程度排个序。
4.3.1 本地部署（On-Premise）
引擎跑在本地服务器或工控机上。延迟最低（<5ms），数据不出厂区，安全性最高。适合工厂、矿山、监狱等对实时性和数据隐私要求高的场景。
4.3.2 边缘部署（Edge）
引擎跑在基站附近的边缘网关里。适合网络条件差、带宽有限的场景。比如隧道、地下矿井。边缘节点可以缓存数据，网络恢复后再同步到中心。
4.3.3 云端部署（Cloud）
引擎跑在公有云或私有云上。扩展性好，运维方便，但延迟受网络影响大（通常20-100ms）。适合园区管理、人员考勤、资产追踪等对实时性要求不高的场景。
| 部署模式 | 延迟 | 扩展性 | 典型场景 |
|---|---|---|---|
| 本地部署 | <5ms | 中 | 工厂自动化、AGV调度 |
| 边缘部署 | 10-30ms | 高 | 隧道、矿井、移动基站 |
| 云端部署 | 20-100ms | 极高 | 园区管理、资产追踪 |
我的建议：如果预算允许，优先本地+边缘混合部署。核心区域（如产线）用本地引擎，非核心区域（如停车场）用边缘网关。这样既保证了关键业务的实时性，又控制了成本。
4.4 系统拓扑结构
拓扑结构决定了信号怎么走、数据怎么汇聚。我画了一张图，帮你快速理解三种主流拓扑。
4.4.1 星型拓扑
所有基站直连定位引擎。结构简单，延迟最低。缺点是引擎单点故障会影响全局。适合小范围、高实时性场景。
4.4.2 树型拓扑
基站先汇聚到区域网关，网关再连引擎。减少了引擎的端口压力，也方便分段管理。我做过一个汽车工厂项目，分了4个区域，每个区域一个汇聚网关，引擎只和4个网关通信，清爽得很。
4.4.3 网状拓扑
基站之间可以互相通信，数据多跳传输。适合布线困难的场景，比如户外矿区、大型体育场。但延迟会随跳数增加，调试也复杂。嗯，非必要不推荐。
重要提醒：不管用哪种拓扑，基站和引擎之间的网络延迟必须稳定。我曾经遇到一个项目，基站走Wi-Fi连引擎，结果Wi-Fi偶尔抖动200ms，定位数据直接飘了。后来全换成有线，问题解决。UWB对网络抖动的容忍度很低，能上有线就上有线。
4.5 架构设计避坑清单
最后，我把自己踩过的坑整理成一份清单，你设计架构时对着检查一遍。
- 基站数量别抠门：理论上3个基站能定位，但实际至少4-6个。多一个基站，定位盲区就少一块。
- 引擎别和业务系统混装：定位引擎是实时服务，业务系统是事务服务。混在一起，一个出问题两个都崩。
- 预留扩展接口：架构设计时留20%的带宽和算力余量。项目上线后加标签、加基站是常态。
- 时间同步方案要提前定：TDOA方案需要基站间纳秒级同步。是用有线时钟同步还是无线同步？这个决定影响整个网络设计。
- 别忘了冗余：引擎可以双机热备，基站可以N+1备份。关键场景（比如AGV防撞）绝对不能单点。
我的习惯：每次做完架构设计，我都会画一张“数据流图”，从标签发脉冲开始，到应用层显示坐标结束，每一步都标清楚延迟和带宽。画完这张图，架构有没有瓶颈一目了然。你也试试。