采用MQTT协议实现Android消息推送.docx

采用MQTT协议实现Android消息推送.docx

《采用MQTT协议实现Android消息推送.docx》由会员分享，可在线阅读，更多相关《采用MQTT协议实现Android消息推送.docx（19页珍藏版）》请在冰豆网上搜索。

采用MQTT协议实现Android消息推送

采用MQTT协议实现Android消息推送（选型）

解决方案分析：

方案1、使用GCM服务（GoogleCloudMessaging）

简介：

Google推出的云消息服务，即第二代的G2DM。

优点：

Google提供的服务、原生、简单，无需实现和部署服务端。

缺点：

Android版本限制（必须大于2.2版本），该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。

方案2、使用XMPP协议（Openfire+Spark+Smack）

简介：

基于XML协议的通讯协议，前身是Jabber，目前已由IETF国际标准化组织完成了标准化工作。

优点：

协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。

缺点：

协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。

方案3、使用MQTT协议（更多信息见：

http:

//mqtt.org/）

简介：

轻量级的、基于代理的“发布/订阅”模式的消息传输协议。

优点：

协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域（参考：

http:

//mqtt.org/software），且已有C++版的服务端组件rsmb。

缺点：

不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。

方案4、使用HTTP轮循方式

简介：

定时向HTTP服务端接口（WebServiceAPI）获取最新消息。

优点：

实现简单、可控性强，部署硬件成本低。

缺点：

实时性差。

------------------------------------------------

（选择）推荐方案：

  推荐使用MQTT协议的方案进行实现，主要原因是：

MQTT最快速，也最省流量（固定头长度仅为2字节），且

极易扩展，适合二次开发。

  消息分发服务：

推荐使用activieMQ，主要原因activieMQ是分布式的具有高性能可扩展性，是apache的下

的项目有很好的团队维护升级。

-----------------------ActiveMQ,mqtt部分资料--------------------

ApacheApollo1.0，新一代ActiveMQ消息系统

Apollo的特性如下：

支持Stomp1.0和Stomp1.1协议

主题和队列

队列浏览器

主题持久订阅

镜像队列

可靠的消息传递

消息过期和交换

消息选择器

JAAS验证

基于ACL的授权

支持SSL/TLS，证书验证

RESTManagementAPI

详细信息参阅：

http:

//activemq.apache.org/apollo/blog/releases/release-1.0.html

下载：

http:

//activemq.apache.org/apollo/download.html

文档：

http:

//activemq.apache.org/apoll...site/documentation/

消息传输协议MQTT

MQ遥测传输（MQTT）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。

这些特点使它适用于受限环境。

例如，但不仅限于此：

网络代价昂贵，带宽低、不可靠。

在嵌入设备中运行，处理器和内存资源有限。

该协议的特点有：

使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。

对负载内容屏蔽的消息传输。

使用TCP/IP提供网络连接。

有三种消息发布服务质量：

“至多一次”，消息发布完全依赖底层TCP/IP网络。

会发生消息丢失或重复。

这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。

“至少一次”，确保消息到达，但消息重复可能会发生。

“只有一次”，确保消息到达一次。

这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。

小型传输，开销很小（固定长度的头部是2字节），协议交换最小化，以降低网络流量。

使用LastWill和Testament特性通知有关各方客户端异常中断的机制。

详细信息参阅：

：

http:

//mqtt.org/

下载：

http:

//mqtt.org/software

文档：

http:

//mqtt.org/documentation

简单demo

packagecom.pig.test.mqtt;

importcom.ibm.mqtt.MqttClient;

importcom.ibm.mqtt.MqttException;

importcom.ibm.mqtt.MqttSimpleCallback;

publicclassSubscribeClient{

privatefinalstaticStringCONNECTION_STRING="tcp:

//192.168.1.60:

1883";

privatefinalstaticbooleanCLEAN_START=true;

privatefinalstaticshortKEEP_ALIVE=30;//低耗网络，但是又需要及时获取数据，心跳30s

privatefinalstaticStringCLIENT_ID="client1";

privatefinalstaticString[]TOPICS={

"Test/TestTopics/Topic1",

"Test/TestTopics/Topic2",

"Test/TestTopics/Topic3",

"tokudu/client1"

};

privatefinalstaticint[]QOS_VALUES={0,0,2,0};

//////////////////

privateMqttClientmqttClient=null;

publicSubscribeClient（Stringi）{

try{

mqttClient=newMqttClient（CONNECTION_STRING）;

SimpleCallbackHandlersimpleCallbackHandler=newSimpleCallbackHandler（）;

mqttClient.registerSimpleHandler（simpleCallbackHandler）;//注册接收消息方法

mqttClient.connect（CLIENT_ID+i,CLEAN_START,KEEP_ALIVE）;

mqttClient.subscribe（TOPICS,QOS_VALUES）;//订阅接主题

/**

*完成订阅后，可以增加心跳，保持网络通畅，也可以发布自己的消息

*/

mqttClient.publish（PUBLISH_TOPICS,"keepalive".getBytes（）,QOS_VALUES[0],true）;

}catch（MqttExceptione）{

//TODOAuto-generatedcatchblock

e.printStackTrace（）;

}

}

/**

*简单回调函数，处理client接收到的主题消息

*@authorpig

*/

classSimpleCallbackHandlerimplementsMqttSimpleCallback{

/**

*当客户机和broker意外断开时触发

*可以再此处理重新订阅

*/

@Override

publicvoidconnectionLost（）throwsException{

//TODOAuto-generatedmethodstub

System.out.println（"客户机和broker已经断开"）;

}

/**

*客户端订阅消息后，该方法负责回调接收处理消息

*/

@Override

publicvoidpublishArrived（StringtopicName,byte[]payload,intQos,booleanretained）

throwsException{

//TODOAuto-generatedmethodstub

System.out.println（"订阅主题:

"+topicName）;

System.out.println（"消息数据:

"+newString（payload））;

System.out.println（"消息级别（0,1,2）:

"+Qos）;

System.out.println（"是否是实时发送的消息（false=实时，true=服务器上保留的最后消息）:

"+retained）;

}

}

/**

*高级回调

*@authorpig

*/

classAdvancedCallbackHandlerimplementsMqttSimpleCallback{

@Override

publicvoidconnectionLost（）throwsException{

//TODOAuto-generatedmethodstub

}

@Override

publicvoidpublishArrived（Stringarg0,byte[]arg1,intarg2,

booleanarg3）throwsException{

//TODOAuto-generatedmethodstub

}

}

/**

*@paramargs

*/

publicstaticvoidmain（String[]args）{

//TODOAuto-generatedmethodstub

newSubscribeClient（""+i）;

}

}

电厂分散控制系统故障分析与处理

作者：

单位：

摘要：

归纳、分析了电厂DCS系统出现的故障原因，对故障处理的过程及注意事项进行了说明。

为提高分散控制系统可靠性，从管理角度提出了一些预防措施建议，供参考。

关键词：

DCS　故障统计分析　预防措施

随着机组增多、容量增加和老机组自动化化改造的完成，分散控制系统以其系统和网络结构的先进性、控制软件功能的灵活性、人机接口系统的直观性、工程设计和维护的方便性以及通讯系统的开放性等特点，在电力生产过程中得到了广泛应用，其功能在DAS、MCS、BMS、SCS、DEH系统成功应用的基础上，正逐步向MEH、BPC、ETS和ECS方向扩展。

但与此同时，分散控制系统对机组安全经济运行的影响也在逐渐增加；因此如何提高分散控制系统的可靠性和故障后迅速判断原因的能力，对机组的安全经济运行至关重要。

本文通过对浙江电网机组分散控制系统运行中发生的几个比较典型故障案例的分析处理，归纳出提高分散系统的可靠性的几点建议，供同行参考。

1　考核故障统计

浙江省电力行业所属机组，目前在线运行的分散控制系统，有TELEPERM-ME、MOD300，INFI-90，NETWORK-6000，MACSⅠ和MACS-Ⅱ，XDPS-400，A/I。

DEH有TOSAMAP-GS/C800，DEH-IIIA等系统。

笔者根据各电厂安全简报记载，将近几年因分散控制系统异常而引起的机组故障次数及定性统计于表1

表1　热工考核故障定性统计

2　热工考核故障原因分析与处理

根据表1统计，结合笔者参加现场事故原因分析查找过程了解到的情况，下面将分散控制系统异常（浙江省电力行业范围内）而引起上述机组设备二类及以上故障中的典型案例分类浅析如下：

2.1　测量模件故障典型案例分析

测量模件“异常”引起的机组跳炉、跳机故障占故障比例较高，但相对来讲故障原因的分析查找和处理比较容易，根据故障现象、故障首出信号和SOE记录，通过分析判断和试验，通常能较快的查出“异常”模件。

这种“异常”模件有硬性故障和软性故障二种，硬性故障只能通过更换有问题模件，才能恢复该系统正常运行；而软性故障通过对模件复位或初始化，系统一般能恢复正常。

比较典型的案例有三种：

（1）未冗余配置的输入/输出信号模件异常引起机组故障。

如有台130MW机组正常运行中突然跳机，故障首出信号为“轴向位移大Ⅱ”，经现场检查，跳机前后有关参数均无异常，轴向位移实际运行中未达到报警值保护动作值，本特利装置也未发讯，但LPC模件却有报警且发出了跳机指令。

因此分析判断跳机原因为DEH主保护中的LPC模件故障引起，更换LPC模件后没有再发生类似故障。

另一台600MW机组，运行中汽机备用盘上“汽机轴承振动高”、“汽机跳闸”报警，同时汽机高、中压主汽门和调门关闭，发电机逆功率保护动作跳闸；随即高低压旁路快开，磨煤机B跳闸，锅炉因“汽包水位低低”MFT。

经查原因系＃1高压调门因阀位变送器和控制模件异常，使调门出现大幅度晃动直至故障全关，过程中引起＃1轴承振动高高保护动作跳机。

更换＃1高压调门阀位控制卡和阀位变送器后，机组启动并网，恢复正常运行。

（2）冗余输入信号未分模件配置，当模件故障时引起机组跳闸：

如有一台600MW机组运行中汽机跳闸，随即高低压旁路快开，磨煤机B和D相继跳闸，锅炉因“炉膛压力低低”MFT。

当时因系统负荷紧张，根据SOE及DEH内部故障记录，初步判断的跳闸原因而强制汽机应力保护后恢复机组运行。

二日后机组再次跳闸，全面查找分析后，确认2次机组跳闸原因均系DEH系统三路“安全油压力低”信号共用一模件，当该模件异常时导致汽轮机跳闸，更换故障模件后机组并网恢复运行。

另一台200MW机组运行中，汽包水位高Ⅰ值，Ⅱ值相继报警后MFT保护动作停炉。

查看CRT上汽包水位，2点显示300MM，另1点与电接点水位计显示都正常。

进一步检查显示300MM的2点汽包水位信号共用的模件故障，更换模件后系统恢复正常。

针对此类故障，事后热工所采取的主要反事故措施，是在检修中有针对性地对冗余的输入信号的布置进行检查，尽可能地进行分模件处理。

（3）一块I/O模件损坏，引起其它I/O模件及对应的主模件故障：

如有台机组“CCS控制模件故障"及“一次风压高低”报警的同时，CRT上所有磨煤机出口温度、电流、给煤机煤量反馈显示和总煤量百分比、氧量反馈，燃料主控BTU输出消失，F磨跳闸（首出信号为“一次风量低”）。

4分钟后CRT上磨煤机其它相关参数也失去且状态变白色，运行人员手动MFT（当时负荷410MW）。

经检查电子室制粉系统过程控制站（PCU01柜MOD4）的电源电压及处理模件底板正常，二块MFP模件死机且相关的一块CSI模件（（模位1-5-3，有关F磨CCS参数）故障报警，拔出检查发现其5VDC逻辑电源输入回路、第4输出通道、连接MFP的I/O扩展总线电路有元件烧坏（由于输出通道至BCS（24VDC），因此不存在外电串入损坏元件的可能）。

经复位二块死机的MFP模件，更换故障的CSI模件后系统恢复正常。

根据软报警记录和检查分析，故障原因是CSI模件先故障，在该模件故障过程中引起电压波动或I/O扩展总线故障，导致其它I/O模件无法与主模件MFP03通讯而故障，信号保持原值，最终导致主模件MFP03故障（所带A-F磨煤机CCS参数），CRT上相关的监视参数全部失去且呈白色。

2.2　主控制器故障案例分析

由于重要系统的主控制器冗余配置，大大减少了主控制器“异常”引发机组跳闸的次数。

主控制器“异常”多数为软故障，通过复位或初始化能恢复其正常工作，但也有少数引起机组跳闸，多发生在双机切换不成功时，如：

（1）有台机组运行人员发现电接点水位计显示下降，调整给泵转速无效，而CRT上汽包水位保持不变。

当电接点水位计分别下降至甲-300mm，乙-250mm，并继续下降且汽包水位低信号未发，MFT未动作情况下，值长令手动停炉停机，此时CRT上调节给水调整门无效，就地关闭调整门；停运给泵无效，汽包水位急剧上升，开启事故放水门，甲、丙给泵开关室就地分闸，油泵不能投运。

故障原因是给水操作站运行DPU死机，备用DPU不能自启动引起。

事后热工对给泵、引风、送风进行了分站控制，并增设故障软手操。

（2）有台机组运行中空预器甲、乙挡板突然关闭，炉膛压力高MFT动作停炉；经查原因是风烟系统I/O站DPU发生异常，工作机向备份机自动切换不成功引起。

事后电厂人员将空预器烟气挡板甲1、乙1和甲2、乙2两组控制指令分离，分别接至不同的控制站进行控制，防止类似故障再次发生。

2.3　DAS系统异常案例分析

DAS系统是构成自动和保护系统的基础，但由于受到自身及接地系统的可靠性、现场磁场干扰和安装调试质量的影响，DAS信号值瞬间较大幅度变化而导致保护系统误动，甚至机组误跳闸故障在我省也有多次发生，比较典型的这类故障有：

（1）模拟量信号漂移：

为了消除DCS系统抗无线电干扰能力差的缺陷，有的DCS厂家对所有的模拟量输入通道加装了隔离器，但由此带来部分热电偶和热电阻通道易电荷积累，引起信号无规律的漂移，当漂移越限时则导致保护系统误动作。

我省曾有三台机组发生此类情况（二次引起送风机一侧马达线圈温度信号向上漂移跳闸送风机，联跳引风机对应侧），但往往只要松一下端子板接线（或拆下接线与地碰一下）再重新接上，信号就恢复了正常。

开始热工人员认为是端子柜接地不好或者I/O屏蔽接线不好引起，但处理后问题依旧。

厂家多次派专家到现场处理也未能解决问题。

后在机组检修期间对系统的接地进行了彻底改造，拆除原来连接到电缆桥架的AC、DC接地电缆；柜内的所有备用电缆全部通过导线接地；UPS至DCS电源间增加1台20kVA的隔离变压器，专门用于系统供电，且隔离变压器的输出端N线与接地线相连，接地线直接连接机柜作为系统的接地。

同时紧固每个端子的接线；更换部份模件并将模件的软件版本升级等。

使漂移现象基本消除。

（2）DCS故障诊断功能设置不全或未设置。

信号线接触不良、断线、受干扰，使信号值瞬间变化超过设定值或超量程的情况，现场难以避免，通过DCS模拟量信号变化速率保护功能的正确设置，可以避免或减少这类故障引起的保护系统误动。

但实际应用中往往由于此功能未设置或设置不全，使此类故障屡次发生。

如一次风机B跳闸引起机组RB动作，首出信号为轴承温度高。

经查原因是由于测温热电阻引线是细的多股线，而信号电缆是较粗的单股线，两线采用绞接方式，在震动或外力影响下连接处松动引起轴承温度中有点信号从正常值突变至无穷大引起（事后对连接处进行锡焊处理）。

类似的故障有：

民工打扫现场时造成送风机轴承温度热电阻接线松动引起送风机跳闸；轴承温度热电阻本身损坏引起一次风机跳闸；因现场干扰造成推力瓦温瞬间从99℃突升至117℃，1秒钟左右回到99℃，由于相邻第八点已达85℃，满足推力瓦温度任一点105℃同时相邻点达85℃跳机条件而导致机组跳闸等等。

预防此类故障的办法，除机组检修时紧固电缆和电缆接线，并采用手松拉接线方式确认无接线松动外，是完善DCS的故障诊断功能，对参与保护连锁的模拟量信号，增加信号变化速率保护功能尤显重要（一当信号变化速率超过设定值，自动将该信号退出相应保护并报警。

当信号低于设定值时，自动或手动恢复该信号的保护连锁功能）。

（3）DCS故障诊断功能设置错误：

我省有台机组因为电气直流接地，保安1A段工作进线开关因跳闸，引起挂在该段上的汽泵A的工作油泵A连跳，油泵B连锁启动过程中由于油压下降而跳汽泵A，汽泵B升速的同时电泵连锁启动成功。

但由于运行操作速度过度，电泵出口流量超过量程，超量程保护连锁开再循环门，使得电泵实际出水小，B泵转速上升到5760转时突然下降1000转左右（事后查明是抽汽逆止阀问题），最终导致汽包水位低低保护动作停炉。

此次故障是信号超量程保护设置不合理引起。

一般来说，DAS的模拟量信号超量程、变化速率大等保护动作后，应自动撤出相应保护，待信号正常后再自动或手动恢复保护投运。

2.4　软件故障案例分析

分散控制系统软件原因引起的故障，多数发生在投运不久的新软件上，运行的老系统发生的概率相对较少，但一当发生，此类故障原因的查找比较困难，需要对控制系统软件有较全面的了解和掌握，才能通过分析、试验，判断可能的故障原因，因此通常都需要厂家人员到现场一起进行。

这类故障的典型案例有三种：

（1）软件不成熟引起系统故障：

此类故障多发生在新系统软件上，如有台机组80%额定负荷时，除DEH画面外所有DCS的CRT画面均死机（包括两台服务器），参数显示为零，无法操作，但投入的自动系统运行正常。

当时采取的措施是：

运行人员就地监视水位，保持负荷稳定运行，热工人员赶到现场进行系统重启等紧急处理，经过30分钟的处理系统恢复正常运行。

故障原因经与厂家人员一起分析后，确认为DCS上层网络崩溃导致死机，其过程是服务器向操作员站发送数据时网络阻塞，引起服务器与各操作员站的连接中断，造成操作员站读不到数据而不停地超时等待，导致操作员站图形切换的速度十分缓慢（网络任务未死）。

针对管理网络数据阻塞情况，厂家修改程序考机测试后进行了更换。

另一台机组曾同时出现4台主控单元“白灯”现象，现场检查其中2台是因为A机备份网停止发送，1台是A机备份网不能接收，1台是A机备份网收、发数据变慢（比正常的站慢几倍）。

这类故障的原因是主控工作机的网络发送出现中断丢失，导致工作机发往备份机的数据全部丢失，而双机的诊断是由工作机向备份机发诊断申请，由备份机响应诊断请求，工作机获得备份机的工作状态，上报给服务器。

由于工作机的发送数据丢失，所以工作机发不出申请，也就收不到备份机的响应数据，认为备份机故障。

临时的解决方法是当长时间没有正确发送数据后，重新初始化硬件和软件，使硬件和软件从一个初始的状态开始运行，最终通过更新现场控制站网络诊断程序予以解决。

（2）通信阻塞引发故障：

使用TELEPERM-ME系统的有台机组，负荷300MW时,运行人员发现煤量突减，汽机调门速关且CRT上所有火检、油枪、燃油系统均无信号显示。

热工人员检查发现机组EHF系统一柜内的I/OBUS接口模件ZT报警灯红闪，操作员站与EHF系统失去偶合，当试着从工作站耦合机进入OS250PC软件包调用EHF系统时，提示不能访问该系统。

通过查阅DCS手册以及与SIEMENS专家间的电话分析讨论，判断故障原因最大的可能是在三层CPU切换时，系统处理信息过多造成中央CPU与近程总线之间的通信阻塞引起。

根据商量的处理方案于当晚11点多在线处理，分别按三层中央柜的同步模件的SYNC键，对三层CPU进行软件复位：

先按CPU1的SYNC键，相应的红灯亮后再按CPU2的SYNC键。

第二层的同步红灯亮后再按CPU3的同步模件的SYNC键，按3秒后所有的SYNC的同步红灯都熄灭，系统恢复正常。

（3）软件安装或操作不当引起：

有两台30万机组均使用ConductorNT5.0作为其操作员站，每套机组配置3个SERVER和3个CLIENT，三个CLIENT分别配置为大屏、值长站和操作员站,机组投运后大屏和操作员站多次死机。

经对全部操作员站的SERVER和CLIENT进行全面诊断和多次分析后，发现死机的原因是：

1）一台SERVER因趋势数据文件错误引起它