基于B/S架構的數控機床實時監測與信息管理系統的開發

發布時間：2023-07-08 10:22

摘要 I

Abstract III

1緒論 1

1.1研究背景 1

1.2國內外研究現狀 2

1.2.1國外研究現狀 2

1.2.2國內研究現狀 3

1.3論文研究的主要內容及技術路線 4

1.3.1主要內容 4

1.3.2技術路線 5

2系統總體結構設計 6

2.1車間設備現狀 6

2.2系統功能要求 6

2.3系統組成架構 7

2.3.1數據顯示層 9

2.3.2數據處理層 9

2.3.3數據存儲層 10

2.3.4數據采集層 10

2.4系統開發環境 11

2.5本章小結 12

3西門子 828D 數控系統數據采集與存儲 13

3.1西門子828D數控系統OPC UA原理 13

3.1.1OPC UA 的架構 13

3.1.2OPC UA 的變量 14

3.1.3OPC UA 的配置 15

3.2基于OPC UA的數據采集 16

3.2.1OPC UA 客戶端設計 16

3.2.1.1OPC UA客戶端功能開發 16

3.2.1.2OPC UA客戶端界面設計 18

3.2.2數據采集的實現 20

3.2.2.1數據采集的具體變量 20

3.2.2.2基于Python的數據采集 21

3.3西門子828D數控系統數據存儲 22

3.3.1關鍵問題分析 22

3.3.2數據庫結構的設計 23

3.3.3數據庫表的設計 24

3.4本章小結 27

4Web 服務器層功能模塊設計 28

4.1基于OEE的數據分析模塊 28

4.1.1設備綜合效率 OEE 28

4.1.2OEE 在本系統的應用 29

4.1.2.1數控機床狀態定義 29

4.1.2.2OEE 基礎數據 29

4.1.2.3OEE 參數計算 30

4.2基于改進的 SDT 算法數據壓縮模塊 31

4.2.1SDT 算法原理 32

4.2.2SDT 算法評價指標 32

4.2.3SDT 改進算法 33

4.3基于RabbitMQ和 WebSocket的實時數據推送模塊 35

431基于RabbitMQ的采集層數據傳輸 35

4.3.1.1RabbitMQ 原理 36

4.3.1.2RabbitMQ 數據傳輸 37

4.3.2基于WebSocket的顯示層數據傳輸 37

4.3.2.1WebSocket 原理 38

4.3.2.2WebSocket 數據傳輸 38

4.4數控機床信息管理模塊 39

4.4.1后臺數據管理 39

4.4.2機床點檢信息管理 42

4.4.3機床故障信息管理 43

4.4.4機床備件信息管理 44

4.4.5機床基礎數據管理 46

4.5本章小結 50

5軟件系統測試 51

5.1實驗環境搭建 51

5.2系統運行實例 52

5.2.1數控機床實時監測模塊運行實例 52

5.2.2數控機床信息管理模塊運行實例 54

5.3系統性能測試 56

5.3.1數據傳輸模塊測試 56

5.3.2數據壓縮模塊測試 57

5.4系統功能測試 59

5.5本章小結 60

6結論與展望 62

6.1結論 62

6.2創新點 62

6.3展望 63

參考文獻 64

攻讀學位期間發表的學術論文及研究成果 67

致謝 68

1緒論

1.1研究背景

隨著 “中國制造 2025”戰略的實施，拉開了我國從制造業大國向制造業強國的轉變的序幕。我國互聯網產業的快速發展，正在深刻的影響著我國的制造行業。在智能制造方面，我國正加大力度建設智能工廠，加快實現工廠各種設備的互聯互通，同時利用互聯網技術智能地根據實時信息進行分析、判斷、自我調整、自動驅動生產［1］。數控機床作為智能工廠建設關鍵設備，如何提升數控機床的信息化管理水平更顯得尤為重要。機床行業技術水平作為衡量一個國家基礎工業發展水平的重要指標，數控機床的研發更是各國在裝備制造領域必爭的兵家之地。數控機床是制造業價值生成的基礎和實現制造業轉型的支點，是一個國家基礎制造能力的核心部分［2］。據統計，在2016年我國數控機床的銷售額達到了2630.4億元，同比增長7.69%。在 2017~2022年，我國數控機床市場將會保持 10%~20%的增長速度。預計到 2022 年，我國數控機床行業的市場規模將超過5000 億元［3］。可以看出，數控機床市場在我國是如此龐大。

數控機床作為典型的機電一體化高端制造裝備，其控制系統和機械系統具有很高的技術含量，現代高檔數控機床更是機械加工設備復雜化、精密化、自動化的代表。隨著制造業對數控機床的需求越來越大，數控機床在通用性、穩定性、安全性等方面也面臨著越來越多的挑戰，數控機床發生故障的概率也隨著提高［4］。在傳統的車間生產制造中，如果數控機床出現故障，只能通過專業的技術人員進行解決甚至必須依靠廠家提供幫助，費時費力。如果故障不能得到及時的排除，那么生產進度將會被影響，降低整個車間的加工效率，甚至可能造成企業客戶的流失。同時在整個車間中對于數控機床的狀態的掌握往往只能通過機床自帶的人機交互界面進行獲取，管理人員不能準確的獲取當前數控機床的狀態。各種信息大多都是通過紙張的形式進行傳遞，沒有進行合理的數據管理［5］。

因此要實現車間的信息化管理，及時解決數控機床的故障。優秀的車間管理模式，合理的數據管理方法刻不容緩，數控機床加工的實時數據是對機床進行實時監測的依據，在數控機床信息化建設當中，應當依托物聯網技術，數據分析技術，通信技術實現對數控機床狀態進行實時監測和對數據的實時獲取。同時應當對采集的數據的運用數據分析的手段，使用Web技術進行數控機床的遠程監測，進而得出合理的結論，反饋給企業改進加工工藝，提高企業的效益［6, 7］。同時開發相應的數控機床信息管理模塊，實現對機床相關信息的統一管理。

所以，借助智能的數據采集技術、數據庫存儲技術、數據分析以及互聯網通信技術，為傳統制造業的數據存儲和設備監測提供新的解決思路。對形成智能化的生產制造，推動我國邁向制造強國具有重要的意義［9］，其具體的實際意義如下：

（1）自動化數據采集，過程數據實時監測。在傳統的數控設備的狀態監測中，數控機床的數據需要現場的操作工人進行手動的數據采集，故障信息主要根據人機界面故障信息顯示或者故障燈的閃爍進行判斷，采集數據時常不準確，重要的是缺乏實時性。同時采集的數據多為紙質存儲或者使用傳統的 EXCEL 進行存儲，沒有合理的管理數據措施。利用數控機床的數據接口獲取需要的過程數據，不僅減輕了工人勞動強度，還提高數據采集的效率與準確性。同時使用基于 B/S 架構的信息可視化技術實現了數控機床加工數據的實時顯示。

（2）數據的科學管理。單臺數據庫服務器存儲海量的機床的加工過程數據已經很難滿足需求，由于系統主要進行存儲實時采集的數據，多為數據寫操作。搭建數據庫的主從配置，既提升了讀寫效率，也保證了數據的備份，使系統運行更加穩定、高效，也為接下來對數控機床進行數據分析提供數據支撐。

（3） Web 遠程數據監測與分析。通過使用基于 B/S 架構的 Web 技術，能夠輕松的在遠端實現實時的掌握數控機床的運行狀態，同時將采集到數據進行統計分析以圖表的形式直觀的展示給的工作人員，管理人員也可以不用深入到一線車間就能實時查看數控機床當前的狀態，進而可以實現與現場人員的實時交流，實現對數控機床的高效管理。

（4）機床相關信息的可視化管理。要維持一臺數控機床的正常運行，需要多方面的共同配合。例如機床操作人員管理、故障解決知識庫管理、數控機床備件管理以及保養維護管理。通過實現上述內容的有效管理，能夠更加高效管理數控機床整個加工流程，提高及時解決故障的能力，提高機床的加工效率，保證生產高效有序的進行。

基于此，該系統可實現遠程或離線訪問查看，同時為 MES （Manufacturing

Execution System，制造執行系統），ERP （Enterprise Resource Planning，企業資源計劃）系統提供一線生產車間的數據，為實現車間乃至企業的智能化管理提供數據保障。

1.2國內外研究現狀

隨著智能制造的概念不斷深化，工業互聯網作為新一代信息技術與制造業深度

融合。基于B/S架構的Web技術也在慢慢的取代原有的C/S架構的客服端，數控機床的智能數據采集、智能存儲技術、實時數據監測、大數據分析、Web可視化信息管理等多個領域已成為國內外學者研究的重點內容［10］。

1.2.1國外研究現狀

（1）Web 實時監測研究現狀

早在1996年，美國的NorthAndover公司開始了Web信息監控技術的研究。同年該公司首次實現了將PLC接入了因特網［小。隨著Web技術的不斷發展，互聯網公司Sun，制造業公司Ford都紛紛加入了該項技術的研究。在這之后，美國麻省理工學院和斯坦福大學聯合發起了對Web遠程信息監控技術的討論的會議。隨后，多家企業使用 Java聯合開發了一套Web信息監控系統，該系統完成了對一定規模的設備信息實時監控，并通過采集的數據完成了早期的數據分析。當然這只是早期的研究，而并未將該系統應用到實際的生產環境中［12］o 2005年，NI公司在自家產品LabVIEW中首加入了網絡通訊處理模塊，實現了基于B/S架構的Web遠程監視系統。西門子開發的 WinCC軟件可使用Web Navigator組建遠程的Web控制系統，實現信息的可視化。國外的研究起步早，技術大都比較成熟，但是都需要購買且價格昂貴。由于在數據傳輸方面需要通過生產商的服務器，所以數據可能存在泄露風險［13］ o

（2）設備信息管理研究現狀設備信息管理作為智能制造研究的一個重要的組成部分，以日本、德國、美國為首的發達國家很早就對信息管理系統進行研發，與此進行了大規模的推廣與應用。 Choy和Su從智能管理的角度研究了生產設備的性能預測與智能維護，智能管理，最終實現了企業對生產管理的高度智能化［14, 15］。在2004年，Fan —TienChen研究了基于協調性和柔性、高度自主能力的智能生產管理信息系統，為該領域的研究奠定了基礎。2005年，Jimenez提出了基于B/S架構的生產管理信息系統的應用框架結構，實現了系統的模塊化與敏捷開發［⑹o美國EDS公司為通用公司開發的IMAN 軟件已經穩定運行了十多年，實現了高度智能化信息化的管理，極大地提高了通用公司的市場競爭力［17］。日本傳統制造業對企業信息化與智能化的重視程度非常高，例如發那科，三菱等大型制造業都進行了相應的設備信息管理的研究以及相應的信息管理數據庫［18］。

1.2.2國內研究現狀

（1）Web 實時監測研究現狀

近年來， Web 技術在我國得到飛速的發展。在智能制造的號召下，基于 Web 的監控技術在制造行業得到了廣泛的關注，各高校人員也開始了相關的研究。上海應用技術大學的張杰人通過OPC UA采集西門子840D數控機床加工的實時數據，利用 Web 技術和數據庫技術將實時信息顯示在網頁上，實現了數控機床的實時監測［19］。武漢理工大學的卓禎雨利用 CORBA（Common Object Request Broker Architecture）技術結合傳統的Web遠程監控技術，使用Java開發出了四層結構的 Web監控系統。該系統降低了 Web服務器和數據庫服務器的負載，大大提高了系統的性能，在某油田原油生產中得到了應用［20］o太原理工大學的邱浩使用MongoDB 數據庫建組建了高性能的分布式數據庫存儲系統，使用 Node.js 技術在該數據庫系統上開發了一套選煤廠機電設備實時運行監測系統，通過 MATLAB 將采集數據進行分析，為選煤廠創造了經濟效益㈤］。上海交通大學的夏志通過嵌入式適配器采集數控機床的數據，利用WebServer技術開發了基于B/S架構的數控機床遠程監視與管理系統，實現了對數控系統實時狀態的監測［22］。

（2）設備信息管理研究現狀

我國在制造業相關設備信息管理方面的研究起步較晚，與發達國家有一定的差距。近年來，隨著互聯網行業的發展與我國對智能制造的需求，我國提出了“中國制造2025”的口號。國內的高校和企業都更加深入地對智能信息管理開展研究。東北林業大學的王哲健［23］等針對中小型機械制造企業的實際生產和管理情況，開發了一套適合中小型機械企業的生產管理信息系統。該系統包括基礎數據管理、信息瀏覽、工資及成本核算、生產信息管理以及系統管理等模塊，較好的滿足了企業的實際需求。李大勇、李欣［24］利用基于 MAXIMO 平臺的 EAM 解決方案，將現代化的技術與企業的實際生產情況進行結合，將設備作為核心、工作流引擎為手段，建設了智能化、一體化的安全生產管理平臺，極大地提高了企業的管理水平。西安理工大學的孫曉寧［25］從實際需求出發，根據企業的運營模式，建立了印刷企業管理信息系統的總體框架，解決了企業管理信息混亂、數據不全或缺失、流轉不暢、安全無法保證等問題。

由于 Web 技術具體有分布性強、維護簡單、開發簡單以及共享性強的特點，在制造業的實時監控方案中得到了廣泛的采用。但是基于 B/S 架構的 Web 應用在速度和安全性上有先天的不足，要做到無延遲、零響應以及完全的實時監控仍然面臨著許多的問題［26］。本文也只能利用當前現有的 Web 技術，通過改進數據傳輸的架構，進而提高系統的實時監測的性能。

1.3 論文研究的主要內容及技術路線

1.3.1主要內容

本文主要為了滿足企業對數控機床實時運行監測、相關信息管理、數據可視化分析的需求。研究了基于OPC UA的828D數控系統的實時數據采集；MySQL數據庫的設計，包括數據表的設計和數據庫架構的設計；對海量的過程數據的壓縮算法進行了研究；對提高實時數據的傳輸速度的方法進行了創新；對采集的數據進行了可視化的分析；設計了 Web 頁面用于各種的數據的顯示。論文的主要研究內容如下：

（1）通過分析車間現狀以及企業需求，進而提出了此次開發系統的設計要求，并設計系統的架構，同時詳細闡述了數據顯示層模塊、數據處理層模塊、數據層存儲模塊、數據采集層模塊該四個模塊的具體實現方法和模塊的功能。

（2）具體研究了西門子 828D 數控系統的 OPC UA 相關內容。通過具體分析

OPC UA的特點，使用Python語言開發了一個OPC UA的客戶端。利用Python語言編寫了自動化的數據采集程序，實現了西門子 828D 數控系統實時數據的采集。系統采用 MySQL 數據庫進行加工過程數據與人工錄入數據的存儲，使用數據庫分表技術，解決數據表存儲量過大的問題。使用數據庫讀寫分離的架構設計，解決數

據讀寫的問題，挺高數據庫性能瓶頸。

（3）通過使用 RabbitMQ 技術結合 WebSocket 技術實現采集數據的實時推送，降低網絡延遲。通過SDT算法將實時采集的加工過程數據進行壓縮，以減少數據庫的存儲容量。通過使用OEE方法計算設備的綜合效率，提高了數控機床的加工效率。最后詳細闡述了數控機床信息管理模塊各個子模塊實現的具體流程，包括用戶登錄模塊、機床點檢模塊、故障信息管理模塊、機床備件管理模塊、后臺數據管理模塊等子模塊的開發。

（4）通過使用 HTML、CSS、JavaScript、Jquery 等編程語言與 Echarts 圖形庫完成了用戶登錄界面、實時數據顯示界面、數據統計分析界面、機床點檢信息界面、故障信息管理界面、機床備件信息管理界面的設計與實現。

1.3.2技術路線

根據研究的主要內容得出論文的主要技術路線如圖1-1 所示。

圖 1-1 技術路線

Figure 1-1 Technical Roadmap )

2系統總體結構設計

基于 B/S 架構的數控機床實時監測與信息管理系統總體結構主要由四個模塊組成：數據顯示層模塊、數據處理層模塊、數據存儲層模塊、數據采集層模塊。其中數據顯示層主要作用是顯示采集的實時數據、數據統計報表以及歷史數據；數據處理層的主要作用是為數據顯示層提供經過處理，并以特定的格式組成的實時數據與非實時數據；數據存儲層的主要作用是存儲采集到的實時數據和非實時數據；系統采集模塊的主要作用是通過OPC UA協議實時采集數控機床的實時數據。

本章主要分析了機械加工企業對數控機床信息精細化的需求，通過對當前存在的弊端進行了需求分析，同時根據當前的需求設計系統的總體結構，介紹了系統的各結構組成，分析了系統數據的流向。

2.1車間設備現狀

本次進行數據采集的數控機床的是 VMC655H 數控機床，其安裝的是西門子 828D 數控系統。由于該數控機床并未進行任何信息化改造。所以數控機床自身的設備信息，以及加工過程的實時信息都只能從數控機床自身的交互界面獲取或者從技術手冊中獲取，這就導致了我們不能實時的獲取到其設備信息和實時信息。與此同時，也無法查詢到機床相關歷史數據，不能對機床所處的狀態進行實時把握與有效的分析。當機床出現某些故障的時候，也無法查詢歷史故障信息，從而影響設備的快速維修維護。以上種種原因使得機床的保養與維護處于被動的狀態，從而降低了機床的生產效率，嚴重時可導致整個生產進度的耽擱。

2.2系統功能要求

該系統是應用于車間的西門子 828D 數控機床的實時監測與信息管理當中。為了能夠實現對機床運行狀態的實時監測，并且同時掌握機床的各種信息，從而達到更好的幫助技術人員和管理人員維修管理機床的目的。因此該系統需具備實時顯示機床基本信息的功能、加工過程實時數據的顯示，能夠及時的顯示報警信息，并且提供對故障信息處理的解決方案。其次還能夠為制定機床的定時保養維護，配件的管理策略等提供數據支持。

針對上述所提的要求，同時結合車間的實際狀況。本次系統開發的功能應滿足以下幾點要求：

(1) 機床實時數據采集本次系統采集的實時數據主要有機床運行狀態、加工位置、運行程序、報警信息、主軸運行狀態等相關數據。由于西門子 828D 數控系統自身是一個開放式的數控系統，其自身是支持 OPC UA 協議。當我們獲取到西門子授權后，通過西門子 828D數控系統提供的標準的數據接口進行數據采集。實時的加工信息主要是為了檢測數控機床當前的運行的狀態，例如當某些數據超過限定值，就會觸發系統報警。根據現場的實際需求，本次需要實時監測的數據主要包括機床的開關機時間、機床實時的運行狀態、當前加工程序的具體信息、機床主軸的轉速、主軸倍率、主軸負載、主軸電流、主軸進給、主軸當前的三維坐標等數據。后續可通過以上的數據對機床當前的狀態，進行生產評估，同時也可將這些數據運用到機床的整個效率分析當中。

（2）數據存儲高效、穩定

由于該生產線屬于批量生產，數據產生的速度極快，同時造成數據量極大，存儲周期長。本次采用了建立數據緩沖區解決插入數據的問題，使用 MySQL 數據庫的表分區功能解決單表儲存數據量過大的問題。同時對數據庫定期進行全備份，保證數據的安全性。

（3）數控機床加工信息的實時顯示

利用Web頁面對采集到的實時數據進行顯示，通過RabbitMQ技術和WebSocket 全雙工通信技術，實現數據實時推送至前端進行顯示，利用事件通知的方式，減少網絡資源的消耗，減輕后臺服務器的壓力

（4）可人工錄入數據

由于機床本身自帶的一些靜態數據無法通過程序采集，需要工作人員進行手工的錄入，需要采取表單提交的方式存儲到數據庫當中。當維修人員對機床故障完成維修之后，也需要將故障的信息以及故障的解決方案通過表單提交的方式提交后臺存儲到數據庫當中，以便后期能夠快速的解決類似的故障。同時為了提高數控機床的加工效率，保證生產，需要對機床進行定期的維護保養，需要人工定期的制定保養的清單，并且錄入系統。

（5）歷史信息的查詢

通過自定義過濾條件，可查詢滿足條件的機床加工的歷史信息，據此分析機床當時的狀態，包括故障信息，以及報警信息等。也可查詢某個故障的維修歷史，包括維修負責人，維修時間，維修的部件等。

（6）統計報表

機床運行的過程中產生大量加工數據，需要統計例如機床的開關機時間、故障報警代碼、主軸的轉速、主軸的負載等數據，通過報表形式實時的展示給技術人員。除了實時的展示數據外，系統還可以以周、月、年作為統計的時間單位，對諸如本月的報警次數、機床加工時間等數據進行統計形成統計報表，保證生產管理者能夠實時的獲取機床的狀態，以保證機床高效的運行，減少機床停機的概率，以及事故率。

2.3系統組成架構

為了實現車間信息化的目標，本次設計的 828D 數控機床信息可視化平臺需要

符合企業的實際需求，提高企業對設備狀態的實時的把控，更加的人性化，智能化的管理整個工廠的加工設備，提高入職人員的培訓效率，工作人員更加容易的了解整個機床的性能、參數，更好地掌控一線車間的狀況，便于快速響應制定決策。本系統的總體架構如圖 2-l 所示。

圖 2-1 系統總體框架圖

(Figure 2-1 System overall framework diagram )

系統采用的是 B/S 的模式，整個系統由四個部分組成。包括：數據顯示層，數據處理層、數據存儲層、數據采集層等。底層的數據采集通過 OPC UA 協議訪問數控機床對外提供數據的API，經過數據處理后將數據儲存到MySQL數據庫當中。客戶端通過地址訪問Web服務器，Web服務器請求數據庫得到相應的數據。其中服務器定義好接口的地址，客戶端通過訪問該接口獲取JSON格式的數據。其中JSON 是一種形如｛keyl:value2,key2:value2｝格式的數據交換格式，易于閱讀和理解,也易于機器解析和生成，是理想的數據交換格式［27, 28］。

2.3.1數據顯示層

數據顯示層是整個系統與外界進行交互的窗口，當用戶通過瀏覽器訪問指定的 URL時，瀏覽器向后端發起AJAX請求，通過訪問數據處理層提供的數據接口，獲取從 MySQL 數據庫中查詢的數據。同時瀏覽器發起 WebSocket 請求，建立瀏覽器和服務器的全雙工通信，然后從消息隊列中獲取實時數據，以此保證數據的實時性。同時操作人員也可以在頁面手工輸入數據。最終數據通過前端頁面的各種圖表，表格顯示數據。本系統通過使用HTML、CSS、JavaScript、Jquery等編程語言與Echarts 圖形庫完成了整個前端Web頁面的設計。頁面結構如圖2-2所示。

圖 2-2 頁面模塊組成圖

Figure 2-2 Page module composition diagram )

2.3.2數據處理層

數據處理層主要是利用Python編程進行構建，利用Python的Django框架對外提供Web服務。Django框架是基于MVT (Model View Template)模式的后端框架，實現了和數據庫交互并進行數據處理、接收請求進行業務處理，封裝構造要返回html 頁面等主要的功能［29］。框架本身自帶的ORM (Object Relational Mapping)框架，非常的容易進行數據的管理和查詢，實現數據庫的增刪改查的功能。Django框架結構如圖2-3 所示。

圖 2-3 Django 框架

( Figure 2-3 Django framework )

2.3.3數據存儲層

數據存儲層使用 MySQL 數據庫進行數據的存儲，包括數控機床的動態數據和靜態數據。由于系統采集的數據多，所以需要存儲的數據量大。同時，因為建立數據庫連接非常消耗資源，所以采用一次數據庫 IO 操作，插入多條記錄，保證插入數據的效率。采用 MySQL 的表分區的操作，緩解數據庫由于單表數據量過大，而造成數據查詢緩慢。采用讀寫分離的模式，能夠線性的提升數據庫的讀性能，消除讀寫鎖沖突從而提升數據庫的寫性能，同時也實現了數據的備份［30］。數據庫讀寫分離架構如圖 2-4 所示。

圖 2-4 數據庫讀寫分離架構圖

(Figure 2-4 Database read-write separation architecture diagram)

2.3.4數據采集層

數據采集層的數據來源主要是數控機床在加工時候產生的各種實時數據以及人工錄入的數據。本次的采集對象是西門子 828D 數控系統里面的數據。自動采集程序采用Python語言進行編寫，Python語言是一門“膠水”語言，有許多可供用戶選擇的工具包［31］。開發工具包則使用開源的OpcUa工具包，通過西門子828D數控系統所支持 OPC UA 協議來獲取各種實時數據，并通過 TCP/IP 協議進行傳輸。通過西門子 828D 數控系統提供的標準的 OPC UA 數據接口進行數據采集，最后將處理后的數據按一定格式存儲到MySQL數據庫中或者使用RabbitMQ消息隊列直接傳輸到數據處理層供前端頁面進行調用。數據采集流程如圖2-5 所示。

圖 2-5 數據采集流程圖

Figure 2-5 Data collection flow diagram )

通過上述的介紹可以發現，本系統經過 OPC UA 協議采集機床的動態數據和靜態數據，經過底層的數據處理模塊將數據儲存到 MySQL 當中，或是直接通過寫入消息隊列中供數據處理層調用。當使用者通過 URL 地址訪問 Web 界面，向數據處理層發起請求，后臺通過數據接口或者消息隊列獲取數據庫當中相應的數據或者采集的實時數據，最終將數據以 JSON 格式返回到 Web 界面當中，通過各種圖形圖表直觀的展示機床的當前狀態。整個系統的數據流向如圖 2-6 所示。

圖 2-6 數據流向圖

Figure 2-6 Data flow diagram)

2.4系統開發環境

根據系統功能要求以及系統組成架構，為了完成本次開發。本次采用的主要軟

硬件型號如表2-1、 2-2所示：

表 2-1 系統軟件

Table 2-1 System software)

名稱具體項備注

操作系統 Win10

編程語言 Python3.7 、JavaScript 1.8.5 Python編寫程序；JavaScript用于前后端數據交

HTML、CSS 互；HTML、CSS用于網頁的開發

數據庫 MySQL5.7 存儲采集到的靜態數據和動態數據

Web 框架 Django2.1 為外界提供 Web 服務

消息隊列 RabbitMQ3.6.14 提供消息隊列服務，傳遞采集數據

IDE Pycharm2019 集成開發環境，編寫程序快速、高效

表 2-2 系統硬件

Table 2-2 System hardware)

名稱具體項備注

服務器 Win10 系統

工控機倍福 TwinCAT 2 訪問信息管理模塊，人工錄入數據

加工中心 VMC655H 安裝西門子828D數控系統

監控大屏 75 寸顯示器作為實時監控顯示屏幕

2.5本章小結

通過上述的介紹，本章主要完成了以下工作：

(1)分析了當前企業生產的狀況以及企業的實際需求，并提出當前系統需要滿足的功能。

(2)完成了可視化系統的框架的設計，并詳細的闡述了當前系統各個組成部分的功能、原理和實現方法。

(3)闡述系統整個數據的流向，明確了數據各個具體的使用環節。

(4)根據系統功能要求設計了系統組成架構，明確了系統的軟，硬件組成。

3西門子 828D 數控系統數據采集與存儲

西門子 828D 數控系統是西門子的全數字化中高端數控系統，該系統具有模塊化、開放性的特點，且該系統支持最新的OPC UA規范。OPC UA是一種標準的工業接口規范，同時也是規范的實施數據中間件開發的框架，具備功能上的完整性、易用性、可擴展性，也具有跨平臺、支持多種開發語言的特點，通過標準的數據接口就可以對其進行數據采集［32］。本章主要研究了西門子機床自身的OPC UA，并開發了符合 OPC UA 規范的客戶端，利用該客戶端獲取變量的信息，通過 Python 開發的程序采集 OPC UA 服務器當中的數據，并且將采集到的數據處理后存儲到 MySQL 數據庫當中。

3.1西門子828D數控系統OPC UA原理

3.1.1OPC UA 的架構

OPC UA 作為一種新的數據傳輸架構，將傳統的 OPC 規范進行了有效的集成與改進。其靈活性、安全性、擴展性相對于傳統的 OPC 技術有了大大的提高，其目的是為了滿足工業 4.0 的需求，同時給行業的軟、硬件供應商和集成方案解決商提供了一種新的思路。由于OPC UA不再依賴于Windows系統，現在只需要滿足OPC UA 新的規范，就能在諸如蘋果的 macOS 操作系統、 Linux 操作系統、各種嵌入式系統中開發出自己的 OPC UA 客戶端與服務器。

西門子 828D 數控系統的 OPC UA 為用戶提供了統一的地址空間和服務模型，解決了以往同一系統的數據不能同時被訪問的難題。同時改進了原來 OPC 信息傳輸的弊端，可以通過管理員授權的單一端口進行數據的訪問，減少了因為防火墻原因訪問失敗的問題。同時西門子 828D 數控系統的 OPC UA 允許數據按不同格式表示，允許開發者自定義變量，這極大方便了對數據的獲取。西門子 828D 數控系統 OPC UA 采用了基于 C/S 網絡架構的設計模式。其中某個設備的 OPC UA 服務器可以被一個或者多個UPC UA客戶端訪問。同時也可以通過OPC UA隧道技術穿透防火墻接入互聯網，在通過 OPC UA 客戶端的進行訪問［33-37］。其技術框架如圖 3-1 所示。

圖 3-1 OPC UA 技術框架

Figure 3-1 OPC UA Technical framework)

3.1.2OPC UA 的變量

本次使用的是西門子OPERATE V4.7版本的OPC UA服務器，該服務器將報警服務器和數據提供服務器整合到一起，給外界提供唯一的一個OPC UA服務器供其調用。根據西門子提供的《西門子828D NC變量和接口信號》可知，西門子828D 數控系統的OPC UA服務器所提供的系統變量如表3-1所示。

表 3-1 系統變量

Table 3-1 System variable)

變量地址變量名稱

/Axis 軸變量

/Bag 方式組變量

/Ch annel 通道變量

/DriveVisa 驅動變量

/GUD GUD 變量

/Hmi Hmi 變量

/Random Plc 變量

/Methods 通過方法讀入變量表中不包含的變量

/Nck Nck 變量

/Plc Plc 變量

/SEA 通用設定數據

通道設定數據

刀具變量

本次采集的機床實時數據來自/Channel地址中的通道變量，報警實時數據來自 /Nck 地址變量，刀具數據來自 /Tool 地址變量。

3.1.3OPC UA 的配置

西門子828D數控系統自身支持最新的OPC UA，在使用西門子828D數控系統的 OPC UA 之前，首先需要購買西門子的授權服務，開通此項功能。然后通過機床的 HMI 面板配置 OPC UA 的服務。主要配置過程如圖 3-2、 3-3 所示：

(1)注冊系統選項，啟動 OPC UA 服務器。

圖 3-2 啟動 OPC UA 服務器

Figure 3-2 Start the OPC UA server)

(2)設置OPC UA服務器，創建管理員及密碼并激活OPCUA服務器。

圖 3-3 初始化配置信息

Figure 3-3 Initial configuration information)

完成上述操作以后，確保HMI面板上的系統時間正確，重啟系統，激活OPC UA 服務器完成對OPC UA服務的設置。

3.2基于OPC UA的數據采集

西門子 828D 數控系統具有“簡單、好用、開放”的特點。通過向西門子購買 OPC UA服務器的授權之后，就可以開發相應的符合OPC UA規范的客戶端程序，并可以通過西門子828D數控系統的OPC UA服務器對外提供的數據接口訪問系統的數據。本小節主要介紹如何開發OPC UA客戶端實現快速獲取OPC UA瀏覽器所支持的變量，以及方便的獲取各變量的屬性以及當前值。通過采用Python編程語言實現了對西門子828D數控系統的數據采集。

3.2.1OPC UA 客戶端設計

OPC UA服務器負責管理自身的數據和處理邏輯，并通過OPC UA通訊協議對 UPC UA客戶端提供相應的服務。當OPC UA客戶端向OPC UA服務器發送請求時，服務器接收請求返回響應，這種C/S網絡架構的通信形式可以實現安全、快速、穩定、加密的數據交換，同時減少數據在傳輸的過程中的丟包現象，節約了網絡帶寬，保證傳輸不受到環境和網絡的過大影響［38］。

3.2.1.1OPC UA客戶端功能開發

選定Pycharm2019開發環境，開發使用的是Python語言，使用的工具包是GitHub 開源的OpcUa工具包，可視化界面基于Python的PyQT5圖形庫編寫。主程序的開

發流程圖如圖 3-4 所示：

圖 3-4 主程序流程示意圖

(Figure 3-4 Schematic diagram of the main program flow)

主程序開發關鍵技術如下：

(1)開發環境配置

以 Python 為開發語言，集成開發環境選擇 JetBrains 軟件公司出品的 PyCharm2019，使用OpcUa工具包連接西門子828D數控系統內置OPC UA服務器，使用 QtDesigner 來制作 UI 界面，最終使用 PyInstaller 將 Python 文件打包成exe文件。具體開發工具如表3-2所示：

表 3-2 客戶端開發工具

(Table 3-2 Client development tools)

工具名稱版本號

Python 3.7

PyCharm 2019

PyInstaller 3.4

PyQt5 5.11.3

OpcUa 0.98.7

QtDesigner 3.1

(2)初始化OPC UA的協議棧

初始化OPC UA協議棧的目的就是在連接到OPC UA服務器之前，與OPC UA 服務器建立信息交流的通道，該通道是獨立于協議之外的通道，用于數據交換的安全性。在 Python 編程的中具體表現在導入 OpcUa 工具包的時候，該工具包有一個名為―init__.py文件初始文件。

(3)連接OPC UA的服務器

通過 OpcUa 工具包的 Connect 函數連接到 OPC UA 服務器，通過 Disconnect 函數斷開與OPC UA服務器的連接。

(4)遍歷獲取節點屬性

當連接到 OPC UA 服務器的時候，通過 get_node 方法獲取節點對象，通過 get_attributes方法獲取node節點的屬性及值，本次開發的OPC UA客戶端主要提供的功能如表 3-3 所示：

表 3-3 客戶端主要功能

Table 3-3 Main functions of the client)

功能描述

連接連接OPC UA服務器

斷開斷開 OPC UA 服務器

瀏覽瀏覽 OPC UA 的所有變量

讀讀取該節點的所有屬性

訂閱訂閱當前節點

監測顯示當前節點值的變化

3.2.1.2OPC UA客戶端界面設計

界面采用 QtDesigner 進行編寫，將編寫完畢的 UI 文件使用 pyuic 工具轉換為 Python 文件代碼，編寫相關控件的邏輯函數，建立界面與程序的聯系。最終使用 PyInstaller工具將其打包為exe文件。程序的主界面原型如圖3-5所示：

圖 3-5 主界面原型圖

（Figure 3-5 Main interface prototype）

OPC UA 客戶端界面主要由五個窗口組成：

（1） OPC UA 連接窗口

在連接欄窗口中，通過顯式的輸入當前OPC UA的URL地址，同時將用戶名和密碼通過參數的形式進行傳遞。點擊連接按鈕，通過 OPC UA 客戶端程序的解析，將各個參數與OPC UA服務器進行匹配，如通過參數正確即可成功連接OPCUA服務器。同時也可點擊斷開按鈕，斷開與OPC UA服務器的連接。

（2） OPC UA變量地址瀏覽窗口

在變量地址瀏覽窗口中，當輸入正確的 URL 地址連接上 OPC UA 服務器時，該瀏覽框即可顯示當前 OPC UA 服務器所有的系統變量，用戶或者開發人員可以通過對照《西門子828D NC變量和接口信號》手冊從變量地址瀏覽窗口中獲取變量的具體地址、變量名稱、變量瀏覽名、節點的ID值。

（3） OPC UA變量屬性瀏覽窗口在變量屬性瀏覽窗口中，當用戶點擊左側的具體變量時，可以在該窗口查看變

量的具體屬性值，例如變量的屬性、變量值、變量類型。

（4） OPC UA變量訂閱窗口在變量訂閱窗口中，當用戶訂閱某個變量時，就可以在該窗口查看訂閱的變量

的當前的狀態。

（5） OPC UA變量監測窗口在變量監測窗口中，當用戶訂閱某個變量時，可通過該窗口查看當前訂閱變量

當前值的變化趨勢。

3.2.2數據采集的實現

本次設計的基于B/S架構的828D數控機床信息可視化平臺的數據主要來源有兩部分，來自機床的實時數據與人工錄入的靜態數據。由于人工錄入數據比較簡單，這里主要講解關于使用Python程序自動采集機床的實時數據。

機床的實時數據主要是指通過OPC UA協議實時的采集數控機床當前的加工過程數據。采集的數據一部分保存到 MySQL 數據庫中，一部分通過消息隊列傳輸到數據處理層供前端頁面使用。

3.2.2.1數據采集的具體變量

查詢《西門子828D OPC UA配置手冊》可知，OPC UA服務器支持監控項的最大數量的計算公式如式(3-1)所示。

MN = — (3-1)

UES

式中：

MN(Max Number)：最大采樣數據條目數

SL(System Load)：系統負載

UES (Update Every Second)：每秒更新

對OPC UA服務器進行數據采集的采樣速率有開發者自定義，通過每秒更新公式可得知OPC UA服務器變量每秒更新的數目，每秒更新計算公式如式(3-2)所示。

UES = — (3-2)

式中：

SR (Sampling Rate)：采樣速率

西門子 828D 數控系統的系統負載為 500 條目/秒，本次預設的采樣速率為 1 秒采集一次，根據上述公式可以計算出OPC UA服務器支持監控項的最大數據量為 500 個。本次監控的變量數目遠遠小于 500，故采集變量的數目滿足 OPC UA 服務器的要求。

通過OPC UA客戶端并對照《西門子828D NC變量和接口信號》可以精確的獲取變量的地址，同時將監控的變量進行分類的統計，具體包括主軸相關變量地址表、 XYZ 軸坐標相關變量地址表、程序相關變量地址表、報警信息變量地址表，各變量地址具體信息如表3-4~3-7 所示。

表 3-4 主軸相關變量地址表

(Table 3-4 Spindle related variable address Table)

變量名稱變量地址

主軸轉速 ns=2;s=/Channel/Spindle/actSpeed

主軸轉速倍率主軸負載率主軸進給速度主軸進給倍率當前刀具號主軸電流 ns=2;s=/Channel/Spindle/speedOvr

ns=2;s=/Channel/Spindle/driveLoad ns=2;s=/Channel/MachineAxis/actFeedRate ns=2;s=/Channel/GeometricAxis/feedRateOvr ns=2;s=/Channel/State/acMeasTNumber ns=2;s=/ChannelMachineAxis/aaCurr

表 3-5 XYZ 軸坐標相關變量地址表

(Table 3-5 XYZ axis coordinate related variable address Ta ble)

變量名稱變量地址

刀具 X 坐標位置 ns=2;s=/Channel/MachineAxis/actToolBasePos[u1,1]

刀具 Y 坐標位置 ns=2;s=/Channel/MachineAxis/actToolBasePos[u1,2]

刀具 Z 坐標位置 ns=2;s=/Channel/MachineAxis/actToolBasePos[u1,3]

X 軸剩余加工量 ns=2;s=/Channel/GeometricAxis/actDistToGoEns[u1,1]

Y 軸剩余加工量 ns=2;s=/Channel/GeometricAxis/actDistToGoEns[u1,2]

Z 軸剩余加工量 ns=2;s=/Channel/GeometricAxis/actDistToGoEns[u1,3]

(Table 表 3-6 程序相關變量地址表

3-6 Program related variable address Table)

變量名稱變量地址

正在運行程序名 /Channel/ProgramInfo/progName

當前程序段的編號 /Channel/ProgramInfo/actLineNumber

當前程序狀態 /Channel/Spindle/actSpeed

當前主運行程序段 /Channel/ProgramInfo/actBlock

程序運行時間估算 /Channel/State/acPRTimeM

從程序段開始的時間 /Channel/State/acTime

當前運行刀具號 /Channel/State/acMeasTNumber

表 3-7 報警信息變量地址表

(Table 3-7 Alarm information variable address Table)

變量名稱變量地址

報警數量 /Nck/State/numAlarms

報警編號 /Nck/SequencedAlarms/alarmNo

報警時間 /Nck/SequencedAlarms/timeBCD

3.2.2.2基于 Python 的數據采集

該采集程序采用的開發包與開發 OPC UA 的客戶端的同為 GitHub 開源的基于 Python的OpcUa工具包。首先初始化OPC UA協議棧后，客戶端發出請求與OPC UA 服務器建立連接，之后程序的任何請求都會通過此連接進行傳輸。數據采集程序流程圖如圖 3-6 所示。

圖 3-6 數據采集程序流程圖

Figure 3-6 Data collection program flow diagram)

數據采集的核心流程是通過對機床當前狀態進行判斷，當機床當前狀態發生變化的時候，調用不同組的對應采集函數對組中各個監測的變量項進行數據采集，其中采集的數據可以在壓縮后直接存儲到 MySQL 數據庫中為數據統計分析提供數據支撐，也可以直接傳輸到消息隊列中以供調用。

3.3西門子828D數控系統數據存儲

本節主要探討了如何儲存西門子 828D 數控系統采集數據，主要包括數據庫設計與具體的實現方案。根據系統的要求，對數據庫設計所遇見的問題進行了具體的分析，并提出了三個關鍵的問題：如何建立不同數據表的結構、如何實現存儲海量的實時加工數據、如何降低數據庫的負載。與此同時，對以上三個問題都提出了具體的解決措施。

3.3.1關鍵問題分析

在軟件開發中，數據庫的設計是非常重要的一項工作。優秀的數據庫設計，可以大大的提高整個系統的運行效率，保證該信息可視化平臺的穩定運行。 MySQL 數據庫作為一款開源且性能優異的關系型數據庫，對事務和外鍵等支持非常好，在 Web開發中占據了巨大的份額陽］。此次采用MySQL的主要原因有：MySQL數據庫和 Python 語言以及 Django 框架的兼容性很高，有許多開源的工具包可供開發者使用，方便整個項目的開發；MySQL數據庫支持多個客戶機的同時訪問，方便后期采集數據在不同用戶之間的共享；MySQL擁有優異的讀寫性能，數據表的數據存儲量大，滿足本次系統的要求。但是在整個系統中數據的儲存以及管理需要面對以下的三個問題：第一，如何在單表中存儲海量的實時加工數據，通過 3.2.2 小節的分析可以知道本次采集系統預設的采集的頻率是每秒采集一次數據，經過計算，僅僅是變量值為數字量的采集變量，當數控機床工作20小時的數據采集量就高達數 GB，如果將所有的實時數據存入 MySQL 數據庫，會給數據庫服務器造成巨大的存儲壓力，所以如何存儲海量的實時加工數據，如何正確采用數據壓縮算法，就顯得格外的重要；第二，如何正確的劃分各個數據表之間的關系，建立正確主外鍵，使得數據查詢的效率更高，這對于提高整個系統的響應速度非常重要，因此應正確分析各個實體之間的關系，建立實體關系模型；第三，本次開發的信息可視化平臺向后臺數據庫讀寫請求操作很頻繁，如果所有的操作都在一個數據庫就會給數據庫帶來很大的讀寫壓力，所以設計讀寫分離的數據庫架構，將寫操作放在主數據庫中，將讀操作放在從數據庫當中，從而使得數據庫的負載均勻，降低數據庫的負載壓力。

3.3.2數據庫結構的設計

通過上一小節的分析可知，數控機床工作20小時的數據采集量就達數GB，也就意味著數據庫單表的數據量大小隨著時間線性增加。當需要對數據進行統計分析的時候，由于單表的數據量巨大，就會造成查詢效率降低，影響整個系統的運行速度，從而給用戶造成不好的體驗。同時將讀寫操作放在同一個數據庫進行，造成數據庫負載壓力過大，查詢緩慢。基于此，本次的數據庫設計在數據庫內部對實時數據表采用水平分區的方式進行設計。數據表分區示意圖如圖 3-7 所示。

實時數據表R 表3 | 表4

圖 3-7 數據庫分區示意圖

Figure 3-7 Database partition diagram)

對用戶來說，分區表是一個獨立的邏輯表，但是底層由多個物理的子表組成。通過設置分區列并以時間范圍為參照標準，數據按照每一個月為尺度進行分區。從而將單表的數據以趨于平均的方式存儲在多個邏輯表中，從而邏輯上降低了單個表的數據存儲大小，提高了 MySQL的性能。

對于數據庫的讀操作是共享鎖并不會阻塞其他讀操作，但寫操作會阻塞其他所有操作。因此讀的效率一般是遠高于寫的效率的，當進行數據采集存儲實時數據的時候都是寫操作，此時寫操作會阻塞大量的讀，如果此時數據量大，甚至會造成數據庫崩潰，因此采用數據庫讀寫分離的策略解決這個問題，同時由于從庫會將主庫的數據進行實時的復制，所以也實現了數據庫的備份操作。數據庫讀寫分離流程如圖3-8 所示。

圖 3-8 讀寫分離流程圖

Figure 3-8 Read and write separation flowchart)

通過上圖可以看出，當主庫中的數據發生變化的時候，此時通過讀取主庫中的二進制日志的改變記錄，然后將從庫的日志重新執行，從而使得從數據庫的數據與主數據庫保持一致［40-42］。

3.3.3數據庫表的設計

首先歸納出需要進行存儲的數據，正確劃分各個實體之間的關系，確保實體之

間的關系明確，無重復。根據分析，系統各實體之間的關系如圖3-9 所示。

圖 3-9 系統實體關系模型

Figure 3-9 System entity relationship model )

通過3.3.2 小節對數據庫結構的設計，可以極大地提高數據庫的存儲性能。根據系統的實體關系模型圖，將采集的實時數據劃分為4 部分：機床加工的實時過程數據、機床加工的程序信息、機床的報警信息、機床開關機信息。分別為其建立數據表，其中 Machine_real_data 數據表用來存儲機床加工的實時過程數據， Machine_program_data 數據表用來存儲機床加工實時程序信息， Machine_alarm_data 數據表用來存儲機床實時的報警信息， Machine_onoff_data 數據表用來存儲機床開關機信息，各數據表的結構如表3-8~ 3-11 所示。

表 3-8 Machine_real_data 數據表結構

Table 3-8 Machine real data data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段 Id 否 Pk

Machine_num Varchar 機床編號否 Fk

Spindle_speed Float 主軸轉速否

Spindle_override Float 主軸倍率否

Spindle_load Float 主軸負載否

Spindle current Float 主軸電流否

Feed_ speed Float 進給速度否

Feed_ override Float 進給負載否

X_location Float X 軸當前坐標否

Y_location Float Y 軸當前坐標否

Z_location Float Z 軸當前坐標否

X_move Float X 軸剩余移動量否

Y_move Float Y 軸剩余移動量否

Z_move Float Z 軸剩余移動量否

Current_time Datatime 當期時間否

表 3-9 Machine_porgram _data 數據表結構

Table 3-9 Machine porgram data data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Machine_num Varchar 機床編號否 Fk

Program_name Varchar 程序名否

Program_num Int 程序段號否

Program_content Varchar 程序內容否

Machine_state Varchar 機床當前狀態否

Tool_num Varchar 當前刀具號否

表 3-10 Machine_alarm_data 數據表結構

Table 3-10 Machine alarm data data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Machine_num Varchar 機床編號否 Fk

Alarm_count Int 報警數量否

Alarm_num Int 報警編號否

Current_ontime Datatime 報警開始時間否

Current_offtime Datatime 報警結束時間否

表 3-11 Machine_onoff _data 數據表結構

Table 3-11 Machine onoff data data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Machine_num Varchar 機床編號否 Fk

On_time Datatime 開機時間否

Off time Datatime 關機時間否

3.4 本章小結

通過上述介紹，本章主要完成了以下工作：

（1）具體分析了西門子828D數控系統的OPC UA的結構、功能、變量以及如何配置，為數據采集做好基礎工作。

（2）開發符合規范的OPC UA客戶端瀏覽西門子828D數控系統的OPC UA服務器的變量，通過Python編寫數據采集程序，通過OPC UA實現數控機床實時的數據采集。

（3）使用MySQL數據將采集的數據進行存儲，在數據庫表的基礎上利用數據表分區功能減少單表的數據存儲量，同時設計了數據庫的讀寫分離的架構，避免了因數據庫寫操作而阻塞數據庫的其他操作，從而提高了數據庫的性能。

4Web 服務器層功能模塊設計

數據的采集是完成整個系統的第一步。利用不同的算法或者不同的處理邏輯對數據進行有效的分析，從而得出不同的結論，是開發此系統目的之一。本章就此問題探討了使用SDT (旋轉門)算法對海量的實時過程數據進行壓縮，然后通過OEE 將數據進行有效的分析得出結果。利用RabbitMQ技術和WebSocket技術，直接將采集到的實時數據進行前端頁面的顯示。最后根據需求，詳細闡述了開發數控機床信息管理模塊的過程。

4.1基于 OEE 的數據分析模塊

設備綜合效率OEE是衡量生產效率的黃金標準，它確定了生產時間中真正生產效率的百分比。 OEE 高意味著生產制造速度快，沒有停頓時間［43］。計算 OEE 被用作衡量設備的綜合利用性能。通過計算OEE和潛在損失，可以獲得如何系統地改進制造過程的重要結論。OEE也是確定損失、基準進度和提高制造設備生產率的最佳單一指標［44］。

4.1.1設備綜合效率 OEE

設備綜合效率 OEE 是主要是由三個部分組成包括設備時間開動率、性能開動率、合格品率。其中設備時間開動率主要用來評價設備因為某種原因而無法開動，從而帶來的損失；性能開動率主要用來考慮任何導致生產不能以最大速度運行的因素；合格品率主要用來衡量加工后沒有達到質量的產品［切。OEE的計算方法為三個指標的乘積，其計算公式為：

OEE = ETOR x PS x PR (4-1)

式中：

ETOR (Equipment time operating rate)：設備時間開動率

PS (Performance Start Rate)：性能開動率

PR( Pass Rate)：合格率

OT (Operation Time)：操作時間

PWT (Planned Working Time):計劃工作時間

TPC (Theoretical Processing Cycle):理論加工周期

APT(Actual Production Time)：實際生產時間

QP(Qualified Product)：合格品

TO(Total Output)：總產量

4.1.2OEE 在本系統的應用

4.1.2.1 數控機床狀態定義

通過OPC UA對西門子828D數控系統進行實時數據采集時，由3.2.2.2小節的分析可知當數控機床發生變化的時候，OPC UA服務器的相關變量會發生變化，此時程序會進行自動的采集數據，并對數據進行基本的處理，并通過依據數據將數控機床的狀態分為 5 種，如表 4-1 所示。

表 4-1 機床狀態

Table 4-1 Machine status)

機床狀態說明機床狀態定義

機床開機，系統通電，電源指示燈亮起開機

機床完成開機，準備運行加工程序待機

機床啟動加工，數控程序開始運行加工

機床換刀、上下料、程序上傳下載轉換

機床檢修、計劃停機、能源中斷停機

機床關機，系統斷電，電源指示燈熄滅關機

通過機床狀態定義，本次將各狀態分別與對應的時間段進行匹配。例如開機狀態即為開機時間，關機狀態即為關機時間，待機狀態則為待機時間，加工狀態即為加工時間，轉換狀態即為轉換時間，停機狀態即為停機時間。通過對上述數控機床狀態的定義，為接下來具體計算機床 OEE 做好理論支撐。

4.1.2.2OEE 基礎數據

通過 4.1.2.1小節對數控機床狀態的定義可知。影響數控機床的綜合效率的因素有很多，在本次開發的系統中，應具體分析這些影響因素。通過與管理人員，操作人員實際溝通并結合上一小節對數控機床狀態的定義分析，得出主要影響數控機床的綜合效率的因素有以下的幾種：機床檢修、計劃停機、停電、待機等因素造成的停機時間。

為了更好的計算數控機床的設備綜合效率，便于 OEE 基礎數據獲取。故將各種基礎數據儲存在如下數據表當中，具體數據如表 4-2 所示。

表 4-2 OEE 基礎數據表結構

(Table 4-2 OEE basic data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Machine_num Varchar 機床編號否 Fk

Open_time Float 通電時間否

Run_time Float 運行時間否

Wait_time Float 待機時間否

Maintenance Float 維修時間否

Planned_shutdown Float 計劃停機否

Energy_interruption Float 能源中斷否

Qualified Int 合格品數量否

Unqualified Int 不合格品數量否

分析可知，由于該機床為批量加工同一種工件剎車盤，且有機械手自動上下料，故由此可以認為每次單個零件加工時的準備時間是固定的。而維修時間、計劃停機時間、能源中斷時間都可以從報表中獲取，其他的機床狀態的定義的時間均可以通過 OPC UA 進行采集得到。

獲取該數控機床某一周的運行情況并進行匯總，耗時如表4-3 所示：

表 4-3 機床運行數據統計

Table 4-3 Machine tool operation data statistics)

耗時項耗時（h）

通電時間 84

運行時間 60.7

待機時間 5.7

維修時間 3.6

能源中斷 0

計劃停機時間 14

理論加工周期 0.25

合格品數 174 個

不合格品數 6個

4.1.2.3OEE參數計算

根據4.1.1小節對OEE公式的介紹，以及通過本系統采集到數據，可以按照OEE 的計算方式進行編程計算，獲取OEE核心的三個指標。在本系統中要計算設備時間

開動率ETOR需要獲取操作時間OT和計劃工作時間PWT，系統中操作時間和計劃

工作時間計算方法如式(4-5)(4-6)所示。

OT =PWT -DT (4-5)

PWT = AT (4-6)

式中：

DT (Down Time)：停機時間

AT (All Time)：總時間

計算性能開動率PS，首先需要先獲取到理論加工周期TPC和實際生產時間APT，其中實際生產時間APT需要從MES中獲取或者操作工人的中記錄中獲取本系統的理論加工周期計算方法如式(4-7)所示。

TPC = NUM x ET (4-7)

式中：

NUM (Number)：工作時間內加工的工件數

ET (Estimated Time)：預計加工時間

合格率PR的計算方式較為簡單，只需要獲取當前加工時間段內，加工工件的合格品數量 QP 和加工的工件總數量 TO。

通過4.1.1節與本節對OEE公式的定義并結合4.122小節獲取的OEE計算的基礎數據，就可以計算出該數控機床的OEE，其中：

設備時間開動率：ETOR=53.7/84X 100% = 63.93%

性能開動率：PS=0.25X (156+6)/53.7x 100%=74.13%

合格品率： PR=174/180=96.7%

設備綜合效率：OEE=63.93%X74.13%x96.7%=45.83%

通過具體分析OEE的各項指標，可以看出設備時間開動率需要改善，可以通過

減少故障維修的時間以及計劃停機時間，同時減少加工前的準備時間從而減少待機

時間，最終實現設備時間開動率的提高。顯然，通過分析OEE可以找出影響加工效率的環節，從而對企業產生積極的作用。

4.2基于改進的SDT算法數據壓縮模塊

在實時監控系統中，過程數據是進行故障診斷、工藝參數優化、數據挖掘以及

數據分析的重要的數據來源。根據3.3.1 小節分析的可知，數控機床工作 20 個小時的產生的數據量高達數 GB。若將其全部存入數據庫，就會造成極大的存儲負擔。

本次采集的數控機床實時數據具有典型的工業數據的特點：在某段時間內，數

據波動小，變化趨勢平穩。而旋轉門算法是一種通過使用線性擬合對連續的過程數據進行壓縮的算法，主要適用于數據波動范圍小，且連續的整型、浮點型數據的壓縮。其中旋轉門算法具有壓縮效率高、壓縮比高、壓縮誤差可控制的特點，現已廣泛用于對實時數據的壓縮［46］。因此需要在數據存入到數據庫之前，結合旋轉門算法

~ 31

進行數據處理，通過數據壓縮，以減少數據存儲空間的浪費，提高存儲的效率。

4.2.1SDT 算法原理

對于SDT算法，其核心的原理就是利用起點和終點確定的直線來代替其他的處于誤差范圍內的數據點。當需要保存數據點的時候，會將當前數據點和上一個數據點以及各自對應的時間點的數值大小進行保存，同時當前保存的數據點作為下一個壓縮區間的起點［47］。SDT算法原理如圖4-1所示。

t0 t1 t2 t3 t4 t5 t

時間

圖 4-1 SDT 算法原理圖

(Figure 4-1 SDT algorithm principle diagram )

圖4-1中的a，b，c，d，e，f均為需要保存的數據點，AE為容差(即門的寬度)。其中a點為壓縮的第一個數據點，根據容差的大小在a點上方和下方構建旋轉門的兩個支點A1和A2,當只有1個數據點a的時候，此時門是關著的。隨著數據點的增加，此時門會逐漸的打開且在一段時間內門一旦打開就不會關閉。當兩扇門的內角和小于180°的時候，旋轉繼續進行。當兩扇門的內角和大于或等于180°的時候，此時將保存當前的數據點的前一個數據點以及時間。如圖 4-1 所示，當旋轉至e點的時候，此時兩門不滿足繼續旋轉的條件，故將d點以及當前時間點進行存儲，并且將d點作為旋轉門的當前起點，對下個數據點進行判斷。重復以上流程直到將所有的數據進行壓縮歸檔［48-50］。

4.2.2SDT 算法評價指標

一般來說，衡量數據壓縮的性能的指標包括壓縮比CR (Compression Ratio)和壓縮誤差CE (Compression Error)。其中壓縮比CR用來表示壓縮前的數據點的個數和壓縮后的數據點的個數的比值，值越小表示壓縮的性能越高。壓縮比 CR 的計算公式如式(4-8)所示：

CR = n (4-8)

式中：n為壓縮前的數據點的個數；m表示壓縮后的數據點的個數且n < m。

這里使用平均絕對誤差來定義壓縮誤差CE，平均絕對誤差常用于測量實驗數據集的預測值和實際值之間的平均絕對誤差。故通過計算壓縮誤差 CE 可以得知壓縮前后數據之間的逼近的程度，壓縮誤差 CE 越小表示壓縮越精確。壓縮誤差 CE 的計算公式如式(4-9) 所示：

CE =-工比-7；| (4-9)

ni=0

式中：n為壓縮前的數據點的個數；y為壓縮前的數據點的值；y；為壓縮后的數據點經解壓后的數據點的值。

從4.2.1小節關于SDT算法的原理描述中可以得知，容差hE是整個SDT算法唯一可以進行人工干預的參數，容差AE大小合理的選擇決定了壓縮比和壓縮誤差最終值的大小，也是保證數據壓縮效果的關鍵因素。當容差hE偏大時，壓縮比也隨之提高，但是會增加壓縮誤差，造成壓縮數據與原始數據之間的偏差較大。當容差hE 偏小時，會保留較多的原始數據，得不到到良好的壓縮效果。因此為了獲得較好的壓縮效果，提高壓縮的性能，就需要動態的調整容差，已獲得更高的壓縮比和更低的壓縮誤差。

4.2.3SDT 改進算法

為了降低壓縮的誤差，提高壓縮的精度。本次改進的 SDT 算法使用壓縮誤差 CE 來衡量壓縮前后數據失真的程度，通過求解原始數據的壓縮誤差與期望壓縮誤差的比值以達到動態的調整容差hE的目的，進而獲得更好的壓縮效果。

首先，在數據壓縮之前自定義期望的壓縮誤差CE，利用改進的旋轉門算法對原始數據進行壓縮。將壓縮過后的數據進行解壓，求出其壓縮誤差CE，計算該壓縮誤差與自定義的壓縮誤差之間的比值b，然后通過比值b對容差進行實時的調整，已達到降低壓縮的誤差的目的。同時對上述流程不斷的進行迭代求解，通過判斷壓縮數據的壓縮誤差CE是否達到要求，動態調整容差h^E，使得被壓縮的數據達到期望的壓縮誤差，提高壓縮的整體性能。

(1) 改進的 SDT 算法的流程

改進的SDT算法的流程圖如圖4-2所示。

圖 4-2 改進的 SDT 算法流程圖

Figure 4-2 Improved SDT algorithm flow diagram)

(2)SDT 改進算法步驟

設容差為A£，其范圍為AE"in < AE < E ;T為壓縮區間的最大時間間隔；e表示自定義的期望壓縮誤差；CE表示壓縮后的解壓縮數據的壓縮誤差。

算法的具體步驟如下：

步驟1:首先初始化SDT改進算法的參數，設定AE"in初始值為0.8，AE^初始 min max

值為 0.2，即 AE =(AEmax + AEmin)/2，誤差 e=0.5。

步驟2:設定壓縮區間時間間隔為T，獲取時間間隔為T的待壓縮數據，將其讀入緩存當中進行下一步的SDT算法壓縮。

步驟 3：對待壓縮數據進行 SDT 算法壓縮，首先計算最近保存的數據點到下一個數據點的兩扇旋轉門的斜率心和d,n„，重復該步驟計算下一數據點的兩扇旋轉門的斜率k”和knn，比較兩數據點的k”和konn，并且保留上門斜率較大值與下門斜率較小值。與此同時，如果上門斜率k””大于或等于下門斜率k””時，存儲上一數據點，并將當前數據點作為新的數據壓縮起始點。如果上門斜率k”小于下門斜率kdnnn，則該數據點將被丟棄。重復上述過程，直到所有的數據壓縮完畢，然后進行下一步驟的操作。

步驟4：等待壓縮數據壓縮完畢，將壓縮完畢的數據進行解壓縮。設壓縮前的數據為y,y,…，y”，解壓后的數據為y；,y：,…，y；，利用式4-2帶入數據，計算出數據壓縮前和數據壓縮后的壓縮誤差CE值。然后計算CE值與自定義的期望誤差e的比值b，然后進行下一步驟的操作。

步驟5 :通過步驟4得到的比值b對容差hE進行動態的調整。

(1)如果b> 1，則認為解壓后計算的壓縮誤差大于自定義的期望壓縮誤差。則令容差hE = hEb，同時應滿足hEn < hE < hEax。

(2)如果b < 1，則認為解壓后計算的壓縮誤差小于自定義的期望壓縮誤差。也即容差hE選擇合理，不需要進行調整。

步驟6:利用調整后的容差hE，返回步驟3對數據進行重新的壓縮，通過不斷地進行迭代計算，直到比值b < 1。保存壓縮后的數據，完成整個數據壓縮的過程。

4.3基于 RabbitMQ 和 WebSocket 的實時數據推送模塊

為了實時的掌握數控機床在加工過程的狀態，保證數控機床正常的運行。同時在機床出現停機時，能夠快速的定位故障位置，減少維修時間，提高維修效率，提升數控機床信息化管理水平，實時數據傳輸是保證上述功能實現的前提。在數控機床加工過程中，本系統通過 OPC UA 對數控機床進行實時數據采集，采集的實時數據一方面處理后直接存入MySQL數據庫，另一方面通過消息隊列RabbitMQ傳輸到數據處理模塊，然后經由 WebSocket 協議直接推送到前端進行實時的數據顯示。本小節在第3 章的數據采集的基礎上，設計了基于 JSON 的數據序列化格式，以及如何通過消息隊列 RabbitMQ 和 WebSocket 進行實時數據傳輸的架構。

4.3.1基于RabbitMQ的采集層數據傳輸

消息隊列MQ(message queuing)是一種服務于不同應用程序間的異步的通信方式。消息隊列可以駐留在內存或者磁盤上，直到隊列中的信息被取走為止，在消息隊列的模式當中，消息的產生者和消息的接收者分別定義為生產者和消費者［51］。隊列在信息傳遞之間有著諸多的優勢，比如：消息異步傳輸、應用間解耦、流量削峰。 (1)消息異步傳輸：通過使用消息隊列，不用等待隊列中數據是否已經被消費者獲取，就可以直接處理下一個任務，從而減少等待時間，實現高效的數據傳輸。 (2) 應用間解耦：生產者不需要考慮是哪一個消費者會消費當前的數據，只需要將產生的數據放入消息隊列當中。(3)流量削峰：在一些高并發的場景中，所有的請求都將寫入到消息隊列中，從而實時了請求的緩沖處理，極大地降低業務處理系統的壓力，同時以保證了數據處理的準確性［52］。

目前常用的消息隊列中間件有 Kafka、ActiveMQ、RabbitMQ、RocketMQ 等這幾種。 ActiveMQ 和 RabbitMQ 這兩種的消息隊列的數據吞吐量小于 Kafka 和 RocketMQ，適用于數據吞吐量一般的應用。常用消息隊列的特性如下表4-4所示。

表 4-4 不同消息隊列的特性

Table 4-4 Characteristics of different message queues)

名稱單機吞吐量時效性可用性可靠性功能支持

Kafka 10萬級毫秒級非常高可達 0 丟失功能較少，支持簡單的

MQ 功能

ActiveMQ 萬級毫秒級高可能丟失功能相比其他MQ極其

完備

RabbitMQ 萬級微妙級高可達 0 丟失功能完備，性能高，延遲低

RocketMQ 10 萬級毫秒級非常高可達 0 丟失功能完備，對分布式支持

好，擴展性強

本次開發的實時監測模塊主要考慮到實時性的問題，所以對延遲的要求較高，同時RabbitMQ與本次采用的Python語言的集成度較好，故采用RabbitMQ作為系統的消息隊列中間件。

4.3.1.1RabbitMQ 原理

高級消息隊列協議(advanced message queuing protocol，AMQP)是一個異步消息傳遞所使用的應用層協議規范，該協議不僅定義了一種網絡協議，同時也定義了服務端的服務和行為。基于Erlang編程語言開發的RabbitMQ是AMQP規范是標準實現，支持多種開發語言的。同時通過AMQP，RabbitMQ提供了靈活的消息路由、配置化的消息持久化以及跨數據中心通信［53］。

在 RabbitMQ 的結構當中，服務端主要是由交換機和隊列組成，而客戶端主要是由消費者和生產者組成。其中交換機主要接受生產者發送的消息，隊列用來臨時存放數據的容器。RabbitMQ的消息傳輸模式如圖4-3所示。

當生產者產生數據時，經由交換機轉存至相應的隊列中進行暫存，隨后隊列中數據遵循先進先出的原則被消費者依次進行消費［54］。

4.3.1.2RabbitMQ 數據傳輸

通過3.2.2.1小節的分析可知數據采集的具體變量包括了主軸相關變量、XYZ 軸相關變量、程序相關變量、報警信息相關變量這 4 類實時數據。對于數控機床實時數據的采集本次系統預設1s采集一次，為了解決實時數據傳輸頻率高和傳輸量大的問題，故采用 RabbitMQ 進行實時數據的傳輸，不僅可以保證數據傳輸的實時性，保證數據不丟失，而且由于數據在傳輸中并不會保存到文件或者數據庫中，也極大地減少了磁盤的頻繁讀寫［55］。

（1）數據傳輸系統設計

基于 RabbitMQ 的采集層數據傳輸系統，實現了進程間的相互通信。實時數據采集模塊作為生產者，后端數據處理模塊作為消費者。其中實時數據采集模塊用于連接OPC UA服務器，后端數據處理模塊將接收到的實時數據封裝為JSON的數據格式，便于數據在各個模塊之間的傳遞。基于 RabbitMQ 的采集層數據傳輸流向如圖 4-4 所示。

實時數據

圖 4-4 基于 RabbitMQ 的采集層數據流向圖

（Figure 4-4 Data flow chart of the acquisition layer based on RabbitMQ）

（2）系統實現

該數據傳輸系統采用 Python 作為開發語言，使用開源的 Pika 庫所提供 API 函數操作RabbitMQo在RabbitMQ的生產者端，首先將數據進行序列化成JSON格式, 然后使用 basic_publish 方法將數據放入隊列當中，實現發布消息的功能，而在 RabbitMQ 的消費者端程序一直處于阻塞模式，當數據到來時程序自動調用 basic_consume 方法接收對應的隊列消息，最后通過 callback 回調函數解析傳遞的數據，獲取數據。

4.3.2基于 WebSocket 的顯示層數據傳輸

在傳統 B/S 架構的實時監測中，為保證數據傳輸的實時性，通常使用 AJAX 輪詢技術由瀏覽器主動向后端詢問是否有實時數據［56］。該方式在方法的實現上比較簡單，但是缺陷也很明顯。（1 ）輪詢每隔一定時間，重復發送HTTP（Hyper Text Transfer Protocol，超文本傳輸協議）請求，加大服務器的壓力，浪費服務器資源。（2）輪詢在服務端沒有數據的時候，會產生大量的無效的請求，浪費帶寬。（3）輪詢中，由于請求是異步的，故響應結果無序，有可能造成數據的無效［57］。

基于HTML5標準的WebSocket通信機制，是建立在TCP （Transmission Control Protocol，傳輸控制協議）連接上實現全雙工通訊的協議。在基于B/S架構的前后端通信中，只需要瀏覽器和服務器完成一次握手，兩者之間就可以進行持久的連接，也可實現數據的雙向通信，實時性強延遲小。 WebSocket 占用的網絡帶寬少，控制開銷小，且幾乎所有的瀏覽器都支持［58, 59］。因此它是實現瀏覽器和服務器之間數據實時推送的理想通信機制。

4.3.2.1WebSocket 原理

WebSocket 是基于 TCP 傳輸協議，其本身屬于應用層協議。在于后端的連接當中，復用了 HTTP握手通道，但是WebSocket在建立長連接之后，實現了瀏覽器和服務器的雙向通信［60］，其交互的過程如圖 4-5 所示。

圖 4-5 WebSocket 瀏覽器與服務器交互過程

（Figure 4-5 WebSocket browser and server interaction process）

在連接開始時，由瀏覽器發起GET請求攜帶主要參數Upgrade: WebSocket。在取得服務器的響應后，服務器攜帶主要參數Switching: Protocols發送至瀏覽器，服務器返回狀態碼101，表示服務器同意連接協議轉換為WebSocket，此時瀏覽器與服務器就建立了 WebSocket 連接。

4.3.2.2WebSocket 數據傳輸

通過4.3.1小節可以得知，通過WebSocket傳輸到前端頁面進行顯示的數據主要是來自 RabbitMQ 中數據，如果使用 AJAX 輪詢的方式進行數據的獲取，浪費服務器資源與帶寬，故使用支持全雙工通信的 WebSocket 技術。同時考慮到數據量過大且 Django 框架需要使用 Redis 數據庫做緩存，故使用 Redis 數據庫的發布-訂閱功能進行數據的傳輸以及數據的緩存。

(1) 數據傳輸系統設計

基于 WebSocket 的前端頁面的實時數據推送系統，主要有四個部分組成包括：數據源、 Redis 數據庫、 WebSocket 推送服務、瀏覽器。當實時數據被暫存在 Redis 數據庫當中，此時通過其發布-訂閱功能就可以將數據通過 WebSocket 推送至前端進行顯示。基于 WebSocket 的顯示層數據流向如圖4-6 所示。

圖 4-6 基于 WebSocket 的顯示層數據流向圖

(Figure 4-6 Data flow diagram of display layer based on WebSocket)

(2) 系統實現

顯示層數據傳輸系統采用了開源的 Django-WebSocket-Redis 工具包。該工具包將 Redis 數據庫作為 Django 框架的緩存數據庫，同時使用了 Redis 數據庫的發布- 訂閱功能，實現數據自動通過 WebSocket 發送至前端頁面。在前端頁面中通過使用 WS4Redis.js 插件的 WS4Redis 方法向服務器發起連接請求，服務器接收請求與前端建立WebSocket連接。后端服務器通過publish_message方法進數據傳輸到Redis的指定的通道中，因為此時使用的是發布-訂閱模式，故前端使用 receive_message 回調函數即可實時的接收數據，然后解析數據將其渲染到頁面進行顯示。

4.4數控機床信息管理模塊

在傳統的車間生產制造中，與數控機床相關的數據大多是通過人工進行采集，同時使用紙質文件進行保存。在進行數據回溯時，不僅費時費力，而且存在數據錯誤與數據丟失的風險［61］。本文開發的數控機床信息管理模塊主要目的就是建立數控機床的基礎數據管理中心，將與數控機床相關的數據通過格式化后存到數據庫當中，實現信息集成與信息管理，提升車間的管理水平。同時為MES，ERP系統提供數據支撐。該數控機床信息管理模塊主要由設備基礎數據管理模塊、故障信息管理模塊、機床點檢信息管理模塊、備件信息管理模塊，后臺數據管理模塊等子模塊組成。

4.4.1后臺數據管理

在整個數控機床信息管理模塊當中，有些數據的改動是需要后臺數據管理員來完成，例如：增加系統用戶以及對用戶權限做管理。利用 Django 開發的后臺數據管理模塊，可以方便的對用戶進行增刪改查以及對用戶進行權限管理，同時也可便捷的導入系統初始數據，提高數據錄入以及數據管理的效率。

( 1 )用戶權限管理

在數控加工車間當中，環境較為復雜，為了保障整個系統的安全，必須對系統的使用人員進行權限管理，不同的人員對應不同的權限。在整個系統中，主要有超級管理員、設備工程師、普通操作人員三類用戶。

數控機床信息管理模塊主要提供以下功能:用戶信息管理、設備點檢信息管理、機床數據管理、故障信息管理、機床備件管理。其中，超級管理員擁有全部權限，出于安全的考慮，系統只允許同時一個超級管理員在線對所有數據進行修改或者添加。設備工程師擁有部分模塊的所有權限，可對機床自身的數據進行管理、對機床的故障信息進行管理、以及對備件信息進行管理。普通操作人員主要擁有各種模塊的查看權限，以及設備點檢信息的修改權限。上述三類人員具體權限如表4-5所示。

表 4-5 用戶具體權限表

Table 4-5 User specific permission Table)

用戶名稱用戶管理機床基礎

數據管理故障信息

管理機床點檢

信息管理備件信息

管理

超級管理員增刪改查增刪改查增刪改查增刪改查增刪改查

設備工程師 -- 查增刪改查查查

普通操作人員 -- 查查增刪改查查

通過以上的具體的權限管理，當用戶登錄時，會通過一系列的驗證操作。用戶具體管理流程圖如圖 4-7 所示。

圖 4-7 用戶管理流程圖

Figure 4-7 User management flowchart)

（2）用戶信息管理在用戶信息管理模塊中，超級管理員通過上述流程可以創建新用戶，同時將用

戶信息保存至用戶數據表當中，用戶數據表的結構如表 4-6 所示。

表 4-6 User_info 數據表結構

Table 4-6 User info data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段 Id 否 Pk

Username Varchar 用戶名否

Password Varchar 密碼否

Is_type Int 人員類別否

Email Varchar 郵箱否

Last_login Datetime 登錄時間否

Data joined Datetime 創建時間否

4.4.2機床點檢信息管理

隨著數控機床使用年限的增加，對數控機床進行定時的保養與維護就顯得更加的重要。如果在長期的加工過程中，不制定相應的數控機床保養策略，那么在后期的使用中就會大大的增加數控機床的故障率，同時使得數控機床的加工精度降低，產品質量難以得到保障。通過和數控機床的操作人員以及車間管理人員的交流，本次開發的設備點檢信息模塊可以定時記錄人員對數控機床的點檢記錄，從而實現對數控設備點檢信息的管理。

( 1 ) 點檢項目

本次數控機床的型號為VMC655H，使用的是西門子828D數控系統。相比傳統的普通機床，對數控機床的日常保養要求更高，本次對數控機床具體的保養項目以

及要求如表4-7 所示。表 4-7 數控機床具體點檢項目及內容

(Table 4-7 Specific inspection items and content of CNC machine tools)

點檢項目點檢內容

橫梁、滑枕檢查是否有漏油和滲油現象

傳動機構使用聽聲法和觸覺法檢查旋轉和進給機構是否有異響聲

主軸頭方健是否磨損，錐孔是否有磕碰傷，主軸頭外表面是否有

新的磕碰痕跡

接油盒、水槽檢查機床周圍的接油盒和水槽是否有漏油、漏水情況，并

清理槽內雜物

冷卻液濾網清理鐵屑及雜物，保持濾網清潔

導軌防護罩是否有損壞并及時清理與工作臺面之間的鐵屑及雜物

工作臺面有無新的磕傷、銑傷的痕跡，及時砂輪或油石處理磕碰

后的高點

控制面板外表保持清潔，按鍵、指示燈、波段開關、鑰匙開關是否正常

手輪外表保持清潔，調節旋鈕是否正常

(2)點檢信息數據表設計為了實現機床點檢信息的有效管理，需要將每次點檢信息都保存至數據庫當中以便后期對數控機床的狀態進行判定，制定更加有針對性的點檢項目。數控機床點檢信息數據表結構如表4-8 所示。

表 4-8 點檢信息數據表結構

( Table 4-8 Check information data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Machine_num Varchar 機床編號否 Fk

Hl_Hz Varchar 橫梁、滑枕否

Cd Varchar 傳動機構否

Zz Varchar 主軸頭否

Jyh_Sc Varchar 接油盒、水槽否

Lw Varchar 冷卻液濾網否

Kzmb Varchar 控制面板否

Fhz Varchar 導軌防護罩否

Gztm Varchar 工作臺面否

Sl Varchar 手輪否

4.4.3機床故障信息管理

故障數據是對數控機床加工產品進行可靠性分析和定期檢驗數控機床加工狀態的重要數據來源。同時當數控機床發生相同或者類似的故障的時候，維修人員能夠通過故障記錄快速找到解決問題的方法，提高維修的速率。通過對國內的機械制造企業的調查發現，大多數的企業沒有將數控機床的故障信息做專門的收集與分析，而是由某個部門將數控機床維修工單保存在 Excel 表或者直接記錄在紙質工單上。同時在企業在收集故障數據方面時效性差，容易遺漏數據，保存在Excel或者紙質文件中不方便進行查找，不能有效利用故障數據。本次設計的數控機床故障信息管理模塊，能夠快速的將故障信息進行錄入，同時支持快速的進行故障信息的查找。

（1）故障信息的分類

由于數控機床的故障信息種類繁多，所以需要將故障信息進行分類，將故障信息進行規范化，有利于快速收集整理故障信息，保存在數據庫當中。在故障信息管理模塊中，我們將故障信息分為 5 類，并且細化各種故障類型的具體故障項，數控機床具體故障類型與故障具體項如表 4-9 所示。

表 4-9 數控機床故障類型與故障具體項

Table 4-9 CNC machine tool fault types and fault specific items)

故障類型故障具體項

狀態溫升異常噪音超標振動過大異響沖擊過大

損壞零部件損壞元器件損壞線路短路線路斷路

功能部件不移動移動不到位回轉不準

堵塞或液、油、氣液、油、氣排屑槽堵塞

滲漏堵塞滲漏

超差幾何精度定位精度工作精度

超差超差超差

松動緊固件松動預緊松動

其他傳感器失靈電壓不穩用戶操作錯誤誤報警系統參數錯誤

（2）故障信息數據表設計

通過上述對數控機床故障信息的具體分類，隨即可在數據庫中建立相應的故障信息表，進而有效管理機床的故障信息。故障信息數據表的具體結構如表4-10所示。

表 4-10 故障數據表結構

Table 4-10 Failure data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Machine_num Varchar 機床編號否 Fk

Machine_name Varchar 機床名稱否

Fault_type Varchar 故障類型否

Fault_item Varchar 故障具體項否

Fault_info Varchar 故障信息否

Fault_solve Varchar 故障解決方案否

Fault_ontime Datatime 故障發生時間否

Fault offtime Datatime 故障解決時間否

4.4.4機床備件信息管理

當車間數控機床出現故障時，如果企業因為維修備件不足而導致維修停止，輕則造成數控機床停機，重則影響生產進度。因此對備件信息進行有效管理，制定備件錄入系統的規范化操作，同時管理人員要實時統計車間備件數量，實時記錄備件入庫數量，并且當備件數量低于某個數值時系統將發出警告，以此來保證備件充足的數量。當數控機床出現故障的時候，能夠第一時間提供維修備件，提高企業的快速維修能力，保證生產的正常進行。

（1）備件出入庫本次開發的備件信息管理模塊主要針對數控機床的電氣備件和機械備件。當執行備件入庫時，首先需要對備件進行初檢，如果檢驗不合格則直接剔除，不執行入庫記錄；檢驗合格則直接進行入庫操作，此時系統會自動記錄入庫備件數量、類型、入庫執行人員、入庫時間，最終完成備件的入庫。當數控機床發生故障需要更換備件時，此時管理人員可進入備件管理頁面，然后選擇備件的類別，最后選擇具體備件執行出庫，執行出庫的同時也將自動記錄出庫備件數量、出庫執行人員、出庫時間，最終完成備件出庫。備件具體出入庫流程如圖4-8 所示。

圖 4-8 備件出入庫流程圖

（Figure 4-8 Flow chart of spare parts storage）

（2）備件數據庫設計在每次執行出庫或者入庫時，備件信息管理模塊都會自動記錄出入庫的信息，并將其保存在數據庫當中。同時當備件的數量更新時，此時也會自動更新備件數據表中的備件的數量。后期需要查詢備件出入庫信息或備件的數量的時，就可以查詢數據庫獲取數據，實現備件相關信息的管理。備件出入庫數據表、備件信息數據表的具體結構如表4-11~4-13 所示。

表 4-11 備件出庫數據表結構

(Table 4-11 Spare parts outbound data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Out_spare_name Varchar 出庫備件名稱否

Out_spare_num Varchar 出庫備件數量否

Out_spare_operator Varchar 出庫執行人否

Out Spare item Datetime 出庫時間否

表 4-12 備件入庫數據表結構

Table 4-12 Spare parts storage data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

In_spare_name Varchar 入庫備件名稱否

In_spare_num Varchar 入庫備件數量否

In_spare_operator Varchar 入庫執行人否

In spare item Datetime 入庫時間否

表 4-13 備件數據表結構

Table 4-13 Spare parts data Table structure)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Spares_type Varchar 備件類型否

Spares_num Varchar 備件編號否

Spares_name Varchar 備件名稱否

Specification_num Varchar 規格型號否

Measure_unit Varchar 計量單位否

Current_amount Int 在庫數量否

Min_amount Int 庫存下限否

Max_amount Int 庫存上限否

Spares info Varchar 詳細信息否

4.4.5機床基礎數據管理

經過對多家機械加工企業的調研發現，當工程師想要快速的了解一臺機床的數據時，往往需要去查詢機床的技術手冊。對于數控機床來說，由于結構復雜，系統集成度高，因此參數也非常多，若一個車間有多臺不同的數控機床，此時先要快速了解數控機床的基礎數據就會花費更多的時間。基于此，本文設計了一個具有普適性的數控機床基礎數據管理模塊。通過此系統車間管理人員或工程師可以快速地的獲取數控機床的基礎數據，節省了查找時間。

（1）數據分類在機床基礎數據管理模塊中，我們把數控機床的基礎數據分為了兩類：數控機床主要技術參數、數控機床后期參數。其中數控機床主要技術參數主要是數控機床在出廠時廠家已經設定好的一些技術參數，主要分為6 類包括：尺寸參數、接口參數、運動參數、動力參數、精度參數、其他參數。數控機床主要技術參數分類如表 4-14 所示。

表 4-14 數控機床主要技術參數

Table 4-14 Main technical parameters of CNC machine tools)

參數類別參數內容

尺寸參數工作臺面積（長 X 寬）、承重主軸端面到工作臺距離交換工作臺尺寸、數量及交換時間

接口參數工作臺 T 形槽數、槽寬、槽間距主軸孔錐度、直徑最大刀具尺寸及重量刀庫最大容量刀具換刀時間

運動參數主軸轉速范圍各坐標行程及擺角范圍各坐標快進速度、切削進給速度范圍

動力參數主軸電機功率伺服電機額定轉矩

精度參數定位精度、重復定位精度分度精度（回轉工作臺）

其他參數外形尺寸、重量

數控機床后期自定義參數主要是指當數控機床在車間已經安裝完畢后，技術人員根據車間實際情況后期定義的參數，例如：數控機床IP地址、編號、操作人員等。具體自定義參數如圖4-9 所示。

數控機床后期自定義參數

圖 4-9 數控機床后期自定義參數

Figure 4-9 Customized parameters for CNC machine tools)

（2）機床基礎數據數據庫設計將數控機床的基礎數據按照上述介紹進行分類管理，實現快速準確查找數控機床的基礎數據。在錄入系統之前，管理員首先將數控機床的主要技術參數進行整理，然后自定義數控機床的后期參數，最終將數控機床的基礎數據錄入到系統保存在數據庫中。數控機床主要技術參數數據表、數控機床后期自定義參數數據表的具體結構如表 4-15、4-16 所示。

表 4-15 數控機床主要技術參數數據表結構

Table 4-15 Data Table structure of main technical parameters of CNC machine tools)

字段名稱

字段類型

備注是否為空約束

Max_tool_size Varchar 最大刀具尺寸否

Max_tool_weight Float 最大刀具重量否

Magazine_ capacity Int 刀庫最大容量否

Tool_change_time Float 刀具換刀時間否

Spindle_speed_range Varchar 主軸轉速范圍否

X_route Float X 軸行程否

Y_route Float Y 軸行程否

Z_route Float Z 軸行程否

Xswing_angle_range Varchar X 軸擺角范圍否

Yswing_angle_range Varchar Y 軸擺角范圍否

Zswing_angle_range Varchar Z 軸擺角范圍否

Xfeed _speed_range Varchar X 軸快速進給速度范圍否

Yfeed _speed_range Varchar Y 軸快速進給范速度圍否

Zfeed _speed_range Varchar Z 軸快速進給速度范圍否

Xcut_speed_range Varchar X 軸切削進給速度范圍否

Ycut_speed_range Varchar Y 軸切削進給速度范圍否

Zcut_speed_range Varchar Z 軸切削進給速度范圍否

Motor_power Float 主軸電機功率否

Servo_motor_torque Float 伺服電機額定轉矩否

Position_accuracy Float 定位精度否

Repeat_position_accuracy Float 重復定位精度否

Indexing_accuracy Float 分度精度（回轉工作臺）否

Dimensions Varchar 外形尺寸否

Weight Float 重量否

表 4-16 數控機床后期自定義參數數據表結構

Table 4-16 Data Table Structure of Customized Parameters of CNC Machine)

字段名稱字段類型備注是否為空約束

Id Int 字段Id 否 Pk

Machine_num Varchar 機床編號否 Fk

Machine_name Varchar 機床名稱否

Machine_ip Varchar 機床 IP 地址否

System_type Varchar 系統類型否

Manufacturer Varchar 生產商否

Production_date Datetime 出廠日期否

Operator Varchar 操作人員否

Service_life Varchar 使用年限否

Installation_date Datetime 安裝日期

Current location Varchar 當前位置否

4.5本章小結

通過上述介紹，本章主要完成了以下工作：

(1)系統的闡述了 OEE在本系統的具體實現方法；

(2)提出了一種改進的 SDT 算法，并成功的應用于實時數據的壓縮；

(3)通過使用RabbitMQ和WebSocket完成了實時數據推送模塊的設計，滿足數據實時推送的要求；

(4)開發了基于數控機床的信息管理模塊，實現對數控機床的相關信息管理。

5軟件系統測試

系統測試作為整個系統開發非常重要的一步，其能夠驗證系統是否存在未知的錯誤，是否能夠按照要求正常運行。只有經過嚴格的系統測試，才能將系統應用于現場環境當中。本章通過搭建軟件測試環境，通過運行系統并對系統重要功能進行測試，從而保障系統運行的可靠性。

5.1實驗環境搭建

本次實驗環境主要采用的設備具體如表 5-1所示。

表 5-1 具體測試設備

(Table 5-1 Specific hardware equipment)

設備名稱作用備注

工控機系統客戶端操作系統為 Windows7

計算機系統服務器操作系統Windows 10，數據庫為MySQL5.7，軟件

系統運行環境為 Python3.7

VMC655H 加工中心實驗臺安裝西門子828D數控系統，

OPCUA 服務器版本為 SW4.7

75 寸顯示器實時監測數據顯示作為實時監控屏幕

VMC655H高速立式加工中心采用的是西門子828D數控系統，可用于實際工件的加工，顯示器用來顯示實時監測的頁面；工控機用于訪問信息管理系統。筆記本電腦作為系統的服務器，其主要功能有3個：（1）運行數據采集程序實現對數控機床實時數據采集；（2 ）作為數據庫服務器存儲采集到的數據；（3 ）作為Web服務器對外提供服務。基于此，本次系統測試的實驗環境如圖5-1 所示。

圖 5-1 現場測試環境

Figure 5-1 Field test environment)

5.2系統運行實例

為了實現對數控機床運行狀態的實時監測，并且同時掌握數控機床的各種相關信息，從而達到更好的幫助技術人員和管理人員管理數控機床的目的。故需要運行數據采集客戶端和 Web 服務器程序，驗證系統運行是否正確。

5.2.1數控機床實時監測模塊運行實例

當數控機床進行模擬加工的時候，數據采集程序開始運行，此時數據采集端通過OPC UA協議與服務器相連進行數據采集。此時通過輸入URL地址訪問服務器, 服務器返回數控機床實時監測的畫面，結果如圖5-2 所示。

數控機床實時監測與分析系統當前時間：2020^12月27-21時51分8&

機床信息 1 L 主軸電流曲線

圖 5-2 實時數據顯示頁面

Figure 5-2 Real-time data display page)

根據圖 5-2 所示，可以獲取到的實時數據包括：當前數控機床的運行時間、月產量、主軸電流、主軸負載、主軸進給、主軸轉速、主軸負載、XYZ軸絕對坐標、加工程序等重要信息。

與此同時截取該時刻數控機床運行時的HMI界面信息，包括絕對坐標數值、運行程序信息、主軸進給、主軸轉速、主軸負載等關鍵信息，具體內容如圖5-3 所示。

圖 5-3 數控機床運行實時狀態圖

Figure 5-3 Real-time state diagram of CNC machine tool operation)

通過對比圖5-2 與圖5-3 可以得知，數控機床的當前加工狀態與實時數據顯示頁面的一致，同時觀察HMI （人機界面）所顯示的每個的軸的編程值、主軸進給速度及倍率、主軸轉速及倍率都同頁面一致。當數控機床進行加工時，實時數據顯示頁面的 X、 Y、 Z 軸當前的機械坐標和剩余移動量會隨著加工的進行不斷地變化，界面也會同步顯示當前主軸電流的曲線以及當前加工程序的具體信息。因此，可以看出數控機床實時監測模塊運行正常。

設備指數分析主要是建立在OEE的分析之上。在測試期間，首先讓機床運行進行模擬加工，利用 4.1.2 小節的計算方法得出數據，觀察設備指數分析頁面數據顯示情況，該界面可以展示數控機床在該段時間里的各項功能指標，通過該界面可以實時的掌握數據機床的當前各種狀態，具體效果如圖5-4 所示。

圖 5-4 設備指數分析頁面

Figure 5-4 Equipment index analysis page)

通過使用 JavaScript 定時器功能，用戶可以自定義時間進行各項指標的計算。從上圖中我們也可以看出，各統計圖的顏色分明，非常便于識別。同時，設備指數分析與累計時間統計模塊，用戶也可以自行定義統計的時間跨度，選擇按周、按月、按年的方式進行數據的統計，滿足不同用戶使用需求。

5.2.2數控機床信息管理模塊運行實例

該模塊可實現遠程或離線的可視化查看，同時為MES，ERP系統提供一線生產車間的數據。該數控機床信息管理模塊主要包括設備基礎數據管理模塊、故障信息管理模塊、機床點檢信息管理模塊、備件信息管理模塊，后臺數據管理模塊等模塊。操作人員可隨時輸入URL地址進行訪問，其登錄界面如圖5-5所示。

當用戶輸入正確的用戶名和密碼后即可進入操作界面，在這里以故障信息管理

界面進行演示。點擊左側的故障信息管理欄即可展開下拉框，當前即可選擇進行信

息的錄入與查詢，具體效果如圖5-6、 5-7 所示。

機床信息管理系統

Machine too I information management system

圖 5-7 故障信息查詢界面

Figure 5-7 Fault information query interface)

5.3系統性能測試

5.3.1數據傳輸模塊測試

數據傳輸是保證采集到的實時數據能夠快速推送至前端頁面進行顯示，是保證整個實時監測系統實時性的重要環節。本次采用消息隊列 RabbitMQ 和 WebSocket 結合的方式實現實時數據低延遲推送。這里主要測試的參數是消息隊列處理速率以及通過 WebSocket 傳輸數據延遲時間。

運行整個系統，可以通過 RabbitMQ 的插件監控 RabbitMQ 內部狀態、確認 RabbitMQ 可用并且能夠響應、觀察隊列狀態檢測消費者異常、檢測消息通信結構中不合需求的配置更改等。定義消息隊列處理速率V為：

式中：

Numl:為T1時刻的消息個數

Num2:為T2時刻的消息個數

每隔五分鐘獲取一次 RabbitMQ 消息隊列處理的消息個數，并將消息處理速率繪制如圖 5-8 所示。

0~5 10 15 20 25 30 35 40 45 50 55 60

t/min

圖 5-8 消息處理速率曲線圖

Figure 5-8 Message processing rate curve)

觀察圖5-8可以看出在一個小時內，RabbitMQ服務器每秒處理數據的速率穩定，曲線平穩，說明此時 RabbitMQ 服務器狀態正常，數據處理穩定，沒有發生消息擁塞等問題，滿足使用需求。

使用 Google Chrome 瀏覽器訪問實時監測頁面，從而建立起瀏覽器與服務器之間的 WebSocket 連接。在這里，我們定義數據采集時間與瀏覽器接收數據時間兩者之間的差值為網絡延遲時間，數控機床實時數據定義每隔一秒采集一次。啟動數控

機床采集實時數據。獲取實時數據采集時間，同時通過 Chrome 開發者工具控制臺日志輸出數據接收時間，計算兩者的時間差值，繪制計算結果如圖 5-9 所示。

(Figure 5-9 WebSocket push delay time curve)

觀察圖 5-9 可以看出，在一小時內，通過 WebSocket 傳輸，瀏覽器數據接收數據的網絡延遲時間平均在21ms,最大延遲時間不超過100ms,根據行業經驗，數控機床的實時監測數據傳輸延遲不超過 3 秒，故滿足實時數據傳輸的延遲要求。

5.3.2數據壓縮模塊測試

基于改進的SDT算法主要是為了對實時加工數據進行壓縮，為了驗證本次改進算法的壓縮性能，故利用改進的 SDT 算法與普通的 SDT 算法對數據進行壓縮，從而進行對比分析。在這里，本文主要選擇了主軸負載和X軸位置坐標兩項典型數據的進行實驗。對工件進行銑平面加工，采集該加工過程的實時數據，對數據進行壓縮，結果如表 5-2、5-3所示。

表 5-2 普通 SDT 算法壓縮結果

Table 5-2 Common SDT algorithm compression result)

采集數據項 △E CR CE

X 坐標 0.35 17.35 0.235

主軸負載 0.5 8.35 0.506

表 5-3 改進 SDT 算法壓縮結果

Table 5-3 Improved SDT algorithm compression result)

采集數據項 △E CR CE

X 坐標 0.35 17.35 0.114

主軸負載 0.5 8.35 0.216

通過表5-2 和表5-3 對比分析可知，兩次壓縮得出的結果主要區別是壓縮誤差的不同。當初始化相同的時候，此時改進的SDT算法相對于標準的SDT算法進行數據壓縮時，壓縮誤差CE明顯變小，也即壓縮后數據更加接近于真實數據。

同時我們將使用改進的SDT算法壓縮過后的X坐標的數據值與壓縮前的X坐標值進行繪制對比，結果如圖 5-l0、5-ll 所示。

Figure 5-10 X coordinate value before compression)

(Figure 5-11 X coordinate value after compression)

從圖 5-l0、5-ll 對比可以看出，經過壓縮后的 X 坐標數據值保留了原始數據的變化趨勢，同時算法能夠準確的記錄到數據改變的關鍵點，進而能夠很好的還原原始數據。

通過上述分析來看，雖然數據在經過壓縮后會丟失一些數據。對于數控機床的實時監測來說，監控變量的數值變化趨勢以及數值的突變往往預示著機床狀態的變化，這些變化通常與機床的故障以及機床的異常有直接的關系。因此，在該系統應用改進的 SDT 算法對數據進行壓縮滿足系統需求。

5.4系統功能測試

數控機床信息管理模塊主要由后臺數據管理模塊、設備基礎數據管理模塊、故障信息管理模塊、機床點檢信息管理模塊、備件信息管理模塊等子模塊組成，現對各個模塊進行功能測試，測試結果如表5-4~5-8 所示。

（1）后臺數據管理模塊運行結果。

表 5-4 系統后臺數據管理模塊運行結果

Table 5-4 System background data management module running results)

功能測試運行結果

管理員及用戶顯示是否正常正常

創建系統管理員是否正常正常

管理員是否能夠正常添加普通用戶正常

添加、刪除、修改權限功能是否正常正常

導入初始化數據是否正常正常

刪除、修改、查詢數據是否正常正常

（2）設備基礎數據管理模塊功能運行結果。

表 5-5 設備基礎數據管理模塊運行結果

(Table 5-5 Operation result of equipment basic data management module)

功能測試運行結果

機床信息能否正常顯示正常

機床信息能否正常錄入正常

機床信息能否正常編輯正常

機床信息能否正常刪除正常

錄入數據時是否進行數據檢查正常

（3）故障信息管理模塊功能運行結果。

表 5-6 故障信息管理模塊運行結果

(Table 5-6 Operation result of fault information management module)

功能測試運行結果

故障信息能否按照類別正常顯示正常

故障信息能否按照類別進行錄入正常

錄入數據時是否進行數據檢查正常

能否正常上傳故障信息相關圖片正常

故障信息能否按照時間進行模糊查詢正常

（4）機床點檢信息管理模塊功能運行結果。

表 5-7 機床點檢信息管理模塊運行結果

Table 5-7 Operation result of machine tool check information management module）

功能測試運行結果

點檢信息能否正常顯示

點檢信息能否正常進行錄入錄入數據時是否進行數據檢查點檢信息能否按照時間進行模糊查詢能否將點檢信息進行快速導出

點檢信息能否正常編輯

每日提醒功能是否正常正常

正常正常正常正常正常正常

（5）機床備件信息管理模塊功能運行結果。

表 5-8 機床備件信息管理模塊運行結果

Table 5-8 Operation results of the machine tool spare parts information management module）

功能測試運行結果

備件信息能否正常顯示

備件信息能否按照類別正常進行錄入錄入數據時是否進行數據檢查備件不足提醒功能否正常備件出入庫功能是否正常能否將備件信息進行快速導出備件信息能否正常編輯

備件信息能否按照類別或時間進行模糊查詢正常

正常正常正常正常正常正常正常

通過對系統的各個模塊的每個功能進行測試，各功能均能正常操作并得到預期的結果，故可證明本系統運行可靠，滿足使用需求。

5.5本章小結

通過上述介紹，本章主要完成了以下工作：

（1）詳細介紹測試環境軟硬件組成并搭建系統的測試環境；

（2）運行整個系統，進行數控機床的模擬加工，作為本系統的測試用例；

（3）對數據采集模塊進行測試，頁面數據顯示準確，傳輸速度滿足需求；

（4）對指數分析模塊進行測試，分析結果符合實際情況；

（5）對數據壓縮模塊進行測試，通過對比分析，表明數據壓縮算法能大幅減少數據存儲量同時保證壓縮后數據的準確性；

（6）對信息管理模塊的各個子模塊進行了功能測試，結果表明，各功能模塊運行正常，系統穩定可靠。

6結論與展望

6.1結論

本文開發的基于B/S架構的數控機床實時監測與信息管理系統，實現了對數控機床加工過程的實時監測、數據的壓縮、數據分析的可視化，同時在此基礎上，還設計了數控機床基礎數據管理、故障信息管理、機床點檢信息管理、備件信息管理等常用功能，實現了互聯網和制造業的融合。現將得到的研究結果總結如下：

（1）設計了整個系統的組成與通信架構。設計了基于數據采集層、數據存儲層、數據處理層、數據顯示層的系統架構，采用RabbitMQ和WebSocket實現實時數據推送，滿足行業數據傳輸延遲不超過 3秒的要求。

（2）研究了西門子828D數控系統數據采集方法。分析OPC UA服務器所提供的功能以及內部變量，通過OPC UA結合Python語言完成了對數控機床實時數據的采集。

（3）利用OEE分析方法改善數控機床加工效率。將采集到的相關數據進行OEE 分析，從而得出影響數控機床 OEE 的環節，最終通過相應的措施提高 OEE 與數控機床的效率。

（4）數據壓縮算法的改進與應用。對廣泛應用的工業過程數據壓縮算法 SDT 算法進行了改進，數據壓縮率達到 50.2%。同時將其運用到實時數據的壓縮當中，從而減少了冗余信息的存儲，減小了服務器的壓力。

（5）設計并開發了前端數據顯示頁面。利用HTML和CSS開發了實時監測與指數分析的前端頁面，通過Echart.js組件實現實時數據動態展示與數據分析結果的圖表化，進而能夠實時掌握數控機床當前狀態。

（6）設計并開發了數控機床的信息管理系統。利用 Django 框架，開發了數控機床的信息管理系統，實現了對數控機床的點檢信息、故障信息、備件信息、基礎數據的管理，實現了制造信息的有效管理，提高了生產效率。

（7）對系統的各個功能模塊進行了現場測試，經過調試，整個系統的軟件和硬件均能夠正常工作。

6.2創新點

（1）通過比值法實現了 SDT算法容差的動態調整，極大提高了 SDT算法的壓縮性能，并同時減小了壓縮誤差，實現了對數控機床加工數據的壓縮。

（2）將消息隊列RabbitMQ和WebSocket協議相結合，實現了采集數據的快速傳輸，極大地降低了數據的延遲。

6.3展望

基于 B/S 架構的數控機床實時監測與信息管理系統，具有一定的通用性和普遍性。該系統的研究涉及到了多方面的工作，包括數據采集、數據存儲、數據傳輸、數據顯示。但本文的研究還有許多的不足，有很多的問題還需繼續深入的研究，今后的研究工作可以從以下幾個方面展開：

（1）在數據采集中，只是針對西門子 828D 數控系統默認提供的系統變量進行數據采集，沒有對數控機床的I/O模塊進行采集。后續可以采集數控機床的10信息，從而更加全面的獲取到數控機床的數據。

（2）本文只是針對數控機床的加工過程進行了實時監測，并未涉及到對數控機床進行實時的控制，后續可深入研究通過OPC UA對數控機床進行數據傳輸以及遠程控制。

（3）本次對數控機床進行實時監測只是針對單臺機床進行開發與測試，后續可以將該系統應用于多臺數控機床，實現對數控機床群的監測，更加符合現代制造業的需求。

參考文獻

[1]李楊，龐觀士.智能制造新模式下的電子行業離散型智能制造工廠[J].機電工程技術, 2017,46(10):23-27.

[2]倪祥明.數控機床及數控加工技術[M].北京：人民郵電出版社,2011.

[3]智研數據研究中心. 2020-2026 年中國數控機床行業市場深度調研及投資前景分析報告 [R].2020.

[4]林宋，田建君.現代數控機床[M]. 2003:工業裝備與信息工程出版中心,2003.

[5]焦亮.沈陽機床集團生產車間管理信息系統升級方案設計[D].吉林大學,2019.

[6]張區委.物聯制造環境下的加工設備智能化方法研究[D].南京航空航天大學，2019.

[7]于會龍.機床大數據采集與存儲技術研究[J].機電信息，2020(30):84-87.

[8]Juras Paul, Johnson Lauren.工業 4.0 實施之路[J].新理財，2020(10):62-64.

[9]聶篤偉.數控機床智能監控技術的研究與應用[J].現代工業經濟和信息化，2018,8(9):29-31.

[10]黃韜，顏永紅.基于WEB的數控遠程監控系統的研究[J].教師，2011(5):117-118.

[11]Caiza G, Nunez A, Garcia C A, et al. Human Machine Interfaces Based on Open Source Web-Platform and OPC UA[J]. Procedia m anufacturing， 2020，42:307-314.

[12]Wang L, Orban P, Cunningham A, et al. Remote real-time CNC machining for web-based manufacturing[J] . Robotics and Computer-Integrated Manufacturing, 2004,20(6):563-571.

[13]宓方瑋，黃賢超，陳濱.數字化制造設備信息采集技術方案[J].機床與液壓，2016,44(02):28-32.

[14]KL C, WB L, Henry L, et al. Design of an intelligent supplier relationship management system for new product development[J]. International Journal of Computer Integrated Manufacturing, 2004,17(8):692-715.

[15]Su Y, Cheng F, Hung M, et al. Intelligent prognostics system design and implementation[J]. IEEE transactions on semiconductor manufacturing, 2006,19(2):195-207.

[16]錢誠.關于企業生產管理信息系統的分析與研究[J].工業控制計算機，2016,29(01):126-127.

[17]呂鐵，韓娜.智能制造:全球趨勢與中國戰略[J].人民論壇•學術前沿，2015(11):6-17.

[18]葉華.項目式機械制造企業生產信息管理系統的設計與實現[D].哈爾濱工業大學，2015.

[19]張杰人.基于HTML5的數控機床實時監控與管理系統的研究與應用[D].上海應用技術大學， 2018.

[20]卓禎雨.基于Web的遠程監控系統實現技術的研究[D].武漢理工大學，2003.

[21]邱浩.基于MongoDB和Node.js的選煤機電設備運行監控系統研究[D].太原理工大學, 2019.

[22]夏磊.基于DNC系統的分布式船舶柴油機數控加工管理系統的設計與實現[D].江蘇大學, 2019.

[23]王哲健.中小型機械制造企業生產管理信息系統設計與實現[D].東北農業大學，2007.

[24]李大勇，李欣，張昊.基于Maximo的生產管理信息系統設計[J].中國電力教育,2009(S2):64-65.

[25]孫曉宇.基于Web的印刷企業管理信息系統的設計與開發[D].西安理工大學,2018.

[26]練俊君，魏琳，饒曉紅.基于嵌入式Linux Web服務器的機械設備狀態監測系統設計J].自動化儀表, 2019,40(07):43-46.

[27]屈展，李嬋.JSON在Ajax數據交換中的應用研究J].西安石油大學學報(自然科學版), 2011，26(01):95-98.

[28]Barbaglia G， Murzilli S， Cudini S. Definition of REST web services with JSON schema[J]. Software: Practice and Experience， 2017，47(6).

[29]Shivam， Dhiman A K， Gupta S， et al. Telemedicine Solution using Django[J]. International Journal of Engineering and Management Research (IJEMR)， 2020，10(2).

[30]高錦濤，劉文潔，李戰懷.一種面向分布式讀寫分離系統的數據同步策略[J].西北工業大學學報， 2020，38(01):209-215.

[31]成建宏.基于Web的低壓電器試驗設備遠程監控系統設計與實現[D].西安工程大學，2019.

[32]劉薇.基于OPC UA的MES數據管理系統的研究[D].北京郵電大學,2019.

[33]陳彥智.基于OPC UA的機床運行狀態數據可配置采集系統研究[D].重慶大學，2018.

[34]何雨婷.基于OPC UA的智能產線通信組件的設計與實現[D].中國科學院大學(中國科學院沈陽計算技術研究所)， 2020.

[35]謝春秋.基于OPC UA的數控機床遠程監控系統研究[D].蘭州理工大學,2017.

[36]張弛，吳明亮，陸軍強，等.基于OPC UA的828D數控機床群遠程監控系統設計[J].機械制造與自動化， 2018，47(6):186-189.

[37]葉小高.基于OPC UA的自動化系統集成技術研究[J].中小企業管理與科技仲旬刊), 2015(11):258.

[38]李金亮.OPC UA客戶端訪問與測試功能研究及開發[D].華北電力大學(北京)，2011.

[39]董梁玉.叉車可靠性強化試驗遠程監控系統的設計與實現[D].機械科學研究總院,2020.

[40]嚴成武.支持分庫分表和讀寫分離的ORM框架的設計與實現[D].哈爾濱工業大學,2016.

[41]吳劍飛.高并發網站數據庫方案的研究[D].上海交通大學，2016.

[42]MySQL Connector/Python Revealed:SQL and NoSQL Data Storage Using MySQL for Python Programmers[M] . Apress.

[43]Cole J. Machine Monitoring System Gives Real-Time KPI， OEE Data[J]. Modern Machine Shop， 2018，90(9).

[44]陳冉升，葉文華.基于數控機床實時數據采集的OEE計算方法研究J].中國制造業信息化, 2008，37(17):58-62， 66.

[45]李星，張加波，劉從華，等. 數控機床遠程監控及加工過程參數實時采集與應用效果分析 [J]. 新技術新工藝， 2015(5):153-156.

[46]王亞坤.火電廠過程數據特性的分析與研究[D].華北電力大學;華北電力大學(保定)模式識別與智能系統， 2009.

[47]Han S， Liu X， Chen J， et al. A real-time data compression algorithm for gear fault signals[J].

Measurement， 2016，88.

[48]趙旭東，丁杰雄，邊志遠，等.SDT改進算法在數控系統監控平臺中的應用[J].制造技術與機床， 2014(10):155-159.

[49]商承亞，鮑先強，付立軍，等.基于改進旋轉門算法的船舶綜合電力數據壓縮技術分析J]. 中國艦船研究， 2020，15(1):82-88.

[50]劉勁松，于東，胡毅，等.改進的旋轉門算法及其在數控機床監控領域的應用[J].組合機床與自動化加工技術， 2018(02):81-83.

[51]馬巍，武欣嶸，鄭翔，等.RabbitMQ在實時監控系統中的應用[J].軍事通信技術, 2017，38(01):82-85.

[52]周健.RabbitMQ消息隊列在城市智慧綜合管廊監控與報警集成管控平臺上的應用[J].工業控制計算機， 2019，32(09):12-13.

[53]Albano M， Ferreira L L， Pinho L M， et al. Message-oriented middleware for smart grids[J]. Computer Standards & Interfaces， 2015，38.

[54]肖順，嚴碧波.一種基于RabbitMq的消息推送系統的設計與實現[J].電子世界, 2019(07):204-205.

[55]馬巍，武欣嶸，鄭翔，等.RabbitMQ在實時監控系統中的應用[J].軍事通信技術, 2017，38(01):82-85.

[56]Zaidman A， Matthijssen N， Storey M， et al. Understanding Ajax applications by connecting client and server-side execution traces[J]. Empirical Software Engineering， 2013，18(2).

[57]呂振剛.基于Ajax技術的WEB研究[J].石油知識,2020(04):50-51.

[58]邵其專，蔣迪，莫熙.基于WebSocket技術面向電力調度的即時通信系統J].電子設計工程， 2020，28(06):144-148.

[59]李先懿，郭正光.基于Websocket的車聯網報警推送系統[J].計算機系統應用, 2020，29(03):127-131.

[60]李代立，陳榕.WebSocket在Web實時通信領域的研究[J].電腦知識與技術, 2010，6(28):7923-7925.

[61]鄒旺.數字化車間制造過程數據采集與智能管理研究[D].貴州大學，2018.

【本文地址：http://www.bzhlmm.com//guanlilei/gongshangguanli/xixinguanli/8802.html】

上一篇：滇池藍藻防控處置信息管理系統設計與開發

下一篇：沒有了

相關標簽:

最熱期刊