基于ZigBee的火灾监控平台的设计

刘志龙　杜宁

摘要： 本文针对传统火灾监控系统所存在的误报警率较高、布线复杂以及维护困难等弊端，参考先进的物联网解决方案，设计并实现了基于ZigBee的火灾监控平台。监控平台主要包括基于JavaEE的分布式软件架构和基于ZigBee的无线硬件网络搭建两个核心部分，采用了私有云、MVC架构、XBee封装模块等主流软硬件技术，充分满足了用户对火灾监控的网络化、自动化、智能化要求。

关键词：ZigBee；XBee； 火灾监控

1 绪论

火灾自动探测报警系统作为早期探测火灾、将火灾遏制在萌芽状态的重要设备，是实现防消结合，预防为主的消防策略的重要手段。目前主要的火灾自动报警系统大多采用有线方式，存在系统耗材多、造价高、布线繁琐、线路容易老化、故障发生率和误报率高等诸多问题[1]。

针对以上提出的问题，本文提出了无线监控的解决方案，在深入的分析了用户在火灾安全中的实际需求后，设计并实现了一套基于ZigBee的物联网监控网络平台[2]，弥补了现有的有线监控方式所存在的不足，实现了火灾安全的管理网络化。快速为用户提供详细准确的火灾安全监控数据，适应不同规模环境的火灾监控需求。

2火灾报警平台的解决方案

本监控平台由数据采集终端、API中间件、数据展示终端三部分组成，采用分布式设计，平台核心是基于私有云的API中间件，采用JavaEE技术进行人机交互界面的研发。采用MySQL数据库进行实时数据的持久化，Redis数据库用于管理缓存数据。在软件架构方面，采用Nginx反向代理服务器进行负载均衡[3]。应用服务器使用Tomcat集群，软件代码部分采用了企业开发中常用的Spring MVC作为MVC层，采用MyBatis作为ORM层，保证软件平台的代码质量和应用级别的安全性。底层使用工业级的Xbee节点用于传感器数据的传输，保证数据传输安全以及准确性[3]。该网络平台经过配置之后可以对不同类型的火灾监控相关数据进行记录，传输，展示，分析等相关操作，同时该平台采用分布式设计，保证了平台的横向和纵向扩展的可行性。在记录环境安全数据的同时，对数据进行分析和折线图展示，以及安全威胁的预警与报警，并设计和实现了前端展示平台，可以对不同的屏幕大小进行自动适应，方便适用于不同类型的使用环境。

2.1 平台总体结构设计

本平台的结构主要分为三部分：API中间件部分、数据节点、数据展示终端，整体的网络拓扑架构如图1所示。

API服务器部分包括：用户注册，用户登录和回话鉴别等部分。其中，用户可以使用个人信息进行注册，用登录系统中，用户正常使用的情况下不需要注意其他问题，用户的数据安全和用户账户的安全由服务器端进行确认和保障。

底层数据节点包括：一到多个数据节点的数据缓存和数据的简单处理，对数据进行处理包括验证数据是否达到了警报值，选择对用户告警并传出警报信息到API服务器，该模块还包括把普通的数据传送到API服务器。

终端展示部分包括：用户的登录，注册，浏览的页面，以及作为用户和API服务器的桥梁，封装用户的请求和API服务器的反馈，并解析为元数据展示给用户，以及简单的鉴别用户的输入，防止一些不正确和非法的请求直接请求到API服务器。

2.2 API中间件架构

API中间件是底层硬件部分和数据展示终端之间的桥梁，这部分接受来自于底层硬件部分的数据，对数据进行操作，持久化到数据库中，通过数据展示终端的请求，提取用户需要的数据，对数据进行封装之后发送到数据展示前端。通过这部分的中转，实现整个系统的联动，也是通过API中间件，实现了底层与前端展现的分离，保证了平台的健壮和可伸缩性，防止出现数据流失和数据泄密，这部分采用了三层架构的设计模式。从对接HTTP请求，到业务层分流，到DAO层的数据库操作，再次采用分层解耦的方式保证了API中间件本身的健壮性和弹性，维持了“高内聚，低耦合”的软件工程设计思想，这部分是整个火灾监控平台的“心脏”，各个部分的依靠弱关系进行连接，每一个部分的宕机都不会导致整个系统的崩溃，API中间件起到了很大作用，API中单件的架构如图2所示。

2.3 硬件设计

数据处理节点是一个中转站，用于对接多个数据采集节点，收集数据采集节点的数据，对数据进行简单的处理，并把数据发送到API服务器。这是数据处理节点的功能。数据处理节点是一个较之数据采集节点更高一级的处理单位，这个部分是保证上下层联通的物理保障。

数据处理節点可以安装一个SD卡模块，通过在SD卡中存储配置文件来保证可以动态修改一些配置文件，类似于API中间件的IP地址。在初始化节点的同时读取配置文件，保证用户可以简单的编辑配置文件完成一些节点的复杂配置，减少用户的学习成本。数据采集节点由四个部分组成：

1. SD模块：

这部分用于读取配置文件，做到配置和程序代码的低耦合性，保证配置文件可以单独进行处理，方便用户随时升级配置。

2. HTTP模块：

这部分负责把已经包装好的数据通过HTTP请求发送到API服务器模块，以及读取来自于服务器的反馈，确认通信的成功与否。把这部分单独抽取出来，可以保证减少重复代码，合并多个需要发送HTTP请求的部分。这部分需要依赖SD模块，通过SD模块读取的配置文件获取到API中间件的IP地址，之后可以与服务器进行通信。

3. 警报模块：

警报模块是对数据进行第一次处理的部分，这部分同样需要依赖SD模块，通过SD模块中存储的报警标准，在对数据进行过滤的时候，通过警报模块对每一条数据和标准进行对比，如果发现超出了标准，就进行报警处理，通过一个报警设备持续播放警报信息，直到用户介入。

4. OLED模块：

负责把实时信息显示到一块小屏幕上，可以让用户随时了解当前节点的工作状态，可以简单的判断出现的问题，当数据处理节点每接收到一条数据的时候，均显示到OLED屏幕上面，平台采用动态刷新的方式对数据进行展示，当触发警报的时候，在屏幕上显示出当前报警的节点的序列号，方便用户对报警的节点位置进行排查，这部分采用点阵对字母进行显示，可以使用软件对常用的字幕进行构造点阵状态，把字符映射到点阵中，可以实现在屏幕上对一些常用字符进行显示。

5. XBee读取模块：

这部分负责对通过XBee传出的传感器数据进行提取，并把16进制数据转换为10进制，方便程序对数据进行处理，可以方便的把数据显示到OLED屏幕上面。这部分负责对XBee节点进行轮询，读取实时数据，保证在对接多个数据采集节点的时候，保证数据采集的稳定性。硬件设计如图3所示：

3 结论

基于ZigBee的火灾监控平台实现了软硬件的联动，数据自底向上的传输，整个平台是对目前物联网技术的一次完整的实践，底层的数据采集节点实现了联网，API中间件的设计保证了平台数据的上传下达，使用JSON进行数据包装，保证了前端展示的平台无关性，平台依照统一化设计，模块化开发，构造出了一套跨平台的，稳定的，结构可伸缩性的物联网平台。

参考文献

[1] 杨艳华， 张凤登， 马进明. ZigBee技术在火灾自动报警系统中的应用[J].上海电力学院学报，2008，24（4）：393-396

[2]李娟，胡方明. 基于ZigBee的高层建筑无线火灾报警系统[J].电子科技，2012，25（6）：34-40

[3]高守伟，吴灿阳，杨超. ZigBee 技术实践教程： CC2430 /31 的无线传感器网络解决方案[M].北京： 北京航空航天出版社，2009.