散装农产品追溯的关键技术研究与实现

丁 磊 陈劲鸿 李 峥 邓杰航

(广东工业大学计算机学院 广东 广州 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协议等关键技术为核心，通过信息的采集、编码与传输解决上述问题。经测试，系统能实现数据的实时采集与追溯链条的构建，可满足对散装农产品进行信息追溯的需求。