陶椿霞TAO Chun-xia

（上海市建筑科學(xué)研究院有限公司，上海 200032）

0 引言

隨著計(jì)算機(jī)和各種先進(jìn)技術(shù)的迅猛發(fā)展，數(shù)字化技術(shù)已廣泛應(yīng)用于建筑工程設(shè)計(jì)和施工等各領(lǐng)域，利用數(shù)字化技術(shù)賦能住宅工程質(zhì)量檢測技術(shù)是住宅工程質(zhì)量監(jiān)管的重要趨勢。

目前住宅工程質(zhì)量檢測與監(jiān)管類信息系統(tǒng)標(biāo)準(zhǔn)化體系尚未健全，多類型檢測數(shù)據(jù)兼容性和互通性差，檢測數(shù)據(jù)的共享和利用不足。隨著現(xiàn)場檢測設(shè)備種類不斷增加和數(shù)據(jù)參數(shù)的日趨復(fù)雜，這對(duì)數(shù)據(jù)的采集傳輸提出了更高要求。因此亟需研究用于住宅工程質(zhì)量檢測數(shù)據(jù)采集傳輸?shù)耐ㄓ霉蚕韰f(xié)議，實(shí)現(xiàn)數(shù)據(jù)的有效管理與利用。依據(jù)目前各類常見的住宅檢測設(shè)備的信息流與數(shù)據(jù)流特征，研究數(shù)據(jù)采集傳輸?shù)墓蚕韰f(xié)議，實(shí)現(xiàn)各類檢測參數(shù)的數(shù)據(jù)接入，便于住宅工程質(zhì)量檢測平臺(tái)的高效開發(fā)和快速集成，也有利于與外部應(yīng)用系統(tǒng)的快速聯(lián)通。

1 住宅工程檢測設(shè)備

1.1 檢測設(shè)備

近年來，住宅建筑工程的質(zhì)量倍受重視。住宅工程質(zhì)量檢測主要包含地基基礎(chǔ)工程、主體結(jié)構(gòu)工程、建筑幕墻工程、鋼結(jié)構(gòu)工程等檢測。本文針對(duì)住宅工程中經(jīng)常使用到的檢測設(shè)備進(jìn)行了調(diào)研。

主要用到的住宅工程檢測設(shè)備和數(shù)據(jù)采集儀器包含激光測距儀、混凝土回彈儀、鋼筋探測儀、超聲測厚儀、全站儀、微功耗數(shù)據(jù)采集儀、靜載儀器、超聲波自動(dòng)循測儀、成槽儀器、高低應(yīng)變儀一體基樁動(dòng)測儀等。不同設(shè)備的數(shù)據(jù)傳輸方式也各有不同，如采用無線近距離Bluetooth 技術(shù)、ZigBee 自動(dòng)組網(wǎng)技術(shù)、3G/4G 無線通訊、USB、RS232等等。

1.2 數(shù)據(jù)采集傳輸現(xiàn)狀

目前在工程質(zhì)量檢測的技術(shù)中，絕大部分還停留在使用人工手動(dòng)測量或者只能將檢測的數(shù)據(jù)通過表格等形式間接導(dǎo)入到相應(yīng)系統(tǒng)的方式。對(duì)于有些檢測設(shè)備的狀態(tài)監(jiān)聽、數(shù)據(jù)采集、數(shù)據(jù)管理等功能都依賴于設(shè)備自身提供的能力，檢測時(shí)必須在設(shè)備的本地操作，無法做到數(shù)字化采集和數(shù)據(jù)傳輸。為了實(shí)現(xiàn)檢測設(shè)備數(shù)據(jù)的共享和利用，亟需針對(duì)檢測設(shè)備設(shè)計(jì)通用的數(shù)據(jù)傳輸協(xié)議。

2 傳輸協(xié)議研究

2.1 常用傳輸協(xié)議

當(dāng)前常用的傳輸協(xié)議有RESTful/HTTP、MQTT、TCP/IP等，各種傳輸協(xié)議情況如下。

2.1.1 RESTful/HTTP 協(xié)議

RESTful/HTTP 協(xié)議是指利用REST 技術(shù)再結(jié)合HTTP 協(xié)議的特性和能力，通過底層直接建立在HTTP 協(xié)議之上，可以充分發(fā)揮Web 的潛力。它是一種基于請(qǐng)求/響應(yīng)模型的協(xié)議，客戶端發(fā)送請(qǐng)求并等待服務(wù)器響應(yīng)。RESTful 是一種基于資源的軟件架構(gòu)風(fēng)格。RESTful 架構(gòu)遵循統(tǒng)一接口原則，統(tǒng)一接口必須符合一組受限的預(yù)定義操作，無論什么資源，都是通過使用相同的接口進(jìn)行資源的訪問。

按RESTful 架構(gòu)風(fēng)格規(guī)定的數(shù)據(jù)基本操作CRUD（即數(shù)據(jù)的增、查、改、刪），分別對(duì)應(yīng)HTTP 方法，統(tǒng)一了數(shù)據(jù)操作的接口，僅通過HTTP 方法，就可完成對(duì)數(shù)據(jù)的所有操作工作。RESTful 的數(shù)據(jù)接口更加簡便高效、統(tǒng)一安全。

2.1.1.1 請(qǐng)求的方法

在請(qǐng)求時(shí)帶上請(qǐng)求的方法，主要為所請(qǐng)求的事件進(jìn)行一個(gè)分類縮寫。用于精確地區(qū)分具體功能，可簡化接口架構(gòu)復(fù)雜性。通過HTTP 進(jìn)行通信交互，所有接口都是標(biāo)準(zhǔn)的 HTTP 協(xié)議請(qǐng)求方式：GET，POST，PUT，DELETE，PATCH 等等。

2.1.1.2 URI

URI 表示統(tǒng)一資源定位符，RESTful 架構(gòu)風(fēng)格要求用URI 指向資源，每個(gè)URI 對(duì)應(yīng)一個(gè)特定的資源，一個(gè)資源可以有一個(gè)或多個(gè)URI 與之對(duì)應(yīng)。在Web 開發(fā)中，URI 也就是URL 地址。因此要獲取此資源，訪問其URI 資源的地址即可實(shí)現(xiàn)。

2.1.1.3 HTTP 規(guī)范響應(yīng)狀態(tài)碼

HTTP 的特點(diǎn)是簡單靈活、易于擴(kuò)展、擁有成熟的生態(tài)規(guī)范，可以實(shí)現(xiàn)客戶端與服務(wù)器之間交互的松耦合，降低客戶端和服務(wù)器之間的交互延遲。HTTP 的狀態(tài)碼是服務(wù)端對(duì)客戶端請(qǐng)求的返回結(jié)果，用于標(biāo)記服務(wù)端對(duì)于該請(qǐng)求的處理情況。

2.1.2 MQTT 協(xié)議

隨著越來越多的物聯(lián)網(wǎng)設(shè)備采用MQTT 作為支持協(xié)議，在圖1 物聯(lián)網(wǎng)數(shù)據(jù)采集系統(tǒng)構(gòu)成中，MQTT 協(xié)議在OSI 模型體系中屬于應(yīng)用層協(xié)議。它是一種基于發(fā)布/訂閱模式的“輕量級(jí)”的通信協(xié)議，該協(xié)議構(gòu)建于TCP/IP 協(xié)議之上。因此只要是支持TCP/IP 協(xié)議的地方，都可以使用MQTT，可以有效降低檢測設(shè)備接入難度和使用成本。

圖1 物聯(lián)網(wǎng)數(shù)據(jù)采集系統(tǒng)構(gòu)成

2.1.2.1 MQTT 特點(diǎn)

①使用發(fā)布/訂閱消息模式，提供一對(duì)多的消息發(fā)布，客戶端彼此之間獨(dú)立，解除了應(yīng)用程序耦合性，增強(qiáng)整個(gè)系統(tǒng)的可靠性。就算一個(gè)客戶端出現(xiàn)故障時(shí)，整個(gè)系統(tǒng)可以繼續(xù)正常工作。

②二進(jìn)制形式編碼，低功耗，協(xié)議開銷小，消息的分發(fā)不受低帶寬、網(wǎng)絡(luò)延遲高、通信不穩(wěn)定等影響，屬于物聯(lián)網(wǎng)的一個(gè)標(biāo)準(zhǔn)傳輸協(xié)議，可降低網(wǎng)絡(luò)流量。

③使用TCP/IP 提供網(wǎng)絡(luò)連接，客戶端（Clients）與代理（Broker）之間可保持TCP 長連接。采用心跳機(jī)制，通過間斷性的發(fā)送報(bào)文，來保持客戶端和服務(wù)端的心跳長連接，以減少電量的消耗，提升系統(tǒng)資源利用率。

④報(bào)文結(jié)構(gòu)緊湊、載荷格式靈活，載荷內(nèi)容支持多種數(shù)據(jù)傳輸，如文本、加密數(shù)據(jù)、圖像及二進(jìn)制數(shù)據(jù)，可以拓展更豐富的應(yīng)用業(yè)務(wù)。

⑤三種消息發(fā)布服務(wù)質(zhì)量QoS：“最多一次”“最少一次”“只有一次”。

“QoS0 最多一次”：指消息只傳遞一次，這種情況可能會(huì)發(fā)生信息丟失，這一級(jí)別的QoS 可用于如環(huán)境傳感器數(shù)據(jù)，丟失一次記錄無所謂，因?yàn)榈却痪煤筮€會(huì)有第二次發(fā)送。

“QoS1 最少一次”：即保證消息準(zhǔn)確到達(dá)，但是可能會(huì)造成信息重復(fù)發(fā)送。

“QoS2 只有一次”：一般使用在對(duì)數(shù)據(jù)完整性和時(shí)效性有高要求的情況下，與此同時(shí)多次往返確認(rèn)會(huì)造成資源過度消耗以及影響并發(fā)。一般適用于一些要求較嚴(yán)格的計(jì)費(fèi)系統(tǒng)中。

⑥具有安全性，支持基于TLS/SSL 的加密和認(rèn)證機(jī)制，保護(hù)通信的安全性。

2.1.2.2 MQTT 協(xié)議格式

MQTT 協(xié)議格式主要由固定報(bào)文頭、可變報(bào)文頭和有效載荷三部分組成。不同的業(yè)務(wù)需求下，預(yù)定義的控制報(bào)文也不同，主要區(qū)別在于是否包含可變報(bào)文頭或有效載荷。整體MQTT 的消息格式如圖2 所示。

圖2 整體MQTT 的消息格式

“固定報(bào)文頭”：它由兩部分組成，第一部分包含了報(bào)文的控制類型和報(bào)文的標(biāo)志；第二部分表示除固定報(bào)文頭長度外剩余的長度。

第一部分高4 位為MQTT 控制報(bào)文的類型，具有實(shí)際意義的控制報(bào)文類型主要分為四大類：連接類、?；铑悺⒃掝}訂閱類、消息發(fā)布類。根據(jù)取值例如：0001 可知控制報(bào)文對(duì)應(yīng)CONNECT 連接類型。

“可變報(bào)文頭”：用來記錄一些協(xié)議內(nèi)容，例如協(xié)議名稱、協(xié)議級(jí)別、連接標(biāo)志和心跳間隔四個(gè)字段組成。

“有效載荷”：是消息主體，是整個(gè)協(xié)議格式中最為重要的部分。物聯(lián)網(wǎng)設(shè)備所要傳遞的數(shù)據(jù)都由這部分保存，表示訂閱者具體要使用的消息內(nèi)容。有效載荷消息體中包含 CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRI BE、PUBLISH 幾種常用報(bào)文類型的消息。

TCP/IP 協(xié)議：TCP/IP 協(xié)議是互聯(lián)網(wǎng)使用最廣泛的協(xié)議之一，它分為兩個(gè)部分：傳輸控制協(xié)議和因特網(wǎng)協(xié)議。TCP/IP 是一個(gè)協(xié)議族，包括多個(gè)網(wǎng)絡(luò)協(xié)議，比如IP、ICMP、TCP、HTTP、FTP、POP3 等。它是因特網(wǎng)的核心協(xié)議，用于在互聯(lián)網(wǎng)上進(jìn)行數(shù)據(jù)傳輸和網(wǎng)絡(luò)通信。TCP 負(fù)責(zé)數(shù)據(jù)的可靠傳輸，IP 則負(fù)責(zé)數(shù)據(jù)包的路由。

TCP/IP 協(xié)議按照層次由上到下：最上層是應(yīng)用層，有我們熟悉的協(xié)議HTTP、FTP 等等。第二層是傳輸層，著名的TCP 和UDP 協(xié)議就在這個(gè)層次。第三層則是網(wǎng)絡(luò)層，IP協(xié)議就屬于這一層，它是一種無連接的協(xié)議，專門負(fù)責(zé)網(wǎng)絡(luò)層的路由選擇和數(shù)據(jù)包的傳輸。它使用IP 地址定位網(wǎng)絡(luò)上的設(shè)備，并將數(shù)據(jù)包從源地址傳輸?shù)侥康牡刂?。IP 協(xié)議提供了一個(gè)層次化、可擴(kuò)展的網(wǎng)絡(luò)架構(gòu)，使得互聯(lián)網(wǎng)上的大部分設(shè)備都可以進(jìn)行通信。第四層是數(shù)據(jù)鏈路層，這個(gè)層次為等待傳送的數(shù)據(jù)加入一個(gè)以太網(wǎng)協(xié)議頭，并進(jìn)行CRC 編碼，為最后的數(shù)據(jù)傳輸做準(zhǔn)備。

2.2 傳輸格式

常用的網(wǎng)絡(luò)數(shù)據(jù)傳輸格式包含：JSON、XML、ProtoBuf等。對(duì)比三種最常用的數(shù)據(jù)傳輸格式如下：

①XML：它是可擴(kuò)展標(biāo)記語言與Oracle、Access 和SQL Server 等數(shù)據(jù)庫不同，數(shù)據(jù)庫提供了更強(qiáng)有力的數(shù)據(jù)存儲(chǔ)和分析能力。XML 簡單易于在任何應(yīng)用程序中讀寫數(shù)據(jù)，這使得XML 很快成為數(shù)據(jù)交換的公共語言。但是XML 文件龐大，傳輸占帶寬、服務(wù)器端和客戶端都需要花費(fèi)大量代碼來解析XML，導(dǎo)致代碼變得異常復(fù)雜且不易維護(hù)，客戶端不同瀏覽器之間解析XML 的方式不一致，需要重復(fù)編寫很多代碼。XML 的有效載荷實(shí)在太低，封裝和解析效率太低，所以只適用于非常少量，對(duì)性能沒要求的網(wǎng)絡(luò)流量。

②JSON：它是一種輕量級(jí)的數(shù)據(jù)交換格式，易于機(jī)器解析和生成。將采集階段得到的數(shù)據(jù)根據(jù)具體的通訊協(xié)議規(guī)約，進(jìn)行有效數(shù)據(jù)的過濾，標(biāo)準(zhǔn)數(shù)據(jù)的格式化，它采用完全獨(dú)立于語言的文本格式。它可以將JavaScript 對(duì)象中表示的一組數(shù)據(jù)轉(zhuǎn)換為字符串，在網(wǎng)絡(luò)或程序之間輕松地傳遞這個(gè)字符串，并可以在需要時(shí)將它還原為各編程語言所支持的數(shù)據(jù)格式。

③ProtoBuf：它是一種數(shù)據(jù)交換格式，又稱PB 編碼，由Google 開源，類似于JSON、XML，但其內(nèi)部是純二進(jìn)制格式，比JSON，XML 等格式要更精煉，主要用于數(shù)據(jù)的序列化和反序列化，目前官方提供了JAVA、Python、C++等多種語言的實(shí)現(xiàn)。

綜上幾種傳輸格式分析，XML 適用于傳輸文檔，而JSON 更適用于傳輸信息對(duì)象，因此本文研究采用JSON的傳輸格式。

3 通用數(shù)據(jù)采集共享協(xié)議設(shè)計(jì)

針對(duì)住宅工程質(zhì)量檢測設(shè)備數(shù)據(jù)傳輸協(xié)議，提供統(tǒng)一的JSON 格式。本文選擇兩種傳輸協(xié)議Restful/HTTP 協(xié)議和MQTT 協(xié)議，以支撐絕大多數(shù)設(shè)備數(shù)據(jù)傳輸。

3.1 Restful/HTTP 協(xié)議設(shè)計(jì)

對(duì)于本次研究的數(shù)據(jù)采集協(xié)議中，基于Restful/HTTP協(xié)議使用的是POST 請(qǐng)求方式，請(qǐng)求和響應(yīng)的消息內(nèi)容采用JSON 格式。

①數(shù)據(jù)接口描述如下：

請(qǐng)求類型：POST

③HTTP 狀態(tài)碼：上傳成功服務(wù)端返回2xx 的HTTP的狀態(tài)碼；上傳失敗則返回4xx/5xx HTTP 的狀態(tài)碼。

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

對(duì)于本次研究的數(shù)據(jù)采集協(xié)議中，基于MQTT 協(xié)議滿足從服務(wù)端主動(dòng)向客戶端發(fā)起推送方式。其訂閱的主題格式：deviceData/{projectId}，projectId 代表具體項(xiàng)目，使用“/”作為分隔符，表示只訂閱“deviceData”該層級(jí)下的所有主題以及所屬projectId 所屬項(xiàng)目的主題內(nèi)容。數(shù)據(jù)采用JSON 格式，每條MQTT 消息上傳一個(gè)監(jiān)測設(shè)備的所有參數(shù)數(shù)據(jù)。

4 結(jié)論

本文研究了常用數(shù)據(jù)傳輸協(xié)議和數(shù)據(jù)傳輸格式，設(shè)計(jì)了住宅工程質(zhì)量檢測平臺(tái)的數(shù)據(jù)采集通用協(xié)議，最終采用RESTful/HTTP 協(xié)議和MQTT 協(xié)議。針對(duì)種類繁多的檢測設(shè)備類型，盡可能做到一站式全方位數(shù)據(jù)采集。將現(xiàn)代化通信技術(shù)與住宅工程質(zhì)量檢測數(shù)據(jù)采集系統(tǒng)相結(jié)合，實(shí)現(xiàn)數(shù)據(jù)的無線采集與傳輸，大大減少人力、物力成本，將有力推動(dòng)住宅工程質(zhì)量檢測數(shù)字化進(jìn)程。