农村供水监控数据共享交互方法研究
2022-05-17李晓琴
李晓琴，孙 毅，梁 玉，孙 颖，李 珊
(1.中国水利水电科学研究院，北京 100048； 2.国家节水灌溉北京工程技术研究中心，北京 100048；3.辽宁省水利事务服务中心， 辽宁 沈阳 110003； 4.盘锦市水利服务中心， 辽宁 盘锦 124000；5.北京市门头沟区水务建设项目事务中心，北京 102302)
农村供水监控数据缺乏共享交互，各个企业建成的不同水厂农村供水自动化监控系统往往各自为战，独立的系统、分散的数据很难向数字化、网络化、智能化的方向转变，需要花费较大的代价来实现数据共享交互。本研究主要服务于水厂中心上位机系统、云端农村供水自动化监控系统、上级农村供水相关业务系统之间的数据共享交互，在农村供水水厂自动化监控系统、农村供水业务系统建设之初，明确数据共享交互方法，提前定义好数据指标、数据结构，方便农村供水监控数据共享交互。
世界各地通信设备有提前约定好的通信协议，遵循这些协议实现设备层面控制器之间、控制器经由网络和其他设备之间的数据共享交互[1]。国际电工组织(IEC)选定和规定了一些应用广泛、通用安全高效的工业通信协议，作为全球通信器材制造和各类通信协议标准[2]。如目前应用最广泛的Modbus RTU协议，转换接口便宜、实施简单方便、性价比较高[3]，也是《村镇供水工程自动化监控技术规程》[4](T/CECS 493—2017)规定的设备层面的接口[5]。还有开放式的Profibus协议，不依赖于设备生产商的现场总线标准[6]。明确了通信协议，针对具体的业务实现，需要进一步定义好数据规约，才能真正实现数据交互共享。国内水文或水资源部门，发布了《水资源监测数据传输规约》[7](SZY206—2012)、《水文监测数据通信规约》[8](SL651—2014)，约定了传感器与遥测终端、各测站与中心站之间的报文数据通信协议和规约。通过约定的报文和协议实现数据共享交互，有效避免工程项目的重复建设。
然而，在设备层之上，PLC主站与水厂中心上位系统、水厂中心上位系统与供水管网监控系统或区域上级信息化监管系统之间，要使其能协同工作、实现信息交互和资源共享，更需要制定互相接受的信息规则。国内外常用的数据共享交互方式有数据交互软件、数据库交互[9]、标准数据交互方法等多种方式实现。数据交互软件方式，花费代价比较大，一般普通的PLC都需要配备一台特定的前置机设备才能实现数据共享交互，而近期新式的一些PLC能够提供诸如OPC UA等标准接口，使得数据对接变得很方便，但这些设备价格一般都比较昂贵，并且设备上的资源对于一般自动化场合显得过多。中间数据库技术，重要的数据信息资源通过数据库交互实现统一管理[10]。中间数据库数据共享有很大的方便，但其缺点也突出，一是当数据共享对接的系统较多的时候，由于数据库连接池的限制，许多系统无可用的连接或者需要依托庞大的数据库系统；二是数据库暴露在多个系统的公共区域，每个系统都有特定的访问权限，数据库容易受到攻击，安全隐患比较大。
随着互联网技术的发展和通信网络的普遍应用，采用Http、消息队列等进行数据交互的方法应用广泛[11]。这种方式下，采用Xml、Protocol Buffer、Json等数据交互技术实现[12]，是简单快捷、实施方便、运维代价最小的一种数据交互方式。有了数据交互技术的支持，还需要研究制定跟业务匹配的数据共享交互方法，约定相关业务的指标定义、统一的信息编码规则、数据结构等内容，才能实现信息的唯一性和同一性，避免信息的多源、失真和缺失。
农村供水管网监控系统由于农村供水工程点多、面广、运行管理单位多样等特点，系统建设水平参差不齐，不同单位建设系统、不同层级的系统之间数据传输协议、共享数据内容、数据结构不明确，缺少数据共享交互方法，兼容性和数据交互共享不足，信息利用率低、系统之间共享度较差[13]。因此，本研究在对比分析目前数据交互方法基础上，选择Json格式，分别从数据指标定义、Json数据结构两方面，构建农村供水监控数据交互方法，并结合实际案例对交互效果进行对比分析。
1 数据交互方法选择
1.1 数据交互方法对比
当前的数据交互技术主要包含Xml、Protocol Buffer、Json等，但是未针对农村供水业务开展标准化定义，需要选用一种成熟的数据交互技术，根据农村供水业务定义数据指标、数据格式、安全机制，保证数据高质量低代价快速度地交互共享。
(1) Xml(Extensible Markup Language，可扩展标记语言)是常用的、也是较早出现的一种数据交换格式[14]，能对文档和数据进行结构化处理，通过对结构性文件的标记实现数据交互。Xml语言以树结构为基础对数据进行描述，
(2) Protocol Buffer，以二进制格式存储，支持数据结构的自定义，还有专门的工具，Protobu编译器能转换为C++、Java、Python等语言的源代码，是一种效率高、兼容性好的二进制数据传输格式。由于二进制的格式是最直白的计算机语言，所以Protocol Buffer比Xml数据体积小、传输速度快、更容易扩展。但正是由于二进制语言，没有文本语言直接和形象，对于程序员来说，编写起来比Xml复杂，转换时间较长。
(3) Json(JavaScript Object Notation，对象简谱)，也是一种文本方式的数据交换格式，它源自于JavaScript，以{Key：Value}键值的形式描述对象[16]。Json是欧洲计算机协会(European Computer Manufacturers Association)脚本程序(ECMA Script)制定的一个子集，它的层次简洁清晰，阅读和编写容易，机器解析与生成方便，任何JavaScript对象都可以转换为Json，然后将Json发送到服务器。同样，从服务器接收的任何Json也可以转换为JavaScript对象[17]。它是一种简洁、容易、快速、理想的数据交换语言，能有效地提升网络传输效率。
三种数据交互格式从可读性、通用性、便捷性方面的区别和特点分析如下：
(1) 可读性方面：Xml和Json都是文本语言，序列化后的内容可读性都非常好，排查错误和纠错容易。当出现数据交互错误时，可以用模拟数据测试[18]。Protocol Buffer是二进制格式，序列化以后的内容不可读，它的可读性最差，容易出现错误且排查纠错困难。
(2) 通用性方面：Xml和Json都比较成熟，是目前比较常用的数据交互格式，Protocol Buffer的应用相对较少，不适于广大业务系统的实际应用。
(3) 便捷性方面：Json数据格式相对于Xml来说更加简单、易于读写，且数据格式经过压缩，所以占用带宽小、传输速度快，更适于不同层级供水监控数据的交互；Json数据格式的序列化和反序列化便于服务器端的解析[19]，服务器端代码能直接使用，这样也简化了服务器和客户端的代码开发量，易于维护[20-22]。表1为Xml和Json描述相同管网数据的更新。
由表1可以看出，相同的数据，Xml的冗余信息远多于Json，特别是对于数组，Json格式只需要一个标记即可描述整个数组，而Xml格式需要对数组的每个元素添加一对标签，因此数组元素越多，冗余越多。Xml与Json的冗余信息对比见表2。
表1 相同管网数据Xml和Json封装对比
表2 Xml与Json冗余信息对比
通过综合比选，选定Json格式进行不同层级农村供水监控数据的交互。
1.2 Json数据交互方法/理论
在当前的数据交互技术Xml、Protocol Buffer、Json中，选择了书写简单、易于读写、解析速度快、占用带宽小的Json交互方法。Json主要有两种表示结构：一是“key:value”键值对的集合，不同的语言中，它被理解为对象、记录、结构、字典、哈希表等数据结构；二是值的有序列表(An Ordered List of Values)，也可以理解为数组，这种数据结构是Json节省冗余的关键所在。
方式1：
[
{"name":"流量1", "value":"1.1"},
{"name":"流量2", "value":"1.2"},
{"name":"流量3", "value":"1.3"},
{"name":"流量4", "value":"1.4"},
{"name":"流量5", "value":"1.5"},
]
方式2：
{
"name":["流量1","流量2","流量3","流量4","流量5"],
"value":[1.1,1.2,1.3,1.4,1.5]
}
监测数据和Json字符串之间，通过Json序列化和反序列化实现转换。在数据交互的两端，数据结构可以完全不同，传输过程中的Json字符串能被正确的生成和解析，则整个过程是有效的。所以在序列化和反序列化的两端，可以用不同的语言、架构、方法，为不同系统之间的数据交互提供了可能。Json数据序列化和反序列化过程如图1。
序列化(Serialization)是将监控数据信息转换为Json字符串的过程。具体执行步骤如下：(1) 上位机定时采集供水监控数据，将数据作为数据对象汇总；(2) 上位机将数据对象序列化为Json数据包；(3) 上位机发送Json数据包给服务器接口；(4) 服务器接收Json数据包；(5) 服务器执行Json反序列化，解析出具体的监控数据对象；(6) 服务器进行数据处理，将处理结果归入中心数据库。
反序列化(Deserialization)是将Json字符串重新转换为监控数据信息的过程。具体执行步骤如下：(1) 服务器接收客户指令，转换为数据对象；(2) 服务器将数据对象序列化为Json数据包；(3) 服务器将Json数据包发送给上位机；(4) 上位机接收到服务器推送的Json数据包；(5) 上位机执行Json反序列化，解析出具体的控制指令；(6) 上位机将控制指令发送给具体的监控设备。
图1 Json数据序列化和反序列化过程
2 数据指标定义
选择Json数据交互格式，需要按照一定规则对农村供水监控数据进行指标定义，以期快速、高效、低成本实现不同厂家、不同设备的数据共享交互。
根据传感器指标监控的不同环节，分三级定义监控数据指标，包括传感器指标——设备设施所属——分类属性，明确每个传感器所处的供水环节、具体位置和类型。传感器指标定义最底层传感器监控的指标名称、标识符、数值类型和数值单位。设备设施所属规定了设备设施所属的供水环节，包括水源、输水管网、水厂、配水管网、管网末梢、用水户6个供水环节。分类属性是针对同一个供水环节不同位置或者不同类型进行的定义，如水厂环节的水处理、调节构筑物、泵站位置的区分，如水源环节是地表水还是地下水的区分。数据指标划分和定义层级如图2所示。
图2 数据指标划分和定义层级
2.1 传感器指标(indicator)
传感器指标是不同传感器采集的指标。每个传感器指标有唯一的标识符，该标识符为字符串类型，且不区分大小写。在数据流转过程中，可通过该标识符对传感器指标进行引用。每个传感器指标还有对应的中英文术语名称、中英文单位、数据类型、单位等信息，传感器指标定义见表3所示。
表3 常见传感器指标定义
2.2 设备设施所属(part_of)
农村供水工程从取输净配四个工艺环节分解出水源、输水管网、水厂、配水管网、管网末梢、用水户等6个供水环节，每种设备设施都从属于这6个供水环节其中之一，所从属的环节就是设备设施(device)的所属(part_of)，表4为设备设施所属part_of属性定义。
2.3 分类属性(props)
水厂供水不同环节的传感器或设备设施还可能有多种分类方式，如水源类型有地表水、地下水；构筑物有水处理、排泥、调节构筑物等；为满足这种更细致的分类划分，这里对设备设施的定义进行了扩展，即分类属性props定义。
表4 设备设施part_of定义
引入分类属性定义props，为设备设施和传感器定义提供更好的灵活性和兼容性。props属性为数组格式，可以对当前设备设施定义多个附加属性，用于兼容更细致的分类。如某工程水源为地表水，且为水库水，则其part_of定义为wss，同时可以定义props为sw-re，表示水源为地表水-水库水。再如水源取水泵站的定义，其part_of为wss，可以添加props定义ips。设备设施的props属性及其part_of限定值见表5。
表5 设备设施device的props属性及其part_of限定
(1) props针对泵站的特殊设定。所有泵站的设备设施必须有props属性。如下所示泵站定义：
"id":"pump_out",//设备设施标识
"name":"配水泵房"
"part_of":"wsp",//设施所属
"props":["dps"],//表明当前泵站的类型为配水泵站，必须包含该属性
(2) 兼容不同位置安装。监测环节和安装位置不一致时，可在“props”中增加安装位置指标，且可以设置多个。
如某个设备设施监测水源浊度指标，安装在水厂，水源为地表水，且为水库水，则part_of定义为wss，props定义为["sw-re","wsp"]。表明该设备安装于水厂，且为地表水-水库水。
3 Json数据结构
定义好数据指标后，本章明确了设备设施定义、新增或更新传感器数据、视频安防监控数据的数据结构和消息类型。
3.1 消息类型定义
基本数据格式包括唯一标识id，版本号ver，类型type三个属性，且均为必填属性，对应的json格式为：
{
"id":"xxx", //消息唯一标识id
"ver":"1.0",
"type":"def",//消息类型
//根据不同类型，消息其他部分
}
针对不同的type类型，消息定义的具体内容不同。消息类型定义如表6。
表6 消息类型定义
3.2 设备设施定义数据结构
设备设施定义消息格式，类型为def，具体消息内容按照供水工程(fields)→设备设施(devices)→传感器(sensors)三级定义。一个消息数据可包含多个供水工程，一个供水工程可包含多个设备设施，一个设备设施可包含多个传感器。fields字段为水厂或者供水工程列表，可以包含多个水厂或者供水工程的监控数据。单个工程标识为field。devices字段为单个供水工程所包含的监控设备设施，可以是一个监控柜、控制箱或者监控点。sensors字段为单个设备设施所包含的多个监控传感器，如流量计、压力表等。
(1) fields。fileds包含唯一标识id，供水工程名称name，工程编号prj_id，经纬度lng，lat四个属性。
id，每个field对应一个唯一水厂标识。规则是：省_市_县_水厂字母进行组合。如： ln_pj_ps_ds辽宁盘锦盘山县东升水厂。name，供水工程名称，与全国农村供水信息管理系统名称必须一致。prj_id，部级系统对供水工程统一标识，由全国农村供水信息管理系统统一分配。lng，lat经纬度，水厂经纬度浮点数。
(2) devices。devices包括唯一标识id，设备设施名称name，part_of，props，经纬度lng，lat五个属性。
id，每个device id在field下面必须唯一，可以以a-z字母开头，后续可以是a-z，0-9，_等字符组成，尽可能简短，如：sor1，fac等。name，设备设施名称。part_of，定义设备设施的供水环节，包括水源，输水管网，水厂，配水管网，管网末梢，用水户六部分，如：{"part of":"wss"}，由供水工程不同环节定义的所属，唯一。props，当供水环节part_of的描述不能准确定义设备设施时，需要增加props属性，如：{"props":"sw-re"}，水源属于地表水水库，可以是数组。lng，lat经纬度，使用浮点数值表达。
(3) sensors。sensors包括id，name，iid，indicator，props五个属性。
id，每个sensor id在device下面必须唯一，可以a-z字母开头，后续可以是a-z，0-9，_等字符组成，尽可能简短，如：flow1 lvl1等。name，指标名称。iid，定义内部唯一id，是整数，内部定位指标。Indicator，传感器sensor的indicator属性。Props，分类属性定义，如：indicator是水质可以增加方向属性in/out。
3.3 新增或更新传感器数据
自动化监测数据格式类型以mdata消息类型为基础，每个消息数据可以包含多个供水工程，每个供水工程内部的多个传感器指标在某个时间的监测值更新。
(1)数据格式允许多个field的更新数据，每个field只需要id属性区分即可，此id在def中被定义。在每个field对象中，有一个updates属性，值为Json对象数组，数组中每个对象都是一个指标在某个时间的值。
(2)每个监控指标对象，都有一个id或iid。其中，id是在def中定义的fieldid_deviceid_sensorid组合而成的全路径唯一标识，而iid是def内部定义的唯一整数压缩标识，如：{"id":"sor1.p1_st","dt":345234524,"v":0.5}。
(3)每个数据项都有时间dt属性，是long值，起始1970.1.1到现在的毫秒数，如：{"iid":11,"dt":345234524,"v":0.5}。
(4)如果某个数据项是无效的，则有valid:false的属性，如：{"iid":14,"dt":345234524,valid:false}。
(5)如果某个数据项是有效的，则有数据值属性v。其中值的类型由sensor中的indicator限定。
3.4 视频安防监控数据
视频安防监控消息格式，类型为video，具体消息内容按照供水工程(fields)→视频监控点(monitorpoints)→监控摄像头(cameras)三级设定。一个供水工程可包含多个视频监控点；一个视频监控点可包含多个监控摄像头；每个消息数据可包含多个供水工程的视频监控数据。
fields字段为水厂或者供水工程列表，可以包含多个水厂或者供水工程的视频监控数据，单个工程标识为field。monitorpoints字段为单个水厂或者供水工程所包含的所有视频监控点。cameras字段为单个视频监控点所包含的所有监控摄像头信息。
(1) fields。fields包括prj_id，monitorpoints两个属性，且均为必填属性。
prj_id，必传，用于区别监控设备属于哪个水厂或供水工程。该id由系统下发，不能自定义。Monitorpoints，必传，用于定义或者更新视频监控点。
(2) monitorPoints，monitorpoints包括id，name，lng lat，part_of，props，cameras六个属性。
id，视频监控点id，必传，自定义，在水厂或供水工程范围内不重复，如：{"id":"bengfang01"}。name，视频监控点名称，非必传，自定义，在水厂或供水工程范围内不可重复，如：{"name": "一号泵房"}。lng，lat：视频监控点位置信息，包含经度和纬度，经纬度应尽量精确，支持小数点后6-8位数据存储，如：{"lng":120.455675, "lat":37.854796}。part_of，视频监控点的设备设施所属，必传，用标识符来标识，如：{"part_of":"wsp"}。props，细化的设备设施所属，非必传，如：{"props": "wss"}。cameras，监控摄像头列表，必传，给定所有摄像头。
(3) cameras。cameras包括id，name，live，brand，model，sn六个属性，可自定义。
id，视频摄像头id，必传，在所属视频监测点范围内不可重复，如：{"id":"01"}。name，视频摄像头名称，必传，在所属视频监测点范围内不可重复，如：{"name":"东南"}，第一次必传，后续有变化时再传。live，视频摄像头名称，必传，如：{"流畅":"https://open.ys7.com/ "}。brand，摄像头品牌，非必传，如：{"brand":"海康威视"}。model，摄像头型号，非必传，如：{"model":"iDS-7816NX-Z2/X"}。sn，摄像头序列号，非必传，如：{"sn":"F72305733"}。
4 与之前交互方式对比分析
农村供水Json数据共享交互方法，支持多个水厂供水管网监控数据的交互共享，已在辽宁、重庆、宁夏等多处水厂监控系统中应用，对接传感器设备数量100个左右。系统运行后，数据对接过程中，不同水厂，不同设备厂商，只需在上位机按照标准协议进行监测设备的定义，并配置数据的定时上传即可实现系统的正常运转，无需额外的开发工作，节省了开发时间和成本。同时，基于Json的交互方式，相同信息量传输的字节更少，与之前的数据共享措施相比，系统响应的速度更快。
图3 辽宁东港供水管网监控
表7是基于Json的数据交互与之前的数据共享措施的对比。结果表明，单个供水工程布设周期缩短50%以上，平均上行数据包大小缩小33%。
表7 两种交互方式对比
5 结 论
本研究创建了一套农村供水Json数据共享交互标准格式。基于Json交互技术，定义了传感器指标、设备设施所属及其分类属性，构建了自动化监控设备设施定义、新增或更新传感器数据、视频安防监控数据的结构类型，数据采集与应用体系使用相同的数据接口，无需重复开发，可统一维护，大幅降低了开发和维护成本。该数据共享交互方法与传统方法相比，单个供水工程布设周期缩短50%以上，平均上行数据包大小缩小33%，破解了农村供水监控数据缺乏共享交互方法、已建系统数据共享费用高、维护成本高的难题。
