基于移动终端的智能疏散指示系统测试平台开发

PAGE7PAGE基于移动终端的智能疏散指示系统测试平台开发摘要随着现代城市化建设的发展，在城市里各种高层和大型建筑越来越多，因为高层和大型建筑内部结构复杂和内部空间巨大，内部人员到达各处安全出口需要相当长的一段路程，这使得在这些建筑内一旦发生火灾，部分前往安全出口的路线被阻断，内部受灾群众很可能因为不能分辨火灾发生的具体位置而闯入火灾现场，或者在浓烟中迷失方向不能及时逃离到各处安全出口。动态消防指示系统必然需要将整栋建筑内的烟雾传感器和消防指示牌都连接在一起，构建出一个庞大的系统，各元器件相互建立联系。如此数量庞大的元器件数量会产生众多的信息，单片机接收处理这些数据的同时应当进行保存和上传。当今物联网技术逐渐成熟，单片机可以通过合适的通讯模组来连接服务器，将所有必要的数据上传。服务器接收到单片机传来的数据后，应当在进行保存的同时对数据进行处理，甚至是与其他物联网设备进行联动。本文将重点介绍如何构建一套简化版的消防指示系统，着重消防指示系统的物联网功能部分。单片机采集并控制子器件，并连接通讯模组，搭建出MQTT协议客户端，与物联网平台的MQTT服务端连接。实现单片机上传设备数据到服务端，并可以通过服务端上开发的移动端应用远程查看数据和下发控制命令给单片机。关键词：动态消防指示系统；物联网；移动端应用；消防技术

ABSTRACTWiththedevelopmentofmodernurbanizationconstruction,therearemoreandmorehigh-risebuildingsandlarge-scalebuildingsinthecity.Becausetheinternalstructureofhigh-risebuildingsandlarge-scalebuildingsiscomplexandtheinternalspaceishuge,ittakesquitealongdistancefortheinternalpersonneltoreachtheemergencyexits,whichmakesincaseoffireinthesebuildings,someroutestotheemergencyexitsareblocked,andtheinternaldisastervictimsareverylikelytoItcanbreakintothesceneofthefirebecauseitcan'tdistinguishthespecificlocationofthefire,oritcan'tescapetotheemergencyexitsintimebecauseit'slostinthethicksmoke.Thedynamicfireindicatorboardmustconnectthesmokesensorandfireindicatorboardinthewholebuildingtogethertobuildahugesystem,andthecomponentsareconnectedwitheachother.Suchalargenumberofcomponentswillproducealargenumberofinformation.Whenreceivingandprocessingthesedata,thesingle-chipmicrocomputershouldsaveanduploadthem.Nowadays,thetechnologyofInternetofthingsisbecomingmoreandmoremature.Thesinglechipcomputercanconnecttotheserverthroughtheappropriatecommunicationmoduleanduploadallnecessarydata.Whentheserverreceivesthedatafromthesinglechipmicrocomputer,itshouldprocessthedatawhilesaving,orevenlinkwithotherInternetofthingsdevices.Thispaperwillfocusonhowtobuildasimplifiedversionofthefireindicatorsystem,focusingontheInternetofthingsfunctionofthefireindicatorsystem.TheMCUcollectsandcontrolsthesubdevices,connectsthecommunicationmodule,buildstheMQTTprotocolclient,andconnectswiththeMQTTserveroftheInternetofthingsplatform.ItcanuploadthedevicedatatotheserverandsendthecontrolcommandtotheMCUthroughthemobileapplicationdevelopedontheserver.Keywords:dynamicfireindicator;Internetofthings;mobileapplication;fire technology

目录TOC\o"1-3"\h\u27205摘要 I11221ABSTRACT II8074目录 III13744第1章绪论 141291.1课题背景及研究的意义 161661.1.1课题背景 1124301.1.2课题研究的目的和意义 2131971.2国内外研究现状 2279171.3本文完成的主要工作 316901第2章MQTT协议 491912.1MQTT简介 4277312.2MQTT控制报文结构 4224042.3MQTT控制报文 5236842.3.1CONNECT——连接服务端 5322502.3.2CONNACK——确认连接请求 9152702.3.3PUBLISH——发布信息 10169372.3.4PUBACK——发布确认 11161222.3.5PUBREC——发布收到 12273022.3.6PUBREL——发布释放 12183572.3.7PUBCOMP——发布完成 12319992.3.8SUBSCRIBE——订阅主题 12291052.3.9SUBACK——订阅确认 13102692.3.10UNSUBSCRIBE——取消订阅 1442872.3.11UNSUBACK——取消订阅确认 1458482.3.12PINGREQ——心跳请求 14229092.3.13PINGRESP——心跳响应 1451062.3.14DISCONNECT——断开连接 1566152.4MQTT操作行为 15294562.4.1状态存储 15180792.4.2网络连接 1536992.4.3服务质量等级（QoS） 1538122.4.4主题过滤器的通配符 1726490第3章物联网装置工作原理 1827368第4章装置选材及构建 1910296第5章web应用与移动应用开发 223051结论 2530363参考文献 2631522致谢 2719964附录单片机程序和web/移动端应用 28第1章绪论1.1课题背景及研究的意义1.1.1课题背景随着当代社会的不断发展，科学技术的迅猛发展，经济水平的日益繁荣，大城市里聚集了越来越多的人。低矮的房屋不再能提供足够的居住空间，越来越多的高楼大厦开始以惊人的速度拔地而起。大楼的设计也在往更多楼层、更多功能、更大的占地面积、更加复杂的布局结构的趋势发展着。然而大楼的楼层数越多，结构布局越是复杂的情况下就越是需要考虑建筑内部的消防安全[1]。在高楼或者大型建筑内部发生火灾，由于人员密集和人们缺少对火灾具体情况的认识，往往惊慌失措，难以选择正确的逃生路径，而酿成不可挽回的严重后果。近年来我国积极发展各类先进的消防技术，防患于未然，使得全国的火灾发生次数和火灾损失都显著减少。当高层火灾发生时，保证建筑内部的人员安全疏散是不可缺少的。在正常外部电源供电因火灾而切断时，如果没有专门的应急照明系统和智能疏散指示系统来指引人员疏散，很多受困人员往往会不能及时找到安全出口，从而误入火灾区域或是迷路不能及时撤离[1]。在没有指示的情况下，也可能因恐慌进而发生拥挤踩踏事故，导致更多人员伤亡，加剧救援工作的难度。综上所述，智能疏散指示系统是高层建筑消防的核心一环，一套可靠的智能疏散指示系统可以有效地保证高层建筑内人员及时疏散，从而尽可能的减少建筑物内人员的伤亡和财产损失。当前国内主要是各种静态应急指示系统占主导地位[2]，静态应急知识系统只能固定的显示当前位置最近的安全出口或者避难场所，并不能统一协调控制，监管运维也很不方便。正是因为当前广泛在高层和大型建筑内放置的消防指示牌只能静止的指向最近的安全出口，这是在制作消防指示牌的时候就设置好的。这就导致发生上述情形时，受灾群众并不清楚最近的安全出口的道路上是否发生了火灾而闯入火场，甚至可能因此而迷失方向，导致受灾人群发生拥挤踩踏事故。现今国内外开始广泛的研究动态的应急疏散指示系统,这也是当下重点研究的消防技术之一，动态指的是消防指示牌会和安装在房屋顶部的烟雾传感器联动，由单片机控制芯片计算出最近的且没有烟雾传感器报警的逃生路线，使得沿途的消防指示牌立即变更所指位置，起到智能化的疏散指示作用，这将大大的提高火灾现场受灾人员的生存几率。也就是说，动态应急疏散指示系统是在静态应急疏散指示系统的基础上，将众多的消防指示牌设备和烟雾传感器通过单片机主机连接起来就可以统一管理，实现相关的寻路算法[3]，在火灾发生时通过各烟雾传感器的报警信息，准确的计算出各消防指示牌位置处最近的无灾情逃生避难路线，从而正确的指示受灾被困人群到达安全出口。动态应急指示系统会产生大量信息，本地处理保存已经不能满足当前需求[4-5]。现今物联网技术越来越发达，把动态应急指示系统的数据上传到物联网云服务器是个不错的选择，可以远程处理大量终端上传的数据，还可以实现远程的操控及调试。更深一层可以通过物联网云服务器实现复杂的逻辑处理和多个物联网装置之间的联动。1.1.2课题研究的目的和意义本课题的研究目的在于对动态智能疏散指示系统连接物联网云服务器的研究，研究如何让由单片机主控和若干子器件构建的智能疏散指示系统通过Wi-Fi通讯模组接入网络，与各物联网云服务器建立连接。最终实现物联网云服务器接收主机上传的信息并向主机发送控制信号。在大型和高楼建筑中，会有数量相当庞大的子器件接入智能疏散指示系统，而单片机主控将这些子器件的状态数据处理后不应抛弃，但是采用本地存储又不方便智能疏散指示系统的维护和调试，因此迫切需要当下日趋成熟的物联网技术[4-5]，将单片机主控中的重要数据上传到云服务器，既方便于调试和维护设备，又可以随时远程查看设备运行状态和远程控制设备，甚至与其他物联网设备相互交互，构成规模更为庞大、功能更为复杂的系统。这就是本课题所研究的重要意义。1.2国内外研究现状在消防技术领域，智能疏散指示牌已经被广泛研究很长时间了，早期大多注重于算法上[3]，国内外对如何快速并准确的判断大楼内消防指示牌应当所指方向的研究已经十分深入，主流的算法是采用计算机图论中的Dijkstra、双向BFS、A*等最短路算法[2]。将大楼内部模型化为一个迷宫，实时根据烟雾传感器的状态更新迷宫内障碍物，并计算各个地方到安全出口的最短距离路线。随着物联网技术的不断发展，现今国内外也涌现出大量的专门提供物联网平台的云服务器服务商，这些物联网云服务使得原本有较高技术才能开发的物联网应用，变得越来越容易上手[4]。通过物联网技术将本地装置联网后，使得智能消防指示牌有了更宽广的发展空间，之后可以实现与大型城市住房智能系统从服务器端互联，从而成为智慧城市系统的一个组成部分。1.3本文完成的主要工作本文将从当下物联网技术中常用的信息传输协议——MQTT协议开始，分析它的数据包格式，并给出如何方便的实现MQTT协议客户端，从而与云服务器的MQTT协议服务端建立连接。在第三章中将阐述简单物联网装置是如何工作的，如何利用阿里云平台构建一个完整的物联网装置。第四章中正式选择主控芯片和Wi-Fi通讯模组，并接入多款传感器和LED、LCD等输出设备，搭建一个物联网装置，实现云端读取传感器参数，并控制输出设备以及设置单片机参数等。最后的第五章中将在阿里云平台中的IOT-Studio中开发一套web应用，可以远程访问网页查看设备数据和操控设备。并在web应用的基础上，通过FasionApp将web应用整合为安卓移动端App。

MQTT协议2.1MQTT简介MQTT协议[6]使用底层传输协议基础设施，它分为服务端和客户端，服务端只能有一个，而客户端可以有多个。每个通过MQTT传输的数据包称作一条应用消息，应用消息通常有不同的主题（Topic）和服务质量（QoS）。客户端是指可以收发MQTT应用信息的程序或者设备，客户端应当通过网络连接到服务端。客户端可以通过发送MQTT报文来发布应用信息给服务端，也可以订阅其他客户端发布到服务端的应用信息，对应的也可以取消订阅其他客户端的应用信息。服务端同样是一个程序或者设备，它作为发送信息的客户端和请求订阅的客户端之间的媒介，起到按照订阅规则转发各客户端应用信息的作用。服务端一般由云服务器充当，各云服务器厂商提供的物联网云服务器服务本质上就是提供了一个功能强大可靠的服务端。服务端可以接收来自各客户端的应用消息，并按照当前各客户端的订阅规则转发应用信息给订阅此信息的客户端。客户端与服务端之间建立网络连接后交互称作会话，客户端需要不断地发送心跳包应答服务端，以表明当前连接未中断。2.2MQTT控制报文结构MQTT协议规定的传输数据格式由三部分组成，包括固定报头、可变报头和有效载荷，其中第一部分是必须有的，而后两部分是根据固定报头中设定的控制报文类型来决定是否有。表2-1固定报头的格式Bit76543210Byte1MQTT控制报文类型用于控制报文类型的标志位Byte2…剩余长度MQTT控制报文类型一共有14种，依次为用于客户端请求连接服务端的CONNECT报文、用于服务端确认客户端的连接请求的CONNACK报文、用于客户端发布消息给服务端的PUBLISH报文、用于客户端向服务端发出订阅请求的SUBSCRIBE报文、用于服务端应答客户端的订阅请求的SUBACK报文、用于客户端向服务端发出取消订阅请求的UNSUBSCRIBE报文、用于服务端回应客户端的取消订阅请求的SUBACK报文、用于客户端发出心跳的PINGREQ报文、用于服务端回应客户端心跳的PINGRESP报文、用于客户端断开连接的DISCONECT报文。标志位只有在控制报文类型是PUBLISH时会使用，在其他控制报文类型下是保留位，一般是统统置零，但有部分控制报文特殊。当接收者接收到不应该存在的标志位时，应当立即断开连接。剩余长度部分从固定报头的第二个字节开始，表示当前报文剩余部分的字节数。剩余长度字段最大为4个字节，采用变长编码方案，因此每个字节可以编码128个数值和1个延续位，当延续位是1的时候表明剩余长度部分还未结束。下面给出剩余长度各字节数下的最大最小值，列为表2-2。表2-2剩余长度各字节长度下的最大最小值字节数最小值最大值10(0x00)127(0x7F)2128(0x80,0x01)16383(0xFF,0x7F)316384(0x80,0x80,0x01)2097151(0xFF,0xFF,0x7F)42097152(0x80,0x80,0x80,0x01)268435455(0xFF,0xFF,0xFF,0x7F)在固定报头后是可变报头，可变报头由报文标识符等组成，报文标识符共两个字节，其余部分因控制报文类型而异。报文标识符只有部分报文控制报文类型需要，报文标识符作用是确定客户端和服务端进行请求和应答时，能够根据报文标识符相同确定是一对。因此报文标识符必须是不能连续重复相同的，应当是采用循环递增数字作为报文标识符。有效载荷是MQTT控制报文的最后一部分，同样也只有部分类型的控制报文才需要有效载荷部分。对于PUBLISH报文来说，有效载荷就是发送的应用信息。2.3MQTT控制报文本节简单介绍MQTT控制报文中的CONNECT、CONNACK、PUBLISH、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBSCRIBE、SUBACK、UNSUBSCRIBE、UNSUBACK、PINGREQ、PINGRESP、DISCONNECT类型。2.3.1CONNECT——连接服务端客户端与网络端建立网络连接后，客户端发送的第一个报文必须是CONNECT报文。在同一个网络连接上，客户端只能发送一次CONNECT报文给服务端。服务端在客户端发送的第二个CONNECT报文时会当作协议违规处理并断开与客户端的连接。CONNECT报文的有效载荷包含了一个或多个编码的字段，包括客户端的唯一标识符、Will主题、Will消息、用户名和密码。除了客户端标识之外，其它的字段都是可选的，如果使用各商业物联网平台需要按照对应的平台确定需要有哪些字段。基于标志位来决定可变报头中是否需要包含这些字段。CONNECT的可变报文由四部分顺序组成，分别为协议名称、协议级别、连接标志、保持连接。协议名称是固定的，前两个字节是字节长度，后面紧跟着MQTT的utf-8的字符串。表2-3协议名称部分说明76543210byte1长度MSB(0)00000000byte2长度LSB(4)00000100byte3‘M’01001101byte4‘Q’01010001byte5‘T’01010100byte6‘T’01010100客户端用8位无符号值表示协议的修订版本，对于当前的最新版的MQTT协议，协议级别应当选用字段值为4（0x04),如果服务端不支持最新版MQTT协议版本，则会发送带有0x01的CONNACK报文回应客户端不支持协议版本。表2-4协议级别部分协议级别说明76543210byte7Level(4)00000100连接标志位用于指出有效载荷中有哪些字符是存在的，最低位为保留位，应当置为0，如果服务端检查到保留位非0，会立即断开客户端的连接。表2-5连接标志位部分bit76543210功能用户名标志密码标志遗嘱保留遗嘱服务质量等级遗嘱标志清理会话保留位byte801010100清理会话位确定了会话状态的处理方式。当标志位置为0时，服务端必须基于当前会话的状态恢复与客户端的通信。如果没有和这个客户端标识符关联的会话，服务端就必须创建一个新的会话。在连接断开之后，客户端和服务端必须要保存会话信息。当清理会话标志为0的会话连接断开之后，服务端必须将之后的QoS1和QoS2级别的消息保存做为会话状态的一部分，如果这些消息匹配断开连接时客户端的任何订阅。服务端也可以保存满足相同条件的QoS0级别的消息。而如果清理会话标志被设置为1，客户端和服务端必须丢弃之前的任何会话并开始一个新的会话。会话仅持续和网络连接同样长的时间。与这个会话关联的状态数据不能被任何之后的会话重用。如果需要用到QoS1和QoS2级别的消息时，为加强通信的可靠性可以选择要求保留会话状态。保留信息并不是服务端会话状态的一部分，会话结束时并不会删除保留信息。客户端的会话状态包括：1）消息已经发送给服务端，但是还没有完成确认的QoS1和QoS2级别2）已从服务端接收完毕，但是还没有完成确认的QoS2级别的消息。服务端的会话状态包括：1）会话是否存在，即便会话状态的其它部分都是空的。2）客户端的所有订阅信息。3）已经发送给客户端，可还没有完成确认的QoS1和QoS2级别的消息。4）即将传输给客户端的QoS1和QoS2级别的消息。5）已从客户端接收，但是还没有完成确认的QoS2级别的消息。6）可选，准备发送给客户端的QoS0级别的消息。连接标志中的遗嘱标志被设置为1时，表示如果连接请求被接受了遗嘱消息必须被存储在服务端并且与这个网络连接关联。之后网络连接关闭时，服务端必须发布这个遗嘱消息，除非服务端收到DISCONNECT报文时删除了这个遗嘱消息。这表明遗嘱信息会在服务端主动断开客户端连接和客户端连接超时时发送，客户端正常的通过发送DISCONNCET报文断开连接时并不会发送。只有在遗嘱标志置为1时，连接标志中的遗嘱保留和遗嘱服务质量等级这两个字段才会被服务端用到，同时有效载荷中必须包含遗嘱Topic和遗嘱Massage字段。而当遗嘱标志被设置为0时，连接标志中的遗嘱保留和遗嘱服务质量等级字段必须设置为0，并且有效载荷中不能包含WillTopic和WillMessage字段。遗嘱保留可以设置服务端在发布遗嘱时是否当作保留信息发布，遗嘱服务质量等级则是用于指定发布遗嘱时使用的服务质量等级，可选0~2，禁止设置值为3。用户名标志和密码标志分别用于设置有效载荷中是否有用户名和密码部分字段。可变报文的最后一部分是保持连接，这是一个以秒为单位的时间间隔，表示为一个16位的字，它是指在客户端传输完成一个控制报文的时刻到发送下一个报文的时刻，两者之间允许空闲的最大时间间隔。客户端负责保证控制报文发送的时间间隔不超过保持连接的值。如果没有任何其它的控制报文可以发送，客户端必须发送一个PINGREQ报文。不管保持连接的值是多少，客户端任何时候都可以发送PINGREQ报文，并且使用PINGRESP报文判断网络和服务端的活动状态。如果保持连接的值非零，并且服务端在一点五倍的保持连接时间内没有收到客户端的控制报文，它必须断开客户端的网络连接，认为网络连接已断开。客户端发送了PINGREQ报文之后，如果在合理的时间内仍没有收到PINGRESP报文，它应该关闭与服务端的网络连接。保持连接的值为零表示关闭保持连接功能。这意味着，服务端不需要因为客户端不活跃而断开连接。注意：不管保持连接的值是多少，任何时候，只要服务端认为客户端是不活跃或无响应的，可以断开客户端的连接。保持连接的实际值由应用指定的，一般是几分钟，允许的最大值是18小时12分钟15秒，也就是16位整数的最大值65535秒。CONNECT报文的有效载荷包含一个或多个以长度为前缀的字段，由可变报头中的标志决定是否包含这些字段。如果包含则必须按照指定顺序：客户端标识符，遗嘱主题，遗嘱消息，用户名，密码。服务端会使用客户端标识符识别客户端。连接服务端的每个客户端都有唯一的客户端标识符。客户端和服务端都必须使用识别两者之间的MQTT会话相关的状态。客户端标识符必须存在而且必须是CONNECT报文有效载荷的第一个字段。服务端可以允许客户端提供一个零字节的客户端标识符，如果这样做了，服务端必须将这看作特殊情况并分配唯一的客户端标识符给那个客户端。然后它必须假设客户端提供了那个唯一的客户端标识符，正常处理这个CONNECT报文。当然如果客户端提供了一个零字节的客户端标识符，它必须同时将清理会话标志设置为1，没有客户端标识符是无法保持会话重连的。如果客户端提供的客户端标识符为零字节且清理会话标志为0，服务端必须发送返回码为0x02的CONNACK报文响应客户端的CONNECT报文，然后关闭网络连接。客户端标识符之后的遗嘱主题，遗嘱消息，用户名，密码四个字段都是utf-8字符串格式，前两个字符为不包含前两个字符的字符串长度，后面紧跟着字符串信息，字符串长度可以为0~65535。最后是MQTT建立连接的响应过程，在客户端通过TCP端口与服务端建立网络连接后，如果服务端在一定时间没有收到CONNECT报文，服务端会关闭这个连接。而若服务端收到的CONNECT报文经验证后发现并不符合规范，服务端将不发送CONNACK报文直接关闭网络连接。当检查报文符合规范后，将对报文执行身份验证和授权检查。未通过身份验证和授权检查时，服务端像客户端发送异常返回值表示拒绝连接，并立即断开这个网络连接。而如果验证成功，服务端会检查是否已有相同客户端标识符的设备接入，断开与已接入设备的连接，之后执行清理对话过程或重新连接对话，最后向客户端发送表示确认链接的CONNACK报文并开始消息分发和监听连接状态。客户端可以在发送CONNECT报文后不等待接收到CONNACK报文，立即发送其他报文。但是如果服务端拒绝连接则后面接收到的报文无效。2.3.2CONNACK——确认连接请求和客户端建立连接后第一个发送的必须是CONNECT报文一样，服务端发送给客户端的第一个报文必须是CONNACK报文。如果客户端在一定时间内没有接收到服务端的CONNACK报文，客户端应当要主动断开连接。由于CONNACK报文只有可变报头部分，没有有效载荷部分，且可变包头部分是固定的只有两个字符。因而在CONNACK报文的固定报头中，剩余长度部分应当设置为0x02。表2-6CONNACK报文可变报头Bit描述76543210byte1连接确认标志0000000Xbyte2连接返回码XXXXXXXX可变报头部分两个字符分别表示连接确认标志和连接返回码。位于第一个字节的连接确认标志前7位都是保存位，必须是置为0。最低位是当前会话的标志。如果服务端收到清理会话标志为1的CONNECT报文，除了将CONNACK报文中返回值设置为0之外，还必须将CONNACK报文的当前会话位设置为0。如果服务端收到了清理对话标志为0的CONNECT报文，而且服务器当前保存着当前客户端标识符的会话状态，那么必须将CONNACK报文中的连接确认标志设置为1。如果完成对话初始化过程后，客户端发现从服务端接收到的值与预期是不相同的，那么客户端可以选择断开连接后将CONNECT报文中的清理会话标志设置为1，再次进行连接，从而初始化会话状态，清理保留在服务端的会话状态。当服务端返回的返回码是异常返回码时，必须将连接确认标识符设置为0。可变报头的第二个字节是连接返回码。接入正常的返回码为0x00，其他的返回码表示的异常含义见表2-7。如果表中的返回值都不合适，则服务端应直接关闭连接不需要发送CONNACK报文。表2-7CONNACK报文连接返回值值返回码响应描述0连接已接受连接已被服务端接受1连接已拒绝，不支持的协议版本服务端不支持客户端请求的MQTT协议级别2连接已拒绝，不合格的客户端标识符客户端标识符是正确的UTF-8编码，但服务端不允许使用3连接已拒绝，服务端不可用网络连接已建立，但MQTT服务不可用4连接已拒绝，无效的用户名或密码用户名或密码的数据格式无效5连接已拒绝，未授权客户端未被授权连接到此服务器6-255保留2.3.3PUBLISH——发布信息PUBLISH报文用于从客户端向服务器或者服务器向客户端传输一个应用信息。需要注意PUBLISH报文的固定报头是有标志位的，具体位置功能见表2-8。表2-8PUBLISH报文固定报头Bit描述76543210byte1连接确认标志MQTT控制报文类型(3)DUPQoSRETAINbyte2...剩余长度第一个标志为DUP重发标志，用于QoS大于0时候表示当前PUBLISH报文可能是一个重发报文。在接受端收到DUP位为1的PUBLISH报文时应当检查确认是否已经收到过此PUBLISH的信息。第二个标志为服务质量等级QoS，QoS必须是取0~2范围的值，不可以取为3。QoS取0时表示应用信息只会发送一次，无论是否接收到；QoS取1时表示应用信息可能发送多次给接受端多次，直到接受端返回消息确认已经接收到应用信息；QoS取2时表示发送端将可能发送多次，且会确认接受端只收到了一次。最后一个标志为保留标志位，当保留标志位置为1的时候，服务端必须存储这个应用信息和它的服务质量等级，这样以便于分发给新的订阅者。意味着这条应用信息将会保留到服务端，当有一个新的客户端订阅此条Topic时服务端将把最新的应用信息发送给客户端，每个Topic下只能有保留一条应用信息，当有新的设有保留标志位的PUBLISH报文时将会刷新此Topic下的保留信息。客户端可以发送有效载荷为空且带有保留标志位的PUBLISH报文，用于删除服务端上保留的应用信息，这样新客户端订阅此Topic时就不会在接收到保留信息。可变报头按顺序包含主题名和报文标识符。主题名即为Topic，用于识别有效载荷应当发布在哪一个Topic中，然后分发给订阅这个Topic的客户端们。主题名部分采用utf-8字符串形式。当QoS等级大于0时，必须有报文标识符部分，用于匹配之后的PUBACK或PUBREC报文。PUBLISH报文的有效载荷部分就是将要发布的应用信息，包含长度为0的有效载荷是合法的，主要应用就是用于删除服务端上的保留信息。表2-9PUBLISH报文的预期响应服务质量等级预期响应QoS0无响应QoS1PUBACK报文QoS2PUBREC报文2.3.4PUBACK——发布确认PUBACK报文是对QoS1等级的PUBLISH报文的接受端响应。PUBACK报文没有有效载荷部分，可变报头部分也只有报文标识符字段。表2-10PUBACK报文可变报头Bit描述76543210byte1报文标识符MSBXXXXXXXXbyte2报文标识符LSBXXXXXXXX2.3.5PUBREC——发布收到PUBREC报文是对QoS等级2的PUBLISH报文的接受端响应。它是QoS2等级下信息传递过程的第二个报文。和PUBACK报文相同，PUBREC报文没有有效载荷且可变报头只有报文标识符这个两字节字段，即为可变报头部分见表2-10。2.3.6PUBREL——发布释放PUBREL报文是对QoS等级2的PUBREC报文的发送端响应。它是QoS2等级下信息传递过程的第三个报文。和上面的PUBACK和PUBREC这类响应报文相同，PUBREC报文没有有效载荷且可变报头只有报文标识符这个两字节字段，即为可变报头部分见表2-10。2.3.7PUBCOMP——发布完成PUBCOMP报文是对QoS等级2的PUBREL报文的接受端响应。它是QoS2等级下信息传递过程的第四个也是最后一个报文。和上面的PUBACK等响应报文相同，PUBCOMP报文没有有效载荷且可变报头只有报文标识符这个两字节字段，即为可变报头部分见表2-10。2.3.8SUBSCRIBE——订阅主题SUBSCRIBE报文用于客户端向服务端发送订阅申请，可以申请订阅一个或多个主题（Topic）。SUBSCRIBE报文也会为每个订阅指定最大QoS等级，服务端根据这个发送应用消息给客户端。须要注意的是SUBSCRIBE报文的固定报头标志位都是保留位，但并非要求全部置为0，而是必须设置为0010。服务端在接收到其他标志位时会认定为非法报文而关闭连接。SUBSCRIBE报文的可变包头部分由报文标识符字段构成，与表2-10中相同。有效载荷中包含了一个主题过滤器列表，用utf-8字符串格式表示，它表示了客户端想要订阅的主题。主题过滤器一般支持使用通配符，如果服务端不支持通配符必须拒绝存在通配符的所有主题过滤器。每一个主题过滤器后面会紧跟着一个字节，字节的后两位用于表示此主题过滤器的最大允许QoS等级，字节剩余位是保留位，应当全部设置为0，如果服务端发现保留位或者QoS值非法，会立即断开与客户端的连接。有效载荷部分可以有一个或多个主题过滤器与QoS字节组合，有效载荷不能为空。表2-11SUBSCRIBE报文有效载荷格式Bit描述76543210byte1报文标识符MSBXXXXXXXXbyte2报文标识符LSBXXXXXXXXByte3...N主题过滤器XByteN+1QoS等级000000XX...(更多主题过滤器+QoS等级)...当服务端收到客户端发出的SUBSCRIBE报文时，必须使用SUBACK报文回应客户端，且SUBACK中的报文标识符必须与客户端发送的SUBSCRIBE报文中的报文标识符相同。当服务端收到的SUBSCRIBE报文中的主题过滤器与当前已有的主题过滤器相同时，服务端必须使用新的订阅彻底替代原有的订阅信息，这个订阅相关的Topic的保留信息会重新发送给客户端。2.3.9SUBACK——订阅确认SUBACK报文用于服务端回应客户端发出的SUBSCRIBE报文，SUBACK的可变报头内包含接收到的SUBSCRIBE报文中的报文标识符，有效载荷包含一个返回码清单，SUBSCRIBE中的每个主题过滤器都对应着一个返回码，返回码的顺序必须和SUBSCRIBE中的主题过滤器的顺序相同。每个返回码仅有四个有效返回码值，0x00表示成功且QoS最大为0，0x01表示成功且QoS最大为1，0x02表示成功且QoS最大为2，0x80表示失败，其他的返回码值都是保留值，不能使用。服务端可以授予比客户端在SUBSCRIBE报文中最大QoS值小的QoS值。2.3.10UNSUBSCRIBE——取消订阅UNSUBSCRIBE报文用于客户端发送给服务端申请取消订阅主题。与SUBSCRIBE报文相同，固定报头中的标志位必须设置为0010，其他的标志位值都是不合法的，服务端会立即关闭网络连接。UNSUBSCRIBE报文的可变报头只有报文标识符部分，具体与表2-10相同。UNSUBSCRIBE报文的有效载荷包含一个或多个主题过滤器，每个主题过滤器都用utf-8字符串表示，多个主题过滤器应当连续排列。服务端接收到UNSUBSCRIBE报文时，必须与服务端持有的这个客户端中的已有主题过滤器相比较，如果有与之完全匹配的主题过滤器，那么将这个主题过滤器删除，否则不进行任何操作。一旦主题过滤器被删除，服务端将不再分发这个主题过滤器的新消息给客户端，但会继续分发完已经给客户端发送的QoS1和QoS2消息，且可以选择是否分发已缓存将要发送给客户端的信息。2.3.11UNSUBACK——取消订阅确认UNSUBACK报文用于服务端回应客户端发送的UNSUBSCRIBE报文，UNSUBACK报文没有有效载荷，且可变报头只有报文标识符部分。2.3.12PINGREQ——心跳请求在客户端没有其他报文需要发送的情况下，必须向服务端发送PINGREQ报文，用于保持与服务器的连接，而不导致服务端因为长时间没有收到任何报文，时间超出保持连接时间而主动断开与客户端的连接。客户端还可以通过发送PINGREQ报文后是否接收到PINGRESP报文来确定和服务端的连接是否正常。PINGREQ报文只有固定报头，没有可变报头和有效载荷部分。2.3.13PINGRESP——心跳响应当服务端接收到客户端发送的PINGREQ报文时，应当立即发送PINGRESP报文给客户端，表明服务端连接和工作正常。和PINGREQ报文一样，PINGRESP报文没有可变报头和有效载荷部分。2.3.14DISCONNECT——断开连接DISCONNECT报文用于客户端向服务端报告正常断开连接，这是客户端发给服务端的最后一个报文。DISCONNECT报文没有可变报头和有效载荷部分。在客户端发送DISCONNECT报文之后，不能再发送任何报文且必须断开与服务端的网络连接。在服务端接收到客户端发送的DISCONNCET报文后，必须舍弃任何此连接的遗嘱信息并关闭与客户端的网络连接。2.4MQTT操作行为2.4.1状态存储MQTT客户端和服务端应当在整个对话期间存储对话状态，会话状态的存储时间必须至少长于它活跃的网络连接。长时间的会话状态可能会占有很大的存储空间，且需要删除长远时间的会话状态，可以按照功能的需求，选择把会话状态存储到何种存储器下。2.4.2网络连接MQTT协议需要建立在有序、可靠、且可双向传输字节流的基础传输层上，一般选择为TCP/IP协议，TLS协议和WebSocket协议也是支持的。MQTT的TLS和非TLS的TCP通信端口为8883和1883。2.4.3服务质量等级（QoS）QoS分为三个等级，分别为最多分发一次的QoS0、至少分发一次的QoS1以及仅分发一次的QoS2。QoS0等级是发送方只向接收方发送依次PUBLISH报文，无论接收方是否成功接收到。QoS1等级为了使接收方至少接收到一次，需要接收方在接收到PUBLISH报文后发送PUBACK报文，回应已经接收到PUBLISH报文。当发送方未接收到PUBACK报文前将不断地发送PUBLISH报文，因而接收方可能接收到多次相同的PUBLISH报文。接收方发送PUBACK报文后，必须把收到的含相同报文标识符的PUBLISH报文当作同一条应用信息。在接受端发送PUBACK报文并处理当前PUBLISH后，可能因发送端没有及时收到PUBACK报文而再次发送PUBLISH给接收方，此时就导致接收端收到了并处理了多条相同的PUBLISH报文。而发送端在收到一次PUBACK报文后，多余的PUBACK报文可以被发送端轻松过滤不做任何事情，因而发送端并不受影响。QoS2等级则是需要保证接收端处理有且仅有一次应用信息，不能重复处理到多条相同的应用信息。采用连续两次的问答模式保证信息传递的可靠性，第一轮问答同QoS1等级，保障了接受端已经至少接收到了一次PUBLISH报文。为了解决上面QoS1等级下出现接受端接收并处理多条PUBLISH报文的问题，需要让确认接收到应用信息的报文与发送端第一次发送的报文不同，这样就可以分辨出到底是发送端发送了新的相同报文标识符的应用信息还是重复发送了旧的应用信息。最佳且最简单的办法就是重复问答两轮，在第一轮接受端回应发送端PUBREC报文后开始等待发送端的PUBREL报文，这之后可能发送端发送了多次PUBREL给接受端，但是接受端一旦收到PUBREL报文，立即会处理当前应用信息并发送PUBCOMP报文。与之不同的是，此时因发送端未收到PUBCOMP报文，而收到重复的PUBREL报文就可以明确的得知发送端是未成功接受到PUBCOMP报文，重发PUBCOMP报文就可以了，不再此处理应用信息。因为如果发送端是接收到了PUBCOMP报文而发送了新的应用信息，则是发送的PUBLISH报文，并非PUBREL报文。简单明了的解决了接受端可能重复处理多条相同应用信息的问题。虽然很好的解决了QoS1中重复处理相同的应用信息的问题，但是QoS2模式下需要处理的信息次数明显增多，成功发送一次应用信息至少要比QoS1模式下多出一倍传递次数，且至少为QoS0模式下的4倍传递次数，因而一般是不采用的。图2-1QoS0逻辑框图图2-2QoS1逻辑框图图2-3QoS2逻辑框图2.4.4主题过滤器的通配符各个主题采用文件系统一样的分级管理形式，但又并非完全与文件系统相同，因为像/monitor/Clients这样的是一个完整的主题名，而并非是一个位于monitor文件夹下的主题名为Clients的主题。所以/就是一个合法的主题名，/作为层级符号，将不同主题名根据/号归类方便通配符匹配，连续的多个/符号表示它们之间仅有零长度的主题层级。#号代表多层通配符，它必须位于主题过滤器的末尾，而且必须独自为一个主题层级，它表示匹配它的父级和所有的当前级和子级。+号代表单层通配符，+号也必须独自为一个层级，但是并不限于主题过滤器的末尾，可以出现在任意层级处，且可以出现多次，并于#通配符一同使用。它表示匹配当前所有层级。须要注意的是$号开头的主题并不能被通配符匹配到，除非主题过滤器的开头也是$号。服务端常采用$SYS/为开头的主题用作服务器的特殊信息和控制接口等，因而客户端不能设置$为开头的主题。第3章物联网装置工作原理利用MQTT协议搭建物联网装置，基本组成有客户端和服务端。客户端常有两种方案搭建，一种是用主控芯片搭配通讯模组，另一种则是直接二次开发通讯模组，省去了主控芯片和相互传递信息的步骤[7]。这两种方案各有好坏，带有主控芯片的方案通常可以按照应用要求自行选择合适的芯片，且只需要留有一个串口与通讯模组相互通信就可以，这就带来了很大的灵活性，也方便开发人员使用自己擅长的控制芯片。而采用二次开发通讯模组是直接省去了主控芯片与通讯模组之间串口传递信息的部分，但是模组工作量加剧，不单单要完成通讯的任务还需要运行本地任务，这适用于小型应用，还有个不足则是开发人员可能需要学习通讯模组二次开发的相关知识，了解模组给出的各项API[8]。当采用主控芯片搭配通讯模组的方案时，主控芯片运行本地程序，负责采集传感器信息和执行云端下发的命令，执行一些不需要大量运算的即时性任务。所有必要的数据都通过通讯模组上传到服务端。通讯模组可以有多种选择，可以是Wi-Fi协议的，同样也可以是现在流行的NB-IOT、LoRa协议，这可以根据物联网应用的实际需求来确定，通讯模组一般采用UART串口与控制芯片传输信息。服务端可以用服务器自行搭建MQTT协议，也可以使用当下各大物联网服务器厂商提供的开发平台快速搭建服务端。不过在各种平台上搭建的服务端会受到平台的各种限制，比如不支持保留消息、遗嘱、QoS2等等。在服务端基础上开发应用可以采用两种方案[8]。第一种是让应用本身成为一个MQTT客户端，订阅来自目标设备客户端的各项应用信息，可这种方案并不能很好的完成下发控制等任务。第二种是现在较为成熟和流行的的方案，直接与服务端建立联系，这大体分为有两种，一个是通过API连接服务端从而获取目标数据和下发控制命令，另一个是下发控制命令采用API的方式，而获取数据则采用AMPQ等服务端订阅，服务端直接将接收到的数据转发到应用[9-10]。第4章装置选材及构建考虑到智能疏散指示系统通常需要连接数量庞大的烟雾传感器和消防指示牌设备，通常会采用主从机的模式，主机负责实时计算各消防指示牌的方向和上传数据接收命令，而从机则是负责接收所在位置附近的传感器和消防指示牌的数据上传主机，并且接收主机的各项命令更新消防指示牌的状态。将这个实际庞大的系统简化为单片机作为主控，配合Wi-Fi协议通讯模组的小型物联网装置，单片机上连接多种传感器和可控设备，来模拟实际的烟雾传感器和消防指示牌等设备。图4-1STCA8K64S4A12单片机—LQFP64封装单片机主控选用STC公司生产的STC8A8K64S4A12单片机，这是一款加强的51内核单片机，STC8系列在51内核的基础上显著提高了指令执行速度，由传统的12T机器周期降至1T。更为强悍的是STC8系列单片机芯片内部集成了大量的外设，例如SPI、I2C、12位ADC、高速PWM等等，更是有着恐怖的4个串口。虽然这款单片机性能并不强大，但是已经能很好的满足当前应用的需要。图4-2EMW-3080Wi-Fi协议通讯模组Wi-Fi协议的通讯模组选用阿里云官方推荐的上海庆科公司推出的EMW-3080模组，功能强大且可靠稳定。且最为重要的是EMW-3080模组自带MQTT协议的客户端功能，单片机只需要串口发送MQTT相关的AT指令集就可以轻松在通讯模组上搭建客户端。图4-3阿里云物联网平台服务端采用阿里云的物联网平台，阿里云提供的物联网平台功能强大、稳定可靠，而且贴心的为水平较差的开发者准备了IOT-STUDIO功能，可以采用可视化拖拽模块的方式完成web应用开发和服务端逻辑应用开发。这个功能虽然性能和可操作性上远不足原生开发，但是可以大大缩短简单应用的开发周期和降低对开发者的能力要求。图4-4DS18B20水温传感器图4-5GY-25方位角传感器传感器选用常见的几种传感器，有可以测量-55~125℃的DS18B20水温传感器，还有可以随时校正的GY-25方位角传感器。可控设备选用三个红色LED灯和LCD1602液晶显示屏，另外将单片机自身也设为可控设备，可以控制单片机离线运行和重启。图4-6LCD1602液晶显示屏图4-7简化的单片机程序框图单片机部分需要完成三部分任务，一是定时采集传感器信息，二是执行简单分析数据，如判断水温传感器温度是否越界，产生高低温报警等，三是上传设备数据和报警信息，并接收服务端下发的控制信息。完整的程序见附件，图4-7给出了简化的程序流程图。装置整体由STC8A8K64S4A12开发板和EMW-3080开发板搭建，通过杜邦线和排针连接。DS18B20、GY-25和LCD1602都接在STC8A8K64S4A12开发板上，三个LED灯则是使用EMW-3080开发板上的现有的。图4-8装置俯视图

第5章web应用与移动应用开发图5-1App界面—DS18B20水温传感器部分图5-2App界面—LED灯部分利用阿里云的IOT-STUDIO开发平台可以简单快速的开发服务端web应用，将当前搭建好的物联网设备可以分为五个功能部分，分别是DS18B20水温传感器部分、LED灯部分、LCD1602液晶显示屏部分、GY-25方位传感器部分、MCU控制部分。在开发web应用后，通过FasionApp软件将所有网页集成为一个安卓App，完成移动应用的快速开发。DS18B20水温传感器部分设计为两个部分，上方用仪表盘显示传感器输出的温度值，下方用信号灯显示单片机上传的温度过高和温度过低报警信息。LED灯部分设计为可通过三个开关控制对应LED灯亮灭，查看开关位置也能得知对应的LED灯的当前状态，最下方设置一个开关用于查看和设定是否用单片机中的IAP功能，将LED灯的状态保存在EEPROM中，这样断电重启后可以让LED灯继续保持之前的状态。LCD1602液晶显示屏部分设有文本输入框和选择框，可选择在LCD1602的第一行或第二行输出字符串，字符串最大长度设置为16个，限制不能输入更多的字符。选定行号并写好字符串后点击发送按钮，就可以向单片机下发控制指令，输出字符串到LCD1602液晶显示屏的指定位置。GY-25方位传感器部分上方显示航向角、俯仰角、横滚角，下方设有校正功能，可以下发命令给单片机，命令其发送校正命令给GY-25传感器，校正功能有校正航向角、校正俯仰角和横滚角。图5-3App界面—LCD1602液晶显示屏部分图5-4App界面—GY-25方位传感器部分MCU控制部分设有两个功能，一个是通过调用在阿里云物联网平台上的API得到最近一次设备上下线的时间，另一个是下发控制指令让单片机主动断开连接并离线运行，或者是让单片机重启。在每个web应用页面的最上方都标有设备状态，用于显示当前单片机客户端有没有连接在线。设备处于离线状态时，所有web应用界面会背景色变为灰色，并在最上方显示设备状态为离线，具体可见图5-6。图5-5App界面—LCD160