岳敏

（重慶遠(yuǎn)通電子技術(shù)開發(fā)有限公司，重慶 400000）

1 背景

在供水與排水網(wǎng)中，有大量的無人值守泵站，7×24小時(shí)工作。為了保證這些泵站的正常工作，建立了聯(lián)網(wǎng)監(jiān)控系統(tǒng)。這些系統(tǒng)主要采用比較傳統(tǒng)的自動(dòng)化技術(shù)構(gòu)建，包括使用組態(tài)軟件作為現(xiàn)場(chǎng)數(shù)據(jù)采集的核心軟件、使用Modbus 作為現(xiàn)場(chǎng)數(shù)據(jù)采集及向中心站的數(shù)據(jù)傳輸協(xié)議、使用關(guān)系型數(shù)據(jù)庫存儲(chǔ)工況數(shù)據(jù)，如圖1 所示。

圖1 以組態(tài)軟件為核心的監(jiān)控平臺(tái)架構(gòu)

在應(yīng)用中，該方案雖然解決了無人泵站的遠(yuǎn)方監(jiān)控問題，但也表現(xiàn)出較多的問題，主要表現(xiàn)在以下方面。

（1）軟件架構(gòu)方面。組態(tài)軟件因架構(gòu)限制，阻礙了監(jiān)控系統(tǒng)的智能化拓展。因應(yīng)用需求，需在基礎(chǔ)監(jiān)控之上進(jìn)一步開發(fā)泵站能耗分析、故障診斷等智能應(yīng)用。但組態(tài)軟件架構(gòu)比較封閉，提供的開放集成接口較少，既不能有效提供數(shù)據(jù)、分析技術(shù)等方面的基礎(chǔ)支持，也不能方便地將智能應(yīng)用集成進(jìn)組態(tài)應(yīng)用中，已不能滿足智能應(yīng)用開發(fā)需求，從整體軟件架構(gòu)上，阻礙了整個(gè)系統(tǒng)的智能化拓展。

（2）網(wǎng)絡(luò)傳輸協(xié)議方面。Modbus 協(xié)議在安全、功能、效率等多方面已不能滿足需求。Modbus 作為應(yīng)用最廣泛的工控網(wǎng)絡(luò)協(xié)議，在現(xiàn)場(chǎng)設(shè)備數(shù)據(jù)采集方面具有最好的兼容性，具有不可替代的價(jià)值。但其協(xié)議幾乎不具備安全機(jī)制，因此，在監(jiān)控站向中心站的廣域數(shù)據(jù)傳輸方面有嚴(yán)重的安全隱患。同時(shí)在新開發(fā)計(jì)劃中，擬進(jìn)一步建立分布式的設(shè)備群事件機(jī)制，開發(fā)泵站的全生命周期管理應(yīng)用，Modbus 的輪詢模式從功能性上來說無法支持這些新功能的開發(fā)，并在監(jiān)控站數(shù)量不斷增加的情況下，出現(xiàn)了明顯的效率瓶頸。

為解決以上問題，以面向大量無人值守泵站群為目標(biāo)，采用新的物聯(lián)網(wǎng)技術(shù)及IT 技術(shù)，設(shè)計(jì)實(shí)現(xiàn)了新的無人值守泵站群物聯(lián)網(wǎng)平臺(tái)。以下將從平臺(tái)架構(gòu)、協(xié)議設(shè)計(jì)、應(yīng)用接口等方面對(duì)新的設(shè)計(jì)進(jìn)行詳述。

2 架構(gòu)設(shè)計(jì)

以數(shù)據(jù)流處理為基本設(shè)計(jì)思想，采用MQTT 為通信協(xié)議，各單元間以標(biāo)準(zhǔn)的集成方式進(jìn)行集成的新架構(gòu)，如圖2 所示。

圖2 以數(shù)據(jù)流處理為核心的系統(tǒng)架構(gòu)

2.1 基于MQTT 的通信架構(gòu)

為解決Modbus 協(xié)議帶來的諸多架構(gòu)局限，采用了以MQTT 為通信協(xié)議的通信架構(gòu)。MQTT 是目前物聯(lián)網(wǎng)系統(tǒng)中應(yīng)用最廣的協(xié)議，訂閱/發(fā)布是MQTT 的基本通訊模式。在該模式下，云中心通過訂閱設(shè)備端的相關(guān)消息，實(shí)現(xiàn)設(shè)備端向云中心的數(shù)據(jù)發(fā)送；同時(shí)，設(shè)備端通過訂閱云中心的相關(guān)消息，實(shí)現(xiàn)接收云中心的控制命令。訂閱/發(fā)布模式在大量遠(yuǎn)方設(shè)備情況下，相對(duì)輪詢模式具有明顯的性能優(yōu)勢(shì)，節(jié)約大量的網(wǎng)絡(luò)資源。

2.2 基于數(shù)據(jù)流的設(shè)計(jì)思想

平臺(tái)架構(gòu)以處理數(shù)據(jù)流作為基本思想。數(shù)據(jù)流的主要特征是數(shù)據(jù)處理單元將數(shù)據(jù)看作無邊界的數(shù)據(jù)集合，在數(shù)據(jù)傳輸?shù)倪^程中即完成數(shù)據(jù)轉(zhuǎn)發(fā)、過濾、分析、轉(zhuǎn)存等操作，相對(duì)于將數(shù)據(jù)按時(shí)間間隔存儲(chǔ)后再進(jìn)行處理的批處理系統(tǒng)，數(shù)據(jù)流系統(tǒng)具有處理延遲小、計(jì)算負(fù)荷分配均勻（從而更適合規(guī)模擴(kuò)展）等特點(diǎn)。Apache Storm、Apache Flink 等流處理系統(tǒng)的廣泛應(yīng)用，已證明了數(shù)據(jù)流處理系統(tǒng)在數(shù)據(jù)密集應(yīng)用中的優(yōu)越性和實(shí)用性。

在泵站監(jiān)控中，主要包括三種數(shù)據(jù)流：（1）設(shè)備數(shù)據(jù)流：即設(shè)備的工況數(shù)據(jù)，是典型時(shí)間序列數(shù)據(jù)；（2）事件數(shù)據(jù)流：即監(jiān)控系統(tǒng)中常見的報(bào)警事件、越限事件等事件數(shù)據(jù)。有效設(shè)計(jì)、處理這類數(shù)據(jù)，形成事件驅(qū)動(dòng)體系，是提升系統(tǒng)智能性的關(guān)鍵之一；（3）控制數(shù)據(jù)流：主要為云中心對(duì)監(jiān)控站的控制信號(hào)，也包括中心對(duì)現(xiàn)場(chǎng)系統(tǒng)的運(yùn)維信號(hào)，例如，設(shè)備升級(jí)數(shù)據(jù)包、遠(yuǎn)方提取日志命令等。

針對(duì)不同數(shù)據(jù)流的結(jié)構(gòu)特征差異，平臺(tái)使用了混合的數(shù)據(jù)存儲(chǔ)方案：對(duì)于工況數(shù)據(jù)這類時(shí)間序列數(shù)據(jù)，使用時(shí)間序列數(shù)據(jù)庫存儲(chǔ)，例如，實(shí)際采用了TDEngine；事件數(shù)據(jù)因具有比較明確的結(jié)構(gòu)特征，仍采用關(guān)系型數(shù)據(jù)庫進(jìn)行存儲(chǔ)，例如，采用了PostgreSQL。

在監(jiān)控站端使用LF EDGE ekuiper 作為流處理核心。LF EDGE 是Linux 基金會(huì)發(fā)起的開源組織，旨在建立獨(dú)立于硬件、芯片、云或操作系統(tǒng)的一個(gè)開放的、可互操作的邊緣計(jì)算框架。作為LF EDGE 下孵化的項(xiàng)目，ekuiper 是一款輕量級(jí)物聯(lián)網(wǎng)邊緣分析、流式處理開源軟件，可以運(yùn)行在各類資源受限的邊緣設(shè)備上。eKuiper 參考了Apache Spark、Apahce Storm 等云端流式處理項(xiàng)目的架構(gòu)與實(shí)現(xiàn)，結(jié)合邊緣流式數(shù)據(jù)處理的特點(diǎn)，采用了編寫基于源（Source），SQL(業(yè)務(wù)邏輯處理)，目標(biāo)（Sink）的規(guī)則引擎來實(shí)現(xiàn)邊緣端的流式數(shù)據(jù)處理。ekuiper 的基本架構(gòu)如圖3 所示。

圖3 ekuiper 的基本架構(gòu)

監(jiān)控站的數(shù)采單元通過modbus 協(xié)議采集二次供水泵站PLC 和其他傳感器的數(shù)據(jù)，并將數(shù)據(jù)轉(zhuǎn)換為MQTT 數(shù)據(jù)包，發(fā)布到監(jiān)控站的MQTT broker（使用Mosquitto）。ekuiper 通過向Mosquitto 訂閱這些數(shù)據(jù)，獲得Mosquitto 轉(zhuǎn)發(fā)的設(shè)備數(shù)據(jù)流。根據(jù)規(guī)則設(shè)定，ekuiper 將一部分需要在云中心即時(shí)顯示的數(shù)據(jù)，直接通過MQTT 轉(zhuǎn)發(fā)布到云中心的MQTT Broker，例如，泵站實(shí)時(shí)出水壓力、實(shí)時(shí)功率等；將不需要在云中心實(shí)時(shí)展示的數(shù)據(jù)，例如，變頻器頻率、電機(jī)三相電流等，存儲(chǔ)在本地，供本地智能應(yīng)用分析使用。

監(jiān)控站各單元產(chǎn)生的事件，也通過ekuiper 匯總后發(fā)送給云中心的MQTT Broker，構(gòu)成事件數(shù)據(jù)流。ekuiper 通過MQTT 接收云中心發(fā)送來的控制數(shù)據(jù)流，并根據(jù)規(guī)則轉(zhuǎn)發(fā)給特定單元，執(zhí)行相應(yīng)控制命令。

基于MQTT 的消息命名機(jī)制，實(shí)現(xiàn)了對(duì)不同數(shù)據(jù)流的分類標(biāo)識(shí)，具體設(shè)計(jì)將在第3 節(jié)中詳述。云中心接收到監(jiān)控端的數(shù)據(jù)流后，流處理引擎根據(jù)分流標(biāo)識(shí)對(duì)數(shù)據(jù)進(jìn)行分流：工況數(shù)據(jù)流將存入時(shí)間序列數(shù)據(jù)庫；事件數(shù)據(jù)流將存入關(guān)系數(shù)據(jù)庫。

2.3 基于標(biāo)準(zhǔn)接口的系統(tǒng)集成

一方面，監(jiān)控應(yīng)用需求不斷擴(kuò)展，為因應(yīng)需求變化，新增或更新相應(yīng)智能應(yīng)用，應(yīng)是平臺(tái)在生命周期內(nèi)的常態(tài)化要求。另一方面，IT 技術(shù)發(fā)展迅速，如何將最適合的IT 技術(shù)不斷引入平臺(tái)內(nèi)賦能，是不斷拓展平臺(tái)功能，提升平臺(tái)性能的重要保證。因此，保證單元接口的標(biāo)準(zhǔn)化是平臺(tái)設(shè)計(jì)的重要原則。

通過對(duì)技術(shù)體系現(xiàn)狀的分析，確定了兩個(gè)層面的集成接口機(jī)制：

（1） 基 于Restful API 的 服 務(wù) 集 成。Restful API 是目前使用最為廣泛的服務(wù)集成方式。通過使用Restful API 能夠?qū)崿F(xiàn)微服務(wù)架構(gòu)，解耦服務(wù)間的緊耦合，提升平臺(tái)的可擴(kuò)展性。平臺(tái)集成的幾個(gè)核心模塊，例如，ekuiper、TDengine 均提供了Restful API，以實(shí)現(xiàn)對(duì)其功能的調(diào)用。在本平臺(tái)中，目前主要在兩種場(chǎng)景中使用Restful API 集成。第一種是在集成調(diào)用以上核心模塊的功能時(shí)。第二種是在作為控制單元的控制臺(tái)（包括監(jiān)控站與云中心的控制臺(tái)）對(duì)外提供對(duì)系統(tǒng)的操作、配置、展示等功能時(shí)，均以Restful API 方式提供。通過該方式可實(shí)現(xiàn)控制臺(tái)核心控制邏輯與使用方式的解耦，例如，當(dāng)實(shí)現(xiàn)控制臺(tái)界面時(shí)，可以靈活選擇各種不同的前端技術(shù)（例如基于瀏覽器的Web UI，或者基于桌面的UI），還可以通過腳本實(shí)現(xiàn)對(duì)系統(tǒng)的自動(dòng)化運(yùn)維。

（2）基于ZeroMQ 的操作系統(tǒng)內(nèi)進(jìn)程間通信。當(dāng)實(shí)現(xiàn)同一操作系統(tǒng)內(nèi)不同智能應(yīng)用間的交互時(shí)，例如，故障診斷應(yīng)用調(diào)用能耗分析應(yīng)用的計(jì)算結(jié)果作為其故障診斷的依據(jù)時(shí)，采用基于ZeroMQ 的操作系統(tǒng)內(nèi)進(jìn)程間通信方式可獲得更高的性能。ZeroMQ 是一種基于消息隊(duì)列的多線程底層網(wǎng)絡(luò)庫，支持線程間，進(jìn)程間、機(jī)器間的消息通訊，提供線程安全的同步接口。

3 協(xié)議設(shè)計(jì)

在2.2 節(jié)中已提到將數(shù)據(jù)流根據(jù)其性質(zhì)進(jìn)行分流是平臺(tái)的核心思想。在具體實(shí)現(xiàn)上，主要依賴對(duì)MQTT 數(shù)據(jù)包的主題（Topic）設(shè)計(jì)，以及流處理引擎對(duì)主題的解析進(jìn)而進(jìn)行對(duì)不同數(shù)據(jù)流的分流。每個(gè)MQTT 數(shù)據(jù)包包括主題與數(shù)據(jù)體(Payload)兩部分。MQTT 規(guī)范除了規(guī)定#與*兩個(gè)通配符外，并未對(duì)主題的設(shè)計(jì)做出其他規(guī)定。因此，利用這種靈活性，設(shè)計(jì)了如下的主題結(jié)構(gòu)：

應(yīng)用名稱/設(shè)備名稱/數(shù)據(jù)流類型/…

應(yīng)用名稱是指整個(gè)平臺(tái)的名稱，例如，對(duì)于二次供水監(jiān)控平臺(tái)，采用拼音首字母命名模式，命名為“eg”。設(shè)備名稱指具體一臺(tái)二次供水設(shè)備的編號(hào)，例如，可命名為“d101”，其中101 是設(shè)備編號(hào)，在前面加入字母是為未來在該應(yīng)用平臺(tái)中加入其他類型設(shè)備預(yù)留空間。數(shù)據(jù)流類型即為以上所述的數(shù)據(jù)流類型，包括設(shè)備數(shù)據(jù)流（d）、事件數(shù)據(jù)流（e）、控制數(shù)據(jù)流（c）。

基于以上規(guī)則，對(duì)于編號(hào)為101 的二次供水泵站的MQTT 數(shù)據(jù)包主題可命名如下：

（1）工況數(shù)據(jù)，“eg/d101/d”，具體的數(shù)據(jù)格式在數(shù)據(jù)體中采用JSON 格式表達(dá)。

（2）事件數(shù)據(jù)，“eg/d101/e/event_name”，其中“event_name”為具體的事件名稱，例如，“online”表示設(shè)備上線事件；“offline”表示設(shè)備下線事件，跟事件相關(guān)的數(shù)據(jù)包含在數(shù)據(jù)體中，例如，“eg/d101/e/online”事件的數(shù)據(jù)體中可包括系統(tǒng)的開機(jī)自檢報(bào)告。

（3）控制數(shù)據(jù)，“eg/d101/c/command_name”，其中“command_name”為具體的控制命令，例如，“reboot”表示設(shè)備重啟命令，收到“eg/d101/c/reboot”命令后，101 號(hào)設(shè)備應(yīng)自啟。

從以上可見，該命名方式具有極大的可擴(kuò)展空間，能夠勝任平臺(tái)未來不斷擴(kuò)展的需要。流處理引擎在接收到MQTT 消息后，將首先對(duì)主題按照命名規(guī)則進(jìn)行分析，分析出數(shù)據(jù)包的來源設(shè)備，數(shù)據(jù)流的類型，并根據(jù)不同類型數(shù)據(jù)流的特定處理方式對(duì)數(shù)據(jù)進(jìn)行處理，實(shí)現(xiàn)數(shù)據(jù)流的分流。

4 應(yīng)用與展望

目前，該平臺(tái)已接入超過100 臺(tái)二次供水設(shè)備。在實(shí)現(xiàn)基礎(chǔ)的遠(yuǎn)程監(jiān)控功能基礎(chǔ)上，進(jìn)一步支撐了智能應(yīng)用的快速開發(fā)和可靠運(yùn)行，包括實(shí)現(xiàn)了發(fā)明專利（CN202010099925.1）《一種邊云協(xié)同的供水設(shè)備能耗監(jiān)測(cè)與能效評(píng)價(jià)系統(tǒng)和方法》中的二次供水設(shè)備能效評(píng)價(jià)算法，為有效降低二次供水設(shè)備能耗奠定了數(shù)據(jù)基礎(chǔ)。未來，平臺(tái)將進(jìn)一步加大二次供水設(shè)備接入量，并通過核心單元集群配置、云原生部署等方式提升平臺(tái)的可靠性和管理效率。