基于容器化架構(gòu)的機(jī)床故障診斷平臺(tái)設(shè)計(jì)

任鑫陽(yáng)，王定榮，張萌萌，易永余，張學(xué)良

（杭州科技職業(yè)技術(shù)學(xué)院，浙江杭州，311400）

0 引言

目前數(shù)控機(jī)床廣泛應(yīng)用和服務(wù)于制造企業(yè)、工廠、技校、高校技術(shù)中心等，但是國(guó)內(nèi)現(xiàn)有大部分?jǐn)?shù)控機(jī)床并不具備直接將內(nèi)部數(shù)據(jù)或加工狀態(tài)信息傳遞給上層控制系統(tǒng)的功能。數(shù)控機(jī)床自帶的標(biāo)準(zhǔn)通信接口也不足以提供生產(chǎn)決策人員所需的全部加工信息，對(duì)于不同時(shí)期、不同生產(chǎn)商的數(shù)控機(jī)床因其異構(gòu)性也難以做到狀態(tài)數(shù)據(jù)的集成采集。而對(duì)于數(shù)控機(jī)床的故障診斷，目前大部分?jǐn)?shù)控機(jī)床仍處于被動(dòng)式維護(hù)，根據(jù)維修計(jì)劃依賴專(zhuān)業(yè)維護(hù)人員到現(xiàn)場(chǎng)進(jìn)行維修[1]。

數(shù)控機(jī)床設(shè)備的組裝和配置越來(lái)越復(fù)雜，加工的方式也越來(lái)越復(fù)雜，隨著加工產(chǎn)品的復(fù)雜度和精密度的增加，多數(shù)控機(jī)床本身的要求也不斷增加。要求數(shù)控機(jī)床本身運(yùn)行更加可靠，因?yàn)樯僭S的故障或者異常都將對(duì)所加工的產(chǎn)品產(chǎn)生不可預(yù)測(cè)的影響。另外，由于數(shù)控機(jī)床本身的價(jià)格越來(lái)越高，要求對(duì)數(shù)控機(jī)床的故障能夠及時(shí)發(fā)現(xiàn)，避免對(duì)機(jī)床本身產(chǎn)生很大損失[2]。此架構(gòu)需要將大量的實(shí)時(shí)機(jī)床數(shù)據(jù)傳輸?shù)竭h(yuǎn)端服務(wù)側(cè)分析，由于數(shù)據(jù)量巨大，容易造成傳輸擁擠、延時(shí)和丟包。本文提出了一種基于容器化架構(gòu)的機(jī)床故障診斷技術(shù)，實(shí)現(xiàn)數(shù)據(jù)采集和本地化運(yùn)算分析，應(yīng)用于數(shù)控機(jī)床的故障預(yù)警、健康評(píng)估、故障診斷、壽命預(yù)測(cè)。

圖1 系統(tǒng)架構(gòu)

1 系統(tǒng)整體框架

本系統(tǒng)的體系架構(gòu)，包括底層硬件相關(guān)的設(shè)備層和感知層，將數(shù)據(jù)發(fā)送至服務(wù)端的數(shù)據(jù)層，對(duì)數(shù)據(jù)進(jìn)行處理的分析層，以及根據(jù)不同業(yè)務(wù)分類(lèi)的應(yīng)用層。數(shù)據(jù)層和分析層可以合并稱(chēng)為數(shù)據(jù)融合層，數(shù)據(jù)融合及應(yīng)用層主要完成對(duì)數(shù)控機(jī)床的振動(dòng)、聲音、溫度等參數(shù)快速采集和高效處理，為故障預(yù)警、診斷和狀態(tài)評(píng)估提供可靠的數(shù)據(jù)服務(wù)。針對(duì)主要監(jiān)測(cè)對(duì)象，實(shí)現(xiàn)模塊化設(shè)計(jì)，結(jié)合系統(tǒng)的設(shè)備接入功能，可方便擴(kuò)展采集監(jiān)測(cè)點(diǎn)，采用高精度、智能化感知單元，對(duì)數(shù)控機(jī)床實(shí)現(xiàn)實(shí)時(shí)感知，就地分析、高效預(yù)測(cè)。

2 系統(tǒng)硬件設(shè)計(jì)

系統(tǒng)硬件主體架構(gòu)分為核心板和采集板模塊，模塊之間通過(guò)網(wǎng)口相互通信。核心板和采集板鑲嵌在主板上，由主板統(tǒng)一提供電源，各類(lèi)外部接口包括網(wǎng)口、串口和IEPE 接口等對(duì)外引出。核心板模塊為邊緣計(jì)算的主芯片，運(yùn)行Linux操作系統(tǒng)，為各個(gè)算法軟件模塊提供運(yùn)行環(huán)境。采集板負(fù)責(zé)管理數(shù)據(jù)的采集和硬件過(guò)濾以及信號(hào)放大，將采集到的數(shù)據(jù)實(shí)時(shí)傳輸給核心板，供其上運(yùn)行的各個(gè)軟件模塊使用。整體硬件框圖如圖2 所示。

圖2 系統(tǒng)硬件電路設(shè)計(jì)框圖

■2.1 核心板模塊設(shè)計(jì)

核心模塊主控芯片是瑞芯微的3399 芯片。該芯片是64 位，由六個(gè)CPU 核，其中兩個(gè)核是ARM Cortex A72，另外四個(gè)核是ARM Cortex A53，芯片的處理速度達(dá)到1.8 GHz，計(jì)算性能非常強(qiáng)。核心模塊的內(nèi)存用的DDR3，內(nèi)存的容量有2GB 和4GB 兩種，可以隨意選擇。存儲(chǔ)芯片用的是SPI 接口的閃存，容量有16GB 和32GB 可選。對(duì)于數(shù)控機(jī)床的診斷運(yùn)算平臺(tái)，已經(jīng)足夠使用。該主控芯片提供一個(gè)千兆的RGMII 口，通過(guò)該接口連接MARVELL 的88E6240 Switch 芯片，通過(guò)switch 芯片拓展出1 個(gè)千兆口和三個(gè)百兆自適應(yīng)網(wǎng)口。通過(guò)主芯片上的HUB 接口，連接一個(gè)USB 轉(zhuǎn)串口芯片，引出4 個(gè)RS485 串行接口。

■2.2 數(shù)據(jù)采集板模塊設(shè)計(jì)

數(shù)據(jù)采集模塊設(shè)計(jì)如圖3 所示，數(shù)據(jù)采集板主芯片采用STM32H74 系列單片機(jī)，ADC 轉(zhuǎn)換芯片采用的是AD7606BSTZ，這是一款16 位采樣精度的模數(shù)轉(zhuǎn)換芯片，擁有同步采樣機(jī)制的8 個(gè)通道。通過(guò)這些通道，引出壓電集成電路形式的振動(dòng)傳感器采集接口和用于采集轉(zhuǎn)速的霍爾轉(zhuǎn)速傳感器采集接口，這8 個(gè)接口可以任意選擇用于振動(dòng)采集或者轉(zhuǎn)速采集。另外通過(guò)單片機(jī)自身攜帶的ADC 模塊，利用運(yùn)放模塊引出用于采集溫度的傳感器接口。

圖3 數(shù)據(jù)采集模塊硬件設(shè)計(jì)

■2.3 其他接口模塊設(shè)計(jì)

其他接口模塊主要包括電源模塊和通信模塊。其中電源模塊提供外部9～36V 的寬幅直流輸入，利用聲壓模塊提升到24V 后，再利用DCDC 分別轉(zhuǎn)換至+12V 和-12V 給運(yùn)放和恒流源供電；轉(zhuǎn)換至3.3V，給MCU 和PT100 采集接口供電。從外部電源輸入后，另一路通過(guò)DCDC 轉(zhuǎn)換成3.3 提供給RK3399 和switch 芯片。通信模塊主要提供上行通信接口和板間信息的交互，這部分功能主要由交換芯片完成。系統(tǒng)采用Marvell88E6240 這款7 端口的以太網(wǎng)交換芯片，包含4 個(gè) 10/100M 快速以太網(wǎng)接口和1 個(gè)千兆以太網(wǎng)口，支持最新IEEE802.1 標(biāo)準(zhǔn)。

3 系統(tǒng)軟件設(shè)計(jì)

核心板作為邊緣計(jì)算平臺(tái)運(yùn)行Linux 操作系統(tǒng)，各類(lèi)應(yīng)用軟件（包括系統(tǒng)管理應(yīng)用軟件和業(yè)務(wù)軟件等）運(yùn)行在Docker 容器內(nèi)，容器提供各類(lèi)業(yè)務(wù)相關(guān)的庫(kù)文件。

如圖4 所示，系統(tǒng)應(yīng)用軟件模塊包括：Web 服務(wù)，存儲(chǔ)管理，網(wǎng)絡(luò)通信、日志管理、系統(tǒng)資源監(jiān)測(cè)/告警，軟件OTA 升級(jí)方案等用于管理系統(tǒng)本身，同時(shí)也可以服務(wù)設(shè)備的管理者。業(yè)務(wù)應(yīng)用軟件模塊：這里的業(yè)務(wù)軟件主要是指各個(gè)數(shù)據(jù)處理軟件模塊和算法模塊，用于智能感知，智能控制，智能決策，包括數(shù)據(jù)采集和預(yù)處理，故障診斷、壽命預(yù)測(cè)、故障預(yù)警和健康評(píng)估等軟件。

圖4 軟件框架

■3.1 Docker 容器及軟件APP 化

容器就是將應(yīng)用程序所運(yùn)行的必要環(huán)境捆綁到一起，然后運(yùn)行在另一個(gè)宿主環(huán)境中的技術(shù)。容器技術(shù)[3]的最大優(yōu)勢(shì)就是與在宿主機(jī)上創(chuàng)建虛擬機(jī)實(shí)例相比，具有更快的速度。Docker 就是一個(gè)開(kāi)源的應(yīng)用容器引擎，與其他同類(lèi)容器相比，它有更高的系統(tǒng)資源利用率；與傳統(tǒng)的虛擬機(jī)的啟動(dòng)速度動(dòng)輒幾分鐘的時(shí)間相比，docker 容器直接運(yùn)行與宿主機(jī)的內(nèi)核上，不需要啟動(dòng)一個(gè)完整的操作系統(tǒng)，因而可以大大節(jié)省啟動(dòng)時(shí)間。Docker 不需要提供完整的運(yùn)行核，但它提供一個(gè)完整的運(yùn)行時(shí)環(huán)境，可以避免出現(xiàn)運(yùn)行環(huán)境不一致的問(wèn)題。由于docker 確保提供運(yùn)行環(huán)境的一致性，因此，App 的遷移變得更加方便、快捷，方便應(yīng)用程序在各個(gè)平臺(tái)上進(jìn)行快速移植。Docker 提供的鏡像是利用分層的結(jié)構(gòu)實(shí)現(xiàn)的，因此，增加和刪減鏡像的組件變得非常方便，輕松實(shí)現(xiàn)后期維護(hù)。擁有如上所述的優(yōu)勢(shì)，使得利用docker 容器化運(yùn)行的App，具有非常好的隔離性、安全性和可維護(hù)性。

■3.2 設(shè)備整體數(shù)據(jù)流

本系統(tǒng)利用IEPE 接口連接振動(dòng)、噪聲、轉(zhuǎn)速和溫度傳感器，采集上來(lái)的數(shù)據(jù)通過(guò)ADC 芯片進(jìn)行模數(shù)轉(zhuǎn)換成數(shù)字信號(hào)，MCU 板上對(duì)數(shù)字信號(hào)進(jìn)行必要的濾波和放大，然后通過(guò)網(wǎng)口發(fā)送到RK3399的核心板上運(yùn)行在容器內(nèi)的應(yīng)用程序?qū)?shù)據(jù)進(jìn)行進(jìn)一步的清洗等處理，算法模塊提取特征值存儲(chǔ)在數(shù)據(jù)庫(kù)里，進(jìn)行后續(xù)的處理。整體數(shù)據(jù)流轉(zhuǎn)圖如圖5 所示。

圖5 數(shù)據(jù)流框圖

■3.3 系統(tǒng)界面展示

根據(jù)上文的軟件設(shè)計(jì)思路，本文研制基于容器化架構(gòu)的機(jī)床故障診斷平臺(tái)，平臺(tái)界面如圖6 所示。平臺(tái)可以實(shí)時(shí)顯示機(jī)床的狀態(tài)信息，數(shù)據(jù)傳輸流暢，基于Docker 開(kāi)發(fā)的多種應(yīng)用可實(shí)時(shí)切換，極大地提升了系統(tǒng)的流暢性和便捷性。

圖6 系統(tǒng)界面圖

4 結(jié)論

本文介紹了一種基于容器化的數(shù)控機(jī)床故障診斷工業(yè)物聯(lián)網(wǎng)邊緣計(jì)算設(shè)備系統(tǒng)。擁有振動(dòng)、聲音、轉(zhuǎn)速和溫度等多種物理參數(shù)的集成采集，同時(shí)擁有供復(fù)雜算法模塊運(yùn)行分析環(huán)境的軟件平臺(tái)環(huán)境，各個(gè)軟件App 可以獨(dú)立無(wú)關(guān)地運(yùn)行，又可以通過(guò)平臺(tái)軟件的內(nèi)部總線進(jìn)行數(shù)據(jù)交互通信，通過(guò)采集板采集數(shù)控機(jī)床的各類(lèi)物理量參數(shù)，通過(guò)平臺(tái)算法模塊的實(shí)時(shí)運(yùn)行，得到數(shù)控機(jī)床機(jī)理模型的各類(lèi)特征參數(shù)，將參數(shù)顯示到前端頁(yè)面，供用戶故障診斷做參考。