超市托盤共用系統設計

佘紅艷

（華錄易云科技有限公司，四川 成都 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語言開發和部署符合業務邏輯和貼合超市托盤共用情景的鏈碼，進而實現超市托盤共用系統的部分功能。