电梯物联网数据架构：城市级垂直交通监控的技术实践
电梯运行数据的采集维度
电梯物联网的数据采集深度取决于控制柜的开放程度和传感器的加装方案。一台配置完整监控方案的电梯，采集参数涵盖以下维度。
运动学参数：轿厢位置（楼层）、运行速度、加速度、运行方向、平层精度。这些参数通过控制总线（CAN/RS-485）从主控板读取，采样频率在运行期间10-100ms，停站期间1秒。加速度数据是困人检测的核心依据——正常减速过程的减速度在0.5-1.2m/s²之间，急停或异常减速可能超过2m/s²。
门系统参数：门开关状态、开关门时间、门电机电流、门光幕状态。门系统是电梯故障率最高的子系统，开关门时间的趋势变化（从正常的3秒延长到5秒）是门系统老化的早期信号。门电机电流的波形特征可用于门轨卡阻和门刀磨损的诊断。
振动与噪声参数：轿厢顶部和导轨的加速度传感器采集振动数据，频率范围0.1-1000Hz。振动数据采样频率在1-10kHz，是所有电梯参数中数据量最大的。正常运行电梯的振动RMS值通常在0.05-0.15g之间，超过0.3g可能预示导轨磨损或平衡异常。
控制柜参数：主回路电压/电流、变频器温度、制动器状态、UPS电池电量。采样频率秒级，数据量小但安全相关性强。
数据类型 | 参数数量 | 采样频率 | 传输方式 | 日数据量/台 | 核心用途 |
运动学参数 | 5-8 | 10-100ms | CAN总线 | 50-200MB | 困人检测、平层精度 |
门系统参数 | 6-10 | 100ms-1s | CAN总线 | 10-50MB | 门系统健康评估 |
振动噪声 | 3-6 | 1-10kHz | 独立传感器 | 500MB-2GB | 导轨磨损、平衡诊断 |
控制柜参数 | 8-12 | 1s | CAN总线 | 5-20MB | 电气安全监测 |
周期性状态 | 15-30 | 60s-5min | 4G/NB-IoT | <1MB | 统计汇总、OEE |
振动数据的数据量与传输成本之间的矛盾是电梯物联网的核心工程挑战。1kHz采样频率下，单台电梯日均振动数据500MB以上，通过4G/NB-IoT传输不现实。实际方案是边缘计算——在电梯控制柜侧加装数据采集网关，本地完成FFT变换和特征值提取（RMS、峰值、峭度），仅将特征值上报到云端，数据量降低到原始数据的千分之一以下。
传输模式：低带宽下的混合写入策略
城市级电梯物联网的数据传输依赖4G或NB-IoT网络。NB-IoT的上行带宽约20-60kbps，延迟1-10秒，适合低频小数据量传输。4G网络上行带宽1-10Mbps，延迟100-500ms，适合中频数据传输。多数电梯监控方案采用NB-IoT传输周期性状态数据、4G传输事件数据的混合模式。
数据传输模式因此呈现事件驱动+周期性混合的特征。正常运行状态下，电梯每1-5分钟上报一次状态摘要数据（当前楼层、门状态、运行方向、累计运行次数），数据量小（<1KB），通过NB-IoT传输。当发生特定事件——困人检测（加速度异常）、急停（速度骤降）、门系统异常（开关门超时）、故障码产生——立即触发事件数据上报，包含事件前后各30秒的高频运动学和门系统数据，数据量50-200KB，通过4G传输。
这种混合写入模式对存储引擎提出特殊要求。周期性低频数据按固定间隔写入，写入速率可预测且平滑。事件驱动高频数据在事件发生时产生写入峰值，可能在短时间内集中写入多条记录。时序数据库需要同时适配平稳写入和突发写入，且突发写入不应对周期性写入产生背压。
困人检测：从加速度数据到事件判定
困人检测是电梯物联网安全等级最高的功能。检测逻辑依赖轿厢加速度数据的实时分析。
困人检测判定链路:
加速度采集(10ms) → 滑动窗口计算(1s) → 速度估计 → 停止判定
→ 门状态检查(60s未开门) → 困人告警正常停站过程中，电梯减速至零速后2-5秒开门。如果速度归零后60秒内门未打开，判定为困人事件。检测延迟约60秒。更短的延迟需要依赖加速度模式的异常检测——急停过程中减速度超过正常范围，且后续无门系统响应，可在10-15秒内预判困人风险。
困人事件的误报代价不低。每次困人告警触发救援调度，人工到场成本高。误报率应控制在5%以下。降低误报的技术路径是引入更多上下文信息——门电机电流是否归零、控制柜是否有故障码、轿厢内对讲是否响应。这些信息需要通过跨数据源的关联查询获取，对存储引擎的标签过滤和多表JOIN能力有要求。
门系统健康评估与预测性维护
门系统的预测性维护是电梯物联网的商业价值场景。电梯门系统的故障占电梯总故障的40%-60%，门系统故障导致的服务中断是用户投诉的主要来源。
预测性维护的数据基础是开关门时间的长期趋势数据。正常新电梯的开关门时间在3-4秒之间。随着门轨磨损、门刀间隙变化、门电机老化，开关门时间逐渐延长。当延长超过正常值的150%（5-6秒），发生卡阻故障的概率显著上升。
趋势分析的数据需求：每台电梯每天开关门约200-500次，每次记录开关门时间，日均200-500条数据。一座城市10万台电梯，日均数据量2000-5000万条。查询模式是：按电梯ID分组，取最近90天的开关门时间序列，计算线性回归斜率。斜率超过阈值（如每周增加0.1秒）的电梯进入维护预警队列。
这一查询如果通过原始数据扫描实现，需要扫描90天×400条/天=3.6万条数据×10万台=36亿条记录。时序数据库的连续查询功能在写入时做日聚合（每天计算平均开关门时间并写入聚合表），趋势分析只需扫描聚合表的90条/台×10万台=900万条记录，查询效率提升400倍。
城市级规模的部署架构
城市级电梯物联网的规模差异显著。一线城市在用电梯数量30-50万台，中等城市5-15万台，县级市5000-2万台。不同规模的部署架构差异较大。
中小规模（5万台以下）可采用单集群部署。TDengine集群部署3-5个Vnode节点，写入吞吐和查询并发均可满足。标签模型适配多楼宇多电梯：设计"电梯运行数据"超级表，标签包括城市区域、楼宇ID、电梯ID、品牌型号、安装年份。楼宇ID基数在城市范围内可达数万，但每个楼宇ID对应的子表数有限（1-10台电梯），标签索引效率可控。
大规模（10万台以上）需要考虑数据分片和地域分区。按城市区域分片，每个区域部署独立的Vnode组，减少跨区域查询的网络延迟。困人告警的实时性要求决定了写入和告警判定需要在同区域完成，跨区域同步引入不可接受的延迟。
低带宽适配方面，NB-IoT网络下电梯控制器的数据上报存在丢包和延迟。存储引擎需要支持数据按自带时间戳写入而非服务端接收时间写入。时间戳偏差在10秒以内不影响趋势分析准确性。NB-IoT的功耗约束要求上报频率不能过高——对于电池供电的NB-IoT终端，1-5分钟的上报间隔是功耗与实时性的平衡点，5分钟上报间隔下终端电池寿命可达3-5年。
结语
电梯物联网正在从"故障后报警"向"故障前预警"转型。这一转型的技术基础是运行数据的长期连续存储和趋势分析能力。困人检测的实时性要求、门系统趋势分析的数据跨度要求、城市级部署的规模要求，三者叠加形成时序数据库存储架构的多维约束。边缘计算与云端存储的协同——特征值在电梯侧提取、原始数据按需上传——是缓解低带宽约束与高频数据需求矛盾的关键架构决策。
