关于数据采集机制的思考

• 网关采集机制的弊端

1. 数据不同期及与其真正发生时刻的分离

平台存储的数据及其时标非底层表计和传感器的数据真正发生时刻，而是经过网关及平台采集后台的层层缓存，网关的上下行协议只传数据未传数据的真正发生时刻。不是同一时期的，时标错误的数据加减等运算易出数据质量问题且无意义，时标是数据的生命。说一个20岁的成人比一个5岁的儿童身高高并无意义。

以导出的XXXX和XXXX网关厂家的网关配置工程为例，下行modbus rtu数据块采集间隔为3s，假如一块表计有10个数据块接入了10块表计则总耗时为300s（3*10*10），若第一次抄的为总表，最后一次抄的为分表，则总分表数值时间差5分钟，对于工厂等用电大户5分钟可能造成总减分得负数。

事实上这种采集模式是靠上下高频的采集来保证时标接近数据发生时刻。不应由平台来采集实时数据并存历史，应该由底层表计和传感器来存历史数据，平台去采底层的历史数据，表计和传感器无存历史功能时，应由中间层采集汇聚设备来实时转历史。

1. 屏蔽了底层表计和传感器，平台未全面感知底层

平台无法直接读写表计数据，无法直接感知表计状态（如对于物理通信链路故障还是表计所属设备未开机运行不加区分和处理，而设备运行时间对于统计分析意义重大）。对于众多的物理通信链路、通信模块、表计和传感器无法感知问题定位问题，只能选择相信网关。应提供协议层的透明转发，而不应追求处处的协议转换。

3、工程化不足

增删改表计等实施运维门槛高，程序化批量配置使用困难，不能做到现场设备上电人即走的效果。例如现有某家已交付的用户物联系统，现有一自定义协议的传感器，用户想自己去完成接入，在用户不懂网关的配置使用，不懂传感器自定义协议，不求网关厂家去二次开发（某些网关厂家号称免费二次开发协议，其实羊毛出在羊身上）协议支持的情况下，怎样能经济性、方便性的来完成？应提供动态可扩展能力而不是做静态的采集。

二、MQTT上行协议的不足

自定义topic和传输json格式，非标准不利于互联互通，不成体系。应考虑远程升级、远程配置、透传、事件上报及其确认的可靠保障机制等全面的协议标准体系。

三、强化网关，弱化平台采集端还是反之

应强化平台采集端，对于多种协议多种灵活组网方式应能同时支持，最大限度的保持灵活性和直接性。弱化网关便于统一化、标准化物联中间层设备。