摩尔信使MThings新功能:水电不分家、一键设备扫描

随着智能水表、智能电表以及综合能源计量设备越来越普及,现场设备的协议种类也越来越多。

一个项目里,可能既有DL/T 645电表 ,也有采用DL/T 698.45 的新型电能计量设备;到了水务、供热等场景,又会遇到CJ/T 188。如果每接入一种设备,都需要寻找不同的调试工具、开发不同的采集程序,无疑会增加设备厂家和系统集成商的工作量。

近期,摩尔信使 MThings V0877版本再次扩展仪表协议能力,新增:

  • CJ/T 188-2018
  • DL/T 698.45
  • DL/T 645-2007

同时,我们还对设备扫描历史数据导出两项实用功能进行了升级。

从设备接入、现场调试,到数据采集、历史存储和数据导出,MThings正在进一步完善面向智能仪表与能源计量场景的一站式解决方案。


📌水电不分家:三大仪表协议集中支持

此次更新的一个重点,就是进一步完善MThings在水、电等智能计量设备领域的协议覆盖能力。

1. CJ/T 188-2018

新增CJ/T 188-2018《户用计量仪表数据传输技术条件》支持。

CJ/T 188面向户用计量仪表的数据传输,适用于仪表主站与从站之间的数据交换,可用于水、气、热等户用计量场景。

通过MThings,可以更加方便地完成相关仪表的通信配置、数据采集与现场调试,为水表等计量设备厂家提供轻量化的上位机方案。

2. DL/T 645-2007

新增DL/T 645-2007多功能电能表通信协议支持。

作为电能表领域应用广泛的通信协议,DL/T 645-2007在智能电表、计量仪表、能源管理以及现场抄表等场景中拥有大量实际设备。

MThings将DL/T 645的设备通信、数据配置、实时采集、历史记录等能力整合到统一的软件框架中。

对于电表厂家而言,不再需要为基本的数据读取和展示单独开发一套上位机;对于系统集成商而言,也可以直接将DL/T 645电表与原有Modbus等工业设备放在同一个项目中管理。

3. DL/T 698.45

在DL/T 645的基础上,本次升级进一步新增DL/T 698.45面向对象的数据交换协议支持。

DL/T 698.45适用于用电信息采集系统主站、采集终端、电能表之间的通信数据交换,其协议体系采用面向对象的数据交换方式。

相比传统的固定数据标识读取方式,DL/T 698.45的数据模型和交互机制更加丰富,也对上位机的数据模型适配能力提出了更高要求。

随着此次协议扩展,MThings 对电力计量设备的支持也从DL/T 645 进一步延伸到了DL/T 698.45


📌从"工业设备"走向"综合计量设备"

过去大家提到工业上位机,首先想到的往往是:

PLC、Modbus、串口设备、传感器......

但在实际项目中,设备之间的边界正在逐渐模糊。

一个能源管理项目可能同时需要采集:

电表 + 水表 + 温控设备 + PLC + Modbus 传感器 + 其他串口设备。

事实上,在综合能源、多表合一等应用中,CJ/T 188、DL/T 645和DL/T 698.45本身就可能同时出现。相关综合能源多表合一标准文件也同时引用了这三类协议。

仪表与工控设备也不应该分家。

无论是智能水表、智能电表,还是传统Modbus传感器、PLC,都可以逐步纳入MThings统一的数据采集体系。

对于设备厂家,可以快速构建自己的专用上位机;对于系统集成商,则可以减少不同协议、不同软件之间来回切换的工作量。


📌新增全协议设备扫描

协议支持只是第一步。真正到了现场,经常遇到的问题反而是:

"设备接上了,但地址是多少?"

尤其是在设备调试、批量接入或者接手已有项目时,设备通信地址不明确,会给现场人员增加不少工作量。

因此,此次 MThings 同步升级了 设备扫描功能

设备扫描不再局限于个别协议,而是进一步向全传输协议设备扫描扩展:MODBUS、S7、DL/T 645-2007、DL/T 698.45、CJ/T 188-2018

通过设定通信参数和扫描范围,MThings可以按照协议规则自动尝试与设备通信,根据设备响应识别在线设备。

对于现场工程师来说,整个过程可以更加直接:

连接设备 → 选择协议 → 设置扫描范围 → 开始扫描 → 发现在线设备

省去了手工逐个修改地址、发送测试报文、等待响应的重复操作。

尤其是在RS-485总线挂接多台仪表的情况下,这项功能能够显著提升前期设备排查和调试效率。

先扫描,再配置,再采集。

让设备接入这件事变得更简单。


📌历史数据导出升级

除了协议和设备调试能力,本次版本还针对实际项目中使用频率非常高的历史数据导出进行了优化。

过去导出历史数据时,一个常见的问题是:

我明明只需要其中几个数据,为什么要把几十个数据项全部导出来?

设备的数据点越来越多以后,这个问题会更加明显。

例如一台电表可能配置:

  • A/B/C 相电压

  • A/B/C 相电流

  • 有功功率

  • 无功功率

  • 功率因数

  • 频率

  • 正向有功电能

  • 反向有功电能

  • 多费率电能

  • 其他运行参数

但用户做一次数据分析,也许只需要:

时间 + A 相电压 + 总有功功率 + 正向有功电能

此次 MThings 对历史数据导出功能进行了优化,新增:

按数据项自由选择导出

用户可以根据实际需要,自由选择本次需要导出的数据项。

需要什么,就导出什么。

这样既可以减少无关数据,也可以让导出的数据表更加清晰,更方便后续使用Excel、MATLAB或其他数据分析软件进行处理。

对于长期运行、数据点较多的项目,这项优化尤其有价值。


📌从"协议调试"到"长期运行"

MThings并不仅仅希望成为一个协议报文收发工具。在完成设备通信之后,真正的工程应用才刚刚开始。

设备数据通常还需要经历:

设备接入 → 数据配置 → 实时采集 → 状态监控 → 历史存储 → 告警 → 数据导出 → 远程监控

因此,MThings 的设计目标一直是:

既能用于设备开发阶段的快速调试,也能直接用于项目现场的长期运行。

例如,一家智能仪表厂家在完成自己的CJ/T 188、DL/T 645 或 DL/T 698.45设备后,可以直接使用MThings进行通信测试和数据显示。

项目交付时,同一套软件又可以继续完成实时监控、历史数据记录以及数据导出。

对于需要进一步产品化的设备厂家,还可以在此基础上构建自己的专用上位机

减少重复开发,也减少从"研发调试工具"切换到"项目运行软件"的成本。


📌写在最后

Modbus、PLC,到DL/T 645、DL/T 698.45,再到CJ/T 188,MThings一直在做同一件事情:

让不同协议、不同厂家、不同类型的工业设备,以尽可能简单的方式接入同一个上位机。

我们希望设备厂家不必为了"做一个能用的上位机"投入大量重复开发成本,也希望现场工程师不必为了不同设备准备一堆不同的软件工具。

水表、电表、PLC、传感器......

能采的,都放进来。

协议越来越多,但使用方式应该越来越简单。

这也是摩尔信使 MThings 持续更新的方向------

轻量化,但不意味着能力少。

配置简单,但不意味着只能做简单项目。

水电不分家,数据统一管。

摩尔信使MThings,让设备接入更简单,让数据真正用起来。

相关推荐
Titan20242 小时前
Linux网络基础知识
linux·服务器·网络·c++·学习
RisunJan3 小时前
Linux命令-tcpdump(网络数据包捕获)
linux·网络·tcpdump
Titan20243 小时前
Linux网络学习:套接字、UDP的封装与应用
linux·服务器·开发语言·网络·c++
jason.zeng@15022076 小时前
服务器磁盘读写效率,网络吞吐量查看,mysql性能调优
服务器·网络·mysql
张小姐的猫6 小时前
【Linux】网络编程 —— 传输层协议 TCP(下)
linux·运维·服务器·网络·tcp/ip·http·php
Light Gao6 小时前
企业级灰度发布技术方案
网络·数据库·oracle
Little Tian6 小时前
基于FPGA的UDP回环实验(二)----ARP模块
网络·网络协议·udp
今儿敲了吗7 小时前
CN——数据链路层(下)
网络·笔记
你怎么知道我是队长7 小时前
计算机网络入门指南:从OSI模型到网络设备
网络·计算机网络