第3頁共3頁基于工業(yè)互聯網的設備遠程監(jiān)控和運維研究摘要在制造系統(tǒng)逐步復雜化，分散化的背景下，系統(tǒng)遠程監(jiān)控和運維成為了現代制造活動至關重要的一環(huán)。對于設備遠程監(jiān)控和運維的業(yè)務建模，通用性強的架構設計，和具體業(yè)務實現方案缺乏系統(tǒng)性的界定和實現。本文針對這些問題，首先將領域驅動設計方法與微服務設計理念進行結合，針對設備遠程監(jiān)控運維領域進行了建模。再針對于當下智能系統(tǒng)對于數據采集，數據分析，再作用于系統(tǒng)的需求，考慮到高算力和實時性保障的相互耦合因素，采用端邊云協(xié)同的架構設計，與微服務系統(tǒng)架構進行結合得到設備遠程監(jiān)控運維的總架構。并針對設備監(jiān)控，遠程運維兩個具體工業(yè)業(yè)務提出了具體實現方案，從工作流程制定，與模型、總架構實際關系，和能夠應用的算法多維度進行了闡述，并針對具體內容完成了實驗驗證。最終得到了一個系統(tǒng)性較為完備，擁有可執(zhí)行性的設備遠程監(jiān)控和運維整體方法。關鍵詞：設備監(jiān)控，遠程運維，工業(yè)物聯網，領域驅動設計，微服務目錄第一章緒論 11.1 研究背景 11.1.1 工業(yè)物聯網 11.1.2 工業(yè)人工智能 21.2 設備遠程監(jiān)控和運維的研究現狀 41.2.1 設備遠程監(jiān)控和運維的發(fā)展 41.2.2 設備遠程監(jiān)控和運維架構 41.2.3 論文研究目標 71.3 本文的結構 7第二章設備遠程監(jiān)控運維領域建模 82.1 領域建模背景與意義 82.1.1 業(yè)務建模技術 82.1.2 工業(yè)微服務技術 82.1.3 領域驅動設計與微服務 92.2 領域驅動設計建模 92.2.1 領域驅動設計 92.2.2 領域驅動設計建模架構 102.3 設備遠程監(jiān)控和運維的領域驅動建模 102.3.1 劃分子域 102.3.2 確定限界上下文 112.3.3 基于DDD的微服務總目錄結構 122.3.4 設備遠程監(jiān)控和運維微服務組件 13第三章設備遠程監(jiān)控和運維架構 153.1 端邊云協(xié)同架構 153.2 微服務架構 163.3 端邊云協(xié)同的監(jiān)控運維方案 17第四章設備監(jiān)控實現方案 194.1 設備監(jiān)控方案 194.2 基于自動編碼器的設備監(jiān)控算法 204.2.1 標準自動編碼器 204.2.2 基于AE的設備監(jiān)控算法 214.3 實驗 234.3.1 參數監(jiān)控組件 234.3.2 異?；貓蠼M件 25第五章遠程運維實現方案 265.1 遠程運維方案 265.2 遠程運維算法 285.2.1 CBM算法 285.2.2 數據驅動的PdM策略 295.3 實驗 29第六章結論與展望 316.1 結論 316.2 展望 31參考文獻 33第一章緒論研究背景由于全球化進程，現代制造活動是在地理分布越來越廣的環(huán)境中進行的，在這種環(huán)境中，中小型企業(yè)和大型企業(yè)已經形成了復雜和分散的制造網絡，由文獻[1～4]可見如今這種制造網絡的普及性。為了在分布式協(xié)作環(huán)境中實現數字化和智能化制造，中小型企業(yè)和大型企業(yè)一直面臨著越來越多的需求，首當其沖的需求是擁有能夠高效收集和分析機器和制造過程中產生的大量數據的硬件和軟件系統(tǒng)，隨后是需求能夠有效診斷已識別缺陷的根本原因、預測其發(fā)展并主動預測維護活動以最大限度減少意外機器停機時間的算法。因此大規(guī)模制造活動的智能化，系統(tǒng)化，數據的云端化，分析處理的遠程化是當下熱點的工業(yè)領域更新方向。智能網絡制造指的是使用高性能計算、優(yōu)化、模擬、傳感技術和數據分析來創(chuàng)造創(chuàng)新產品，在文獻[5]和文獻[6]中介紹了這種智能網絡制造模式。近年來，推進智能網絡制造得到了很多關注和資助。例如，根據美國的國家科學基金會(NSF)的數據，2015年至2020年有超過3億美元投資于網絡智能制造系統(tǒng)。2015年，其向28所大學授予了25個探索性研究早期概念贈款項目，以支持制造業(yè)和計算機及信息科學和工程研究人員之間的合作研究。數字制造和設計創(chuàng)新研究所(DMDII)發(fā)布了幾個項目，要求對傳統(tǒng)設備和配備數控控制器和傳感器的現代機床進行實時機器和過程監(jiān)控、診斷和預測。此外，歐盟根據地平線2020計劃也發(fā)布了幾個智能網絡物理系統(tǒng)和制造業(yè)高性能云計算基礎設施的項目招標。由此可見在國際領域內，各國家對于智能網絡制造的重視程度。設備遠程監(jiān)控和運維的研究現狀設備遠程監(jiān)控和運維有效針對研究背景中所提及的制造分布式協(xié)作模式，契合工業(yè)4.0時代，提供了一種智能化，遠程化的制造解決方案，其實現了設備側，邊緣側，云側的物理分離卻又信息互通互聯，相互配合，提供了設備數據采集，管理存儲，使用高計算力進行數據分析等符合當下智能制造需求的眾多重要功能模塊。設備遠程監(jiān)控運維技術隸屬于工業(yè)人工智能，屬于工業(yè)人工智能的一個具體應用場景。設備遠程監(jiān)控運維的目的是將各種不同類型的設備的實時運行數據收集，集中管理，進行數據分析，并能夠一并進行個性化的可視化展示，監(jiān)控功能為通過一定的算法識別出設備故障并及時報警，運維功能為基于數據對設備進行維護。這往往不同于傳統(tǒng)制造過程中，采集的數據有限，且只能在有限的設備現場附近某一控制室可見，而是數據實時發(fā)送到云端，可以在任何位置的任何有權限的終端查看實時數據，故障內容信息，推薦的運維策略等。設備遠程監(jiān)控和運維的發(fā)展設備監(jiān)控的概念其實早已存在，早期在設備上直接使用儀表直接測量顯示部分過程量其實就是監(jiān)控的概念。后來發(fā)展為在設備現場附近的集中監(jiān)控室，在其中集中放置了接出的儀表數據，派專人進行監(jiān)控。如今在工業(yè)物聯網以及工業(yè)人工智能概念的提出和發(fā)展下，提出了設備聯網遠程監(jiān)控的概念。設備維護策略已經存在修復性維護、定時維護、視情維護等許多維護策略[10-12]。修復性維護（Correctivemaintenance，CM），也可以被稱為事后維護（Breakdownmaintenance，BM）指在故障已經發(fā)生后進行停機維修，它可以歸屬于典型的非計劃之內維修策略[13]。CM帶來的制造停滯時間非常長，對機器，產線所帶來的危害完全不可控。定時維護（Time-basedmaintenance，TBM）根據每個獨特制造過程的計劃制定以及歷史經驗，按照計劃好的時間間隔進行停機的大規(guī)模檢查，來發(fā)現那些設備的老化，即將損壞現象，來保證安全性和可持續(xù)性。這種維護策略的停機時間也很長，每次檢查耗費的人力也很高，但相比于修復性維護，對機器，產線的安全性保護較好。視情維護（Condition-basedmaintenance，CBM）指的是以機器，系統(tǒng)的工作運行狀態(tài)為依據，對于那些關鍵部分的關鍵狀態(tài)定期，連續(xù)，甚至實時進行監(jiān)控，當產生了不合理狀態(tài)時，進行維護。CBM是一個寬泛的概念，通常涵蓋基于退化模型對實時數據進行判斷的維護策略，在工業(yè)人工智能的背景下產生了預測性維護（Predictivemaintenance，PdM）的維護策略，指使用工業(yè)人工智能算法對大數據進行分析，從而預測系統(tǒng)剩余使用壽命（Remainingusefullife，RUL）的維護策略。設備遠程監(jiān)控和運維架構端云架構設備遠程監(jiān)控運維的傳統(tǒng)端云架構指的是在設備端采集數據，將數據從傳感設備流式傳輸到云中，在那里進行處理和建模。傳感設備通常在短時間內，連續(xù)或周期性地產生大量數據。例如，一秒鐘內，一臺機器可以生成數千條記錄[14]。根據思科云指數(2013-2018)，一個自動化設施每小時可以生成萬億字節(jié)的數據。為此，使用采樣、壓縮、過濾等方法來減小數據大小。這些技術可以減少轉發(fā)到云中的數據量。這種架構是設備端與云端的直接互聯，著重于數據的處理，下面具體介紹：采樣，采樣指的是從輸入數據中獲取數據點的頻率。比如它可以描述了被轉發(fā)的頻率感應值為每秒，每分鐘，或者每小時。這通常用于具有頻繁冗余值的應用程序。拿恒溫監(jiān)控來簡單舉例，可以用較少的樣本進行推斷或決策。下面回顧一些最近的采樣手段：文獻[15]中提出的方法通過在數據流上應用儲層和隨機采樣，并在聚合器中關聯指示數據值重要性的權重。這種方法的問題是權重與數據點的乘積最終會改變值。這使得它不適用于要求實際值或特定范圍內的值的應用。與這種方法不同的是，在[16]中提出的技術并不改變數值。它基于兩個子集、最大值和最小值，聚合節(jié)點使用這些子集來獲得近似流，這種方法可能會很好地解決重復值的問題。壓縮，數據壓縮是一種重要的減少數據量方法，數據在傳輸到云進行進一步處理分析之前先會被壓縮。在文獻[17]中，作者提出了一種節(jié)能的方法來壓縮物聯網設備的多元時間序列數據。該方法中調整了最初是為壓縮高性能計算應用程序的數據而提出的壓縮算法。傳感器節(jié)點進行數據壓縮處理，以及重建，并轉發(fā)到云端。作為用例，他們使用文獻[18]中的數據集來確定駕駛員的壓力水平，給出了心電圖信號、呼吸和心率等特征。結果表明，數據挖掘模型可以有效地預測使用壓縮數據，而不損害準確性。此外，結果還表明該方法在智能設備的計算時間和能耗方面是有效的。融合，來自各種流的數據被融合來減少數據冗余、提高數據質量、提高可靠性、處理丟失的數據以及擴大被監(jiān)控區(qū)域的覆蓋范圍。在文獻[19]提出的研究中，首先借助拉格朗日多項式在傳感器節(jié)點上對數據進行約簡，然后將其發(fā)送到云服務器。端云結構如下所示：圖SEQ圖\*ARABIC4端云架構圖 端云架構的弊端：雖然端云架構減少了云中發(fā)送、存儲和處理的數據，但采樣、壓縮和融合等傳統(tǒng)方法主要在設備本身上實現，分析在云中執(zhí)行。傳感器節(jié)點有限的資源影響了復雜算法的實現。隨著物聯網應用的發(fā)展，這種情況變得更加嚴重，因為物聯網應用涉及豐富的數據類型，如圖像。此外，由于延時問題，在云中開發(fā)實時分析幾乎是不可能實現的，不同的物聯網應用幾乎都需要本地分析。例如，基于本地分析，在生產環(huán)境中快速打開/關閉某些設備的決定可以避免災難性情況。這些本地分析在這種架構中，被放置在了傳感器，也就是端側。對于一些微小的傳感器來說，這種算法在計算上非常昂貴，同時，微型傳感器的能耗也是一個重要問題。因此，用端云架構實現實時目標似乎是成本極高，難以實現的。端邊架構為了擴展云計算并將高性能計算能力帶到企業(yè)網絡的邊緣，思科引入了邊緣計算[20]。邊緣計算，也稱為霧計算或霧化，是一種在邊緣設備(如無線路由器和廣域網接入設備)和云計算數據中心之間提供高性能計算資源、數據存儲和網絡服務的計算模型[21-23]。在云計算中，大量數據必須傳輸到云上的數據中心，從而產生巨大的性能開銷。與云計算相反，訓練大型數據集和可視化數據分析等計算密集型工作負載是在邊緣計算中進行的，在邊緣計算中收集和存儲大量數據，而不是集中云存儲。邊緣計算的一個關鍵優(yōu)勢是，它使用戶能夠通過將計算節(jié)點移動到更靠近本地物理對象或設備的位置，并直接在大數據上執(zhí)行應用程序，避免在邊緣設備和云計算數據中心之間傳輸大量數據。因為邊緣計算非常接近原始數據源，所以邊緣計算能夠顯著減少延遲。這對延遲敏感的應用尤為重要。思科將邊緣計算應用到智能電網中，在智能電表等邊緣設備上執(zhí)行能源負載平衡應用，實現實時應用和位置敏感服務[24]。邊緣計算的另一個關鍵特征是，它是保護基于云的制造系統(tǒng)的有效方法[25]。端邊架構是設備端與邊緣端的直接互聯，不涉及云端，意味著將算力全部放在靠近設備端的邊緣側。在文獻[26]中，作者考慮了所提出的混合架構中的延遲要求。他們提出的混合架構由邊緣服務器和傳感設備組成。采用這種架構的，如在文獻[27]中，邊緣服務器首先對提取的圖像數據進行預處理，并將其轉換成基于文本的時間序列數據。一旦數據準備好，它們就被傳送到長短期記憶人工神經網絡。第二個組成部分，也是該方法的新穎之處，是通過粒子群優(yōu)化算法對長短期記憶人工神經網絡參數進行調整。端邊結構如下所示：圖SEQ圖\*ARABIC5端邊架構圖基于這種架構設計的框架有幾個好處。首先，該架構需要更少的通信資源以及更少的云資源負擔。其次，如果被設計成獨立于云之外工作，技術甚至可以在完全沒有連接的情況下工作。第三，使用這種體系結構，滿足實時要求是可能的。第四，當邊緣側在本地處理數據時，它也滿足了安全性和隱私方面的考慮。但端邊架構有一個致命的問題，在于在近設備側構建一個邊緣側，提供的算力往往是有限的，同時，構建的成本十分高，但卻只能針對于這一個工業(yè)現場，使得這種架構的應用十分受限。例如，構建一個峰值性能為幾十億次的大規(guī)模高性能計算集群的初始成本是幾百萬美元[23]，而運營和維護這樣一個集群的成本每年可能超過一百萬美元。端邊云架構由于邊緣計算的提出，端邊云架構自然得以提出。實際上，在工業(yè)物聯網的架構設計中往往都設置了邊緣層，但是在針對于設備監(jiān)控運維的具體應用場景中，實際系統(tǒng)設計了端邊云架構并實施的案例較少。由于不同于兩側結構，端邊云的三側結構存在算力如何分布設置；云側，邊緣側分別獲取，存儲哪部分的數據等眾多問題，分歧大，不同情形下個性化程度也很高。論文研究目標如今基于物聯網和工業(yè)人工智能的概念，很多企業(yè)都提出了自己的物聯網架構，在云側放置了許多功能模塊，然而每個功能模塊適宜的架構，實行方案，運用的技術都不盡相同。而往往他們對于具體功能模塊的實現是不展示給公眾的，而每個模塊的落實，研究才是真正能夠推動工業(yè)智能發(fā)展，將應用與理論更好結合的關鍵。在學術研究方面，針對于設備監(jiān)控和運維的學術研究集中于具體算法的開發(fā)研究，而較少考慮整體架構的部署。因此本文致力于就端邊云協(xié)同環(huán)境下的設備遠程監(jiān)控與運維提出具體的架構，方案設計。本文的結構第一章為緒論，在研究背景部分簡要介紹了工業(yè)物聯網以及工業(yè)人工智能的相關內容，并且對于設備遠程監(jiān)控運維的發(fā)展以及通常采用的架構基礎進行了簡單分析。 第二章為設備遠程監(jiān)控與運維領域建模，首先對于業(yè)務技術和微服務做了簡要介紹，微服務作為一種架構風格，領域驅動設計是符合這種架構風格的方法論。之后介紹了領域驅動設計的相關內容，并對設備遠程監(jiān)控運維進行了領域驅動建模。 第三章為設備遠程監(jiān)控運維架構，首先在緒論基礎的架構研究基礎上，針對設備遠程監(jiān)控運維場景，設計了端邊云協(xié)同的架構，并在此基礎上，結合第二章獲得的領域驅動建模模型和微服務內容，對架構進行了深入具體化，得到了設備遠程監(jiān)控和運維的端邊云協(xié)同微服務整體架構。 第四，五章分別針對于設備監(jiān)控和遠程運維兩個工業(yè)業(yè)務的詳細方案進行設計，并進行了相關實驗。第六章對全文做出了總結和展望。第二章設備遠程監(jiān)控運維領域建模領域建模背景與意義業(yè)務建模技術業(yè)務建模指的是根據最終端業(yè)務對象的屬性進行企業(yè)系統(tǒng)的搭建，比起傳統(tǒng)的由上至下的企業(yè)系統(tǒng)搭建模式，業(yè)務建模由終端為基礎構建，更加貼合業(yè)務模塊，同時能夠更好地得知組織的當前情況，更易于基于市場需求開拓新的業(yè)務模塊，組織的溝通協(xié)作也會更加流暢。業(yè)務建模擁有很高的組織自由度，根據業(yè)務開展規(guī)劃的風險也相對較低，整個組織結構較輕，便于重組，應對變化能力強。根據業(yè)務進行建模可以大致分為3個時期，初步成型期對應于1980年前后，出現了集成計算機輔助制造定義方法，Petri網方法等等；而在1980至1990年間，出現了計算機集成制造開放系統(tǒng)結構CIMOSA(ComputerIntegratedManufacturing-OpenSystems2Architecture)方法；1990年后，統(tǒng)一建模語言（UML）被創(chuàng)建，它又在對象管理組織（OMG）的相關工作下得到了統(tǒng)一標準方案，此時相當大規(guī)模的企業(yè)、個人、組織都開始利用這種語言進行系統(tǒng)的模型建立。為了擁有相應于的具體化的體系描繪，分別對應建立的粗略的業(yè)務模型，UML獲得了擴展版本，更加貼合了整個社會對其的預期效果。業(yè)務模型是對企業(yè)（機構、組織）內部組織及其業(yè)務流程的抽象描述，包含組織結構模型、資源模型、業(yè)務過程模型和業(yè)務信息模型。這幾種模型之間相互補充，共同完成對業(yè)務的描述[28]。業(yè)務建模存在廣泛被認可的3個發(fā)展的方向：首先是對于模型的建立的方法論需要一個統(tǒng)一的標準。傳統(tǒng)意義上而言，模型都以形象的圖形或者符號來代表，這種方式易于人的直觀接受和理解，但在這個信息化的時代。大部分信息以數據的信息在互聯網存儲，傳遞，但圖形難以被計算機直接辨識，容易產生識別錯誤，帶來錯誤產生的可能性。因此一種便于接受的模型表達方法，不論是對人的視覺識別，還是對計算機的代碼識別，都有一種新的需求。優(yōu)化相關的具體內容。業(yè)務模型得到之后的一大功能是指導企業(yè)完成內部各個模塊的自我評價和判斷，包含現存實施流程是否合理，組織的構建方式是否合理，資源的配置方式是否合理等等，更重要的是得到了這樣的結論之后，需要有對應的方法論來指導模型應當如何優(yōu)化，模型的優(yōu)化當下的成體系的知識十分匱乏。最后是能夠支撐業(yè)務建模的廣泛普適性的軟件。進行業(yè)務建模是時代趨勢，各種企業(yè)都需要一個統(tǒng)一的平臺來提供建模服務的支撐，這不僅是便利性的問題，同一被廣泛認同的平臺成為了一種標準之后，對于模型的理解也變得容易。這個軟件中需要提供各種細小的具體服務，能夠使用于各種領域的企業(yè)完成建模工作。 工業(yè)微服務技術微服務指的是一種構建架構的思路和風格，這種模式提倡將一個大型的應用或者任務，拆分為一塊塊的微型服務進行獨立實現。微型服務與微型服務彼此之間是相對獨立的，在各自的進程中運行，但可以通過一些簡單的輕量的機制實現互通協(xié)作。另外，微服務可以獨自存在，用于完成某一個具體的任務，但也可以通過組合完成一個龐大的任務。 與傳統(tǒng)的單體，集群，分布式的結構進行比對，微服務架構具有極度優(yōu)越的可維護性，相對簡單性，可再利用性。微服務架構把大任務拆解為了多個獨立存在的微服務，對于每個微服務進行維護是十分簡單而直觀的，同時微服務僅是有效拼接完成了對某一大任務的實現，相對于傳統(tǒng)架構它們并不只服務于特定應用，因此有小模塊相同的其余大任務需要實現時，可以再次使用之前布置的微服務進行有效拼接。此架構的奔潰風險也是相對較低的。 微服務擁有兩個主要特性： 松耦合：微服務的重要屬性之一，就是能夠實現獨立的編寫，改動，部署，作為一個服務，基本不需要依賴系統(tǒng)中的其他部分可以獨立存在運行以及維護。松耦合的特性造成了整個系統(tǒng)的高維護性，因為每個微服務相對獨立，當停止運行故障的微服務時，對其進行單獨維護而不會對其他微服務產生致命影響。達到松耦合屬性的前提是開發(fā)每個微服務是需要盡可能少的掌握其他服務的信息，不考慮與其他服務的協(xié)作可能。 高內聚：指的是一個微服務內需要聚合了盡可能多的同類型內容，微服務不意味著微服務總量的大，屬性的雜亂，甚至存在部分功能重疊。每個微服務需要是對于某具體任務高度凝練的，這種基礎上，才使得了微服務與微服務之間的區(qū)分明確，共同構建大型任務以及再次使用必須基于高內聚的前提下完成。 工業(yè)微服務指的是將微服務的思想運用于實際工業(yè)場景之中，將工業(yè)任務拆分并具體定義，以工業(yè)微服務組合實現。領域驅動設計與微服務微服務是一種理念，需要具體系統(tǒng)的設計方法和實現方案。而領域驅動設計（DomainDrivenDesign，DDD）是一種具體設計方法，從業(yè)務層的角度出發(fā)，嘗試將一個高度復雜的業(yè)務領域細化拆分。實際上，領域驅動設計在2004年就已經被提出，逐漸發(fā)展已擁有了完整的實現方法體系，但在微服務概念不被認可的情況下，對DDD了解的個體、企業(yè)十分有限，使得DDD沒有應用的場景。 微服務的理念和領域驅動設計開發(fā)的初衷完全匹配，實現了無縫對接。DDD給微服務提供了具體的拆分設計方法論。領域驅動設計建模領域驅動設計領域驅動設計包含有兩大主要設計，戰(zhàn)略和戰(zhàn)術。戰(zhàn)略設計著重業(yè)務角度，區(qū)分了業(yè)務與業(yè)務之間的領域邊界，針對于這些界限建立限界上下文，并且構建領域模型。而限界上下文可以作為微服務劃分和實現的依據。戰(zhàn)略設計包含以下重要內容：領域/子域領域指針對一個問題所有內容的集合，包括相關知識，相關行為等等。被劃分在一個領域內的可以被視作一個系統(tǒng)，它們針對的業(yè)務內容高度重合，需要解決的問題也是歸一的。因此可以認為，領域等同于一個問題域。而對于領域進行更細一層的劃分就成為了子域，它們的劃分方法和領域相同。通用語言和限界上下文通用語言指一個團隊內采用不會引起歧義，簡潔卻又精準的語言；通用語言同常說的語言相同，具有語境，語境是不產生歧義的前提條件，因此限界上下文對應的就是在規(guī)定某一個限界，在這個限界內采用通用語言可以無障礙卻又最簡潔達到互相理解配合的目標。相關性討論首先子域和限界上下文存在關系，子域是DDD在問題空間對進一步問題的細劃分；而限界上下文是解決空間的概念，不僅僅局限在問題本身，而涉及到了解決方案。但是解決方案需要針對對應的問題，所以限界上下文往往存在于某個子域之中。由于限界上下文是針對某一具體問題的解決方案，因此可以根據限界上下文對于微服務類進行劃分。但往往微服務類仍具有較大的規(guī)模，不利于具體實現，因此微服務類又被劃分為更具體的組件。戰(zhàn)術設計包含以下重要內容：實體實體是領域中需要唯一標識的領域概念。由于實體有生命周期，需要為實體定義一個唯一標識，使實體可以從創(chuàng)建后被可持續(xù)化到數據庫，在某個時候又可以被取出。值對象值對象沒有唯一標識，這是它和實體的最大不同。值對象在判斷是否是同一個對象時是通過它們的所有屬性是否相同，如果相同則認為是同一個值對象。值對象另外一個明顯的特征是不可變，即所有屬性都是只讀的。因為屬性是只讀的，所以可以被安全的共享；當共享值對象時，一般有復制和共享兩種做法，具體采用哪種做法還要根據實際情況而定。領域驅動設計建模架構領域驅動設計架構分成用戶接口層(InterfaceLayer)、應用層(ApplicationLayer)、領域層(Domainlayer)以及基礎層(InfrastructureLayer)。表SEQ表\*ARABIC1領域驅動設計建模架構分層英文描述用戶接口層InterfaceLayer存放與前端應用交互的代碼。應用層ApplicationLayer存放與應用層服務組合和編排的代碼。向下針對領域服務和應用服務，向上為用戶接口層提供數據支持服務。領域層DomainLayer存放與領域層核心業(yè)務邏輯相關的代碼?？梢园鄠€聚合代碼包，共同實現領域模型的核心業(yè)務邏輯。基礎層InfrastructureLayer存放與基礎資源服務相關的代碼。為其他各層提供的通用技術能力，數據庫服務，配置和基礎資源服務代碼都在此層中。設備遠程監(jiān)控和運維的領域驅動建模首先將設備遠程監(jiān)控和運維視為一個領域，這是一個業(yè)務邏輯較為復雜的領域，但相對于具體工業(yè)制造過程又相對獨立，并且含有多個業(yè)務對象，因此對設備遠程監(jiān)控運維進行建模有一定價值。一旦對該領域建立起宏觀模型，便可適用于各式各樣的工業(yè)生產設備。本節(jié)運用2.2節(jié)的領域驅動設計建模內容對該領域進行領域建模。主要包含劃分子域，確定限界上下文，總目錄設計，微服務組件劃分四個部分。劃分子域領域可以拆分成為多個子域，拆分的過程相當于大問題拆分為小問題的過程。將這六個內容作為設備遠程監(jiān)控與運維的子域：設備信息，狀態(tài)監(jiān)測，智能算法，歷史數據，維保中心，遠程控制。設備信息域主要提供設備本身的基本信息，關注設備的設定，任務等信息。狀態(tài)監(jiān)測域包含了對于設備加工情況的全部相關問題。智能算法域包括了各種傳統(tǒng)或新興算法的集合，同時包含基于數據的決策問題。歷史數據域負責記錄設備運行歷史，停機歷史，統(tǒng)計產量趨勢，不良原因等，還可用于查詢歷史數據。維保中心域用于指揮和管理設備的維修保養(yǎng)措施。遠程控制域可以讓工業(yè)生產人員對工業(yè)生產設備進行直接控制和參數修改。通過劃分子域，設備遠程監(jiān)控與維護這一領域被拆分成六個子域，可視作為六個子業(yè)務，業(yè)務分解便于理清各個業(yè)務之間的邏輯關系和各個團隊的負責工作。 子域與領域的包含關系如下圖所示：圖SEQ圖\*ARABIC6子域劃分確定限界上下文限界上下文更多考慮的是領域對象的語義邊界和技術實現細節(jié)。限界上下文的劃分體現的是更為詳細的解決問題的過程，該過程劃分了上下文語義邊界，完成了領域模型。設備信息域有機器屬性，生產屬性，實際狀況三個限界上下文。狀態(tài)監(jiān)測域有產量監(jiān)測，異常監(jiān)測兩個限界上下文。智能算法域有知識庫，推斷服務兩個限界上下文。歷史數據域有行事歷，故障統(tǒng)計，生產統(tǒng)計三個限界上下文。維保中心域有備件訂購和現場維修兩個限界上下文。遠程控制域有異?；貓螅脑O備設定，寫入驗證三個限界上下文。圖SEQ圖\*ARABIC7限界上下文劃分基于DDD的微服務總目錄結構基于2.2中的DDD四層架構，設計了具體的架構以及它們所對應的子目錄。在符合基礎實際應用的前提下，進行了基礎層，領域層，應用層以及接口層的設計安排，基礎層需要完成的功能包括了文件部署、信息配置、定時、單元測試、基礎工具、中間件和初始化，作為后續(xù)實現的基礎，其體量較為龐大；領域層主要對應于通用數據結構，應用層對對應于應用；接口層完成交互內容。圖SEQ圖\*ARABIC8基于DDD的微服務總目錄結構設備遠程監(jiān)控和運維微服務組件基于2.2小節(jié)的內容，限界上下文可以作為微服務類的劃分依據，但為了更利于具體算法的實現，每個微服務類中的眾多功能需要進一步聚合，此小節(jié)對于限界上下文對應的微服務類進行了組件維度的進一步劃分。如下表所示：表SEQ表\*ARABIC2微服務劃分子域微服務類組件設備信息機器屬性查詢設備列表，設備詳情，設備通訊方式，設備任務生產屬性查詢產品分類，產品工藝，生產區(qū)域，生產線，常用人員實際狀況查詢實際生產狀況，實際運轉狀況狀態(tài)監(jiān)測產量監(jiān)測今日生產進度，生產日報，生產情況分析，產量分析異常監(jiān)測參數監(jiān)控，異?；貓螅\轉情況分析，當日設備異常異常原因，稼動時間，異常設備數量，設備綜合效率智能算法知識算法庫傳統(tǒng)算法，人工智能算法推斷服務庫遠程診斷，故障原因分析，停機原因分析歷史數據行事歷查詢行事歷，停機行事歷，設備停機日志，延時工單查詢生產統(tǒng)計產量統(tǒng)計與趨勢，設備稼動設備歷史數據記錄設備歷史數據記錄故障統(tǒng)計歷史異常原因，歷史故障原因與故障碼，不良原因統(tǒng)計維保中心備件訂購備件訂購現場維修現場維修遠程控制異?；貓螽惓；貓蟾脑O備設定開關控制，參數設定寫入驗證寫入驗證

第三章設備遠程監(jiān)控和運維架構本章提出了設備遠程監(jiān)控和運維的整體架構，在3.1小節(jié)中提出了端邊云協(xié)同的基礎架構，并且闡述了三側的具體功能和這種架構的優(yōu)越性；3.2小節(jié)介紹了微服務架構；3.3小節(jié)中依據微服務相關內容，對3.1小節(jié)的基礎架構進行了完善和補充。端邊云協(xié)同架構結合緒論對于架構的介紹，監(jiān)控和運維往往涉及到端側，邊緣側，云側三側；基于領域驅動建模的結果，各子域對于云側都有著不同程度的需求，其中狀態(tài)監(jiān)測子域對于邊緣側的低延時特性有特殊需求。因此，本文對于監(jiān)控運維領域進行了端邊云協(xié)同的基礎架構設計，如下圖所示：圖SEQ圖\*ARABIC9端邊云架構圖端邊云架構由三側式構成，下面將對每一側進行介紹：端側：端側包含設備本身以及網關設備。通過數據采集網關設備可以收集機器數據，它們利用傳感器網絡、通信適配器、傳感器適配器和輸入/輸出適配器從工廠車間收集實時流數據。這些適配器是基于通信協(xié)議開發(fā)的，例如簡單對象訪問協(xié)議（SimpleObjectAccessProtocol，簡稱SOAP）、MTConnect和開放平臺通信統(tǒng)一架構（OpenPlatformCommunicationsUnifiedArchitecture簡稱OPCUA）。數據采集網關設備將不同設備采集到的不同格式、類型的數據通過針對不同協(xié)議的適配器轉換為統(tǒng)一格式的數據。同時，網關放置在端側，提供了數據初步處理后直接上傳云側的功能，當整個制造體系中含有難以構建邊緣側的設備現場時，依舊可以完成數據上云。在緒論部分提及了CPS的5C架構，端側對應于智能連接層，起到了將設備數據統(tǒng)一識別，采集的功能。另外其具有數據分流功能，通過設定，一部分數據將作為樣本數據集被分流，以供云端使用。 邊緣側：邊緣側位于靠近端側位置，其實也可稱其為私有云，是具有一定算力和存儲能力的云，只有企業(yè)內部擁有查看操作的權限。其包含兩個組成部分，邊緣服務器和本地存儲設備，通過端側采集到的實時數據保存在本地存儲設備之中；而邊緣服務器與上端云側，下端端側均處于連通狀態(tài)，其可以從云側下載已經訓練完成的模型，將其運用于實時的在線數據，以此來實現對設備的監(jiān)控；同時在常規(guī)應用場景中，邊緣側起到數據中轉的作用，將部分歷史數據作為云側數據分析的樣本數據集上傳至云側。 邊緣側對應于CPS中的智能執(zhí)行層，起到了將模型運行對設備運行狀態(tài)進行監(jiān)控的作用。 云側：云側指的是公有云，是第三方提供的云，具有強大的計算能力，并且提供了高擴展性的功能模塊。在云側可以充分對數據應用工業(yè)人工智能算法，也可以制定合適的有依據的決策方案，同時可以進行相關應用的開發(fā)以及使用。 云側對應于CPS中的智能分析層，網絡層，智能認知層，基于數據的各種操作均在此處實現，同時由于其與位于公網，與網絡環(huán)境內的其余信息也可實現交互，從而可以擁有更加強大的功能。采用此端邊云架構，具有以下原因和優(yōu)勢：首先，邊緣側具有靠近端側，數據傳輸延時低，數據傳輸成本少的突出優(yōu)點；并且邊緣側作為私有云，數據的安全性得到了完全的保障，只有極少數擁有權限的人才能接觸到邊緣側存儲的數據。但同時它具有搭建成本高，若要求高算力，搭建相匹配的邊緣側幾乎難以實現的問題。云側雖然遠離端側，實時處理數據并對數據作出響應是難以實現的；但在算力方面，云側遠遠超越邊緣側，且作為公有云，第三方會提供比較于自建大規(guī)模邊緣服務器相對較低的計算成本。在安全性方面，公有云要求數據上傳第三方平臺，就存在了數據泄露的可能性。因此本文提出的針對設備監(jiān)控和運維的端邊云架構，結合了邊緣側，云側各自的優(yōu)點，且對于成本，安全性進行了考量。將全部實時數據存儲于邊緣側是考量到了數據安全性，同時近距離傳輸數據成本較低；邊緣側還承擔了下載云端模型執(zhí)行監(jiān)控，這一功能所需要的算力較小，但卻可以滿足實時分析，實時響應的要求。將樣本數據集發(fā)送至云端進行算法執(zhí)行，充分利用了云端的強大算力，并且這些離線數據的處理對于時效并沒有太高的要求。值得注意的是，樣本數據集是企業(yè)篩選之后發(fā)送給公有云的，也保證了數據的安全性。微服務架構在第二章中，基于領域驅動設計，對設備遠程監(jiān)控運維這個領域劃分了6個子域，在子域之中又包含了各自的界限上下文，最終組成了相對應的關鍵微服務。微服務是業(yè)務的劃分，實際運行需要基于一個通用的代碼架構之下。微服務架構需要能夠提供以下三個重要功能：實現大型應用的持續(xù)交接和布置應用、使多團隊合作開發(fā)成為現實、擁有故障的分隔功能。目前較為成熟的有以下微服務架構：gin，Dubbo，SpringCloud等。本節(jié)將對gin架構進行介紹。gin是采用Golang撰寫的Web架構，它具有性能高，量級輕，應用程序接口易用等特點。gin架構主要有以下功能與優(yōu)勢：它采用基于基數樹的路由，占用內存少，且具有訪問快速性；傳入的HTTP請求可由一組中間件，如記錄，授權，壓縮等，和最終操作組合完成；能夠捕獲HTTP請求期間發(fā)生的突發(fā)情況并恢復；更好的路由組織形式；采集請求期間發(fā)生的錯誤；可擴展性非常強，可以自定義中間件。gin的整體結構可以視作一個總引擎，保存了各個組件的信息，其中RouterGroup為路由組，保存路由信息；trees是樹結構，保存了url和handler的映射關系；pool用于存在context，context主要對于請求過程進行值傳遞。示意圖如下所示：圖SEQ圖\*ARABIC10gin架構端邊云協(xié)同的監(jiān)控運維方案在3.1小節(jié)中給出了基礎的端邊云架構，介紹了為了實現設備遠程監(jiān)控與運維的目的，設備，網關，存儲，服務器等部分有效的組織構建形式。在本小節(jié)中，將結合第二章中的四大微服務劃分，以及微服務架構中需要包含的具體部分，對3.1小節(jié)中的結構進行完善和補充，獲得最終的基于端邊云協(xié)同的設備遠程監(jiān)控與運維微服務架構。完整架構圖如下圖所示：圖SEQ圖\*ARABIC11端邊云協(xié)同的總架構端側以及邊緣側的實現功能、部署設備在3.1小節(jié)中已經完整介紹，此小節(jié)對于云側部分進行了詳細擴充。依據工業(yè)物聯網架構，云側具體包含3個大部分，云基礎設施IaaS層、工業(yè)平臺PaaS層、應用SaaS層，以下分別介紹：云基礎設施IaaS層中最重要的部分為API（ApplicationProgrammingInterface）網關，其包含了統(tǒng)一數據接入，協(xié)議轉換與適配，流量管理和容錯，安全保護四個主要功能。對于微服務架構而言，雖然獲得了低耦合，高類聚的一個個模塊化的微服務，對于組建新的業(yè)務或實現新的功能提供了極大便利，但是同樣擁有各自采用的協(xié)議不相同，安全性不能得到保障等等問題，而部署于云端的API網關很好地解決了這些問題。因此不論是樣本數據集的上傳還是獲得的模型的下載全部需要通過API網關進行中轉。工業(yè)平臺PaaS層中主要包含兩個模塊，云數據庫和組件微服務模塊。云數據庫對于上傳云端的樣本數據集進行存儲；組件微服務模塊包含大量的小型組件，具體表現為簡單，體量小的實現少量功能的代碼，組件又分為基礎微服務組件和工業(yè)微服務組件?；A微服務組件提供了任何微服務運行都需要的公用組件，例如權限的授權，消息的發(fā)送接收等等；而工業(yè)微服務組件包含了最終實現的微服務內容的個性化組件，例如一個工業(yè)人工智能算法實現的組件，一個對象的機理模型輸入組件等等。而由這些大量組件進行合理組合，實現了具體業(yè)務功能的構成了一個微服務。因此，在此架構下組件微服務模塊對應于設備信息，歷史數據，狀態(tài)監(jiān)測，智能算法，維保中心，遠程控制六個子域中的相應微服務，以及它們各自需要的組成組件。應用SaaS層對應于開發(fā)的工業(yè)APP，是設備監(jiān)控運維的最終端，可以在工業(yè)APP查看基于四大微服務得到的整體數據、具體數據、獲得決策等等，同時可以從APP發(fā)送指令給云端，一層層下放至端側進行實施。

第四章設備監(jiān)控實現方案本章節(jié)基于設備遠程監(jiān)控和運維的總體架構，針對設備監(jiān)控工業(yè)業(yè)務，給出了實現方案。首先展示了設備監(jiān)控業(yè)務涉及到的微服務類及其組件，基于設備監(jiān)控業(yè)務的需求設計了具體方案并進行了相關實驗。設備監(jiān)控方案如今工業(yè)制造的發(fā)展趨勢是形成復雜而分散的制造網絡，具體而言，每家企業(yè)的制造設備可能分散于各地，而非全部集中于一個設備現場；而完成一個最終產品的過程中使用的設備可能隸屬于不同企業(yè)。因此需求一種通用性高的設備監(jiān)控方案，它能夠適用于這種復雜而分散的制造網絡，在設備現場保留實時監(jiān)控的能力的同時，也能夠提供強大的計算能力支持，而最終的可視化顯示能夠實現隨時隨地的便捷性。在第二章中進行了領域驅動建模，設備監(jiān)控業(yè)務由以下微服務與組件構成：圖SEQ圖\*ARABIC12設備監(jiān)控業(yè)務微服務基于設備監(jiān)控業(yè)務的業(yè)務邏輯，本節(jié)的設備監(jiān)控方案分為了離線部分以及在線部分兩大部分進行實現。離線部分的主要功能為在云側完成對于歷史數據樣本集的數據分析，產生一系列可靠的可以作用于制定設備現場的監(jiān)控依據。由于數據上傳云側，以及工業(yè)人工智能算法的應用需要一定的時間成本，因此該模塊設置為離線模式，不需要時間限制，從而追求將云側高算力發(fā)揮至最大，致力于提供一個準確的監(jiān)控參照依據。而在線部分指的是在邊緣側將云側得到的監(jiān)控參考依據應用于實時采集到的設備數據，這是真正的監(jiān)控模塊，對于實時性要求高，但并不需要很強的計算能力，因此將這個模塊部署于邊緣側。如下圖所示，下面將以按時間線發(fā)生的4步具體工作流程進行具體地闡述：步驟1：在端側通過網關設備收集機器數據。步驟2：將原始數據集和樣本數據集分別流式傳輸到本地私有邊緣云（邊緣側）和遠程公共高性能計算云（云側）。通過數據采集網關設備，實時數據集被收集并流式傳輸到本地專用邊緣云中。同時，通過邊緣服務器的處理篩選或者直接通過數據采集網關設備，樣本數據集（訓練數據集）被流式傳輸到遠程公共云中。步驟3：在云側對獲得的樣本數據集進行組件的執(zhí)行，進而完成對應的微服務流程工作，獲得輸出，輸出往往是一個模型，包含了對于在線數據是否故障的判斷標準。步驟4：將在云側訓練得到的模型應用于存儲在本地私有邊緣云中的原始數據集，在邊緣側實時獲得設備的狀態(tài)信息。步驟5：將設備狀態(tài)傳輸至云側的服務器通過應用進行顯示。圖SEQ圖\*ARABIC13端邊云架構下的工作流程圖基于自動編碼器的設備監(jiān)控算法本小節(jié)依據上節(jié)提出的設備監(jiān)控方案，提出了基于自動編碼器的設備監(jiān)控算法，將介紹自動編碼器原理，在云側如何得到作為設備監(jiān)控判斷依據的檢測統(tǒng)計量，在邊緣側和端側如何應用檢測統(tǒng)計量與實時數據進行比對達到遠程監(jiān)控設備的目的。標準自動編碼器Rumelhart[29]提出了一種無監(jiān)督的ML（machinelearning）方法，標準自動編碼器（AutoEncoder，AE）。結構中包含了輸入、編碼器、隱含層、解碼器。輸出，結構如下圖所示：圖SEQ圖\*ARABIC14自動編碼器結構自動編碼器的輸入層層數與輸出層層數相同，其目的在于重新構建輸入，而非對于目標的預測功能。編碼器fx起到了提出輸入數據的隱含層特征信息，輸入x∈Rdx通過編碼器變換到?x∈?=fx=sfWx+b?解碼器gx起到了將隱層特征?x反向變換到輸入，從而獲得輸入重構x的功能。其中W'=Wz=x=g?=sgW'?+b給定樣本數據集Dn，目標函數JAEθ是輸入x與經過解碼重構獲得的x之間的誤差和，其中g?，f?如表達式（4-1）和（4-2）所示，θ=W,bJAEθ=x?DnLx,gfx優(yōu)化目標：θ?=argmin1nLx,gfx(當輸入連續(xù)時，可選用平方誤差作為損失函數：Lx,y=x?y2(4-SEQ

公式\*ARABIC\s15此情況下采用梯度下降法最小化重建誤差：θ?=argmin1ni=1Lxi,gfxi 基于AE的設備監(jiān)控算法對應于工作流程圖的離線部分，采用了以下的算法邏輯：為了監(jiān)控設備是否處于正常的運行狀態(tài)，一般通過構建檢測統(tǒng)計量來進行假設檢驗，并基于檢測統(tǒng)計量的值是否超過了控制上限來判斷設備的運行狀態(tài)是否正常。正常工作情況下的樣本數據集定義為Dn=x:x∈Rdx，利用A對應于工作流程圖的在線部分，采用了以下的算法邏輯：輸入實時數據，同樣可以獲得特征?t∈R檢測統(tǒng)計量首先將隱含層中h∈Rd?所形成的認定為特征的子空間，誤差L=xH2H2=?T=sf當設備工作正常時，測試樣本數據會處于自動編碼器的特征子空間之中，對應的H2SPE定義如下：SPE=eTe=若數據擁有較小的重構誤差，計算所得的SPE也具有較小的值，那么就認為是正常的在線數據；若值較大則為發(fā)生故障對應的數據。核密度估計法與統(tǒng)計量的控制上限Rosenblatt和EmanuelParzen提出了核密度估計法，用于估計隨機變量的的概率密度函數[30]。其原理是假設樣本數據集的概率密度函數為fx，當新的數據進入樣本數據時，其分布也認定為符合fx。當一個樣本出現在了樣本數據集之中，那么認為它的概率密度非常大，同時與其相近的其余數據的概率密度也相對比較大，用這種想法，對樣本數據集中的每一個數據都可以f(x?xi)去擬合概率密度。對樣本數據集中的每個數據，對新的觀察樣本數據擬合多個不同概率密度函數后，取平均作為其概率密度函數[31]fx=1ni=1n其中K?是核函數，?表示核寬度，ngx=12πe?x2對于樣本數據集中的樣本對應的H2和SPE分別擬合和密度函數fx，通過選取概率密度的上0AE算法流程算法流程依舊分為離線與在線兩個部分，架構與上一小節(jié)對應設計，在算法部分根據AE算法進行了具體化。離線部分，首先對樣本數據集的樣本進行標準化，將數據變換到[0,1]區(qū)間之內，采用方法如下：(4-11)隨后利用梯度下降算法訓練AE，得到最優(yōu)的參數，從而計算檢測統(tǒng)計量H2和SPE，并對控制上限進行估計。 在線部分，對在線數據首先同樣進行標準化處理，根據參數計算檢測統(tǒng)計量H2和SPE，將其與上限進行比較，判斷是否發(fā)生故障。 具體流程圖如下所示：圖SEQ圖\*ARABIC15基于AE算法的工作流程圖實驗實驗背景為在某企業(yè)中協(xié)作共同搭建端邊云協(xié)同的微服務架構，并以數控機床為對象實現設備監(jiān)控。參數監(jiān)控組件本小節(jié)的實驗對應于第二章建模獲得的參數監(jiān)控組件，實現了數控機床數據采集，經過邊緣服務器，上傳至云端。數據與數據庫對接的同時，在用戶端界面進行顯示的功能。每一次的數據傳輸與操作對應著一個更低一層級別的組件，具體定義了相應的協(xié)議對接，端口對接，以及功能實現代碼。具體流程圖如下所示：圖SEQ圖\*ARABIC16參數監(jiān)控組件流程圖以功能組件數據處理服務為示例進行介紹，其實現了從kafka消息隊列獲得數據，對數據庫進行持久化的同時，對MQTT服務器發(fā)送數據來作為用戶端顯示的基礎。下面以數據處理服務組件為例展示代碼實現邏輯： 主函數(){ Kafka服務連接 數據庫連接 Mqtt服務連接 Kafla數據讀取 寫入數據庫寫入mqtt服務器} 連接Kafka消息隊列函數 { kafka.NewReader信息配置 { Brokers信息（消息代理） ID信息

Topic信息 傳輸速度}} Kafka數據讀取函數 { 循環(huán)數據個數的次數： Error狀態(tài)確認 非故障時：數據寫入 故障時：報錯顯示，程序暫停} 主函數中每一步分別對應于若干個函數，分別進行各個參數的對接，包括需要數據的傳輸，端口的確認，發(fā)布主題的確認等。實際代碼在golanggin架構中完成，如下所示：圖SEQ圖\*ARABIC17數據處理服務組件主函數圖SEQ圖\*ARABIC18Kafka消息隊列連接函數 可見每個組件的構成實際上十分簡潔，組件本身也是對于編寫好的系統(tǒng)性的函數進行組合的拼接調用，符合采用微服務架構的初衷。 最終在云端獲得數控機床監(jiān)控數據界面如下所示：圖SEQ圖\*ARABIC19智能橋切機設備監(jiān)控界面圖異?；貓蠼M件4.3.1小節(jié)中的實驗過程，數據在端側，邊緣側，云側單線式傳輸得到了最終的界面顯示。而設計方案中在線數據與云端獲得的檢測依據在邊緣側比較，保證了實時性，在設備端即刻作出相應后將故障情況上傳至云側顯示。因此在此小節(jié)中，完成了在邊緣側進行X，Y，Z軸坐標數據的在線數據比對，對于數控機床的一組速度量運用了AE監(jiān)控算法后在邊緣側進行監(jiān)控，隨后將數據上傳云側進行顯示。下圖展示了某一次超限后云端處理所得的報警界面，可以發(fā)現先獲得了緊停端口報警，在邊緣側發(fā)現X軸坐標異常后立刻停止了設備運行，隨后又發(fā)送了X軸負向限位的報警告知管理者異常情況的發(fā)生，實現了設計目標：圖SEQ圖\*ARABIC20監(jiān)控報警圖

第五章遠程運維實現方案本章節(jié)基于設備遠程監(jiān)控和運維的總架構，針對遠程運維工業(yè)業(yè)務，給出了實現方案。首先展示了遠程運維業(yè)務涉及到的微服務類及其組件，基于遠程運維業(yè)務的需求設計了具體方案并進行了相關實驗。遠程運維方案當今工業(yè)制造更加強調設備的安全性，制造活動的可持續(xù)性，因此遠程運維業(yè)務需要對于某些關鍵設備的關鍵參數進行數據監(jiān)控的前提下，對于數據進行分析得到設備的當前狀態(tài)，以及獲得對一定時間后的狀態(tài)預測，從而制定運維決策。遠程運維與設備監(jiān)控的區(qū)別在于，設備監(jiān)控強調實時性監(jiān)控設備當前是否發(fā)生故障，而遠程運維強調獲得設備當前和未來的設備狀態(tài)，最終目的是防范關鍵設備或部件發(fā)生故障，進而防范制造停滯甚至產生大規(guī)模損失的可能性。在第二章中進行了領域驅動建模，遠程運維業(yè)務由以下微服務類與組件構成：圖SEQ圖\*ARABIC21遠程運維業(yè)務微服務因此本節(jié)提出的遠程運維方案是一個閉環(huán)過程，通過端側邊緣側進行數據采集，為云端提供了樣本數據集，基于樣本數據集在云側進行設備狀態(tài)分析和維護決策制定，最終決策執(zhí)行于設備。基于設備情況的不斷動態(tài)更新，維護策略和實施也相應發(fā)生變化，由于執(zhí)行完整的一次閉環(huán)過程，需要耗費時間，算力，人力，因此維護策略不僅僅包括針對設備采用何種維護方法，具體更換何種設備，也需要通過設備剩余生命的衰減速度更新需要進行整個閉環(huán)過程的頻率。如圖所示，下面將以按時間線發(fā)生的3步具體工作流程對遠程運維進行具體闡述：步驟1：在端側通過網關設備收集機器數據。步驟2：將所有原始數據集和樣本數據集分別流式傳輸到本地私有邊緣云（邊緣側）和遠程公共高性能計算云（云側）。通過數據采集網關設備，所有實時數據集被收集并流式傳輸到本地專用邊緣云中。同時，樣本數據集（訓練數據集）被流式傳輸到遠程公共云中。步驟3：在云側進行設備狀態(tài)評估，作為維護決策的判斷依據。此模塊采用微服務的方式執(zhí)行，涉及到了設備信息子域，歷史信息子域，智能算法子域，維保中心子域，以及遠程控制子域。遠程運維流程圖如下所示：圖SEQ圖\*ARABIC22遠程運維流程圖遠程運維算法設備歷史數據傳入云數據庫后需要運用一定的算法才能夠對于設備的剩余壽命進行預測。這些算法在實際中以智能算法子域中知識庫微服務中的分離的組件形式存在，應用時只需要進行調用即可。遠程運維算法包含CBM，PdM兩大策略。CBM算法視情維護，即CBM指的是以機器，系統(tǒng)的工作運行狀態(tài)為依據，對于那些關鍵部分的關鍵狀態(tài)定期，連續(xù)，甚至實時進行監(jiān)控，當產生了不合理狀態(tài)時，進行維護。CBM進一步可以分為傳統(tǒng)經驗CBM和基于退化模型的CBM，傳統(tǒng)經驗CBM指的是依據一直以來的生產經驗，制定了何時應當進行維護的決策，具有不確定性。而基于退化模型的CBM存在一個判斷標準，相比于傳統(tǒng)經驗視情維護更加可靠。因此本小節(jié)重點介紹基于退化模型的CBM算法。 一臺設備在實際運行過程中，同時也在經歷逐漸退化和失效的過程，而失效退化與時間的關系往往與設備的運行狀態(tài)，連續(xù)工作時間，設備所處環(huán)境變化等許多因素耦合相關。當失效退化累積到故障閾值時，故障就會發(fā)生，這就是上一章設備監(jiān)控方案需要解決的問題。而在達到失效閥值之前，較為準確地尋找到貼合實際情況的退化模型，用于對某一時間節(jié)點后續(xù)的設備壽命預測提供參考依據。下圖展示了退化過程和失效閥值的相對關系示意圖。圖SEQ圖\*ARABIC23退化過程與失效閥值示意圖離散狀態(tài)退化模型由于無法得到系統(tǒng)退化當前狀態(tài)的精確測量值，采用離散狀態(tài)的建模手段，馬爾科夫過程模型。其將系統(tǒng)退化狀態(tài)劃分為數量有限的數個退化階段是可以實現并且具有實際意義的。馬爾科夫過程描述了空間狀態(tài)兩個狀態(tài)的切換隨機過程，設{Xt,t∈T}是取值于狀態(tài)空間E中的隨機過程,若對任意的正整數n,tPXtn+1≤xn+1Xt則稱{Xt連續(xù)退化模型如果系統(tǒng)狀態(tài)隨時間進程擁有連續(xù)退化的特性，且系統(tǒng)擁有實時可得的狀態(tài)量，則可以使用連續(xù)狀態(tài)退化模型描述其退化過程。伽瑪過程模型在1975年被引入可靠性領域[30]，當退化過程具有不確定、非遞減特征時，可將其視為伽瑪過程。伽瑪過程是擁有獨立的非負增量的隨機過程，其中增量具有相同尺度參數的伽瑪分布。設隨機過程{Y(t),Ga(y∣αt,β)= 其中α>0,β>0分別是形狀參數和尺度參數，exp??指以e為底的指數函數，Yt的均值和方差分別為αβ數據驅動的PdM策略當前已有許多基于機器學習的剩余壽命預測方法，例如基于邏輯回歸方法[32]（Logisticregression），基于人工神經網絡的方法[33]（Artificialneuralnetwork，ANN），基于支持向量機的方法[34]（Supportvectormachine，SVM），基于決策樹的方法[35]（Decisiontree，DR）等等。數據驅動的PdM策略擁有許多優(yōu)勢，首先這個概念可以應用于任何能采集到數據的設備，因為它只基于數據進行模型的生成和預測，不同于CBM任需要將設備本身和退化模型進行匹配，因此它具有較廣的應用范圍。同時，根據機器學習算法的不同，和具體參數的調整，理論上可以獲得極度貼近實際的模型，可以對RUL進行精準預測。但與設備監(jiān)控方案不同，僅需要將故障與常規(guī)數據區(qū)分，可以設計詳細的通用算法進行應用，對于設備剩余壽命的預測采用的算法必須根據實際數據的整體特征進行選擇。實驗本實驗實現了遠程診斷組件，對于數控機床的刀具進行數據采集，經過邊緣服務器，上傳至云端，對于數據庫中存儲的刀具相關的數據運用刀具管理服務，結果反送回數據庫存儲并且通過MQTT在用戶端進行顯示。每一次的數據傳輸與操作對應著一個微型組件，具體定義了相應的協(xié)議對接，端口對接，以及功能實現代碼。具體流程圖如下所示：圖SEQ圖\*ARABIC24遠程診斷組件流程圖 實際上，遠程診斷微服務在參數監(jiān)控微服務的基礎上擴展得以實現。組件刀具管理服務，首先從云數據庫中基于數據庫數據協(xié)議提取得到某一臺設備的所有相關刀具信息，查看它們的最近一次更新數據，主要是歷史總使用時間；在此基礎上加上當前更新的新使用時間，得到總使用時間。隨后從數據庫提取對應刀具的壽命時間模型，進行比對，判斷刀具的壽命情況。將壽命情況與刀具的本身信息反送回數據庫進行存儲，同時在用戶端進行顯示。最終在用戶端的刀具管理顯示如下圖所示：圖SEQ圖\*ARABIC25刀具情況總覽圖SEQ圖\*ARABIC26具體信息查看

第六章結論與展望結論現代制造擁有分散化、復雜化的趨勢，分散化具體表現在共同完成同一任務的設備分散在物理間隔較大的不同設備現場，復雜化體現于業(yè)務縱向視角下，完成一個目標需要歷經多臺設備，小產品進行組合層層組成最終產品；而企業(yè)橫向視角下，一個企業(yè)往往具有多種類型，每個機型復數數量的設備群。同時，隨著科技發(fā)展，價值昂貴的設備愈發(fā)普及，對它們的監(jiān)控與維護任務必不可少。實際上，對于設備群的統(tǒng)一化管理，對于企業(yè)效率的提升，成本的降低，都有著至關重要的作用。因此，基于工業(yè)互聯網的設備遠程監(jiān)控和運維方法，急需理論建模以及具體實現開發(fā)。在此基礎上，本文從領域驅動建模，架構設計，方案設計三個具體方面，對于設備遠程監(jiān)控和運維從抽象到具象，從理論設計到方案落地進行了具體方法制定。本文主要完成了以下三個工作內容：完成了設備遠程監(jiān)控運維領域建模。針對于現代制造的復雜化趨勢，業(yè)務建模的概念被廣泛承認和使用，這種建模方式實際上是從業(yè)務端出發(fā)進行劃分和界定，再反向構造對應的內容。對應于工程方面，存在微服務的概念，它是一種構建架構的思路和風格，提倡將一個大型的應用或者任務，拆分為一塊塊的微型服務進行獨立實現。微服務與業(yè)務建模兩個概念具有高度匹配性。而領域驅動建模的方法論，恰好支撐微服務概念。因此本文將三者結合，應用于設備遠程監(jiān)控運維。將設備遠程監(jiān)控運維視作一個領域，進行了設備信息，狀態(tài)監(jiān)測，智能算法，歷史數據，維保中心，遠程控制六個子域的劃分，再在子域內確定了界線上下文并依此劃分了微服務，并且給出了微服務實現必要的組件構成。同時，基于領域驅動設計的架構，對于微服務代碼總目錄進行了創(chuàng)建。完成了設備遠程監(jiān)控運維總架構的設計。為了支持現代制造對于大數據處理，數據云端統(tǒng)一管理，但在設備端又需要低延時地響應速度，采用了端邊云協(xié)同的模式搭建了基礎架構，隨后結合微服務架構特點，以及之前完成的微服務劃分，對于架構進行了細化，從而提出了完成的設備遠程監(jiān)控運維總架構。針對于設備監(jiān)控和遠程運維兩個核心的工業(yè)業(yè)務，設計了具體工作流程，并且對于各個環(huán)節(jié)在端邊云協(xié)同架構中如何使用微服務及其組件得以實現進行了闡述。并且針對于常常用于這兩個工業(yè)業(yè)務的智能算法進行了介紹和方案設計。最后，針對于參數監(jiān)控、異常回報、遠程監(jiān)控三個微服務進行了實驗，獲得了較為滿意的實驗結果。同時，在非技術性層面，本文在設備遠程監(jiān)控運維總架構的設計過程中，邊緣側和云側的數據傳輸可選擇性，提供了用戶使用第三方技術的同時，保證自己全部數據的安全性；而對于企業(yè)而言，提供了監(jiān)控和運維業(yè)務功能實現的同時，也提供了一個可擴展性強，擁有潛力的基礎方法，為企業(yè)實現效率提升，設備保護等方面都提供了可能性。實際上，設備的監(jiān)控和運維也意味著防范重大事故，節(jié)省用于損壞后重建的社會資源與自然資源，對于社會和環(huán)境也有著間接的作用。展望希望能夠在本文設計成果的基礎上，進一步對于設備遠程監(jiān)控和運維方法進行深入開發(fā)和進一步完善，具體在以下幾個方面：對領域驅動建模結果的合理性驗證。由于本文進行了從子域，基于限界上下文的微服務類，及其對應組件的層層劃分，但其合理性需要在一個適合的環(huán)境下進行驗證，進行閉環(huán)優(yōu)化，對于不合理的劃分做出相對應的添加，刪減，重組等操作。在具體方案實現方面，擴展能夠實際應用的微服務及其組件，本文提及的都是基礎算法，需要對算法庫進行擴充，當算法庫豐富且有了實際應用對比之后，對于不同場景下的合適算法進行性能比較。本文的建模仍比較淺顯，驗證部分和實驗部分也仍有欠缺，需要在合適的場景下進行進一步的完善和優(yōu)化。參考文獻WuD,GreerMJ,RosenDW,SchaeferD.Cloudmanufacturing:strategicvisionandstate-of-the-art[J].ManufSyst2013;32(4):564–79.WuD,RosenDW,WangL,SchaeferD.Cloud-baseddesignandmanufacturing:anewparadigmindigitalmanufacturinganddesigninnovation[J].ComputAidedDes2015;59:1–14.WuD,RosenDW,SchaeferD.Scalabilityplanningforcloud-Basedmanufacturingsystems[J].ManufSciEng2015.XuX.Fromcloudcomputingtocloudmanufacturing[J].RobComputIntegrManuf2012;28(1):75–86.WangL,T?rngrenM,OnoriM.Currentstatusandadvancementofcyber-physicalsystemsinmanufacturing[J].ManufSyst2015;37(Part2):517–27.LeeEA.Cyberphysicalsystems:designchallenges,proc.objectorientedreal-Timedistributedcomputing(ISORC)[C].200811thIEEEInternationalSymposiumon,IEEE2017:363–9.李倩.工業(yè)互聯網平臺需要具備四個基本功能[J/OL].中自數字移動傳媒,2018,23(3);4[2000-01-18].李杰,劉宗長,高虹安,等.工業(yè)人工智能[M].上海:上海交通大學出版社,2019:73-85.LeeJay,LiXiang,XuYuan-Ming,YangShaojie,SunKe-Yi.RecentadvancesandprospectsinindustrialAIandapplications[J].ActaAutomaticaSinica,2020,46(10):2031?2044.HuynhKT,BarrosA,BerenguerC.Multi-Leveldecision-makingforthepredictivemaintenanceofk-out-of-n:Fdeterioratingsystems[J].IEEETransactionsonReliability,2015,64(1):94?117.RafieeK,FengQ,CoitDW.Condition-basedmaintenanceforrepairabledeterioratingsystemssubjecttoageneralizedmixedshockmodel[J].IEEETransactionsonReliability,2015,64(4):1164?1174.JongeBD,TeunterR,TingaT.Theinfluenceofpracticalfactorsonthebenefitsofcondition-basedmaintenanceovertime-basedmaintenance[J].ReliabilityEngineering&SystemSafety,2017,158:21?30.WangH.Asurveyofmaintenancepoliciesofdeterioratingsystems[J].EuropeanJournalofOperationalResearch,2002,139(3):469?489.L.D.XuandL.Duan,Bigdataforcyberphysicalsystemsinindustry4.0:Asurvey[C].EnterpriseInf.Syst.,vol.13,no.2,pp.148–169,Feb.2019.Z.Wen,D.L.Quoc,P.Bhatotia,R.Chen,andM.Lee,ApproxIoT:Approximateanalyticsforedgecomputing[C].Proc.IEEE38thInt.Conf.Distrib.Comput.Syst.(ICDCS),Jul.2018,pp.411–421.V.Alieksieiev,OneapproachofapproximationforincomingdatastreaminIoTbasedmonitoringsystem,[C].Proc.IEEE2ndInt.Conf.DataStreamMiningProcess.(DSMP),Aug.2018,pp.94–97.J.Azar,A.Makhoul,M.Barhamgi,andR.Couturier,AnenergyefficientIoTdatacompressionapproachforedgemachinelearning[J].FutureGener.Comput.Syst.,vol.96,pp.168–175,Jul.2019.J.A.HealeyandR.W.Picard,Detectingstressduringreal-worlddrivingtasksusingphysiologicalsensors[J].IEEETrans.Intell.Transp.Syst.,vol.6,no.2,pp.156–166,Jun.2005.H.Harb,C.A.Jaoude,andA.Makhoul,Anenergy-efficientdatapredictionandprocessingapproachfortheInternetofThingsandsensingbasedapplications[J].PeerPeerNetw.Appl.,vol.13,no.3,pp.780–795,2020.BonomiF,Milito