ICS13.060.30CCSZ0132范forwaterenvironmentandwate在提交反饋意見時，請將您知道的相關專利連同支持性文件一并附上。IDB32/TXXXX—XXXX前言 II 12規范性引用文件 3術語和定義 4監測系統的基本構成 2系統結構 2組網結構 25傳輸鏈路協議 5現場機與上位機專用傳輸鏈路協議 5現場機與上位機基于物聯網通用協議的傳輸鏈路協議 9通信安全要求 6通訊協議 通訊協議數據結構 通訊流程 代碼定義 7在線監測儀器儀表與數采儀的通訊方式 總則 在線監測儀器儀表與數采儀的電氣接口標準 18在線監測儀器儀表與數采儀的串行通訊標準 18串行通訊傳輸內容（可擴充） 附錄A（規范性）循環冗余校驗（CRC）算法 21附錄B（規范性）常用監測因子和設備信息編碼表（可擴充） 23附錄C（資料性）污水污染源監測點主要污染物計算方法 34C.1污水排放量 34C.2水污染物排放量（加權法） 35C.3水污染物排放量（算術平均法） 35參考文獻 37DB32/TXXXX—XXXX本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規則》的規定起草。請注意本文件的某些內容可能涉及專利。本文件的發布機構不承擔識別專利的責任。本文件由江蘇省環保產業標準化技術委員會提出、歸口并組織實施。本文件起草單位：南京大學宜興環保研究院、南京大學、浪潮智慧科技有限公司、蘇州首創嘉凈環保科技股份有限公司、無錫物聯網產業研究院、江蘇藍創智能科技股份有限公司、江蘇禾美環保科技有限公司、河海大學等。本文件主要起草人：任洪強、許柯、耿金菊、孫捷、黃中慶、陳晨、許明等。1DB32/TXXXX—XXXX水環境與水處理自動監測系統通信技術規范本文件規定了水環境與水處理自動監測系統的基本構成、傳輸鏈路協議、通訊協議、在線監測儀器儀表與數采儀的通訊方式。本文件適用于水環境與水處理自動監測系統中，現場機與上位機之間的數據傳輸，以及在線監測儀器儀表與數采儀之間的數據傳輸。2規范性引用文件下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。SL61水文自動測報系統技術規范3術語和定義下列術語和定義適用于本文件。3.1水環境與水處理自動監測系統automaticmonitoringsystemforwaterenvironmentandwatertreatment由對水環境與水處理中的監測因子實施在線自動監測的儀器設備、數采儀、自動監控設備和監控中心組成。[來源：HJ212—2017，3.1，有修改]3.2監控中心monitoringcenter安裝在各級環保部門、通過傳輸網絡與自動監控設備連接并對其發出查詢和控制等指令的數據接收和數據處理系統，包括計算機硬件和軟件等，以下簡稱“上位機”。[來源：HJ212—2017，3.2，有修改]3.3在線自動監測設備onlinemonitoringequipment安裝在監測點現場及影響污染物排放的工藝節點，用于監控、監測并完成與上位機通訊傳輸的設備，包括監測儀器、流量（速）計、水處理設施運行記錄儀和數據采集傳輸儀等，以下簡稱“現場機”。[來源：HJ212—2017，3.3，有修改]3.4數據采集傳輸儀equipmentofdatacollectorandtransmission采集各種類型監控儀器儀表的數據、完成數據存儲及與上位機數據傳輸通訊功能的單片機、工控機、嵌入式計算機、可編程自動化控制器（ProgrammableAutomationController，PAC）或可編程控制器（ProgrammableLogicController，PLC）等，以下簡稱“數采儀”。[來源：HJ212—2017，3.4]2DB32/TXXXX—XXXX3.5水處理設施watertreatmentfacilities用于治理水污染物所需的設備、裝置等。[來源：HJ212—2017，3.5，有修改]3.6水處理過程監控monitoringofwatertreatmentprocess根據工藝設計，對影響污染物排放的生產設施和水處理設施運行的關鍵參數（包括諸如流量、溫度、含氧量、壓力等工藝參數和諸如電流、電壓、頻率、轉速等電氣參數）進行的監測；結合企業生產工藝和末端監測數據，全面監控企業的生產設施和水處理設施的運行、污染物治理效果和排放情況，判定污染物排放監測數據的合理性、真實性和可接受性。[來源：HJ212—2017，3.6，有修改]4監測系統的基本構成4.1系統結構水環境與水處理自動監測系統從地層逐級向上可分為現場機、傳輸網絡和上位機（平臺）三個層次。上位機通過傳輸網絡與現場機進行通訊（包括發起、數據交換、應答等）。水環境與水處理自動監測系統結構如圖1所示。圖1水環境與水處理自動監測系統結構圖4.2組網結構4.2.1端對端組網端對端組網結構端對端組網基本結構宜按照圖2構建。3DB32/TXXXX—XXXX圖2端對端組網基本結構圖端對端組網工作模式.1現場機與上位機基于專用數據傳輸規約的端對端組網工作模式可選用自報式、查詢/應答式或兼容式，符合下列規定。——自報式：.監測站告警、被測參數值發生變化或定時等事件觸發，現場機向上位機主動發送數據；.自報觸發條件及優先級順序為：告警自報、要素值變化自報、特定條件自報、定時自報等；.可分為無確認自報和確認自報。無確認自報表示現場機發出數據，上位機只需接收無需應答。確認自報表示現場機發出數據，上位機接收正確應發出“數據正確”確認響應。——查詢/應答式：.上位機發出指令對現場機進行數據查詢、參數（狀態）設置或設備控制，現場機應響應指令發送所查詢的數據或狀態、設置參數或執行控制設備指令并返回執行結果；.査詢的方式有定時順序輪詢，隨機順序輪詢或定點査詢等；.隨機查詢的優先級高于定時查詢。——兼容式表示同時包括查詢/應答式和自報式，可根據應用需求設定工作模式。.2現場機與上位機之間采用物聯網數據傳輸協議時，數據交換可釆用物聯網端對端組網工作模式，其邏輯結構宜滿足圖3規定，并符合下列規定：——上位機宜部署LWM2M服務器和Bootstrap服務器；——上位機數據接收處理機與現場機均作為客戶機，與LWM2M服務器連接，并通過Bootstrap服務器獲得消息接收端的真實地址，再通過CoAP協議下的URL指令進行通信。圖3物聯網端對端工作模式結構圖4.2.2扁平化組網扁平化組網結構扁平化組網基本結構宜按照圖4構建。4DB32/TXXXX—XXXX圖4扁平化組網結構圖扁平化工作組模式.1現場機與上位機采用物聯網通用數據傳輸協議通信時宜采用扁平化組網架構，可采用數據中心工作模式或通信中心工作模式。.2數據中心工作模式邏輯結構宜滿足圖5規定，并符合下列規定：——數據中心應具備監測數據接收、存儲、分發和查詢服務的基本功能；——現場機和上位機可根據需求選擇數據中心提供服務的鏈路類型和物聯網數據傳輸協議實現與數據中心的互聯互通；——現場機和上位機通過數據中心提供的API接口和SDK在數據中心上完成注冊，向數據中心分別發布監測數據、控制指令；——上位機采用數據中心提供的API接口和SDK向數據中心查詢監測數據的實時值和歷史記錄；——數據中心在接收到現場機數據或上位機控制命令后，向上位機或現場機推送數據通知。圖5數據中心工作模式邏輯結構圖.3通信中心工作模式邏輯結構宜滿足圖6規定，并符合下列規定。——通信中心只負責現場機與上位機間的數據報文轉發，為現場機與上位機提供透明的傳輸信道。該模式下通信中心作為服務器，現場機與上位機作為客戶端，數據上傳、存儲和分發可采用訂閱分發方式。——現場機和上位機均應通過物聯網數據傳輸協議與通信中心建立連接，宜采用MQTT協議。——現場機在低功耗要求下，與通信中心連接可采用CoAP傳輸層協議及LWM2M應用層協議。5DB32/TXXXX—XXXX——在采用MQTT協議通信時，現場機發布的上行報文通信質量參數應釆用QoSl?;上位機發布的下行報文通信質量參數應采用QoS2?。——在采用CoAP協議時，現場機與上位機均應采用需要被確認的請求（CON）消息類型。圖6通信中心工作模式邏輯結構圖5傳輸鏈路協議5.1現場機與上位機專用傳輸鏈路協議5.1.1物理層通信傳輸信道應根據系統組網需求確定，物理層傳輸接口、速率等技術指標應根據信道特性確定。通信組網應按照SL61有關規定執行。5.1.2鏈路傳輸模式及協議對于非透明傳輸通信方式，專用傳輸鏈路協議宜建立在所選用的通信方式傳輸層協議之上。鏈路傳輸模式規定見表1。應根據監測系統需求、通信信道特點和系統工作模式選定鏈路傳輸模式。一個系統中可以混合使用多種鏈路傳輸模式。表1鏈路傳輸模式種類——對于多包發送/一次確認模式M3和査詢/多包發送響應模式M5，適用于傳輸的數據量比較大，通信信道是雙向通信，通信可靠性和數據傳輸暢通率比較高的應用場景。數據發送方（不一定是通信發起端）是現場機或監控站，數據接收方是上位機。——傳輸流程為：數據的發送方與接收方建立連接后，發送方將要發送的數據分包后，依次全部發完，接收方在接收到最后一幀數據包后，如果全部正確，接收方只給發送方發送一次“確6DB32/TXXXX—XXXX認”回答，告知發送方數據包全部正確；如果有數據包錯誤或者丟失，則將錯誤或者丟失的數據包序號等信息回復至發送方，發送方根據錯誤或丟失的包序號將相應的數據幀再次發送。接收過程中，如果超過一定時間沒有接收到后續報文，按照丟包方式處理。——發送方在依次發送分包數據時，需要設定兩幀數據包之間的幀時間間隔，以免造成發送信道擁擠而導致數據丟失；幀時間間隔應考慮通信發生時通信信道帶寬、接收方的接收緩沖、接收方的數據接收處理能力、中間環節延時等因素。——在進行數據分包時，分包長度應根據通信信道類型、一次通信的最大負載長度、信道繁忙狀況等因素進行確定。傳輸鏈路協議包括自報式和查詢/應答式報文幀傳輸鏈路協議，其報文幀傳輸鏈路協議分別按圖7和圖8的規定執行。鏈路傳輸模式應用符合下列規定。a)Ml，現場機為通信發起端。現場機發出報文后，上位機只需接收不需應答響應。可用于特定信道發送單幀自報報文，沒有下行確認幀。Ml自報式報文傳輸鏈路見圖7（a）。b)M2，現場機為通信發起端。現場機發出報文后，上位機接收報文正確，應響應發送“確認”報文；上位機接收報文無效，則不響應。現場機收不到響應報文應啟動重發機制，最多重發2次。多幀報文有一包傳輸不正確，該份報文下次通信重發。M2自報式報文傳c)M3，現場機為通信發起端。現場機連續發出多包報文后，上位機正確接收全部數據包，僅應回答1次確認報文；若有錯誤或丟失數據包，上位機應發送包括錯誤或丟失的數據包序列號（1個包序列號，每包單獨重發）的響應包，現場機重發相應序列號包數據，此時重發應改為由上位機控制，最多重發2次；接收過程中，如果超過一定時間沒有接收到后續報文，按照丟包方式處理。M3自報式報文傳輸鏈路見圖7（c）。d)M4，上位機為通信發起端。上位機發出查詢請求報文后，現場機接收請求報文正確，應發送響應幀；如現場機接收請求報文無效，則不響應。上位機發出命令后收不到響應報文應啟動重發機制，最多重發2次。上位機未能接收到第2包及以上包響應報文，應重新發起通信，最多重發2次；上位機接收第2包及以上包報文出錯，則應發送“接收錯誤”否認幀，現場機重發對應幀，上位機控制最多重發2次；重發2次不成功，結束本次通信。M4用于查詢現場機監測數據，設置（修改）現場機運行狀態參數、控制現場機運行。M4查詢/應答式報文傳輸鏈路見圖8（a）。e)M5，上位機為通信發起端。上位機發出査詢請求報文后，現場機接收請求報文正確，應發送響應幀；如現場機接收請求報文無效，則不響應。現場機收到查詢請求后，現場機連續發出多包報文，上位機正確接收全部數據包，僅應回答1次確認報文；若有錯誤或丟失數據包，上位機應發送包括錯誤或丟失的數據包序列號（1個包序列號，每包單獨重發）的響應包，現場機重發相應序列號包數據，最多重發2次；接收過程中，如果超過一定時間沒有接收到后續報文，按照丟包方式處理。M5查詢/應答式報文傳輸鏈路見圖8（b）。7DB32/TXXXX—XXXX圖7自報式報文傳輸鏈路圖8DB32/TXXXX—XXXX圖8查詢/應答式報文傳輸鏈路圖9DB32/TXXXX—XXXX5.1.3傳輸規則幀傳輸間隔遵守下列規則：——報文幀的字節之間不設線路空閑間隔；——在兩個數據幀之間應至少等待一個線路空閑間隔；——兩幀之間的線路空閑間隔應根據信道網絡延時、中間環節延時、終端響應時間、傳輸速率等因素確定。通信超時處理遵守下列規則：——超時等待時間應根據信道類型、傳輸速率以及報文單幀長度等因素確定；——發起端在規定時間內沒有正確收到響應報文，應作為超時出錯處理；——接收端在剛建立的鏈路上接收幀信息錯誤，接收端直接退出，發送端作超時處理；——自報式工作模式中，現場機發起多包報文傳輸時，上位機接收第2包及以上包報文，應等待到超時退出；——查詢/應答式工作模式中，現場機發出報文包后需等待上位機回復。回復是“確認”信息，進入下一個進程；回復是“否認”信息，重發該包，并應繼續等待，收到“確認”信息進入下一個進程，否則超時退出。報文傳輸重發機制符合下列規定：——通信出現超時，一般由通信發起端控制啟動重發機制，最多應重發2次；——對應接收端未正確收到的任何一個報文包，發起端均應啟動重發機制，最多應重發2次；——若連續三次重發均未被成功接收，應退出通信，等待下次重新建立鏈路；——自報式重發機制見圖7（d），査詢/應答式重發機制見圖8（c）。半雙工信道應采用非平衡傳輸規則，并符合下列規定：——在前一次數據通信服務結束后，方可啟動新一次數據通信；——對于單向信道，在前一次通信的傳輸過程結束后，應選擇適合的幀傳輸空閑間隔等待后才能進行下一次的發送傳輸，現場機發完報文即退出通信；——對于雙向信道，宜由上位機負責控制是否退出通信狀態。全雙工信道傳輸可釆用平衡傳輸規則，允許同時建立一個或多個通信服務。同時建立多個通信服務時，由通信發起端進行數據流控制。5.2現場機與上位機基于物聯網通用協議的傳輸鏈路協議5.2.1物理層通信傳輸信道可采用傳感器網絡與移動通信技術、互聯網技術相融合，宜采用NB-IoT組網。注：NB-IoT，即NarrowBand通信傳輸信道及其技術指標應根據扁平化組網或物聯網端對端組網工作模式確定。通信傳輸信道應能實現更加廣泛的互聯功能，將感知到的信息無障礙、高可靠性、高安全性地進行傳送。5.2.2鏈路傳輸規則針對扁平化組網工作模式，傳輸鏈路協議符合下列規定。——現場機與數據中心或通信中心間宜采用基于物聯網MQTT等傳輸協議的通信傳輸鏈路協議。現場機具有低功耗要求時，宜采用基于CoAP協議的通信傳輸鏈路協議。——上位機與數據中心或通信中心間宜采用基于物聯網MQTT等傳輸協議的通信傳輸鏈路協議。DB32/TXXXX—XXXX針對物聯網端對端組網工作模式，宜采用基于物聯網CoAP或LWM2M等傳輸協議的通信傳輸鏈路協議。5.3通信安全要求5.3.1現場機與上位機釆用MQTT協議通信時，釆用下列安全方式：——應提供客戶標識和用戶名、密碼進行應用層安全保障；——宜采用基于證書加密的WSS或TSL的加密通信方式。5.3.2現場機采用CoAP協議通信時，宜釆用DTLS加密通信方式。5.3.3上位機采用數據中心提供的API或SDK查詢監測數據時，宜采用基于證書加密的HTTPS加密通信方式。6通訊協議6.1通訊協議數據結構所有的通訊包都是由ASCII碼（漢字除外，采用UTF-8碼，8位，1字節）字符組成。通訊協議數據結構如圖9所示，不含其非必要內容。圖9通訊協議數據結構6.1.1通訊包結構組成通訊包結構組成見表2。表2通訊包結構組成表24數據段的ASCII字符數，例如：長255，則寫為“0255”426.1.2數據段結構組成數據段結構組成見表3，表3中“長度”包含字段、“=”、字段內容三部分內容。DB32/TXXXX—XXXX表3數據段結構組成表579MN=設備唯一標識，這個標識固化在設備中，用于唯一標成88Flag=標志位，這個標志位包含標準版本號、是否拆分包答V5V4V2V0DAV5~V0：標準版本號；Bit：000000表示本次標準986.1.3數據區數據區結構定義字段與其值用‘=’連接；在數據區中，同一項目的不同分類值間用‘，’來分隔。不同項目之間字段定義.1字段名字段名要區分大小寫，單詞的首個字符為大寫，其他部分為小寫。.2數據類型數據類型如下：——C4：表示最多4位的字符型字符串，不足4位按實際位數；——N5：表示最多5位的數字型字符串，不足5位按實際位數；——N14.2：用可變長字符串形式表達的數字型，表示14位整數和2位小數，帶小數點，帶符號，最大長度為18；——YYYY：日期年，如2016表示2016年；DB32/TXXXX—XXXX——MM：日期月，如09表示9月；——hh：時間小時；——mm：時間分鐘；——ss：時間秒；——zzz：時間毫秒。.3字段對照表字段對照表如表4所示，表4中“寬度”僅包含該字段的內容長度。表4字段對照表N14N3N3N4N2N14N14———— ————— A-Z/0-9A-Z/0-9—值N1N2.2間DB32/TXXXX—XXXX表4字段對照表（續）N14N14N14NewPW—N2N2N2N6N2N4xxxxxx-Info——“xxxxxx”是現場端信息編碼，詳見表B.66.2通訊流程6.2.1請求命令（三步或三步以上）請求命令流程圖見圖10。圖10請求命令流程圖6.2.2上傳命令（一步或兩步）DB32/TXXXX—XXXX上傳命令流程圖見圖11。圖11上傳命令流程圖6.2.3通知命令（兩步）通知命令流程圖見圖12和圖13。圖12現場機通知上位機命令流程圖圖13上位機通知現場機命令流程圖6.3代碼定義6.3.1系統編碼（可擴充）類別劃分DB32/TXXXX—XXXX系統編碼分為四類，每個類別表示一種系統類型：——10～29表示環境質量類別；——30～49表示環境污染源類別；——50～69表示工況類別；——91~99表示系統交互類別；——A0～Z9用于未知系統編碼擴展。系統編碼方法系統編碼（見表5）由兩位取值0~9、A~Z的字符表示。表5系統編碼表—— ——6.3.2執行結果定義（可擴充）執行結果定義如表6所示。表6執行結果定義表1 2 3—4—5—6 —6.3.3請求命令返回（可擴充）請求命令返回如表7所示。表7請求命令返回表1—2—3 4—5—DB32/TXXXX—XXXX6—7—8 9 —6.3.4數據標記（可擴充）數據標記如表8所示。表8數據標記表NFMSDCTB6.3.5命令編碼（可擴充）類別劃分共有四類命令（即請求命令、上傳命令、通知命令和交互命令），命令編碼分為以下四組：——1000~1999表示初始化命令和參數命令編碼；——2000~2999表示數據命令編碼；——3000~3999表示控制命令編碼；——9000~9999表示交互命令編碼。命令編碼方法命令編碼用4位阿拉伯數字表示，如表9所示。表9命令編碼表—————DB32/TXXXX—XXXX—— ——— ———————— ——— —— —— ——— —DB32/TXXXX—XXXX—— ——— —— —————————— 7在線監測儀器儀表與數采儀的通訊方式7.1總則在線監測儀器儀表與數采儀之間采用RS-485串行通訊標準實現數據通訊。7.2在線監測儀器儀表與數采儀的電氣接口標準7.2.1推薦在線監測儀器儀表與數采儀采用兩線制的RS-485接口，關于RS-485接口的電氣標準，參照RS-485工業總線標準。7.2.2在線監測儀器儀表和數采儀的RS-485接口應明確標明“RS485+”、“RS485-”等字樣，以指示接線方法。7.3在線監測儀器儀表與數采儀的串行通訊標準7.3.1串行通訊總線結構在線監控（監測）儀器儀表與數采儀通訊總線結構為一主多從，見圖14所示。DB32/TXXXX—XXXX圖14RS485總線系統結構7.3.2串行通訊傳輸協議推薦在線監控（監測）儀器儀表與數采儀的通訊協議采用ModbusRTU標準。ModbusRTU協議定義了一個與下層通信層無關的簡單協議數據單元（PDU）。串行鏈路上的ModbusRTU幀如圖15所示。圖15串行鏈路上的Modbus幀串行鏈路上的Modbus幀，應按以下規定：——在ModbusRTU串行鏈路上，地址字段只含有從機地址；——功能碼指示指令要執行何種操作，功能碼的后續數據是請求或響應數據字段；——差錯檢驗字段是“報文內容”數據進行“循環冗余校驗”計算所得結果，采用CRC16循環冗余校驗算法。7.4串行通訊傳輸內容（可擴充）串行通訊傳輸內容如表10所示。表10串行通訊傳輸內容表123456789對超標污染物進行留樣保存，由具體儀器確DB32/TXXXX—XXXX對在線監控（監測）儀器儀表進行零點校準，由具體儀器儀表確設置在線監控（監測）儀器儀表的采樣時間周期，由具體儀器提取在線監控（監測）儀器儀表的采樣時間周期，由具體儀器儀表對在線監控（監測）儀器儀表量程校準，由具體儀器儀表確DB32/TXXXX—XXXX（規范性）循環冗余校驗（CRC）算法CRC校驗（CyclicRedundancyCheck）是一種數據傳輸錯誤檢查方法。本文件采用ANSICRC16，簡稱CRC16。CRC16碼由傳輸設備計算后加入到數據包中。接收設備重新計算接收數據包的CRC16碼，并與接收到的CRC16碼比較，如果兩值不同，則有誤。CRC16校驗字節的生成步驟如下：a)CRC16校驗寄存器賦值為0xFFFF；b)取被校驗串的第一個字節賦值給臨時寄存器；c)臨時寄存器與CRC16校驗寄存器的高位字節進行“異或”運算，賦值給CRC16校驗寄存器；d)取CRC16校驗寄存器最后一位賦值給檢測寄存器；e)把CRC16校驗寄存器右移一位；f)若檢測寄存器值為1，CRC16校驗寄存器與多項式0xA001進行“異或”運算，賦值給CRC16校驗寄存器；g)重復步驟d)~f)，直至移出8位；h)取被校驗串的下一個字節賦值給臨時寄存器；i)重復步驟c)~h)，直至被校驗串的所有字節均被校驗；j)返回CRC16校驗寄存器的值。校驗碼按照先高字節后低字節的順序存放。CRC校驗算法示例：/************************************************************************************函數:CRC16_Checkout描述:CRC16循環冗余校驗算法。參數一:*puchMsg：需要校驗的字符串指針參數二:usDataLen：要校驗的字符串長度返回值:返回CRC16校驗碼************************************************************************************/unsignedintCRC16_Checkout(unsignedchar*puchMsg,unsignedintusDataLen){unsignedinti,j,crc_reg,check;crc_reg=0xFFFF;for(i=0;i<usDataLen;i++){crc_reg=(crc_reg>>8)^puchMsg[i];for(j=0;j<8;j++){check=crc_reg&0x0001;crc_reg>>=1;if(check==0x0001)DB32/TXXXX—XXXX{crc_reg^=0xA001;}}returncrc_reg;}示例：##0101QN=20160801085857223;ST=32;CN=1062;PW=100000;MN=010000A8900016F000169DC0;Flag=5;;CP=&&RtdInterval=30&&1C80\r\n，其中1C80為CRC16校驗碼，是對數據段QN=20160801085857223;ST=32;CN=1062;PW=100000;MN=010000A8900016F000169DC0;Flag=5;CP=&&RtdInterval=30&&進行CRC16校驗所得的校驗碼。DB32/TXXXX—XXXX（規范性）常用監測因子和設備信息編碼表（可擴充）B.1水監測因子如表B.1所示。表B.1水監測因子編碼表w00000N5.2w01001pH值—N2.2w01002—N3.2w01006—N4w01009——N3.1w01010——N3.1w01012N4w01014——N3.1w01017N5.1w01018N5.1w01019—N3.1w01020N3.1w02003—N9w02006——N9w03001—N3.1w03002 N3.1w19001 N3.2w19002N3.2w20012鋇N3.3w20023硼N3.3w20038鈷N3.4w20061鉬N3.4w20089鉈N4w20092錫N3.1w20111克N3.2w20113N4w20115克N3.1w20116N3.3w20117克N2.3w20119克N2.3w20120克N4w20121N3.2DB32/TXXXX—XXXX表B.1水監測因子編碼表（續）w20122N3.2w20123N3.3w20124N3.3w20125N3.3w20126N3.3w20127克N3.3w20128克N4.2w20138銅 N3.3w20139鋅—N3.3w20140硒—N3.3w20141砷—N3.3w20142汞 克N3.3w20143鎘 克N3.3w20144鉛—N3.3w21001N4.2w21003N4.2w21004N3.1w21006N2.3w21007N2.3w21011N3.2w21016N3.3w21017N4.2w21019N3.3w21022N3.1w21038—N6w22001N3.2w23002N3.4w25043克N3.1w33001N4w33007N4w99001N3.1B.2水處理過程監控處理工藝如表B.2所示。表B.2水處理過程監控處理工藝表1—12—2DB32/TXXXX—XXXX3—3DB32/TXXXX—XXXX表B.2水處理過程監控處理工藝表（續）4—45 56—67—78—89—9注1：AO法：即厭氧-好氧法，英文全稱為Ana注2：A2O法：又稱AAO法，即厭氧-缺氧-好氧法，英文全稱為Anaerobic-An注3：SBR法：即序批式活性污泥法，英文全稱為sequencingbatchreactoractivatedsB.3水處理過程監控監測因子編碼如表B.3所示。表B.3水處理過程監控監測因子編碼表N6.2N5.1N3.2N3.2N5.1N2.2N6.2N5.1N3.2N3.2N2.2N4.2N4.2N7N5.1N5.1N4.2N4.2N7N7N4.2N1米N2.3DB32/TXXXX—XXXXN5.1DB32/TXXXX—XXXX表B.3水處理過程監控監測因子編碼表（續）N7N4.2N4.2N5.1N5.1N5.1N5.1N4.2N4.2N4.2N4.2N4.2N1N1N7N7米N2.3米N2.3N5.1N4.2N4.2N1N5.1N5.1N5.1N5.1N4.2N4.2N7N1N1N7N7米N2.3米N2.3N5.1N4.2N4.2DB32/TXXXX—XXXXN5.1DB32/TXXXX—XXXX表B.3水處理過程監控監測因子編碼表（續）N5.1N4.2N4.2N7N7N4.2N4.2N7N1米N2.3米N2.3N4.2N4.2N5.1N5.1N4.2N7N4.2N1米N2.3米N2.3N5.1N4.2N4.2N5.1N5.1N4.2注：xx代表污水處理過程中同一工藝中使用的相同設備的編號，取值范圍為01~99。B.4現場端設備分類編碼如表B.4所示。表B.4現場端設備分類編碼表1122334DB32/TXXXX—XXXXB.5現場端信息分類編碼如表B.5所示。表B.5現場端信息分類編碼表1122334B.6現場端信息編碼如表B.6所示。表B.6現場端信息編碼表 N2N1N1————N4—N3.1—N2—— ———— N1N1N1N1N3.3—DB32/TXXXX—XXXX—DB32/TXXXX—XXXX表B.6現場端信息編碼表（續）型N1N4—N4—N4 N6 N6—N6—秒N4—N4.2 N13—N7—DB32/TXXXX—XXXX（資料性）污水污染源監測點主要污染物計算方法C.1污水排放量C.1.1時間片內（秒）污水排放量