散裝農產品追溯的關鍵技術研究與實現

丁 磊 陳勁鴻 李 崢 鄧杰航

(廣東工業大學計算機學院 廣東 廣州 510006)

0 引 言

近年來農產品安全問題日益顯現。當出現農產品安全問題的時候，監督機構、供應鏈各環節、消費者能及時獲取農產品信息并迅速定位產生安全問題的責任方，對于協助解決農產品安全問題有著重要的作用和意義，農產品追溯在這樣的背景下應運而生。

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

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

1 散裝農產品追溯模型

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

圖1 散裝農產品追溯模型

2 系統總體設計與關鍵技術

2.1 系統總體設計

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

圖2 系統總體設計

2.2 基于虛擬標簽的追溯鏈構建

虛擬標簽包含農產品交易過程中產生的關鍵信息，通過信息編碼與推送機制，不同的虛擬標簽形成關聯，為追溯鏈構建算法的實現提供基礎。

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

表1 農產品信息關鍵編碼

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

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

圖3 交易信息推送流程

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

(a) 線性結構

(b) 樹狀結構圖4 追溯鏈基本結構

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

算法1構建農產品去向追溯連

Vertex {

information;

//關鍵信息

vertexList；

//鄰接點集合

}

DFS(vertex) {

//從數據庫中獲取當前頂點關鍵信息

vertex.information=get information from database

//從數據庫中獲取當前頂點的鄰接點集合

nextVertexs=get next vertexs from database

//遍歷鄰接點集合

for nextVertex:nextVertexs

//添加鄰接點

vertex.vertexList.add(nextVertex)

//進行DFS遍歷

DFS(nextVertex)

}

2.3 多協議通信框架

追溯系統中Android終端需要與具有不同通信方式的外圍設備進行數據交互。為了降低應用程序的復雜性，防止通信阻塞。利用模塊化、面向對象和多線程的思想，設計一種基于Service組件的多協議通信框架，其結構如圖5所示。

圖5 多協議通信框架

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

2.4 可靠通信實現

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

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

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

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

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

3 系統測試

3.1 測試平臺搭建

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

3.2 并發連接性能測試

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

表2 并發連接測試結果

3.3 消息傳輸性能測試

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

表3 消息傳輸性能測試結果

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

3.4 追溯結果有效呈現測試

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

圖7 追溯鏈構建結果

4 結 語

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