莫超雄，劉建軍，陳慶新，毛 寧，胡常偉

(廣東工業(yè)大學(xué) 廣東省計算機集成制造系統(tǒng)重點實驗室，廣東 廣州 510006)

1 問題的描述

近年來，制造業(yè)服務(wù)化轉(zhuǎn)型升級逐漸呈現(xiàn)出蓬勃發(fā)展的勢頭，高級服務(wù)化的制造企業(yè)僅聚焦于自營核心業(yè)務(wù)，通過集成外包的非核心業(yè)務(wù)向客戶提供定制化服務(wù)[1]。例如，主要集中分布于廣東省及長江三角洲等制造業(yè)發(fā)達地區(qū)的裝備制造業(yè)，逐漸從單機裝備制造商轉(zhuǎn)變?yōu)榧苫ㄖ品?wù)商(以下簡稱集成商)。

集成商面向特定行業(yè)與領(lǐng)域，基于定制需求集成工業(yè)機器人等自動化、智能化裝備，交付非標(biāo)自動化產(chǎn)線，提供“交鑰匙工程”或EPC(engineering procurement construction)總包服務(wù)。集成商主要服務(wù)內(nèi)容包括制造系統(tǒng)一體化設(shè)計、系列非標(biāo)零部件/設(shè)備加工組裝、零件/部件/設(shè)備構(gòu)件及系統(tǒng)控制器的客戶現(xiàn)場集成總裝，最后進行全要素調(diào)試的全流程服務(wù)。如汽車零部件、3C產(chǎn)品和醫(yī)護產(chǎn)品的非標(biāo)自動化生產(chǎn)線，由集成商根據(jù)客戶軟硬條件以及對構(gòu)件的型號、價格等個性化需求設(shè)計生產(chǎn)線解決方案，制造組裝或外包生產(chǎn)控制器、機器人、伺服電機、傳感器等相關(guān)中小型構(gòu)件，運送到客戶地并進行集成化總裝。由于智能工廠的盛行和用工成本的增加，這種需要集成各種自動化、數(shù)字化與智能化中小型裝備的非標(biāo)定制需求，即集成化定制需求，也隨之攀升。

智能制造浪潮中，集成商迅速發(fā)展，成為智能工廠重要的建設(shè)力量，然而競爭同質(zhì)化嚴(yán)重，缺乏具有差異化的核心競爭力。目前，客戶定制需求和波動大的市場需求使交付周期越來緊迫，以至于交付周期成為集成商占領(lǐng)市場的關(guān)鍵。例如新冠疫情下不同類型口罩的生產(chǎn)線集成化定制需求，能夠快速響應(yīng)并完成生產(chǎn)線交付的集成商可短時間內(nèi)獲得大批客戶，把握市場主動權(quán)。在定制化方案設(shè)計能力相對成熟或確定的情況下，客戶現(xiàn)場集成裝配環(huán)節(jié)在整個交付周期的比重最大，因此能否精細(xì)化管控裝配作業(yè)，以避免不必要的浪費并提高作業(yè)效率，成為當(dāng)前定制化項目交付周期長短的決定性因素。

集成化定制裝配作業(yè)是以手工裝配為主的離散型裝配，集成商根據(jù)客戶需求定制工藝方案，從不同供應(yīng)商訂購物料到各個客戶地，并調(diào)配裝配人員進行異地裝配，具有多地的特點(如圖1)，因此稱集成裝配作業(yè)過程為多地總裝作業(yè)。

多地總裝作業(yè)過程包括物料訂購、供應(yīng)商協(xié)商和裝配調(diào)配等多個業(yè)務(wù)流程，具有多地、多流程和多參與者的特點，而集成商這類中小企業(yè)在運營模式上隨市場變動且不斷發(fā)展，使業(yè)務(wù)流程具有一定的動態(tài)性。因此，在復(fù)雜的業(yè)務(wù)流程中協(xié)同客戶、供應(yīng)商和集成商三方的交貨期需求、物料齊套協(xié)商以及裝配組調(diào)配，滿足集成商對管控系統(tǒng)的可維護性需求，實現(xiàn)對多地總裝作業(yè)精細(xì)化管控，成為集成商亟待解決的問題之一。

國內(nèi)外學(xué)者針對離散型裝配過程管控問題，在物料管控、車間現(xiàn)場監(jiān)控、生產(chǎn)計劃和調(diào)度控制以及管控系統(tǒng)的質(zhì)量屬性方面進行了大量研究。

(1)物料管控 結(jié)合生產(chǎn)需求對物料進行精細(xì)化管理，以提高生產(chǎn)效率。楊曉英等[2]以供應(yīng)鏈物流總成本最小為優(yōu)化目標(biāo)，以準(zhǔn)時與齊套配送等為約束條件，提出由混流生產(chǎn)計劃驅(qū)動、由物料配送期量標(biāo)準(zhǔn)及其計劃控制智能決策構(gòu)成的供應(yīng)鏈物流協(xié)同策略，解決了供應(yīng)鏈物流協(xié)同智能制造混流生產(chǎn)需求問題；ZHEN等[3]基于條碼技術(shù)構(gòu)建了物流控制系統(tǒng)，確保物料交付物的及時性和有效性，解決了物料庫存管理和生產(chǎn)需求脫節(jié)的問題；劉檢華等[4-6]針對復(fù)雜產(chǎn)品裝配過程中的物料管控問題，研究了物料跟蹤與管理技術(shù)、采購物料生產(chǎn)過程協(xié)同管理系統(tǒng)、物料精細(xì)化管控系統(tǒng)，實現(xiàn)了對物料的精細(xì)化管控，最終達到提高裝配作業(yè)效率的目的。

(2)車間現(xiàn)場監(jiān)控 基于生產(chǎn)作業(yè)流程，利用互聯(lián)網(wǎng)、物聯(lián)網(wǎng)相關(guān)技術(shù)，設(shè)計信息采集和監(jiān)控架構(gòu)或系統(tǒng)，通過提高車間現(xiàn)場信息透明度確保車間生產(chǎn)過程的管理效率。葉劍輝等[7]提出基于日作業(yè)計劃的車間現(xiàn)場數(shù)據(jù)管理模型并建立基于裝配工藝流程的車間現(xiàn)場監(jiān)控模型，通過復(fù)雜產(chǎn)品裝配車間監(jiān)控看板系統(tǒng)實現(xiàn)了復(fù)雜產(chǎn)品裝配車間現(xiàn)場的精細(xì)化監(jiān)控；YIN等[8]提出一種用于復(fù)雜產(chǎn)品裝配車間的智能制造模型，構(gòu)建了智能制造技術(shù)體系結(jié)構(gòu)及其運行模式、精益物流管理和裝配過程控制；QIAN等[9]針對車間管理信息不透明的問題，提出基于系統(tǒng)運行模式的可視化架構(gòu)和數(shù)據(jù)采集與處理的方法框架，開發(fā)能夠全面詳實展示車間工作狀態(tài)的實時監(jiān)控系統(tǒng)，從而提高生產(chǎn)過程透明度和管理效率，降低生產(chǎn)成本。

(3)生產(chǎn)計劃和調(diào)度控制 結(jié)合作業(yè)流程特點與調(diào)度算法，實現(xiàn)對作業(yè)過程的精細(xì)化管控。劉檢華等[10]針對航天裝配型制造企業(yè)的單件小批量離散生產(chǎn)特點，提出一種基于工作流的裝配車間生產(chǎn)過程計劃和控制方法，有效描述了裝配數(shù)據(jù)和裝配過程間的動態(tài)交互行為，為車間制造執(zhí)行提供了一條新的研究途徑；萬峰等[11]基于復(fù)雜產(chǎn)品裝配調(diào)度的實際需求，通過對裝配過程的可視化監(jiān)控、動態(tài)調(diào)度以及對調(diào)度信息的有效管理，實現(xiàn)了裝配計劃的快速、動態(tài)調(diào)整，并保證了生產(chǎn)調(diào)度信息的可追溯性。

(4)管控系統(tǒng)質(zhì)量屬性 主要關(guān)注可集成、可重構(gòu)和可擴展等，較少考慮因業(yè)務(wù)需求和市場環(huán)境而變更和發(fā)展所需要的系統(tǒng)可維護性[12]。李亞杰等[13]基于車間層對制造執(zhí)行系統(tǒng)(Manufacturing Execution System，MES)流程的重構(gòu)需求，提出一種可重構(gòu)流程模型驅(qū)動的流程進化實施技術(shù)；靳國杰等[14]研究具有完整功能粒度的應(yīng)用級構(gòu)件的構(gòu)造標(biāo)準(zhǔn)和配置機制,以及相關(guān)的組裝和集成方法,作為提升構(gòu)件重用能力的原理基礎(chǔ)；王軍強等[12]從系統(tǒng)架構(gòu)設(shè)計與軟件實現(xiàn)角度提出基于工廠方法模式的可擴展MES體系結(jié)構(gòu)，建立了面向航空制造業(yè)典型離散制造車間的可擴展MES。

上述研究在裝配作業(yè)過程管控問題上提供了思路和解決方案，但多地總裝作業(yè)是多客戶項目并行、多供應(yīng)商協(xié)同異地裝配的生產(chǎn)方式，在工藝、物料、裝配人員和運營模式方面的特點使得目前研究成果雖有一定參考價值，但難以適用。表1所示為集成化定制需求下的多地總裝作業(yè)與航天器、運輸飛機、武器系統(tǒng)等為代表的典型離散型復(fù)雜產(chǎn)品裝配作業(yè)特點的對比。

表1 集成化定制需求下的多地總裝作業(yè)與典型的復(fù)雜產(chǎn)品裝配作業(yè)的特點對比

續(xù)表1

(1)工藝 基于市場導(dǎo)向的定制化需求，如交貨期變更、交貨期承諾，會直接影響客戶服務(wù)水平高低，甚至能夠決定客戶項目的成敗。

(2)物料 以單機設(shè)備等中小型構(gòu)件為主，然而客戶地裝配現(xiàn)場往往沒有相關(guān)設(shè)備的保養(yǎng)人員，以及足夠大的、單機設(shè)備專用的倉庫。物料過早到達客戶地，會導(dǎo)致物料堆積，而客戶地存儲容量有限，且存儲條件不支持長期存儲，因此對物料齊套提出了準(zhǔn)時性要求。另外，物料主要是多品種、少批量外包生產(chǎn)或訂購，沒有長期大量供貨的供應(yīng)商，以至于提前期不穩(wěn)定，物料到達時間隨預(yù)定日期的接近漸進確定。

(3)裝配人員 為了有效利用裝配人員資源，采用多項目并行執(zhí)行的方式，共享高級裝配人員，普通裝配人員駐廠，使得高級裝配人員的裝配任務(wù)都帶有前置時間，即差旅時間。高級裝配人員以裝配組為單位，由于人員流動和集成商業(yè)務(wù)擴展等客觀因素，裝配組之間的裝配技術(shù)資質(zhì)和熟練度各不相同，主要區(qū)別體現(xiàn)在裝配任務(wù)類型對資質(zhì)的要求和裝配工時的快慢。

(4)運營模式 集成商會因客戶和市場需求的不同而采用不同的運營模式，如總承包與分包交付方式、以租代購交易方式或售賣產(chǎn)線生產(chǎn)能力的合作方式。集成商的主要業(yè)務(wù)均為訂購物料、協(xié)商物料和派遣裝配員，但不同運營模式會導(dǎo)致具體業(yè)務(wù)內(nèi)容有所偏差。如有些物料一般為一次性使用，而在以租代購交易運營方式下，物料是多個客戶重復(fù)使用；裝配員一般由集成商派遣，而在分包交付運營模式下，裝配員可能由客戶方/物料供應(yīng)商派遣。

針對集成商對多地總裝作業(yè)過程的管控問題，本文從作業(yè)過程和系統(tǒng)質(zhì)量屬性兩方面分析需求，設(shè)計基于領(lǐng)域驅(qū)動設(shè)計的微服務(wù)系統(tǒng)架構(gòu)，以降低系統(tǒng)復(fù)雜性。在此基礎(chǔ)上，提出基于云計算的三階管控機制，實現(xiàn)對總裝作業(yè)多用戶的協(xié)同管控和對作業(yè)現(xiàn)場實況的敏捷響應(yīng)，并基于SpringCloud微服務(wù)技術(shù)框架開發(fā)具有穩(wěn)定性、可維護性以及低成本特點的管控系統(tǒng)，實現(xiàn)對用戶賦能的目的。

2 多地總裝作業(yè)過程分析

以廣東佛山幾家典型自動化噴釉生產(chǎn)線集成商為例，多地總裝作業(yè)一般由工程部主辦，以按需分配資源的管理方式為主，分為需求確定與定制化設(shè)計、物料訂購、異地裝配和客戶驗收4部分，如圖2所示。

(1)需求確定與定制化設(shè)計 裝配工藝流程是以任務(wù)節(jié)點為基本單位，由串/并聯(lián)混合而成的裝配工序鏈構(gòu)成的工作流組成。任務(wù)節(jié)點屬于各個客戶項目，每個項目具有里程碑式交貨期，具有多階段和動態(tài)的特點。而當(dāng)前的手工管理方式無法根據(jù)項目交貨期的緊迫程度分配裝配資源，使得客戶交貨期相關(guān)需求難以滿足。

(2)物料訂購 為了使物料能夠盡早齊套，當(dāng)前物料訂購的做法是基于裝配工藝流程圖一次性訂購全部所需物料，然而有限的裝配能力會導(dǎo)致物料堆積。另外，因為物料提前期較長(一般為1個月左右)，而且裝配工時不穩(wěn)定性導(dǎo)致物料需求時間具有動態(tài)性，所以仍存在齊套準(zhǔn)時性差的情況。

(3)異地裝配 工程部以按需調(diào)配的方式派遣裝配組，即當(dāng)裝配任務(wù)滿足緊前任務(wù)邏輯約束且物料齊套時，通過人工計劃和郵件/電話通知的方式派遣高級裝配小組到現(xiàn)場裝配。這種實時性差的方式容易導(dǎo)致裝配組處在忙碌和空閑兩個極端，對有限裝配資源的利用效率較低。

(4)客戶驗收 當(dāng)裝配進度執(zhí)行到交付任務(wù)節(jié)點時，需要聯(lián)系客戶方進行驗收，另外安排質(zhì)檢也需要提前期。由于不能預(yù)知任務(wù)完成時間，導(dǎo)致項目會因等待質(zhì)檢而停滯。

分析可知，現(xiàn)行的多地總裝作業(yè)管理方式無法響應(yīng)客戶交貨期需求，存在物料齊套準(zhǔn)時性差的問題，而且高級裝配組調(diào)度困難并有等待浪費現(xiàn)象，可將問題歸結(jié)為作業(yè)過程信息化問題和計劃控制問題，一方面需要通過動態(tài)的有限能力計劃，對物料和裝配組進行精細(xì)化管控，以響應(yīng)客戶交貨期需求；另一方面需要規(guī)范和信息化作業(yè)過程，使集成商能夠敏捷反應(yīng)現(xiàn)場情況并下發(fā)作業(yè)指令，確保對裝配現(xiàn)場計劃和調(diào)度控制的有效性。

3 集成商管控系統(tǒng)需求分析

通過對珠三角地區(qū)的集成商調(diào)研得知，當(dāng)前的集成商普遍具有一定的信息化基礎(chǔ)。例如，在企業(yè)資源計劃(Enterprise Resource Planning, ERP)系統(tǒng)中實現(xiàn)客戶需求設(shè)計及其具體集成裝配設(shè)計、客戶信息、供應(yīng)商信息等進銷存業(yè)務(wù)。然而，在裝配制造執(zhí)行環(huán)節(jié)按需分配裝配資源，沿用“電話—郵件—會議”的傳統(tǒng)手工管理方式，存在客戶服務(wù)水平低、等待浪費嚴(yán)重和作業(yè)過程不透明的現(xiàn)象。

IEC/ISO 62264系列國際標(biāo)準(zhǔn)對企業(yè)制造執(zhí)行過程給出了MES參考解決方案，通過生產(chǎn)、質(zhì)量、維護和庫存4方面運行模塊解決執(zhí)行管控問題，具有較強的歸納性和普遍性。然而由于多地總裝作業(yè)過程業(yè)務(wù)場景的特殊性，需要更強的具有針對性和可操作性的智能化MES。

多地總裝作業(yè)過程包括物料訂購、協(xié)調(diào)物料到達時間、裝配人員調(diào)度派遣、客戶驗收等多個業(yè)務(wù)流程，使管控比較困難。其中涉及多個客戶的交貨期需求、多個供應(yīng)商的物料供應(yīng)以及多個裝配組的調(diào)配，有跨企業(yè)、跨部門多用戶協(xié)同的特點，而且客戶、供應(yīng)商和集成商自身往往也有業(yè)務(wù)管理系統(tǒng)。另外，集成商以中小企業(yè)居多，在經(jīng)營模式上會隨市場需求而變動，例如雖以項目總承包為主業(yè)，但也會承擔(dān)分包業(yè)務(wù)，使得業(yè)務(wù)管控需求具有一定的動態(tài)性。因此，多地總裝作業(yè)過程管控系統(tǒng)不僅需要在設(shè)計上優(yōu)化管理多個業(yè)務(wù)流程，敏捷響應(yīng)裝配現(xiàn)場狀況，提高執(zhí)行效率，還要在開發(fā)實現(xiàn)上考慮系統(tǒng)的成本和可維護性。

當(dāng)前制造執(zhí)行管控系統(tǒng)的開發(fā)以單體架構(gòu)和面向服務(wù)的架構(gòu)(Service Oriented Architecture，SOA)為主[14]，難以滿足集成商對系統(tǒng)的要求，如業(yè)務(wù)流程的變更、算法能力的優(yōu)化提升或集成其他系統(tǒng)。由于單體架構(gòu)的強耦合性和SOA中企業(yè)服務(wù)總線(Enterprise Service Bus，ESB)方式的維護復(fù)雜性，使得系統(tǒng)維護困難、成本高、時間長，以至于集成商這類中小型企業(yè)雖然知道信息化能夠提高效率，但是難以承擔(dān)風(fēng)險而選擇沿用手工方式。

集成商的運營模式日新月異，帶來了諸多管控難題，而互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等技術(shù)迅速發(fā)展，為解決難題帶來了多種解決方法。為滿足軟件系統(tǒng)用戶的服務(wù)集成和多樣化系統(tǒng)需求，衍生出了擁有獨立進程和部署能力的、基于SOA的微服務(wù)技術(shù)。LEWIS等[15]在2014年首次提出微服務(wù)一詞，將微服務(wù)架構(gòu)定義為一種構(gòu)造方式，將一套小型服務(wù)(微服務(wù))組合構(gòu)造成單個應(yīng)用程序。其中，微服務(wù)的特點是在進程上相互獨立，在交互上使用輕量級通信機制。雖然學(xué)術(shù)界對微服務(wù)架構(gòu)的研究仍處于早期階段[16]，但是在工業(yè)界已經(jīng)有許多成功應(yīng)用，如微信和優(yōu)步。此外，微服務(wù)的業(yè)界應(yīng)用還有豐富的微服務(wù)開源解決方案，如能夠構(gòu)建一套完整微服務(wù)架構(gòu)技術(shù)生態(tài)鏈的SpringCloud框架、阿里巴巴電商平臺探索開發(fā)的Dubbo框架以及微軟專門針對模塊化微服務(wù)架構(gòu)設(shè)計的.NET Core框架等。

與單體架構(gòu)相比，微服務(wù)架構(gòu)的邏輯單元清晰、開發(fā)迭代速度快、維護方便、伸縮性好、容錯性好[17]；與傳統(tǒng)SOA相比，微服務(wù)架構(gòu)采用表述性狀態(tài)傳遞(Representational State Transfer，REST)更加輕量級的通信機制，代替了SOA的簡單對象訪問協(xié)議(Simple Object Access Protocol，SOAP)機制，具有服務(wù)定義粒度細(xì)、服務(wù)邊界劃分清晰的優(yōu)勢。

作為當(dāng)前軟件體系結(jié)構(gòu)的新趨勢，微服務(wù)強調(diào)高度可維護和可擴展性，能夠快速響應(yīng)個性化的開發(fā)需求，具有可集成性[18]。因此，考慮集成商業(yè)務(wù)流程的復(fù)雜性及其發(fā)展所帶來的動態(tài)性特點，采用微服務(wù)架構(gòu)能夠很好地降低業(yè)務(wù)邏輯開發(fā)的復(fù)雜性和成本，滿足可維護性的需求。

4 微服務(wù)系統(tǒng)總體架構(gòu)

通過分析多地總裝作業(yè)過程可知，集成商在業(yè)務(wù)管控上有敏捷響應(yīng)和多用戶協(xié)同的需求，在系統(tǒng)技術(shù)實現(xiàn)上需要降低復(fù)雜度和成本，并具備可維護性。對此，本文基于領(lǐng)域驅(qū)動設(shè)計的分層方法，構(gòu)建了基于微服務(wù)架構(gòu)的多地總裝作業(yè)過程敏捷—協(xié)同管控系統(tǒng)。

4.1 分層設(shè)計

傳統(tǒng)的分層設(shè)計主要分為表現(xiàn)層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層3層架構(gòu)，缺少對基礎(chǔ)服務(wù)的劃分，如請求網(wǎng)關(guān)、服務(wù)治理相關(guān)服務(wù)，對微服務(wù)這類新興架構(gòu)不夠友好；另外，過于強調(diào)數(shù)據(jù)訪問層，使得業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層之間存在依賴關(guān)系。即使業(yè)務(wù)發(fā)生小變更，系統(tǒng)開發(fā)人員也不得不首先關(guān)注數(shù)據(jù)表設(shè)計，無疑增大了系統(tǒng)維護成本。

因此，基于領(lǐng)域驅(qū)動設(shè)計(Domain-Driven Design, DDD)的分層結(jié)構(gòu)設(shè)計方法[19]，本文將微服務(wù)架構(gòu)系統(tǒng)從上層到底層依次設(shè)計為用戶接口層、應(yīng)用服務(wù)層、領(lǐng)域服務(wù)層和基礎(chǔ)設(shè)施層，明確了層級職能(如表2)和協(xié)作方式。

表2 基于領(lǐng)域驅(qū)動設(shè)計的微服務(wù)系統(tǒng)分層

4.2 層間協(xié)作

各層之間保持高內(nèi)聚低耦合，即上層只依賴于其下方的層，下層向上層只能通過通信中間件通信，層間協(xié)作實現(xiàn)了系統(tǒng)的數(shù)據(jù)輸入、數(shù)據(jù)處理和數(shù)據(jù)輸出。

(1)數(shù)據(jù)輸入 由用戶接口層從外部接口/移動/PC/Web端獲取數(shù)據(jù)，如ERP系統(tǒng)或人工輸入的裝配工藝流程、裝配組/供應(yīng)商信息及裝配現(xiàn)場數(shù)據(jù)等，輸入到應(yīng)用服務(wù)層，然后調(diào)用基礎(chǔ)措施層的數(shù)據(jù)持久化服務(wù)和領(lǐng)域服務(wù)層的數(shù)據(jù)處理相關(guān)服務(wù)。

(2)數(shù)據(jù)處理 由應(yīng)用服務(wù)層驅(qū)動并傳輸必要的數(shù)據(jù)到領(lǐng)域服務(wù)層的服務(wù)體進行邏輯運算，再將處理結(jié)果返回給應(yīng)用服務(wù)層。即應(yīng)用服務(wù)層依賴于領(lǐng)域服務(wù)層，領(lǐng)域服務(wù)層通過應(yīng)用層間接地進行數(shù)據(jù)持久化。

(3)數(shù)據(jù)輸出 基于業(yè)務(wù)需求，應(yīng)用服務(wù)層根據(jù)前端用戶需求，對領(lǐng)域服務(wù)層的一個或多個服務(wù)體返回的數(shù)據(jù)做出必要的數(shù)據(jù)轉(zhuǎn)換處理，并通過用戶接口層輸出展示。

4.3 總體架構(gòu)設(shè)計

基于上述理念，系統(tǒng)架構(gòu)設(shè)計如圖3所示。系統(tǒng)架構(gòu)將業(yè)務(wù)流部分抽象到應(yīng)用服務(wù)層，將數(shù)據(jù)處理功能抽象到領(lǐng)域服務(wù)層并與業(yè)務(wù)流和數(shù)據(jù)流解耦，使得業(yè)務(wù)流程變動不直接影響數(shù)據(jù)處理功能，同時數(shù)據(jù)處理功能的優(yōu)化升級或變更也不直接依賴于持久化數(shù)據(jù)庫。這種架構(gòu)設(shè)計方式使管控系統(tǒng)的數(shù)據(jù)輸入輸出、業(yè)務(wù)邏輯、算法處理及數(shù)據(jù)持久化各部分不但界限劃分清晰，而且內(nèi)聚化、低耦合，降低了系統(tǒng)多業(yè)務(wù)流程、多用戶所帶來的技術(shù)實現(xiàn)復(fù)雜度，提高了系統(tǒng)的可維護性。

5 基于云計算的三階段管控機制

多地總裝作業(yè)包括需求確定與定制化設(shè)計、物料訂購、供應(yīng)商協(xié)商、裝配員調(diào)配和客戶驗收多個業(yè)務(wù)流程，存在客戶交貨期需求變更、物料齊套時間漸進確定和裝配工時不穩(wěn)定等裝配現(xiàn)場多變的情況，涉及物料管理員、供應(yīng)商、普通/高級裝配組和客戶多個參與者，為解決其中作業(yè)過程信息化問題和計劃控制問題，本文提出一種能夠協(xié)同多用戶多流程、敏捷響應(yīng)裝配現(xiàn)場的基于云計算的三階段管控機制，如圖4所示。

5.1 管控機制相關(guān)對象說明

三階段管控機制針對集成商行業(yè)中具體的業(yè)務(wù)場景而設(shè)計，涉及較多行業(yè)相關(guān)的名詞對象，其中重復(fù)出現(xiàn)對象采用[#1,#2,#3，…]序號區(qū)別。以圖4為例，具體說明如下：

(1)裝配工藝流程圖由串/并行工作節(jié)點組成，每個節(jié)點代表一個工作流，即裝配任務(wù)，包括任務(wù)名稱、標(biāo)準(zhǔn)工時、裝配任務(wù)類型和里程碑式交貨期，同時對應(yīng)以中小型構(gòu)件為主的物料清單，如圖5所示。其中裝配任務(wù)類型(如執(zhí)行模塊、輔助模塊等)限定了裝配組的資質(zhì)。實際工時取決于標(biāo)準(zhǔn)工時和裝配組的熟練度。另外，每個工藝流程圖均對應(yīng)客戶項目，具有相關(guān)的項目文檔，包括裝配地點、客戶等級和具體技術(shù)工藝。

(2)裝配任務(wù)池裝配工藝流程圖通過業(yè)務(wù)規(guī)則計算處理后，得到多個與實際裝配任務(wù)/工作節(jié)點/工作流一一映射的對象實體，該實體包括裝配任務(wù)的所有屬性和狀態(tài)，存放在裝配任務(wù)池中，可將每個裝配任務(wù)視作Agent個體。

(3)裝配任務(wù)的生命周期有3種狀態(tài)，即未訂購物料、距離物料齊套時間大于一個星期、距離物料齊套時間小于等于一個星期，將其劃分為#1，#2，#3共3個裝配任務(wù)列表，分別對應(yīng)管控機制的3個階段。

(4)云端算法集群共有3個算法集群，均部署到云端。輸入為裝配任務(wù)和實況約束，即當(dāng)裝配任務(wù)和實況約束更新時會驅(qū)動算法；輸出為基于有限能力的總裝計劃。數(shù)據(jù)運算處理采用分層多目標(biāo)的方式，即根據(jù)其所在階段的目的和特征而采用不同的算法和優(yōu)化目標(biāo)，如表3所示。優(yōu)化目標(biāo)中，min{E/T懲罰}指最小化提前/延期懲罰，追求項目完工的準(zhǔn)時性；3個時間一致指總裝計劃的最早開始時間、物料齊套時間和裝配組齊套時間趨于一致，追求減少互相等待浪費；min{差旅時間}為最小化差旅時間，追求減少無效差旅帶來的裝配組資源浪費。另外，算法應(yīng)用部分并非固定為本文所述的算法，可引用其他已驗證調(diào)度優(yōu)化有效的算法。

(5)總裝計劃由算法集群計算而得，基于總裝計劃，通過業(yè)務(wù)規(guī)則計算出訂購計劃、需求時間表和作業(yè)計劃。總裝計劃包括5個時間：最早開始時間取決于該任務(wù)的緊前任務(wù)的結(jié)束時間；物料齊套時間指裝配任務(wù)物料清單都到達的時間；裝配組齊套時間指任務(wù)所需要的裝配組全部到齊的時間；計劃開始時間指前面3個時間中最大的時間；計劃結(jié)束時間指計劃開始時間加標(biāo)準(zhǔn)裝配工時與裝配組熟練度的乘積?？傃b計劃示例如圖6所示。

表3 分層多目標(biāo)

(6)實況約束指實時裝配資源的占用情況，是算法優(yōu)化計算有限能力總裝計劃的基礎(chǔ)。整個機制有3種，均由裝配任務(wù)實際開始時間、實際完工時間和物料預(yù)計到達時間組成。實況約束#3由裝配組和物料供應(yīng)商實時反饋，經(jīng)過下達階段的總裝計劃占用裝配組資源后更新#3得到#2，同理得到#1。上述實況反饋方式能夠確保排程約束的實時性，進而使得每個階段的算法排程得到的計劃是基于當(dāng)前集成商的有限能力。

(7)業(yè)務(wù)規(guī)則指根據(jù)實際業(yè)務(wù)場景得到的對數(shù)據(jù)進行邏輯處理的規(guī)則，管控機制中有#1，#2，#3，#4，#5共5個業(yè)務(wù)規(guī)則，具體內(nèi)容配置示例如表4所示。業(yè)務(wù)規(guī)則并非一成不變，當(dāng)業(yè)務(wù)場景或集成商的運營策略發(fā)生變更時，業(yè)務(wù)規(guī)則隨之變更。

表4 業(yè)務(wù)規(guī)則說明

5.2 管控機制運行步驟

管控機制以裝配任務(wù)為主要對象，采用云端算法集群、分層多目標(biāo)優(yōu)化以及輔助人工審核管控的運作方式，具體運行步驟如下：

步驟1在任務(wù)輸入階段，客戶提出的定制化需求、質(zhì)檢后返工返修工單和交貨期相關(guān)需求(如交貨期推遲/提前)，由集成商的其他部門處理，得到的最終結(jié)果均以裝配工藝流程圖的形式保存。本文以ERP系統(tǒng)應(yīng)用程序接口(Application Programming Interface, API)方式獲取工藝流程圖，將通過規(guī)則處理得到的裝配任務(wù)池作為三階段管控機制的數(shù)據(jù)輸入口。

步驟2在隊列階段，主要目的是確定訂購物料時間。在裝配任務(wù)池中，未訂購物料的裝配任務(wù)會在此階段排程。基于實況約束，通過云端算法集群進行集中式調(diào)度排程得到總裝計劃，再經(jīng)過業(yè)務(wù)規(guī)則處理得到物料訂購計劃，由物料管理員審核/修改后形成訂購指令下發(fā)給物料供應(yīng)商。其中總裝計劃、訂購計劃等計劃是動態(tài)的，會隨算法輸入的更新而不斷刷新變動，只有當(dāng)人工審核/修改變成指令后才停止變動，確定為作業(yè)執(zhí)行依據(jù)。

步驟3緩存階段，該階段以協(xié)調(diào)物料到達時間為目的。在裝配任務(wù)池中，已訂購物料但距離物料到達時間超過1個星期的裝配任務(wù)會在此階段排程，類似于隊列階段的處理流程。由于裝配現(xiàn)場的動態(tài)性以及要求物料齊套的準(zhǔn)時性要求，物料需求時間會隨資源約束的變化而變更。該時間在發(fā)生變更時通知物料供應(yīng)商，由供應(yīng)商自主做出變更預(yù)計到達時間的反饋，必要時物料管理員會通過線下協(xié)商方式(如電話/郵件)進一步確定時間或催料。

步驟4下達階段，該階段以裝配組調(diào)配為目的。在裝配任務(wù)池中，已訂購物料且物料預(yù)計到達時間小于1個星期的裝配任務(wù)會在此階段排程。經(jīng)過算法、規(guī)則處理后得到裝配作業(yè)指令來指導(dǎo)裝配組執(zhí)行任務(wù)，開始或完成一項任務(wù)時會反饋相關(guān)時間。其中，基于總裝作業(yè)過程多地的特點，裝配員使用的APP具有實時定位功能，當(dāng)裝配員到達客戶地后會直接反饋裝配任務(wù)的開始時間并計算裝配工時，能夠預(yù)警提醒裝配員反饋完工時間。這種方式解決了以人為主的手工裝配所帶來的監(jiān)控困難和報工不準(zhǔn)確問題。

步驟5質(zhì)檢交付，該階段以反饋實況約束和質(zhì)檢交付為目的。監(jiān)聽物料供應(yīng)商和裝配組反饋的開工/完工時間與物料預(yù)計到達時間，計算得到的實況約束作為上3個階段調(diào)度排程和質(zhì)檢交付的依據(jù)。其中，質(zhì)檢交付在項目中以里程碑的形式存在，由客戶執(zhí)行。質(zhì)檢后，移除裝配任務(wù)池中相關(guān)的裝配任務(wù)，若需要返修返工則轉(zhuǎn)步驟1，重新進入裝配任務(wù)池中。同理，裝配任務(wù)需求變更會在任務(wù)池中進行。

5.3 管控機制的優(yōu)勢

通過上述分析說明，相對于第2章和第3章的現(xiàn)行手工管理方式，本文提出的管控機制具有滾動優(yōu)化、整體聯(lián)動(如圖7)和云端計算的優(yōu)勢。

(1)滾動優(yōu)化 隨著裝配任務(wù)的狀態(tài)變更而采用不同的優(yōu)化方法，當(dāng)裝配任務(wù)持續(xù)輸入時形成滾動優(yōu)化的方式。該方式得到的總裝計劃，分別在不同階段協(xié)同客戶、供應(yīng)商和集成商完成物料訂購、物料到達時間協(xié)商、裝配組調(diào)配和質(zhì)檢交付，即能在多業(yè)務(wù)流程的情況下協(xié)同多用戶優(yōu)化裝配相關(guān)計劃，相比于傳統(tǒng)手工管理方式，實現(xiàn)了對多地總裝作業(yè)過程的精細(xì)化協(xié)同管控。

(2)整體聯(lián)動 集成商傳統(tǒng)管理方式中也曾存在過人工/機器編排生產(chǎn)計劃，之所以舍棄這種方式并采用按需調(diào)配裝配組，是因為原先生產(chǎn)計劃存在計劃可執(zhí)行性差的問題。對此，本文管控機制計算出的計劃均基于集成商的有限能力/資源等約束，即能夠敏捷響應(yīng)裝配現(xiàn)場中的客戶、供應(yīng)商和裝配車間約束，實時更新計劃以確保計劃的可執(zhí)行性。

(3)云端算法 管控機制的滾動優(yōu)化、整體聯(lián)動特點雖然帶來了協(xié)同管控、敏捷響應(yīng)的優(yōu)勢，但也對運作機制的算力提出更高要求，需要整個機制持續(xù)不斷地進行實時運算。集成商多為追求低成本、高計算性能的中小型企業(yè)，而服務(wù)器的購買成本和維護成本高昂，因此機制中最消耗算力的算法處理部分采用云端算法集群的方式?；谠朴嬎阒械幕A(chǔ)設(shè)施即服務(wù)(Infrastructure as a Service，IaaS)計算服務(wù)，將多個算法以容器化的微服務(wù)集群部署到云端。每個算法集群包含多個重復(fù)/非重復(fù)的優(yōu)化算法，并規(guī)定了優(yōu)化目標(biāo)和輸入輸出。當(dāng)更新輸入數(shù)據(jù)時，將自動調(diào)用云算法集群，以RESTful API(representational state transfer fulAPI)方式傳送約束和任務(wù)的JavaScript對象表示法(JavaScript Object Notation, JSON)數(shù)據(jù)包到云端算法集群，以輪詢?yōu)槟J(rèn)方式進行計算，不斷將結(jié)果用json返回總裝計劃，直至輪詢完所有算法。其中，項目管理員不僅可以手動選擇算法計算，還可以在不影響機制運作的情況下對集群中的算法進行優(yōu)化升級或刪減處理。

6 微服務(wù)系統(tǒng)開發(fā)實現(xiàn)

集成商作業(yè)管控數(shù)字化轉(zhuǎn)型的關(guān)鍵阻力之一是成本問題，市面上的管控系統(tǒng)成本普遍需要數(shù)十或上百萬人民幣，甚至超過集成商的年收益，而且集成商對管控系統(tǒng)需求具有動態(tài)性，導(dǎo)致系統(tǒng)應(yīng)用效果難以保證，具有高額成本風(fēng)險，使得集成商望而止步。因此，系統(tǒng)非常有必要從開發(fā)、上線發(fā)布以及后續(xù)維護的各個環(huán)節(jié)盡可能降低成本風(fēng)險。

相對于傳統(tǒng)管控系統(tǒng)的單體架構(gòu)、SOA架構(gòu)，微服務(wù)系統(tǒng)更適用于邏輯和需求復(fù)雜的業(yè)務(wù)場景，其不僅具有可擴展、可集成、可維護等系統(tǒng)質(zhì)量屬性方面的優(yōu)勢，同時，采用微服務(wù)架構(gòu)開發(fā)方式能夠縮短開發(fā)周期，降低開發(fā)和維護成本。因此，在作業(yè)管控系統(tǒng)方面，作為中小型企業(yè)的集成商應(yīng)用微服務(wù)架構(gòu)進行開發(fā)實現(xiàn)是目前比較合適的選擇。

系統(tǒng)的微服務(wù)化也帶來了諸多挑戰(zhàn)，尤其是與服務(wù)治理相關(guān)的服務(wù)注冊與發(fā)現(xiàn)、配置管理、負(fù)載均衡、服務(wù)通信等，是開發(fā)實現(xiàn)微服務(wù)系統(tǒng)的必經(jīng)之路。工業(yè)界對微服務(wù)已經(jīng)有了大量實踐經(jīng)驗，并開源了多個微服務(wù)框架，幫助系統(tǒng)開發(fā)人員實現(xiàn)微服務(wù)系統(tǒng)。主流微服務(wù)開源框架有Dubbo，SpringCloud，Istio，如表5所示。相對于互聯(lián)網(wǎng)企業(yè)軟件來說，制造企業(yè)的業(yè)務(wù)系統(tǒng)主要關(guān)注系統(tǒng)的維護性和成本問題，對高并發(fā)、多線程等性能方面要求較低。因此，由對比可知SpringCloud穩(wěn)定、成本低、開發(fā)速度快的特點更加切合集成商對實現(xiàn)管控系統(tǒng)的要求。

表5 主流微服務(wù)開源技術(shù)框架對比

續(xù)表5

6.1 基于SpringCloud的系統(tǒng)實現(xiàn)技術(shù)

針對構(gòu)建分布式系統(tǒng)容易出錯和技術(shù)復(fù)雜的難題，SpringCloud為最常見的分布式系統(tǒng)，例如微服務(wù)系統(tǒng)提供了一種簡單且可讀性高的編程模型，幫助系統(tǒng)開發(fā)人員構(gòu)建彈性的、可靠的、協(xié)調(diào)的應(yīng)用程序。SpringCloud構(gòu)建于SpringBoot之上，其提供了能夠一鍵啟動部署的一站式微服務(wù)系統(tǒng)架構(gòu)解決方案(如圖8)，開發(fā)者容易入手并將其快速應(yīng)用于生產(chǎn)。下面給出主要運行步驟，由于體系龐大，此處僅展示說明關(guān)鍵部分示例，可通過Spring官網(wǎng)(https://spring.io/)查看全部組件說明。

步驟1外部請求統(tǒng)一先到達SpringCloud Gateway的API網(wǎng)關(guān)，基于從注冊中心(Eureka)獲取的可用服務(wù)信息，由Ribbon進行負(fù)載均衡，重定向到對應(yīng)的內(nèi)部服務(wù)。

步驟2微服務(wù)之間通過Feign進行通信和處理業(yè)務(wù)，并通過組件進行服務(wù)治理，以確保微服務(wù)系統(tǒng)的穩(wěn)定性。相關(guān)的服務(wù)治理組件有配置中心(Config)、熔斷器(Hystrix)、監(jiān)控系統(tǒng)(ELK)等，其中各個組件都屬于SpringCloud技術(shù)框架，均支持SpringBoot開發(fā)風(fēng)格的一鍵啟動和部署。

6.1.1 管控系統(tǒng)技術(shù)架構(gòu)

考慮集成商成本低、可維護的系統(tǒng)質(zhì)量需求和管控機制滾動優(yōu)化協(xié)同多用戶、敏捷響應(yīng)裝配現(xiàn)場擾動的特點，通過分析微服務(wù)系統(tǒng)的實現(xiàn)技術(shù)框架，設(shè)計了基于SpringCloud的管控系統(tǒng)技術(shù)架構(gòu)，如圖9所示，其中黑色加粗的線框表示系統(tǒng)的前端和后端。

6.1.2 關(guān)鍵開發(fā)技術(shù)說明

基于SpringCloud的技術(shù)框架解決了管控系統(tǒng)開發(fā)需求和開發(fā)實現(xiàn)中遇到的主要問題，包括前后端分離、安全認(rèn)證與鑒權(quán)、數(shù)據(jù)存儲、負(fù)載均衡、云端部署和系統(tǒng)可用性。

(1)前后端分離 因為部分客戶/供應(yīng)商有管控系統(tǒng)以及集成商本身的EPR系統(tǒng)，需要以O(shè)penAPI集成的方式對接，同時為了滿足用戶使用便利的需求，需配備Web，OpenAPI，PC，APP多種應(yīng)用端口，另外第4章的總體架構(gòu)圖將前端單獨列為用戶接口層以對前端展示和業(yè)務(wù)處理之間進行解耦，以確保系統(tǒng)可維護，所以采用前后端分離的開發(fā)方式，前端基于VUE.js和Node.js技術(shù)框架開發(fā)，其服務(wù)器采用Nginx，存放超文本標(biāo)記語言(Hyper Text Markup Language，HTML)、層疊樣式表(Cascading Style Sheets，CSS)、JS(Java Script)等靜態(tài)資源，負(fù)責(zé)控制頁面引用、路由和跳轉(zhuǎn)。用戶端發(fā)送請求時會直達前端的HTML頁面，以AJAX(asynchronous Javascript and XML)異步的方式調(diào)用后端的RESTfulAPI接口，并采用JSON數(shù)據(jù)進行交互，達到前后端分離解耦的目的。只要通過部分代碼重構(gòu)，就能大量復(fù)用API接口，從而提高多端應(yīng)用的開發(fā)效率。

(2)安全認(rèn)證與鑒權(quán) 管控系統(tǒng)涉及多用戶，尤其是來自企業(yè)外部的用戶，如客戶和供應(yīng)商，需要限制不同用戶的不同訪問權(quán)限等級以保障信息安全。另外，微服務(wù)架構(gòu)中的每個微服務(wù)相當(dāng)于個體，訪問調(diào)用也需要鑒權(quán)，傳統(tǒng)單體架構(gòu)采用的session認(rèn)證方式使得微服務(wù)被調(diào)用時占用大量內(nèi)存，而且每個微服務(wù)都要進行一次鑒權(quán)，導(dǎo)致代碼冗余。對此，采用SpringCloud Gateway和JWT(JSON Web Token)規(guī)范解決，首先用戶通過網(wǎng)關(guān)和后臺的用戶管理微服務(wù)初步驗證登錄賬號密碼，成功后簽發(fā)JWTToken信息給用戶，用戶后續(xù)的訪問都會攜帶TOKEN，由SpringCloud Gateway網(wǎng)關(guān)進行過濾鑒權(quán)，判斷是否有權(quán)限，有則放行，無則返回未認(rèn)證錯誤，最終完成單點登錄。

(3)數(shù)據(jù)存儲 數(shù)據(jù)存儲是管控系統(tǒng)運行的基礎(chǔ)保障，可將管控系統(tǒng)產(chǎn)生的數(shù)據(jù)分為文件數(shù)據(jù)、緩存數(shù)據(jù)和持久化數(shù)據(jù)3類。文件數(shù)據(jù)指Word/Excel或圖片等小文件，例如裝配工藝文檔采用FASTDFS存儲，以實現(xiàn)對文件的存儲、同步、訪問等管理功能；緩存數(shù)據(jù)指系統(tǒng)中算法部分所持續(xù)產(chǎn)生的、動態(tài)的總裝計劃，采用Redis高性能數(shù)據(jù)庫，以滿足數(shù)據(jù)頻繁增刪查改所帶來的性能需求；持久化數(shù)據(jù)指系統(tǒng)中由人工審核修改后的指令、裝配進度數(shù)據(jù)等，采用體積小、速度快、總體擁有成本低的開源數(shù)據(jù)庫MySQL。

(4)負(fù)載均衡 負(fù)載均衡的方式是分別以單個微服務(wù)部署到云端形成算法集群，以輪詢方式進行調(diào)用。對此，采用Ribbon組件，該組件的輪詢策略能夠?qū)Ω鱾€微服務(wù)進行逐個調(diào)用；重試機制能夠識別并跳過無法使用的微服務(wù)而調(diào)用集群內(nèi)的其他微服務(wù)。這種云端算法集群方式，不僅能夠使用多種算法運算來提高優(yōu)化程度，還能在不停止管控系統(tǒng)運行的前提下對算法進行優(yōu)化升級或者增刪算法。

(5)云端部署 為降低集成商在系統(tǒng)所需服務(wù)器方面的硬件和管理成本，將最消耗算力的算法部分部署到云端。對此，在云端部署方面，采用的是彈性計算服務(wù)器(Elastic Compute Service，ECS)，ECS相當(dāng)于一臺虛擬服務(wù)器的實例，包含操作系統(tǒng)或軟件的鏡像、高性能低時延的塊存儲等，具有性能高、穩(wěn)定可靠且能彈性擴展的特點。發(fā)展成熟的云計算服務(wù)使得ECS的部署變得簡單高效，首先配置云服務(wù)器相關(guān)的安全組規(guī)則、密鑰以及微服務(wù)相關(guān)的運行環(huán)境，然后將微服務(wù)打包成Java歸檔(Java Archive，JAR)上傳到云端部署啟動即可完成部署。

(6)系統(tǒng)可用性 管控系統(tǒng)由多個微服務(wù)組成，服務(wù)間的互相調(diào)用使其之間存在耦合，若某個微服務(wù)宕機，則易產(chǎn)生雪崩效應(yīng)。對此，采用RabbitMQ消息隊列對需要頻繁傳輸數(shù)據(jù)的微服務(wù)進行解耦，采用Hystrix熔斷器服務(wù)降級模式避免雪崩效應(yīng)，以提高系統(tǒng)的可用性。

6.1.3 系統(tǒng)質(zhì)量優(yōu)勢

系統(tǒng)質(zhì)量的優(yōu)劣直接影響系統(tǒng)應(yīng)用效果，是系統(tǒng)最終落地應(yīng)用的關(guān)鍵因素。因此，本文系統(tǒng)設(shè)計方面，考慮了開發(fā)效率、穩(wěn)定性和可維護性3方面的系統(tǒng)質(zhì)量屬性。

(1)開發(fā)效率 系統(tǒng)基于SpringCloud技術(shù)框架開發(fā)，可直接使用該框架的原生組件進行微服務(wù)治理，并結(jié)合SpringBoot開發(fā)風(fēng)格進一步提高開發(fā)速度。例如，本文管控系統(tǒng)中的SpringCloud Hystrix熔斷器使用非常簡便，能夠大大降低開發(fā)人員的工作量，其創(chuàng)建代碼如下：

@SpringBootApplication

@EnableCircuitBreaker

public classHystrixMSCApplication {

public static void main(String[]args){

new SpringApplicationBuilder(HystrixMSCApplication.class).web(true).run(args);

}

}

同時，由于SpringCloud微服務(wù)為主流技術(shù)棧，國內(nèi)具備相關(guān)技術(shù)的程序員數(shù)量充足，集成商后續(xù)對系統(tǒng)進行迭代更新和運維的人力成本不高。另外，將比較耗算力的算法部分部署到云端，降低了服務(wù)器成本。

(2)穩(wěn)定性 微服務(wù)架構(gòu)將單體應(yīng)用拆分為多個微服務(wù)，在擁有能夠解耦、易于開發(fā)維護、可伸縮性高等優(yōu)勢的同時，對服務(wù)治理形成了挑戰(zhàn)。SpringCloud來源于Spring，經(jīng)過Netflix網(wǎng)站的實踐，在質(zhì)量、持續(xù)性、項目社區(qū)活躍度、文檔成熟度等方面都可以得到保證。本文采用其熔斷器、消息隊列、負(fù)載均衡等服務(wù)治理技術(shù)來確保系統(tǒng)的可用性，出現(xiàn)故障時也能夠利用其成熟的社區(qū)文檔來解決，因此穩(wěn)定性較高。

(3)可維護性 基于第4章的分層設(shè)計，其將業(yè)務(wù)邏輯、持久化數(shù)據(jù)庫與算法處理解耦，并以單個微服務(wù)的形式存在。發(fā)展集成商運營模式而導(dǎo)致的業(yè)務(wù)邏輯變更或?qū)λ惴ㄌ幚聿糠值膬?yōu)化升級，均能夠在不影響系統(tǒng)運行的情況下進行，直接修改相對應(yīng)的微服務(wù)即可，因此具有可維護性。

6.2 裝配現(xiàn)場監(jiān)控

與普通的裝配作業(yè)不同，多地總裝作業(yè)是需要協(xié)同客戶和供應(yīng)商、以手工為主的異地裝配。一方面手工裝配的裝配作業(yè)監(jiān)控對象是人，現(xiàn)行的監(jiān)控方式是靠人工主動報工，存在報工工作量大、數(shù)據(jù)完整性和實時性差的問題；另一方面，裝配現(xiàn)場情況包括與客戶需求相關(guān)的裝配任務(wù)和供應(yīng)商的物料供應(yīng)，具有跨企業(yè)的特點。對此，管控系統(tǒng)通過API方式連接集成商的ERP系統(tǒng)，實時監(jiān)聽并響應(yīng)客戶需求，取代了傳統(tǒng)郵件、會議等時效性差的方式；考慮到客戶和供應(yīng)商自身也存在信息系統(tǒng)，提供Web和API接口兩種方式對接，實現(xiàn)了跨企業(yè)協(xié)同；采用手機APP定位方式自動采集裝配員的作業(yè)信息和預(yù)警報工，使報工具有便利性和實時性，最終完成對裝配現(xiàn)場情況的數(shù)據(jù)采集。

管控系統(tǒng)雖然能夠基于實時采集的數(shù)據(jù)自動生成計劃排程，但是由于整個裝配作業(yè)過程的復(fù)雜性，最終的執(zhí)行指令仍需由管理員進行人工審核，審核修改的依據(jù)為管理員自身的管理經(jīng)驗以及裝配現(xiàn)場情況。對此，設(shè)計了基于“績效—計劃—排程”的數(shù)據(jù)可視化大屏，如圖10所示。其中：績效指過去已經(jīng)發(fā)生的作業(yè)；計劃指在績效的基礎(chǔ)上，疊加已被管理員審核通過的計劃部分，旨在預(yù)測即將發(fā)生的裝配作業(yè)情況；排程指當(dāng)前算法排程的結(jié)果，旨在反映當(dāng)前裝配資源是否充足?？紤]到總裝作業(yè)多地的特點和管理員查看數(shù)據(jù)的便利性，設(shè)計了以地圖形式展示各個客戶地，可直接點擊地點查看作業(yè)情況。

7 系統(tǒng)應(yīng)用分析

7.1 系統(tǒng)使用流程

管控系統(tǒng)采用多種終端實現(xiàn)了對多地總裝作業(yè)過程的敏捷—協(xié)同管控。系統(tǒng)盡可能地將業(yè)務(wù)邏輯處理、算法處理等過程封裝在系統(tǒng)內(nèi)部，用戶僅需在系統(tǒng)所生成計劃的基礎(chǔ)上審核修改即可作為作業(yè)指令，通過終端指導(dǎo)和預(yù)警用戶執(zhí)行任務(wù)，從而提高管控效率，達到對用戶賦能的目的。以廣東佛山某噴釉產(chǎn)線集成商的應(yīng)用為例，系統(tǒng)使用流程統(tǒng)一建模語言(Unified Modeling Language，UML)時序圖如圖11所示，作業(yè)過程相關(guān)人員只需審核修改系統(tǒng)生成的計劃指令、執(zhí)行指令和反饋報工，盡可能地簡化用戶的操作流程，以減少系統(tǒng)實施成本。同時，用戶端也追求極簡化，使用界面以裝配員APP為例，僅展示作業(yè)情況、報工和通信3種必要的頁面，如圖12所示。

7.2 系統(tǒng)優(yōu)勢

相比于傳統(tǒng)手工管理方式和市面上普通的MES系統(tǒng)，管控系統(tǒng)應(yīng)用在集成商作業(yè)過程的優(yōu)勢如表6所示。系統(tǒng)通過多端應(yīng)用和可視化大屏提高管控信息傳達效率，使裝配作業(yè)情況透明化；基于云計算的三階管控機制能夠敏捷響應(yīng)裝配作業(yè)現(xiàn)場中的客戶需求，以及供應(yīng)商的物料供應(yīng)和裝配員的作業(yè)進度情況，以分層多目標(biāo)和云端算法的方式實時排程出有限能力計劃，并結(jié)合人工審核方式實現(xiàn)多用戶跨企業(yè)協(xié)同；基于領(lǐng)域驅(qū)動設(shè)計的分層思想和SpringCloud微服務(wù)技術(shù)框架，開發(fā)具有可維護性、成本低的管控系統(tǒng)，滿足集成商對系統(tǒng)質(zhì)量屬性的要求。

表6 管控系統(tǒng)優(yōu)勢

8 結(jié)束語

本文針對集成商的作業(yè)管控特點和現(xiàn)狀，分析了作業(yè)過程存在的問題和系統(tǒng)質(zhì)量屬性需求，設(shè)計并開發(fā)了多地總裝作業(yè)敏捷—協(xié)同管控系統(tǒng)替代傳統(tǒng)手工管理模式，提高了作業(yè)管控效率。在架構(gòu)方面，基于領(lǐng)域驅(qū)動設(shè)計的分層方法設(shè)計了高內(nèi)聚低耦合的微服務(wù)系統(tǒng)架構(gòu)；在運行機制方面，提出基于云計算的三階管控機制，實現(xiàn)了敏捷響應(yīng)裝配現(xiàn)場和跨企業(yè)協(xié)同多用戶的精細(xì)化管控；在開發(fā)實現(xiàn)方面，基于SpringCloud技術(shù)框架，運用前后端分離、安全認(rèn)證與鑒權(quán)、云端部署等技術(shù)，使系統(tǒng)具有穩(wěn)定性、可維護性和低成本的特點。最后，以廣東佛山某噴釉產(chǎn)線集成商的應(yīng)用為例，闡述了使用流程，并對比分析了系統(tǒng)優(yōu)勢。

管控系統(tǒng)雖然初步滿足了集成商對作業(yè)過程信息化、生產(chǎn)計劃控制及系統(tǒng)質(zhì)量屬性方面的需求，但仍存在計劃排程結(jié)果優(yōu)度一般、疲于應(yīng)付多種運營模式的問題。未來的研究將集中在：①對云端算法部分進行升級，提高優(yōu)化效果；②收集歸納各種常用的運營模式，抽象出一個可二次開發(fā)的標(biāo)準(zhǔn)化業(yè)務(wù)邏輯，減少運行模式變更帶來的工作量；③微服務(wù)之間仍然存在依賴，后續(xù)可運用ServiceMesh架構(gòu)對微服務(wù)之間繼續(xù)解耦，進一步提高系統(tǒng)的可維護性；④航空制造業(yè)中某些企業(yè)在裝配作業(yè)環(huán)節(jié)也采用異地裝配模式，具有“多地”的特點，后續(xù)可針對航空領(lǐng)域特點，研究本文管控系統(tǒng)的二次開發(fā)和應(yīng)用。