建筑中设备通信协议及数据融合处理方法

2022-01-20陈勤平上海市建筑科学研究院有限公司0008上海建科商务服务有限公司上海0003

绿色建筑 2021年4期

关键词：批处理通信协议网关

陈勤平，严敏（.上海市建筑科学研究院有限公司， 0008； . 上海建科商务服务有限公司，上海 0003）

通过研究建筑设备通信协议，应用物联网技术将分散的设备系统进行集成，建立建筑物联网基础平台。将多系统数据进行融合，打通设备和系统的壁垒，为设备协调优化和建筑能源的智能管控奠定技术基础。

1 设备通信协议

建筑内部设备类型种类繁多，通信协议和现场总线也多种多样，但目前楼宇中以 BACnet、Modbus 和 M-Bus 应用最为广泛。

1.1 BACnet

BACnet 是一种用于楼宇自动化和控制网络的数据通信协议，由美国采暖、制冷和空调工程师协会（American Society of Heating, Refrigerating and Air-Conditioning Engineers ，ASHRAE）主持开发，是美国等 30 多个国家的国家标准，也是欧洲标准和 ISO 全球标准，在楼宇设备自控系统（BA 系统）中广泛应用。BACnet 通信协议中定义了几种不同的数据链接层/物理层，包括 ARCNET、RS-232/RS-485、LonTalk。目前应用最为广泛的是基于以太网的BACnet/IP。

BACnet 是一种开放性协议，提供了不同厂商 BACnet设备之间的互操作性，通过 BACnet 协议，可将基于此协议的暖通空调系统、照明控制、门禁系统、火警侦测系统及其相关设备进行集成，实现数据互联互通和设备互操作。

1.2 Modbus

据 GB/T 19582.1—2008《基于 Modbus 协议的工业自动化网络规范》，Modbus 是 OSI (Open System Interconnection，开放系统互联)参考模型第 7 层上的应用层报文传输协议，其连接至不同类型总线或网络的设备，并未这些设备之间提供客户机/服务器通信。Modbus 简单易用，已经成为工业领域通信协议的标准协议，是工业电子设备之间常用的连接方式。在楼宇设备如电表、空调机组等设备中也广泛应用。Modbus 可基于串口和以太网进行通信，目前常用的是基于串口的 Modbus RTU 和基于以太网的 Modbus TCP 协议。

1.3 M-Bus

M-Bus 专门为测量仪器和计数器传送信息设计的数据总线，采用二线制，可以同时实现供电和传输数据。因此成本较低，支持星形、环形和总线结构，在冷热计量表水表、燃气表等计量器具的数据通信领域应用广泛。

2 建筑物联网平台

按 GB/T 51243—2017《物联网应用支撑平台工程技术标准物》的定义，联网是通过感知设备，按照约定协议，连接物、人、系统和信息资源，实现对物理和虚拟世界的信息进行处理并做出反应的智能服务系统。在云端设置建筑物联网平台，通过物联网网关连接终端设备，可对多种建筑或建筑群进行数据集成和融合处理。

2.1 平台架构

平台结构如图 1 所示。

图1 建筑物联网平台架构图

在建筑或建筑群中设置物联网网关，支持 Modbus、M-Bus、BACnet 等常用通信协议，通过以太网、双绞线、LoRa （远距离无线电）等多种通信方式连接智能化系统或智能设备，将数据转换成 MQTT （消息队列遥测传输）等标准协议，传输到云端的物联网平台。在平台上对数据进行融合处理，为各种物联网应用提供技术支撑，同时可将物联网应用的下发数据传输到物联网网关，再转换成各种系统和设备的协议对设备进行控制，在双向通信的基础上实现设备间的协调优化控制。

2.2 通信方式

通信方式可分为有线通信、WLAN （无线局域网）类通信和蜂窝类通信。

（1）有线通信：BACnet、Modbus、M-Bus 等协议一般采用基于双绞线、网线等通信介质的有线通信方式。

（2）WLAN 类通信：包括 WiFi、蓝牙、Zigbee 等通信方式，在传感器、智能终端等设备中应用较多，无需布线，位置灵活，但通信距离较短。

（3）蜂窝类通信：包括 2G/3G/4G/5G、NB-IoT、eMTC、LoRa 等。2G/3G/4G/5G、NB-IoT、eMTC 等均依托于移动运营商网络，适合于多种应用场景。LoRa 是低功耗广域网无线通信技术，传输速率从几百到几十 Kbps，工作在非授权频段，在应用场景上有一些限制。

2.3 物联网通信协议

常用的物联网通信协议有 CoAP、DDS、XMPP、MQTT。目前以 MQTT 应用最为广泛，一般物联网平台如阿里巴巴、腾讯、百度的物联网平台均支持。

（1）CoAP 协议：CoAP（Constrained Application Protocol，受限应用协议）是一个基于表述性状态转移（Representational State Transfer，REST）模型的网络传输协议，适用于在资源受限的通信的 IP 网络，传输层使用 UDP协议，以减少开销和支持组播功能，支持异步通信。

（2）DDS 协议：面向实时系统的数据分布服务，适用于分布式高可靠性、实时传输设备数据通信，在服务质量（QoS）上提供非常多的保障途径。

（3）XMPP 协议：一个开源形式组织产生的网络即时通信协议，是基于 XML 的协议，在互联网及时通信应用中运用广泛。

（4）MQTT 协议：基于“发布-订阅”模式的轻量级通信协议，已经成为 OASIS（结构信息标准化促进组织）标准，是物联网的重要组成部分，适合于低带宽、不可靠连接、嵌入式设备、CPU 内存资源紧张的场景。

MQTT 协议可以作为网关和物联网平台之间的标准通信协议，JSON (JavaScript Object Notation) 作为数据传输格式。JSON 是一种轻量级的数据交换格式，具有良好的可读和便于快速编写的特性，可在不同平台之间进行数据交换。JSON 比 XML 更加小巧、简洁，格式简单，占用带宽少，处理性能要求低，更适用于网络数据传输领域，如果对传输数据量有较高的要求，可在传输前进行压缩。为保障数据传输安全，应基于安全传输层协议 (Transport Layer Security Protocol，TLS)进行数据传输。

网关和物联网平台之间通过 MQTT 协议的“发布-订阅”模式实现双向通信。网关向平台 MQTT Server 的数据传输Topic（主题）发布采集的设备数据，平台的消息处理程序订阅 MQTT Server 的数据传输 Topic 进行消息处理。平台的物联网应用向 MQTT Server 的控制命令 Topic 发布控制命令，网关订阅 MQTT Server 的控制命令 Topic 获得控制消息并执行，从而实现数据传输和控制命令执行的双向通信。有多种消息中间件支持 MQTT 协议，可作为 MQTT Server，如 Apollo、ActiveMQ、Mosquitto、RabbitMQ、EMQ X 等。

2.4 消息和事件流

物联网通常需要处理大量数据，而且有时有明显的数据洪峰效应，在采集时间周期附近，会有大量数据涌入。因此，需要引入分布式消息中间件处理事件流。Kafka 和Pulsar 是常用的大数据组件，Kafka 是一个分布式消息中间件，也是一个开源的分布式事件流平台，高吞吐、低延迟，支持热扩展，数据多副本，支持高并发读写。 Pulsar 不仅可以像 Kafka 那样处理高速的实时场景，还能支持标准的消息队列模式。通过引入 Kafka 或 Pulsar，不仅进行数据的“削锋填谷”，大幅度提供系统处理能力，同时也可以降低系统之间的耦合。

2.5 数据存储

常用的 MySQL、Oracle、SQL Server 等单机关系型数据库并不适合存储海量的物联网数据。单机数据库很难水平扩展，即使通过主从复制、集群和分片等方式进行扩展也有很多限制。近年来出现的 Mongodb、HBase 等 NoSQL 数据库可以很好支持海量数据扩展，但不支持事务，不支持ACID（原子性、一致性、隔离性和持久性）特性，不支持SQL，同时原有开发模式需要做较大地改变。

如果需要数据强一致性，需要支持事务还需要很强的弹性扩容能力，可以采用类似 TiDB、OceanBase 这样的NewSQL 新型分布式关系型数据库，将 NoSQL 数据库的强水平扩展能力和关系数据库的强一致性、SQL 支持等特性很好地进行了融合。如果需要支持视频、图片、语音等非结构化数据，可以构建基于大数据技术的数据湖，从而能以任意规模存储结构化和非结构化数据,管理各类数据相关的要素，并在此基础上形成批处理、流式计算、交互式分析以及机器学习等多样化的分析能力。

3 数据融合处理

接收数据后通常需要对数据进行融合处理，从多个维度、多个指标反映事物特征。常规的单机数据处理技术已无法满足海量数据处理要求。分布式计算将一个大的计算任务划分为若干个子任务，然后为计算机网络中的计算节点分别分配一部分子任务，通过并行处理提高数据处理效率，最后整理、综合各部分的计算数据，得到最终的计算结果。

3.1 大数据处理架构

分布式计算按类型可分为批处理、流处理（流式计算、实时计算）。批处理是对一批数据聚合后进行处理，基本流程是收集数据→放到数据库中→取出来进行计算。在计算时效性要求高的场景下，无法满足实时性要求。流式计算持续接收发来的数据流，实时地进行处理与分析，并及时反馈结果，以满足对数据处理有较高实时性要求的场景。其特点是实时、低延迟，数据持续不断，无终止，计算持续进行，计算完之后数据即丢弃。

最早的批处理采用 Hadoop MapReduce（映射归约），MapReduce是一种编程模型，用于大规模数据集的并行运算。相比于基于磁盘计算的 Hadoop，Spark基于内存进行计算，速度要快得多（最多可比 Hadoop 的MapReduce 快 100 倍)，同时有 Spark SQL（分布式 SQL引擎）、Spark Streaming（流处理）、Spark MLlib（机器学习库）、GraphX（图计算）等多种组件，已经基本取代Hadoop MapReduce，成为Hadoop 生态中的重要成员。

目前大数据处理架构可分为 Lambda 架构和 Kappa架构。

（1）Lambda 架构。Lambda 架构分为批处理层（Batch Layer）、实时处理层（Speed Layer）、服务层（Serving Layer）。数据分别进入批处理层和实时处理层，批处理层将数据存储到主数据集，并对主数据集进行汇总计算。实时处理层针对增量数据进行实时处理，服务层可以将批处理层和批处理层的结果进行汇聚，为上层应用提供数据。

（2）Kappa 架构。Lambda 需要将算法实现 2 次，一次是为批处理系统，另一次是为实时系统。为此 Kappa 架构对流处理进行改进，取代了批处理。需对全量数据进行重新计算时，用 Kafka 或类似的分布式队列保存需要时长的数据，重新启动起一个流计算实例进行计算。但是，因为所有的数据都通过流式计算，如果历史数据规模很大，很难适应物联网时代对数据查询响应的即时性要求。

目前批处理以 Spark 为代表，流处理以 Flink 为主，但二者相互也在融合对方特点，Spark Streaming 以微批方式实现流式处理，Flink 以流处理为基础实现流批一体。

3.2 建筑数据的融合处理方法

建筑数据的处理分为 2 种类型，接收数据进行实时处理，如超限报警、异常判定等。在数据库层需要进行时、日、月、年等时间维度的多种指标汇总计算，如统计能耗指标、设备运行指标等。

在数据汇聚到 Kafka/Pulsar 等分布式流系统后，可采用 Flink 进行实时处理，计算参数超限报警、异常判定等，如果对实时要求不是非常高，也可采用 Spark Streaming。在数据库层，可采用 Spark/Flink 进行汇总计算。

针对建筑数据的处理，目前 Lambda 架构更合适些。一方面随着建筑数量和采集数据的增多，数据量会急剧增大，并且时、日、月、年等时间维度的指标汇总计算和实时计算的逻辑并不一致，不能使用同一套代码；另一方面需要使用历史数据进行机器学习，使用批处理来反复验证不同的算法。但是，可以统一分布式计算引擎，在实时计算和流处理统一使用 Spark 或者 Flink，实现流批一体。