散裝農(nóng)產(chǎn)品追溯的關(guān)鍵技術(shù)研究與實(shí)現(xiàn)

丁 磊 陳勁鴻 李 崢 鄧杰航

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

0 引 言

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

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

綜上，散裝農(nóng)產(chǎn)品在銷售過程中的身份標(biāo)識(shí)、完整追溯鏈的構(gòu)建為實(shí)現(xiàn)有效追溯的難點(diǎn)。因此，本文以電子支付、MQTT協(xié)議、GS1編碼體系等關(guān)鍵技術(shù)為核心，從上述難點(diǎn)展開研究，探索一種對(duì)散裝農(nóng)產(chǎn)品進(jìn)行有效追溯的系統(tǒng)方案。利用基于電子支付的數(shù)據(jù)采集手段與GS1編碼體系構(gòu)建散裝農(nóng)產(chǎn)品電子虛擬標(biāo)簽，實(shí)現(xiàn)農(nóng)產(chǎn)品的身份標(biāo)識(shí)，并通過基于MQTT協(xié)議的數(shù)據(jù)同步與推送網(wǎng)絡(luò)構(gòu)建信息的關(guān)聯(lián)性。最終，追溯平臺(tái)利用算法檢索具有關(guān)聯(lián)性的數(shù)據(jù)并構(gòu)建完整的追溯鏈。用戶通過可視化界面即可實(shí)現(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é)、消費(fèi)者、檢驗(yàn)檢疫部門、物流配送單位等在農(nóng)產(chǎn)品銷售過程中通過多種渠道提供可追溯信息。這些信息由服務(wù)器統(tǒng)一存儲(chǔ)與處理以形成追溯鏈。追溯鏈包含了散裝農(nóng)產(chǎn)品的完整銷售路徑，以及相關(guān)環(huán)節(jié)的信息。追溯者可通過追溯鏈定位安全問題的責(zé)任方，亦可為散裝農(nóng)產(chǎn)品召回提供依據(jù)。

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

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

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

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

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

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

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

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

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

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

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

圖3 交易信息推送流程

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

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

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

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

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

Vertex {

information;

//關(guān)鍵信息

vertexList；

//鄰接點(diǎn)集合

}

DFS(vertex) {

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

vertex.information=get information from database

//從數(shù)據(jù)庫中獲取當(dāng)前頂點(diǎn)的鄰接點(diǎn)集合

nextVertexs=get next vertexs from database

//遍歷鄰接點(diǎn)集合

for nextVertex:nextVertexs

//添加鄰接點(diǎn)

vertex.vertexList.add(nextVertex)

//進(jìn)行DFS遍歷

DFS(nextVertex)

}

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

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

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

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

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

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

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

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

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

圖6 電子秤安全通信時(shí)序圖

3 系統(tǒng)測試

3.1 測試平臺(tái)搭建

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

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

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

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

3.3 消息傳輸性能測試

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

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

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

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

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

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

4 結(jié) 語

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