面向生產過程管控的數據建模、集成與存儲技術

孫 云 江海凡 丁國富

西南交通大學先進設計與制造技術研究所，成都，610031

0 引言

車間生產管控系統通過對數據采集和監控系統(supervisory control and data acquisition，SCADA)、制造執行系統(manufacturing execution system，MES)、產品數據管理(product data management，PDM)等系統的業務數據進行集成和分析，實現生產多層次信息的集中化展示，達到了輔助管理者決策的目的。生產過程數據是管控系統的核心業務對象，故從技術上打通過程數據的模型構建、采集傳輸、存儲分析等環節是實現生產過程智能管控的關鍵。然而，隨著車間數字化、智能化的加速發展，車間生產設備和測控元件愈發多樣，隨著更多車間信息系統的開發和部署，生產管控系統在數據建模、數據集成、數據存儲的實施過程中面臨著缺乏通用數據模型、多通信接口維護管理難、傳統存儲架構性能低下的問題[1-3]。

針對上述問題，學者們展開了廣泛研究。在數據建模方面，周亞勤等[4]借助統一建模語言(unified modeling language，UML)建立了針織生產智能管控的通用數據模型，并梳理出設備監控/制造執行/生產計劃中的數據流，為針織生產智能管控提供了技術指導；王亞輝等[5]基于標準語義模型搭建了云架構下的制造車間數據采集和融合系統，實現了生產設備的泛在感知。在數據集成方面，張培等[6]借助面向對象方法和ETL技術提出了數字化車間多源異構數據的集成方案；李文俊等[7]構建了數據中臺對裝備基礎數據、器材數據、維修數據進行集成，通過統一數據視圖來提供數據集中管理服務，實現了裝備保障數據的集成共享。在數據存儲方面，YE等[8]用Hadoop生態圈框架搭建了工業大數據存儲平臺，實現了海量生產過程數據的存儲；潘明陽等[9]使用非關系數據庫MongoDB構建了船舶歷史數據庫，實現了基于船舶大數據的船舶監控、航道管理及海事管理等地理位置服務；趙炯等[10]基于Redis設計了盾構遠程監控系統，實現了盾構數據的高速緩存、高容災和高可用。上述研究主要聚焦于特定車間生產過程中設備數據的集成和存儲技術，較少從多維度對生產過程數據進行全面描述；同時數據感知/集成方式主要面向SCADA/MES等系統制定，難以適應管控系統對車間多信息系統集成適配的需求；在數據存儲方面，當前研究著眼于采用一種存儲工具來實現海量數據的高速讀寫，較少從多存儲工具協同運行的角度進行架構設計。

綜上所述，本文以生產過程管控系統為載體，面向車間多源數據，對系統實施中的數據建模、數據集成、數據存儲技術進行深入研究。

1 車間數據特性分析與數據建模

生產車間不同網絡層次設備及數字化系統的監控數據由于描述語義、結構層次各不相同，使得生產過程管控系統從中集成到的數據不能基于統一數據模型一致地解析及存儲。通過構建生產過程數據模型，對生產過程監控數據進行梳理和組織，并定義統一結構層次的可視化描述標準，是解決上述問題的關鍵。然而，當前對生產車間數據建模的研究多針對生產設備展開，處于設備控制階段，主要用于解決設備間互聯互通的問題，沒有針對車間計劃下達—產線作業調度—設備生產執行的生產管理流程來系統、全面地描述監控對象；同時，當前生產數據建模往往針對特定制造領域展開，模型可重用性差，管控業務面向不同制造領域展開將會增加額外的數據建模工作。

針對上述情況，本文將車間生產過程劃分為多個子過程，并對各子過程的數據特性進行分析，以明確生產過程數據建模的問題域；在此基礎上，借助圖形化數據描述工具EXPRESS-G構建生產過程數據模型，定義了共性的生產過程監控對象及其內涵、屬性、結構層次，將生產過程多維數據以統一的層次結構映射到生產過程管控系統中，為集成數據的統一解析和傳輸提供模型依據。

1.1 車間數據特性分析

本文將車間生產過程劃分為設備生產、產線執行、車間管理3個子過程。其中，設備生產過程主要包含開工條件核查、作業任務執行、生產情況反饋等業務內容。產線執行過程主要包含作業排程及調度、質量檢測、物料配送、資產維護等活動。車間管理過程主要包含生產計劃/設計文件的下達及工藝路線制定等業務。生產過程管控系統即面向設備生產、產線執行、車間管理3個子過程中設備級數據、產線級數據、車間級數據展開數據建模、數據集成及數據存儲。表1對各維度數據的監控對象、數據來源、采集方式、采集特性、數據格式、存儲方法進行了分析，分析結果顯示了車間生產過程數據的海量、多源、異構的特點。

表1 車間生產過程數據特性分析

1.2 車間數據建模

本文基于車間管理—產線執行—設備生產的生產執行過程，自上而下將車間數據模型進行分解，建立與之對應的3個子模型。在此基礎上依據過程監控需求對各子模型中涉及的關鍵數據信息進行抽象，建立相應的抽象實體，并明確各抽象實體包含的屬性及其關系。抽象實體對生產過程包含的監控對象進行共性表達，并可通過屬性拓展實例化為具體監控對象，進而對生產過程進行全面描述。

EXPRESS-G是一種圖形化數據描述工具，較多地應用于系統開發前的數據需求描述。下面將通過標準化圖形建模語言EXPRESS-G對各子模型中的抽象實體、實體屬性等要素進行定義，該過程需要保證各子模型沒有業務重疊，且對各抽象實體設置拓展屬性以應對監控需求變化。

1.2.1設備級數據模型

設備級數據模型從設備設計、運行、維護3個維度對設備生產過程中的服役狀態進行描述，為設備監控看板的實時及歷史狀態監視提供模型支撐。建立設備靜態信息、設備運行信息、設備組成信息、設備維護信息4個抽象實體，并對其屬性和對應關系進行定義，如圖1所示。圖中[1∶1]表示一對一關系，[1∶n]表示一對多關系。

圖1 設備數據建模

設備靜態信息包含設備名稱、類型、出廠日期、設備型號等設備出廠固有(或生產系統建立時已配置好)且長期保持不變的屬性；設備運行信息包含閑忙狀態、加工時間、動作指令、實時能耗等隨生產實時變動的屬性，能反映設備在生產中的加工狀態、工藝參數、能耗情況等，是設備監控的重要部分；設備組成信息包含組成設備的機構及其測控系統的基本信息、狀態信息、拓撲結構、模型信息等；設備維護信息包含故障時間、故障代碼、維修人員、維修時間等設備服役后的故障及維護信息。

1.2.2產線級/車間級數據模型

產線級數據模型依據產品質量管控要素人、機、料、法、環、測來構建，為產線執行過程中影響產品質量主要因素的明確提供模型支撐，包含人員信息、設備統計信息、物料信息、生產作業信息、環境信息、質檢信息6個抽象實體，各抽象實體包含的對象屬性及關系如圖2所示。人員信息定義了工作人員的基本信息和工作狀態；設備統計信息不同于1.2.1節中設備級數據模型的描述內容，通過對設備狀態信息進行分析處理，提取出設備綜合效率(OEE)、設備故障率等參數用于設備生產效能的評估；物料信息對在制物料的靜態信息、加工狀態進行定義；生產作業信息描述了產線內生產作業的具體內容、執行要素、執行情況及異常信息；環境信息包含溫度、濕度等影響產品加工質量的參數；質檢信息對產線內質檢活動的檢測內容、物料對象和檢測結果進行描述。

車間級數據模型依據訂單下達—任務調度—工藝規劃的車間管理流程展開，包含訂單管理信息、生產任務信息、工藝設計信息、倉儲信息4個抽象實體，各抽象實體包含的對象屬性及關系見圖2。訂單管理信息主要包含產品訂單的客戶信息、產品數量、成交額、完成進度等基本信息；生產任務信息對車間內生產任務的具體內容、執行要素、完成情況進行描述；工藝設計信息包含車間工藝流程的設計文檔、加工對象和執行要素等；倉儲信息涵蓋車間內倉儲的基本信息、在倉物料和物料進出情況等。

圖2 產線/車間數據建模

2 基于通信適配的生產數據集成

生產過程管控系統面向車間物理設備、數字化管理系統等數據源，從設備、產線、車間多個維度進行數據集成，以保證監控數據的全面性。然而不同車間數字化建設情況各異，各數據源所提供的數據通信接口各不相同，通信方式主要包含面向物理設備采集(通過串口通信、TCP/IP、RFID等)和面向信息系統集成(通過數據庫、消息中間件、文件系統、ETL工具等)兩種，多數據接口適配是生產數據集成必須解決的技術問題。另外，當前開發模式直接調用數據源所提供通信接口，各通信接口的調用流程、輸入/輸出參數均不相同，系統需單獨開發與之對應的通信調用層以實現數據接口適配，這將使生產管控系統通信層與數據層高度耦合，新數據層的引入將會改動通信層程序源碼，大大增加了系統開發工作量。同時，數據層源碼及其所依賴的資源文件內嵌在通信層源文件內部，這將影響程序的編譯/執行效率，也使通信現場部署及測試變得困難。

因此本文將數據通信過程中的共性業務邏輯抽象為通信適配層，將系統對多個通信調用層的開發維護工作變為僅對通信適配層展開，從而實現系統通信層和數據層的分離，后續新的數據層的接入不需修改上層應用程序源碼。同時，將常見通信協議封裝為動態庫可實現代碼的重用，現場通信僅需將動態庫加載到指定環境目錄中即可實現便捷的通信部署及測試。由此可見，通信適配層具備可重用、易拓展和易維護的特點，實現原理如圖3所示。

圖3 通信適配層實現原理

2.1 通信適配層設計

通信適配層的本質是基于面向對象設計(oriented object design，OOD)中依賴倒置、開放封閉、單一職責的原則，根據數據接口類別對其共性業務流程進行抽象，建立數據通信基類，定義其基本通信功能，如環境初始化、數據讀取、通信日志、斷開連接等。而具體的數據通信協議類則繼承自該基類，基于不同通信協議提供的通信開發包對具體方法進行實現，派生出不同通信協議的適配器，如MTConnect適配器、OPC適配器等。上層應用調用基類的抽象接口，基于多態原理實現子類方法的自動調用，從而實現上層應用與底層數據的分離。采用通信適配層既可對通用標準協議OPC-UA、MTConnect等進行適配，實現設備數據的互聯互通和同構采集，還可對車間信息系統的數據接口進行適配。通過對多數據接口的通信和管理，實現對設備/產線/車間多層次異構數據的集成，保證監控數據源的豐富性，并降低數據接口的開發和維護成本。

基于上述方法對通信適配層進行設計。通信適配層包含接口管理器、抽象接口、適配器、適配接口4個部分，基于UML建立其組成模型，如圖4所示。

圖4 通信適配層UML圖

適配接口是由車間通信組件開發商提供或自行封裝的通信客戶端類，如武漢華中數控股份有限公司提供的HNC-8、OPC基金會提供的OPCDAAuto.dll等，調用其API對車間信息系統的數據服務器進行連接訪問，實現業務數據的通信采集。

適配器是實現抽象接口集成適配接口的中間環節。通過繼承并實現抽象接口中的標準通信接口以生成OPCAdapter、TCP/UDPAdapter等適配器類。各適配器實例對應一種具體的適配接口，將適配接口中的通信API封裝到其標準通信接口中，實現配置屬性、初始化、讀取數據等操作，并根據配置信息將集成數據轉化成統一數據格式。

抽象接口是接口管理器所依賴的抽象集成類，根據車間主流數據源建立通信協議、數據庫、消息中間件和文件系統4個抽象類，各抽象類根據業務特性封裝有不同的標準通信接口，并保留未定義功能的方法，以便于該類抽象接口的功能拓展。

接口管理器通過人機交互界面個性化選擇要適配的通信接口，對現有通信接口進行匹配、測試和通信，并通過抽象類指針多態地調用同類適配器類中的通信方法，實現多源數據的適配和管理。

2.2 數據集成流程

基于通信適配層的多源生產過程數據集成框架如下：生產設備及測控元件如機器人、數控機床、AGV、PLC、RFID等生產的底層數據可由OPC-UA協議統一采集和管理，或者通過SCADA、DCS等工控系統對底層數據進行間接集成。產線執行、車間管理等業務數據則通過適配MES、ERP、PDM等信息系統提供的數據接口來獲取。集成得到多層次生產過程數據由適配器依據車間信息模型統一轉化為JSON格式存入管控系統存儲模塊，也可將數據上傳至生產大數據平臺中，為大數據分析、挖掘提供數據支持。技術框架如圖 5所示。

圖5 多源數據集成架構

進一步地，以OPC-UA、HBase兩種常見通信接口為例，對數據源適配過程進行闡述。

2.2.1OPC-UA協議適配

OPC-UA因具備統一對象模型、命名空間、層次管理等機制，被作為工控標準通信協議廣泛應用于設備層數據的統一管理和傳輸。管控系統通過通信適配層對OPC-UA協議進行適配，可遠程對車間工控系統的OPC服務器進行數據訪問。適配過程如下：①適配接口類動態加載OPCDAAuto.dll，建立OPCServer對象并連接到OPC遠程服務器，依據OPCGroup對OPCServer命名空間中已定義的具體車間設備進行訪問，調用讀取事件獲取相應OPCGroup中的OPCItem值；②繼承通信協議類抽象類生成OPC-UA適配器類并將①中通信過程封裝到其標準通信接口中，包含創建客戶端實例、初始化通信環境、配置通信參數、接收增量數據、發送數據、數據格式轉換等，將封裝結果生成為動態庫；③將返回車間數據項與設備實例化對象的映射關系寫入配置文件，同時，調用OPC-UA適配器動態庫，根據配置信息將數據統一以JSON格式返回，完成數據格式轉換。

2.2.2HBase數據庫適配

以HBase為代表的NoSQL數據庫為車間信息系統提供了海量業務數據存儲與查詢服務，正在生產車間中得到普及，對其進行適配可使管控系統對車間各信息系統進行業務數據訪問和集成。具體適配過程如下：①適配接口類在加載Thrift數據庫驅動后，創建HBase客戶端對象并連接到數據庫服務器，通過客戶端所提供的Scan、Get等方法獲取返回參數以實現過程數據讀??；②繼承數據庫類抽象接口生成HBase適配器類并將①中通信過程封裝到其標準通信接口中，包含創建實例、連接服務器、映射關系配置、訂閱增量數據、寫入數據、數據格式轉換等，將封裝結果生成為動態庫；③建立服務器元數據結構和實例化對象的字段映射關系，以csv文件的格式保存，調用HBase適配器動態庫，加載csv文件信息將集成數據統一轉換為JSON格式，實現車間異構數據的同構集成。

3 基于Redis-MongoDB-HDFS架構的生產數據存儲

當前生產數據存儲框架主要采用傳統關系型數據庫MySQL、Oracle等。關系型數據庫適用于查詢過程復雜、數據量不大的結構化數據管理，難以應對非結構化數據(如圖片、視頻等)和大規模數據的存儲。由1.2節車間數據特性分析可知，生產過程管控系統集成的生產數據包含結構化數據、半結構化數據、非結構化數據，若僅采用傳統關系型數據則難以實現異構數據的高效存儲。同時，設備工藝狀態等數據刷新頻率快，讀寫頻繁，要求數據庫具備高速讀寫能力，而車間運行過程產生的歷史數據則要求數據庫具有大規模數據存儲與分析能力，當前研究多采用一種數據存儲工具，難以較好地滿足上述需求。

針對當前問題，本文將NoSQL數據庫及分布式文件系統引入生產數據存儲中。其中，NoSQL數據庫采用Key-Value、面向Document等存儲結構，具備較好的拓展性，能應對TB/PB級結構化/半結構化數據的高效存儲。分布式文件系統將數據文件分布于多個存儲節點，主要用于海量非結構化數據的存儲和管理。本文設計了基于Redis-MongoDB-HDFS的生產數據存儲架構，根據生產實時數據、生產歷史數據及生產文件各自的特點選擇合適的數據庫，并定義了各數據庫間的交互及協同關系，以實現異構數據的高效實時讀寫及歷史數據冗余。

生產數據存儲架構將通信適配層集成得到的海量數據按照一定組織進行分類存儲，為生產管控系統的生產實時監控、歷史數據分析、現場視頻回顧等業務模塊提供數據支持。該架構包含集群環境、實時數據存儲、歷史數據存儲、文件存儲4個模塊，通過Redis-MongoDB-HDFS架構協同實現對海量生產數據的實時存儲和高速讀取，總體框架見圖6。

圖6 基于Redis-MongoDB-HDFS的生產數據存儲框架

集群環境模塊為整個存儲框架提供了硬件運行環境，基于交換機、虛擬路由等網絡硬件將多臺服務器或虛擬終端的網絡地址設置到同網域，實現網絡互通；將指定版本Redis、MongoDB、Hadoop的數據存儲服務、集群管理服務部署到各服務節點上，在單一節點內通過配置文件的形式設置主從角色、讀寫權限等參數，實現集群的數據備份，保證生產數據的安全存儲，并將讀寫操作定向到同一節點的不同數據存儲服務上，提高集群的讀寫速度。同時，集群通過線性增加服務節點，實現存儲容量和讀寫吞吐量的水平拓展。

實時數據存儲模塊為生產實時數據提供緩存和高速讀取服務，通過Redis實時數據庫來實現[10]。在存儲結構上選擇String結構，以Key-Value對進行存儲。將監控實例對象ID作為Key，Value部分對應通信適配層的數據輸出格式，是包含內嵌結構的JSON串，有Timestamp和Entity等多個Map對象，其中Timestamp為當前時間戳，Entity為監控對象包含的實體名，其值為實體包含的所有屬性集合，屬性集合的層次結構由實例對象模型決定，定義存儲格式如表2所示。

表2 實時數據存儲格式

管控系統調用通信適配層中的方法將原始數據轉換成上述JSON格式并寫入Redis服務器完成過程數據的實時存入。為保證生產過程信息的實時展示，Redis集成的最新實例對象數據會覆蓋歷史數據，使內存中始終保存各監控實例對象最新的屬性信息，從而保證服務器的讀取性能。

歷史存儲模塊負責構造生產歷史數據集并提供查詢分析服務，借助MongoDB數據庫實現[9]。首先對歷史數據的存儲結構進行定義，基于車間、產線、設備3個監控層次建立Workshop、Production-line、Equipment 3個Database。然后根據監控實例模型的結構在Database中創建相應Collection，并按照一定頻率讀取并解析Redis中實例對象的Timestamp和Data，全量地插入到對應的Collection中，完成歷史數據寫入。

文件存儲模塊為視頻、圖片、文件等非結構化數據提供存儲和讀取服務，借助HDFS實現[8]。首先按照監控主題、監控日期、監控內容的層次生成生產文件管理樹，然后在HDFS根目錄中以車間、產線、設備為主題建立文件目錄，各主題目錄中每天以當前日期為文件名添加日期文件目錄。在日期文件目錄中創建生產文本資料、生產監控視頻、文件圖片副本等內容篩選目錄，各篩選目錄可根據實際情況繼續嵌套。集成得到的生產文件以“監控主體_監控日期_文件內容”的格式重命名并存放到相應的文件目錄中。通過獲得該文件的索引，將索引、文件名、文件路徑信息作為一條Document插入MongoDB中，方便根據文件名快速查找文件。

4 實例驗證

實例車間主要生產任務為亞克力雕刻件和合金結構件的粗精加工，并分設雕刻件產線和結構件產線。以雕刻件產線為例，該產線包含了雕刻機、AGV、機械手、五軸加工中心等生產設備及傳感器、RFID、控制電機等測控設備。車間生產信息系統包括SCADA、MES、ERP。SCADA配置有Kafka隊列作為數據傳輸接口，MES、ERP則為管控系統提供MySQL的讀取權限。若采用OPC-UA協議對設備數據進行直接采集，則只能完成對設備級數據的監控，而采用常規設計模式對每種數據接口編寫耦合的數據通信層又將使數據接口的拓展和維護變得復雜。同時，車間單班制運作，部署有數據監控點100多個，每日產生實時數據1.2 GB，約300萬條，視頻、圖片等文件數據3 GB。若采用傳統關系型數據庫對車間數據進行存儲，則由于其橫向拓展性差、數據模型約束復雜，不能較好地應對生產管控中變動的監控需求，且對視頻等大型非結構化數據文件的讀寫性能較差。同時，當存儲數據量達到TB、PB級后，關系型數據庫的吞吐性能將顯著下降?；谠撥囬g遇到的問題，將本文提出的海量異構生產數據的建模、集成和存儲方法應用到車間管控中，并對管控系統的存儲/集成模塊進行實現。

4.1 車間數據建模實現

基于車間信息模型，依據實際監控對象，對監控對象各抽象實體進行實例化。以華數機器人為例，建立機器人實例模型，如圖7所示。

圖7 機器人數據建模實例

在此基礎上，以實例車間雕刻件產線為例，對產線級數據模型進行拓展和重用，建立雕刻件生產線實例模型，如圖8所示。

圖8 雕刻件產線數據模型

4.2 車間數據接口及通信

基于通信適配層技術，對Kafka、MySQL兩種客戶端接口進行適配，將librdkafka.lib及Msado15.dll中的通信API按照其通信邏輯封裝到通信適配層的標準通信接口中，并生成KafkaAdapter.dll及MySQLAdapter.dll兩個動態庫，將動態庫放置到生產過程系統指定的文件目錄下。

系統通過增量數據訂閱的形式調用通信適配層中相應的動態庫，對生產線上已部署的SCADA、MES、ERP系統進行數據集成，而SCADA系統則采用OPC-UA統一對車間底層設備進行數據采集。集成數據格式依據實例化模型統一轉換為JSON格式后寫入Redis中進行實時緩存。Redis以每秒一次的頻率將全量數據寫入MongoDB中形成生產歷史數據。視頻、生產文件等數字則按天批量導入HDFS中，構建車間通信網絡拓撲結構，如圖 9所示。

圖9 車間通信網絡拓撲圖

4.3 數據存儲平臺部署及測試

存儲模塊利用虛擬化組件VMware在工控服務器上搭建，配置了3臺虛擬節點，并依據負載均衡、主從備份、讀寫分離的原則，將Redis、MongoDB、HDFS相應的存儲、管理服務進程部署到虛擬節點上，完成存儲框架的搭建。配置情況如表3所示。

表3 集群性能配置

基于上述配置，使用性能測試工具Redis-Benchmark、YCSB、Sysbench模擬50個線程并發，對Redis、MongoDB、MySQL服務器進行查詢操作，以測試存儲架構的讀取性能。首先在各服務器中導入有300萬條信息的生產過程數據表，單條記錄大小為1 kB，并將查詢總次數分別設置為10萬、100萬、1000萬，分3組測試服務器每秒查詢率(queries-per-second，QPS)，最終測試結果如表4所示。由測試結果可知，在相同硬件配置環境下，Redis和MongoDB在應對GB級數據查詢的性能遠優于關系型數據庫MySQL，且尚未出現性能瓶頸。

表4 集群吞吐量測試結果

4.4 車間生產管控系統實現

基于通信、存儲環境部署，對生產數據集成、存儲模塊進行實現。首先，基于MFC框架開發了通信適配集成模塊的管理界面。通過人機交互可增加、修改、刪除接口實現動態管理；同時，對已定義的接口添加配置文件實現字段映射、結構轉換等功能，并在此基礎上進行連接測試和數據通信。存儲模塊通過部署在工控服務器上的存儲服務進程實現對通信適配層和管控系統業務層的讀寫響應；采用RedisDesktopManager、Studio 3T和WebHDFS分別對Redis、MongoDB、HDFS進行可視化管理，實現各存儲框架的元信息構建、數據操作和權限授予等功能。最后，將上述模塊作為數據服務端為生產管控系統應用層提供數據讀取、分析等服務，進而實現生產過程數據集中化展示、生產狀況實時監控、歷史數據關聯分析等應用功能，實施效果如圖 10所示。

圖10 數據集成、存儲模塊設計與實現

5 結論

本文從生產過程管控的實際問題出發，使用EXPRESS-G建立了車間信息模型，從設備生產、產線執行、車間管理3個層次對生產過程進行了抽象描述，結合柔性制造車間對所有監控對象進行實例化，較為全面地反映了生產過程監控所需的關鍵信息；借助通信適配層對柔性制造車間的Kafka、MySQL接口進行適配，對車間SCADA、MES、ERP數據進行結構轉化和統一集成，保證了生產過程監控數據的豐富性和同構性；提出Redis-MongoDB-HDFS架構，將通信適配層集成的JSON數據按照統一的邏輯結構寫入數據庫中，應用案例表明，該存儲架構能滿足車間每天4 GB增量數據的實時寫入，并可實現實時/歷史數據的微秒級查詢，保障了大規模生產數據的高性能存儲與讀寫。

在生產數據建模、采集、集成和存儲的基礎上，深度融合制造技術、工業大數據與新一代人工智能是實現車間智能管控的關鍵和趨勢，也是下一步研究方向。