綜合水務信息管理平臺設計與實現

發布時間：2023-07-19 10:31

摘要 I

Abstract II

1緒論 1

1.1課題背景及意義 1

1.2國內發展現狀研究 2

1.3課題概況 3

1.4本文的主要工作及內容結構 4

2關鍵技術介紹 5

2.1后端相關技術 5

2.1.1SpringCloud 5

2.1.2Flowable 工作流 5

2.1.3數據庫技術 5

2.1.4消息推送技術 5

2.1.5ElasticSearch 引擎 6

2.1.6YOLOv3 6

2.2前端相關技術 6

2.2.1Angular 6

2.2.2Ant Design 7

2.2.3ECharts 7

2.2.4Leaflet 7

3系統需求分析 8

3.1功能性需求分析 8

3.1.1綜合信息管理模塊 9

3.1.2實時監測模塊 10

3.1.3常規調度模塊 10

3.1.4巡河管理模塊 11

3.1.5系統管理模塊 11

3.1.6大屏展示模塊 12

3.2用例分析 12

3.3非功能性需求分析 14

4系統設計 15

4.1系統架構設計 15

4.2系統功能模塊設計 18

4.2.1綜合信息管理模塊 18

4.2.2實時監測模塊 23

4.2.3常規調度模塊 24

4.2.4巡河管理模塊 28

4.2.5系統管理模塊 30

4.2.6大屏展示模塊 31

4.3系統安全設計 31

4.3.1用戶權限控制 32

4.3.20Auth2 認證 33

433 SQL防注入攻擊 34

4.3.4HTTPS安全傳輸協議 34

4.4數據庫設計 35

4.4.1概要設計 35

4.4.2數據庫表設計 37

5系統實現 40

5.1綜合信息管理模塊 40

5.2實時監測模塊 44

5.3常規調度模塊 47

5.4巡河管理模塊 48

5.5系統管理模塊 52

5.6大屏展示模塊 54

5.7安全模塊 55

6系統測試 57

6.1測試方案 57

6.2測試用例設計 57

6.3測試結果及分析 59

結論 60

參考文獻 61

致謝 63

大連理工大學學位論文版權使用授權書 64

1緒論

1.1課題背景及意義

水資源是人類賴以生存的資源，水環境的質量決定了人類生存的質量。黨中央、國務院高度重視水資源和水環境工作，于 2015 年 4 月發布《水污染防治行動計劃》，重點治理劣五類黑臭水體；2016 年12 月，中國中共中央辦公廳、國務院辦公廳印發了《關于全面推行河長制的意見》，落實各級河長負責組織領導相應河湖的管理和保護工作，包括水資源保護、水域岸線管理、水污染防治、水環境治理等［1］。國家導向的利好政策為水務市場帶來新的機遇，水利事業蓬勃發展指日可待。

縱觀以往的水務管理方式簡單粗放，管理手段單一落后、缺乏監管督察，從而造成了水資源的浪費、水環境的污染、水生態的破壞。在“互聯網+”的催生下，互聯網與傳統行業深度融合，各行各業從數字化逐漸演變到信息化。互聯網通過將開放、平等、互動等網絡特性在傳統產業的運用，通過大數據的分析與整合，理清供求關系，通過改造傳統產業的生產方式、產業結構等內容，創造新的發展生態。

對于水利行業，“互聯網+”帶來的大數據，可以讓水利工作更加專業：根據流域水量、水位、潮位、氣象、水質等實時監測信息，自動分析流域內水系需求，實現區域內水利設施設備的按需自動調節和控制；移動通訊可以克服水利管理在空間、時間層面的阻礙，可以應對現場性、突發性的水利工作［2］，如水利工程的巡查通過手機端執行，通過GPS、攝像等手段，實現實時巡查地點的上報。

在政策發展的剛需下，深圳坪山區為治理黑臭水體坪山，建立了提升干流水質工程體系。為滿足日后對水質的管理，以及對工程的運營維護，迫切地需要一套完善的綜合水務信息管理平臺。

本系統響應實際需求，從實際情況出發，建立了具備適應性和延展性的坪山河綜合水務信息管理平臺。其中數據實時由傳感器，攝像頭，變送器等設備傳輸到數據庫，通過對數據的處理，分析，顯示來對當地的水利水質情況進行評估、告警，并從大數據中提煉關鍵信息，供相關人員參考輔助科學決策，同時系統能夠根據當前的數據信息來智能地控制設備的開啟與關閉。利用系列工作流操作，對人員進行智能委派來及時解決可能存在的風險與問題。

本文的主要意義在于通過綜合水務信息管理平臺的運行，城市水務部門可以對城市河流展開精細化管理，力保水質達標；在系統匯總分析大數據的基礎上，更好地發現水

務工作中的問題，并為決策提供科學支撐；智慧水務是大勢所趨，現階段的綜合水務信

息管理平臺為后續推動智慧水務建設提供扎實的基礎和良好的經驗。

1.2國內發展現狀研究

國外學者Lahmer等在Gis中實現水環境模擬可視化，類似的，Shin-Jye Linag等人采用三維水動力水質模型WQMAP，可視化臺灣淡水河水動力及鹽度變化的過程［3］°IBM 公司于 2010 年開始推行智慧水資源管理解決方案，利用物聯網技術，數據管理技術可視化技術以及協同辦公技術將供水設備，資產計費設施和各種與系統相關的操作者接收的信息轉為可利用的信息，輔助和引導人們做出相應的決策［4］。美國的“智能水網” 平臺采用地表水和地下水聯合調度，解決了水資源區域空間分配不均以及資源不均的問題［5-6］。M. Safdar Munir等人提出了一種智能灌溉系統(SWS)，并結合Android應用程序，實現了中小型園林和農田的智能用水［7］。

相對于國外的水務信息化技術，國內起步較晚，但發展速度迅猛。目前，水務信息化已經卓有成效，上海、北京和深圳等地已經開展了水務信息化的建設。稅朋勃等人［8］綜合考慮數據信息資源、應用分析功能和地圖管理，進行了北京市基層水務信息管理系統架構設計與實現。彭九敏［9］覆蓋承德市的水務一體化管理信息系統平臺，對行政轄區范圍內水源、取水、供水、排水、防洪、污水處理與回用、農田水利、水土保持、乃至農村水電等所有涉水事務全面實行一體化的信息管理，提高了水資源的優化配置。早期張行南等人［10］研制了上海市中心城區水務信息管理系統。該系統實現了對象的空間分布和屬性的耦合查詢、條件查詢、專題查詢等功能。

現階段智慧水務建設正如雨后春筍一般，在信息化的基礎上增加人工智能，實現真正的全面監測和自動控制的路途，任重而道遠。

對于坪山地區而言，以“上洋斷面水質達標”為核心目標，采用智慧水務的理念，建立坪山河干流的綜合水務信息管理平臺，依托各種數據采集器實時掌握水量和水質信息、并使用相關水利模型實現水質評價、調度等功能，提高應對復雜工況和突發事故的能力，確保坪山河上洋斷面的水質監測達標，坪山安全防護體系如圖 1.1 所示。

1.3課題概況

坪山河的地理位置位于深圳市東北部坪山新區內，在社會經濟飛速發展的大背景下工業污水的大量排放，凈化設備的陳舊落后導致坪山河承擔了過重的污染負荷，使得河流水質下降，嚴重影響到了沿河的生態環境和下游城區的生活環以及居民生活。因此，對于坪山河干流的整治工程主要內容包括了河道防洪工程、水質改善工程、生態修復工程、管線遷改工程等。其中坪山河干流水質提升工程主要包括截污系統、濕地深度凈化系統、調蓄系統、污水處理系統。

（1）截污系統：是面源控制的先決條件，只有對雨后坪山河流域內的截污做得徹底才能夠保障河道的水質。實現該工程的方式是在河道兩側布置了截污井，當降雨產生污水后，會將污水進行阻截，并且根據截污井內的 SS 在線監測儀對其水質進行監測，當漂浮物濃度達到排放標準時，會將其通過管道，傳輸至就近的調蓄池中。當漂浮物濃度沒有達到排放標準時，則匯入河道中。上述過程通過儀器自動控制。

（2）濕地深度凈化系統：它位于系統末端，處理后的污水會匯入坪山河干流的上游端，其水質的優劣直接關乎上洋斷面的水質是否達標，因此如何充分發揮濕地的處理能力至關重要。在污水處理廠處理完后的水，其水質很難達到標準，因此將污水通過水泵將其抽到各個濕地中進行凈化，最后再將其匯入至河流之中。同時，在各濕地受水終端安裝流量監測儀，實時獲取各濕地的配水是否滿足配水方案的要求。

（3）調蓄系統：作為坪山河流域水質提升系統的核心部分，起到承上啟下的關鍵作用，通過截污系統收集污水，有效控制面源污染；并且向水質凈化站和污水處理廠供水，對污水進行處理以及污染物濃度削減。

（4）污水處理系統：是削減污染負荷，提高水質的關鍵環節，也是防止雨污溢流的重要節點，其水質是否達標處理決定著整個坪山河干流的水質狀況。在本工程對流域內 5座水質凈化站進行全方位監測，包括入流水量水質、出流水量水質、水位高低。

1.4本文的主要工作及內容結構

第一章緒論，以項目背景和意義為切入點，主要介紹了課題背景及意義，國內外發展現狀，課題概況以及本文中的主要工作。

第二章關鍵技術介紹，介紹了后臺開發框架 SpringCloud 微服務架構，介紹了關系型數據庫MariaDB以及非關系型數據庫ElasticSearch，介紹前端開發主要采用的 Angular、Ant Design 和 ECharts 等技術。

第三章系統需求分析，從系統的實際業務需求出發，明確系統功能性需求，系統用例以及系統非功能性需求。

第四章是對系統需求分析的基礎對系統進行設計，分別從系統架構設計，系統安全設計，系統功能模塊設計以及數據庫設計出發，闡述了整個系統的設計思路與業務流程。

第五章對系統的各個模塊實現進行詳細地闡述。

第六章對系統的各大功能模塊進行了功能測試并給出了分析結果。

2關鍵技術介紹

2.1后端相關技術

2.1.1SpringCloud

Spring Cloud是一個微服務框架，能夠提供全套的分布式系統解決方案［11］。Spring Cloud 一方面對微服務基礎框架Netflix的多個開源組件進行了完整的封裝，另一方面又實現了對Spring Boot開發框架以及云端平臺的集成。Spring Cloud為開發者提供了快速構建分布式系統的工具，開發者可以快速地啟動服務或構建應用，同時能夠快速地和云平臺資源進行對接。Spring Cloud為微服務架構開發涉及的一系列操作提供了一種簡單的開發方式，其操作包括配置管理，智能路由，一次性token，分布式session，服務治理，熔斷機制，控制總線，微代理，全局一致性鎖‘leader選舉，集群狀態管理等。

2.1.2Flowable 工作流

Flowable是一款基于Java的開源業務流程引擎，核心為BPMN流程引擎，還包括了 DMN決策表和CMMN案例管理引擎。Flowable易于集成，并且自帶REST API。 Flowable流程引擎可以部署BPMN 2.0流程定義（用于定義流程的行業XML標準）、創建這些流程定義的流程實例、進行查詢、訪問運行中或歷史的流程實例與相關數據等。

2.1.3數據庫技術

數據存儲方面采用了 Tk.MyBatis + MariaDB。MariaDB是一款拓展性和功能都優于 Mysql的替代品。相比于Mysql，MariaDB提供了開箱即用的AWS密鑰管理插件，并且MariaDB支持連接線程池，這能為短查詢和CPU密集型的工作負載（OLTP）提供更優的性能。Tk.MyBatis可視為MyBatis與JPA的結合。傳統的MyBatis將SQL查詢語句通過XML文件或Java注解存儲配置并映射實體［12］，但是對于單表操作需要手動編寫，降低了開發效率。引入Tk.Mybatis，能夠為單表操作提供更友好更高效的支持。

2.1.4消息推送技術

系統中使用Spring WebSocket + STOMP +SockJS實現了點對點，點對群的消息推送。

WebSocket是通過單個TCP連接提供全雙工（雙向通信）通信信道的計算機通信協議。WebSocket允許用戶和服務器之間的流連接，并允許即時信息交換。同時，它還會考慮代理和防火墻等危險，使得任何連接都可以進行流式傳輸。它支持單個連接的上游和下游通，減輕了服務器的負擔，允許現有機器支持同時連接［13］。

SockJS是一個瀏覽器JavaScript庫，提供了一個類似于網絡的對象。SockJS提供了一個連貫的、跨瀏覽器的Javascript API，在瀏覽器和web服務器之間創建了一個低延遲、全雙工、跨域通信通道。當游覽器不支持 WebSocket 時，可采用 SockJS 代替來實現功能業務。

STOMP是面向消息的簡單文本協議。STOMP用一種簡單的文本傳輸類型來規定傳輸內容，即交互中的高級協議來定義交互信息。STOMP支持流類型的網絡傳輸協議，包括WebSocket協議和TCP協議。STOMP還提供JS庫供前端使用。

2.1.5ElasticSearch 引擎

Elasticsearch 是一個分布式可擴展的實時搜索和分析引擎，建立在全文搜索引擎 Apache Lucene(TM)的基礎上。Elasticsearch是面向文檔型的數據庫，一條數據以一個文檔形式存儲，用JSON作為文檔序列化的格式。ElasticSearch擁有強大的索引，能夠提高搜索查詢的性能。

2.1.6YOLOv3

YOLO是一種基于單個神經網絡的目標檢測系統。YOLO是將目標分類和定位統一為回歸問題，YOLO網絡不需要RPN,直接對圖像中的目標進行回歸檢測。

YOLOv3是基于v2與vl改進后的算法，用于圖片的目標檢測。YOLOv3在保持速度優勢的前提下，提升了預測精度，尤其是加強了對小物體的識別能力［14］。

YOLOv3是當前性能較好的一個實時檢測系統，相比Fast R-CNN，它的速率要快出許多，現已集成至tensorflow庫中，結合Python的Flask框架能夠方便地集成到現有的 SpringCloud架構之中。本文中采用了 coco數據集，根據后期的需求，會適當地訓練自己的數據集。

2.2前端相關技術

2.2.1 Angular

Angular 是用于設計和構建模塊化的單頁 Web 應用，它是由 Google 維護的一個開源JavaScript框架。Angular通過簡單的指令把頁面結構和數據結合，通過自定義指令實現組件化編程，最大程度地減少了頁面上的 DOM 操作，讓 JavaScript 開發專注業務邏輯，代碼結構更合理，維護成本更低。

Angular繼承了 AngularJS的優點，同時解決了 AngularJS中存在的一些問題，如性能問題(雙向數據綁定帶來的)，Angular中默認使用單向數據綁定，并且整個檢查機制被重寫。AngularJS中路由功能不完善，作用域不靈活，表單驗證顯示錯誤信息比較薄弱等問題在Angular中都得到了解決。同時，Angular使用了 TypeScript語法，給變量加上了類型限制，能夠更好地支持面向對象的開發。

2.2.2Ant Design

Ant Design是一款面向Web應用程序，服務于企業級產品設計體系的前端框架。 Ant Design采用全鏈路開發和設計工具體系，提供了開箱即用的高質量React組件。

Ant Design由TypeScript構建，能夠提供完整的類型定義文件，可以通過對其屬性進行查閱以及修改樣式以達到設計的效果，能夠讓開發者和設計人員致力于更好的用戶體驗。

Ant Design 現已支持 Angular， Vue， React。相比 BootStrap， Ant Design 上手更加容易，操作更加簡易，文檔更加詳備，在Angular中可以使用angular-cli 一鍵式集成。

2.2.3ECharts

ECharts是使用JavaScript實現的圖表庫，兼容當前絕大部分瀏覽器（IE8/9/10/11, Chrome，Firefox， Safari等），底層依賴輕量級的Canvas類庫ZRender，基于BSD開原協議，提供直觀、生動、可交互、可高度個性化定制的數據可視化圖表［15］。

ECharts對React，Angular，Vue等框架都提供了良好的支持。對于本文中使用的 Angular，它提供了 ngx-echarts，為每個組件提供 Angular 扌旨令 options，merge，loading， theme，antoResize等，實現ECharts圖像的加載，主題變化，自適應等功能。ECharts還提供了友好的用戶界面，支持一系列圖形以及數據之間的轉換和保存，提高了用戶的工作效率。

2.2.4Leaflet

Leaflet是一個為移動設備設計的交互式地圖的開源javascript庫。Leaflet支持離線的地圖數據，也支持最新的在線地圖數據，還可以在地圖上進行繪制和修改。

Leaflet支持HTML5和CSS3，能夠適配大多數的瀏覽器，同時也支持插件擴展，有一個友好、易于使用的API文檔和一個簡單的、可讀的源代碼。

3系統需求分析

3.1功能性需求分析

該系統在對業務管理情況，信息化網絡情況和應用現狀進行充分調研后，深入理解了用戶需求，進行如下詳盡的分析。

該系統適用于坪山綜合水務信息管理，包括 Web 端以及移動端，能夠對水務信息提供管理平臺和決策支持，其功能主要包括水質監測，水量監測，工程信息，污水處理情況，告警管理，服務報表，巡河管理，調度分析，用戶管理以及角色管理等。

從業務需求出發，系統主要由綜合信息管理，實時監測，常規調度，巡河管理，系統管理，大屏展示六個部分組成。綜合信息模塊包括工程信息，污水處理情況，工程運行情況，上洋水質以及告警管理。實時監測模塊包括水質監測，水量監測，設備設施監測以及視頻監測。常規調度模塊包括情勢分析，調度規則，調度方案以及方案管理。巡河管理模塊包括巡河方案，巡河監視，方案查詢以及信息錄入。系統管理模塊包括用戶管理，角色管理，菜單管理，部門管理以及臺賬管理。大屏展示模塊包括綜合大屏，凈化大屏，水質大屏，水量大屏以及控制大屏。綜合水務信息管理平臺功能圖如圖 3.l 所示：

綜合水務信息管理平臺

3.1.1 綜合信息管理模塊

綜合信息管理模塊主要分為工程信息，污水處理情況，工程運行情況，上洋水質告警管理以及服務報表。

（1）工程信息：展示整個坪山河干流內所有的涉水工程信息。包括該流域的凈化站、調蓄池、截流井等設備的基本信息，如位置、占地面積等，以及各自的特性信息如處理規模、變化系數等。

（2）污水處理情況：污水處理情況針對凈化系統和濕地系統，向用戶展示了在旨定時間段內凈化站和濕地所處理的污水總量，污染物削減狀況以及污泥堆積情況。

（3）工程運行情況：主要關注的是坪山河干流兩岸的截污井、調蓄池、凈化站人工濕地以及流域內的水情和雨情，實時展示各檢測儀器采集到的相關數據，如截污井在具體時段、具體地段內ss濃度變化曲線，調蓄池的水位、COD、H2S等指標信息的組合圖等，用戶可以了解到具體的工程情況并且實時做出調整決策。

（4）上洋水質：上洋斷面水質分析包括趨勢分析和達標分析。在趨勢分析中，通過水質情況的同比以及環比，得出本時段內水質的提升情況，并通過秩相關法對斷面的數據進行分析，得到各污染物指標的變化趨勢。在達標分析中，通過對水質達標天數的統計、水質類別隨時間的演進以及各主要污染物指標達標狀況的統計分析多維度展示上洋水質的達標情況。河流健康評價的目的是綜合反映河湖生態系統狀況與社會服務功能狀況，及時反饋治理效果，便于后期調整規劃［16］。針對坪山河干流的河流健康評價體系包括目標層和決策層，目標層為河流健康，準則層根據需要選擇完整性準則、河長制任務兩大類，每類賦予不同的權重，經計算得到河流健康賦分。

告警管理

告警詳情

圖3.2 告警管理結構示意圖

Fig. 3.2 Schematic diagram of alarm management structure

（5）告警管理：根據監測設備上傳的水情、水質、水位、設備運行狀況等數據，進行數據統計與分析，對異常信息發出告警。告警管理功能結構如圖 3.2 所示。告警分為兩個功能：告警詳情和告警查詢。其中告警詳情主要是以不同的告警狀態區分顯示上洋斷面水質超標，上洋溢流，河道水位超標，截污井閥門狀態異常，調蓄池H2S濃度超標，濕地進水超負荷等報警信息。告警查詢主要提供對上述六個對象的告警事件的查詢。查詢內容既包括實時水質、水位、水量以及設備運行異常告警信息，也包括歷史的累計告警信息。

（6）服務報表：服務報表分為巡河報表與工程報表，巡河是日常任務，在巡河任務執行過程中，發生的異常事件都會被記錄。該功能對具體時間段內的巡河事件和特定的巡河類型進行統計并以圖表展示，讓用戶能夠了解到坪山河的近況。工程報表主要是對凈化站和濕地處理的污水量與污染物削減量進行統計和展示。

3.1.2實時監測模塊

實時監測主要分為水質監測，水量監測，設備監測以及視頻監測。

（1）水質監測：主要對支流、截污井、凈化站、人工濕地，上洋斷面水質進行實時監測，監測到異常后觸發告警事件。

（2）水量監測：主要對坪山河干流中各個水文站中的水量水位進行實時的監測，監測到異常后觸發告警事件。

（3）設備運行狀態監測：主要對設備運行狀態進行監測，若出現異常則進行報警處理。

（4）視頻監測：主要對沿河偏僻地段進行視頻監測，若監測到人或物數量超過一定閾值，則進行報警處理。

3.1.3常規調度模塊

常規調度主要分為情勢分析，調度規則，調度方案以及方案管理。

（1）情勢分析：主要包括污水量預測信息與降雨預報信息等，這些信息是各工程系統制定調度計劃的依據。污水量預測主要是根據歷史污水量數據，結合天氣、人口、生活污水、溫度等相關因素對當天及未來七天的生活污水量進行預測，預測數據由污水處理廠提供；降雨預報信息主要是通過將平臺與GFS等降雨預報產品耦合，及時獲取降雨預報信息，為調度計劃的制定提供基礎信息。

（2）調度規則：展示與調整調蓄池、凈化站以及污水處理廠在旱時，雨時以及雨后的調度規則。

（3）調度方案：根據當天的污水預測情況以及具體的工況，制定合適的方案。

（4）方案管理：供查詢的歷史調度方案庫，詳細記錄了各方案的編制時間、執行時間、調度目標、編制人等信息，既是對工程調度運行方案的記錄，也可為新方案的編制提供參考。

3.1.4巡河管理模塊巡河管理主要分為巡河方案，巡河監視，方案查詢以及信息錄入。

（1）巡河方案：主要用于下達巡河任務，并對巡河方案進行管理，包括當前巡檢方案、巡河人員值班表以及月巡檢工作記錄三大塊內容。

（2）巡河監視：結合巡河App的定位功能，在坪山河地圖上實時顯示巡河人員的巡河軌跡，同時可在地圖上顯示異常提醒，并展示異常問題的詳細情況，方便管理人員實時掌握當前巡河工作進展及河道情況。

（3）方案查詢：巡河工作結束后，巡河人員需在 App 端及時上傳當次巡河記錄，包括巡河任務的起止時間、有無發現異常情況、異常問題描述、處理結果及異常節點照片等。PC端結合巡河方案模塊中下達的巡河方案和App端上傳的巡河記錄，生成完整的巡河方案記錄。在系統中通過數表的形式對坪山河流域內所有巡河方案及事件處理情況進行匯總管理，并提供方案查詢、導出功能。

（4）信息錄入：由于發生特殊情況，設備損壞或者是其他因素導致儀器無法記錄正確的數據，需要采用人工的方式錄入信息。

3.1.5系統管理模塊系統管理主要分為用戶管理，角色管理，菜單管理，部門管理以及臺賬管理。

（1）用戶管理：對系統用戶進行管理，管理的內容主要為用戶的個人信息。

（2）角色管理：對于不同的用戶，給與不同的角色，不同的角色擁有不同的權限 [17]，如管理員對系統的操作是不受限制的，并且可看到所有菜單內容，但是對于隊長而言，系統管理模塊是不可見的，并且部分操作是受限的，對于隊員而言，僅有巡河管理模塊和綜合信息管理模塊中的部分內容是可操作的。

（3）菜單管理：系統的前端資源并不是固定的，可以通過菜單管理進行動態的配置，為其配置上資源路徑以及資源名稱等信息。

（4）部門管理：對用戶部門進行管理，新用戶注冊后，都需要為其分配部門與角色才能登入到系統中。不同部門的用戶擁有不同的職能。

（5）臺賬管理：反映各種類型設備的數量、購入價格、運行狀態、設備分布及其變動情況等信息。

3.1.6大屏展示模塊

大屏按照1+4的模式，主要提煉了關鍵的工程信息以及當前設備的運行狀態，使用戶能夠快速地了解到整個工程的作用。

（1）綜合大屏：主要用于展示坪山地區所有設備以及水質變化情況。

（2）凈化大屏：主要用于展示凈化系統處理污水的能力及實時狀態。

（3）水質大屏：主要用于展示水質信息的實時狀態。

（4）水量大屏：主要用于監測各設備水量信息的實時狀態。

（5）控制大屏：主要用于展示和查看坪山河沿岸可控的設備信息。

3.2用例分析

通過功能需求分析的論述，坪山綜合水務信息管理平臺共需完成六大模塊的設計與實現。接下來將給出用例圖清晰展示。

綜合水務信息管理平臺的角色主要分為3種，分別是管理員，隊長以及隊員。不同的角色擁有的權限不同，用例也不同。圖3.3展示了隊員的用例情況，隊員的核心任務是處理坪山河的告警以及巡河任務，他們需要經常外出去執行任務，并且根據處理結果及時反饋情況。

工程信息查看

受巡河

一一＜＜包含〉〉丿

--Y〈包含〉〉-----＜提交巡河任務》

〈＜包含〉〉-?

__逅饋巡河任務

圖3.3 隊員用例圖

Fig. 3.3 Team member use case diagram

系統管理員擁有系統所有的功能權限，并且能夠對不同角色的權限進行配置。圖3.4

展示了管理員的用例情況。隊長相比管理員少了系統管理與智能調度。

（工程信息查看）

///「工程運行情況查詢

＜〈包含＞＞ / "

/'〈＜包含〉c上洋水質查看；■＞「〈包含〉廠一一C告警委派＞ ――一一接受＞二二二＜＜包含〉〉匕書警查詢》

＜＜包含〉〉、 —

'、、、「＜〈包含〉〉、、「?ii告警審核n

＜〈包含〉〉—

、、、、O警反饋二）

（服務報表修改）

＜＜包含〉〉__£各種實時監測信息查看〉

□勢查°

＜〈包含〉〉"一 k 、

二＜＜包含〉〉一一一-窪規則修改一-＜〈包含〉〉—©度方案查看

河發起》

一一-一〈＜包含〉〉■一…一

—〈＜包含〉〉——c巡河接受〉

二二＜＜包含〉〉—一十十一、

＜〈包含〉〉（巡河提交及反饋

（查詢巡河任務

3.3非功能性需求分析

在設計綜合水務信息管理平臺時，除了對系統的功能性需求以及系統用例進行分析外，還需要對系統的非功能性需求進行分析。本文將從如下幾個方面來對系統的非功能性需求進行分析。

（1）性能需求綜合水務信息管理平臺為保證有效地分析展示數據，需要從不同儀器設備中高頻地接受相關數據，數據量大且數據接收頻率高，為防止由于斷電或者網絡波動引起的數據丟失，需要平臺能高并發并且穩定運行。穩定運行要求平臺能夠在全天24小時內平穩運行，平臺的容錯率和錯誤恢復能力都是重要的考察指標；高并發則要求平臺在支持多個服務的同時能夠接收與處理數據，并且對于歷史數據能夠及時處理，統計并存儲。

（2）可維護性需求平臺發布以后，需要不斷地對平臺進行升級或者漏洞修復，因此需要平臺具有較高的可維護性。可維護性體現在以下兩個方面：

①平臺可以簡單快速地發布和部署。開發人員發布平臺軟件后，使用者可以快速獲取并部署。

②平臺能獲取最新版本升級，并能快速恢復服務。當新版本平臺軟件發布后，使用者可以快速獲取進行升級，并能快速恢復中斷的服務。

（3）可移植性需求

平臺的可移植性是考察該平臺是否強健的標準之一，如今硬件設施多種多樣，為了保證綜合水務信息管理平臺能夠方便快捷地部署到相應的設備服務器上，對平臺架構的可移植性要求較高。同時，代碼開發版本更替的過程中，新版本應盡量地兼容舊版本。

（4）安全需求系統的安全既是一個必要的組成部分，又是一個重要的考量指標。系統的安全需求包括以下幾個方面：

①系統完整性：系統內存儲、傳輸的數據，必須保證其完整性，所有對數據進行的操作，必須通過系統提供的合法接口，只有擁有該權限的用戶才能夠進行操作。

②系統保密性：系統內存儲、傳輸的數據，必須經過加密或者保護，防止數據被非法篡改和泄露。

③系統防護性：系統能夠抵抗一系列的安全攻擊，確保系統的正常運行以及數據的完整性和安全性。

④系統可維護性：系統具有一定的備份機制、容錯機制，在出現問題和錯誤時能夠進行自動修復或者提供維護機制。

4系統設計

4.1系統架構設計

綜合水務信息管理平臺的概要設計架構如下圖4.1所示。

開發架構執行架構運營架構

交互應用集成

1版本控制1 1 部署 1

Web、移動端、大屏、三維 1 規則引擎 1 1 消息 1

1代碼構建1 1 配置 1

1 API 1 1 規則引擎 1 1 連接集成 1

1代碼管理1 1個性化，社交化1 1 人工智能 1 1工作流引擎 1 1 監控 1

1 搜索 1 服務化 1 1 元數據管理 1

1持續集成1 1可靠性1

1 語音識別 1

1 分布式部署 1 1 主數據管理 1

1代碼分析/檢查1 1 內谷管理 1 1 恢復 1

1 內容分發 1

1持續部署1 1 國際化 1 1 治理 1

1自動測試1 1緩存II同步鎖II日志和審計1公共模塊1索引和搜索II歸檔II安全1 1安全丨

基礎架構

云計算平臺［計算莖儲迥絡安全

數據中心（機房） 1呼和浩特1 1北京1

圖4.1 整體概要架構

Fig. 4.1 Overall outline architecture

在平臺開發過程中，開發框架應當考慮項目的版本控制，代碼構建，代碼管理，持續集成，代碼分析/檢查，持續部署以及自動測試。

在執行架構中，應當考慮項目的用戶交互、應用、集成和公共模塊的設計。在運營架構中，應當考慮項目的部署，配置，監控，可靠性，恢復，治理和安全。基礎設施的安全也是尤為重要，數據中心的建立應該選擇不同的地點，異地容災。針對上述的系統概要分析，本文進行了如下詳細架構的設計，如圖4.2所示，開發架構是系統開發過程中所使用的一些工具，系統中使用Visual Studio Code進行前端代碼的編寫與調試，使用Intellij IDEA進行后端SpringCloud相關代碼的開發，使用Git對代碼進行版本控制以及代碼管理，使用Jenkins對代碼進行持續集成、持續部署和代碼檢測，使用NPM作為前端的包管理工具，使用Maven作為后端java的包管理工具。

（初基使設用施阿里云）openstack 計算-Nova 存儲-Swift/Cinder 網絡-Neutron

圖4.2 整體詳細架構

Fig. 4.2 Overall detailed architecture

運營架構是系統在運行和部署時使用的工具，使用Jenkins對代碼進行持續的集成、發布、部署，以保證代碼的可靠性，使用 docker 對微服務進行封裝和運行，使用 kubernetes對docker進行容器編排、管理與監控。

執行架構是系統在開發和運行過程中使用的相關技術，主要包括如下五個部分：

（1）交互：使用Angular作為前端開發框架，使用Echarts對前端圖形進行繪制，移動端開發中使用了 ionic+Angular進行混合編程，開發過程中使用Leaflet庫來對坪山地區的地圖進行繪制。

（2）負載均衡：使用Nginx對請求進行負載均衡以及轉發，進行雙機熱備份預防宕機帶來的危害。

（3） SpringCloud微服務架構：使用SpringCloud框架作為后臺開發框架，它是一系列可用框架的有序集合，實現了服務注冊，服務配置，服務間調用，負載均衡以及斷路器等功能。

（4）公用模塊：使用 Redis 進行數據緩存（用戶信息 session、token 等），使用 Elasticsearch搜索引擎進行全文索引，使用SpringSecurity安全框架進行用戶登錄認證和權限控制，使用 Tensorflow 庫作為數據處理，圖像處理的基礎，使用 Tk.MyBatis 對數據進行持久化操作。

（5）集成：使用了 RabbitMQ作為消息代理通道。

基礎架構方面使用openstack與kubernetes搭建谷器云平臺(目前使用阿里云)。綜合水務信息管理平臺在縱向上劃分可分為三層，分別是表示層，應用層，和數據層，如下圖4.3所示。

圖4.3 整體功能交互架構

Fig. 4.3 Overall functional interaction architecture

(1)表示層：將H5+Angular+ionic代碼構建后放入Nginx服務器中運行。

(2) 應用層：使用了 Consul， Gateway， Config， Sleuth， Turbine 與 Hystrix。

Consul是google開源的使用go語言寫的服務發現、配置管理中心服務，它部署簡單，不依賴任何其他的工具，SpringCloud將服務注冊至服務中心。ApiGateWay用于轉發用戶請求，屬于正向代理，它將請求轉發至相應服務進行處理，在轉發請求的各個階段都可以進行攔截。Config用于管理所有微服務的配置信息，方便配置的統一維護與修改。Sleuth用于鏈路跟蹤與問題排查，能夠對方法的調用過程與耗時進行追蹤與調試。 Turbine用于服務監控，檢測服務健康狀況。Hystrix提供了容錯保護機制，用戶請求異常或微服務異常時進行服務降級與熔斷。系統中還存在若干業務微服務，如公用服務認證服務，巡河告警服務，工作流服務，水務信息服務，圖像處理服務等等。每個服務針對獨立的業務且可相互協作。

(3)數據層：主要用作數據倉庫與數據存儲，目前使用阿里云。

4.2系統功能模塊設計

坪山河綜合水務信息管理平臺包括綜合信息管理，實時監視，常規調度，巡河管理

系統管理和大屏展示這六大模塊，如下圖 4.4 所示。

綜合水務信息管理平臺

圖4.4 綜合水務信息管理平臺功能圖

Fig. 4.4 Integrated water information management platform function map chart

其中綜合信息模塊包括工程信息，污水處理情況，工程運行情況，上洋水質以及告警管理。實時監測模塊包括水質監測，水量監測，設備設施監測以及視頻監測。常規調度模塊包括情勢分析，調度規則，調度方案以及方案管理。巡河管理模塊包括巡河方案，巡河監視，方案查詢以及信息錄入。系統管理模塊包括用戶管理，角色管理，菜單管理，部門管理以及臺賬管理。大屏展示模塊包括綜合大屏，凈化大屏，水質大屏，水量大屏以及控制大屏。以下對每個模塊的核心功能進行設計。

4.2.1 綜合信息管理模塊

綜合信息管理主要是對坪山地區工程情況以及告警情況進行管理與展示，以下對每個功能的設計進行闡述。

(1)工程信息

工程信息頁面用于展示坪山地區的具體工程情況。當用戶需要查看具體工程情況時選定具體位置能夠在地圖上看到該地基礎信息，包括位置、類型、編號，實時信息、設計信息與占地面積等等。其具體流程如圖4.5所示，首先前端獲取后臺的地圖數據進行初始化地圖，由于站點的信息較多，并且存在變化，當用戶選擇站點時，調用后臺接口獲取具體站點信息。

圖4.5 工程信息流程圖

Fig. 4.5 Engineering information flow chart

(2)污水處理情況

污水處理情況的分析主要針對凈化系統和濕地系統，以豐富的圖表展示了凈化站和濕地對污水的凈化效果以及耗能情況。處理污水量通過監測數據累積獲得，污染物的削減需根據污染物的進出量進行進一步的計算，污泥主要分成固體柵渣和剩余污泥，二者均要運送至固體垃圾處理中心進行處理，因此統計產生量對于處理成本至關重要。從安全角度考慮，連續天責任傷亡事故日是凈化站的考核指標；單位水量電耗和能源自給率的數據均需要凈化站的中控系統進行上傳。

(3)工程運行情況

工程運行情況主要用于工程信息查詢，便于管理人員查看歷史信息，該模塊可自動獲取實時監測信息，也可由管理員修改相關信息。圖4.6展示了具體查詢流程，用戶可

以根據時間尺度、工程對象、時段等條件查詢相關信息，數據會以表格、圖形等方式展

示，圖下配有時間軸，通過拖動靈活地聚焦要查詢的數據。

（4）上洋水質

工程的建設和本平臺的建立都是為保障上洋斷面水質達標，在實時監視掌握了斷面水質情況的基礎上，將所得數據進行充分的數據挖掘，做到全面了解斷面水質的污染情況及發展趨勢。因此，綜合水務平臺從多種角度對上洋斷面水質進行了分析和評價，主要包括達標分析、趨勢分析、河流健康評價等，下面主要對達標分析與趨勢分析進行詳細說明。下圖4.7為達標分析數據處理流程圖。

無論是支流、凈化站出水、濕地出水還是上洋斷面水質的達標分析，都是采用了達標率這個指標，通過餅圖和雷達圖均可清晰展示各部分的達標情況，其達標率的公式如下：

趨勢分析分為兩個部分，第一部分是不同時段水質變化趨勢分析評價，主要是獲取指定時間段內的上洋斷面水質情況，之后以斷面水質類別比例的變化為依據，按組合類別比例法進行評價。

圖4.7 達標分析數據處理流程圖

Fig. 4.7 Compliance analysis data processing flow chart

第二部分是多時段的變化趨勢評價，主要是根據指定時間段內污染物的濃度變化繪制濃度趨勢圖，對污染物濃度與時間序列進行相關性分析，可采用 Spearman 秩相關系數法［18］，檢驗相關系數和斜率的顯著性意義，確定其是否有變化和變化程度。最終變化趨勢可用折線圖來表征。圖 4.8 為趨勢分析數據流程圖。主要是獲取同比、環比的數據以及污染物濃度趨勢數據，根據上述指標函數運算得出結果并返回給前端。

圖4.8 趨勢分析數據流程圖

Fig. 4.8 Trend analysis data flow chart

（5）告警管理告警管理模塊是對于設備、水質等相關問題進行告警處理。采用了工作流引擎

Flowable進行集成，將業務和流程分開，并且根據微服務的概念，將告警業務代碼與工作流相關的代碼分別放在兩個微服務中。告警微服務對每個告警階段對應的功能進行編寫，如反饋告警事件，委派告警事件與審核事件等等。工作流微服務對整個流程進行繪制并調用告警微服務代碼進行業務操作。當需要修改告警流程時，只需要修改工作流微服務中的BPMN流程圖，對告警微服務并不影響。對于傳統的方式，流程和業務代碼耦合度高，易導致后期維護成本較高。

告警流程泳道圖如圖 4.9 所示，整個告警的流程可分為如下幾個步驟：

①設備發現異常，并上傳異常至系統之中。

②管理員收到異常提醒，查看告警管理。

③委派告警事件給相應部門人員。

④部門人員接受委派并處理告警任務。

⑤部門人員處理完后，對告警任務進行反饋并等待管理員審批。

⑥若管理員審批通過則完成事件，若沒有通過則撤回告警事件重新委派。

圖4.9 告警流程泳道圖

Fig. 4.9 Alarm flow lane diagram

4.2.2實時監測模塊

實時監測模塊主要是對水質、水量、設備、視頻圖像等信息進行實時監測與反饋。當水質，水量與設備發生異常時會觸發告警事件并在地圖上顯示，管理人員可通過監測頁面跳轉至告警事件詳情頁進行處理。圖4.10為水質、水量監控的時序圖，主要可以分為如下幾個步驟：

（1）水質，水量采集設備實時采集并傳輸數據，若存在異常則生成告警事件。

（2）前端定時讀取水質、水量信息與告警信息。

（3）后端獲取并處理數據返回給前端。

（4）前端展示并標注告警信息。

（5）管理員可根據告警信息跳轉至詳情頁。當視頻監測出現異常時，管理員需要聯系相關人員前往現場進行處理。視頻監測中，

使用了 Python的Flask框架搭建相應的服務，并通過Tensorflow機器學習庫中的Y0L0v3 算法對目標進行檢測，具體處理流程如下所示：

（1）攝像頭每隔一段時間會上傳一張監測圖。

（2）后臺使用coco數據集并采用YOLOv3算法對目標物體進行檢測與識別。

（3）檢測結果記錄到數據庫中并返回前端進行展示。

（4）當物體的數量超過一定閾值時，會觸發報警。

（5）管理員獲取報警信息，聯系相關人員處理問題。針對上述流程，本文將在系統實現部分，對水質監測以及視頻監測部分的實現進行

詳細闡述。

用戶 Moni torComponent Monitor Controller Monitor

Service 設備

; 循環丿；； 1

訪問A 一實時監控 while ( True）

_刷新告警事件列表. 調用 getAlarmList（）一讀取告警事件調用A ge tAl lAl armL ist（）

w-返回處理結果 ?設備告警

0 — uploadAlarm()

— ‘八4? 土敬 JL

y 設備口警

返回可視化界面數 formatA

W—返回處理后數據…― 據

l 處理 rmData()

、 1

1-1 1

圖4.10 水質、水量監控時序圖

Fig. 4.10 Water quality and water quantity monitoring timing diagram

4.2.3常規調度模塊

常規調度模塊主要功能為情勢分析，調度規則，調度方案以及方案管理。情勢分析是接收凈化系統上傳的污水量和從氣象系統接入的溫度、降雨的數據，主要是刻畫未來的天氣條件，成為日后工程調度的基礎。

每個工程都有本身的調度規則，截污井的調度規則是控制閾值，調蓄池的調度規則是在收納和排放初期雨水的優先級，而凈化站的調度規則是每日凈化站的處理能力，既有保底水量，也有最大負荷。

調度方案涉及當前方案展示，方案創建，默認方案切換以及方案量質平衡圖。調度方案的具體流程見圖 4.11。調度方案根據工況分為旱時、雨時和雨后三種，旱時采用單目標優化模型；雨時與自動控制聯動，智能響應；雨后的模型類似于水庫群調度，采用迭代模型以最大量進行逐時段決策泄流。

方案管理主要是篩選編制人、執行時間、模型類型等信息，查詢歷史方案。

圖4.11 調度方案流程圖

Fig. 4.11 Scheduling scheme flow chart

（1）旱時調度在旱時，由于沒有降雨，系統里是生活污水，因此旱時要完成的調度是向凈化系統分配污水。凈化系統分為兩個凈化站與一個污水處理廠，凈化站包括南布凈化站與碧嶺凈化站，污水處理廠為上洋污水處理廠。凈化站的出水標準為IV類，處理效果好、處理能力低、單方成本高，污水處理廠的出水標準為一級A,處理效果一般、處理能力高、

單方成本低。在此前提下，污水的分配存在成本和水質的對應關系，在工程運行中需要

建立至少保證上洋斷面的水質達標的水質-成本優化模型，在數學中抽象成單目標優化問題，利用線性規劃求解。優化模型是建立在水質模型的基礎上，由于坪山河干流是淡水河一級支流，河長僅十幾公里，沿岸的排污口均被截污系統截留，并且結合坪山河河道窄，流速平穩特性，所以采用零維模型來描述坪山河干流污染物在水中的混合過程。

E = min琨iQ^

P = min扌爲=1呀

公式 4.2 和4.3能夠分別作為目標函數，其約束條件為：

L = SF=1 Qi

Q嚴 <Qi< Q^ax

公式 4.2 為成本最低方案的目標函數，由于凈化站和污水處理廠處理污水都需要一定的成本，為了使成本最低，建立了上述的目標函數，其中@表示凈化站和污水處理廠的污水處理量，At表示它們分別的單方成本。公式4.3為水質最優方案的目標函數，P的含義是坪山河最低平均污染物濃度，嗎1表示各污染物的濃度。兩個目標函數可以根據用戶的需求進行組合，例如在系統上線的初期，為力保上洋斷面水質達標，可以在不考慮成本的情況下，讓水質目標函數最小，后期經歷長期運維，可能需要成本最低，即第一個目標函數最小，如果兩個都需要考慮則可以組合成多目標方程來求解。

公式 4.4 為水量平衡約束，需保證所有凈化站或污水處理廠處理的污水量之和等于總的生活污水量，其中L表示生活污水量，Qt表示各凈化站和污水處理廠的污水處理量。其中i表示站點的次序。

公式 4.5 為處理負荷約束，需保證每個凈化站或污水處理廠處理的污水量應當大于該設備的最小能力，小于其最大能力，其中Q嚴"為最小處理量，Q嚴皿為最大處理量。

對于坪山河流域，污水經由凈化站處理后直接匯入河流中，在此過程中，造成了一次流量損耗以及一次污染物濃度衰減。污水經由污水處理廠處理后，再通過人工濕地處理并匯入河流中，在此過程中，造成了兩次流量損耗以及兩次污染物濃度衰減。

公式 4.6 為上洋斷面水質約束，需要保證上洋斷面的水質滿足河流的水質標準。主要針對河流之中四種典型污染物（COD, NH3-N、TP、TN）進行約束，其中％"為上洋斷面各污染濃度，臨為河流的水質標準污染物濃度。上述公式中，n對應污染物的類型。

公式4.7為上洋斷面各污染濃度的計算公式，其中表示經凈化站處理后污染物的濃度，Kn表示經污水處理廠處理后污染物的濃度，a表示經污水處理廠或者凈化站處理后的流量損失系數，B表示經濕地處理后的流量損失系數，Yn表示經濕地處理后污染物的濃度，表示各支流的流量，聲表示各支流污染物的濃度，Qi、Q2、Q3分別對應分配給南布凈化站、碧嶺凈化站與上洋污水處理廠的生活污水量。上述公式中，n對應污染物的類型。

公式4.8為河流水質標準污染物濃度的計算公式，G"為國標的污染物濃度。在公式中，n對應污染物的類型。

在系統實現部分將給出實現代碼。

（2）雨時調度

雨時，由于降雨產匯流存在時間和空間的不確定性，管網水力條件復雜，無法準確模擬管網內的水動力情況，且截流井內和調蓄池內本身存在水質監測儀和自動控制，所以根據后臺判斷調蓄池進水特征，自動在雨時將工程的處理能力根據調度規則開啟至最大，由截流井和調蓄池根據水位和水質自動收納污染嚴重的初期雨水。

（3）雨后調度

經歷了雨時，截留進入系統的初期雨水，被存儲在七個調蓄池中。雨后，出于工程安全的考慮，以及要為下次降雨做準備，需盡快將調蓄池內的初期雨水排入系統，通過管網運輸到末端的上洋污水處理廠進行處理。上洋污水處理廠需不停歇的對生活污水進行處理，如果七個調蓄池同時放水，產生的流量會超過上洋污水處理廠的最大能力，因此需要充分利用污水處理廠處理生活污水的余量，協調調蓄池的放水順序和流量，使得每小時的流量能夠達到最大值。

根據工程實況，碧嶺調蓄池、南布調蓄池以及墩子河調蓄池，可以和附近的碧嶺凈化站、南布凈化站以及墩子河凈化站配套使用，直接將水輸送到附近的凈化站進行處理，不需要再通過管網輸送到上洋污水處理廠。其余四個調蓄池閥門的啟閉成為雨后調度的對象。圖4.12為調度的流程圖。

具體流程可分為如下幾步：

①獲取污水處理廠預測數據，各個調蓄池水位情況以及調蓄池的排放能力等參數。

②每個小時的最大排水量，排水量需要滿足上洋污水處理廠最大處理能力的約束。

③當每個調蓄池水位都為0時，結束計算。

④將計算出的結果整理統計后返回給用戶。

圖4.12 雨后調度流程圖

Fig. 4.12 Post-rain scheduling flow chart

4.2.4巡河管理模塊

巡河管理主要用于管理和控制巡河任務的整個生命周期，包括巡河任務的創建，委派，審核等。相比告警管理，巡河管理的業務流程更為復雜。巡河任務是日常任務，在巡河過程中，記錄了巡河人員的巡河路徑，巡河任務的處理結果，巡河過程中的異常節點等，具體流程如圖4.13所示，可分為如下幾個步驟：

(1)管理人員在巡河方案中發起巡河事件。

(2)巡河人員接受巡河。

(3)巡河人員開始巡河，App記錄巡河軌跡。

(4)巡河過程中，若發現異常，上報異常并緊急處理。

(5)剩余人員繼續巡河，遇到步驟4中的情況則反復執行。

(6)巡河結束后，上報所有異常節點及處理情況。

(8) 管理人員根據實際情況對異常事件進行審核。

針對巡河管理模塊的執行流程，將對巡河方案，巡河監視與方案查詢進行詳細闡述。

(1)巡河方案

巡河方案主要用于記錄當天的巡河情況，可以從巡河方案進入巡河詳情頁，查看巡河的詳細情況并及時處理。

（2）巡河監視

巡河監視主要用于記錄巡河軌跡以及異常問題情況，主要使用了 Leaflet 對坪山地圖進行繪制，對巡河軌跡進行追蹤，對異常事件進行標注。其中巡河軌跡的追蹤部分結合手機App的GPS定位功能進行實現。

（3）方案查詢

方案查詢主要用于查詢巡河的歷史記錄，本文采用ElasticSearch作為搜索引擎以方便用戶查詢到想要的信息。當用戶新增，刪除，修改巡河任務時，向RabbitMQ發送消息，由監聽RabbitMQ的服務接收到消息并對ElasticSearch中的數據進行增刪改操作。當用戶對巡河記錄進行查詢時，后臺根據關鍵字在ElasticSearch中獲取記錄的編號，再通過編號到MariaDB中找到所有的相關記錄返回給前端。

圖4.13 巡河管理流程圖

Fig. 4.13 River management flow chart

4.2.5系統管理模塊

系統管理主要是對用戶信息，用戶角色，角色權限等內容進行管理。系統管理主要包括用戶管理，角色管理，菜單管理，部門管理和臺賬管理［19］。

在圖4.14中，展示了用戶登錄以及權限配置的過程，整個過程可以分為如下幾步：

(1)老用戶可通過賬號密碼直接登錄，新用戶需要完善個人信息注冊新賬號并由管理員分配部門與角色后方可登陸。

(2)管理員為新用戶分配部門與角色。

(3)若為新用戶分配的部門不存在或需要修改，創建或修改部門信息。

(4)若為新用戶分配的角色不存在或需要修改，創建或修改角色信息。

(5)配置完權限的新用戶可成功登陸系統。針對上述流程，本文將在系統實現部分，對用戶管理，部門管理和角色管理部分的實現進行詳細闡述。

圖4.14 系統管理流程圖

Fig. 4.14 System management flow chart

4.2.6大屏展示模塊

大屏展示模塊主要展示了關鍵的工程信息以及當前設備的運行狀態，分為綜合大屏凈化大屏，水質大屏，水量大屏以及控制大屏。圖 4.15 為大屏展示的流程圖，大屏展示大致流程如下：

（1）選擇某一大屏進行展示。

（2）前端設置定時器獲取地圖信息與統計數據。

（3）后臺查詢數據并根據相關模型計算后返回結果。

（4）前端獲取返回數據，渲染頁面內容。

圖4.15 大屏展示流程圖

Fig. 4.15 Large screen display flow chart

4.3系統安全設計

對于系統的安全設計，從以下四個方面考慮：

（1）系統級安全系統級安全是安全防護的第一道屏障，用戶在訪問系統時，必須要經過登錄授權和訪問認證，確保用戶身份的真實性和可靠性。

（2）程序資源訪問控制安全

不同權限的用戶，只能對其權限下的程序資源進行訪問。系統采用RBAC模型，將用戶通過角色與權限進行關聯，用戶可以綁定不同的角色，角色也可以綁定不同的權限，在確保程序資源訪問控制的安全下，能靈活進行管理。

（3）功能性安全功能性安全會在一定程度上對系統程序流程產生影響，因此在設計系統的時候就需

要詳細考慮。用戶在進行操作時，系統會校驗數據的合法性，確保交互的數據是準確可靠的。

（4）數據安全

數據安全包括兩個方面，數據傳輸安全以及網絡安全。數據傳輸安全能保證系統的數據在傳輸時不會被竊取和篡改，既確保了數據的可靠性和完整性，又能保護敏感數據的安全性。網絡安全能保障系統的正常運行，同時確保了數據的規范性。

對于以上安全設計的考慮，系統使用了 0Auth2認證，用戶權限控制，SQL防注入攻擊以及HTTPS安全傳輸協議等，下文將進行詳細闡述。

4.3.1用戶權限控制

根據業務需求，系統的用戶權限控制采用粗粒度權限管理。

不同的用戶屬于不同的角色，不同的角色擁有不同的權限，如管理員持有最高的權限，能夠對部門信息，用戶信息，用戶角色進行修改和刪除，而普通操作員只能擁有部分權限。嚴格的權限控制能夠保證系統的安全與高效。

本文中權限管理主要包含兩部分，一部分是后臺的權限控制，在服務端對 URL 程序資源和業務服務類方法的調用進行訪問控制，當用戶沒有權限時，無法通過 Postman 等工具訪問到該接口的任何內容。另一部分是前端的視圖控制，系統中為所有的控件加上 ACL 指令標識，標識的內容與用戶的權限相對應，并且根據用戶的權限進行顯示與隱藏。

系統采用 RBAC 模型，權限數據保存在數據庫之中，由五個表組成權限控制模塊，避免進行非法修改。用戶表中存儲用戶信息，角色表中存儲角色信息，資源表中存儲所有資源，如按鈕、頁面等資源的url，用戶角色表是用戶表和角色表中的對應關系表，角色資源關系表是角色表和資源表的對應關系表。除了資源表是由開發人員維護，其他的表都是由業務人員進行維護。

在后臺代碼開發中，用戶權限控制需要獲取到用戶的Id,并且根據Id獲取所有相關的權限，系統中使用了 JsonWebToken對用戶的Id信息進行保存。JsonWebToken在

token （內容無意義）的基礎上進行改進，能夠保存部分用戶信息，并且在JsonWebToken 失效后提供了 RefreshToken對JsonWebToken進行刷新，防止由于JsonWebToken時效過短而導致的頻繁登錄，使用JsonWebToken的方式還能夠確保用戶和服務器之間信息傳輸的可靠性。

4.3.20Auth2 認證

OAuth （開放授權）是一個開放標準，允許用戶授權第三方移動應用訪問存儲在另外的服務提供者上的信息，而不需要將用戶名和密碼提供給第三方移動應用或分享他們數據的所有內容，OAuth2是OAuth協議的延續版本。

圖4.16 OAuth2認證過程

Fig. 4.16 OAuth2 certification process

本文中將JsonWebToken、OAuth2相結合，設計了 Auth微服務來完成用戶的登錄授權以及訪問認證等操作。圖4.16展示了用戶首次登陸后的0Auth2認證過程。可分為如下幾個步驟：

(1)用戶在進行登錄認證時，填寫賬號密碼，賬號密碼被發送至 0Auth2 認證服務器。

(2)0Auth2 認證服務器驗證用戶信息的有效性，再根據用戶信息與秘鑰生成 JsonWebToken，將 token 返回給用戶。

(3)用戶獲得 token 后，再次向服務器發起請求時，需要在請求頭中帶上 JsonWebToken。

(4)后端的微服務接收到相應的請求，轉發給OAuth2認證服務器進行認證。

(5) OAuth2服務器認證JsonWebToken的有效性。認證成功后，根據其包含的用戶編號獲取用戶的權限，保存在上下文信息中，返回給微服務。

(6)微服務根據上下文信息獲得具體的用戶權限，判斷用戶是否有權限訪問該接口，若無權限則返回錯誤碼，若有權限則處理用戶請求并將結果返回給用戶。

4.3.3SQL防注入攻擊

SQL注入(SQL injection，SQLi)攻擊是指攻擊者通過執行惡意SQL語句，來控制某個Web應用的數據庫服務器，進而未經授權地訪問、修改或刪除各種數據。SQL注入攻擊是系統中常見的安全問題，如果不及時解決此類問題，會導致重要數據丟失，或被篡改等一系列風險［20］。

在傳統的JDBC中，常常使用字符串拼接的方式來組成SQL語句，這樣會導致SQL 注入的風險，如 select * from user where username=' ' or 1=1 --' and password=' 123' 。黑客可以直接通過輸入' or 1=1 --，免驗證進入到系統中。

系統使用了 Tk.MyBatis來編寫數據庫操作。Tk.MyBatis有多種配置方式，包括XML 配置文件的方式和Annotation注解配置的方式<>Tk.MyBatis在編寫SQL語句的過程中，使用#{}傳遞參數并限制參數傳遞的類型，在實現代碼底層， Tk.MyBatis 將#{}解析成 PreparedStatement，使用參數綁定的方式來設置參數。這種機制防止了數據庫SQL的注入攻擊。

4.3.4HTTPS安全傳輸協議

HTTP協議是無狀態、無連接、靈活、簡潔的，但它存在如下缺點：

(1)通信傳輸過程中使用明文。

(2)不驗明通信方的身份。

(3)無法驗證報文的完整性。

為了保證傳輸過程的安全，本文使用HTTPS傳輸協議。HTTPS協議通過SSL提供

數據加密處理（訪問的中間過程無法被黑客捕捉到）、驗證對方身份（簽名認證，通過證書來訪問服務器）以及數據完整性保護（防止傳輸的內容被中間人冒充或者篡改）。

4.4數據庫設計

數據庫設計是系統設計的關鍵環節，它的設計好壞直接影響到系統性能的優劣。針對本文中的綜合水務信息管理平臺，由于數據庫數量較多，表關系較為復雜，數據庫設計的合理與否關系到系統能否正常運行。

4.4.1 概要設計

綜合水務信息管理平臺數據庫多為結構化數據，在數據存儲過程中，使用結構化數據庫存儲數據，將會簡化數據存取過程。除了動態的能耗數據還有靜態數據，例如設備信息，污染物閥值等等。在數據庫設計過程中，應當合理地設置主鍵以及索引，以便加快用戶存取速度。并且在數據庫設計過程中，應當合理地設置數據庫用戶權限。

圖4.17水利信息數據庫E-R圖

Fig. 4.17 Water resources information database E-R diagram

由于微服務的特性，每個微服務都會與其業務相關的數據庫關聯，系統主要由四個數據庫組成，分別是水利信息數據庫，事件管理數據庫，用戶管理數據庫和工作流數據庫。其中工作流數據庫由Flowable工作流引擎自動生成，后續不做詳細介紹。

水利信息數據庫主要有以下十二個表：實體表，實體類型表，實體組織表，工程信息表，逐時水質表，逐時水量表，逐時流量表，逐時水位表，平均水質表，平均水量表，平均流量表，平均水位表。圖4.17為水利信息數據庫的E-R圖，該數據庫中的表主要用于存儲各站點采集到的水質，水量，水位與流量數據。

事件管理數據庫主要有以下八個表：事件表，任務表，日志表，圖片表，問題表，任務事件表，事件用戶表以及任務用戶表。事件表主要用于保存巡河異常事件與告警異常事件的相關信息。任務表主要用于保存巡河任務的相關信息。日志表用于記錄告警事件的日志信息。圖片表用于保存用戶反饋的圖片信息。問題表用于保存異常事件類型的相關信息。任務事件表用于保存任務與事件的關系。事件用戶表用于保存異常事件和用戶的關系。任務用戶表用于保存巡河任務與用戶的關系。圖4.18為事件管理數據庫的 E- R圖。

用戶管理數據庫主要有以下八個表：資源表，角色表，角色資源表，用戶表，用戶角色表，認證令牌表，應用信息表，刷新令牌表。資源表用于保存前端資源以及操作權限相關信息，角色表用于保存用戶的角色相關信息，角色資源表用于保存角色與資源的對應關系，用戶表用于保存用戶的個人信息，用戶角色表用于保存用戶與角色的對應關系。認證令牌表用戶保存用戶登錄的token信息。應用信息表用于保存可認證的應用信息。刷新令牌表用來保存用戶的refreshtoken信息，當token過期時，用戶可使用 refreshtoken進行刷新。圖4.19為用戶管理數據庫的E-R圖。

圖4. 19用戶管理E-R圖

Fig. 4.19 User management E-R diagram

4.4.2 數據庫表設計

在數據庫表設計中，由于每個數據庫中的表較多，本文將會對每個數據庫中較為重要的表的字段描述，字段名稱以及數據類型等信息進行詳細的設計。在設計過程中，需要合理的定義字段名，主外鍵，字段長度等。

表4.1為水利信息數據庫中的平均水位表，該表主要記錄了平均水位信息，可以通過小時、天、月對數據進行篩選。該表主要包括以下屬性：水位統計編號，測站編號，平均水位，水位統計時間，描述和時間類型。

表4.1 平均水位表

Tab. 4.1 Average water level table

字段描述字段名稱數據類型說明

水位統計編號 Z_STATS_ID bigint(20) 主鍵，非空

測站編號 ENTITY_ID bigint(20)

平均水位 MEAN_Z decimal(8) 小數點3位

水位統計時間 STATS_TIME datetime

描述 DESCRIPTION varchar(255)

時間類型 PERIOD TYPE varchar(12)

表 4.2 為水利信息數據庫中的實體表，該表主要用于保存了各個站點的信息，水質、水量、流量、水位等信息都與實體表相關。該表主要包括以下屬性：實體編號，實體名稱，實體標識，實體類型編號，中心點經度，中心點緯度，高程，參考面，地圖縮放層級，文字描述和刪除標識。

表4.2 實體表

Tab. 4.2 Entity table

字段名（中）字段名（英）數據類型說明

實體編號 ENTITY_ID bigint(20) 主鍵，非空

實體名稱 ENTITY_NAME varchar(64)

實體標識 ENTITY_CODE varchar(64)

實體類型編號 TYPE_ID bigint(20)

中心點經度 LONGITUDE decimal(8) 小數點6位

中心點緯度 LATITUDE decimal(8) 小數點6位

高程 ELEVATION decimal(20)

參考面 DATUM_TYPE varchar(64)

地圖縮放層級 MAP_ZOOM int(2)

文字描述 DESCRIPTION text

刪除標識 DELETE FLAG int(1)

表 4.3 為事件管理數據庫的任務表，該表主要用于保存執行巡河任務過程中產生的相關信息，由巡河任務產生的異常事件會存于事件表中，巡河任務與異常事件的對應關系會通過任務事件表進行管理。該表主要包括以下屬性：任務編號，任務開始時間，任務結束時間，任務名稱，任務類型，任務狀態，任務結果，任務描述，未巡檢說明以及任務巡檢隊。

表4.3

Tab. 4.3 任務表

Task table

字段名（中）字段名（英）數據類型說明

任務編號 TASK_ID varchar(64) 主鍵，非空

任務開始時間 TASK_START datetime

任務結束時間 TASK_END datetime

任務名稱 TASK_NAME varchar(64)

任務類型 TASK_TYPE int(11)

任務狀態 TASK_STATUS int(11)

任務結果 TASK_RESULT int(11)

任務描述 TASK_DESCRIPTION varchar(255)

未巡檢說明 TASK_UNPATCHED text

任務巡檢隊 TASK TEAM varchar(64)

表 4.4 為用戶管理庫中的資源表，用于保存前端資源相關信息。該表主要包括以下屬性：組件編號，組件名稱，組件標記，組件路徑，父節點編號，組件圖標，請求方式，操作標記，系統編號以及激活標記。

表4.4 資源表

Tab. 4.4 Resource table

字段名（中）字段名（英）數據類型說明

組件編號 MODULE_ID bigint(20) 主鍵，非空

組件名稱 MODULE_NAME varchar(64)

組件標記 MODULE_CODE varchar(64)

組件路徑 MODULE_PATH varchar(255)

父節點編號 PARENT_ID bigint(20)

組件圖標 MODULE_ICON varchar(64)

請求方式 HTTP_METHOD varchar(8)

操作標記 IS_OPERATING int(11)

系統編號 SYSTEM_ID bigint(20)

激活標記 ACTIVE int(11)

5系統實現

5.1 綜合信息管理模塊綜合信息管理模塊中包含的功能有工程信息，污水處理情況，工程運行情況，上洋水質，告警管理以及服務報表。本文主要對工程信息，工程運行情況以及告警管理的實現進行詳細闡述。

(1)工程信息工程運行頁面主要展示了坪山地區工程設備的基本信息。圖5.1為綜合水務信息管理平臺的工程信息界面。

主要實現步驟分為如下幾步：

①調用this.gis.getMapConfig()方法獲取地圖初始配置信息，如地圖中心位置 initCenter，各圖層配置 jsonLayer 等。

②調用this.initMap()方法初始化地圖，初始化過程中調用L.map()方法初始化地圖的底圖，調用L.geoJSON()方法對邊界信息進行繪制。

③獲取具體的工程站點信息與屬性，通過Marker的方法對地圖上的站點進行渲染和顯示。

詳細代碼在后續章節中展示，核心代碼如下所示： this.gis.getMapConfig('mapconfigQuery.json').subscribe((data: any) => { this.config = data;

//初始化頁面信息 this.initMap(); const qualityIndicatorCriterias: QualityIndicator = {}; this.gis.getMapEntityInfos().subscribe((sidata: any) => { sidata.forEach(element =>{ //處理設備站點信息 this.formatEntity(entry);

});

this.staInfos = sidata; //初始化設備站點信息 this.initStations();

}); this.gis.getMapEntityProps().subscribe((spdata: any) => { this.staProps = spdata; this.initStations();

});

(2)工程運行情況工程運行情況中主要包含了截污井，調蓄池，凈化站，人工濕地，水情與雨情的運行情況，以凈化站為例。從圖 5.2 中能夠看到碧嶺凈化站，南布凈化站以及上洋污水處理廠的儲水情況。

該模塊主要采用了數據庫多表查詢的方法對數據進行選取與展示，實現的主要過程可分為如下幾步：

①前端通過qualitylndicatorService的getData()方法從后臺獲取污染物濃度數據。

②由于返回數據可能存在缺漏，前端通過調用 periodTypeHelper.getFormattedDate 方法對數據的時間進行處理以及排序，該方法底層由DatePipe實現。

③將獲得的數據與 Echarts 的 option 進行綁定，并且調用自定義的 updateEcharts() 方法刷新前端的圖表。

④當選擇其他污染物時，重新調用第一步中的方法。

C (!) localhost:4200/#/query/treatinentplant

殳綜合水務信息管理系統 O綜臺信息 Q實時監視 ©常規調度民巡河菅理 @ 翹誣

軒”]•丼4

飆站信息統計

按他按天按月發年 *起止時間：刃始日期 ~ 結束日期 b|

凈化站水質凈化站進出水星

(•) COD NH3-N TN TP

mg/L YD-碧嶺岀水-O 南布出水-O-上洋出水

100]

60- A

20- \\ 1

\\ 7

2018-11-22 00:00 2018-11-22 00:00 2018-11-22 00:00 2018-12-31 00:00 2018-12-31 05:00

圖5.2凈化站查詢頁面

Fig. 5.2 Purification station inquiry page

(3)告警管理

坪山綜合水務信息管理平臺中，告警查詢部分使用了工作流引擎Flowable，將告警業務代碼與告警流程代碼進行了分離，當告警流程發生改變時，并不需要對告警業務代碼進行大量改動，提高了業務的拓展能力以及代碼的可讀性。告警頁面如圖 5.3 所示。

主要實現細節如下，前端獲取事件列表，事件共有五個狀態，分別為未處理，待接受，處理中，待審核和已處理狀態。后臺調用 IncidentMapper 的 getAlarmIncidentList() 方法獲取事件列表。IncidentMapper的接口定義如下：

@org.apache.ibatis.annotations.Mapper

public interface IncidentMapper extends Mapper<Incident> {

List<Task> getAlarmIncidentList (int status);

Task getAlarmIncidentDetail(String incidentId);

Boolean assignIncident(Incident incident);

圖5.3 告警查看頁面

Fig. 5.3 Alarm viewing page

當點入詳情后，界面如圖5.4所示。前端通過調用自定義的AlarmService中的 getIncidentDetail()方法獲得當前事件的具體的詳情。在詳情頁中，可以根據不同的狀態對事件進行委派，撤回，審核，接受等操作。

后臺部分包含兩個微服務之間的互相調用，分別是事件微服務Basin以及工作流微服務Bpm，為保證微服務之間能夠互相調用，需要在微服務的application文件中加入 @EnableFeignClients注解。具體調用流程是前端調用Bpm的接口，Bpm微服務根據該告警事件在工作流的流程中所處位置，通過feign的方式同步調用Basin提供的方法并處理請求。

通過上述方式將流程與業務分離。具體實現流程以及代碼如下：

①通過runtimeService來獲得對應事件編號的工作流的實例。

②通過task節點的getName()方法獲得節點名稱判斷當前事件所處位置。

③通過basinIncidentService中提供的assignIncident()方法對任務進行委派。 ProcessInstance processInstance = runtimeService.createProcessInstanceQuery() .processInstanceBusinessKey(businessId).singleResult();

Task task = taskService.createTaskQuery().processInstanceId(processInstance.getId()) .singleResult();

if (task != null && task.getName().equals("委派任務")){

basinIncidentService. assignIncident (incident);

}

為了實現消息推送，搭建了 Message微服務，它基于WebSocket實現，可為其他服務提供消息推送功能。可在委派成功后加入Message微服務的消息通知，需標明推送類型以及推送內容。

■> C 0 localhost:4200/#/alarm/incidentdetail?id=3265422506541973540 ?

詡牛編號：

3265422506541973540

已完成

（0發生時間——0）已委派——（J）處理中——0）待審核——?已處理

O Sat May 25 02:07:12 CST 2019 產生了告警事件： 3265422506541973540

O管理員Sat May 25 02:07:39 CST 2019委派了告警事件： 3265422506541973540

O張世良Sat May 25 02:07:52 CST 2019接受了告警事件: 3265422506541973540

O張世良Sat May 25 02:08:08 CST 2019反饋了告警事件:

~亠=1 ■一 » I Acta、| -T” :―I r.—r «-*-■ 、rm

Fig. 5.4 Alarm details page

5.2實時監測模塊

實時監測模塊中包含的功能有水質監測，水量監測，設備運行狀態監測與視頻監測。本文主要對水質監測與視頻監測的實現進行詳細闡述。

（1）水質監測

圖5.5為水質監測實現截圖，該功能與告警流程相關。當支流，凈化站，人工濕地以及上洋斷面的水質存在異常時，系統會觸發告警事件，用戶可以在水質監測頁面了解到各站點水質的情況。

在該功能實現過程中，主要使用了定時器定時發送請求來獲取具體告警信息，并且通過Leaflet中的Marker圖層對前端頁面進行渲染。在開啟定時器后，調用AlarmService 中的getAlarmInformation（）方法來獲得具體的告警數據，通過getResponseDataEvents（）方法對數據進行處理。實現代碼如下：

timedTask（） {

this.timer = setInterval(() => { this.subscriptionEvents = this.AlarmService

.getAlarmInformation()

.subscribe((data: any) => { this.getResponseDataEvents(data.data.rows);

});

}, this.REFRESH_INTERVAL);

}

在getResponseDataEvents()方法中，對后臺返回的告警事件信息進行處理，并調用 Marker的方法對告警站點進行顯示。具體實現流程如下，定義了告警圖標，移除之前在圖層之中的的所有告警節點，將當前請求中獲得的告警節點加入至圖層中，最后在地圖中繪制出圖層中的的所有節點。

const redPulsingIcon = L.icon.pulse({iconSize: [10,5],color:'red',fillColor:'red' }); const bluePulsingIcon = L.icon.pulse({iconSize: [10,5],color:'blue',fillColor:'blue' }); this.removeExistingPulseMarker(); //移除之前的圖層

this.pulseMakers.push(

L.marker([entity.latitude, entity.longitude], {

icon: pulsingIcon,

zIndexOffset: -1, // 置于最底層圖標

interactive: false, //并忽略鼠標響應，只保留上層的電站Marker響應事件 });

this.pulseMarkerGroup = L.layerGroup(this.pulseMakers); // 力加入 layerGroup this.map.addLayer(this.pulseMarkerGroup); // 添加到地圖上

(2) 視頻監測視頻監測的主要功能是監測河岸的具體情況，對攝像頭實時上傳的圖像進行識別，并且對識別的圖片內容進行統計，當人或物的數量超過一定閾值時，會在右上角發起通知進行報警。為了實現該功能使用了 Flask，Tensorflow等框架。具體實現頁面如圖5.6 所示。

在功能實現過程中，通過如下代碼加載Y0L0v3模型，使用input_tensor與 output_tensors對圖像進行處理與識別，對識別后的信息進行統計，將獲得的相關信息存入數據庫中。前端設置定時器，每隔60秒獲取一次數據，并定時刷新頁面。若出現異常情況，后臺會推送websocket消息通知前端用戶。

input_tensor, output_tensors = util.read_pb_return_tensors(gpu_nms_graph, "./data/yolov3_gpu_nms.pb", ["Placeholder:0","concat_10:0", "concat_11:0", "concat_12:0"])

5.3常規調度模塊

常規監測模塊中包含的功能有情勢分析，調度規則，調度方案以及方案管理。本文主要對調度方案的實現進行詳細闡述。圖 5.7 為調度方案頁面。

調度方案的創建可分為旱時調度，雨時調度與雨后調度。旱時調度通過構造單目標優化問題求解成本最低方案或是水質最優方案。雨時調度由于降雨產匯流存在時間和空間的不確定性而使用設備自動調控。雨后則是采用總體流量最大的方案對調蓄池中的水進行排放，使得有足夠多的空間進行儲水。

圖5.7 調度方案頁面

Fig. 5.7 Scheduling plan page

下面主要對旱時調度與雨后調度的實現進行闡述。在旱時調度中，使用了線性規劃的方法求解單目標問題。在實現過程中，需要明確地列出約束條件以及目標函數，下面是約束條件瞬 < 臨的部分代碼。

A_ub = np.array([[(H1*a -G1*a),(H1*a -G1*a),(K1*a*b*r1)], [(H2*a -G2*a),(H2*a -G2*a),(K2*a*b*r2)], [(H3*a -G3*a),(H3*a -G3*a),(K3*a*b*r3)], [(H4*a -G4*a),(H4*a -G4*a),(K4*a*b*r4)]])

b_ub = np.array([ G1 * q.sum() - np.dot(c1, q),

G2 * q.sum() - np.dot(c2, q),

G3 * q.sum() - np.dot(c3, q),

G4 * q.sum() - np.dot(c4, q)])

水量平衡約束，需要滿足碧嶺，南布，上洋污水處理廠處理污水的總量為生活污水量，生活污水量由污水處理廠提供，可從數據庫中讀取。

A_eq = np.array([[1,1,1]])

b_eq = np.array([Qlife[i]])

通過確定約束條件以及目標函數，帶入線性規劃函數 linprog 進行處理，有如下代碼：

r = linprog(c,A_ub,b_ub,A_eq,b_eq,bounds=((1,2.7),(1,2.7),(10,26)))

其中 c 為目標函數各決策變量的系數，即污水處理廠與凈化站處理的單方成本， A_ub,b_ub為上洋水質約束，A_eq,b_eq為水量平衡約束，bounds為處理負荷約束，主要針對三個決策變量Qi、Q2與Q3。

在雨后調度中，湯坑調蓄池、石井調蓄池、上洋調蓄池與錦龍調蓄池的閥門開關是可控的，因此他們的啟閉情況總可分為 16種。在代碼實現中，將0 至15 轉換成四位二進制數，把每位都存入condition中，對應16種開關啟閉的情況。接著，遍歷每小時的十六種情況，選出流量最大且不超過上洋污水廠最大處理能力的情況并記錄下來，計算流量的代碼如下：

Qcurrentq = np.zeros(4)

Qcurrentq[0] = Q1(condition[0], ho1)

Qcurrentq[1] = Q2(condition[1], ho2)

Qcurrentq[2] = Q3(condition[2], ho3)

Qcurrentq[3] = Q4(condition[3], ho4)

Q = Q1(condition[0], ho1) + \

Q2(condition[1]) + \

Q3(condition[2], ho3) + \

Q4(condition[3], ho4) + Qlift[times]

在代碼中，QI、Q2、Q3、Q4對應的是湯坑調蓄池、石井調蓄池、錦龍調蓄池與上洋調蓄池的排放量，可通過調蓄池當前的啟閉情況、當前的水頭以及排水能力系數進行計算獲得。參數 condition]。]、condition]]]、condition[2]、condition[3]是四個調蓄池對應的啟閉情況，hoi、ho2、ho3、ho4是四個調蓄池對應的水頭信息。

5.4巡河管理模塊

巡河管理模塊主要包含的功能有巡河方案，巡河監視，方案查詢和信息錄入，本文主要對巡河方案，巡河監視以及方案查詢的具體實現進行詳細闡述。

(1)巡河方案

巡河方案頁面主要包括巡檢記錄表，巡河人員值班表，月巡檢工作記錄以及巡河詳情頁。在巡檢記錄表中記錄了日常巡檢的相關信息。在巡河人員值班表中記錄了當天值班的人員信息。在月檢工作記錄中統計了當月日常巡檢與異常告警的完成情況。在巡河詳情頁中記錄了巡河任務的具體信息以及反饋情況，巡河方案的具體實現界面如圖5.8 所示：

圖5.8 巡河方案頁面

Fig. 5.8 Cruise program page

巡河方案的實現共使用了四個微服務，分別是Common微服務，Basin微服務， Message微服務與Hydrology微服務。Common微服務主要是用于管理用戶信息。Basin 微服務主要用于管理巡河事件與告警事件。Message微服務主要用于推送消息， Hydrology微服務主要用于管理水利信息與設備站點信息。在獲取巡檢記錄表的數據時，后臺調用 taskService.getCurrentTaskListByOrganizationId (organizationId)方法獲取當天的巡河任務記錄以及巡河任務的具體信息，由于巡河任務的部分信息存儲于其他數據庫中因此調用了 Common微服務提供的接口獲取巡河人員的詳細信息，調用了 Hydrology微服務提供的接口獲取具體站點的信息，調用了 Message微服務將消息推送給指定部門的用戶。

在巡河過程結束后，若巡河人員發現異常問題，則需要通過手機APP進行拍照上傳圖片，并且將處理情況反饋到系統中。管理人員對上報的問題進行及時處理。巡河詳情頁如圖5.9所示。

C Q localhost:4200/#/integratedmanageinent/window?id=3297904588287377409

M卜丼1

踐編號：

3297904588287377409

巡河狀態：已完成

異常問題狀態：已處理

基本信息

任務起止時間：20190604 22:33

他隊：謝隊

任務發起人：管理員 18840837372

圖5.9 巡河詳情頁面

Fig. 5.9 Cruise river details page

（2）巡河監視

巡河監視功能使用了手機 App 的自動定位功能與 Leaflet 的地圖路徑描繪功能。在 App中調用GPS定位接口，獲取當前位置信息并存儲到數據庫中。Web前端設置定時器，獲取用戶存儲在數據庫中的巡河路徑，通過LeafLet將路徑渲染至前端頁面中。

地圖的右側提供了各巡河隊的歷史未處理任務，今日未處理任務和今日已處理任務可以方便管理人員對未處理和歷史未處理的事件進行查看與處理，實現如圖 5.10。

巡河路徑繪制的核心代碼如下，調用了 L.geoJSON初始化巡河路徑的圖層，調用了 patrolService 方法獲取用戶巡河路徑，將路徑信息添加至圖層之中，最后渲染并顯示在前端頁面中。

this.overlays]'巡河路徑']=L.geoJSON（null, {

style: {

color: '#ff7800',

weight: 3, opacity: 1,

}).addTo(this.map); this.patrolService.getPatrolPath({userId:userid}).subscribe((data: any) => { this.overlays]'巡河路徑'].addData(data);

});

(3)方案查詢

方案查詢用于查詢巡河的歷史記錄，方便管理員對巡河的歷史情況進行審查分析。圖5.11為巡河查詢頁面的實現截圖。

在查詢過程中，由于巡河任務篩選條件較多，本文結合MariaDB與ElasticSearch搜索引擎來進行巡河任務的查詢，同時考慮到效率問題，使用RabbitMQ作為消息隊列異步處理ElasticSearch的操作。在創建、修改、刪除巡河任務時，發送消息至RabbitMQ。在Basin微服務上監聽RabbitMQ消息隊列，當接收到消息時，調用updateSuggest()方法與updateIndex()方法對ElasticSearch中的數據進行修改以及更新，updateSuggest()方法中調用AnalyzeRequestBuilder()中的方法創建與更新Suggest， Suggest主要用于中文的自動補全。updateIndex()方法中調用ESTaskMapper中的方法對巡河任務進行新增，修改和刪除。ESTaskMapper的代碼如下：

public interface ESTaskMapper extends ElasticsearchRepository<ESTask,String> {} 本文中使用了 ik_smart分詞對ElasticSearch存儲的中文字段進行分詞處理，在創建 ElasticSearch 的索引時，給需要分詞處理的字段加上 analyzer 分詞器，具體查詢方法實現分為如下幾步：

①創建 BoolQueryBuilder 對象。

②創建QueryBuilders.multiMatchQuery指定查找字段范圍。

③根據關鍵字，調用BoolQueryBuilder對象的must方法并執行該查詢條件。

④通過SearchResponse類對象接收數據并處理。

⑤將處理后的數據根據編號在MariaDB中查找并返回給前端。

圖5.11 巡河查詢頁面

Fig. 5.11 Cruise river query page

5.5系統管理模塊系統管理模塊主要包含的功能有用戶管理，角色管理，菜單管理，部門管理以及臺賬管理。本文主要對用戶管理，部門管理和角色管理的具體實現進行詳細闡述。

（1）用戶管理用戶管理主要用于修改和管理用戶相關信息，如部門，姓名，郵箱等。管理員可以進行用戶管理，而隊員和隊長沒有操作權限。管理員可以管理所有用戶的用戶信息，實

現頁面如圖5.12所示。

圖5.12 用戶管理頁面

Fig. 5.12 User management page

（2）部門管理部門管理主要用于管理部門信息，系統中提供了對部門信息的添加，編輯與刪除操作。實現頁面如圖5.13所示。

圖5.13 部門管理頁面

Fig. 5.13 Department management page

< result column "ORGANIZATIONNAME" property=,,title"/>

SELECT * FROM organization WHERE PARENT_ID = #{PARENT_ID}

</select>

圖5.14遞歸菜單sql語句

Fig. 5.14 Recursive menu sql statement

在部門信息展示中使用了 Mybatis的collection對子菜單進行遞歸查詢。sql語句如圖 5.14 所示。

（3）角色管理角色管理主要用于管理角色的權限。系統中為不同的用戶分配不同的角色，不同的角色擁有不同的權限。在用戶管理數據庫中的資源表展示了資源信息，它通過 IS_OPERATING字段來區分該資源是操作還是菜單。角色管理頁面如圖5.15所示。

前端的控件有 ACL 指令標識，當用戶登錄時，后臺根據前端傳回來的用戶編號獲取用戶對應角色的菜單列表與操作列表，后臺將菜單列表加載到前端頁面中，并且根據操作列表來決定前端控件是否加載。

圖5.15 角色管理頁面

Fig. 5.15 Role management page

5.6大屏展示模塊

大屏展示模塊主要包括綜合大屏，凈化大屏，水質大屏，水量大屏以及控制大屏。本文主要對水量大屏的實現進行闡述。

水量大屏頁面主要包括該年的水文站生態水位滿足度，各水文測站水位變化趨勢以及各水文站的當前的水位情況。用戶可以通過該大屏直觀的了解到坪山河的實時水位變化情況。這部分主要通過Leaflet與Echarts實現了圖形的繪制，數據通過Timer定時獲取。具體實現截圖如圖 5.16 所示。

圖5.16 水量大屏頁面

Fig. 5.16 Volume large screen page

5.7安全模塊

安全模塊主要包括，用戶權限認證，OAuth2認證，SQL防注入以及HTTPS傳輸協議，本文主要對權限控制與OAuth2認證的實現進行詳細介紹。本文搭建了 OAuth2微服務作為認證中心，結合用戶權限對接口訪問與前端控件顯示進行了權限控制。接下來對用戶登錄到訪問后端接口的全過程進行闡述。

登錄認證的實現具體實現可分為如下幾步：

(1)用戶登錄時，通過 authenticationService.authenticate 訪問后臺的/oauth/token 接口，認證用戶信息并且生成token返回給前端。

(2)前端調用 tokenService.set 方法設置 token，調用 userService.getUserModule 方法獲取用戶權限。

(3)進入全局攔截器，調用moduleService.getMenu()獲得用戶菜單，加載菜單。為了保證前端訪問的安全性，在每個控件上加入了自定義的結構化指令，它能根據

用戶權限控制前端控件的顯示。

@Input()

set myacl(condition: any) {

this._context.$implicit = this._context.ngIf = condition;

//循環acl數組查詢是否含有權限特征值

for (const i in this.settings.user.moduleResource) {

if (this.settings.user.moduleResource[i] === this._context.$implicit) { this._viewContainer.createEmbeddedView(this._thenTemplateRef, this._context); break; } } }

后端通過SpringSecurity搭建OAuth2微服務。以下為SpringSecurity配置過濾規則的代碼。

httpRequest. addFilterAt(getMyLoginAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class). addFilterBefore(getPhoneLoginAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class). addFilterBefore(getQrLoginAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class). // 配置登錄頁/login 并允許訪問 formLogin().loginPage("/login").permitAll().// 登出頁 and().logout().logoutUrl("/logout").logoutSuccessUrl("/backReferer"). and().authorizeRequests().

antMatchers("/oauth/token").permitAll(). anyRequest().authenticated().

and().csrf().disable();

當用戶進入主頁訪問其他接口時，前端需要在請求的 Header 部分加入 token 信息，后端接收到請求會轉發至OAuth2微服務進行認證。具體的轉發處理配置如下：

oauth2: client:

accessTokenUri: http://localhost:18001/oauth/token userAuthorizationUri: http://localhost:18001/oauth/authorize resource:

token-info-uri: http://localhost:18001/oauth/check_token

后端 OAuth2 認證完后，會將用戶的權限信息存于 SecurityContextHolder 中，其他微服務可以通過 SecurityContextHolder.getContext().getAuthentication()方法獲得用戶的權限信息，并在Controller上加上注解@PreAuthorize來判斷用戶存在指定權限。若權限足夠，則返回處理數據，否則返回錯誤碼。

6系統測試

軟件的質量就是軟件的生命，為了保證軟件的質量，軟件測試是最有效的排除和防止軟件缺陷與故障的手段，它能夠盡快盡早地發現在軟件產品中所存在的各種問題，與用戶需求、預先定義的不一致性的方面［21］。本章將從測試方案、測試用例設計、測試結果及分析三個方面介紹系統測試。

6.1 測試方案

系統測試有較多種方法，本文采用黑盒測試的方法對系統進行測試。黑盒測試，將程序的內部代碼全部封閉，當做是一個黑盒，只是通過輸入和輸出來測試程序運行的正確性。測試搭建在本地，系統部署在遠程云服務器上。

本系統的測試內容主要是系統能否正常工作、系統對于正常數據、異常數據是否能夠正常判斷、需求階段的功能是否實現，是否達到預期結果，對于錯誤輸入，是否能給出錯誤提示。

6.2測試用例設計

本文主要以系統管理模塊、巡河管理模塊、實時監測模塊以及綜合信息管理模塊為例進行測試用例的設計。

（1）系統管理模塊功能測試：測試用例1、2是驗證用戶能否正確修改個人信息。測試用例 3、4是驗證管理員能否為正確地為其他用戶修改權限，測試用例5、6 是驗證管理員是否能夠正確系統修改系統菜單，測試用例 7、8 是驗證管理員能否正確添加部門信息。

表6.1 系統管理模塊測試用例表

Tab. 6.1 System management module test case table

編號輸入預期結果

1 輸入錯誤手機格式修改失敗，提示手機格式錯誤

2 輸入錯誤郵箱格式修改失敗，提示郵箱格式錯誤

3 清空用戶權限項授予權限失敗，提示權限為空

4 選擇正確用戶權限授予權限成功，提示修改成功

5 修改菜單路徑為空修改菜單失敗，提示路徑不能為空

6 正確修改菜單項修改成功，提示修改菜單成功

7 添加部門名為空添加失敗，提示部門名不能為空

8 正確添加部門信息添加成功，提示添加部門成功

（2）巡河管理模塊功能測試：測試用例1、2、3 是驗證能否正確地發布巡河任務。測試用例 4 是驗證能夠正確地進行頁面跳轉，測試用例 5、6 是驗證能否正確地根據權限對巡河任務進行刪除，測試用例 7、8、9 是驗證是否能夠正確對巡河任務進行反饋，測試用例 10、11是驗證在巡河審核中安全認證是否生效。

表6.2 巡河管理模塊測試用例表

Tab. 6.2 Cruise river management module test case table

編號輸入預期結果

1 點擊發布巡河彈出發布巡河任務界面

2 再次點擊發布巡河提示請發布巡河任務

3 錯誤的巡河任務部門發布失敗，提示選擇正確部門

4 點擊查看詳情跳轉任務詳情頁面

5 管理員刪除巡河任務操作成功，提示刪除任務成功

6 隊長刪除巡河任務操作失敗，提示用戶權限不夠

7 巡河異常反饋內容為空反饋失敗，提示反饋內容為空

8 巡河異常反饋狀態為空反饋失敗，提示反饋狀態為空

9 正確的巡河異常反饋反饋成功，提示反饋成功

10 不帶token審核巡河任務審核失敗，跳轉未認證頁面

11 正確token審核巡河任務審核成功，提示巡河任務結束

（3）實時監測功能測試：測試用例1、2、 3是驗證能否正確地操作水質監測頁面

的功能。測試用例 4、5、6 是驗證能否正確地操作水量監測頁面的功能。測試用例 7、

8 是驗證能否正確操作視頻監測頁面的功能。

表6.3 實時監測模塊測試用例表

Tab. 6.3 Real-time monitoring module test case list

編號輸入預期結果

1 點擊水質監測地圖站點顯示站點水質信息

2 點擊水質監測選擇欄站點地圖上跳轉至相應站點

3 點擊水質監測選擇欄的異常站點詳情跳轉至異常站點詳情頁

4 點擊水量監測選擇欄站點地圖上跳轉至相應站點

5 點擊水量監測選擇欄的異常站點詳情跳轉至異常站點詳情頁

6 點擊水量監測選擇欄的正常站點詳情提示該站點不存在異常

7 篩選視頻監測地點信息顯示指定地點視頻監測信息

8 點擊查看視頻監測詳情信息顯示監測詳情

(4)綜合信息管理模塊功能測試：測試用例1、2是驗證能否正確地對工程信息進行查詢。測試用例3、4、5是驗證能否正確地對污水處理情況與上洋斷面信息進行查詢。測試用例6至12是驗證能否正確使用告警業務中的查詢，委派，反饋，審核等功能。

表6.4 綜合信息管理模塊測試用例表

Tab. 6.4 Comprehensive information management module test case list

編號輸入預期結果

1 查詢工程使用情況時未輸入起止時間查詢失敗，提示請輸入時間

2 查詢工程使用情況時未選擇地點信息查詢失敗，提示請選擇地點

3 查詢污水處理情況時未選擇地點信息查詢失敗，提示請選擇地點

4 查詢污水處理情況時未輸入起止時間查詢失敗，提示請輸入時間

5 查詢上洋斷面趨勢時未輸入時間查詢失敗，提示請輸入時間

6 查詢告警信息時未選擇過濾條件查詢成功，顯示所有告警信息

7 點擊告警詳情跳轉至告警詳情頁面

8 點擊委派告警按鈕彈出告警委派頁面

9 委派告警時未選擇部門委派失敗，提示請選擇部門

10 反饋告警任務時未填寫內容反饋失敗，提示請填寫反饋內容

11 管理員點擊駁回告警事件狀態改變，需重新委派

12 管理員點擊通過告警事件狀態改變，事件完成

6.3測試結果及分析

完全執行上述測試方案，對系統的功能進行了測試，結果顯示系統能夠根據輸入值給出預期的輸出。由此證明本系統功能的正確性。測試結果表明系統功能能夠正常運行且相應速度較快，未出現無響應情況。

綜上所述，綜合水務信息管理平臺在整體功能和邏輯結構上滿足了預期的設計，運行效果良好。

結論

本文首先介紹了綜合水務信息管理平臺的背景和意義以及系統在開發過程中使用的關鍵技術。按照軟件工程的開發流程，本文對綜合水務信息管理平臺進行了功能性需求分析、非功能性需求分析以及用例分析，并且根據上述分析對系統架構，功能模塊和數據庫表進行了詳細的設計。本文還對綜合水務信息管理平臺實現過程中的關鍵點進行了介紹和展示。最后使用了黑盒測試的方法對系統進行用例測試，最終完成了綜合水務信息管理平臺，使用該平臺能夠幫助用戶更好地管理與了解河流情況。

綜合水務信息管理平臺主要分為綜合信息管理，實時監視，常規調度，巡河管理，系統管理和大屏展示六個模塊。本文結合相關技術，重點對這六個模塊進行設計與實現。在綜合信息管理模塊中，主要為用戶提供了坪山地區可視化的綜合信息展示頁面，用戶可以通過工程運行情況、污水處理情況和上洋水質情況等了解到坪山地區的工程全貌。在實時監測模塊中，對坪山河設備的信息進行采集、展示與分析，方便管理員進行管理以及查看，其中視頻監測使用了 YOLOv3算法對物體進行檢測。在常規調度模塊中，通過數據分析與模型運算解決各種工況下的調度問題。在巡河模塊中，通過巡河管理體系對坪山河的巡河任務進行有序管理。在系統管理中，為管理員提供了較為完善的用戶管理體系，包括用戶管理，角色管理，菜單管理等。此外，系統通過0Auth2和權限控制等功能的實現保證了系統的安全性。在開發過程中，前端使用了 Angular，Ant Design， LeafLet 等技術，后端 SpringCloud，Tk.Mybatis，MariaDB，ElasticSearch，Redis，RabbitMQ 以及WebSocket等技術。

本文設計的綜合水務信息管理平臺滿足了基本的業務需求，在實現功能的同時，充分考慮了用戶的體驗感，具有較好的實用性和交互性，可以投入實際的使用中去。但是該系統還存在一定的改進空間，如可以對一些敏感數據進行加密或保護，更進一步的，可以實現系統的集群部署和熱部署，保證在系統部分服務出現問題或者系統需要更新的情況下，仍舊能夠提供穩定的服務。

參考文獻

[1]左其亭，韓春華，韓春輝等.河長制理論基礎及支撐體系研究J].人民黃河,2017,39(6):1-6.

[2]趙彤，邱春.互聯網思維及“互聯網+水利”淺析[J].東北水利水電,2015,33(10):59-62.

[3]Liang S J , Molkenthin F . A virtual GIS-based hydrodynamic model system for Tamshui River[J]. Journal of Hydroinformatics, 2001, 3(4):195-202.

[4]王靜.基于J2EE的水務管理信息系統設計與實現[D].石家莊:河北科技大學,201 &

[5]彭智欣，徐嘉祺.智慧水務——水務發展新起點[J].中國水運月刊,2015,15(9):234-236.

[6]Lee S W , Sarp S , Jeon D J , et al. Smart water grid: the future water management platform[J]. Desalination and Water Treatment, 2015, 55(2):339-346.

[7]Munir M S, Bajwa I S, Cheema S M. An intelligent and secure smart watering system using fuzzy logic and blockchain[J]. Computers & Electrical Engineering, 2019, 77(1): 109-119.

[8]稅朋勃，牛鑫艷，張文升等.淺析北京市基層水務信息管理系統架構與設計[J].中國水利,2018,1(9):74-76.

[9]彭九敏.承德市城市水資源實時監控和管理系統的設計與實現[D].成都：電子科技大學,2012.

[10]張行南，井立陽，劉建芬.水務信息管理系統開發與應用[J].河海大學學報(自然科學版)， 2001, 29(4):38-44.

[11]辛園園，鈕俊，謝志軍等.微服務體系結構實現框架綜述[J].計算機工程與應用，2018，54(19):10-17.

[12]王寬，李紅信.基于SSM的同城電商平臺的設計與實現[J].電腦知識與技術，2018，14(17):295-296.

[13]Pimentel V ， Nickerson B G . Communicating and Displaying Real-Time Data with WebSocket[J]. IEEE Internet Computing， 2012， 16(4):45-53.

[14]Tian Y， Yang G， Wang Z， et al. Apple detection during different growth stages in orchards using the improved YOLO-V3 model[J]. Computers and Electronics in Agriculture， 2019， 157(1): 417-426.

[15]冀瀟，李楊•采用ECharts可視化技術實現的數據體系監控系統[J].計算機系統應用，2017，26(6):72-76.

[16]韓曉剛.城市水源水質風險評價及應急處理方法研究[D].西安:西安建筑科技大學,2011.

[17]劉勇，慕曉蕾.基于權限管理的設備管理系統的設計與實現[J].河北省科學院學報，2017，34(1):20-24.

[18]劉宏燕.秩相關系數及其在蒲石河水質分析中的應用[J].黑龍江環境通報,2014,38(2):23- 24.

[19]吳希.基于角色的用戶權限授權系統的研究[J].電腦知識與技術,2012,8(20):4797-4799.

[20]王云，郭外萍，陳承歡.Web項目中的SQL注入問題研究與防范方法[J].計算機工程與設計,2010,31(5):976-978.

[21]陳虹.軟件測試方法研究[J].軟件導刊,2013,12(4):24-25.

【本文地址：http://www.bzhlmm.com//guanlilei/gongshangguanli/xixinguanli/8923.html】

上一篇：基于建筑產業轉型升級視角下施工企業信息鏈研究

下一篇：沒有了

相關標簽:

最熱期刊