物联网智能数据采集和监测系统后台服务设计研究

杜 渂 王聚全

（1.上海迪爱斯通信设备有限公司 上海 200030 2.电信科学技术第一研究所 上海 200032）

0 引言

近年来，随着物联网智能设备大量的应用，针对物联网智能设备数据采集和监控系统的需求也越来越多，基于这样的市场需求，笔者所在的研发团队研发了一款基于物联网的智能数据采集设备和相对应的数据采集和监控系统。

本单位研发的物联网智能数据采集和监控系统，以物联网智能终端设备为基础应用设备，通过物联网数据采集设备进行数据采集，以计算机网络为通信平台，将本单位研发的物联网智能数据采集和监控系统作为上层应用，实现各种智能终端设备的统一接入、统一数据采集、统一监控。

本文将介绍基于物联网的智能数据采集和监控系统在后台服务上的一些设计方法。

1 设计理念

早期的智能设备采集和监控系统，采用的设计理念是针对每个智能设备编写一个采集和监控程序。这样的设计方式不易动态增加设备，在开发上导致每一个设备的采集和监控程序都需要控制通信、转换和容错等处理功能。同时，新增加的采集监控程序需要下载到数据采集设备中，并进行调试和测试，上位机系统也需要增加相应功能的采集和监控程序。

基于物联网的智能数据采集和监控系统，实现了各种智能终端设备的统一接入、统一数据采集和统一监控。系统在服务设计上采用了通过配置实现解耦的设计思想，将面向设备的设计理念通过多层抽象、解耦和协议转换，转变成编写设备协议转换规则的模式，使得智能设备可以通过配置的方式快速接入到系统，如图1所示。解决了不同厂商、不同功能的智能终端设备的接入问题，大大提高了系统的实施效率和可扩展性。

图1 通过配置实现解耦的架构体系

通过这种设计方式，在产品化方面，通过配置即可达到接入大部分智能设备的功能。通过多层抽象，编写通用的业务模型组件、通信协议组件和协议转换组件，将设备数据交互抽象成为某一数据转换协议，通过配置协议转换组件达到接入大部分智能设备的功能。

在可扩展方面，针对某些使用自定义协议的智能设备或者无法通过配置协议转换规则接入的智能设备，可以采用编写应用插件的方式进行扩展。应用插件采用对协议转换规则进行抽象封装，使得以后使用同种协议模式的智能设备的不需要再进行开发即可方便的接入到系统中。

在开发复杂度方面，数据采集设备内不需要编写复杂的智能设备接入程序，仅需下载配置好的解析文件即可采集智能设备的各种数据，使得采集设备内的嵌入式软件开发复杂度降低。同时，业务模型层－解析层－视图模型层－界面层等各层之间业务和数据进行了解耦，各层之间通过配置后的协议转换组件进行通信和解析，使得监控系统开发的复杂度降低。由于采用了统一框架的模式，由系统框架来统一处理各种设备的数据、通信和界面显示等异常情况，使得定制开发和插件开发的复杂度降低。

在实施过程中，由于采用动态界面的设计模式，使得界面上所有展现组件可根据使用场景随意添加和布局。针对大部分设备，由工程人员通过配置化操作即可实施，降低了项目实施的复杂度。

2 服务设计方法

系统后台服务主要由业务模型层、解析层、资源层、通信层和公用模块组成，本章主要通过介绍业务模型层、解析层和资源层的设计思想，描述可配置的智能设备接入方案的实现原理。系统的各层模型如图2所示。

2.1 业务模型层的设计

业务模型层主要用来描述业务的基础模型和设备模型，也包含了监控相关的流程。业务模型层主要由三部分组成，分别是基础模型、设备模型和业务模型层配置化消息解析功能。

基础模型定义了系统中所有类的基类。

设备模型定义了物联网数据采集设备及终端设备的层次结构、设备属性、设备中测点的属性、ModbusTCP消息解析协议和数据转换协议等内容，同时对物联网数据采集设备与终端设备的消息收发与解析进行相应的操作。设备模型中还定义了设备的监控过程，包括消息的发送、接收、解析、数据转换、采集的数据是否在正常范围内、异常事件通知等业务逻辑。设备模型是业务模型层的核心模型，也是整个系统的基础。

图2 后台服务模型图

系统中所有消息解析的规则都是在XML文件中进行配置的，包括消息的解析、消息变量的解析和数据转换等，现系统主要包含了对ModbusTCP协议的01和03消息的解析。针对每种消息类型，设计有相应的消息解析器，如果需要解析其它的消息类型，可以采用开发消息解析插件的方式编写相应的解析器类，并在XML中进行配置，动态加载使用。

通过配置化的解析过程，使得系统能够灵活适应不同设备的监控需求。当现有系统中的转换器不能满足要求，也可以通过编写转换器插件进行扩展，并在XML文件中配置后动态加载使用。

业务模型层的消息解析结构如图3所示。

图3 业务模型层消息解析图

2.2 解析层的设计

解析层架构由ModbusTCP消息解析器、数据转换器及XML解析器三部分组成，主要用于对消息的解析及XML配置文件的读取解析。

（1）ModbusTCP消息解析器

ModbusTCP消息解析器用于对ModbusTCP消息的封装和解析，现包含01和03消息的解析器插件，针对业务上的需求，可以通过扩展插件的方式进行解析器的扩展。

ModbusTCP 01/03消息解析需要对字节流按照ModbusTCP协议分解为7个字节的消息头，并根据功能码是否正常保存相关数据，返回解析后的消息包。功能码如果收发消息一致则正常，如果接收的消息功能码是发送消息功能码加上0x80，则表示消息异常，程序中需要保存错误信息。

01/03消息封装需要将上层的消息包按照ModbusTCP协议填充到字节流中，需要注意的是由于协议中规定需要按照Big Endian方式传递消息，故在填充时需要将数据按照这种方式来转换，最后生成包含字节流和原始功能码的发送消息包。在设计时考虑将原始功能码封装到包中是为了达到判断接收消息中的功能码是否正常的目的。

（2）数据转换器

数据转换器主要针对智能设备每个测点采集的监测数据进行数据转换使用，转换器可以配置参数并进行扩展。

01/03消息数据转换过程实际上涉及到模型层中定义的接收消息处理流程。对于01消息只需要将字节流转化为位数组，采用默认的ByteToBitConverter转换器即可实现。03消息较复杂，需要根据每个设备测点在字节流中的位置先将字节流中的数据分离出来，再根据每个测点对应的数据转换器数组进行依次的数据转换。两种消息在数据转换完成时，都需要进行数据的效验，最终进行测点赋值。

由于需要监控的终端设备千变万化，每种设备的测点数据在从物联网数据采集设备中获得时可能还不能直观的显示给用户，因此需要做一定的转换。例如从温湿度计获得的数据可能并不是摄氏度的方式表达的，就需要转换为摄氏度。在转换的过程中，系统提供了相应的数据转换器对测点数据进行处理。但由于转换过程的不定性，不可能穷尽所有的转换方式，在设计时可以将一些转换方式分解，然后根据实际需求采用多个转换器累加串联的模式，即上一个转换器得到的结果将被应用于下一个转换器，使用多个转换器来实现同一个数据的转换，并获得最终的结果，实现了更多的转换功能。

针对业务上特殊的需求，用现有的转换器无法对数据进行有效转换的话，可以以开发插件的方式新编写一个或多个转换器来应对出现的特殊转换，当然在研发时需要尽量进行抽象设计，保证新的转换器能被应用到新的场合。这种方式通过使用多个转换器就能对复杂的数据进行转换并获得结果，最大程度的复用了转换器，并通过使用不同的转换器参数还能完成同一个转换器的不同功能。相对应的，在XML配置时则需要对每个测点配置多个转换器，配置顺序决定了转换器执行的顺序。

转换器累加串联结构如图4所示。

图4 转换器串联结构图

（3）配置解析器

配置解析器用于所有XML配置文件的解析与验证，同时支持解析器的扩展。

配置解析过程包括：加载XML配置文件，解析XML配置文件根元素，根据根元素获取对应的解析器，并进行XML配置文件架构验证，最后再使用解析器解析XML配置文件获得对应对象。如果解析器在解析配置的过程中，该XML配置文件还关联了其它XML配置文件，则会对关联的所有XML配置文件进行再解析。系统中的XML配置文件是从第一个主XML文件开始，将所有XML文件关联起来的，因此只需要调用一次加载方法即可将所有的XML配置文件加载起来。

3 配置解析器的设计

在配置解析器设计中采用的是工厂模式的设计方法。一般的工厂模式是将选择权交给工厂，本系统则将选择权配置在XML文件中。每种类型的工厂存储了该类型相关的解析器或转换器，对应于相应的XML配置。同时工厂中的每个解析器或转换器的ID又被其它XML文件引用，从而确定了运行时需要的具体对象类型。这样的方式类似于IoC，能够将类之间的依赖放在配置中而不是代码中，有利于修改和扩展功能。调用解析器/转换器过程如图5所示。

图5 调用解析器/转换器过程图

在定义解析器或转换器的同时，也可以定义其默认参数和用户参数。默认参数是在工厂对应的XML文件中定义的，属于出厂时的参数，在其它XML引用工厂中对象时，可以更改默认参数为实际的用户参数，最终使用的参数将是这两种参数的组合，其中用户参数优先。默认参数和用户参数的定参过程如图6所示。

图6 定参过程图

4 配置解析器的解析流程

XML配置文件的解析实际上采用了两种方式：一种是自解析，即XML根元素已经描述了如何解析该XML文件，主要包含创建解析器需要使用的程序集和对象类型，以及架构验证需要的文件路径。另一种是通过根元素名称在XML解析器工厂对应的XML文件中进行匹配。分别使用这两种方式的原因在于，第二种方式的使用前提是XML解析器工厂已经从XML文件中加载起来，这样该工厂对应的这个XML就必须要先完成自解析，即第一种方式是第二种方式的前提。

采用根元素来匹配的方式也简化了系统中的判断流程，根元素名称决定了该XML的类型和所使用的解析器类型。同时这种设计方法可以在解析XML配置文件的时候重用，例如系统中大部分的数据字典在XML结构上都是一样的，所以只需要采用同一个根元素名称，就能使用同一个解析器进行解析，不需要再增加额外的解析器。

系统在解析时还采用了XML架构文件来验证XML的结构正确性，这样设计的目的是为了简化程序代码中对XML的效验，同样每个根元素名称也对应唯一一个XML架构文件。XML配置文件解析方法如图7所示。

图7 XML配置文件解析方法

（1）资源层的设计

资源层主要包含了系统需要使用的相关资源，包含了界面需要使用的控件库、容器库、监控主题、配置需要使用的模板字典、加载XML配置文件的统一入口信息，以及系统需要使用的数据类型和字典资源。

资源层供其它模块和层次调用，也采用类似解析层使用的工厂模式设计方法进行设计，可进行资源的配置、扩展和替换。

资源层最主要的应用场景是使用监控主题，监控主题主要是将所监控的各个设备以及设备上的各个测点依据用户的需求动态组合在一个监控界面中，并结合布局进行动态展示。

监控主题主要由主题、主题映射及自定义主题三个部分组成，其中主题用于展示界面需要显示的监控内容，由主题工厂、主题、布局容器和前端展现控件组成。主题工厂层次如图8所示。

图8 主题工厂关系图

主题映射是主题与界面对象之间的映射关系，通过映射关系可关联到主题集合，进而可关联到每个主题，使得前台界面层能依据主题映射关系动态加载用户需要展现的主题。主题映射层次如图9所示。

图9 主题映射关系图

（2）通信层的设计

通信层主要用于建立ModbusTCP连接，可同步或异步收发ModbusTCP消息。通信层的核心为通信适配器，通过通信适配器可以同其它支持ModbusTCP协议的设备建立连接和收发消息（ModbusTCP协议默认端口为502）。

通过构建通信适配器插件的方式也可扩展通信层支持的协议类型。

（3）业务公共层的设计

公共层主要包含通用辅助类库、异常中心及系统配置模块。

通用辅助类用于定义系统使用的一些通用方法和信息。异常中心用于记录异常的日志信息以及发出异常通知消息。系统配置模块用于读取和保存系统中使用的各种配置项。

5 结束语

本文结合物联网智能数据采集和监控系统实际应用需求，通过对该系统后台服务设计理念和架构设计的论述，阐述了该系统的研究设计成果，对构建具有良好的扩展能力、高性能和易实施的物联网智能数据采集和监控系统具有一定的指导意义。通过使用该系统，可以显著降低研发人员工作量，缩短项目履行人员实施周期，提高工作效率和提升项目质量，具有良好的应用价值和前景。

[1] 杜渂，王聚全，雷霆，基于物联网的智能数据采集和监控系统设计[J].电信快报，2013（7）：14-17.

[2] 杜渂，基于RFID技术的公共交通调度系统开发与应用[J].电信快报，2010（6）：10-13，18.