`

物联网 设备协议 动态编码解码协议框架

阅读更多

       今天心血来潮,突然想把多年前写的一套设备协议动态编码解码框架分享给大家。这套框架谈不上设计的很好(从构思到实现只用了3、4天时间,没有经过精雕细琢),但在某些设计方面还是有可取之处(后面一直在用,也用的挺好的)。先说说产生背景吧。这是我在一家智能家居公司工作的时候开发的一套框架,当时我主要负责设计开发设备网关系统,同时编码解码设备协议。在工作期间,我发现一个非常浪费人力的事情,每个设备的接入都需要一名java开发人员配合硬件工程师进行硬件程序的调试,每种产品的协议都要硬编码,说白了,需要一个JAVA开发人员按照硬件工程师给的协议硬编码(解析设备上传的数据,同时编码下发用户给出的指令)。最重要是,还要陪着硬件工程师调试设备,协助他们查找问题,工作效率极低。于是,我想着是否能开发一套通用的协议解析程序,然后跟公司说 了自己的想法。因为我很懒,不喜欢做重复的事情,我在网上查找过,发现没有符合我们业务需求的开源框架,只能自己研发。

     如果是做过设备协议解析的开发人员,应该明白,协议就是有规则的多个数据的集合,既然是有规则,那程序就一定能做的了这件事情。我们的设备协议主要有两部分构成:wifi模块协议和硬件的数据协议。废话就不多说了,就说说这套框架的优缺点:

优点:

  1.  能动态的编码和解码设备协议。说白了就是能把设备上传的数据包(二进制数据)按照设备协议转换成JSON数据,也能将用户下发的JSON格式数据命令,转化为设备读的懂的二进制。(前提条件就是把设备的协议配置成xml配置文件,程序就是根据xml的配置去解码或者编码设备数据)。

 

  1. 易扩展,支持协议层层解析,换句话说,不管一个数据包有多少种协议的数据,框架能一层层解码也能一层层编码。

 

  1. 支持不定长数据包解析。一般情况下,数据包都是定长的,如果设备协议规定了数据包总长度是200个字节,设备上传的数据就是200字节,这种是定长协议。但实际情况,有时候会出现同一种数据,设备上传的数据包大小不定。当然,这种数据有部分数据是按照某种规则循环,说白了就像数据库表里面的数据一样。

 

  1. 支持不规则数据类型解析。硬件工程师为了节约使用设备闪存,可能一个数字使用3个字节或者5个字节来表示。

 

  1. 支持bit解析。硬件工程师为了节约设备闪存,可能一个字节存放多个功能的数据。

如果有需要的朋友,可以在百度网盘下载: https://pan.baidu.com/s/1VFlvIXo2JjGScavHSDFaSw(里面有详细的设计文档和样例)

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics