基于大數(shù)據(jù)的分揀設(shè)備智能分析系統(tǒng)的設(shè)計與研究

龔亞彬

關(guān)鍵詞：自動分揀；數(shù)據(jù)采集；大數(shù)據(jù)；HBase/Hive；智能分析

0 引言

隨著物流行業(yè)的發(fā)展和物聯(lián)網(wǎng)的普及，全國現(xiàn)代物流中心為了提高物流效率和服務(wù)質(zhì)量，已逐步實現(xiàn)了信息化，對高性能物流分揀設(shè)備的需求在日益增長， 相應(yīng)的各類智能自動化分揀設(shè)備也在不斷地涌現(xiàn)。在眾多的分揀設(shè)備中，小件交叉帶分揀設(shè)備、大件擺臂擺輪分揀設(shè)備、模組帶分揀機轉(zhuǎn)換機和AGV等產(chǎn)品得到了業(yè)界廣泛的應(yīng)用與認可。

包裹分揀模式由傳統(tǒng)的人工分揀逐步演變?yōu)樽詣踊謷瑢崿F(xiàn)了對分揀全過程、全環(huán)節(jié)的信息跟蹤與監(jiān)控，提升了作業(yè)自動化水平，使得物流行業(yè)的整體運營效率大幅提升，運營成本大大降低。

由于包裹的多樣性、供件人員操作不規(guī)范、設(shè)備元器件精密度要求高和分揀環(huán)境復(fù)雜等因素，給設(shè)備的穩(wěn)定性和分揀的準(zhǔn)確性造成了諸多困擾。分揀過程記錄、設(shè)備PLC通信和光電信號傳感器產(chǎn)生了海量數(shù)據(jù)，尤其在“618”“雙11”“雙12”“節(jié)假日”等高峰期間呈指數(shù)級增長。面對其龐大、多源、異構(gòu)等特點，如何保證數(shù)據(jù)的快速接收與存儲，并將分析結(jié)果反饋給相關(guān)業(yè)務(wù)部門，如何進一步確保設(shè)備運行的高穩(wěn)定性和分揀結(jié)果的99.99%高準(zhǔn)確率成為一大難題。

本文以Ginfon交叉帶分揀設(shè)備為例，在分析分揀過程數(shù)據(jù)的特點和大數(shù)據(jù)技術(shù)的基礎(chǔ)上，基于HBase 大數(shù)據(jù)庫、Hive數(shù)據(jù)倉庫和Spark計算模型進行整體架構(gòu)設(shè)計和針對性分析，最終實現(xiàn)了對海量多源、異構(gòu)和分布式分揀大數(shù)據(jù)的高效快速處理。對各項指標(biāo)進行建模，可對分揀過程和設(shè)備元器件進行全方位智能診斷和智能決策，通過模型計算與評估挖掘潛在問題與規(guī)律，有效改善設(shè)備的分揀流程，促進設(shè)備工藝的優(yōu)化，從而提升產(chǎn)品的市場競爭力。

1 相關(guān)技術(shù)簡介

1.1 交叉帶分揀設(shè)備的特點

交叉帶分揀機由主驅(qū)動帶式輸送機和眾多載有小型帶式輸送機的臺車組成。環(huán)線小車與主驅(qū)動帶式輸送機連接在一起，包裹經(jīng)供件臺掃碼后由PLC預(yù)約小車和裝載。小車采用伺服直流驅(qū)動技術(shù)，毫秒級瞬時啟動，確保貨物能上正確的小車且位置居中。在控制系統(tǒng)的控制下，包裹隨小車與主驅(qū)動帶式輸送機一起運行。當(dāng)運行到目標(biāo)位置時，小車皮帶啟動，將待分揀物品推送至分揀格口，完成包裹的分揀任務(wù)[1]。

1.2 HBase/Hive

HBase建立在HDFS之上，提供了高可靠性的列存儲和實時讀寫的大數(shù)據(jù)庫系統(tǒng)，介于關(guān)系型數(shù)據(jù)庫和NoSql之間，通過主鍵和主鍵的Range來檢索數(shù)據(jù)，支持單行事務(wù)，主要用來存儲非結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)。

Hive是基于Hadoop的數(shù)據(jù)倉庫工具，可以將結(jié)構(gòu)化數(shù)據(jù)文件映射為數(shù)據(jù)庫表，是一種類SQL的引擎，可以將SQL轉(zhuǎn)化為MapReduce任務(wù)運行，十分適合數(shù)據(jù)倉庫的統(tǒng)計分析[2]。

1.3 Spark

Apache Spark 是為大規(guī)模數(shù)據(jù)處理而設(shè)計的快速通用計算引擎，任務(wù)中間輸出結(jié)果保存在內(nèi)存中，由于不需要讀寫HDFS，Spark能更好地適用于數(shù)據(jù)挖掘與機器學(xué)習(xí)等需要迭代的MapReduce的算法。Spark 啟用了內(nèi)存分布數(shù)據(jù)集，除了能夠提供交互式查詢外，還可以優(yōu)化迭代工作負載。在內(nèi)存計算模式下，Spark比Hadoop快100倍以上。Spark提供了大量的庫，開發(fā)者可以在同一個應(yīng)用程序中無縫組合使用這些庫[3]。

2 系統(tǒng)架構(gòu)設(shè)計

智能數(shù)據(jù)分析系統(tǒng)（Intelligence Data Analysis Sys?tem，IAS） 采用客戶端分布式采集，云端集中處理模式。云端服務(wù)器與全國各個分揀中心交叉帶分揀設(shè)備WCS實時連接，接收PLC控制器的指令。通過對分揀機WCS系統(tǒng)的日志目錄監(jiān)控，定時和實時采集正常日志、錯誤日志和系統(tǒng)信息，從各個分揀客戶端傳輸至系統(tǒng)云端。服務(wù)端接收日志數(shù)據(jù)后保存至相關(guān)目錄，通過Hadoop任務(wù)調(diào)度對相應(yīng)的日志內(nèi)容進行數(shù)據(jù)清洗、格式轉(zhuǎn)換及規(guī)范處理，實現(xiàn)了包裹信息檢索、分揀過程分析、設(shè)備元器件分析、錯分分析、設(shè)備狀況感知與分析、運營與監(jiān)管、模型預(yù)警與預(yù)判、設(shè)備畫像，同時給出分析報告。系統(tǒng)整體流程如圖1所示。

系統(tǒng)整體架構(gòu)（如圖2）包括數(shù)據(jù)采集層、清洗與存儲層、數(shù)據(jù)計算、數(shù)據(jù)挖掘、任務(wù)調(diào)度、數(shù)據(jù)倉庫和網(wǎng)關(guān)服務(wù)等。

2.1 數(shù)據(jù)采集層

數(shù)據(jù)源由設(shè)備參數(shù)數(shù)據(jù)和WCS分揀日志記錄構(gòu)成。設(shè)備參數(shù)數(shù)據(jù)包含交叉帶的層數(shù)、小車數(shù)、供件臺數(shù)、格口數(shù)、灰度儀數(shù)、小車組/格口組/急停按鈕數(shù)和分揀方案數(shù)據(jù)等。分揀日志記錄以文本文件格式保存，具體包括：分揀流程記錄、PLC通信報文數(shù)據(jù)和光電傳感器信號數(shù)據(jù)。數(shù)據(jù)采集層通過異步Socket 由客戶端發(fā)給服務(wù)器，服務(wù)端接收后進行處理，處理完畢后返回給客戶端相應(yīng)指令。服務(wù)端將接收到的日志文件根據(jù)設(shè)備名稱保存在相應(yīng)的目錄中，數(shù)據(jù)存儲在HBase 和MySQL。服務(wù)端大數(shù)據(jù)環(huán)境Hadoop+Spark采用1主2從模式，可支持橫向擴容[4]。

2.2 數(shù)據(jù)清洗與存儲層

由于客戶多樣，不同的WCS客戶端分揀記錄日志格式存在差異、數(shù)據(jù)的不完整和未統(tǒng)一標(biāo)準(zhǔn)化，服務(wù)端將采集到的日志文件進行清洗處理形成規(guī)范，清洗的內(nèi)容有：字段格式轉(zhuǎn)換、缺失值、重復(fù)值、錯誤值和異常值等。分揀過程需要按不同階段設(shè)定不同的INFO 類別（如表1），不同階段的異常設(shè)定不同的ERR類別（如表2），控制設(shè)備元器件的PLC報文按協(xié)議編號進行區(qū)分（如表3）。

清洗后的INFO類別、ERR類別和PLC報文數(shù)據(jù)存儲在大數(shù)據(jù)庫HBase表中，通過數(shù)據(jù)倉庫Hive統(tǒng)一調(diào)用。

2.3 數(shù)據(jù)分析

系統(tǒng)通過采集交叉帶設(shè)備的分揀日志，做針對性分析，集設(shè)備分揀效率評估、分揀流程追溯、供包臺供件效率、小車落格率分析、集包效率、可疑流程診斷、設(shè)備元器件分析和錯分分析等于一體，挖掘規(guī)律，控制各項指標(biāo)在有效的閾值內(nèi)，同時實現(xiàn)預(yù)警。

3 功能模塊設(shè)計與實現(xiàn)

系統(tǒng)主要包括分揀統(tǒng)計、集包效率分析、分揀過程追溯、相鄰小車落格分析、錯分分析和重量體積比分析等功能，具體功能模塊如圖3所示。

3.1 分揀統(tǒng)計與集包效率分析

通過Spark Core讀取清洗后的標(biāo)準(zhǔn)日志文件，針對不同場地可進行如下分析：

1） 供件臺分揀統(tǒng)計：根據(jù)各個供件臺分揀量評判供件效率情況。

2） 小車分揀統(tǒng)計：根據(jù)小車分揀量評判可疑小車情況。

3） 集包效率分析：根據(jù)人員鎖格、解鎖時間差評估集包操作人員的熟練度。

4） 根據(jù)設(shè)備元器件運行過程的關(guān)鍵評判指標(biāo)提供相關(guān)預(yù)警、提高主動式維修響應(yīng)速度。具體包括：迷路預(yù)警、灰度儀及光電的故障預(yù)警、環(huán)線碳刷壽命預(yù)警、48V電源報警和小車故障檢測等。提供的預(yù)警閾值分為供件臺供件量閾值、小車分揀量閾值和集包時長閾值等。

3.2 分揀過程追溯

根據(jù)不同設(shè)備進行不同條件的組合查詢，如條碼、格口/小車/供件臺號、報文類型和日志消息類型等，供分揀分析使用。

1） 分揀過程追溯：通過JDBC調(diào)用Hive Sql詳細跟蹤包裹分揀過程中供件臺、小車、格口的狀態(tài)詳情及系統(tǒng)錯誤信息，并可關(guān)聯(lián)查詢供件臺上一個包裹、下一個包裹，相鄰小車上一個包裹、下一個包裹分揀情況。

2） 分揀調(diào)查：根據(jù)條碼、錯分格口、異?？卺槍π苑治鲥e分原因，并實現(xiàn)關(guān)聯(lián)查詢分析。

3） 針對分揀的流程，統(tǒng)計分析迷路占比及趨勢，可直觀地評判糾偏儀、灰度儀的工作運行正確率及穩(wěn)定性。

3.3 相鄰小車落格分析

環(huán)線小車通用截距60cm，格口寬度75cm，在2m/s的速度運行時，每5個小車在時間分配上為一組連貫性控制。當(dāng)出現(xiàn)相鄰小車落相鄰格口時，可評估采用動態(tài)變換格口擋板角度來增加包裹的落格準(zhǔn)確性。此時需要統(tǒng)計分析交叉帶項目場地1s內(nèi)、500ms內(nèi)相鄰小車落相鄰格口情況，結(jié)果供設(shè)計部門對滑槽工藝改進及相關(guān)決策。相鄰小車落相鄰格口模型如圖4所示。

由表4可得出，小車間隔越大，相鄰格口落格比例逐漸降低，各場地占比情況整體類似。貨物相鄰、貨物間隔1個小車、貨物間隔2個小車落相鄰格口導(dǎo)致格口變換的占比約為1.23%。而通過擺臂動作測試，只有貨物相鄰、貨物間隔1個小車才可能導(dǎo)致擺臂來不及動作，占比為0.85%，此種情況，完全可以通過程序禁止第二件貨物在此區(qū)域落格，而去另外一個區(qū)域落格，卻對整體分揀沒有影響。

3.4 錯分分析

根據(jù)條碼、錯分格口和回流口可進行批量錯分原因分析與錯分關(guān)聯(lián)查詢。

包裹是否落入正確格口，和上車的位置、糾偏的位置、環(huán)線速度、包裹外觀、材質(zhì)重量等諸多因素有關(guān)聯(lián)，通過大數(shù)據(jù)相關(guān)性分析得出包裹的重量和體積是直接的可量化指標(biāo)。通過分析得出整體包裹的重量體積比分布情況，步驟如下：

1） 使用Spark SQL讀取錯分條碼的重量（kg）、長寬高（cm）數(shù)據(jù)。

2） 通過Stream.groupBy（）按包裹密度（重量/體積）級別分類，計算其占比[5]。

由圖5所示：包裹密度主要分布在0.02～0.8kg/立方分米以內(nèi)，總占比95.18%。根據(jù)上述包裹密度結(jié)果，在確定落格時PLC可精確實現(xiàn)對小車的毫秒級控制，減少錯分機會。

4 結(jié)束語

智能數(shù)據(jù)分析系統(tǒng)作為一個物流分揀的大數(shù)據(jù)分析平臺，是智能分揀設(shè)備、物聯(lián)網(wǎng)和大數(shù)據(jù)相結(jié)合的典型應(yīng)用，支持和兼容各類分揀設(shè)備的高并發(fā)場景，易于擴展，滿足了快速、高效處理和專項分析有效數(shù)據(jù)的硬性要求。實現(xiàn)了數(shù)據(jù)來源于設(shè)備，分析結(jié)果逆向促進對分揀設(shè)備的有效智能管理，為提高設(shè)備的穩(wěn)定性、準(zhǔn)確性和產(chǎn)品的進一步的迭代奠定了真實的應(yīng)用基礎(chǔ)，大大提升了產(chǎn)品的市場競爭力。