超市托盘共用系统设计

佘红艳

（华录易云科技有限公司，四川 成都 610000）

1 引言

政府在《物流业发展中长期规划（2014-2020年）》中将开展托盘循环共用作为物流行业的发展重点，且近几年我国分别出台了《物流产业调整与振兴规划》、《商贸物流标准化专项行动计划》和《物流标准化中长期发展规划》等文件推进托盘共用系统发展。现如今我国推广托盘循环共用已经有4-5 年的时间了，多家企业和城市的试点推广都取得了很好的效果。

国家对超市托盘共用系统重视的同时，一些大型超市也开始积极进行托盘共用尝试，并取得了不错的效果。例如沃尔玛在中国尝试推行托盘共用后收货率提高了129%，货物装卸率由原来的一车货需要4小时装卸缩短至半小时，同时配送中心的作业能力得到显著的提升，货损率降低，门店响应时间也由原来的32小时缩短至20小时，门店有货率由原来的95%提高至99%。而华润在进行托盘共用后，配送周转时间降低4-6 个小时，整体效率提升了2-3 倍以上。因此，托盘共用可以为超市节省收货时间，降低货损，提高装卸效率，降低成本。

虽然一些大型超市积极进行托盘共用尝试并且取得了很好的效果，具有很大的潜力，但现在只有少数超市进行托盘共用，多数超市还只将托盘应用在仓库中，仅仅提高了仓库的周转效率，还有一些超市只将托盘应用在仓库的装卸环节中，这就导致托盘共用的效用大打折扣。因此，为了提高超市的装卸效率、降低成本、降低货损，对超市托盘共用系统进行设计具有重要意义。

本文在分析超市托盘共用现状的基础上，提出适合超市场景的托盘共用模式和流程，引入区块链技术设计超市托盘共用系统，促进超市托盘共用。

2 超市托盘共用流程设计

2.1 超市托盘共用现状

目前托盘在超市中的共用方式主要是交换模式和转移模式。交换模式是超市接收多少供应商的带货托盘，交付给供应商多少空托盘，如图1 所示。转移模式是供应商和超市均在托盘租赁公司注册账号，用来结算托盘的租金，当托盘将货物从供应商运输到超市时，托盘的使用方由供应商转移到超市，托盘租金结算也相应的从供应商转移到超市，如图2所示。

图2 转移模式

在使用过程中，交换模式对于托盘的管理相对简单，不需要在托盘租赁企业拥有账户，供应商运输货物到达超市时当场完成托盘交换，但是对于供应商而言，一方面运输车辆的利用会出现问题，因为供应商有可能对运输配送车辆有其他的安排，假设供应商将货物运输到超市后，运输车辆要去下一个供应商装货，但是由于超市交换了空托盘从而导致空托盘占用车辆的运输空间，影响接下来的运输工作。另一方面需要供应商和超市拥有一定数量的托盘进行日常的托盘交换工作，而且要求供应商到达超市卸货时当场完成托盘交换，这就要求超市本身拥有的托盘数量大于接收的带货托盘数量，在一定程度上造成超市前期投入大，流动资金减少。

转移模式虽然不会影响供应商运输车辆接下来的工作，也不需要超市拥有一定数量的托盘，减少了购买托盘资金的投入，但是在转移模式中，供应商会持续送货到超市，短时间内会造成超市内托盘数量快速增加，从而导致托盘数量的积压，来不及消化，假如积累的托盘数量超过需求量，就会增加托盘的租赁使用费用，而且造成托盘利用率降低，浪费社会资源。

2.2 超市托盘共用模式

在以超市为中心的供应链上的企业属于零售业的重要组成部分，具有零售业淡旺季供货量波动大的特点，如果自购托盘，则需要按照托盘的最大需求量进行购买，会造成资金投入大，而且在淡季托盘闲置，还会浪费存储费用。由于不是专业的托盘服务企业，对于托盘的管理维护存在很大的问题，托盘本身的维护管理成本较高，假如需要自行对托盘进行维护管理会造成企业成本增加，而且一旦管理维修不当会在使用过程中出现货损的情况。同时零售业供应链的优化方向是去库存，带托运输是实现去库存的重要基础，想要上下游带托一贯化运输，自购托盘是很难做到的。我国专业托盘服务商能够提供优质服务，可以随租随退，租赁托盘方便。因此本文的超市托盘共用系统中流转的托盘是向专业托盘租赁企业租赁的托盘，在借鉴现有托盘共用模式的基础上考虑托盘再分派对空盘进行调度，超市托盘共用模式如图3所示。

图3 超市托盘共用模式

由图3可知，在超市托盘共用系统中流转的托盘是向专业的托盘租赁企业租赁的托盘，也就是托盘租赁企业为超市托盘共用系统提供托盘池，以便于托盘在超市共用系统中更好的流转。上游供应商向专业托盘服务商租赁托盘，专业托盘服务商提供空盘给供应商，上游供应商将货物装载至托盘上形成带货托盘运输单元，将带货托盘运输至超市，超市接收带货托盘后对托盘的处理方式分为三种情况，第一种超市自身需要使用托盘，则将托盘的租赁方由上游供应商转移至超市；第二种情况是附近的节点有托盘需求，那么进行托盘再分派；第三种情况是周围节点没有需求，自身同样也不需要，则与专业托盘服务商进行还盘操作。

图4 超市托盘共用流程

2.3 超市托盘共用流程设计

由于超市托盘共用是为了实现上游供应商与超市的托盘共用，因此在托盘共用模式的基础上设计托盘共用流程，如图4 所示，相关主体包括供应商、超市、专业托盘服务商以及配送车辆，主要的流程包括：托盘租赁、发货、运输、收货和还盘。

3 超市托盘共用系统需求

3.1 系统相关主体

用户主体是指系统服务的对象，用户主体对系统的目标要求是系统需求分析、功能模块设计以及系统设计的基础。

本文的超市托盘共用系统是在前面超市托盘共用分析设计的基础上设计的超市托盘共用系统，因此本文设计的超市托盘共用系统的用户主体主要是专业托盘服务商、超市供应链上的上游供应商以及超市。在超市托盘共用系统中专业托盘服务商作为托盘供应商方提供托盘服务，上游供应商和超市是托盘的使用方。

3.2 系统需求分析

超市托盘共用系统是为了实现超市托盘共用，基于前面的分析，超市托盘共用中用户所存储的托盘数量真实性关系着托盘共用系统中托盘利用率和成本。

托盘共用系统能够高速有效的运转是基于用户的信任，只有互相信任才能简化为了实现托盘共用而增加的处理信任问题存在的复杂手续。并且为了对超市托盘共用系统中的托盘进行更好的管理，托盘需要能够被追溯。所以本小节总结出要建立一个超市托盘共用系统具有以下需求：

3.2.1 信任需求。现有的托盘共用系统中信任大都是基于运营方，大多数中心化结构的系统都是由单一的运营商进行研发与维护的，当用户需要用托盘时都将自身的信息提供给运营商，需要非常信任运营商。

3.2.2 数据分布式存储需求。由于当前的托盘共用系统大多都是基于Web应用程序开发技术与中心化存储的应用程序，中心化的存储容易被破坏，并且系统日志或者操作记录数据容易被篡改，且难以追责，数据真实性存疑。而进行数据分布式储存后每个节点都进行数据存储，单节点数据被修改没有价值，从而避免数据由一方掌控的现象。

3.2.3 系统数据真实的需求。各个用户的数据造假和错误的数据将会影响托盘共用系统中托盘的高效利用，在一定程度上增加成本。

3.2.4 完整追溯托盘信息的需求。超市托盘共用系统中，托盘直接由还盘方调度到托盘需求方，精简了还盘租盘的步骤，但是对于托盘的定位有了更高的要求，需要避免托盘丢失以及丢失后难以追责的问题，所以对于托盘信息以及托盘流转追溯十分重要。在前面的技术分析中可知，区块链是一种按时间顺序将区块互相连接形成链状结构的分布式存储账本，具有去中心化、数据不可篡改、安全可信的特点。所以为了保证超市托盘共用系统中数据的真实性，解决系统信任问题，简化超市托盘共用的手续以及更好的进行管理托盘，引入区块链技术建立超市托盘共用系统。

3.3 系统功能分析

在超市托盘共用系统中，用户需要登录系统，并且在系统中能够对托盘交易进行管理和查询，能够调度托盘和进行托盘租金结算，系统功能如图5 所示。

3.3.1 登录管理

（1）账户注册。在目前有些应用程序中，用户可以匿名以游客模式访问系统，但是由于超市托盘共用系统是仅仅为超市供应链用户服务的，是为了能够追溯托盘交易信息，保证托盘交易信息的可信和安全，因此用户必须登录注册才能够访问系统。

图5 系统功能图

（2）用户登录。用户输入注册时的密钥就可以登录系统。对用户进行验证时需要用户再次输入密钥产生的新地址与之前保存的公钥地址进行对比，结果一样即可以访问系统。

3.3.2 交易管理。在这个超市托盘共用系统中的核心就是托盘交易。其中托盘交易发起者、交易接收者、发送的托盘数量是发起托盘交易的三个必不可少的要素，通常是由发起者输入发送的托盘数量以及接收者的账户地址后，系统会对三要素进行合法性校验，主要是要校验发起者和接收者是系统的合法用户，以及校验发送者的交易托盘数量是否超过了发起者现有的托盘存储数量，通过校验后，托盘交易发起者会对交易进行数字签名，然后通过点对点网络广播到系统中。在系统中还可以对托盘交易进行查询。

（1）托盘调度。在超市托盘共用系统中各个节点之间可以进行托盘调度。某一节点A的托盘现有量少于托盘需求预测量时，节点A 发布托盘租赁请求，通过托盘共用系统验证后，通过点对点网络广播到系统各节点中，系统匹配附近节点。假设附近节点的存储托盘数量大于自身节点的托盘需求量且大于等于节点A 的托盘调度量，则附近节点进行托盘再分派，由附近节点发起托盘交易，节点A 接收交易，配送车辆提供运输服务。假设附近节点均不符合调度需求，那么系统通知托盘租赁企业发起托盘交易，由节点A接收交易，配送车辆提供托盘运输服务。

（2）钱包管理。在本系统中的托盘均来自于托盘租赁企业，需要对托盘进行租金支付，并对提供托盘调度服务的配送车辆进行服务费用支付。

4 超市托盘共用系统设计

4.1 系统架构设计

为了满足超市托盘共用系统信任、数据真实、数据可追溯以及分布式存储的需求，本文的超市托盘共用系统采用区块链技术来设计，系统总体架构如图6所示。

图6 系统总体架构

4.2 区块链层设计

区块链技术在中本聪（Satoshi nakamoto）的《比特币：一种点对点电子现金系统》一文中首次被提出，它是一种把数据区块按时间顺序形成链状结构的去中心化共享总账，其中应用共识机制和P2P来确保系统的去中心化，应用密码学来保证数据的不可篡改和造假[1]。

4.2.1 数据区块的形成。区块就是链式存储结构中的数据元素，数据区块的结构包括区块头和区块体，数据区块对应类应包含相关信息，并能够实现创建新区块、添加有效数据、校验数据、校验Merkle 根等功能。在超市托盘共用系统中，数据区块形成的过程如图7所示。

图7 区块链数据区块形成过程图

由图7 可知，当前区块的前一区块是父块，一个区块包括区块头和区块体，区块头记录区块的元信息，包含当前区块的版本号、时间戳、随机数、Merkle等。其中前一个区块地址是父块区块头数据通过hash算法生成的hash值。区块体记录一定时间内所发生的交易数据，区块体中通过hash 算法把区块中的交易信息进行加密，通过加密后的交易信息被压缩成一串数字和字母组成的散列字符串。一个区块可以有多个交易信息，通过hash 算法对交易信息加密，不断进行hash计算，最后生成Merkle存入区块头中。

4.2.2 共识机制。所谓的共识必须遵循安全性和活跃性两个属性。安全性是指保证每个节点相同的输入序列和相同的输出，即一个节点接收到一笔交易，其他所有节点的状态变化是一模一样的。活跃性是指每一个节点都必须接收到所有提交的交易。而共识机制是区块链的核心模块，可以保证在没有中心主体进行控制的情况下，系统中的各个参与方能够遵循相同的规则，实现数据分布式记账的一致性。即共识机制是各节点在记账权归属问题上达成共识的机制。本系统是为超市供应链上的用户服务的，在此应用Fabric网络进行系统区块链网络构建，Fabric区块链网络具有支持插拔式共识机制的特点。在多节点情况下在Fabric 中达成共识可以使用实用拜占庭容错算法（FBFT）。FBFT 降低了拜占庭协议的运行的复杂度，使其能应用在分布式系统中。作为一种状态机复制的FBFT 被要求共同维护的是一个状态，所有节点的行动是一致的。PBFT 在能够保证活性和安全性的前提下提供了(n-1)/3 的容错性[2]。PFFT算法的运作步骤为：

（1）选一个节点作为主节点；

（2）用户端向主节点发起请求；

（3）主节点将客户端的请求进行排序生成序号，将用户端的请求和序号通过广播发送给其他节点；

（4）所有节点执行请求后将结果发回用户端；

（5）用户端F+1个不同节点发回来的结果是最终的结果，步骤如图8 所示，图中×掉的节点是错误节点或者内奸节点。

图8 FBFT

假设超市托盘共用系统中具有N-1 个从节点，一个主节点O，从节点根据加入的顺序排序为1,2,...,N-1。根据FBFT，最多能容忍的“内奸节点”或者“错误节点”为(N-1)/3 个。在不同的用户在客户端向主节点发起托盘交易、托盘调度、租金转账和托盘查询等请求时，主节点接收客户端的请求，并且对请求进行排序分配序列号，主节点将客户端的请求序列号广播给从节点，从节点收到主节点分配的序列并且节点间相互确认消息，如果有一个节点是内奸节点，则不会跟其他节点进行相互确认，之后各个节点对视图内的请求和序列号，进行Commit 消息广播。最后各个节点执行请求并将结果回执给客户端，客户端在一段时间内收到F+1个回执消息就可以将结果作为最终结果。

4.2.3 智能合约。智能合约最早由科学家Nick Szabo 提出，其定义的智能合约为一种自动执行的协议[3]。智能合约是部署在区块链上的一段链码，具体根据应用场景实现业务逻辑，在Fabric 中，智能合约实现的方式是链码（Chaincode），在超市托盘共用系统中智能合约主要是为了实现托盘交易和托盘信息查询功能，并且定义相关数据结构，方便数据结构的序列化以及反序列化。

为了实现超市托盘共用信息查询，对托盘的数据结构进行了定义，托盘数据结构体定义的数据为：托盘的ID、托盘的租赁价格以及托盘所有者，具体如图9所示。

图9 托盘数据结构

4.3 系统业务逻辑

本文的系统是基于Fabric进行设计的，在超市托盘共用系统中要实现托盘交易、托盘信息查询以及托盘调度等需求的关键是智能合约，而智能合约是根据实际应用场景的业务逻辑来开发的，所以超市托盘共用系统中业务逻辑的设计是实现超市托盘共用系统的基础。

4.3.1 登录/注册业务逻辑。为了保证超市托盘共用系统用户互相信任，超市托盘共用系统只有与超市有配送业务往来的供应商以及超市自身的配送中心进入。并且为保证托盘共用结果可追溯，本系统只有供应商和超市配送中心注册后才能进入。每个用户在注册时会产生唯一的私钥、公钥以及地址，私钥主要是用来对发起的交易进行数字签名，公钥是用来对信息进行加密，区块链地址用来对交易记录进行追溯。公钥和区块链地址是通过私钥计算得来的，但是公钥和区块链不能反推得到私钥，即区块链使用的是非对称加密技术，区块链地址、公钥与私钥都是唯一的。

每个账户的登录/注册流程如图10所示。

图10 登录注册逻辑

4.3.2 交易逻辑。超市托盘共用系统的核心是托盘交易，超市托盘交易中主要是指的带货托盘和空托盘在两个不同节点之间的移动。带货托盘的交易是由节点根据运输货物的需求将托盘交易给接收货物即接收托盘的节点。具体的的交易流程如图11 所示。

由图11 可知，带货托盘交易涉及的用户节点主要为供应商节点、配送车辆和超市，带货托盘由上游供应商发往超市，所以由供应商发起托盘交易，超市托盘共用系统判断是否符合交易条件即供应商是否具有足够托盘数量进行托盘交易，超市接收交易，配送车辆根据交易提供服务，最后由超市托盘共用系统确认交易。

图11 带货托盘交易逻辑

由图12 可知，当超市节点和供应商节点有托盘租赁需求时，由超市、供应商节点发布租赁需求，超市托盘共用系统判断就近满足托盘需求的节点，由就近能满足托盘租赁需求的节点发起托盘交易，超市托盘共用系统验证交易以及确认交易，配送车辆根据交易提供服务。

由图13 可知，当供应商或超市节点有还盘需求时，有两种情况，一是附近的系统用户有托盘需求且供应商或超市节点能满足附近用户托盘需求，由超市或供应商发起托盘交易，附近用户接收交易，超市托盘共用系统验证和确认交易，配送车辆根据交易提供服务。二是附近用户没有托盘需求或者不满足附近用户的托盘需求，就只能将托盘归还至托盘租赁企业，由托盘租赁企业接收交易。

4.3.3 调度逻辑。在超市托盘共用系统中，要形成托盘的循环共用，托盘调度功能必不可少。调度逻辑如图14所示。

由图14 可知，超市托盘共用系统涉及的主体主要是托盘需求方、附近节点以及专业托盘服务商，满足托盘需求方需求的用户可能是附近节点也可能是专业托盘服务商，根据就近原则选择满足托盘需求的用户发起托盘交易，超市托盘共用系统验证交易，托盘需求方接收交易，配送车辆提供服务，最终确认交易完成调度。

图12 空盘交易逻辑1

图13 空盘交易逻辑2

4.4 部分功能实现

本节基于超市托盘共用系统总体架构、系统需求以及业务逻辑设计，对超市托盘共用系统的部分原型进行开发，主要分为两部分，一是超级账本Fabric搭建，二是web客户端开发。

图14 调度逻辑

4.4.1 链码开发。在Fabric 中，智能合约就是链码，链码在Fabric中分为系统链码和用户链码，而根据现实场景定义业务逻辑的链码通常指的是用户链码。链码是用来访问超级账本的方法，是用来实现规定接口的代码。应用层通过调用链码来访问和管理账本，链码与链码在有权限的情况下也可以互相调用。由于GO是Fabric的官方语言，所以本文选用GO语言进行链码开发，本文链码主要部分如图15所示。

图15 链码Main结构

4.4.2 部分功能。由于电科信链智能合约底层架构是Fabric，并且使用的共识机制是PBFT，与本文的Fabric 底层环境以及调用的PBFT 共识机制一致，由于云环境中搭建的Fabric 环境不能直观地展示托盘交易以及托盘查询功能，所以本文将链码部署在电科信链智能合约快速开发平台上进行实现。

（1）带货托盘交易实现。将根据带货托盘的交易逻辑开发且定义了托盘的数据结构的链码部署到平台上，可以实现信息查询、托盘交易功能。根据托盘交易逻辑，在超市托盘共用系统中是将托盘作为交易Token，直接进行用户间的托盘交易，在带货托盘交易流程中，托盘是由供应商用户交易给超市，初始化两个用户owner1 和owner2，带货托盘交易实现结果如图16所示。

图16 托盘交易实现

由图16可知，通过invoke函数调用链码，托盘实现了由owner1 到owner2 之间的流转，实现了一次交易过程，即实现了ID 为“tray1”的托盘由owner1 交易到owner2。

（2）交易信息查询。在系统通过调用链码实现托盘交易后，系统会产生交易日志，也就是交易记录，能够对交易信息进行查询，实现系统查询功能中的交易查询功能，查询结果如图17、图18所示。

图17 托盘交易信息

图17 可以查询到进行过的所有托盘交易信息，图18 能够查询具体的托盘交易信息，包括交易Hash、交易时间、交易结果以及所在区块的具体信息，其中交易hash 是通过对交易信息进行加密计算得到的hash值，交易时间是交易发生的时间。

图18 托盘交易详细信息

（3）托盘溯源。在进行托盘交易后，可以通过调用链码，查询托盘的去向，如图19所示。

图19 托盘去向查询

在图19 中，通过query 函数调用链码，可以得到ID为tray1的托盘，托盘流转从owner1流向owner2，实现对托盘流向查询，即能够对托盘进行溯源。

（4）托盘信息查询。链码中定义托盘数据结构，链码部署后，初始化数据，可以通过query 函数调用链码，进行托盘信息查询，查询结果如图20所示。

由图20 可以看出定义的托盘信息，包括托盘的ID、托盘租赁价格以及托盘的所有者，实现托盘信息查询功能。

（5）用户账户信息查询。在链码中定义托盘所有者的数据结构，通过query 函数调用链码，对Owner1用户进行查询，能够实现对用户账户信息的查询功能，如图21所示。

由图21可知，系统实现了用户账户信息查询，能够查询到owner1的id，及对应的现实用户姓名，并能够查询用户账户中的托盘，实现账户用户信息查询功能。

图20 托盘信息查询

5 总结

图21 用户账户信息查询

本文在分析超市托盘共用现状的基础上，对超市托盘共用模式和共用流程进行分析，引入区块链技术，根据用户需求对超市托盘共用系统总体架构进行了设计，对系统功能进行了分析，并根据超市托盘共用系统的共用方案设计了系统实现的关键基础业务逻辑。最后通过搭建Fabric网络以及利用GO语言开发和部署符合业务逻辑和贴合超市托盘共用情景的链码，进而实现超市托盘共用系统的部分功能。