基于nb-iot消防网络管理平台的规划与建设

系统简介

当前社会快速增长的社会经济和大面积结构升级的社会结构，让原本消防能力本就捉襟见肘的传统消防工作压力日益增加。消防工作面临挑战的同时，人民也发现了传统消防的弊端，传统消防在安全基础建设，安全保障能力，和对公众的消防安全意识等多个方面来说，都越来越不能够适应社会的发展状况，不能适应社会需求，不能适应现代社会的管理需求。传统消防对于现代安全需求来说，任然是整体工作在灾害易发，多发，并且难防的形势下。物联网技术的发展为消防领域带来了转机，借助物联网的万物互联的特点，消防系统能够实现智能化。极大程度的减少了消防工作对于人力物力财力的投入，减少了楼宇安全隐患，大大的提升了现有消防系统的险情预警和处理能力。
在众多物联网技术中，NB-IOT前景最为广阔，拥有三方面的优点：广覆盖，同样频段的网络，nb-iot网络基站的覆盖面积是传统GSM网络的10倍，更不要说目前的4g网络；海量设备连接的能力，NB-IoT基站一个200KHz频率扇区能轻松达到数十万级别的连接；低功耗，NB-IoT节点设备的静态功耗普遍在3-10的uA,使用一节1500ma的电池，待机时间都在十年以上;
目前在政策的扶持下，单个NB-IOT模块成本在4美元左右，可以预见在未来成本下降到1-2美元之后，势必会带来NB-IOT设备的爆发式增长。
因此，设计一个结合物联网NB技术和消防管理，对设备汇聚、终端管理、应用开发、数据分析等的承载，向上为应用开发，向下对终端进行“管、控、营”，包含连接管理（CMP）、应用使能（AEP）和垂直行业设备管理（DMP）等功能的网络管理平台是很必要的。
在实现上，本系统的开发采用IntelliJ IDEA和Hbuilder等软件进行开发，实现前后端分离设计，IDEA 是java编程语言开发的集成环境，业界被公认为最好的java开发工具，尤其在智能代码助手、代码自动提示、重构、J2EE支持、各类版本工具(git、svn等)、JUnit、CVS整合、代码分析、 创新的GUI设计等方面的功能可以说是超常的。HBuilder可以通过完整的语法提示和代码输入法、代码块等，提升HTML、js、css的开发效率。前端使用vue这个JavaScript框架，使用Hbuilder进行开发。Hbuilder和vue的契合度相当的高，各种vue的应用在Hbuilder上配置起来相当的方便，是vue的作者也推荐使用的ide。

第1章 绪论

1.1 系统开发的背景及意义
目前中国的经济结构正在转型和升级，可以说，社会正在飞速发展。消防工作面临着前所未有的挑战与压力，传统的消防工作在比较新型的的智慧消防项目面前，优势不断减少，弊端越发突出。况且在社会消防监管和政府管理部分方面，消防工作的难度也在不断的提升，压力也越来越大，因此，对于现代消防来说，传统的安全基础建设是不能满足现在社会经济发展的现状的。
“智慧消防”顾名思义，也就是智能的消防，是指使用物联网和大数据等现代技术，将灭火救援、消防设施、社会化消防监督管理等各个要素，通过物联网相关的信息技术与基站通讯等技术的有机连接，实现动态、实时、融合、互动的消防信息采集然后传递最后处理，全面促进与管理水平与提高消防监督，提高救灾灭火的决策、调度和处理能力，大幅度的提升消防管理社会化水平、智能化。
“智慧消防”项目有着传统消防项目的无可比拟的优点：
第一，在各个地区的消防隐患排查方面：传统消防通常是使用纸质文档记载检查记录，非常易造成档案的累压和堆叠产生信息闭塞导致防灾工作巡查不到位、检查记录不实时，不真实的状况。这些原因在智慧消防方面确实不用担心的，智慧消防运用高端的物联网通信技术，平台系统会自动提示不同消防设备及其主要部位的巡查标准和方法，自动记录消防巡查人员检查的痕迹。并实时上传到云平台上。
第二，在消防网络重点部位的监管可视化方面：传统消防的监控能力受限制，无法做到设备实时监控。但是智慧消防却能够对所监控的地区24小时不间断的分析，在消防事故发生初期，就能够通过平台后者手机提醒用户关注，减少损失。并且通过平台的历史记录，也便于事故现场的回溯，原因的排查。
最后，传统消防设备在使用寿命达到一定年限的时候，或者电池低压电量不足的时候，经常导致现场产生警报不报或者误报的情况发生，而智慧消防同过设备端上传设备状态，可以分析的出当前设备的传感器失灵，电力电量，使用寿命等设备的监控清空，及时提醒用户更换传感器或者电池，将不良的情况扼杀在摇篮之中。
因此本设计的目标在于在于根据当前物联网最广泛的NB-IOT技术，设计一个能让用户轻松接入NB-IOT消防设备，搭建智慧消防网络，提高消防设备的工作效率和消防设备现代化管理水平的网络管理平台，减少工作人员的劳动强度，节省劳动力，减少设备资源的浪费。
1.2 国内外NB-IOT消防管理平台研究现状
1.2.1国外管理平台发展状况
早在2014年推出的国际标准ISO-7240-1中已经明确提出过火灾报警等安防的相关设备联网的概念，其中有提到用信息传输的装置，被称之为传输设备，这套标准规定了主要的其主要的功能，主要的性能等。不过在指定标准的时候，只制定了一些基本功能，简单的将警报和故障的信息分别传送到相应的收发点，至于更加细节的流程并未提及。根据研究显示，当下只有美国，英国，加拿大等少部分发达国家和地区执行了该标准。加之国外注重隐私，过高的联网程度反而引起居民不满，所以国外往往考虑到家庭尤其是人居住环境中的报警，所以在报警系统设置范围上强调家庭用的体系，常见的平台以套件类的消防局域网和独立消防设备居多。因此，虽然国外最先提出物联网这个概念，并且物联网在国外发展势头也很迅猛，在消防报警方面，物联网平台的优势并不明显，nb-iot类的平台更是如此。
1.2.2国内设备平台发展状况
国内智慧消防提出和启动时间要比国外晚上几年，但是发展非常迅猛，从时间段来看可以分成三个主要的阶段，第一阶段，在2012年出台的《武警消防部队“十二五”信息化建设项目总体规划》。第二阶段，2016年6月举办“全国创新社会消防管理会议”。第三阶段，2017年10月部局下发的《关于全面推进“智慧消防”建设的指导意见》。主要的阶段性特征先是要消防技术和信息技术的高度融合，然后是在官方提出要由传统消防向智慧消防转型，最后则是要求加速消防的智能化和转型升级。直到现在，中国绝大多数城市都在提出智慧消防建设计划，大到省会和经济特区，小到地级市和小县城，无数的地区与城市正在对智慧消防进行建设和规划，行业未来发展潜力不言而喻。依托海量的消防设置，消防平台作为智慧消防的基石，市场份额也水涨船高。
1.3 论文的主要研究内容
本论文主主要针对应用了nb-iot技术的二级用户的消防设备的接入和管理以及应用的管理平台软件的设计进行深入研究，在此基础上对物联网系统的研究和设计，完成一个可以用户登录，产品创建，设备管理，数据存储分析与应用的消防设备管理平台，论文的主要研究内容如下：
1.使用idea平台、B/S多层体系结构、MVC设计模式和Spring开源框架实现一个可视化的设备管理系统。
2.介绍了系统实现的主要技术，包括了SSM框架的开发和前端VUE的开发。
3.对当前消防管理管理平台进行了长时间的调查与需求分析，并在需要分析的基础上进行了系统的详细设计，包括了系统的总体架构、数据库的选取及设计和系统功能模块的设计。
4.介绍了系统中如何对SSM框架中使用junit构件进行测试的方法

第2章 系统需求分析

2.1 总体需求
NB-IOT消防网络管理平台应该接入涵盖市面上常见的消防类产品，能够感知社会单位已经安装的火灾报警器，水浸报警器，红外报警器等设备的实时数据信息，通过数据库的方式把数据存储下来，并且在留有接口方便用户二次开发使用和前台查询展示。
2.2 系统的功能需求
1.本系统功能的具体需求如下：
(1)数据协议的统一
设备通过NB模块对现场的消防状况信息进行采集，并上传数据到平台，但是现状消防行业产品及种类足有数百种，接口和输出的数据格式可能千差万别，这样会给联网工作带来巨大的困难。对数据传输协议的同意就很有必要。
(2)报警接收功能
在消防管理平台的数据中心服务器收到现场设备的报警上报后，先对设备的身份进行认证，判断设备的合法性，如果合法，就进行事件的分类，存储。最后，根据上报数据的设备的从属产品，对用户客户端或者前端进行推送，相应接收端软件应该能准确显示出报警的类型和位置信息。
(3)分析统计查询功能
通过采集各种报警信息并保存下来，可以对地区的消防风险进行评估。也可以通过采集设备故障的信息，对设备完好率进行分析。
(4)用户管理功能
可以在平台上注册用户，让同使用注册的密码和名称进行用户的登录。
(5)产品的添加与删除功能
产品的添加是当用户开发了一款新的产品，平台应能创建对应的产品。产品的删除指的是当用户的产品下线后，平台可以删除已经上线了的产品。
创建产品用户应提供产品名称，产品类型，以及产品的描述信息。
(6)设备的添加与删除功能
设备的添加指的是用户在选择的产品下添加一个真是的实体设备。删除则是此设备因为其他原因导致下线，平台提供接口删除。
(7)产品的种类定义
针对市面上各种常见的nb类消防设备进行分类，涵盖烟感报警器，气感报警器，门磁报警器，水浸报警器，红外报警器，以及nb主机等设备，方便对设备的类型区分以及管理。
(8)报警方位显示功能
Nb设备本身并没有坐标方位的信息，但是这个信息对客户定位报警点和故障纠察非常重要，平台要留有接口来使设备和坐标绑定，达到坐标显示的效果。
(9)报警提示功能
在设备检测到报警并上报报警信息后，平台应能对用户进行短信提示，让用户迅速反应并处理

2.3 数据流图
1.用户的登录数据流图
用户登陆过程的数据流为：第一，用户输入管理平台的网站进行帐号密码的输入；第二，后台服务器对用户登陆信息进行验证；第三，后台服务器验证通过后返回用户的信息；第四，前端页面收到信息后存到本地，实现登录状态。
用户登陆DFD如图
2-1所示：

图2-1 用户的登录DFD
2.产品创建数据流图
产品创建数据流的过程：第一步是用户手工输入产品名称，选择产品类型，完善产品描述等信息，点击却上上报请求给服务器；第二步是后台通过查询产品列表并处理请求，返回结果给前台；第三步前头收到发来的信息进行结果的显示。

3.产品删除数据流图
产品删除数据流的过程：第一步是用户选择要进行删除操作的产品；第二步是平台通过产品名进行删除，并删除相关产品的设备，上报信息等内容，返回结果；第三步前台收到处理结果并展示。
产品删除DFD如图2-3所示：

图2-3产品删除DFD
4.设备添加数据流图
设备可以通过选择对应的产品，并填入id号等信息进行添加。其数据流过程为：第一步是用户选择产品，填入设备的id，坐标等信息，；第二步是后端查询设备表进行添加，返回结果；第三步最后将结果返回给设前端显示。
设备添加DFD如图2-4所示：

图2-4设备添加DFD
5.设备删除数据流图
设备删除数据的过程：第一步是用户选择要进行删除操作的设备；第二步是平台通过设备名进行删除，并删除上报信息等内容，返回结果；第三步前台收到处理结果并展示。

6.设备数据上传数据流图
设备数据上传数据流的过程：下位nb节点触发事件后，上报响应的数据给broker，broker鉴权后转发给后台服务器，服务器收到数据后记录到数据库。

7.平台数据下发数据流图
平台数据下发数据流过程，其步骤如下：第一步用户进入设备操作页面，输入需要发送的数据内容；第二步是后台接收导数据进行分析处理，打包发送给broker服务器；第三步broker服务器收到pulish数据后发送给订阅了此主题的nb节点设备。
本章对NB-IOT消防网络管理平台进行了需求分析，并且对该平台的功能进行了设计。介绍了数据协议的统一，报警接收功能，分析统计查询功能，用户管理功能，产品的添加与删除功能，设备的添加与删除功能，产品的种类定义，报警方位显示功能，报警提示功能等系统功能的具体需求。最后，文中给出用户的登录、产品创建、产品删除、设备添加、设备删除、设备数据上传、平台数据下发的数据流图，并作了详细说明。

第3章 系统设计与实现

3.1 系统设计
3.1.1 系统总体架构设计
本系统的总体设计框架采用前后端分离设计，使用vue+ssm实现，主要概念就是：后台只需提供API接口，前端调用AJAX实现数据呈现。在以前的web应用开发中，前后端不分离的原因导致了诸多的问题，对于开发人员，最可怕的问题莫过于前后端代码糅杂在一起，应为没有对应的约束，MVC中每一层都可以能有其他层的代码出现，日积月累，项目维护性的大大降低。而且还存在着开发效率低下的问题，前端代码写好静态，后端的开发居然还要在静态代码的基础上翻译成vm模板，过程繁琐不说，后端在实现业务的同时，不可避免的要对展现界面的强关注；还有就是对前端发挥的局限，性能优化前端自己可以操作的空间是很有局限性的，经常要与后端合作才能有所成效，但由于后端框架限制，我们很难使用Comet、Bigpipe等技术方案来优化性能。使用前后端分离的设计，大大降低的程序的耦合行，前后端从工程层面上就已经分离开来，通过api进行交互，后端只需要提供业务接口，前端在提供接口的文档下只关注客户端的展现效果，大大提高了生产力。现在，前后端分离的设计已经是大大小小公司开发的首选了。
前端项目使用的是vue编写，Vue是一个对新人非常友好的框架，React和Angular相对来说就没那么容易入门。由于Vue是中国人开发的，它的文档也符合大家阅读和学习的习惯。Vue用于构建交互式的界面库，是一个搭建数据驱动的页面渐进式框架，核心设计模式是Model-View-View-Model和可组合的组件系统，提供的api不仅十分简单而且也非常灵活。React著名的虚拟dom技术和Angular十分好用的双向数据绑定等的技术都有继承在这个框架中，是一款非常年轻的功能性框架。本设计是基于vue实现spa单页面应用。
后端使用ssm框架实现。ssm框架，第一个s是SpringMVC的缩写，第二个s是 Spring的缩写，最后的m则是MyBatis的缩写。Spring 是J2EE最出名的开源框架之一，创建的初衷是为了解决企业应用程序编写的复杂性。框架的主要优点是其分层架构，允许你自由选择哪一个组件进行开发。Spring提供Spring MVC是当前最好用的MVC框架之一，自从Spring 2.5版本发布后，由于支持注解配置，易用性的提高非常巨大。Mybatis是用来操作数据库，基于jdbc的框架,可以通过注解把各个业务实体类和数据表结合起来。
1．Web层
Web层使用SpringMVC实现,SpringMVC属于SpringFrameWork的后续产品，已经融合在Spring WebFlow里面。Spring MVC 分离了控制器、模型对象、分派器以及处理程序对象的角色，这种分离让它们更容易进行定制。
SpringMVC 通过一套 MVC 注解，让 POJO 成为处理请求的控制器，无需任何接口，同时，SpringMVC 还支持 REST 风格的 URL 请求。此外，SpringMVC 在数据绑定、视图解析、本地化处理及静态资源处理上都有许多不俗的表现。它在框架设计、扩展性、灵活性等方面全面超越了 Struts、WebWork 等 MVC 框架，从原来的追赶者一跃成为 MVC 的领跑者。
SpringMVC 框架围绕 DispatcherServlet 这个核心展开，DispatcherServlet 是前端控制器设计模式的实现，提供 Spring Web MVC 的集中访问点，负责职责的分派，而且与 Spring IOC 容器无缝集成，从而可以获得 Spring 的所有好处。
SpringMVC的框架流程如下：

图3-1 SpringMVC的框架流程
2. 业务逻辑层
业务层使用Spring设计，Spring是一个开源框架，是于2003年兴起的一个轻量级的Java开发框架由Rod Johnson在其著作Expert One-On-One J2EE Development and Design中阐述的部分理念和原型衍生而来。它是为了解决企业应用开发的复杂性而创建的。pring使用基本的JavaBean来完成以前只可能由EJB完成的事情。但是，Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度而言，任何Java应用都可以从Spring中受益。简单来说，Spring 是一个分层的 JavaSE/EE Full-Stack（一站式） 轻量级开源框架。

（1）分层
JavaEE 经典的 MVC 三层结构为表现层、业务层、持久层，Web表现层负责页面数据显示、页面跳转调度，例如 JSP/Servlet、SpringMVC；Service业务层负责业务处理、功能逻辑和事务控制，例如 Service、JavaBean、EJB；而持久层Dao则负责数据存取和封装，及与数据库打交道，例如 JDBC、Hibernate、Mybatis。
（2）一站式
一站式，指 Spring 为 JavaEE 的每一层都有相应的解决方案，比如：
表现层：Struts1、Struts2、Spring MVC；
业务层：AOP 面向切面编程、IoC 控制反转、事务控制；
持久层：JdbcTemplate、HibernateTemplate、ORM 框架（对象关系映射）的整合
（3）轻量级
从大小与开销两方面而言，Spring都是轻量的。完整的 Spring 框架可以在一个大小只有 1MB 多的 Jar 文件里发布。且 Spring 所需的处理开销也是微不足道的。Spring 的出现解决了 EJB 臃肿、低效、繁琐复杂、脱离现实的情况。而且使用 Spring 编程是非侵入式的。Spring 应用中的对象不依赖于 Spring 的特定类。
Spring 的体系结构：

图3-2Spring 的体系结构

3. 数据持久化层

本系统的持久化层采用了目前流行的持久层框架-mybatis，Myatis 原本是apache开源项目iBatis, 2010年这个项目由apache software foundation 迁移到了google code，并且改名为MyBatis。MyBatis是一个基于Java的持久层框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO）MyBatis消除了几乎所有的JDBC代码和参数的手工设置以及结果集的检索。MyBatis使用简单的 XML或注解用于配置和原始映射，将接口和Java的POJOs（Plain Old Java Objects，普通的Java对象）映射成数据库中的记录。

3.1.2 数据库设计
管理系统主要功能是对设备节点的所有关信息进行处理，是对数据的操作，因而数据库建立的好与坏会直接影响系统的运行效果，本系统使用mqsql数据库作为后台数据库。本节对系统用到的数据库表结构进行详细设计。
根据系统需求分析，管理平台需要建立一些数据库表来存储各类型相关的信息，如用户的信息、产品的信息、设备的信息、设备上传数据的信息、多对多的关系信息等一些数据库，下面对上述一些主要数据库表的设计：
(1)User（用户信息）表
表3-1 User表
列名 数据类型 可为空 注释
USER_ID VARCHAR2(32) NOT NULL 用户Id
UPWD VARCHAR2(32) NOT NULL 密码
UNAME VARCHAR2(32) NOT NULL 用户名
EMAIL VARCHAR2(32) NULL 电子信箱
表3-1描述了存放用户信息的数据库表结构
(2)Product(产品表)表
该表为产品表，用于保存产品创建时的一些基本信息（如产品名称、产品名称、设备名称、产品设备拥有量、产品类型、设产品描述等）。表结构如表3-2所示：
表3-2 Product表
列名 数据类型 可为空 注释
ID NUMBER(15) NOT NULL id
PNAME VARCHAR2(30) NOT NULL 产品名称
PCDATE VARCHAR2(30) NOT NULL 创建日期
DEVNUM VARCHAR2(30) NOT NULL 设备拥有量
TYPE VARCHAR2(20) NOT NULL 产品类型
MSG VARCHAR2(20) NULL 产品描述
(3)u_p_relation(用户和产品对应表)表
该表为为一个关系表，由于产品和用户之间是多对多的关系，因此需要一个中间表作为中转，表结构如表3-3所示：
表3-3 u_p_relation表
列名 数据类型 可为空 注释
ID NUMBER(15) NOT NULL id
UNAME VARCHAR2(30) NOT NULL 用户名
PNAME VARCHAR2(20) NOT NULL 产品名
(4)Device(设备表)表
表3-4 Device表
列名 数据类型 可为空 注释
ID NUMBER(15) NOT NULL id
NAME VARCHAR2(30) NOT NULL 设备名称
REC_NAME VARCHAR2(20) NOT NULL 设备接收数据量
STATUS VARCHAR2(20) NULL 设备状态
X DATE NULL 坐标x
Y DATE NULL 坐标y
PHONE VARCHAR2(30) NULL 手机号码
表结构如上表3-4所示，该表为设备表，用于描述nb消防设备的相关信息（如设备编号、设备名称、设备接收数据量、设备状态、坐标x、坐标y、手机号码等）。
(5)Update(数据上报表)表
该表是存储着各种设备上报的数据，记录着上传数据的主题，数据的内容，以及接受的时间，表结构如表3-5所示：
表3-5 Update表
列名 数据类型 可为空 注释
ID NUMBER(15) NOT NULL id
TOPIC VARCHAR2(30) NOT NULL 数据接收主题
DATA VARCHAR2(20) NOT NULL 数据内容
DATE VARCHAR2(20) NULL 接收时间
3.1.3 系统模块的设计
通过需求分析可知，基于NB-IOT的消防网络管理平台的实现主要包括用户管理方面、产品管理方面、设备管理方面、数据管理方面、下发数据刚面等几模块的实现，本节不对全部的模块进行介绍，主要展示网络管理平台中用户登陆模块、用户注册模块、产品添加模块、设备查询模块、设备上报数据查询模块的设计。

1. 用户登陆模块
   用户登陆模块作为门户的入口，要访问网络管理平台一定要先进行身份验证，只有验证通过的用户才能访问本系统。因此，首先用户要打开用户登陆页面，在登陆页面按照要求输入自己的用户名和密码，然后单击页面“登陆”按钮，用户输入的信息在客户端进行加密后发送到服务器，服务器接受到客户的请求后将对数据进行解密操作，将解密得到的用户名和密码与数据库的用户表中的用户名和密码进行比较，如果表中存在该用户名且密码也相同，则用户登陆成功，返回相应的用户信息给用户；如果存在用户名不存在或密码错误的现象，将会给出相应的提示信息“用户名不存在”或“密码错误”；如果不输入用户名或密码进行登陆，前端会直接提示“用户名或密码不能为空”。

2. 用户注册模块
   用户要进行登录操作就必须拥有一个用户账号，要用有一个用户帐号就必须注册一个用户帐号，要注册账号就必须打开注册界面。输入网址进入登录界面，在登录按旁边有个注册按键，单击“注册”按钮弹出注册窗口。根据要求，填写用户名称和用户密码等相关信息，点击“提交”按钮，请求发送到后台服务器，后台服务器接收到请求后，将在数据库中的用户表中查询该用户是否存在，如果不存在，则将用户名称和用户密码添加进用户表中，并且返回ok给前端；如果存在，则返回false给前端。前端弹出窗口表示注册失败

3. 产品添加模块
   创建产品是管理设备的前提，要创建产品要要用户登录成功，然后到产品添加页面点击添加，输入产品信息并点击确认，后台服务器收到后会在数据库中验证产品是否已经存在，已存在返回已近在给前端，前端显示添加失败。若不存在，则返回添加成功给前端，前台显示添加成功。其具体的

4. 设备查询模块
   设备查询是监控设备的有力手段，在通过登录用户后，点击相应的产品，客户端就会发送请求到后台的api，后台服务器收到请求并确认身份后，返回设备的列表信息给客户端展示。

5. 设备上报数据查询
   节点设备的数据上报对整个管理平台尤为重要，节点检测到事件后将数据发送到broker，broker将数据转发到订阅了设备的后台服务器中，后台服务器对收到的数据类型进行解析，进而执行进一步的工作
   根据上一节的系统模块的设计，本节给出了它们的实现。下面分别是它们实现的界面效果。
   3.2.1 用户登陆模块的实现
   下图3-7是用户登陆模块的界面图，最上面的是站点的名称，下方有两个input输入框，分别是用户名输入框和密码输入框，密码输入框最右边的是密码可是选项，点击后就可以显示输入的密码。在输入框下方有两个button，
   如图3-7所示，在用户输入用户名称和用户密码之后，后台服务器会接收到登录请求，验证正确后会返回一个用户信息给客户端，客户端收到后保存在本地，以后每次发起请求都携带这个信息，后台服务器就可以完成身份的识别。设备管理员登陆成功后的操作主页面，主页面会展示用户创建的消防产品和对应产品的数据接收量，
   3.2.2 用户注册模块的实现
   下图3-9是注册模块实现的界面图，界面上包含了用户注册的基本信息，如：用户名称、用户密码、邮箱地址等，点击“提交”按钮可以进行注册操作；用户注册成功后台会返回成功信息，客户端会有弹出提示，若失败，客户端也会有失败的弹窗提示。
   

图3-9 用户注册界面
3.2.3 产品添加模块的实现
下图3-10是产品添加的的界面图，有产品名称，产品类型，产品描述三个输入框。产品名称是产品的名字，产品类型是这类产品的类型，有烟感，气感，门磁，水浸，红外等类型可选，产品描述是对这个产品的详细说明。

图3-10 设备入库界面
3.2.4 设备查询模块的实现
下图3-11是产品列表的界面图，上面包含着产品id，产品名称，产品接入设备数量的界面图，查询产品的设备可以在这个页面的操作控制栏上，点击查询图标，客户端会发送请求给后台服务器，后台服务器受理后会返回数据给客户端，客户端收到数据后会进行跳转到设备列表。
：

3.2.5 设备上报模块的实现
在上图3-12的结果页面，点击操作栏的查询图标，同样可以跳转的设备的上报数据历史列表，下图3-13是设备报修模块实现的界面图，。

在这个界面上，用户可以看到对应的设备上报的历史数据，包含着上报数据的时间，上报数据的内容等。
3.2.6 平台下发模块的实现
在图3-12的设备页面，通过在对应设备的操作栏中的下发按键进行点击操
输入需要下发的命令，点击确定后，数据就会通过后台服务器发送到消防设备节点端。
3.3 nb-iot消防网络管理平台网络环境和整体工作展示
3.3.1管理平台网络环境
一个消防网络管理平台，最主要的功能还是对各种不同地区以及不同类型的设备进行一个统一的监控管理与维护，并在满足了基本功能需求后，提供一些对数据的应用服务和对用户的紧急提醒。所以，在各个模块的功能实现后，我们的消防网络管理平台可以通过现有的模块功能组合起起来，在管理维护设备的基础上，实现报警数据的可视化，进行风险分析。同时也能通过短信业务的紧急提醒，对报警现场提供快速的救援。下图是消防网络管理平台整体的网络通信环境：

在上图3-14中，我们可以看出我们管理平台的管理网络主要有三个部分组成，分别是在最下级的分布在各个不同地区，通过物联网连接平台的节点设备，中间对下位数据和上方数据进行整合处理的broker服务器，以及最上层与用户进行直接交互的平台端。
3.3.2整体工作展示
下面通过对上述的三个部分进行展示来构建管理平台的整体工作。
1.节点端
消防节点端的设备无非是各种各样的消防设备，诸如烟感，气感，水浸门磁等等。他们通过对环境的数据采集，如烟感的烟雾浓度，气感的co浓度，红外报警的人体触发等等，通过NB-IOT网络，用mqtt协议将采集的数据发送到中间服务器，也就是代理服务器。由于nb模块并不能获得经纬度，也就无法知道位置信息，所以我们会在平台测留有输入经纬度的接口，这样就可以在对应的设备报警的时候得知具体的位置信息了。同时，为了以防设备报警的时候信息得不到及时处理，设备也要绑定对应的手机号。以及时处理报警状况。

图3-15 节点设备添加
图3-15我们添加了一个id为00000005的smoker产品里面的一台设备。它的方位坐标是 [121.59996, 31.197646]，紧急联系的手机号则是13187867742。点击确定，设备则会在平台注册，此时真实设备并未连接到平台。
2.中间服务器
中间端的broker对数据的聚合以及引流有着不可忽视的作用，可是说是整个管理平台数据流的核心。通过emq的mqtt代理服务器，不同类型，不同产品的数据上传能够高效的到达管理平台服务器。平台下发的命令数据，如消音，改心跳时间之类的操作也可以精准的下发到特定的设备。我们将mqtt服务器放在了腾讯云的ubuntu系统上进行部署，域名是www.pensword.cn，接入端口是1883。
3.平台端
平台端作为整个系统的最上层，重要性自然不言而喻，然其核心也不过两个方面，一个是平台的设备的基本管理，设备的上下线，设备的报警，报警恢复，设备的低压以及各种各样的故障。另一个则是设备对大量采集的数据进行处理，也就是对数据的应用。下面可以通过展现设备的状态体现管理平台对设备的基本管理：

图3-16 设备状态离线
在图3-16中我们看见之前添加的00000005设备状态显示离线中。下面我们通过mqtt设备端的模拟器模拟真实的烟感设备连接到远程的平台。

上图的青色圆点表示此处发生了报警记录。此处坐标与我们添加设备是设定的坐标一致，通过对比下面的风险颜色对照条，可以很清楚的分析出次地区的消防安全程度。
3.4 本章小结
本章介绍基于nb-iot的消防网络管理平台的总体架构，数据库的设计和系统部分模块设计与实现四个方面阐述了设备管理系统的设计与实现。数据库的设计包括了用户信息表、设备表、设备上传数据表、产品表和用户与产品关系表的设计；系统模块设计主要包括了用户登陆模块、用户注册模块、产品添加模块、设备查询模块和设备上报数据查询模块的设计；本章后半部分则对网络管理平台的使用网络环境，整体工作流程进行了展示。

第4章 系统测试

4.1 系统测试
4.1.1 测试的意义
软件测试是一个程序执行的过程，目表是最大程度的地发现和改正被测软件中的错误，使软件的可靠性有所提高。软件测试作为一项在软件生命周期中非常重要和复杂的流程，最重大的意义在于保证软件的可靠性。目前，形式化方法和程序正确性证明技术还不能成为实用的方法。在未来相当长的一段时间内，软件测试仍然是保证软件可靠性的有效方法。显而易见，任何的软件工程的最终目标都是在有限的人力、物力资源下，高效率、高质量的完成项目开发。测试不充分，势必会使软件投入运行时出现一些未发现的隐藏错误，这意味着用户将承担更多的风险。过度测试浪费了大量宝贵的资源。测试结束时，即使发现错误，成本也太高。E.A的一句名言解释了这一点：“程序测试只能表明错误的存在，而不是没有错误。”可以看出，测试的目的是使软件中的缺陷低于某个值，并使输出与输入的比率最大化
4.1.2 测试的目的
测试最主要的也是最重要的使命就是：debug，找也就是出缺陷，一旦有bug遗漏没有被找出来，等到产品上线，最后推向市场之时，必然会引发诸多问题.
因此，软件测试工程师的工作或者说职责，根据软件测试的目的，可以细分为下面几个点：
1）通过用户的需求分析判断软件产品功能是否符合。
在用户提出的需求和各种功能的情况，产品没有达到或者满足的话，交付产品以及产品上面就无从提起了，因为要想软件产品能够达到交付的程度，对软件产品进行测试非常必要。

2）分析软件的代码逻辑、业务逻辑。
一千个人的心中有一千个哈姆雷特，就算参加过同样的需求分析会议，每个人的需求的理解也不尽相同，更何况一个软件相同同时开发的人数少至3-5人，多到数十人。因此，要一定程度上对工程师的代码逻辑，业务逻辑进行测试，找出其中有偏差的错误。
3）产品的易用性。
这点也很重要，用户并不是工程师和设计师，他们对产品的了解程度不可能做到像开发者这般透彻，产品的易用性不够，学习成本太高，用户接受的满意度自然就会下降，市场占有率就不要妄想了，所以测试一个产品对小白的应用型尤为重要。
4）一些其他的错误。
一些设计不合理的，功能可以被阻塞的导致产品不能正常使用的，都要发现并提出讨论，让开发人员修改完善或者备注说明！
4.1.3 软件测试方法
不了解金字塔模型的测试方案，是没有办法构建一个面面俱到的测试框架的。在以前，大多数软件公司的测试方法都是模拟用户进行测试，在用户的界面上进行各种软件测试。有的还需要工程师直接动手操作，别切开发编写配套的测试脚本。这样的测试方法是没有办法检测出代码中存在的一些隐性的问题的，应为不同的测试方法导致的测试结果是不尽相同的，能检测出来的问题自然也不一样不，下面金字塔模型测试方法重要的三个步骤。
一、单元测试
集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能
二、集成测试
集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试
三、系统测试
确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。。
4.2 部分功能测试
4.2.1通讯接口测试
通讯接口测试的目的在于测试设备节点上传的数据能否正确的发送到后台服务器上，并且被接收。可以使用真实的NB-IOT设备通过mqtt协议接入mqt服务器在转发到后台服务器中，这次测试中我们使用的是emq提供的mqtt客户端模拟真实的设备发送数据给后台。Broker的地址：www.pensword.cn,端口号是1883.客户端模拟器的设置如下图：

节点设备发送数据的时候发布信息的主题名称的格式为： 产品名/设备id 如下图：

发送的报警数据应能在客户端显示出来，如下图：

数据成功显示出来，测试成功。
4.2.2 SSM框架测试
对于后台框架的测试我们使用junit测试框架。JUnit作为一个测试框架在java ee的开发中普及度非常高。有它自己的JUnit扩展生态圈并逐渐成为源于Kent Beck的sUnit的xUnit家族中最为成功的一个。Spring框架可以直接通过maven管理器导入JUnit来进行单元测试。
在maven的 pow文件中添加spring下的junit的包，即可完成在代码层面的整合。然后创建测试类，对各个dao类进行单独的测试，可以对数据库io进行纠错，对各个service的实现类进行单独测试，可以排查业务逻辑的bug。相当的方便。
4.3 本章小结
本章节通过模拟NB节点设备上报数据到服务器，显示在客户端页面。成功模拟了真实设备使用的通讯过程的可行性。另外，通过junit 对ssm框架进行了各个部分的单元测试。

第5章 结束语

5.1 全文总结
本文给出了NB-IOT消防网络管理平台的开发过程。平台采用java语言来开发，前端，数据库采用的是Mysql。而系统中用到的用例图以及体系结构图等是采用ProcessOn绘制的。
论文首先阐述了系统开发中应用的关键技术和开发环境，如idea平台、MVC设计模式及其优缺点、spring框架运行机制和开发优点等。
此后通过对NB-IOT消防网络管理平台的需求分析，进行了总体设计和功能模块设计。
在系统的实现部分，文中重点给出了用户登陆模块、用户注册模块、产品添加模块、设备查询模块和设备数据上报模块的实现流程和实现界面。
文中最后从软件测试意义和目的为出发点，论述了如何对设备节点到客户端的端对端测试和ssm框架的单元测试。
综上所述，本文通过对IDE开发平台、vue.js、数据库mysql、MVC设计模式以及Java语言等相关知识的应用，给出了一个NB-IOT消防网络管理平台的开发实例。
5.2 课题展望
虽然已经完成了课题相关的研究和系统的设计实现工作，但是受限于技术及时间等因素，课题和系统的设计仍存在未得到很好地解决一些问题，如与现在的NB-IOT消防设备并不能十分完美的配合，下位设备只能使用mqtt协议接入，后续应该开发支持COAP协议的设备。另外前端布局任然有许多细节可以继续提高，优化性能。现在系统运行久了容易卡，后续还可以提升。