工业物联网中”六遥”概念解析
面向嵌入式 / 边缘计算 / 物联网工程场景的工程化理解，不堆学术八股，只说用得上的。
一、为什么要在意这几个”遥”
做物联网项目——尤其是工控、电力、车载这类场景——通信链路上跑的从来不只是”数据”两个字能概括的。同样是串口 / MQTT / Modbus 上的一帧报文，它的语义可能天差地别：
- 这一帧是传感器采集回来的模拟量？
- 还是下发给设备的启停指令？
- 还是断路器跳了之后自动上报的告警信号？
电力系统和工业自动化领域用六个”遥”来区分这些语义。理解它们，本质上是在理解**「链路上每一帧到底在干什么」**。这对于设计通信协议帧结构、划分数据通道、制定异常处理策略，都是绕不开的基本功。
二、一张表先看清
| 概念 | 英文 | 方向 | 数据特征 | 典型载体 | 一句话 |
|---|---|---|---|---|---|
| 遥测 | Telemetry (YC) | 终端 → 上位机 | 连续模拟量 | 传感器、PLC、电表 | “你现在多少度？” |
| 遥信 | Teleindication (YX) | 终端 → 上位机 | 离散状态 / 事件 | 开关量、继电器、断路器 | “我跳闸了！” |
| 遥控 | Remote Control (YK) | 上位机 → 终端 | 离散指令 | 继电器输出、GPIO | “启动 / 停机” |
| 遥调 | Remote Regulation (YT) | 上位机 → 终端 | 连续调节量 | 变频器、阀门定位器 | “转速调到 1200rpm” |
| 遥感 | Remote Sensing (YG) | 非接触探测 | 光谱 / 电磁波数据 | 摄像头、激光雷达、多光谱 | “不去碰它，但全看见了” |
| 遥视 | Remote Vision | 终端 → 上位机 | 视频流 | IP 摄像头、RTSP/RTMP | “千里眼看现场” |
遥测(Telemetry)在本语境下强调 SCADA/自动化领域的测量值采集，不直接等同于航天领域广义的”遥测”。后者涵盖更宽，但工程落地时核心区分方式是一样的。
三、逐个拆，用捡球车说话
3.1 遥测（采集量上报）
遥测是最高频的数据流向。终端设备持续采集模拟量——温度、电压、电流、转速、位置——然后打包上报。
在我之前做过的智能捡球车项目里，典型的遥测数据包括：
- 电机实时反馈：
vel_estimate（转速）、iq_measured（电流） - 电池管理系统：单体电压、总压、SOC、温度
- GPS / IMU：经纬度、航向角、加速度
- 超声波 / 红外避障传感器距离值
这些数据的特点是周期性上报（比如 50ms 一帧），数值连续变化，对时效性和丢包都比较敏感。传丢了可以用插值兜底，但不能一直丢。
在协议设计上，遥测帧通常会带时间戳和序列号，方便做断线补发和轨迹回放。
3.2 遥信（状态 / 事件主动上报）
遥信用来描述设备的离散状态变化或故障事件。它不是周期性的，而是事件驱动的——变了才报。
关键特征：
- 离散：只有有限的几个状态（正常/故障、开/关、运行/停机）
- 事件驱动：不是定时轮询，是状态翻转时立即上报
- 优先级高：一条”电池过温”的遥信，比一百条正常的温度遥测更重要
捡球车场景举例：
- 急停按钮被拍下（硬件信号，0 → 1）
- 电机驱动器报
ERROR_DC_BUS_OVER_VOLTAGE - 电池 BMS 触发过放保护
- 通信链路看门狗超时，触发链路中断告警
工程上通常给遥信加上变化上报（COS, Change of State）+ 周期全量复检双重机制，防止漏报。MQTT QoS 1 + Retained Message 天然适合干这个。
3.3 遥控（离散指令下发）
遥控是上位机到终端的离散控制指令，典型的二值——开/关、启/停、分/合。
核心要求是安全。误触一次”急停解除”，现场可能出事故。所以工程上常见的加固手段：
- 选择-确认-执行三步走：先选目标设备 → 回路校验通过 → 才真正执行
- 超时自动复归：指令发出后在规定时间内未收到执行回执，自动撤销
- 闭锁逻辑：比如”电机正转”和”电机反转”不能同时为真，硬件或软件层面做互锁
捡球车里遥控指令典型如：
- 整车上电 / 下电
- ODrive 进入
CLOSED_LOOP_CONTROL/ 回到IDLE - 切换工作模式：手动遥控 → 自动驾驶 → 跟随模式
在 CCESP32 项目里，这些遥控指令就是通过 UART 发到 ODrive 的 ASCII 协议命令（如 v 0 1000 200），配合 WiFi 手柄做了二次映射。
3.4 遥调（连续参数下发）
遥调和遥控都是”上到下”，但调的是连续量而不是开关量——不是”开不开”，而是”开到多少”。
本质区别：
| 遥控 | 遥调 | |
|---|---|---|
| 值域 | 离散（0/1） | 连续（一个区间） |
| 反馈 | 回执确认即可 | 需要回读实际值做闭环 |
| 安全性 | 防误触 | 防越界 |
捡球车里：
- 巡航目标速度设定：下发
traj_vel_limit的值 - 舵机转向角度
实现上，遥调指令下发后必须回读实际值做二次确认。比如设了目标转速 1000rpm，得等电机的 vel_estimate 反馈回来确认真的达到了，才算闭环。
3.5 遥感（非接触感知）
遥感在工业物联网语境下，更多指非接触式传感器获取环境信息，而不是卫星对地观测。共性是”不接触被测量对象”。
捡球车上的遥感应用：
- YOLO 目标检测：通过摄像头识别高尔夫球，典型非接触视觉感知
- 超声波 / ToF 测距：发射波束，接收回波，不接触障碍物
- 红外热成像：远距离检测人体或热源
这些传感器的数据量和传统遥测完全不在一个量级——一张 VGA 图像 ≈ 300KB，一路串口遥测帧可能才几十字节。所以在通信架构上，遥感数据往往走独立的高带宽通道（如 Ethernet / WiFi 图传），不和遥测遥信混在一条低速工业总线上。
3.6 遥视（远程实时视频监控）
遥视可以理解为遥感的一个子集，专指视频流的远程实时传输和观看。
和遥感的区别在于：遥感强调的是”用传感器获取信息”这个感知动作，遥视强调的是”人在远端看到画面”这个使用场景。
实现上无非就是：IP 摄像头 → RTSP/RTMP 推流 → 远端播放器拉流。捡球车如果后续加入全景监控/远程驾驶，就会用上。
四、通信协议层面的落地映射
不同协议对”六遥”的支持方式不同，选型和帧设计时要心中有数：
| 协议 / 总线 | 遥测 & 遥信（上行） | 遥控 & 遥调（下行） | 遥感 & 遥视 |
|---|---|---|---|
| Modbus RTU | 03/04 功能码读保持/输入寄存器（遥测），01/02 功能码读线圈/离散输入（遥信） | 05/06/0F/10 功能码写线圈/寄存器 | 不适合（带宽太低） |
| MQTT | publish 到 device/+/telemetry，JSON payload 带时间戳 | subscribe device/+/command，收到后执行 + 回执 | 不直接承载视频流，元数据可走 MQTT |
| TCP 自定义帧 | 定义帧类型字节 0x01=遥测 0x02=遥信 | 0x03=遥控 0x04=遥调 | 可用但视频建议走专用通道 |
| OPC UA | 原生支持订阅 + 历史数据 | 原生支持 Method Call | 可通过配套协议 |
实际项目中常采用控制面 + 数据面分离架构：遥测/遥信/遥控/遥调走 Modbus 或 MQTT（控制面），遥感/遥视走单独的以太网 / WiFi 链路（数据面）。
五、实践建议
- 帧设计时把”遥类型”编码进去。每个数据帧的开头放一个字节标识它是遥测/遥信/遥控/遥调，接收端解析逻辑直接分叉，不会把告警当温湿度处理。
- 遥信一定要做 COS + 周期复检。别只依赖变化上报——通信可能刚好在状态翻转的瞬间中断，导致上位机永远不知道设备已经变了状态。
- 遥控加安全锁。哪怕只是一个简单的 GPIO 翻转，也至少走”下发 → 终端校验 → 回执确认”，不要直接无脑执行。急停相关的指令必须走硬件直连 + 软件互锁双保险。
- 遥调要有闭环反馈超时机制。设定值下发后如果收不到实际值回读确认，要么重发、要么告警、要么降级——不能假装调成功了。
- 大带宽数据别和小带宽数据挤一条线。遥感 / 遥视的流量能把 Modbus RTU 这种 9600bps 的线路直接打瘫。物理通道要分开，逻辑上通过关联 ID 做数据融合即可。
参考
- 工业自动化领域 SCADA 系统”四遥”（遥测、遥信、遥控、遥调）基本概念
- IEC 60870-5（电力系统远动协议）、IEC 61850（变电站通信网络与系统）
- Modbus 协议规范（Modbus Organization）
- MQTT 3.1.1 / 5.0 Specification（OASIS）
写于 2026-07-03，结合捡球车 / CCESP32 实际通信架构经验整理。后续有新体会再迭代。
