文/唐一凡，楊明川，張龔磊 北京奔馳汽車有限公司

奔馳動力總成工廠已應(yīng)用了眾多數(shù)字化設(shè)備并且搭建了傳感器實時監(jiān)控數(shù)據(jù)系統(tǒng)，但由于種類繁多，上傳流程難以統(tǒng)一，還未形成統(tǒng)一的數(shù)據(jù)閉環(huán)。本方案創(chuàng)新點主要集中在端到端業(yè)務(wù)流的數(shù)字打通，借助物聯(lián)網(wǎng)技術(shù)、創(chuàng)造性的全面打通數(shù)控中心工業(yè)層信息孤島，在數(shù)據(jù)采集和數(shù)據(jù)上傳之間搭建橋梁，將采集數(shù)據(jù)雜亂的格式進行歸一化處理，降低后期數(shù)據(jù)分析的難度，使數(shù)據(jù)真正地流動起來，應(yīng)用起來，形成反饋提升設(shè)備性能；更為重要的是，本方案創(chuàng)造性地解決了數(shù)控系統(tǒng)各種類型數(shù)據(jù)的統(tǒng)一上傳，針對各種場景形式能夠綜合分析。實現(xiàn)業(yè)務(wù)數(shù)字化，業(yè)績數(shù)字化。

整個項目的網(wǎng)絡(luò)設(shè)計與構(gòu)成如圖1所示，通過BFC（BrownField connectivity）解決設(shè)備多樣性造成的數(shù)據(jù)采集格式不統(tǒng)一及數(shù)據(jù)孤島的問題，這些數(shù)據(jù)會被上傳到MSB平臺，進行數(shù)據(jù)的存儲與展示，并傳輸?shù)絻?nèi)部數(shù)據(jù)庫中。

圖1 方案網(wǎng)絡(luò)設(shè)計與構(gòu)成

整個項目的軟硬件設(shè)計及流程如圖2所示，控制層各執(zhí)行單元通過數(shù)控系統(tǒng)實現(xiàn)數(shù)據(jù)傳輸及通信，集中數(shù)據(jù)處理NCU與上位機PCU通信。同時PCU中預置MSB-kibana平臺進行數(shù)據(jù)的展示。BFC客戶端能夠?qū)崿F(xiàn)數(shù)據(jù)整合、收集、統(tǒng)一上傳到工廠網(wǎng)絡(luò)服務(wù)器，另外工廠網(wǎng)絡(luò)服務(wù)器具備訪問功能實現(xiàn)數(shù)據(jù)配置端等功能，最終服務(wù)器與MSB連通對接業(yè)務(wù)。存儲在msb服務(wù)器中的數(shù)據(jù)通過算法處理，將處理結(jié)果存儲到數(shù)據(jù)庫中，該數(shù)據(jù)庫還包含其余與設(shè)備相關(guān)聯(lián)的信息，如工程師經(jīng)驗總結(jié)，預防性維護清單等。在進行預測性維護、緊急性維修時，MSB平臺及維修信息數(shù)據(jù)庫會提供設(shè)備參數(shù)值趨勢及異常情況、歷史維護報告、故障根本原因預測等；一方面可以檢索過往的維修信息，設(shè)備狀態(tài)，另一方面通過算法分析給出優(yōu)化建議和維護策略。同時設(shè)備的狀態(tài)會產(chǎn)生一個反饋，優(yōu)化系統(tǒng)信息。

圖2 方案軟硬件設(shè)計及流程

硬件系統(tǒng)及網(wǎng)絡(luò)搭建完成后，即可開始采集數(shù)據(jù)、監(jiān)控數(shù)據(jù)、分析數(shù)據(jù)。

數(shù)據(jù)采集

北京奔馳動力總成系統(tǒng)內(nèi)大量的高自動化智能化設(shè)備，其控制方式也多樣化，例如PLC控制、NC系統(tǒng)控制等。如圖3所示，數(shù)據(jù)源自于眾多廠商的加工設(shè)備數(shù)控系統(tǒng)、傳感器、智能電表，多個來源渠道對數(shù)據(jù)的統(tǒng)一采集造成了很大的困難。這些設(shè)備大部分可以自動采集數(shù)據(jù)并上傳至服務(wù)器或存儲在緩存區(qū)中，但這種分散式的存儲方式有幾項缺陷，一方面浪費資源，可能需要購買不同類型的服務(wù)器或存儲設(shè)備，另一方面，會對數(shù)據(jù)的分析造成很大的困難，在分析前需要完成大量的篩選與整合工作，比如將所需信息從不同渠道聚合在一起，并且統(tǒng)一數(shù)據(jù)格式、時間戳(timestamp)等。

圖 3 多種數(shù)據(jù)采集設(shè)備

傳統(tǒng)方案中會使用PLC或者OPC采集加工中心數(shù)據(jù)，但這一方案對加工設(shè)備的硬件版本或PLC軟件版本有較為嚴格的要求，若版本不匹配會影響數(shù)據(jù)的采集。為了解決多種規(guī)格型號的設(shè)備數(shù)據(jù)統(tǒng)一采集這一問題，北京奔馳與西門子公司合作開發(fā)了BFC解決方案，該網(wǎng)關(guān)可以連接不同型號的數(shù)控系統(tǒng)，如西門子、FANUC、heidenhain等，還可以連接智能電表、傳感器等物聯(lián)網(wǎng)設(shè)備，在統(tǒng)一的平臺上配置采集信息，如頻率、上傳格式等。同時，上傳數(shù)據(jù)時支持多種工業(yè)物聯(lián)網(wǎng)協(xié)議，可以匹配工廠中所使用的網(wǎng)絡(luò)協(xié)議。該方案實現(xiàn)了軟件和硬件設(shè)備的統(tǒng)一化連接，通過在硬件設(shè)備上安裝BFC插件，從而得到與該設(shè)備唯一匹配的ID，在軟件端配置時，從ID列表中選取需要采集信息的設(shè)備的ID，即可完成數(shù)據(jù)采集配置與其相對應(yīng)的硬件的連接，BFC網(wǎng)關(guān)連接工廠網(wǎng)絡(luò)，全程采用信息閉環(huán)傳遞，極大的保障的數(shù)據(jù)安全與網(wǎng)絡(luò)安全。

北京奔馳目前使用的工業(yè)物聯(lián)網(wǎng)框架為MSB(Manufacturing Service Bus)平臺，該平臺以MQTT協(xié)議為基礎(chǔ)實現(xiàn)了從數(shù)據(jù)采集、數(shù)據(jù)上傳、到數(shù)據(jù)展示的功能。BFC解決方案在數(shù)據(jù)采集與數(shù)據(jù)上傳中增加了數(shù)據(jù)轉(zhuǎn)換功能，實現(xiàn)了多種數(shù)據(jù)的整合，例如，改造前，同一機床設(shè)備的能耗數(shù)據(jù)、溫度數(shù)據(jù)、電機振動頻率等都是通過獨立的json文件上傳至服務(wù)器的，各個網(wǎng)關(guān)也需要單獨配置，改造后，同一機床的眾多數(shù)據(jù)源在同一json文件中上傳，網(wǎng)關(guān)只需要配置一次，在kibana展示頁面可以高效的查看這一設(shè)備的所有信息。

在json文件配置中，進行統(tǒng)一的命名，方便數(shù)據(jù)存儲后進行提取和分析，例如index均使用it-ocs_msb_prd-cnc-mcprocess作為頭部字符，變量命名時，使用線體名稱+工位名稱+采集變量類型的方式，例如CS2OP30EpowerConsumption，表示該變量采集的是曲軸線op30E工位的能耗等。

數(shù)據(jù)監(jiān)測

設(shè)備的各項指標，如主軸溫度、實時電流、設(shè)備耗能、PLC反饋數(shù)據(jù)等通過平臺上傳至服務(wù)器后，工程師可以遠程查看設(shè)備的各項數(shù)據(jù)，不需要在工廠設(shè)備PLC端查看或調(diào)試異常數(shù)據(jù)。但動力總成廠區(qū)內(nèi)有近500臺機加工設(shè)備，40臺自動裝配設(shè)備及320臺半自動裝配設(shè)備，并且電池工廠采用全自動電池生產(chǎn)線，若采用人工監(jiān)測異常情況，會有以下3個缺陷，效率低、時效性差、無法分析異常趨勢。

人工監(jiān)測與軟件算法監(jiān)控相比，對數(shù)據(jù)的趨勢性判斷會較差，并且對于人員的現(xiàn)場經(jīng)驗和維護理論水平有較大要求，異常情況分析時間也較長，反之，軟件算法可以快速統(tǒng)計單位時間內(nèi)溫度高于某一閾值的次數(shù)或持續(xù)時間，這些數(shù)據(jù)在圖表上不容易統(tǒng)計，人工監(jiān)測時，工程師需要查看原始文件，再逐一統(tǒng)計相關(guān)數(shù)據(jù)，耗費大量時間；軟件算法也可以對一些趨勢進行分析，例如是否存在電流值的擬合曲線參數(shù)波動，人工監(jiān)測可以看出數(shù)據(jù)值明顯的波動或突變，但難以分辨這種較小的趨勢性變化，而這種趨勢性的波動往往體現(xiàn)了某些元器件的老化或異常使用，在設(shè)備的預防性維護與性能提升等方面有著重大的意義。

數(shù)據(jù)監(jiān)控前端平臺的一個頁面內(nèi)可以選擇多個曲線進行展示，該平臺可以選擇時間段查看相對應(yīng)的曲線趨勢，也可以根據(jù)數(shù)據(jù)的更新進行曲線的實時更新，方便工程師瀏覽設(shè)備運行狀態(tài)。該展示平臺可以從兩個維度進行展示和設(shè)備監(jiān)控，數(shù)據(jù)點類型和硬件設(shè)備。一方面，可以展示所有相似設(shè)備的同一類型的數(shù)據(jù)，如溫度監(jiān)控；另一方面，可以在一個頁面中展示該設(shè)備的所有數(shù)據(jù)指標，全面監(jiān)控該設(shè)備的健康狀態(tài)。SCADA系統(tǒng)監(jiān)控如圖4所示。

圖4 SCADA系統(tǒng)監(jiān)控

除此之外動力總成工廠同事能對設(shè)備狀態(tài)進行監(jiān)控，基于SCADA系統(tǒng)，具備狀態(tài)反饋已經(jīng)效率指標的監(jiān)控，如OEE、TA 及簡單的數(shù)據(jù)處理。并借助于SCADA系統(tǒng)打通ERP 的接口實現(xiàn)業(yè)務(wù)數(shù)據(jù)流動。

數(shù)據(jù)展示

設(shè)備采集信息存儲在MSB服務(wù)器中，設(shè)備運行屬性存儲在prisma系統(tǒng)中，數(shù)據(jù)展示平臺為SFM，為了實現(xiàn)上述的設(shè)備狀態(tài)實時監(jiān)控預警、智能維護數(shù)據(jù)庫和智能化預防性維護，需要整合不同平臺的信息。上述的幾個平臺的數(shù)據(jù)導出功能操作起來較為煩瑣，沒有設(shè)計一鍵導出的功能，若人為的導出數(shù)據(jù)，需要耗費大量的時間，效率低下。智能維護及數(shù)據(jù)監(jiān)控平臺的數(shù)據(jù)導出及監(jiān)控預警均采用了機器人流程自動化(Robotic Process Automation，RPA)，根據(jù)不同軟件和數(shù)據(jù)的特征，采用了像素定位法和圖像識別定位法，實現(xiàn)一鍵自動化執(zhí)行。

數(shù)據(jù)展示平臺如圖5所示，該平臺可以實現(xiàn)靈活的看板展示功能，但是無法實現(xiàn)數(shù)據(jù)異常的預警，為了實現(xiàn)智能預警，需要將數(shù)據(jù)下載從展示平臺上下載到本地，經(jīng)過相關(guān)算法處理，再次上傳到異常預警平臺，若數(shù)值超過指定的值，數(shù)值將會顯示為紅色，同時會發(fā)送郵件給負責該設(shè)備或技術(shù)類型的工程師。由于數(shù)據(jù)較多，并且需要及時更新，人工操作的話會耗費大量時間，并且數(shù)據(jù)反饋不及時，故采用了RPA，可以自動執(zhí)行數(shù)據(jù)下載、算法執(zhí)行、數(shù)據(jù)上傳等功能，目前更新頻率為一小時，可根據(jù)設(shè)備狀態(tài)調(diào)整頻率。

圖5 MSB前端展示頁面