仪表在电池/外电源切换时平台的自动切换支持

PS:可参照电信NB平台,下文中的短链接模式下平台实现的机制类似电信NB后台的功能。


2种模式说明:在外电源供电情况下,采用长链接模式,仪表定时发送心跳包,服务器与仪表之间采用应答式通讯机制,所有指令实时下发,包括定时数据采集及控制指令;在电池供电情况下,采用短链接模式,控制指令在服务器缓存,只有当仪表上线并主动上报数据完成,服务器才下发控制指令,所有工作完成后仪表断网进入休眠状态。


本功能实现以下目的:

1 支持外电源长链接模式,客户可自由设定数据刷新间隔,可设定远程操作指令

2 支持电池供电定时上线模式,仪表定时上报数据,可设定远程操作指令

3 系统可根据仪表工作模式自动切换(仪表上报指令通知平台)


要解决的问题

1 电池供电模式下,仪表定时上线,需要解决控制命令缓存的问题,只有当设备上线的时候才下发

2 在部分情况下,需要比较详尽的数据,但是频繁上线会消耗电量,所以采取仪表定时采集传感器数据,上线时集中上报数据。举例说明:下位机单片机5分钟采集一次数据,6小时上报一次。每次上报数据有72条,在连续上报历史数据的过程中,会产生2个问题 1 如果连续上报,会产生粘包问题 2 如果间隔5S上报数据,耗时太长,且不能消除粘包问题。

3 在有下发指令的情况下(在线充值,开关阀),如何协调指令下发与数据上报之间问题



解决方案


1 C5短链接模式下仪表与平台交互逻辑

1573564809867092.png


2 数据包头机制

所有数据(包括上报数据及下发指令)均加上包头,包头格式为:

0XFA  0X0A  0X1F  0 X1F  0 X1F 数据长度(1个字节)

比如仪表上传数据为 01 03 04 11 22 33 44 4B C6,则在C5包头机制下发送数据为 FA 0A 1F 1F 1F 09  01 03 04 11 22 33 44 4B C6

此机制可以解决如下几种情况:

A 2条数据包粘成一条,可以正确识别。

B 3条数据包,平台接收变成2条数据。系统会自动将此2条数据进行拼接并识别为3条数据。

C 连续3条数据,平台接收的时候,每2条数据中间都会插入一些垃圾数据。此情况下,系统也会准确的识别3条数据。

注:此机制已经可以确保数据准确性,无须包尾。理论上说,基于无线联网的系统均需加上包头机制。当然,在有线联网情况下,无需添加包头。

至于仪表与服务器平台之间的数据交互指令,可使用任意格式和规范。标准modbus可以,自定义的通讯协议也可以,只要满足包头机制即可。


3 数据确认机制

部分重要的数据,必须要 仪表/平台 确认收到才能够做下一步操作,比如模式切换机制(在平台,长链接与短连接是完全不同的运行机制),仪表由电池供电切换成外电源供电,上报模式通知指令的时候必须收到服务器的回复才可以正式切换,这样可以保证仪表及服务器均可以运行在同一种模式下。当然,绝大多数情况下,数据不需要回复。有了这样一种机制,可以做到平台跟随仪表自动切换运行模式,因为在服务器平台,2种模式除了数据接收,指令下发,对历史数据的处理也是完全不同的逻辑。

所以,在做仪表程序初始设计的时候,至少应该设计一条供电模式切换通知指令,且此指令,服务器必须回复,且只有收到服务器正确回复后,单片机数据收发机制才能按照新模式运行。当然某些重要的时间节点数据,以及重要的报警数据,也需要平台确认回复收到。


4 时间戳机制

如果需要上报历史数据,则在中间中必须携带时间戳。


通过以上4个方面的改进,可以完美实现平台在仪表供电机制改变时候的自动切换。


当然了,有人可能会说,我的要求比较简单,比如流量计,不管是外电源,还是电池供电,6个小时主动上报一次数据,别的需求也没有,还用弄得你这么复杂嘛。当然不需要了,如果只是这么简单的一个需求,上面的啥交互机制,包头机制,确认机制,时间戳机制通通都是废话。只需要仪表程序设计成定时6个小时上报一次就完事,不涉及到模式切换的问题,当然了,服务器平台也不涉及到什么模式切换的问题。