王波波， 鄭小虎， 申興旺， 鮑勁松， 劉天元

(1. 東華大學(xué) 機(jī)械工程學(xué)院， 上海 201620； 2. 東華大學(xué) 人工智能研究院， 上海 201620；3. 上海工業(yè)大數(shù)據(jù)與智能系統(tǒng)工程技術(shù)研究中心， 上海 201620)

在紡紗生產(chǎn)中，紗線的生產(chǎn)要經(jīng)歷原料、梳理、并條、粗紗、細(xì)紗、絡(luò)筒等諸多工序，每個(gè)環(huán)節(jié)中都可能出現(xiàn)質(zhì)量或其他問(wèn)題[1-2]。引發(fā)問(wèn)題的因素往往來(lái)自于各個(gè)工序問(wèn)題的耦合作用，其可能隱藏在前一道或者前多道工序中。只有對(duì)兩兩相鄰工序間的數(shù)據(jù)建立關(guān)聯(lián)，實(shí)現(xiàn)整個(gè)紡紗生產(chǎn)的數(shù)據(jù)互聯(lián)，才能在后面工序發(fā)現(xiàn)問(wèn)題時(shí)，核實(shí)前面工序中的問(wèn)題因素，并及時(shí)修正；在工廠實(shí)驗(yàn)室進(jìn)行前面工序的離線檢測(cè)時(shí)，發(fā)現(xiàn)問(wèn)題后也能夠立即暫停包含問(wèn)題因素的后面工序，做到及時(shí)止損。只有構(gòu)建合理的紡紗生產(chǎn)數(shù)據(jù)追溯方法，才能實(shí)現(xiàn)紡紗生產(chǎn)全過(guò)程的數(shù)據(jù)管理和數(shù)據(jù)追溯。

目前，在實(shí)際紡紗生產(chǎn)中嚴(yán)重依賴人工，且生產(chǎn)標(biāo)識(shí)體系落后、標(biāo)識(shí)聯(lián)通性差導(dǎo)致了質(zhì)量溯源困難。為此，國(guó)內(nèi)研究者們基于制造執(zhí)行系統(tǒng)(MES)和企業(yè)資源計(jì)劃系統(tǒng)(ERP)提出了多種實(shí)現(xiàn)質(zhì)量溯源的框架。萬(wàn)由順等[2]在全流程智能化紡紗研究中以MES為核心構(gòu)建了紡紗質(zhì)量追溯系統(tǒng)。崔士濤[3]采用全面質(zhì)量管理和MES，并通過(guò)設(shè)定供應(yīng)標(biāo)識(shí)牌,從絡(luò)筒工序開(kāi)始倒推實(shí)現(xiàn)了質(zhì)量溯源。薛建昌[4]也探討了基于MES和ERP等系統(tǒng)實(shí)現(xiàn)對(duì)紡紗生產(chǎn)全過(guò)程信息采集、分析和處理的框架及方案設(shè)計(jì)。紡紗生產(chǎn)數(shù)據(jù)追溯作為前人MES研究框架下的一個(gè)子系統(tǒng)或子模塊，目前更多地停留在宏觀層面，沒(méi)有進(jìn)行更深入、細(xì)致的研究。

相比于國(guó)內(nèi)，目前國(guó)外有針對(duì)實(shí)現(xiàn)數(shù)據(jù)追溯的具體相關(guān)技術(shù)的研究。Agrawal等[5]使用區(qū)塊鏈技術(shù)研究紡織品的追溯問(wèn)題，其本質(zhì)是利用哈希算法對(duì)要追溯的內(nèi)容，在保證數(shù)據(jù)不變性的前提下進(jìn)行加密。Agrawal等[6-7]還利用在紡織品上隨機(jī)打印的顆粒和二維碼進(jìn)行追溯，在提供溯源信息的同時(shí)實(shí)現(xiàn)防偽。Fernandez-Carames等[8]認(rèn)為在工業(yè)4.0中,智能標(biāo)簽和射頻識(shí)別(RFID)是較為先進(jìn)的產(chǎn)品追溯解決方案。Jalonen等[9]針對(duì)RFID標(biāo)簽易損壞和移除的問(wèn)題，提出一種替代的、不會(huì)產(chǎn)生物理干擾的視覺(jué)產(chǎn)品追溯系統(tǒng)。不管是區(qū)塊鏈、二維碼，還是RFID，都是在數(shù)據(jù)層面進(jìn)一步展開(kāi)，通過(guò)提供一個(gè)類似標(biāo)簽的內(nèi)容告訴系統(tǒng)要追溯的數(shù)據(jù)地址，本身并不包含數(shù)據(jù)。但這些都沒(méi)有觸及數(shù)據(jù)的核心，即數(shù)據(jù)的存儲(chǔ)和搜索，需要依靠MySQL、SQL Server和Elasticsearch等方法來(lái)實(shí)現(xiàn)。

MES框架下的質(zhì)量溯源研究主要基于MySQL和SQL Server等方法進(jìn)行構(gòu)建[10]，與之相比，Elasticsearch在電商平臺(tái)的訂單追溯中有較多成功應(yīng)用，可為電商平臺(tái)承擔(dān)訂單查詢和產(chǎn)品追溯任務(wù)，且隨著各行業(yè)對(duì)數(shù)據(jù)的愈加重視，紡紗生產(chǎn)數(shù)據(jù)的采集量也呈現(xiàn)不斷上升的趨勢(shì)。MySQL和SQL Server等已無(wú)法滿足構(gòu)建質(zhì)量溯源的性能要求。而Elasticsearch既可以接納非結(jié)構(gòu)化數(shù)據(jù)[11]，同時(shí)采用的倒排索引和分布式架構(gòu)可以不斷提升數(shù)據(jù)追溯性能。出于其優(yōu)越的存儲(chǔ)和搜索性能[12]，本文通過(guò)構(gòu)建相適應(yīng)的標(biāo)識(shí)體系和合理的追溯方法，以棉紡為例，研究了基于Elasticsearch的紡紗生產(chǎn)質(zhì)量溯源方法，并通過(guò)對(duì)比實(shí)驗(yàn)進(jìn)行驗(yàn)證。

1 紡紗生產(chǎn)質(zhì)量溯源問(wèn)題

目前，紡紗行業(yè)中普遍存在標(biāo)識(shí)體系落后，質(zhì)量溯源困難的問(wèn)題，示意圖如圖1所示。以棉紡并條工序?yàn)槔l機(jī)會(huì)被喂入6～8根棉條，并制成1根棉條。被喂入的多根棉條會(huì)分別用帶有不同顏色標(biāo)識(shí)的筒承裝，見(jiàn)圖1中的筒①、②。不同標(biāo)識(shí)的筒代表承裝的棉條之間的成分、質(zhì)量、性能和相關(guān)數(shù)據(jù)存在差異。不止并條，這種標(biāo)識(shí)體系在各紡紗工序中普遍使用，如細(xì)紗進(jìn)入絡(luò)筒的錠子也同樣以不同顏色區(qū)分不同批次。

圖1 紡紗生產(chǎn)質(zhì)量溯源問(wèn)題Fig.1 Realistic problems of quality tracing in spinning production

在圖1中，假設(shè)筒④的容量已滿，筒①的棉條用盡。筒④進(jìn)入粗紗工序，筒①更換為筒③。當(dāng)筒④棉條制成的粗紗出現(xiàn)質(zhì)量問(wèn)題時(shí)，并條工序加工的棉條已經(jīng)改變，此時(shí)只能依靠對(duì)應(yīng)工序以及2個(gè)工序之間負(fù)責(zé)物料搬運(yùn)的紡紗工，通過(guò)對(duì)不同顏色標(biāo)識(shí)的棉條的記憶來(lái)分析原因，容易出錯(cuò)且效率低下。

將圖1中紡紗質(zhì)量溯源的現(xiàn)實(shí)問(wèn)題進(jìn)行抽象描述，得到如圖2所示的紡紗生產(chǎn)過(guò)程時(shí)序圖，說(shuō)明在粗紗中出現(xiàn)質(zhì)量問(wèn)題的時(shí)機(jī)位于Q1這個(gè)區(qū)間內(nèi)，且和當(dāng)前的并條工序沒(méi)有重合。即使位于Q2這個(gè)重合區(qū)，如果在并條工序沒(méi)有發(fā)現(xiàn)問(wèn)題，再向梳棉工序排查時(shí)，又可能陷入非重合區(qū)。綜上，目前面臨的問(wèn)題可以總結(jié)如下：標(biāo)識(shí)和追溯體系沒(méi)有數(shù)字化、規(guī)范化；標(biāo)識(shí)沒(méi)有在相鄰工序中很好地聯(lián)通，造成可追溯性差。

圖2 紡紗生產(chǎn)過(guò)程時(shí)序圖Fig.2 Sequence diagram of spinning production process

2 紡紗生產(chǎn)數(shù)據(jù)追溯方法

2.1 紡紗數(shù)據(jù)關(guān)聯(lián)性

工序之間的關(guān)聯(lián)關(guān)系是理解和實(shí)現(xiàn)數(shù)據(jù)追溯的前提。在整個(gè)紡紗生產(chǎn)過(guò)程中，從原料、棉條、粗紗等生產(chǎn)線上被加工的半成品到最終的紗線產(chǎn)品，不僅是承載數(shù)據(jù)的客觀載體，也是串聯(lián)各個(gè)工序的紐帶。圖3示出紡紗生產(chǎn)數(shù)據(jù)關(guān)聯(lián)性示意圖。

圖3 紡紗生產(chǎn)數(shù)據(jù)關(guān)聯(lián)性示意圖Fig.3 Schematic diagram of data relevance in spinning production

由圖3可見(jiàn)，在前道工序中，假設(shè)id為i表示紗線是在當(dāng)前工序下在某個(gè)具體的設(shè)備上進(jìn)行加工，同理如果id為m(mi)表示的就是另一臺(tái)設(shè)備。id為i_1表示的則是紗線加工處于某個(gè)固定的加工狀態(tài)，當(dāng)這個(gè)固定的狀態(tài)發(fā)生改變，即某個(gè)或多個(gè)因素發(fā)生變動(dòng)，紗線承載的數(shù)據(jù)就由i_1變?yōu)榱薸_2。id為i和id為i_1、i_2的不同在于表示數(shù)據(jù)的粒度不同，同時(shí)i_1和i_2包含了id為i的信息。后道工序同理，但是像在細(xì)紗機(jī)和粗紗機(jī)上，id為p_2的粒度又可表示某個(gè)錠子，用p_2_1的粒度來(lái)表示某個(gè)錠子上紗線承載的數(shù)據(jù)。受限于數(shù)據(jù)采集的難度，本文研究和探討的數(shù)據(jù)粒度為i_1級(jí)別。

假設(shè)當(dāng)前道工序id為i_1和i_2的紗線流通到后道工序，且在后道工序中都承載了j_1、j_2、p_1和p_2的數(shù)據(jù)時(shí)，可用數(shù)據(jù)對(duì)[i_1,j_1]和[i_2,p_1]等來(lái)表示前后2道工序的關(guān)聯(lián)關(guān)系。在紡紗生產(chǎn)的任意2道工序之間都存在這樣的關(guān)聯(lián)關(guān)系，故從任意的位置追溯最終都會(huì)歸于原料數(shù)據(jù)。

2.2 追溯框架

基于Elasticsearch的紡紗生產(chǎn)數(shù)據(jù)追溯框架如圖4所示?？梢?jiàn)，紡紗生產(chǎn)要經(jīng)歷原料、清梳聯(lián)、并條、粗紗、細(xì)紗和絡(luò)筒等工序[1-2]，每個(gè)工序都會(huì)產(chǎn)生相應(yīng)的數(shù)據(jù)。又如圖2紡紗生產(chǎn)過(guò)程在時(shí)序上的特性，當(dāng)出現(xiàn)問(wèn)題時(shí)不能只檢測(cè)當(dāng)前時(shí)刻每道工序可能存在的問(wèn)題。紗線不可能再經(jīng)歷絡(luò)筒、細(xì)紗、粗紗這樣的倒序幫助分析問(wèn)題因素所在，但每個(gè)工序上記錄的數(shù)據(jù)可重構(gòu)成一個(gè)紡紗產(chǎn)品從原料到某個(gè)固定工序的生產(chǎn)過(guò)程，從而進(jìn)行輔助分析。

圖4 基于Elasticsearch的紡紗生產(chǎn)數(shù)據(jù)追溯框架Fig.4 Framework of data traceing based on Elasticsearch for spinning production

為實(shí)現(xiàn)數(shù)據(jù)追溯和重構(gòu)紡紗生產(chǎn)過(guò)程，需要在后道工序中增加相鄰前道工序的關(guān)聯(lián)數(shù)據(jù)的唯一標(biāo)識(shí)。每個(gè)關(guān)聯(lián)數(shù)據(jù)的標(biāo)識(shí)是唯一的，但關(guān)聯(lián)的數(shù)據(jù)并不唯一。如圖4虛線箭頭部分所示，在最終產(chǎn)品的記錄數(shù)據(jù)中會(huì)包含指向成包數(shù)據(jù)的標(biāo)識(shí)，成包數(shù)據(jù)中又會(huì)包含指向絡(luò)筒數(shù)據(jù)的標(biāo)識(shí)，依此類推直到指向原料的標(biāo)識(shí)。本文借助開(kāi)源的搜索引擎Elasticsearch，通過(guò)搜索內(nèi)嵌的標(biāo)識(shí)可得到從某道工序直至原料的所有相關(guān)數(shù)據(jù)，從而完成前向追溯，見(jiàn)圖4實(shí)線箭頭部分。然后將原本內(nèi)嵌的標(biāo)識(shí)使用其實(shí)際數(shù)據(jù)進(jìn)行替換，層層遞進(jìn)就能夠?qū)⑺邢嚓P(guān)數(shù)據(jù)融合為一個(gè)紡紗產(chǎn)品生產(chǎn)過(guò)程的完整數(shù)據(jù)塊，見(jiàn)圖4融合部分。

2.3 數(shù)據(jù)轉(zhuǎn)換和存儲(chǔ)

Elasticsearch完全采用JSON (JavaScript Object Notation)數(shù)據(jù)格式進(jìn)行存儲(chǔ)，所以要將原本存儲(chǔ)在SQL Server或MySQL等關(guān)系型數(shù)據(jù)庫(kù)中的原始紡紗表數(shù)據(jù)轉(zhuǎn)換為JSON格式[13]，并在轉(zhuǎn)換成的JSON數(shù)據(jù)格式中添加標(biāo)識(shí)數(shù)組，使之指向相關(guān)聯(lián)的前道工序數(shù)據(jù)以實(shí)現(xiàn)追溯。

最終帶標(biāo)識(shí)數(shù)據(jù)的存儲(chǔ)使用以下3種方案(共包括5種方法)。其中：方案1分別基于MySQL、SQL Server以數(shù)據(jù)表方法來(lái)實(shí)現(xiàn)；方案2分別基于MySQL、SQL Server以關(guān)聯(lián)表方法來(lái)實(shí)現(xiàn)；方案3是本文基于Elasticsearch的方法。

1)MySQL和SQL Server數(shù)據(jù)表方法：直接在原始數(shù)據(jù)表中添加標(biāo)識(shí)，包含的標(biāo)識(shí)有幾個(gè)則這條數(shù)據(jù)就存儲(chǔ)幾次。

2)MySQL和SQL Server關(guān)聯(lián)表方法：引入1張新的表來(lái)存儲(chǔ)當(dāng)前工序數(shù)據(jù)的唯一標(biāo)識(shí)和所關(guān)聯(lián)工序數(shù)據(jù)的多個(gè)標(biāo)識(shí)，并分別和各自的數(shù)據(jù)表以外鍵形式建立聯(lián)系。

3)Elasticsearch方法：將每個(gè)工序的原始數(shù)據(jù)轉(zhuǎn)換為JSON格式后,增加一個(gè)新的字段存儲(chǔ)前道工序的相關(guān)標(biāo)識(shí)，其值為數(shù)組形式，這樣可靈活擴(kuò)展多個(gè)標(biāo)識(shí)。

2.4 數(shù)據(jù)追溯

Elasticsearch使用一種稱為倒排索引的索引方法，適用于快速的全文搜索[14]。本文的數(shù)據(jù)追溯依托Elasticsearch來(lái)搜索數(shù)據(jù)中插入的標(biāo)識(shí)和關(guān)鍵字段信息，從而追溯到與關(guān)注的問(wèn)題數(shù)據(jù)密切相關(guān)的所有紡紗生產(chǎn)過(guò)程數(shù)據(jù)。

紡紗生產(chǎn)數(shù)據(jù)的前向追溯過(guò)程如圖5所示。假設(shè)現(xiàn)在想要在精梳的數(shù)據(jù)集合中追溯到與并條標(biāo)識(shí)為1的生產(chǎn)數(shù)據(jù)相關(guān)聯(lián)的精梳數(shù)據(jù)，則從該并條數(shù)據(jù)的數(shù)據(jù)塊中取出精梳工序的數(shù)據(jù)標(biāo)識(shí)數(shù)組，如圖中的1和2標(biāo)識(shí)，然后在精梳數(shù)據(jù)集合中分別檢索到相對(duì)應(yīng)的數(shù)據(jù)，從而完成并條到精梳這個(gè)過(guò)程的追溯。

圖5 紡紗生產(chǎn)數(shù)據(jù)前向追溯示意圖Fig.5 Schematic diagram of forward tracing of spinning production data

在確定追溯的數(shù)據(jù)起點(diǎn)和工序終點(diǎn)后，假設(shè)每個(gè)追溯過(guò)程只包含2個(gè)標(biāo)識(shí)，則從某個(gè)確定的絡(luò)筒數(shù)據(jù)追溯到并條工序的路徑如圖6所示。圖中的數(shù)字從小到大代表了追溯的先后順序。首先從該絡(luò)筒數(shù)據(jù)中取出相關(guān)的標(biāo)識(shí)數(shù)組；然后從該數(shù)組中選擇一個(gè)標(biāo)識(shí)追溯到細(xì)紗數(shù)據(jù)；此時(shí)緊接著以該細(xì)紗數(shù)據(jù)為起點(diǎn)進(jìn)行追溯，后面依此類推，并不是完成所有細(xì)紗數(shù)據(jù)的追溯，然后進(jìn)行粗紗數(shù)據(jù)的追溯。

圖6 紡紗生產(chǎn)數(shù)據(jù)追溯路徑圖Fig.6 Tracking diagram of spinning production data

在紡紗生產(chǎn)中，除自動(dòng)絡(luò)筒機(jī)上的電子清紗器在線監(jiān)測(cè)紗線中的粗節(jié)、細(xì)節(jié)、棉結(jié)和雜質(zhì)等質(zhì)量問(wèn)題外，還需要離線在工廠實(shí)驗(yàn)室檢測(cè)條干和捻度等紗線性能。此時(shí)，被抽樣檢測(cè)的同批次紗線已經(jīng)進(jìn)入后面的工序。后向追溯可追溯到同批次或包含相同問(wèn)題因素的紡紗產(chǎn)品，從精梳到并條的后向追溯示意圖如圖7所示。當(dāng)察覺(jué)到標(biāo)識(shí)為1的精梳數(shù)據(jù)有問(wèn)題時(shí)，在并條的數(shù)據(jù)集合中檢索數(shù)據(jù)塊的關(guān)聯(lián)標(biāo)識(shí)數(shù)組中包含標(biāo)識(shí)1的所有并條數(shù)據(jù)，則這些數(shù)據(jù)所代表的紡紗產(chǎn)品可能會(huì)存在相同的質(zhì)量問(wèn)題。

圖7 紡紗生產(chǎn)數(shù)據(jù)后向追溯示意圖Fig.7 Schematic diagram of backward tracing of spinning production data

假設(shè)此時(shí)以圖6的追溯路徑完成圖5從并條到精梳的數(shù)據(jù)追溯，將原本在并條數(shù)據(jù)中的標(biāo)識(shí)數(shù)組使用相應(yīng)的精梳數(shù)據(jù)數(shù)組代替，結(jié)果如圖8所示。則該融合結(jié)果形成了紡紗產(chǎn)品在并條和精梳工序上的完整數(shù)據(jù)塊，并通過(guò)對(duì)比問(wèn)題紡紗產(chǎn)品和緊鄰的正常紡紗產(chǎn)品在追溯結(jié)果融合后的差異，從而找出可能導(dǎo)致問(wèn)題的相關(guān)因素。

圖8 紡紗生產(chǎn)數(shù)據(jù)融合示意圖Fig.8 Schematic diagram of data fusion of spinning production

不同于追溯路徑，假設(shè)每個(gè)追溯過(guò)程只包含2個(gè)標(biāo)識(shí)，具體的融合路徑如圖9所示。圖中的數(shù)字從小到大代表了融合的先后順序。

圖9 紡紗生產(chǎn)數(shù)據(jù)融合路徑圖Fig.9 Road map of data fusion for spinning production

3 實(shí)驗(yàn)案例

3.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)使用的紡紗生產(chǎn)數(shù)據(jù)采集自無(wú)錫某紡紗廠的現(xiàn)場(chǎng)數(shù)據(jù)，數(shù)據(jù)的產(chǎn)生時(shí)間為2018-06-30至2019-03-30。 實(shí)驗(yàn)數(shù)據(jù)涉及的紡紗生產(chǎn)設(shè)備有JWF1211型梳棉機(jī)、JWF1312B型并條機(jī)、JWF1418型粗紗機(jī)、JWF1562型細(xì)紗機(jī)和SMARO-E型絡(luò)筒機(jī)，得到后續(xù)實(shí)驗(yàn)結(jié)果的數(shù)據(jù)和代碼見(jiàn)GitHub倉(cāng)庫(kù)地址：https://github.com/WangBaobaoLOVE/ES-for-data-provenance-of-spinning。

3.2 實(shí)驗(yàn)對(duì)比

為測(cè)試基于Elasticsearch的紡紗生產(chǎn)數(shù)據(jù)追溯方法的性能，后續(xù)通過(guò)實(shí)驗(yàn)對(duì)比了和MySQL、SQL Server在存儲(chǔ)及追溯時(shí)間上的差異，并展示了數(shù)據(jù)追溯和數(shù)據(jù)融合的結(jié)果。

3.2.1 原始數(shù)據(jù)存儲(chǔ)對(duì)比

為顯示紡紗數(shù)據(jù)在標(biāo)識(shí)添加前后其內(nèi)存的變化，表1示出原始細(xì)紗數(shù)據(jù)在不同數(shù)據(jù)量情況下各方法的內(nèi)存占用，而添加標(biāo)識(shí)后的存儲(chǔ)分析將在后文討論。

表1 原始細(xì)紗數(shù)據(jù)內(nèi)存占用表Tab.1 Memory occupancy table of original spinning data MB

表1結(jié)果使用了JWF1562型系列細(xì)紗機(jī)上采集到的92個(gè)字段的原始數(shù)據(jù)。可知，在未添加標(biāo)識(shí)前，MySQL的內(nèi)存占用要明顯小于逗號(hào)分隔值(CSV)文件、Elasticsearch和SQL Server。這里CSV文件主要是作為MySQL、Elasticsearch和SQL Server的中間轉(zhuǎn)換文件，即導(dǎo)入數(shù)據(jù)的源文件，其內(nèi)存消耗僅優(yōu)于Elasticsearch。此外，Elasticsearch的內(nèi)存消耗最大，且數(shù)據(jù)存儲(chǔ)量從1～10萬(wàn)的各情況下平均內(nèi)存消耗分別是MySQL和SQL Server的1.89和1.85倍。這主要是因?yàn)樵谠紨?shù)據(jù)存儲(chǔ)過(guò)程中會(huì)自動(dòng)建立倒排索引，從而增加了內(nèi)存消耗，但也使得數(shù)據(jù)搜索的速度達(dá)到毫秒級(jí)別。而這時(shí)MySQL中只有數(shù)據(jù)消耗內(nèi)存，并沒(méi)有建立數(shù)據(jù)索引；SQL Server則會(huì)建立正排索引，所以綜合形成表1 的情況。

3.2.2 帶標(biāo)識(shí)存儲(chǔ)對(duì)比

在本節(jié)依然如3.2.1節(jié)以同樣細(xì)紗數(shù)據(jù)為例，分析了2.2節(jié)5種方法在標(biāo)識(shí)數(shù)量變化下的內(nèi)存占用情況。注意在實(shí)際生產(chǎn)中，各工序數(shù)據(jù)中標(biāo)識(shí)數(shù)量是不統(tǒng)一的，且是較多的，這里假設(shè)標(biāo)識(shí)數(shù)量一致進(jìn)行研究分析。將1萬(wàn)條數(shù)據(jù)分別按照2.2節(jié)的5種方法添加標(biāo)識(shí)，結(jié)果如圖10所示。MySQL和SQL Server數(shù)據(jù)表的內(nèi)存消耗隨標(biāo)識(shí)數(shù)量的增加呈現(xiàn)明顯的增加趨勢(shì)，并與添加的標(biāo)識(shí)數(shù)量成線性關(guān)系，其比例系數(shù)分別為2.68和3.27。MySQL和SQL Server關(guān)聯(lián)表相較其各自的數(shù)據(jù)表方法增加趨勢(shì)明顯減小，且同樣與添加的標(biāo)識(shí)數(shù)量成線性關(guān)系，其比例系數(shù)分別為0.89和0.25。而Elasticsearch方法的存儲(chǔ)消耗基本穩(wěn)定在5.0 MB左右。其次在少于2個(gè)標(biāo)識(shí)時(shí)，Elasticsearch的內(nèi)存消耗大于SQL Server關(guān)聯(lián)表，和MySQL關(guān)聯(lián)表持平，優(yōu)于另外2種數(shù)據(jù)表方法。在大于2個(gè)、少于8個(gè)標(biāo)識(shí)時(shí)，Elasticsearch的內(nèi)存消耗僅大于SQL Server關(guān)聯(lián)表。在大于8個(gè)標(biāo)識(shí)后，Elasticsearch方法最優(yōu)。顯然，本文方法更適應(yīng)各紡紗工序數(shù)據(jù)中標(biāo)識(shí)數(shù)量不統(tǒng)一并且較多的實(shí)際應(yīng)用場(chǎng)景。

圖10 帶標(biāo)識(shí)細(xì)紗數(shù)據(jù)的占用內(nèi)存Fig.10 Memory usage of marked spinning data

3.2.3 追溯速度對(duì)比

本節(jié)研究了單過(guò)程和多過(guò)程數(shù)據(jù)追溯、標(biāo)識(shí)數(shù)量及MySQL、Elasticsearch和SQL Server這3種方法對(duì)追溯時(shí)間的影響。其中單過(guò)程是指從細(xì)紗向粗紗或粗紗向并條單過(guò)程的數(shù)據(jù)追溯，這里以細(xì)紗向粗紗為例，細(xì)紗數(shù)據(jù)來(lái)自JWF1562型細(xì)紗機(jī)，粗紗數(shù)據(jù)來(lái)自JWF1418型粗紗機(jī)。多過(guò)程是指數(shù)據(jù)追溯的過(guò)程多于1個(gè)，這里以絡(luò)筒→細(xì)紗→粗紗→并條→梳棉4個(gè)過(guò)程的追溯為例，細(xì)紗、粗紗數(shù)據(jù)同單過(guò)程，絡(luò)筒、并條、梳棉數(shù)據(jù)分別來(lái)自SMARO-E型絡(luò)筒機(jī)、JWF1312B型并條機(jī)和JWF1211型梳棉機(jī)。單過(guò)程數(shù)據(jù)追溯方法見(jiàn)圖5，而多過(guò)程追溯是由多個(gè)單過(guò)程構(gòu)建而成。

在單過(guò)程數(shù)據(jù)追溯中，隨機(jī)選擇10個(gè)細(xì)紗數(shù)據(jù)，每個(gè)數(shù)據(jù)追溯10次，然后計(jì)算其平均耗時(shí)作為該過(guò)程數(shù)據(jù)追溯時(shí)間，結(jié)果如圖11所示。3種方法追溯時(shí)間都隨標(biāo)識(shí)數(shù)量的增加而增加。但MySQL追溯時(shí)間始終遠(yuǎn)遠(yuǎn)高于Elasticsearch和SQL Server，分別是其2.2和1.9倍；而Elasticsearch和SQL Server則比較接近，且Elasticsearch略優(yōu)。

圖11 單過(guò)程數(shù)據(jù)追溯時(shí)間隨標(biāo)識(shí)添加數(shù)量的變化Fig.11 Data tracing time varies with number of labels added in single process

在多過(guò)程數(shù)據(jù)追溯中，隨機(jī)選擇10個(gè)絡(luò)筒數(shù)據(jù)，然后不斷追溯到對(duì)應(yīng)的梳棉數(shù)據(jù)，并計(jì)算其平均耗時(shí)作為該過(guò)程追溯時(shí)間，結(jié)果如圖12所示?？芍?，MySQL、Elasticsearch和SQL Server的數(shù)據(jù)追溯時(shí)間都隨標(biāo)識(shí)數(shù)量的增加而增加，且每次追溯時(shí)間由少到多依次是Elasticsearch、SQL Server和MySQL。在Excel中使用多項(xiàng)式對(duì)3條曲線進(jìn)行擬合，其最高次冪的系數(shù)分別為0.15、0.18和0.24，說(shuō)明Elasticsearch的追溯速度分別大約是MySQL和SQL Server的1.6和1.2倍。

圖12 多過(guò)程數(shù)據(jù)追溯時(shí)間隨標(biāo)識(shí)添加數(shù)量的變化Fig.12 Data tracing time varies with number of labels added in multi-process

在圖12中，追溯時(shí)間隨添加標(biāo)識(shí)數(shù)量呈現(xiàn)的增長(zhǎng)趨勢(shì)主要是實(shí)驗(yàn)設(shè)定每個(gè)加工過(guò)程數(shù)據(jù)其包含的標(biāo)識(shí)數(shù)目是相同的。由圖5可看出，這是1個(gè)單過(guò)程兩標(biāo)識(shí)的數(shù)據(jù)追溯示意圖，2個(gè)箭頭表示執(zhí)行2次搜索操作完成該追溯過(guò)程。在圖12的多過(guò)程追溯中，4個(gè)過(guò)程的搜索次數(shù)就是30。其查詢次數(shù)N與標(biāo)識(shí)數(shù)量b和追溯過(guò)程數(shù)p的關(guān)系可用下式[15]表示：

之前得到的實(shí)驗(yàn)結(jié)果可得Elasticsearch的追溯速度分別約是MySQL和SQL Server的1.6和1.2倍， 可以歸結(jié)為每次搜索操作，Elasticsearch的追溯速度是MySQL和SQL Server的1.6和1.2倍。

3.2.4 數(shù)據(jù)融合和對(duì)比分析

在完成數(shù)據(jù)追溯后，將追溯到的數(shù)據(jù)按照?qǐng)D8、9進(jìn)行數(shù)據(jù)融合，得到圖13所示為一個(gè)單過(guò)程追溯結(jié)果數(shù)據(jù)融合的實(shí)例。圖中“115”是該追溯起點(diǎn)數(shù)據(jù)的唯一標(biāo)識(shí)，“16”是產(chǎn)生該數(shù)據(jù)的紡紗設(shè)備編號(hào)，“before_record”中以數(shù)組形式記錄了前道工序相關(guān)聯(lián)的數(shù)據(jù)，如標(biāo)識(shí)為“774”和“826”的數(shù)據(jù)。

圖13 數(shù)據(jù)融合結(jié)果圖Fig.13 Chart of data fusion results

通過(guò)對(duì)比圖13所示緊鄰的正常和問(wèn)題紡紗產(chǎn)品的追溯結(jié)果融合數(shù)據(jù)塊，分析二者之間的差異，包括但不限于是某個(gè)或多個(gè)參數(shù)的變動(dòng)，某道工序少了或多了幾個(gè)標(biāo)識(shí)數(shù)據(jù)等，從而輔助分析可能的問(wèn)題產(chǎn)生因素。

3.3 結(jié)果分析

紡紗生產(chǎn)過(guò)程的數(shù)據(jù)追溯使用本文提出的基于Elasticsearch的方法和MySQL、SQL Server等方法都可以實(shí)現(xiàn)。但本文基于Elasticsearch的方法其內(nèi)存消耗對(duì)標(biāo)識(shí)數(shù)量更加具有穩(wěn)定性，在圖10所代表的實(shí)驗(yàn)中基本維持在5.0 MB左右。另外，Elasticsearch在追溯速度上均優(yōu)于另外2種方案。之所以造成3種方法在存儲(chǔ)和時(shí)間上的性能差異，原因分析如下。

1)存儲(chǔ)上：使用數(shù)據(jù)表方法不能適應(yīng)標(biāo)識(shí)數(shù)量變化的情況，會(huì)造成數(shù)據(jù)冗余和更多的內(nèi)存消耗。使用關(guān)聯(lián)表以多對(duì)多關(guān)系和相關(guān)聯(lián)的2張數(shù)據(jù)表通過(guò)外鍵建立聯(lián)系的方法會(huì)生成索引數(shù)據(jù)，同樣會(huì)消耗較多的內(nèi)存，但在JSON中，以一個(gè)字段的數(shù)組值來(lái)存儲(chǔ)標(biāo)識(shí)，可靈活擴(kuò)展標(biāo)識(shí)的數(shù)量，相當(dāng)于在數(shù)組中增加了若干數(shù)據(jù)，所以其對(duì)帶標(biāo)識(shí)數(shù)據(jù)存儲(chǔ)的穩(wěn)定性表現(xiàn)最好。

2)時(shí)間上:主要得益于Elasticsearch的倒排索引，而MySQL、SQL Server等主流關(guān)系型數(shù)據(jù)庫(kù)使用的是正排索引方式。從實(shí)驗(yàn)結(jié)果可以看出，針對(duì)紡紗數(shù)據(jù)，倒排索引的機(jī)制是適用的。

4 結(jié) 論

本文通過(guò)研究基于Elasticsearch的紡紗生產(chǎn)數(shù)據(jù)追溯方法，使得在紡紗生產(chǎn)中實(shí)現(xiàn)數(shù)字化管理和質(zhì)量管控的數(shù)據(jù)存儲(chǔ)性能和追溯速度得到提升。通過(guò)對(duì)MySQL、Elasticsearch和SQL Server實(shí)現(xiàn)的數(shù)據(jù)追溯方法進(jìn)行充分的對(duì)比實(shí)驗(yàn)發(fā)現(xiàn)，所提追溯方法在添加標(biāo)識(shí)情況下更具存儲(chǔ)穩(wěn)定性，且追溯速度分別是MySQL、SQL Server的1.6和1.2倍；使用JSON結(jié)構(gòu)可很好的擴(kuò)展追溯到的數(shù)據(jù)，形成數(shù)據(jù)融合結(jié)果，從而進(jìn)行分析比對(duì)，實(shí)現(xiàn)質(zhì)量溯源。

在實(shí)際生產(chǎn)環(huán)境中，該方法可有效解決現(xiàn)實(shí)紡紗生產(chǎn)中人工依賴嚴(yán)重、標(biāo)識(shí)體系落后和聯(lián)通性差導(dǎo)致的質(zhì)量溯源困難問(wèn)題，具有一定的應(yīng)用價(jià)值，但也要清晰意識(shí)到MySQL、SQL Server和Elasticsearch具有各自的優(yōu)勢(shì)和缺陷，在不同的實(shí)際應(yīng)用中還需要根據(jù)實(shí)際情況進(jìn)行實(shí)驗(yàn)分析。