基于Elasticsearch的紡紗生產數據追溯方法

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

(1. 東華大學 機械工程學院， 上海 201620； 2. 東華大學 人工智能研究院， 上海 201620；3. 上海工業大數據與智能系統工程技術研究中心， 上海 201620)

在紡紗生產中，紗線的生產要經歷原料、梳理、并條、粗紗、細紗、絡筒等諸多工序，每個環節中都可能出現質量或其他問題[1-2]。引發問題的因素往往來自于各個工序問題的耦合作用，其可能隱藏在前一道或者前多道工序中。只有對兩兩相鄰工序間的數據建立關聯，實現整個紡紗生產的數據互聯，才能在后面工序發現問題時，核實前面工序中的問題因素，并及時修正；在工廠實驗室進行前面工序的離線檢測時，發現問題后也能夠立即暫停包含問題因素的后面工序，做到及時止損。只有構建合理的紡紗生產數據追溯方法，才能實現紡紗生產全過程的數據管理和數據追溯。

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

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

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

1 紡紗生產質量溯源問題

目前，紡紗行業中普遍存在標識體系落后，質量溯源困難的問題，示意圖如圖1所示。以棉紡并條工序為例，并條機會被喂入6～8根棉條，并制成1根棉條。被喂入的多根棉條會分別用帶有不同顏色標識的筒承裝，見圖1中的筒①、②。不同標識的筒代表承裝的棉條之間的成分、質量、性能和相關數據存在差異。不止并條，這種標識體系在各紡紗工序中普遍使用，如細紗進入絡筒的錠子也同樣以不同顏色區分不同批次。

圖1 紡紗生產質量溯源問題Fig.1 Realistic problems of quality tracing in spinning production

在圖1中，假設筒④的容量已滿，筒①的棉條用盡。筒④進入粗紗工序，筒①更換為筒③。當筒④棉條制成的粗紗出現質量問題時，并條工序加工的棉條已經改變，此時只能依靠對應工序以及2個工序之間負責物料搬運的紡紗工，通過對不同顏色標識的棉條的記憶來分析原因，容易出錯且效率低下。

將圖1中紡紗質量溯源的現實問題進行抽象描述，得到如圖2所示的紡紗生產過程時序圖，說明在粗紗中出現質量問題的時機位于Q1這個區間內，且和當前的并條工序沒有重合。即使位于Q2這個重合區，如果在并條工序沒有發現問題，再向梳棉工序排查時，又可能陷入非重合區。綜上，目前面臨的問題可以總結如下：標識和追溯體系沒有數字化、規范化；標識沒有在相鄰工序中很好地聯通，造成可追溯性差。

圖2 紡紗生產過程時序圖Fig.2 Sequence diagram of spinning production process

2 紡紗生產數據追溯方法

2.1 紡紗數據關聯性

工序之間的關聯關系是理解和實現數據追溯的前提。在整個紡紗生產過程中，從原料、棉條、粗紗等生產線上被加工的半成品到最終的紗線產品，不僅是承載數據的客觀載體，也是串聯各個工序的紐帶。圖3示出紡紗生產數據關聯性示意圖。

圖3 紡紗生產數據關聯性示意圖Fig.3 Schematic diagram of data relevance in spinning production

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

假設當前道工序id為i_1和i_2的紗線流通到后道工序，且在后道工序中都承載了j_1、j_2、p_1和p_2的數據時，可用數據對[i_1,j_1]和[i_2,p_1]等來表示前后2道工序的關聯關系。在紡紗生產的任意2道工序之間都存在這樣的關聯關系，故從任意的位置追溯最終都會歸于原料數據。

2.2 追溯框架

基于Elasticsearch的紡紗生產數據追溯框架如圖4所示。可見，紡紗生產要經歷原料、清梳聯、并條、粗紗、細紗和絡筒等工序[1-2]，每個工序都會產生相應的數據。又如圖2紡紗生產過程在時序上的特性，當出現問題時不能只檢測當前時刻每道工序可能存在的問題。紗線不可能再經歷絡筒、細紗、粗紗這樣的倒序幫助分析問題因素所在，但每個工序上記錄的數據可重構成一個紡紗產品從原料到某個固定工序的生產過程，從而進行輔助分析。

圖4 基于Elasticsearch的紡紗生產數據追溯框架Fig.4 Framework of data traceing based on Elasticsearch for spinning production

為實現數據追溯和重構紡紗生產過程，需要在后道工序中增加相鄰前道工序的關聯數據的唯一標識。每個關聯數據的標識是唯一的，但關聯的數據并不唯一。如圖4虛線箭頭部分所示，在最終產品的記錄數據中會包含指向成包數據的標識，成包數據中又會包含指向絡筒數據的標識，依此類推直到指向原料的標識。本文借助開源的搜索引擎Elasticsearch，通過搜索內嵌的標識可得到從某道工序直至原料的所有相關數據，從而完成前向追溯，見圖4實線箭頭部分。然后將原本內嵌的標識使用其實際數據進行替換，層層遞進就能夠將所有相關數據融合為一個紡紗產品生產過程的完整數據塊，見圖4融合部分。

2.3 數據轉換和存儲

Elasticsearch完全采用JSON (JavaScript Object Notation)數據格式進行存儲，所以要將原本存儲在SQL Server或MySQL等關系型數據庫中的原始紡紗表數據轉換為JSON格式[13]，并在轉換成的JSON數據格式中添加標識數組，使之指向相關聯的前道工序數據以實現追溯。

最終帶標識數據的存儲使用以下3種方案(共包括5種方法)。其中：方案1分別基于MySQL、SQL Server以數據表方法來實現；方案2分別基于MySQL、SQL Server以關聯表方法來實現；方案3是本文基于Elasticsearch的方法。

1)MySQL和SQL Server數據表方法：直接在原始數據表中添加標識，包含的標識有幾個則這條數據就存儲幾次。

2)MySQL和SQL Server關聯表方法：引入1張新的表來存儲當前工序數據的唯一標識和所關聯工序數據的多個標識，并分別和各自的數據表以外鍵形式建立聯系。

3)Elasticsearch方法：將每個工序的原始數據轉換為JSON格式后,增加一個新的字段存儲前道工序的相關標識，其值為數組形式，這樣可靈活擴展多個標識。

2.4 數據追溯

Elasticsearch使用一種稱為倒排索引的索引方法，適用于快速的全文搜索[14]。本文的數據追溯依托Elasticsearch來搜索數據中插入的標識和關鍵字段信息，從而追溯到與關注的問題數據密切相關的所有紡紗生產過程數據。

紡紗生產數據的前向追溯過程如圖5所示。假設現在想要在精梳的數據集合中追溯到與并條標識為1的生產數據相關聯的精梳數據，則從該并條數據的數據塊中取出精梳工序的數據標識數組，如圖中的1和2標識，然后在精梳數據集合中分別檢索到相對應的數據，從而完成并條到精梳這個過程的追溯。

圖5 紡紗生產數據前向追溯示意圖Fig.5 Schematic diagram of forward tracing of spinning production data

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

圖6 紡紗生產數據追溯路徑圖Fig.6 Tracking diagram of spinning production data

在紡紗生產中，除自動絡筒機上的電子清紗器在線監測紗線中的粗節、細節、棉結和雜質等質量問題外，還需要離線在工廠實驗室檢測條干和捻度等紗線性能。此時，被抽樣檢測的同批次紗線已經進入后面的工序。后向追溯可追溯到同批次或包含相同問題因素的紡紗產品，從精梳到并條的后向追溯示意圖如圖7所示。當察覺到標識為1的精梳數據有問題時，在并條的數據集合中檢索數據塊的關聯標識數組中包含標識1的所有并條數據，則這些數據所代表的紡紗產品可能會存在相同的質量問題。

圖7 紡紗生產數據后向追溯示意圖Fig.7 Schematic diagram of backward tracing of spinning production data

假設此時以圖6的追溯路徑完成圖5從并條到精梳的數據追溯，將原本在并條數據中的標識數組使用相應的精梳數據數組代替，結果如圖8所示。則該融合結果形成了紡紗產品在并條和精梳工序上的完整數據塊，并通過對比問題紡紗產品和緊鄰的正常紡紗產品在追溯結果融合后的差異，從而找出可能導致問題的相關因素。

圖8 紡紗生產數據融合示意圖Fig.8 Schematic diagram of data fusion of spinning production

不同于追溯路徑，假設每個追溯過程只包含2個標識，具體的融合路徑如圖9所示。圖中的數字從小到大代表了融合的先后順序。

圖9 紡紗生產數據融合路徑圖Fig.9 Road map of data fusion for spinning production

3 實驗案例

3.1 實驗環境

實驗使用的紡紗生產數據采集自無錫某紡紗廠的現場數據，數據的產生時間為2018-06-30至2019-03-30。 實驗數據涉及的紡紗生產設備有JWF1211型梳棉機、JWF1312B型并條機、JWF1418型粗紗機、JWF1562型細紗機和SMARO-E型絡筒機，得到后續實驗結果的數據和代碼見GitHub倉庫地址：https://github.com/WangBaobaoLOVE/ES-for-data-provenance-of-spinning。

3.2 實驗對比

為測試基于Elasticsearch的紡紗生產數據追溯方法的性能，后續通過實驗對比了和MySQL、SQL Server在存儲及追溯時間上的差異，并展示了數據追溯和數據融合的結果。

3.2.1 原始數據存儲對比

為顯示紡紗數據在標識添加前后其內存的變化，表1示出原始細紗數據在不同數據量情況下各方法的內存占用，而添加標識后的存儲分析將在后文討論。

表1 原始細紗數據內存占用表Tab.1 Memory occupancy table of original spinning data MB

表1結果使用了JWF1562型系列細紗機上采集到的92個字段的原始數據?？芍谖刺砑訕俗R前，MySQL的內存占用要明顯小于逗號分隔值(CSV)文件、Elasticsearch和SQL Server。這里CSV文件主要是作為MySQL、Elasticsearch和SQL Server的中間轉換文件，即導入數據的源文件，其內存消耗僅優于Elasticsearch。此外，Elasticsearch的內存消耗最大，且數據存儲量從1～10萬的各情況下平均內存消耗分別是MySQL和SQL Server的1.89和1.85倍。這主要是因為在原始數據存儲過程中會自動建立倒排索引，從而增加了內存消耗，但也使得數據搜索的速度達到毫秒級別。而這時MySQL中只有數據消耗內存，并沒有建立數據索引；SQL Server則會建立正排索引，所以綜合形成表1 的情況。

3.2.2 帶標識存儲對比

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

圖10 帶標識細紗數據的占用內存Fig.10 Memory usage of marked spinning data

3.2.3 追溯速度對比

本節研究了單過程和多過程數據追溯、標識數量及MySQL、Elasticsearch和SQL Server這3種方法對追溯時間的影響。其中單過程是指從細紗向粗紗或粗紗向并條單過程的數據追溯，這里以細紗向粗紗為例，細紗數據來自JWF1562型細紗機，粗紗數據來自JWF1418型粗紗機。多過程是指數據追溯的過程多于1個，這里以絡筒→細紗→粗紗→并條→梳棉4個過程的追溯為例，細紗、粗紗數據同單過程，絡筒、并條、梳棉數據分別來自SMARO-E型絡筒機、JWF1312B型并條機和JWF1211型梳棉機。單過程數據追溯方法見圖5，而多過程追溯是由多個單過程構建而成。

在單過程數據追溯中，隨機選擇10個細紗數據，每個數據追溯10次，然后計算其平均耗時作為該過程數據追溯時間，結果如圖11所示。3種方法追溯時間都隨標識數量的增加而增加。但MySQL追溯時間始終遠遠高于Elasticsearch和SQL Server，分別是其2.2和1.9倍；而Elasticsearch和SQL Server則比較接近，且Elasticsearch略優。

圖11 單過程數據追溯時間隨標識添加數量的變化Fig.11 Data tracing time varies with number of labels added in single process

在多過程數據追溯中，隨機選擇10個絡筒數據，然后不斷追溯到對應的梳棉數據，并計算其平均耗時作為該過程追溯時間，結果如圖12所示。可知，MySQL、Elasticsearch和SQL Server的數據追溯時間都隨標識數量的增加而增加，且每次追溯時間由少到多依次是Elasticsearch、SQL Server和MySQL。在Excel中使用多項式對3條曲線進行擬合，其最高次冪的系數分別為0.15、0.18和0.24，說明Elasticsearch的追溯速度分別大約是MySQL和SQL Server的1.6和1.2倍。

圖12 多過程數據追溯時間隨標識添加數量的變化Fig.12 Data tracing time varies with number of labels added in multi-process

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

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

3.2.4 數據融合和對比分析

在完成數據追溯后，將追溯到的數據按照圖8、9進行數據融合，得到圖13所示為一個單過程追溯結果數據融合的實例。圖中“115”是該追溯起點數據的唯一標識，“16”是產生該數據的紡紗設備編號，“before_record”中以數組形式記錄了前道工序相關聯的數據，如標識為“774”和“826”的數據。

圖13 數據融合結果圖Fig.13 Chart of data fusion results

通過對比圖13所示緊鄰的正常和問題紡紗產品的追溯結果融合數據塊，分析二者之間的差異，包括但不限于是某個或多個參數的變動，某道工序少了或多了幾個標識數據等，從而輔助分析可能的問題產生因素。

3.3 結果分析

紡紗生產過程的數據追溯使用本文提出的基于Elasticsearch的方法和MySQL、SQL Server等方法都可以實現。但本文基于Elasticsearch的方法其內存消耗對標識數量更加具有穩定性，在圖10所代表的實驗中基本維持在5.0 MB左右。另外，Elasticsearch在追溯速度上均優于另外2種方案。之所以造成3種方法在存儲和時間上的性能差異，原因分析如下。

1)存儲上：使用數據表方法不能適應標識數量變化的情況，會造成數據冗余和更多的內存消耗。使用關聯表以多對多關系和相關聯的2張數據表通過外鍵建立聯系的方法會生成索引數據，同樣會消耗較多的內存，但在JSON中，以一個字段的數組值來存儲標識，可靈活擴展標識的數量，相當于在數組中增加了若干數據，所以其對帶標識數據存儲的穩定性表現最好。

2)時間上:主要得益于Elasticsearch的倒排索引，而MySQL、SQL Server等主流關系型數據庫使用的是正排索引方式。從實驗結果可以看出，針對紡紗數據，倒排索引的機制是適用的。

4 結 論

本文通過研究基于Elasticsearch的紡紗生產數據追溯方法，使得在紡紗生產中實現數字化管理和質量管控的數據存儲性能和追溯速度得到提升。通過對MySQL、Elasticsearch和SQL Server實現的數據追溯方法進行充分的對比實驗發現，所提追溯方法在添加標識情況下更具存儲穩定性，且追溯速度分別是MySQL、SQL Server的1.6和1.2倍；使用JSON結構可很好的擴展追溯到的數據，形成數據融合結果，從而進行分析比對，實現質量溯源。

在實際生產環境中，該方法可有效解決現實紡紗生產中人工依賴嚴重、標識體系落后和聯通性差導致的質量溯源困難問題，具有一定的應用價值，但也要清晰意識到MySQL、SQL Server和Elasticsearch具有各自的優勢和缺陷，在不同的實際應用中還需要根據實際情況進行實驗分析。