文保单位，古建筑，古村落消防物联网系统介绍是什么？

国家文物局部署开展全国文物火灾隐患整治和消防能力提升三年行动，关于文物火灾隐患排查整治，强调要求重点排查大型古建筑群、传统村落、作为宗教活动场所文物建筑、博物馆和文物保护工程工地等火灾诱因较多的单位或场所；重点整治生活用火、生产活动用火、宗教场所用火、电气安全故障，以及可燃物和易燃易爆危险物品管理、消防设施设备使用维护、占堵消防通道、消防安全管理等方面存在的火灾隐患和问题。

智慧消防物联网系统应用，成为文保单位、古建筑消防监管、祸患防控新抓手。建设“文物保护单位智慧消防监控服务中心”，构建一体化的“智慧消防”技术和管理体系。统一数据标准，规范数据来源，对消防内部、外部数据资源进行汇聚和挖掘分析，为火灾风险研判、灭火救援指挥等提供信息支撑。同时，推进面向政府应急管理部、文保单位、公众的消防-化发展进程，创新消防安全治理新模式。

消防物联网系统介绍：　

1、分级管控的智慧消防监控系统

部署智慧消防服务器集群及数据库，配置大屏幕图像显示系统，组建智慧消防监控系统，同时提供数据接口对接城市级消防数据中心和政府应急管理部门。

2、消防物联网自动报警系统

物联网声光手报、NB-IOT智慧烟感等自动报警终端接入消防监控系统，实现消防设施状态及火灾报警信息的实时采集及远程传输，警情信息、位置信息平台化展示，警情信息快速响应。

3、消防水源监测监控系统

通过文物古建筑、博物馆等单位消防给水系统末端的消防设施上安装传感器，实时采集水压水位数据，实现数据的远程传输。一旦发现消防供水不足，出水量偏低，立即发出警示提示信息。

4、电气火灾监控系统

高度商业化的古城内，游客众多，酒吧、旅社林立，这导致明火火源较多。同时，急功近利的古城改扩建，让原本就严重老化的电线负荷剧增，火灾危险陡升。在各供电系统内安装电气火灾监测设备，实时探测线路中的电流、电压、温度等数据，当探测项目数据超过报警设定值时，自动发出报警信号，并将报警信息上传至平台监控中心。实现了对单位电气情况的远程监控，加强了对用电事故的预防能力。

5、安全通道监控系统

通过摄像头和车道占用分析程序，完成对车道的实时监控。实现对消防区域内应急车道的智能监管，有效减少因车道堵塞造成额外的人员、财产损失。

6、消防设施巡检维保系统

各文物、博物馆等单位的消防安全责任人和消防安全管理人负责组织和实施消防安全检查，通过消防巡检专用APP软件，督促和落实火灾隐患整改工作。系统综合运用“互联网+”实现消防巡检任务定时派发、隐患信息实时推送、隐患整改闭环跟踪、文字全程记录、巡检工作数据长期保存、分级查询统计等功能。

文保单位智慧消防物联网系统从智能监测、自动预警、智慧管理三个层面的应用，有效强化责任落实，健全文物消防安全责任制，从源头治理，人防+技防相结合化解重大文物火灾风险，增强火灾预警防控能力，实现精准管理，为文物消防安全治理现代化建设添助力

通过云端服务器对柴油机的运行进行监控和分析。
物联网技术可以有效地解决船舶柴油机的运行状态监控问题，采集的参数数据实时上传到云端服务器，通过云端服务器对柴油机的运行状态进行实时监控和分析。
物联网是指物理世界中的物体可以通过网络连接，与其它物体或系统进行交互，以获取、分析和处理数据，在各种环境中实现自动化控制的技术。

IOT网关，接收sensor数据的总入口，主要是日志，安全防护，流控，协议转换等功能，

图1 IOT网关

之前有提到IOT网关是基于python的twisted框架实现的，初期的时候该IOT网关主要实现的功能是 数据接收和转换功能 和 安全防护 。

数据接收和转换功能 ，这里很简单，拟定好数据交互格式后，IOT网关按照约定好的格式进行解析，然后转发给后端服务进行进一步的处理

安全防护 ，设备的区分主要是依靠烧录到硬件的SN号来实现，SN号包含的信息比较多，如生产批次，设备型号等，受制于厂商我安全防护不能做的非常完善，同时sensor与IOT网关的交互不能非常复杂。安全防护这一块理论上是设备接入要一型一密或者一机一密，协议上还应该启用tls/ssl安全通信协议。

图2 鉴权

安全防护要做ssl这类的安全通信协议的话，要考虑设备厂商实现通信模块能力，设备功耗，设备性能（低端设备cpu性能可能比较差，可考虑对称加密形式），IOT网关也需要引入相应模块。

另外认证从性能方面考虑，后期在设备比较多的情况下，可以加入redis等内存型key-value数据库，缓存设备信息，提高鉴权模块性能。

实践中，我们的sensor基本都是依靠电池供电，因此我们的IOT网关基本是面向短链接（后期我们有监测设备，依靠外部电源直接供电，为长连接），因此在每次发起连接我们都要进行一次鉴权，鉴权通过后，设备方可上传传感器监测数据和设备自身状态。

图3 数据交互流程

这一块的调试工作长达半年左右，才基本稳定下来，主要集中在设备商处除了硬件稳定性，还有在调试中发现传输的字符串乱码（c语言处理问题），沾包（厂商开发人员tcp协议不熟），优化传输效率，关闭cork或者 Nagle 算法（传输包很小）。

因为IOT网关不能主动断连接，理论 *** 作中，IOT网关应该和sensor有心跳协议，保证连接的有效性。设备商在数据流程交互完成后，竟然没有close 连接，直接休眠，导致网关所在服务器的连接的文件描述符一直没有正常释放，后面为了预防这种现象，我开启了 *** 作系统层面的keepalve定时器，回收失效连接（系统默认时间是2小时左右，我缩短了失效时间），理论上来说应该是应用层面去实现心跳协议。

整个IOT网关的设计，是无状态，可伸缩的，单网关在普通型ecs上可轻松达到数百tps。

---