RTU

• 状态：idea
• 提出人：待确认
• 参与人：王小杰、刘力夫
• 创建日期：2026-08-14
• 最近更新：2026-08-14

一句话说明

调研并规划一款 RTU 设备，具体应用场景、通信接口与采集控制能力待确认。

背景与问题

用户提出 RTU 创意并提供了三个淘宝/天猫参考商品。三个商品页已通过 Edge CDP 完成截图和基础信息采集；目标应用场景、目标用户和需要解决的问题待确认。

RTU 的接口、协议和联网选项组合非常多。如果不先限定现场对象和数据闭环，容易做成“功能齐全但没有明确购买理由”的通用工控盒。

目标用户与使用场景

优先从以下候选场景中选择一个作为首版，不预设全部覆盖：

• 分散设备远程运维：采集水泵、机房、农业或环保设备状态并远程控制。
• 老设备联网改造：把 Modbus RTU、开关量或模拟量转换为 MQTT/HTTP 等上行数据。
• 小型无人站点：本地规则控制、断网缓存，恢复联网后补传数据。

潜在购买者可能是设备厂商、系统集成商或最终运维单位。三者对二次开发、部署工具和售后责任的要求不同，需要分别访谈。

核心设想

• 围绕 RTU 设备开展产品方案调研。
• 具体采集控制能力、通信接口、通信协议、联网方式和供电方式待确认。
• 以用户提供的三个商品作为首批参考案例，先形成可比信息，再确定产品定位。

典型数据闭环

1. 现场传感器或设备通过 DI、AI、RS485/RS232 接入 RTU。
2. RTU 进行采集、量程转换、阈值判断和本地缓存。
3. 数据经以太网、4G、Wi-Fi 或 LoRa 中的一种主链路上报。
4. 云端或本地平台下发参数和控制命令，RTU 校验权限与现场安全条件后执行。
5. 断网、掉电或从站异常时记录诊断信息，链路恢复后按策略补传。

首版范围

建议优先验证的最小闭环

• 1 路 RS485，支持 Modbus RTU 主站采集。
• 一组 DI、AI、继电器 DO，具体数量与电气规格待场景确认。
• 以太网或 4G 二选一作为首个上行链路，支持 MQTT 或 HTTP 中的一种。
• 本地配置、设备身份、断网缓存、远程参数更新和基础运行日志。
• 看门狗、掉电重启、输出安全默认态和通信失败降级。

暂不纳入首版

• 同时集齐 4G、LoRa、以太网、Wi-Fi、蓝牙和所有串口组合。
• 通用 PLC 编程环境、复杂图形化组态和任意脚本开放执行。
• 未经目标场景验证的高精度采集、行业认证和全协议网关能力。

首轮验证指标

差异化与商业假设

• 参考产品已覆盖低价、多接口和 Python 可编程，自研若只复制硬件配置，很难建立优势。
• 可验证的切入点包括：针对一个垂直场景预置数据模型与规则、部署极简、断网数据可靠、远程诊断清晰。
• 商业形态可能是硬件一次性销售、硬件加设备管理服务，或面向集成商的可定制平台；在明确首要购买者前不确定收费方式。

讨论记录

2026-08-14

• 参与人：待确认
• 结论：建立 RTU 创意并收录三个参考商品；已采集商品标题、店铺、页面价格、所选规格和主要参数，具体应用场景和目标规格待确认。
• 补充：本轮把候选场景、最小数据闭环、首版范围和验证指标拆开记录；尚未选定垂直场景，创意状态保持 idea。

验证方式

• 已通过 Edge CDP 核对三个参考商品的基础页面信息并形成对比摘要。
• 待确认：目标场景、核心功能和原型验证方法。

风险与待确认问题

• 首要行业、被采集设备、安装环境和必须解决的业务问题：待确认。
• AI/DI/DO 的数量、量程、精度、隔离和保护等级：待确认。
• 本地协议角色、点位规模、轮询周期与上行数据模型：待确认。
• 是否允许远程控制，若允许，需要确认鉴权、审计、互锁和失联策略。
• 蜂窝通信资费、平台运维、现场安装和售后可能比硬件成本更影响商业可行性。

阶段里程碑

1. 场景访谈：选定一个垂直场景和一个明确购买者。
2. 规格冻结：确定 I/O、协议、联网、供电和环境边界。
3. 台架原型：完成采集、上报、控制、断网缓存和异常恢复闭环。
4. 现场试点：部署 1 至 3 个站点，连续运行并统计运维成本。

下一步

• 采集三个参考商品的截图、标题、店铺、页面价格与所选规格。
• 继续核对型号、接口、通信制式、供电与环境参数，确定目标规格。
• 从候选场景中选择一个，访谈至少 3 名设备厂商、集成商或运维人员。
• 画出首版现场设备到云端的数据点表、控制链路和断网策略。

相关资料

• 参考产品