基于有限狀態機的數字化加工單元管控系統研究與應用

陳加才，張虎，文紹華，劉永坡，陳勇

(四川航天長征裝備制造有限公司，四川成都 610100)

0 前言

加工單元是一種能獨立完成特定生產任務的制造系統[1]。隨著物聯網、信息物理系統等技術的發展，單元的生產效率不斷提高[2]。然而，一方面，現有單元數字化程度仍不高；另一方面，企業生產模式正由單品種大批量向多品種變批量過渡。為提升產能，企業必須提升對生產過程信息的掌控能力。加工單元作為企業實現智能制造、數字化決策等目標的數據源，其數字化程度直接影響生產效率。因此為解決上述問題，有必要針對加工單元的管控系統進行研究，實現單元全流程數字化管控與面向多品類產品的柔性制造[3]。

加工單元的控制核心在于PLC，而RFID是實現數字化追蹤的關鍵[4]。根據PLC控制策略，王元生等[5-7]實現了單元自動裝卸、機床控制。通過對加工流程進行分析，何佩云等[8-9]利用RFID研究了單元柔性控制系統。孔志學等[10-11]利用基于PLC的過程控制算法，開發了設備通信上位機程序。上述研究內容一定程度上實現了單元數字化控制，但仍存在如下不足：(1)設備覆蓋管控與采集難。基于PLC的設計控制策略解決了機床、機器人的管控問題，NC程序傳輸，RFID讀寫等均無法通過PLC完成，且缺少可視化界面。(2)系統維護擴展難。一些研究實現了單元可視化管控，但生產業務與程序代碼高度耦合，難以應對業務變動造成的控制邏輯變化。(3)系統響應慢。現有管控軟件采用面向生產過程的流程化設計，無法做到對設備/設施的狀態實時響應。

基于上述問題，本文作者以某車削單元為研究對象，分析單元生產流程，研究單元信息架構、異構數據采集以及基于有限狀態機的生產調度策略等內容，利用面向對象語言C#開發響應式管控系統，以實現單元數字化柔性生產、可視化/自動化監控。

1 加工單元總體設計

整個單元由4臺數控機床、1臺工業機器人、裝卸臺、暫存工件/托盤的線邊倉、1臺采集數據的總控PLC、管控系統及相應配套設備組成。為減少占地面積，保證作業安全的同時便于觀測生產，單元采用封閉式、單側布局的方式，將機床與線邊倉布置在兩側。為了減少重復搬運、提升運行效率，將工件進出單元的操作布置在同一裝卸臺上，實現裝置復用。單元的整體布局如圖1所示。

單元生產流程的物料流如圖2所示。生產流程分為入庫(工件從裝卸臺運至線邊倉)、上料(工件從線邊倉運至機床)、加工、下料(工件從機床運至線邊倉)、出庫(工件從線邊倉運至裝卸臺)。機器人負責機床加工外的全部流程。為提升柔性生產能力，由托盤裝載工件進行加工，托盤采用RFID作為唯一標識。入庫后，工件會綁定托盤，因此追蹤托盤RFID即可實時監控工件。為保證數據安全，入庫與上料時會校驗RFID，校驗失敗會執行回滾。根據業務需求，在進行生產調度時，出入庫優先級高于上下料。

圖2 加工單元物料流

2 多源異構實時數據流構建

2.1 多源異構數據的實時采集

管控系統控制下的生產調度是一個數據密集型過程，系統需通過不同通信協議和數據結構與各設備實時進行數據流、控制流交互，同時系統內還存在大量維護業務運行的基礎數據。圖3所示為單元信息互通架構，考慮到動態業務數據與靜態基礎信息“動靜分離”管理及后續擴展，根據業務特點與用戶權限分割需求，將管控系統分為基于B/S架構的Web端單元管理平臺和基于C/S架構的調度服務程序。前者部署于Web服務器，負責基礎數據/生產任務管理、看板展示；后者部署于調度服務器，負責讀取任務并執行生產調度、設備通信。為提升系統性能與數據安全性，在二者間部署數據庫/ FTP服務器，存儲運行數據與機床NC程序。

圖3 加工單元信息互通架構

管控系統采用“設備-以太網-client”的三層結構與設備進行通信，將采集數據封裝處理后存儲到數據庫中，以實現單元生產調度與信息展示。為降低數據復雜度，提升通信效率，采用PLC作為數據主源，將單元大部分數據集中采集后過濾、驗證、打包，并利用TCP/IP協議傳輸給系統，其他不能集成通信的數據則以各設備協議進行傳遞，如RFID數據(TCP/IP、串口)、NC程序等(FOCAS協議)。

2.2 異構數據的封裝與處理

硬件設備運行數據是管控系統進行生產調度的邏輯依據[12]。為屏蔽異構數據的多樣性，在管控系統內構建了針對底層硬件的通信模塊。模塊數據流如圖4所示。

模塊介于上層業務代碼與底層設備間，包括API、異常處理、數據處理、緩沖區、硬件通信等子模塊。在系統進行硬件通信時，考慮到可能存在因車間生產現場業務需求的變化而造成的硬件設備變更，管控系統應盡量減少與硬件設備的耦合程度，并具備可擴展的通信能力。根據上述需求，將通信配置信息(報文結構、通信地址、通信協議等)以JSON字串的形式在數據庫/配置文件中持久化存儲，由該模塊利用數據讀取技術加載到內存后，生成數據映射字典。模塊在與設備數據進行交互時，利用數據映射字典，根據通信數據字節索引、比特索引、對象類名、屬性名、對象編號等配置內容進行數據映射，實現非結構化字節數據和系統使用的結構化對象數據雙向映射。

為提升系統的響應能力，減少無效請求，模塊在進行數據映射后，采用事件響應完成數據傳遞，上層則通過調用API將控制數據注入模塊，實現系統與底層硬件雙向通信。

3 基于有限狀態機的生產調度設計

有限狀態機(Finite State Machine，FSM)也稱有限狀態自動機，是一種面向事件驅動型系統的建模工具[13]。對于適用FSM建模的系統，其只有有限狀態，且始終處于某行為確定狀態。系統下個狀態是當前狀態和輸入內容的函數。系統會響應外部/內部事件，并進行狀態跳轉或維持當前狀態。

由于設備/設施行為可預測，因此可利用FSM對單元關鍵調度對象進行建模，控制其狀態轉移，并基于異步編程與事件驅動設計構建響應式系統，從而避免無效等待，實現有序調度，增強可重構能力。

3.1 生產調度過程建模

為優化建模過程，提出以下對象選擇原則：(1)應滿足FSM特征；(2)生命周期應盡量覆蓋單元生產流程；(3)狀態轉換應盡量多地調動設備運轉，從而提高效率。基于上述原則，由于搬運任務均由機器人完成，而工件生命周期內系統對各設備均有調用，但對二者單獨建模均無法覆蓋整個生產流程，因此文中分別對機器人及工件進行FSM建模。

3.1.1 機器人調度對象運行建模

機器人調度對象由機器人設備及其任務信息組成。任務類型包括入庫、出庫、上料、下料、回滾。單個任務包含一或多條原子級機器人指令，并可能涉及其他設備的調用、數據庫的讀寫等操作。根據任務類型和優先級，對象狀態如表1所示。

機器人調度對象由用戶/硬件觸發的外部事件驅動。為體現出入庫優先級高于上下料的業務需求，依據任務區分了驅動事件，包括：鎖定機器人C0、添加入庫C1、添加出庫C2、裝卸臺/線邊倉未就緒C3、校驗失敗C4、檢驗成功C5、上料請求C6、下料請求C7、任務完成C8、硬件故障C9、硬件恢復C10、窗口關閉C11、運行調試C12。

用戶點擊出入庫或調試機器人時，若機器人空閑，系統會將它鎖定，并僅響應出入庫/機器人調試而忽略上下料，否則系統會待其執行完當前任務再鎖定。當未添加任務并關閉窗口時，機器人回到空閑狀態，可響應上下料。校驗RFID時，若校驗失敗，會執行回滾(將工件退回裝卸臺/線邊倉)。考慮到系統的安全性，機器人硬件故障時，無論當前處于何種狀態，系統將跳轉到故障并報警。檢測到機器人正常后，系統跳轉到之前狀態并繼續執行。基于上述流程，調度對象狀態轉移過程如圖5所示。

圖5 機器人調度對象狀態遷移過程

3.1.2 工件調度對象運行建模

工件調度對象面向單元內工件建模，其運行狀態由工件位置、托盤綁定、機床狀態等信息決定。根據工件生命周期中加工、流轉過程，可得其狀態如表2所示。

表2 工件調度對象狀態

工件調度對象由機器人/機床觸發的外部事件驅動。通過分析加工流程，總結出如下事件：運至裝卸臺C0、運至線邊倉C1、運至機床C2、機床確定C3、NC程序傳輸完成C4、機床加工完成C5、讀取到RFID C6、取消綁定C7。

用戶將工件安裝在托盤并固定于裝卸臺后，點擊入庫，指定加工任務。入庫流程中，系統讀取RFID，使工件綁定托盤。監測到有機床空閑時，系統在倉內找到匹配工件，傳輸/校驗NC程序并啟動機床。機床請求上下料時，系統自動響應請求。工件在線邊倉時(處于S2、S3、S4或S7)，用戶點擊出庫，系統調度機器人搬運，同時解綁托盤，并終結該對象。據此可得工件狀態遷移過程如圖6所示。

圖6 工件狀態遷移過程

3.2 基于事件驅動的FSM程序設計

FSM的實現模式有過程模式、狀態模式等[14]。過程模式利用嵌套條件語句實現事件觸發/狀態跳轉。狀態模式將控制邏輯基于狀態拆分，能避免過程模式維護困難的問題，但狀態間切換無明確表達，沒有體現事件的驅動特性，不利于擴展。

由于上述問題的存在，文中基于狀態模式改進了面向生產調度過程的狀態機結構。考慮到同時調度多個對象的需求，簡化了調度對象的數據結構，將狀態/行為分離，由調度對象動態保存狀態，由狀態處理程序靜態保存對象跳轉策略。圖7所示為狀態機結構及該結構下實現機器人/工件調度的程序類圖，展示了以下關鍵類部分屬性、函數和關系。

圖7 狀態機的類

IStateMachineContext接口：狀態機調度對象，保存了狀態變量與運行信息。

泛型T：調度對象類型約束，約束為實現IStateMachineContext接口的類。

IStateHandler接口：泛型狀態處理程序，聲明了處理的狀態(CurrentState)、狀態輸出(DoStateAction)、跳轉事件監測(GetEvent)和跳轉邏輯(GetNext)。

IDriveData接口：驅動數據，由外部系統注入，包含了外部系統觸發的事件及調度對象標識，如工件/機器人編號等。該數據是狀態轉移驅動源。

StateMachine類：泛型狀態機，由調度對象集合ContextList、處理程序集合HandlerList、驅動管道DriveQueue、驅動函數DriveMachine、數據注入函數InsertDrive、調度對象注冊/取消函數RegContext/UnregContext等組成。

WorkpieceContext類：實現IStateMachineContext接口的工件調度對象。

RobotContext類：實現IStateMachineContext接口的機器人調度對象。

其余為機器人運行狀態(S0-S12)與工件運行狀態(S0-S9)對IStateHandler實現類(限于篇幅未完全畫出)。

當系統需調度新工件/機器人時(如新工件入庫)，調用狀態機RegContext即注冊調度對象。這使系統分別對WorkpieceContext類與RobotContext類創建一個狀態機實例，并以較小的數據結構便可生產調度。當業務變動導致對象調度邏輯新增/變更時，僅需創建IStateHandler對應實現類，或對已有實現類進行少量修改，保證了系統可擴展性。

圖8所示為狀態機的程序流程。當事件觸發時，系統執行InsertDrive注入數據。狀態機內由單獨線程執行DriveMachine。

圖8 事件驅動流程

該函數從DriveQueue獲取驅動，依據標識找到調度對象后，由其狀態獲取對應IStateHandler實例并執行DoStateAction完成狀態輸出，隨后執行GetEvent判斷跳轉事件是否觸發，若觸發，則根據事件id執行GetNext，更新調度對象狀態，實現狀態跳轉。

4 實現與驗證

4.1 系統技術實現

考慮到編碼時調用多方dll的需求，文中采用面向對象語言C#編程，以SqlServer2018為系統數據庫，利用FTP進行文件傳輸，并用IIS管理器完成服務(Web/FTP服務)部署。

圖9所示為管控系統軟件架構。單元管理平臺為B/S架構。為降低耦合度，基于.NET Core技術，采用Vue +WebAPI前后端分離方案。單元管理平臺處于系統上層，還負責與外部MES數據通信，該方案保證在已有代碼基礎上，對MES開放指定接口即可通信，提升了系統動態集成能力。

圖9 管控系統軟件架構

調度服務程序采用C/S架構，由于它直接與硬件設備通信，因此技術方案應具備快速開發調試、易于部署的能力。據此，采用了Winform+MVC的方案，利用Winform控件庫進行程序界面的迅捷設計，通過MVC模式實現了UI與數據的解耦。

4.2 運行驗證

文中將開發的管控系統部署在四川航天長征裝備制造有限公司某車間車削單元，圖10所示為管控系統程序界面與單元運行展示。該系統實現了基于生產現場運行事件的自動響應與調度控制，能根據生產任務自動控制相關設備實現物料轉運、倉儲管理、生產加工、日志記錄。使用該管控系統后，加工單元對工件實現了100%的狀態追蹤，形成了面向單元生產現場的實時可視化/自動化化監控、異常處理、設備保護、數據統計與分析一體化系統。

圖10 單元運行展示

5 結語

文中針對加工單元數字化管控所需解決的設備管控與采集難、數字化程度低、系統響應慢等問題，利用.NET技術，設計并開發了基于FSM的數字化管控系統。該管控系統的特點如下：(1)通過B/S與C/S架構的組合設計，將基礎數據與生產數據動靜分離，與硬件設備組成了單元信息互聯互通架構。(2)構建了可配置通信格式的設備通信模塊，實現多源異構設備實時數據采集與封裝處理。(3)基于響應式系統設計，利用FSM對生產調度進行行為建模，能夠依據生產事件驅動單元自動化生產調度與設備管控。

此管控系統已在公司某車削單元完成了測試與部署。經測試，在系統控制下，此單元實現了全流程數字化自動生產調度，為后續數字孿生車間、數字工廠的建設提供了數據基礎。