楼层定位的工程骨架架端边云协同与回传网络怎么选

封面图

楼层定位的工程骨架：端边云协同与回传网络怎么选

某化工园区一次例行巡检，运维人员在地下管廊失联 11 分钟。事后复盘，定位终端其实一直在采样，问题出在回传：基站到机房的网线被施工挖断，边缘节点没做本地缓存，这 11 分钟的数据全丢了。楼层定位圈子里，大家聊得最多的是"用什么技术判楼层"，可真正决定系统能不能跑稳的，往往是端、边、云怎么分工，数据怎么回传。这篇文章就拆这件事。

问题定义：楼层定位难的不是算，是送

GNSS 在楼里基本失效，这一点工程上早有共识。进了楼，定位改成蓝牙信标、UWB、气压这类手段，但它们只解决"算得准"的问题，没解决"算完往哪送、谁来算、链路断了怎么办"。一套楼层定位系统的数据流是这样走的：定位终端（工牌、手环、胸卡）采集 RSSI、气压、IMU 甚至原始测距值，就近被基站或网关接收，向上汇聚，最后到平台做融合、存轨迹、画围栏、推报警。每一跳的分工不清，系统就会在三个地方翻车：时延飘、容量顶不住、断网即失明。

很多项目验收时一切正常，一投产就出问题，根因常常不在算法，而在链路。比如终端采样率是 1Hz，但网关到云之间用的是普通宽带，晚高峰一拥塞，轨迹就开始"跳帧"；再比如边缘不做缓存，一根光纤被挖断，这一片楼的人集体"消失"。这些都不是定位精度问题，是工程骨架问题。

技术原理：端、边、云是三个干不同活的人

把端边云想成三个干不同活的岗位。终端是采集员，负责把原始无线信号变成可传输的样本，它离人最近，也最受限——电池、体积、成本都卡在它身上。边缘是车间组长，在离终端一两跳的地方做滤波、去重、补点，把乱糟糟的样本整理成干净的定位候选，顺便把断网时的数据先存住。云端是总部，把多个边缘的结果做多源融合，落地成"某人在某楼某区"，再驱动围栏、报警、考勤这些业务。

一个类比：终端像前线的哨兵，边缘像连队的副官，云像战区指挥部。哨兵不必懂全局，副官不必存全部历史，指挥部不必处理每一发子弹的轨迹。各管一段，链路才不堵。反过来，如果让哨兵直接给指挥部打电话报每一发子弹，通信立刻炸；如果让指挥部去数每一发子弹，算力立刻爆。楼层定位系统的设计，本质就是在这三者的权责边界上反复找平衡。

举个时延账。终端在 3 楼触发报警，事件要经网关上行、云端解算、再下发到监控端，这一圈在理想网络下也要几十到几百毫秒；若走公网且晚高峰拥塞，可能涨到秒级甚至更久。对"人掉进管廊"这类场景，这几秒的差异就是能不能及时响应的差别。把算力往边缘挪一层，等于把这段上行延迟砍掉大半。所以时延预算不是纸面指标，它直接挂钩业务能不能用，这也是端边云分工最实在的考量。

原理链路见配图：终端采样 → 边缘网关（滤波、去重、本地缓存）→ 云端融合引擎 → 业务应用（实时定位、轨迹、围栏、报警）。

图1：楼层定位端边云协同链路拓扑。终端就近接入边缘网关，边缘完成滤波与本地缓存后上送云端融合，业务应用层消费最终定位结果。

方案对比：算力放哪，各有各的代价

端边云三种算力摆放，对应完全不同的工程取舍。下面这张表把三条路线放在一起看。

表1：端边云三种算力摆放路线对比（均为工程量级描述，具体数值以厂商资料为准）

这张表里的时延和成本都是"量级"描述，不是精确值。实际工程里，蓝牙信标单点定位常见精度在米级，具体取决于布设密度与环境；回传周期、网关带机量这些硬指标，以厂商资料为准，不要拿纸面参数直接下单。

技术细节：真正坑人的几个点

边缘节点必须做本地缓存与断点续传。开篇那个 11 分钟失联，根因就是边缘没有"先存后传"。楼层里施工多、线路老化快，链路抖动是常态不是例外。经验做法：边缘网关在本地保留至少一圈滚动缓存，网络恢复后按时间戳补齐，平台侧做去重。这样即使断了十几分钟，恢复后数据能接上，轨迹不断裂。

采样率与回传频次要解耦。终端可以 1Hz 采样，但不必 1Hz 上送。只在状态变化（开始移动、进入新楼层、触发报警）或定时窗口回传，既省电又省带宽。具体回传周期与唤醒策略以厂商资料为准，这里只讲原则：采样密、回传疏，是低功耗定位的通用解法。

网关供电与回传一体两面。PoE 部署省一根线，供电和回传走同一根网线，适合新楼和大改。但大量老楼改造只能走无线回传（4G、5G、NB-IoT 或 LoRa），这时得权衡带宽与资费：NB-IoT 资费低但带宽小，只够稀疏回传；4G/5G 带宽足但成本和功耗都上来。选哪条，看的是楼层里要传什么——纯定位坐标和稀疏轨迹，窄带就够了；要传语音调度或高频轨迹，得上宽带。

跨网关切换是楼层定位的隐形坑。人在楼里走，终端会在不同楼层的网关之间移交。如果边缘对"终端当前归属网关"管理不好，就会出现定位跳变、轨迹回退。做法是在边缘层维护一张终端-网关归属表，切换时做平滑过渡，把"上一网关的最后位置"作为新网关的初始先验。这步做不好，再准的无线电也会画出鬼画符。

监控中心的状态呈现，本质就是端边云把三件事翻译成颜色。主流工业外勤平台的监控中心用四色区分状态：灰色表示离线、绿色表示在线静止、蓝色表示在线运动、红色表示有未处理报警。这套颜色背后，是终端报"我还活着"、边缘判"他在动没"、云端汇"他出事没"的协同结果。读懂这四色，基本就读懂了链路健康度。

时间同步容易被忽略。多网关做 TDoA 或做轨迹拼接时，各节点的时钟要对齐，否则时间戳错位会让位置算出偏差甚至错层。边缘网关一般靠 NTP 或北斗授时对齐，跨厂商设备更要先确认同步机制一致，别等验收时轨迹对不上才返工。

带宽怎么估，给个可套的算法。单终端日均流量约等于"采样点数 × 单点包大小 × 回传倍率"，回传倍率通常小于 1，因为采样密、回传疏。以某工业园区为例，两千个终端按每分钟一次稀疏回传，单终端日均流量约几十 KB，总上行不过百 MB/日，一根企业宽带就能扛；一旦开启语音调度，单终端峰值可能爬到几十 kbps，总带宽要按"终端数 × 峰值"重新算，不能再拿统计均值糊弄。具体单终端流量以厂商资料为准，但估算框架是通用的：先定回传频率，再乘终端数，最后乘单包体积，得到的才是真实带宽需求，而不是拍脑袋说"物联网流量小"。

回传网络的隔离也值得补一句。定位数据最好走独立 VLAN 或专网，和生产网、办公网分开。这样做既保住了定位自己的带宽，也不至于别的网络出事时把定位系统一起拖下水。属于网络工程里的常规操作，但不少项目偷懒共用一根宽带，投产后的跨网故障最难查。

落地清单：照着这张表做端边云选型

把前面散落的点收成一张可执行清单，照着走能少踩大部分坑。

先定时延预算。问清楚业务对"人在哪"的容忍延迟：巡检类秒级即可，语音调度类可能要求亚秒。时延要求直接决定算力能不能放心放云端。

再定网络可靠性。楼里有没有现成有线回传、有没有不间断电源、无线信号覆盖如何。可靠性低于某个阈值，边缘本地缓存就不是可选项，而是必选项。

然后反推算力落点。终端极简加云端集中适合小场景；多楼层统一管控上边缘网关；时延极敏感又网络不稳，才考虑终端侧解算。别一上来就追最重的方案。

接着算回传带宽。单个终端稀疏回传，窄带物联链路就够；要传语音或高频轨迹，就得上宽带。按"终端数 × 单终端日均流量"估总带宽并留余量，具体单终端流量以厂商资料为准。

最后规划运维面。边缘节点数等于网关数加其上行链路数，每一个都要管供电、固件、时钟。小项目把节点压到最少，大项目再按区域铺开。

这套清单里没有"最先进"，只有"最匹配"。我见过不少项目，无线电选了最贵的，链路却用一根普通宽带裸奔，结果精度再高也救不了断网即失明的尴尬。

局限与边界：不是越分散越好

端边云不是越往终端推越好。终端侧算受功耗与体积死死压着，复杂的多源融合、地图匹配根本放不进去；纯云端又扛不住万级终端的实时回传，一拥塞就全线飘。真正的折中点在边缘：滤波、去重、补点放网关，融合与业务放云端。这套分工在园区和厂区最稳。

另一个边界是运维面。边缘节点越多，要管的固件、时钟、供电、上行链路就越多。小项目上全套边缘，光运维就亏了。一两层楼、几十个人的场景，终端极简 + 云端集中反而最划算。别被"边缘计算"几个字绑架，按规模选型。

结论

楼层定位的难点，一半在算得准，另一半在送得稳、断得了、恢复得快。给架构师一个判断标准：先定你的时延预算和网络可靠性，再反推算力该放终端、边缘还是云。别一上来就追最准的无线电，链路塌了，再准也是瞎的。

一句话收束：选楼层定位方案，先把端边云这三层的账算清，无线电技术反而是后面才该纠结的事。