周 盛,鄭 瑋
(航空工業西安飛機工業(集團)有限責任公司,陜西 西安 710089)
大型飛機因其在產品設計與制造方面的高度復雜性,不僅是航空工業水平的體現,而且是反映一個國家綜合國力的重要標志[1]。因此,不斷提高大型飛機制造的技術水平、提升大型飛機生產制造的管理水平成為了重要課題。生產計劃是飛機生產制造中的核心環節,直接用來指導車間對零組件進行投產以及交付的時間節點。對于保障飛機裝配進度,在整個生產管理周期中起著重要的作用。尤其是在脈動線成為飛機裝配模式的主流趨勢條件下[2],如何確保生產計劃的實時性和可靠性,成為保障生產、提升生產效率的核心問題之一[3]。該文通過使用分布式與并行計算技術,依據一定的規則將整個運算任務劃分為若干個子任務同時展開并行計算,顯著提高了計算效率。
物料需求計劃(Material Requirements Planning,MRP)是飛機生產計劃的核心算法,大型飛機具有BOM結構復雜、產品構型眾多等特點,使得MRP運算的復雜度遠高于其他工業產品。同時由于大飛機生產過程中頻繁出現工程更改問題,頻繁的工程更改是造成生產數據不完整、不一致、生產計劃脫節等一系列相關問題的主要原因。目前MRP運算中存在的算法實時性較低、生產計劃變更執行響應不及時等問題,已成為飛機生產管控計劃和執行的制約因素[4]。
傳統的MRP運算算法是基于單件小批計劃管理模式,圍繞大批量零部件生產計劃展開的。而大飛機生產計劃具有生產周期長,產品裝配過程復雜和同時包含零件生產、部件裝配、整機裝配等多層次、多階段的面向項目混合生產計劃的特點,因此大飛機的MRP算法與傳統面向大批量制造的MRP算法具有顯著差異。
大飛機的MRP算法基于層次分解的思想,結合飛機PBOM和MBOM結構,將MRP分解為推拉結合的兩個層次而降低復雜問題的解決難度,達到有效解決復雜問題的目的。
在MRP運算理論中,核心是根據BOM數據逐層展開分解,形成生產計劃。在飛機制造過程的典型BOM分為PBOM、MBOM,其中PBOM從飛機零件設計階段開始形成,到生產全部完成最終確定;而MBOM是從飛機裝配過程中形成,當飛機裝配完成后完全確定。這就與傳統的BOM結構穩定后再進行MRP運算的方式有明顯的區別[5]。
同時飛機生產過程具有并行特性,由于飛機生產具有長周期特性,飛機的零組件生產不能等待所有前置條件全部具備才展開。大量工作需要并行協同進行,包括工藝準備、材料采購、工裝準備,這是飛機研制生產規律的必然要求[6]。
因此,在飛機的生產計劃過程中不能直接使用針對大批量生產、結構穩定、串行管理模式的傳統MRP算法。需要在沒有單一和穩定的BOM作為MRP算法的輸入前提下,將PBOM與MBOM有機結合,形成零件生產和裝配拉動結合的MRP算法。在早期投產階段,尚不具備MBOM的情況下,使用PBOM作為MRP運算的輸入,進行需要零件投產的生產計劃運算從而保證零件投產的順利進行。在進入裝配階段時,整機或部件的裝機清單與裝配順序均已確定,裝配所需的AO定版完成,此時,可以根據MBOM中AO包含的零件配套清單確定飛機最終的零件需求。因此,進行裝配拉動運算得到裝機所需的零件需求,并對前序PBOM運算結果進行反饋。通過推拉結合,以PBOM進行零件投產,以MBOM中AO的零件配套需求對投產階段的投產計劃進行補充和完善,保證生產計劃運算管理的順利進行。
大飛機的MRP運算還有如下特性:1)更改頻繁。在飛機設計和生產過程中更改非常頻繁,為了及時響應工程更改,保證生產現場與工藝設計數據的同步和一致,需要針對同一主計劃需求每日多次進行MRP運算。2)運算復雜。由于飛機結構的復雜性,飛機BOM結構的層次數量和節點數量遠超過一般工業產品,MRP運算的運算復雜度很高。
在大飛機MRP運算中存在運算邏輯復雜、運算次數頻繁、運算數據規模大、需要進行多輪運算等特點。傳統的單機MRP運算在處理大規模運算時,受到單一計算節點處理能力的限制,通常會使計算時間超出預期,甚至無法產生計算結果。因此,在大飛機MRP運算中需要引入新的計算理論和計算技術,突破傳統的單機MRP運算限制。
秦明月再問了一些問題,已經沒什么價值了,他掏出名片給兩個搬運工,告訴他們要是再想起什么可以給他打電話,搬運工如釋重負地走了。
分布式計算是通過計算機網絡將同一網絡區域中的大量計算機組合,形成一個較大的計算系統。將單一的計算任務拆分為若干較小的計算任務,并在不同的計算節點上分別完成這些任務,最終將各個節點的運算結果進行匯總聚合。通過分布式計算可以在更有限的時間內,完成更大規模計算的任務[7]。
相對于傳統的單機計算,分布式計算具有以下優勢:1)通過分布式計算平臺而非人工的方式進行計算任務的管理;2)分布式計算可以充分利用企業網絡中的大量計算資源在支出與性能之間尋找到一個平衡點;3)分布式計算中,各個計算節點運算數據及計算任務均是相對獨立的,有利于構建高度可用的系統。
對于包括MRP運算在內的分布式計算核心需要考慮的是分割后的計算任務調度算法設計,調度算法的核心目標是將計算任務根據一定的策略分配到盡可能最優的執行節點。調度算法的優劣,對于分布式計算平臺的執行效率起著關鍵性作用[8]。
常見的任務調度算法有集中式任務調度算法和分布式任務調度算法。集中式任務調度算法是指由單一的計算機調度任務,使用中心化的方式管理資源和調度任務。集中式調度算法的主要問題在于中心化節點的存在,導致整體的可容錯性與可擴展性較差[9]。為了解決這一問題逐漸演變出分布式任務調度模式,在分布式任務調度模式中沒有中央計算機統一調度任務,任務調度及控制由每個計算節點完成,各個計算資源的節點可以提供任務調度方法,通過節點間的協調判斷計算任務的執行隊列[10]。由于系統中取消了中央處理單元,所有的調度器之間也不進行系統間通信,因此具有以下優勢:1)減少調度延時;2)取消中心化調度器,使用多個調度單元并行執行,保證計算的并行度;3)使用多隨機的調度方法,提升計算任務的健壯性。
綜上所述,采用去中心化調度的分布式調度算法在大規模MRP運算的場景下具有更高的計算并行度和可靠性,因此該系統的核心算法設計采用了分布式調度算法。
系統架構如圖1所示。數據預處理模塊主要對計算過程中需要頻繁查詢的基礎數據進行預處理和預加載,以提升數據讀取和計算效率;任務調度模塊接收需要完成的MRP運算任務,并將計算任務差分后分發到合適的計算節點;計算執行模塊對MRP計算任務進行分布式執行運算,執行完成后上報任務執行的結果和狀態;消息隊列模塊提供任務的分發和傳遞通道,完成運算結果數據回傳。運算日志模塊提供對任務調度執行日志的查看和狀態監控功能。

圖1 系統架構框圖
在進行MRP運算前,需要對數據進行初始化操作,加快數據讀取,將物料、工藝路線、BOM實例等數據初始化進內存緩存Redis中,后續運算可直接根據Key獲取對應數據,避免頻繁查詢數據庫。由于MRP需要預處理的數據文件規模龐大,該系統采用MapReduce的思想,將數據文件分為幾個小的分區,并通過K-V鍵值對的方法將數據散列存儲在分布式內存緩存集群中,保證可承載的數據量[11]。
任務調度模塊是分布式并行MRP系統中的核心模塊,其算法如圖2所示。在MRP計算過程開始前,首先構建出當前MRP計算的執行計劃樹,計劃樹記錄了并行計算任務之間的關聯關系。當并行計算任務由于異常故障丟失,任務調度模塊可以根據計劃樹重新恢復丟失的計算任務并再次分發出去。任務調度模塊同時對外部提供了可視化界面,界面實時動態展示了正在運行中的MRP運算任務。任務的分布式與容錯恢復對用戶是完全透明的,任務調度模塊將計算任務的調度控制節點和任務執行計算節點均納入統一的資源管理。系統引入負載均衡,實時監控每個節點的運行情況,并根據節點的運行狀況下發計算任務。

圖2 任務調度算法
為了使系統有效發揮分布式計算的優勢,將接收到MRP運算任務的調度數據散列到不同的調度節點上。當任意一個調度節點在收到MRP運算任務后,將運算任務拆解為多個子任務,然后再將子任務分發出去,多個計算節點共同完成計算。在計算過程中若發現任務運算量過高,則不斷拆解成子任務,直到節點計算完成后將計算結果反饋為發送計算完成的消息。通過并行調度算法的方式實現任務并行調度分發,降低了調度節點單機負載[12]。為了支持迅速完成的任務調度規則計算,每次任務調度的數據均保存在內存中而不是磁盤上,這樣可以減少每次調度對磁盤I/O的占用,降低等待時間,提高任務分發調度效率[13]。
在計算執行模塊中,需要根據任務調度模塊分發的計算任務讀取運算數據并完成計算,其流程如圖3所示。

圖3 計算執行流程圖
MRP運算任務執行節點根據MRP運算的運算策略,拉取策略中的物料、架次及對應主計劃的信息,生成MRP運算日志。同時發起MRP運算任務,即將以上信息作為消息體發送到消息隊列模塊中。
接收MRP運算任務后,執行節點的MRP運算單元實時監聽消息隊列模塊中MRP運算所對應的消息隊列,同時接收消息體,開始進行MRP運算。
MRP運算過程中根據預處理結果構建出單機BOM樹,自頂向下逐層遍歷,生成WO,然后保存在對應的TEMP臨時表中。在從上向下遍歷的過程中開始執行分片操作,即將每個子節點的信息作為消息體發送到MQ中,形成一個子任務,其余運算單元繼續監聽隊列。當該機型架次的MRP運算完成后,發送消息到消息隊列模塊中,通知MRP服務更改運算日志狀態為成功。
裝配拉動運算過程中,由于裝配計劃開完工日期的計算是在編制裝配拉動計劃部分來完成的。然后在構建BOM樹的過程中將時間貫徹到對應節點上,最終由MRP運算的過程進行最終貫徹,即輸出到WO上。
消息隊列模塊負責完成系統中實時通信消息的傳遞,在該系統中有3種類型消息在消息隊列模塊投遞:1)任務調度生產的正向MRP計算任務消息,計算任務消息為消息隊列模塊主要投遞的消息類型,同時數據量級是較大的;2)MRP運算完成消息通知是計算執行模塊任務計算過程中,判斷全部MRP計算任務均已處理完后發出的消息通知,調度模塊收到該類型消息后記錄MRP運算任務日志;3)計算異常反饋類型消息,計算執行模塊任務計算過程中發生異常時會及時發出異常消息反饋,調度模塊收到異常反饋后會做出相應的處理[14]。
運算日志子模塊主要包括日志視圖查看、任務日志搜索和任務監控告警。日志視圖主要分為計算任務調度日志視圖與計算節點任務執行日志視圖;日志搜索功能根據關鍵字等條件搜索任務日志,并按開始時間顯示任務歷史調度日志;任務監控報警模塊對調度或執行失敗后的技術任務進行監控,并發出相應的報警,通知運維管理人員介入重試和恢復操作[15]。
為了驗證基于大規模分布式并行MRP計算的綜合性能和穩定性,該文與傳統的單機計算展開了對比實驗,驗證分布式并行算法的穩定性[16]。
為完成上述測試,需要基于參數相同的軟硬件和計算任務規模,設計測試參數如表1所示。

表1 測試參數
運算效率是該系統的核心優化指標,通過對單位時間內完成計算任務的數量進行測試可以表征系統的運算效率。
如圖4所示,隨著運算時間的增加,傳統單機運算與文中分布式并行計算的MRP運算完成次數有所增加;但該系統實現的分布式并行MRP算法效率始終高于傳統平臺。當持續運算10 min時,傳統單機運算完成兩次MRP運算,文中的分布式計算完成9次MRP運算;當持續運算30 min時,傳統單機運算完成6次MRP運算,文中的分布式計算完成23次MRP運算;當持續運算60 min時,傳統單機運算完成12次MRP運算,文中的分布式計算完成46次MRP運算。分布式并行計算方式效率相比傳統單機運算效率提高了300%,達到了系統構建目標。

圖4 運算效率對比
除了運算效率外,任務吞吐量與平穩性也是衡量分布式計算系統的重要指標,實驗持續運行該系統中分布式并行MRP運算60 min,結果如圖5所示。任務吞吐量最低為59 900個/min,最高為60 300個/min,平均60 136個/min。驗證了分布式并行計算具有較高的吞吐量,達到了設計要求。吞吐量波動范圍小于0.4%,且在長時間運算后系統仍可以保證充足的吞吐量。

圖5 系統吞吐量運行圖
該系統設計的分布式并行MRP運算系統,經過實驗驗證,運算效率提升約300%,可以有效節約MRP運算所需時間,極大提高MRP運算的計算效率,提升MRP運算的實時性。為大飛機的生產計劃提供了一種自主、可控、高效能MRP運算方案,為進一步推進分布式計算在飛機制造領域的應用提供了理論基礎。