人员定位系统技术分享：楼层定位技术及其分支——卫星、蓝牙信标与气压海拔如何协同回答“人在第几层”

一、开篇：平面地图能框住一栋楼，却框不住“第几层”

化工厂的多层框架装置里，一名巡检工在三楼反应釜区失联。控制中心的大屏上，红点稳稳落在建筑轮廓内，却给不出楼层。应急队进场只能逐层搜索，一层层喊、一间间找。这个场景暴露了平面定位的输出边界：经纬度把整栋楼压成一个点，垂直方向的信息被完全抹掉。楼层级定位是人员定位系统里常被低估、却极考验多源协同功底的一环——它不是一个传感器能解决的事，而是一组定位分支技术围绕“垂直维度”的分工与配合。本文把楼层定位拆成一条主干和若干分支，讲清卫星、蓝牙信标、气压海拔各自负责什么，又在哪里让位给彼此。

二、痛点定义：楼层为什么是平面定位的盲区

室外场景下，卫星导航给出的经纬度连续且可用；人一旦进入建筑，信号遮挡让这条链路直接失效。多数室内定位方案把位置投影到一张平面地图上，问题随之而来：所有楼层重叠在同一张图上，三楼的人和五楼的人在图上是同一个点，电子围栏判定分不出垂直方向。

行业内常见的两类补法，都不能连续回答“此刻在第几层”。其一是用楼宇进出记录与楼层停留统计做推断：数据来自门禁与定位记录，能回答“这个人去过哪层、待了多久”，但它是事后统计视图，适合考勤与追溯，用于正在发生的搜救与处置则时延不够。其二是NFC 刷卡点位：人刷过哪台读卡器，位置就停在哪个点，粒度是点、更新靠人走过去刷卡。两类方法的共同短板，是输出的不是实时海拔。楼层判定真正需要的观测对象是高度——而大气压随海拔升高而降低，高度本身是可测量的物理量。这就引出了楼层定位的核心机理，以及支撑它的分支技术体系。

三、核心技术原理：楼层定位是一棵分支技术树，主干是海拔判定

楼层定位的机制可以类比成一摞托盘：每层楼是一个高度区间明确的托盘，知道人所在的高度落在哪个区间，就知道他在哪层。把这套机制落进一个平台，主干是三段式：测高、校准、建模。

测高靠气压。大气压随海拔升高按对数关系下降，终端内置的气压计读出气压即可换算海拔，成本低、无累计误差，是终端测高的主流路线。

校准靠基准站。气压是个易变量，天气过程会让同一地点的气压一天内明显波动，各终端若各自换算，早晚读数对不上。平台因此要求接入基准站——架设在坐标与海拔都已知的固定点上的参考设备。以手持基准站为例，登记时需填写设备编号、架设点的纬度、经度与预估海拔，其中预估海拔用于换算楼层高度。终端勾选「上报海平面基准大气压 P0」后，气压读数统一折算到海平面基准，天气带来的基准漂移被显式消除。

建模靠建筑管理。沿建筑外轮廓依次描点圈定建筑轮廓，按实际层高逐层添加楼层并覆盖全部楼层，系统按层高自动生成各层海拔区间，再填写地平海拔（首层地面海拔）并把地平层指定为首层。此后终端海拔落进哪个区间，三维建筑地图就把它画在哪一层。

围绕这条主干，平台另有四条辅助分支技术，各自填补主干在不同场景下的空缺：

卫星定位（GNSS/北斗）是主干的室外底座。它给基准站和终端提供室外坐标与授时，广域覆盖、室外可用；一旦进入建筑，信号被遮挡，这条链路失效。载波相位差分（RTK）在有服务账号时开启并填写账号与密码，没有则保持关闭，对应的平面精度增益随之缺位，精度量级以厂商资料为准。

蓝牙信标是主干在室内水平维度的延伸。信标以 MAC 地址登记（例如 ff:10:00:1b:9c:f4），终端开启信标扫描后，监控中的定位方式变为信标定位，从而在楼层平面内标出 XY 坐标。它解决的是“楼层内哪个位置”，不解决“在第几层”。

惯性 / 计步是盲区补位分支。在信号遮挡或信标间隙，终端凭三轴传感器推算步数与位移，维持短时间的位置连续性；它依赖标定，且存在累积误差，不能作为独立定位来源，精度与算法以厂商资料为准。

楼宇台账（进出记录、楼层停留统计）是统计型分支。它不输出实时海拔，而是基于门禁、NFC 与信标触发，回答“去过哪层、待了多久”，用作考勤分析与事后追溯。

把气压换算成楼层，细节在“参考”二字。单个终端的气压计读数包含两类变化：一是海拔带来的系统性下降，二是天气过程带来的全局抬升或下沉。若让每个终端独立按气压算海拔，天气项会被当成高度误差，楼层判定随气压系统移动而整体漂移。P0 的做法是让基准站用已知海拔做“标准尺”，终端只报相对基准站的气压差，从而把天气项从两端同时扣除。这也是为什么手册把“勾选上报海平面基准大气压 P0”列为配置前提，而不是可选项。建筑模型则把抽象的海拔变成可读的楼层：系统按每层实际层高生成连续的海拔区间，再把地平层（首层）的地平海拔钉死，之上一层叠一层，终端海拔落进哪个区间就归到哪层；层高这一项因此既是精度来源，也是误差来源。

图1 楼层定位技术体系拓扑：主干为“测高—校准—建模”三段海拔判定，四条辅助分支（卫星定位、蓝牙信标、惯性计步、楼宇台账）在室外、室内水平、盲区、统计四个维度补位，建筑模型输入层高海拔区间，最终在三维建筑地图呈现人员实时楼层归属。

四、方案对比：五种技术路线在楼层定位中的角色对照

把参与楼层定位的五条技术路线放在一起，差别在它们各自承担的“角色”而不只是精度数字。卫星定位负责把人定位到“哪栋楼、室外哪个点”，是楼层判定前的地理锚点；蓝牙信标负责“楼层内哪个位置”，把平面坐标落到 XY；气压海拔（P0）负责“第几层”，是垂直维度上连续可用的观测；惯性计步负责“信号断了之后往哪走”，做短时补位；楼宇台账负责“历史去过哪层”，做离散统计。表1 按角色、输出粒度、部署要点与主要约束四列对照。

需要说明，精度量级不在这张表的承诺范围内：不同厂商、不同布点密度下数值差异很大，本文统一标注以厂商资料为准。工程上更有用的判断是看“它在楼层判定链路里补哪一段”——单一路线都不完整，组合才是常态。图1 已经把这种组合关系画成树状：主干收拢多源观测，分支各管一段。

落到选型，一个实用的做法是先问“楼层判定链路里哪一段会断”。如果现场全是单层厂房或露天作业面，垂直维度本就不需要，平面定位已够；如果是多层框架但只有零星信标、没有基准站与建模，那么你能拿到楼层内 XY，却拿不到“第几层”，此时与其硬上气压方案，不如用楼宇进出记录与楼层停留统计做离散推断。楼层定位的引入门槛，本质上由“基准站能否室外开阔架设”和“建筑层高资料是否齐备”两个硬条件决定，而不是由预算决定。

表1 五种参与楼层定位的技术路线对照：技术分支、在楼层定位中的角色、输出粒度/精度量级、部署要点与主要约束（精度量级以厂商资料为准）。

五、技术细节：工程落地与现场踩坑

平台给定的楼层定位部署流程是五步：添加基准站 → 配置设备参数 → 现场部署验证 → 添加建筑与楼层 → 开启三维显示查看定位。每一步都有可核对的验收点，下面按分支拆解现场容易出问题的地方。

卫星与基准站分支。进入设备的基准站页面，类型按实际机型选择，填写设备编号、纬度、经度与海拔。现场部署验证要求手持基准站安置于室外露天、视野开阔、无遮挡的固定点位——开阔是为了让基准站自身的定位与气压读数有代表性，遮挡会让参照系先失真。开机联网上报后，打开设备首页查看海拔数值：显示为绿色即表示数据上传正常；数值异常则返回配置页核对。

蓝牙信标分支。信标以 MAC 登记后，终端开启扫描即切换为信标定位。这个分支的工程坑在环境：蓝牙使用 2.4GHz 微波，金属会反射信号、人体站在信标与网关之间会吸收约 10dB 以上信号，混凝土承重墙能吃掉 50% 到 70% 的能量，多径叠加让 RSSI 来回跳。工程实测中货架区的信号抖动可达 15dB，导致近距离与远距离测距结果接近、定位引擎失准。应对手段是现场勘测后加密布点、抬高安装位置避开地面铁皮、关键路口用多颗信标交叉覆盖，并以现场标定与滤波抵消人体遮挡；多径严重的拐角可改用 RSSI 指纹库（先采全区域信号特征存成地图再匹配），比纯测距更稳。广播信道上优先选择 37、38、39 避开较拥挤的频段。

气压海拔分支。勾选「上报海平面基准大气压 P0」是这一步的关键开关，没有它，各终端各自换算，天气漂移会让楼层判定整体平移。建筑建模里层高按实测填写并覆盖全部楼层，系统据此自动生成各层海拔区间；地平海拔填首层地面海拔，地平层指定为首层。层高填错是隐性错误：海拔区间整体错位后，每层判定都平移，系统却不会报错，现场表现是“人明明在三楼，地图显示在二楼”，因此建模阶段建议先拿首层实测海拔反推层高，再逐层展开。

建筑建模与设备参数分支。设备参数里 GNSS、RTK、LoRa 均为启停项：RTK 有服务账号时开启并填写账号与密码，可把室外平面精度从米级提升到更高量级（具体数值以厂商资料为准），没有账号则保持关闭，不影响楼层判定；LoRa 则在无公网覆盖的密闭区域承担回传，是否开启取决于现场网络条件。基准站自身也遵循同一套配置逻辑——启用设备、勾选 P0、再按现场条件决定 GNSS/RTK/LoRa 的启停，它既是气压参考尺，也是室外坐标与授时的来源。

惯性 / 计步分支在楼层切换时尤其有用：人走楼梯在楼层间移动的那十几秒，往往既脱离了室外卫星、又没踩到信标热点，气压虽然在变但采样与区间判定有滞后，这时三轴传感器推算的步数与爬升方向能把“正在上楼”这件事先顶上，等进入上一层信标覆盖再回归精确定位。它不能独立定位，却是楼层判定链路里少不了的“过渡档”。这类辅助分支的价值，恰恰在主干（气压）与水平分支（信标）的接缝处。

台账与可视化分支。监控数据基于监控对象（人员），修改绑定的设备后原数据依然保留，未绑定监控对象的设备为库存设备、不记录数据——这意味着人员与终端、基准站的对应关系要在部署前理清。签到点支持地图坐标点、NFC 标签、信标、楼宇（可指定楼层）与电子围栏，其中楼宇可指定楼层，把任务与考勤锚定到具体层。实时状态用四色表示：灰色离线、绿色在线静止、蓝色在线运动、红色有未处理报警。报警均只会在平台显示，设备不会有反应；报警推送顺序为 web → 微信 → 短信 → 邮件（邮箱需客户定制），只要节点上有一种推送成功即停止推送以节省资源。

图2 楼层定位五步部署链路拓扑：从基准站登记、设备参数配置、现场验证到建筑建模与三维显示，底部为平台给定的三项核对清单（基准站是否在线 / 是否勾选「上报海平面基准大气压 P0」/ 「地平海拔」与「地平层」是否填写正确）。

六、技术局限性：楼层维度的能力边界

楼层定位不是万能的，它的能力边界几乎都落在“前提条件”上。基准站掉线或未勾选 P0，三维地图就看不到楼层；建筑模型是硬前提，没有建模的建筑输出不了楼层，改建加层后模型要同步维护，这在多楼栋园区是一笔持续的运维量。同层的中庭、挑空区或复式结构里，层间气压差很小，楼层边界容易误判。蓝牙信标只给水平位置、不解决楼层，纯信标方案仍要气压或台账补楼层；而在多径严重的金属罐区，信标水平精度下降，楼层内 XY 也会漂移。气压本身受天气、温湿度影响，需要基准站持续校准。地下矿井、密闭无 GNSS 的区域里，卫星分支失效，回传要依赖 LoRa 等其他链路（设备参数里保留了 LoRa 启停项）。还要说清一点：楼层定位缩短的是寻找与处置时间，它改变不了事故是否发生，任何把系统能力表述成消除风险的说法都不成立。

运维侧也要算清一笔账：建筑模型不是一次性的，园区每加一层、每改一次用途，模型都要同步更新，否则新区域的楼层归属会沿用旧区间而失真。复式、挑空结构里，同一水平面可能对应两个楼层编号，靠单一气压区间无法区分，需要结合楼层平面与信标做二次判定。这些都说明，楼层定位的能力上限不是传感器精度，而是“模型与现场一致”这件看似平淡的事。

七、结论：给架构师与集成商的一条判断标准

回到开篇场景：红点给不出楼层，搜救就只能逐层扫。楼层定位的价值由此定义——当“此刻在第几层”直接决定处置路径时，它不是显示特性而是响应资源。可落地的判断标准是：先看业务是否存在垂直维度的实时处置需求，再看现场能否满足基准站室外开阔架设与建筑建模两个前提；两者同时成立才引入楼层维度，否则用楼宇进出记录与楼层停留统计做事后推断已是成本更低的答案。具体到选型，记住一句话：卫星负责把你带到楼前，蓝牙信标负责在楼层平面内标出位置，气压（P0）负责回答“第几层”，惯性计步与楼宇台账负责补位与追溯——组合使用，各取所长。基准站接入方式、精度量级与各配置项取值，以厂商资料为准。