丁 磊 陳勁鴻 李 崢 鄧杰航

(廣東工業(yè)大學(xué)計算機學(xué)院 廣東 廣州 510006)

0 引 言

近年來農(nóng)產(chǎn)品安全問題日益顯現(xiàn)。當出現(xiàn)農(nóng)產(chǎn)品安全問題的時候，監(jiān)督機構(gòu)、供應(yīng)鏈各環(huán)節(jié)、消費者能及時獲取農(nóng)產(chǎn)品信息并迅速定位產(chǎn)生安全問題的責(zé)任方，對于協(xié)助解決農(nóng)產(chǎn)品安全問題有著重要的作用和意義，農(nóng)產(chǎn)品追溯在這樣的背景下應(yīng)運而生。

農(nóng)產(chǎn)品追溯的研究有多個方面，如農(nóng)產(chǎn)品身份識別以及防偽[1]，農(nóng)產(chǎn)品生產(chǎn)和運輸?shù)男畔⒉杉c過程監(jiān)控[2-4]，農(nóng)產(chǎn)品追溯信息管理與查詢平臺的開發(fā)[5]，信息透明、安全、保真追溯鏈的構(gòu)建[6-7]等。目前，農(nóng)產(chǎn)品追溯的研究大多針對包裝農(nóng)產(chǎn)品，人們可通過包裝上的標簽獲取追溯信息。但對于散裝的農(nóng)產(chǎn)品而言，其散裝稱重銷售的特性使人們難以預(yù)先為其粘貼標簽。Feng等[8]提出一種RFID電子秤，能在稱重后打印含追溯碼的標簽。但為交易的每種農(nóng)產(chǎn)品打印標簽一方面會增加銷售操作的復(fù)雜性，另一方面大量標簽的使用會給銷售方帶來經(jīng)濟上的負擔(dān)。此外，消費者作為追溯鏈中的重要一環(huán)，其信息往往存在缺失。劉艷飛等[9]提出一種雙向追溯系統(tǒng)，可向下追溯到具體的消費群體，但需要具有RFID或NFC讀寫功能的設(shè)備支持。

綜上，散裝農(nóng)產(chǎn)品在銷售過程中的身份標識、完整追溯鏈的構(gòu)建為實現(xiàn)有效追溯的難點。因此，本文以電子支付、MQTT協(xié)議、GS1編碼體系等關(guān)鍵技術(shù)為核心，從上述難點展開研究，探索一種對散裝農(nóng)產(chǎn)品進行有效追溯的系統(tǒng)方案。利用基于電子支付的數(shù)據(jù)采集手段與GS1編碼體系構(gòu)建散裝農(nóng)產(chǎn)品電子虛擬標簽，實現(xiàn)農(nóng)產(chǎn)品的身份標識，并通過基于MQTT協(xié)議的數(shù)據(jù)同步與推送網(wǎng)絡(luò)構(gòu)建信息的關(guān)聯(lián)性。最終，追溯平臺利用算法檢索具有關(guān)聯(lián)性的數(shù)據(jù)并構(gòu)建完整的追溯鏈。用戶通過可視化界面即可實現(xiàn)農(nóng)產(chǎn)品信息的有效追溯。

1 散裝農(nóng)產(chǎn)品追溯模型

一種典型的散裝農(nóng)產(chǎn)品追溯模型如圖1所示。農(nóng)產(chǎn)品信息的采集、處理與呈現(xiàn)賦予散裝農(nóng)產(chǎn)品可追溯的特性。供應(yīng)鏈各環(huán)節(jié)、消費者、檢驗檢疫部門、物流配送單位等在農(nóng)產(chǎn)品銷售過程中通過多種渠道提供可追溯信息。這些信息由服務(wù)器統(tǒng)一存儲與處理以形成追溯鏈。追溯鏈包含了散裝農(nóng)產(chǎn)品的完整銷售路徑，以及相關(guān)環(huán)節(jié)的信息。追溯者可通過追溯鏈定位安全問題的責(zé)任方，亦可為散裝農(nóng)產(chǎn)品召回提供依據(jù)。

圖1 散裝農(nóng)產(chǎn)品追溯模型

2 系統(tǒng)總體設(shè)計與關(guān)鍵技術(shù)

2.1 系統(tǒng)總體設(shè)計

系統(tǒng)總體設(shè)計如圖2所示，從結(jié)構(gòu)上分為追溯電子秤、追溯平臺、支付平臺和Web客戶端四部分。追溯電子秤采用Android設(shè)備作為控制終端，分別連接稱重與打印模塊，主要實現(xiàn)交易數(shù)據(jù)的采集、存儲與同步的功能。追溯平臺部署有MQTT Broker、Web Server和MySQL數(shù)據(jù)庫，用于處理、存儲和推送追溯電子秤上傳的數(shù)據(jù)并構(gòu)建追溯鏈。支付服務(wù)器使用銀聯(lián)商務(wù)提供的聚合支付接口，能響應(yīng)設(shè)備的請求，返回支付信息。Web客戶端通過瀏覽器訪問Web Server，并通過可視化界面進行農(nóng)產(chǎn)品追溯、電子秤監(jiān)控等操作。

圖2 系統(tǒng)總體設(shè)計

2.2 基于虛擬標簽的追溯鏈構(gòu)建

虛擬標簽包含農(nóng)產(chǎn)品交易過程中產(chǎn)生的關(guān)鍵信息，通過信息編碼與推送機制，不同的虛擬標簽形成關(guān)聯(lián)，為追溯鏈構(gòu)建算法的實現(xiàn)提供基礎(chǔ)。

(1) 農(nóng)產(chǎn)品編碼。系統(tǒng)利用GS1編碼體系對農(nóng)產(chǎn)品相關(guān)信息進行編碼，關(guān)鍵編碼如表1所示。GTIN碼用于標識不同種類的農(nóng)產(chǎn)品，通過與系列號的配合使用，能對每個售出的散裝農(nóng)產(chǎn)品進行唯一標識。訂購單代碼則用于標識交易，每一筆成功的交易均會產(chǎn)生一個唯一的訂購單代碼。

表1 農(nóng)產(chǎn)品信息關(guān)鍵編碼

系統(tǒng)設(shè)計有source_gtin、self_gtin、terminus_gtin三類GTIN碼，分別標識農(nóng)產(chǎn)品的來源、所屬和流向。通過交易信息推送機制，三類GTIN碼在不同的銷售階段被更新，因此利用GTIN碼可還原某種農(nóng)產(chǎn)品的完整銷售路徑。結(jié)合訂購單代碼和農(nóng)產(chǎn)品系列號，剔除冗余的信息，即可得到一條特定的追溯鏈。

(2) 交易信息推送機制。供應(yīng)鏈相鄰的兩個環(huán)節(jié)在完成一筆交易后，下游環(huán)節(jié)需將交易信息錄入數(shù)據(jù)庫中，方便統(tǒng)計農(nóng)產(chǎn)品存量以指導(dǎo)銷售工作的進行。為了克服數(shù)據(jù)人工入庫耗時耗力、容易出現(xiàn)紕漏的缺點，本文系統(tǒng)利用MQTT協(xié)議基于訂閱/發(fā)布的通信特性，以及電子支付信息、用戶信息和設(shè)備信息的關(guān)聯(lián)性，實現(xiàn)交易信息的推送。實現(xiàn)流程如圖3所示。追溯平臺根據(jù)供應(yīng)鏈上一環(huán)節(jié)所上傳的交易記錄中的關(guān)鍵信息，從數(shù)據(jù)庫中篩選出需要進行消息推送的下一環(huán)節(jié)。若存在該下一環(huán)節(jié)則提取交易記錄中的農(nóng)產(chǎn)品信息錄入到數(shù)據(jù)庫中，并推送至該環(huán)節(jié)的設(shè)備上。平臺與上一環(huán)節(jié)設(shè)備將記錄的push_status置為1，表示推送成功。若不存在該下一環(huán)節(jié)，則push_status置為2，表示無需推送。交易信息推送機制利用農(nóng)產(chǎn)品編碼規(guī)則構(gòu)建數(shù)據(jù)間的關(guān)聯(lián)性，為追溯鏈的構(gòu)建提供基礎(chǔ)。

圖3 交易信息推送流程

(3) 追溯鏈構(gòu)建算法。一條典型的追溯鏈為一個有向圖，以其中的某點為例，其來源為線性結(jié)構(gòu)，去向為樹狀結(jié)構(gòu)。因此需要使用兩種算法來分別獲取上述兩種結(jié)構(gòu)，并整合為一條完整的追溯鏈。追溯鏈線性部分的基本結(jié)構(gòu)如圖4(a)所示，相鄰兩個環(huán)節(jié)交易成功后，下一環(huán)節(jié)便帶有指向上一環(huán)節(jié)的信息，可使用鏈表遍歷算法獲取散裝農(nóng)產(chǎn)品來源路徑，算法中的每次循環(huán)均為一個“向上一步”的過程，循環(huán)結(jié)束即可獲取散裝農(nóng)產(chǎn)品來源的每一步的信息。追溯鏈樹狀部分的基本結(jié)構(gòu)如圖4(b)所示，當一批散裝農(nóng)產(chǎn)品被不同的購買者購買后，一個上游環(huán)節(jié)便帶有了指向多個下游環(huán)節(jié)的信息，可使用深度優(yōu)先搜索算法(Depth First Search,DFS)[10]獲取農(nóng)產(chǎn)品的去向路徑，算法中的每次遞歸均為一個“向下一步”的過程，遞歸結(jié)束即可獲取散裝農(nóng)產(chǎn)品去向的每一層次各環(huán)節(jié)的信息。

(a) 線性結(jié)構(gòu)

(b) 樹狀結(jié)構(gòu)圖4 追溯鏈基本結(jié)構(gòu)

上述遍歷最終得到一條線性路徑，無法表達追溯鏈的層次結(jié)構(gòu)。層次結(jié)構(gòu)的缺失可能會導(dǎo)致無法得到一條唯一的追溯鏈，所以需要在算法中加入記錄層次結(jié)構(gòu)的邏輯。以農(nóng)產(chǎn)品去向追溯鏈構(gòu)建為例，其算法如算法1所示，定義一種包含了追溯鏈某環(huán)節(jié)的關(guān)鍵信息和其鄰接點集合的結(jié)構(gòu)體Vertex，在DFS算法的每次遞歸中為當前的頂點的結(jié)構(gòu)體添加鄰接點，即可將數(shù)據(jù)庫中數(shù)據(jù)的層次關(guān)系映射到各結(jié)構(gòu)體中。

算法1構(gòu)建農(nóng)產(chǎn)品去向追溯連

Vertex {

information;

//關(guān)鍵信息

vertexList；

//鄰接點集合

}

DFS(vertex) {

//從數(shù)據(jù)庫中獲取當前頂點關(guān)鍵信息

vertex.information=get information from database

//從數(shù)據(jù)庫中獲取當前頂點的鄰接點集合

nextVertexs=get next vertexs from database

//遍歷鄰接點集合

for nextVertex:nextVertexs

//添加鄰接點

vertex.vertexList.add(nextVertex)

//進行DFS遍歷

DFS(nextVertex)

}

2.3 多協(xié)議通信框架

追溯系統(tǒng)中Android終端需要與具有不同通信方式的外圍設(shè)備進行數(shù)據(jù)交互。為了降低應(yīng)用程序的復(fù)雜性，防止通信阻塞。利用模塊化、面向?qū)ο蠛投嗑€程的思想，設(shè)計一種基于Service組件的多協(xié)議通信框架，其結(jié)構(gòu)如圖5所示。

圖5 多協(xié)議通信框架

通信服務(wù)模塊作為Service組件封裝基本通信方法和方法代理。基本通信方法用于與外圍設(shè)備實現(xiàn)基本通信邏輯，如連接、數(shù)據(jù)讀寫等。通過綁定服務(wù)，上層程序邏輯能獲取相應(yīng)的方法代理，后者能提供調(diào)用基本通信方法的接口。數(shù)據(jù)協(xié)議模塊能將數(shù)據(jù)幀解析為若干個參數(shù)并存儲在參數(shù)模塊中，用戶界面能從參數(shù)模塊中獲取所需的應(yīng)用數(shù)據(jù)。同理，用戶界面可將應(yīng)用數(shù)據(jù)更新至參數(shù)模塊中并由數(shù)據(jù)協(xié)議模塊整合為完整的數(shù)據(jù)幀。通信過程中各種狀態(tài)，如是否成功連接、是否成功讀寫數(shù)據(jù)等，會經(jīng)由通信狀態(tài)模塊中的廣播發(fā)送者發(fā)送到系統(tǒng)的消息池中。用戶界面可通過注冊相應(yīng)的廣播接收者和設(shè)置消息過濾規(guī)則來獲取相應(yīng)的狀態(tài)廣播，并根據(jù)廣播的內(nèi)容組織通信邏輯，確保通信的可靠性。

2.4 可靠通信實現(xiàn)

(1) 通信協(xié)議選擇。目前追溯電子秤與追溯平臺多采用HTTP輪詢或Socket進行通信[11-12]。MQTT作為一種輕量級的、持久化的雙向通信協(xié)議，其報文結(jié)構(gòu)緊湊，固定頭部只有2字節(jié)，且提供多種服務(wù)質(zhì)量，能在保證通信的可靠性同時降低數(shù)據(jù)傳輸?shù)拈_銷[13-14]。為了實現(xiàn)可靠通信，系統(tǒng)采用MQTT協(xié)議構(gòu)建追溯電子秤與追溯平臺之間的數(shù)據(jù)同步與推送網(wǎng)絡(luò)。Web客戶端則使用HTTPS和基于MQTT的Web Socket協(xié)議與追溯平臺連接。對于實時性較高的信息，如電子秤狀態(tài)，通過Web Socket持久化連接獲取。而對于一般的信息，如追溯信息，則通過HTTPS的請求/響應(yīng)機制獲取。

(2) MQTT話題與載荷設(shè)計。MQTT基于話題進行消息路由[15]，為了確保追溯平臺與不同電子秤之間通信的獨立性，設(shè)計設(shè)備與平臺兩種話題，分別被追溯平臺與電子秤訂閱。平臺話題包含標識不同的設(shè)備字符串，因此電子秤可訂閱自身的平臺話題，避免其他消息的干擾。

MQTT部分報文中包含載荷結(jié)構(gòu)，由于協(xié)議采用字節(jié)的形式傳輸載荷，因此本系統(tǒng)采用JSON格式定義載荷，并設(shè)計了3個鍵值對：type、data和sign。type代表載荷類型，系統(tǒng)可根據(jù)該類型對數(shù)據(jù)進行特定的處理；data代表載荷數(shù)據(jù)，其為具體的應(yīng)用數(shù)據(jù)；sign為線程標記，系統(tǒng)可通過該標記對大批量的數(shù)據(jù)進行分批傳輸。

(3) 通信安全設(shè)計。追溯系統(tǒng)的數(shù)據(jù)涉及用戶信息，因此需保證通信的安全性。MQTT、HTTP和Web Socket均為應(yīng)用層協(xié)議，可采用SSL/TLS協(xié)議實現(xiàn)身份認證和數(shù)據(jù)加密?？紤]到追溯電子秤和Web用戶數(shù)量眾多的問題，系統(tǒng)采用SSL/TLS單向認證的方式認證追溯平臺，并使用檢驗用戶名和密碼的方式實現(xiàn)電子秤與Web用戶的身份認證。以追溯電子秤的安全通信為例，其流程如圖6所示。

圖6 電子秤安全通信時序圖

3 系統(tǒng)測試

3.1 測試平臺搭建

測試平臺如下：PC服務(wù)器的配置為Windows 10操作系統(tǒng)、Core i5-4210U處理器，內(nèi)存8 GB，部署MQTT Broker、Web Server和數(shù)據(jù)庫。負載測試機的配置為Ubuntu操作系統(tǒng)、Core i5-2450M處理器，內(nèi)存6 GB，運行測試程序。PC服務(wù)器和負載測試機處于同一局域網(wǎng)中，網(wǎng)絡(luò)帶寬為1 MB。Android終端配置為：Android 7.0操作系統(tǒng)，全志A33處理器，內(nèi)存1 GB，運行追溯電子秤App。

3.2 并發(fā)連接性能測試

負載測試機分別模擬1 000至10 000的客戶端向MQTT Broker發(fā)起連接請求。采用SSL/TLS單向認證方式構(gòu)建加密傳輸通道，采用用戶名密碼方式認證模擬客戶端，客戶端新增的速率為每秒1 000個。測試結(jié)果如表2所示，隨著客戶端數(shù)目的增加，在時間方面，平均連接時間和最大連接時間有所增長，而最小連接時間則變化不大；在資源消耗方面，服務(wù)器的CPU占用率與內(nèi)存占用數(shù)亦有所增長，其中CPU占用率在并發(fā)連接期間會迅速增長至一個峰值，隨后會不斷下降，而內(nèi)存占用則保持相對穩(wěn)定。綜上，系統(tǒng)對服務(wù)器的資源要求較高，但在需要加密通信和身份認證的情況下，平均連接時間較短，能提供較好的用戶體驗。

表2 并發(fā)連接測試結(jié)果

3.3 消息傳輸性能測試

交易信息、商品信息等采用逐條傳輸?shù)姆绞竭M行同步或推送，每條消息的數(shù)據(jù)量一般在1 KB以下。因此采用負載測試機模擬5 000或10 000臺設(shè)備分別發(fā)布大小為1 KB的消息，并記錄消息從發(fā)布到成功接收所需時間。測試結(jié)果如表3所示。

表3 消息傳輸性能測試結(jié)果

隨著消息數(shù)量與服務(wù)質(zhì)量的提升，在時間方面，平均傳輸時間和最大傳輸時間呈小幅度增長；在資源消耗方面，服務(wù)器CPU占用率峰值亦隨之提升，而內(nèi)存占用數(shù)則與消息數(shù)量相關(guān)。綜上，系統(tǒng)在面對較大的消息壓力時，能以較快的速率完成消息的傳輸。當系統(tǒng)需要處理更大的消息量時，需要提高服務(wù)器性能和采用MQTT Broker集群的方式來均衡負載。

3.4 追溯結(jié)果有效呈現(xiàn)測試

在數(shù)據(jù)庫中導(dǎo)入測試數(shù)據(jù)，測試追溯鏈是否能成功構(gòu)建。如圖7所示，供應(yīng)商A作為追溯者，通過其提供的訂購單代碼成功檢索出所有相關(guān)聯(lián)的數(shù)據(jù)，并生成一條追溯鏈。可見測試商品經(jīng)歷了5個層次的流通環(huán)節(jié)。點擊某環(huán)節(jié)的相應(yīng)實體，可獲取相應(yīng)的追溯信息。結(jié)果表明，使用本文所述編碼方式對散裝農(nóng)產(chǎn)品流通過程中的關(guān)鍵信息進行編碼，能有效構(gòu)建完整的追溯鏈條。

圖7 追溯鏈構(gòu)建結(jié)果

4 結(jié) 語

針對散裝農(nóng)產(chǎn)品粘貼產(chǎn)品標識困難從而難以追溯的問題，本文設(shè)計并實現(xiàn)一種由追溯電子秤與追溯平臺組成的散裝農(nóng)產(chǎn)品追溯系統(tǒng)。以電子支付、GS1編碼體系、MQTT協(xié)議等關(guān)鍵技術(shù)為核心，通過信息的采集、編碼與傳輸解決上述問題。經(jīng)測試，系統(tǒng)能實現(xiàn)數(shù)據(jù)的實時采集與追溯鏈條的構(gòu)建，可滿足對散裝農(nóng)產(chǎn)品進行信息追溯的需求。