目前市面上大多數(shù)的超聲波熱量表數(shù)據(jù)采集都是通過485總線的方式進行串口數(shù)據(jù)采集，因485總線的采集方式采集距離受到現(xiàn)場很大因素的影響，因此越來越多的用戶選擇無線方式進行采集數(shù)據(jù)，并上報采集數(shù)據(jù)，無線采集的方式又可以細分為lora集中器方式，NB網(wǎng)絡并發(fā)的方式，GPRS網(wǎng)絡方式(3G和4G)，無線電臺方式，上述方式均可上報至服務器端，服務器端均解析modbus RTU的回復報文就可以將采集到的數(shù)據(jù)進行數(shù)據(jù)庫存儲，本質上還是依托于設備的modbus RTU協(xié)議。

   因市面上大面積采用的4G方式均為獲取單臺超聲波熱量表的儀表信息，因此一般一臺設備配一個數(shù)據(jù)采集模塊進行數(shù)據(jù)采集，數(shù)據(jù)采集一般可分為主動和被動式，主動方式一般為數(shù)據(jù)采集模塊內(nèi)可配置時鐘，定時時間，到固定時間點，模塊立即對超聲波熱量表的485端口發(fā)送采集指令，獲取當前超聲波熱量表的當前數(shù)據(jù)，并附加采集當時前時刻的時鐘進行遠程上報，上報的方式可以是原始的16進制數(shù)據(jù)，也可以是解析好的10進制數(shù)據(jù)組成的json數(shù)據(jù)包，json數(shù)據(jù)包發(fā)送至服務器端，服務器端就可以直接進行解析，無須進行數(shù)據(jù)解碼工作，另一種方式是采用TCP/IP的方式，進行網(wǎng)絡通訊，數(shù)據(jù)采集模塊對服務器端發(fā)送注冊碼和心跳包，進行身份注冊，完成注冊后根據(jù)注冊碼進行分包，服務器下發(fā)指ding類型的請求數(shù)據(jù)指令，數(shù)據(jù)采集模塊獲取到請求指令轉發(fā)給底層的超聲波熱量表設備，超聲波流量表設備收到后，立刻進行回復，服務器收到回復，回復內(nèi)容為標準的modbus RTU的16進制原始報文，根據(jù)通訊協(xié)議在服務器端編寫解碼函數(shù)，對對應的設備進行解碼，將數(shù)據(jù)整理并存入數(shù)據(jù)庫，遠程服務器端可以從數(shù)據(jù)庫內(nèi)獲取數(shù)據(jù)并可以展示在網(wǎng)站上，因node.js的異步性能*，因此比較推薦采集程序采用node.js開發(fā)。