遵循模型驅(qū)動設(shè)計策略的系統(tǒng)化數(shù)控機(jī)床核心設(shè)計方法研究

遵循模型驅(qū)動設(shè)計策略的系統(tǒng)化數(shù)控機(jī)床核心設(shè)計方法研究,遵循,模型,驅(qū)動,設(shè)計,策略,系統(tǒng)化,數(shù)控機(jī)床,核心,方法,研究 遵循模型驅(qū)動設(shè)計策略的系統(tǒng)化數(shù)控機(jī)床核心設(shè)計方法研究 劉亞東，郭新貴，李偉，山崎和夫 加州大學(xué)機(jī)械與航空工程系 關(guān)鍵字 數(shù)控核心，模型驅(qū)動設(shè)計，狀態(tài)圖，數(shù)據(jù)流圖 摘要 為了克服傳統(tǒng)的硬件預(yù)定設(shè)計的缺點(diǎn)，我們提出了一種模型驅(qū)動設(shè)計（MDD）的方法來設(shè)計CNC核心。按照這種方法，選擇狀態(tài)圖來模擬數(shù)控核心的行為，并應(yīng)用數(shù)據(jù)流圖（DFD）來模擬數(shù)控核心內(nèi)部與NC程序相關(guān)的數(shù)據(jù)處理。然后，對基于Statechart的CNC核心模型進(jìn)行仿真，以檢查其正確性。在最后的實施階段，提出了一種新穎的數(shù)控核心結(jié)構(gòu)，其中實施軟件分為兩部分：設(shè)計規(guī)范相關(guān)數(shù)據(jù)和處理引擎，這極大地簡化了系統(tǒng)調(diào)試和重新設(shè)計。與規(guī)范相關(guān)的數(shù)據(jù)是由成熟的狀態(tài)圖模型生成的，它可以在未來可能的變化中進(jìn)行更新。處理引擎只需設(shè)計一次，將來也會保持不變。最后，一個原型系統(tǒng)已經(jīng)被開發(fā)出來，并證明了所提方法的可行性。 簡介 數(shù)控系統(tǒng)已在工業(yè)界廣泛使用多年。但即使在今天，它們?nèi)匀皇亲鳛閷Ｓ械?、供?yīng)商特定的解決方案提供的，不能滿足機(jī)床制造商所要求的功能更新、定制和降低成本的需求。這些解決方案的主要局限性被總結(jié)為以下幾點(diǎn)。 首先，很難加強(qiáng)專有的數(shù)控系統(tǒng)。通常情況下，要想更快地生產(chǎn)出更好的零件，往往意味著要為數(shù)控系統(tǒng)配備額外的設(shè)備，以提高其感知和補(bǔ)償工藝參數(shù)的能力，如力、扭矩、振動或熱。在專有系統(tǒng)中，大多數(shù)情況下，增加傳感器和使用這些傳感器的軟件只能由原始制造商來完成，而且往往要付出很大代價。 其次，機(jī)床用戶不能輕易訪問CNC內(nèi)部的數(shù)據(jù)。不管是否需要修改控制器的功能，用戶都認(rèn)為，只要把工藝數(shù)據(jù)從機(jī)床上拿下來，就是一個很大的進(jìn)步。 第三，使用專有數(shù)控系統(tǒng)的成本也很高。不同的控制器有不同的操作界面和程序格式。因此，受過培訓(xùn)的人在操作機(jī)器時使用一種類型的控制器，往往不能操作安裝了不同控制器的類似機(jī)器。在有幾十種控制器類型的大型車間里，機(jī)械師不能輕易地從一臺機(jī)器移到另一臺機(jī)器上，這是一個嚴(yán)重的制約效率和靈活性的因素。 最后，維護(hù)專用數(shù)控系統(tǒng)的成本也很高。例如，臺式電腦的硬盤、內(nèi)存和CPU的升級是現(xiàn)成的，而且價格低廉。而另一方面，對于數(shù)控系統(tǒng)來說，這些部件往往更加昂貴，有時甚至完全不可用，僅僅是因為原始供應(yīng)商停止生產(chǎn)。 為了克服這些限制，許多機(jī)床制造商開始開發(fā)自己的數(shù)控系統(tǒng)。然而，他們中的大多數(shù)并不成功，因為數(shù)控系統(tǒng)是非常復(fù)雜的，沒有一個數(shù)控系統(tǒng)制造商愿意公開他們的技術(shù)訣竅。雖然有幾個國家的研究項目被提出來進(jìn)行開放式結(jié)構(gòu)的CNC設(shè)計，如OSACA（歐洲）、OMAC（美國）和OSEC（日本），但它們大多是針對CNC的模塊化和模塊間的接口標(biāo)準(zhǔn)化，關(guān)于CNC內(nèi)部結(jié)構(gòu)的信息并不多。 本文闡明了數(shù)控系統(tǒng)的邏輯結(jié)構(gòu)。數(shù)控系統(tǒng)分為幾個部分：人機(jī)界面（HMI）、數(shù)控核心、運(yùn)動控制器（MC）和PLC?；谶@樣的模塊劃分，預(yù)計可以很容易地設(shè)計一個數(shù)控系統(tǒng)，并整合機(jī)床制造商的專有功能，而不依賴于特定的數(shù)控系統(tǒng)供應(yīng)商。本文主要關(guān)注第二部分。數(shù)控核心。 模型驅(qū)動的設(shè)計方法 為了進(jìn)行數(shù)控設(shè)計，圖1顯示了一種傳統(tǒng)的方法，在這種方法中，設(shè)計者往往在規(guī)格分析之后立即選擇硬件/軟件平臺，然后進(jìn)行系統(tǒng)設(shè)計。然后，主要的設(shè)計活動將集中在基于預(yù)先確定的平臺的軟件編程上。最后階段是測試和調(diào)試。這樣的方法有很多缺點(diǎn)。 圖1 傳統(tǒng)系統(tǒng)設(shè)計流程 首先，這是一種典型的逐案處理的方法。最終的設(shè)計結(jié)果往往強(qiáng)烈依賴于設(shè)計者的經(jīng)驗。最終的設(shè)計結(jié)果是否反映了原意，取決于設(shè)計者對文本格式的原始規(guī)范的理解。文本說明趨向于模糊和不完整。此外，隨著現(xiàn)代機(jī)床的功能變得越來越復(fù)雜，設(shè)計者更難弄清規(guī)范的正確性。因此，可能會有更多引入錯誤的可能性。這些錯誤在建立原型系統(tǒng)之前是很難發(fā)現(xiàn)的。 第二，系統(tǒng)設(shè)計必須局限于特定的硬件，因為硬件在一開始就已經(jīng)確定。一般來說，一個項目會持續(xù)一到兩年，硬件的發(fā)展非?？?，兩年后會有很大的變化，然而，那時的系統(tǒng)設(shè)計者不能輕易應(yīng)用，因為整個設(shè)計是基于兩年前的硬件。因此，系統(tǒng)設(shè)計者不能自由地思考他們的設(shè)計。設(shè)計結(jié)果將不再是最佳的。如果系統(tǒng)設(shè)計者試圖應(yīng)用這種新的硬件技術(shù)，整個系統(tǒng)的開發(fā)就必須從頭開始。 最后，在一個控制系統(tǒng)中，數(shù)據(jù)和數(shù)據(jù)處理通常在軟件代碼中。要找出代碼的哪一部分與規(guī)范的相應(yīng)部分有關(guān)并不容易。如果在規(guī)范中需要進(jìn)行一些修改，設(shè)計人員需要翻閱整個代碼來找到相應(yīng)的部分。即使是一個小的修改，也可能導(dǎo)致大量的bug，因為修改的部分與代碼的其他部分不一致，這使得系統(tǒng)的調(diào)試更加困難和費(fèi)時。從某種意義上說，對于一個新的設(shè)計，即使它與現(xiàn)有的設(shè)計有相當(dāng)相似的規(guī)格；大多數(shù)設(shè)計者更愿意從頭開始，而不是修改現(xiàn)有的代碼。 圖2 模型驅(qū)動的設(shè)計流程 本文提出了一個模型驅(qū)動設(shè)計（MDD）的方法來加強(qiáng)數(shù)控系統(tǒng)的核心設(shè)計，如圖2所示。通過這種方法，設(shè)計人員首先分析規(guī)范，并使用一些計算機(jī)輔助控制系統(tǒng)設(shè)計（CACSD）工具建立一個可執(zhí)行的系統(tǒng)模型。然后，這個模型將被模擬，以確保它的行為與預(yù)期相同。最后，系統(tǒng)的實現(xiàn)將被構(gòu)建成兩部分：與規(guī)范相關(guān)的數(shù)據(jù)和一個過程引擎。與規(guī)范相關(guān)的數(shù)據(jù)將直接轉(zhuǎn)換為從一個成熟的模型和對應(yīng)的個人規(guī)范。過程引擎是為了解釋與規(guī)范相關(guān)的數(shù)據(jù)。使用這個方案，系統(tǒng)調(diào)試和重新設(shè)計變得更加容易。例如，當(dāng)規(guī)范被修改或給出一個新的版本時，只有規(guī)范相關(guān)的數(shù)據(jù)需要重新生成。處理引擎將始終保持不變。將MDD方法應(yīng)用于數(shù)控核心設(shè)計的關(guān)鍵問題是：如何對數(shù)控核心進(jìn)行建模，如何驗證模型，以及如何從經(jīng)過驗證的模型中實現(xiàn)。 Cnc核心邏輯模型 數(shù)控系統(tǒng)概述 數(shù)控系統(tǒng)由幾個部分組成，每個部分都有特定的功能。人機(jī)界面有兩個部分：機(jī)器控制面板和數(shù)控面板。操作員的要求，如工作模式切換、功能選擇和手動機(jī)器控制，都是通過機(jī)器控制面板提出的。NC面板就像PC的顯示器，顯示CNC/機(jī)床的工作狀態(tài)，允許用戶編輯NC程序和參數(shù)。數(shù)控核心負(fù)責(zé)管理任務(wù)和數(shù)控程序處理。它處理伺服控制和主軸旋轉(zhuǎn)，以確保刀具和工件之間的相對運(yùn)動能夠準(zhǔn)確嚙合。PLC負(fù)責(zé)處理機(jī)床的訪問控制，包括來自CNC核心的PLC命令，換刀順序邏輯，報警等。 功能分析 為了建立一個數(shù)控系統(tǒng)核心的模型，其主要功能模塊在圖3中得到澄清。它從人機(jī)界面讀取兩種輸入：操作員的請求和通過其通用API的NC程序。經(jīng)過處理后，CNC核心將其運(yùn)行狀態(tài)輸出到人機(jī)界面，并通過實時接口向MC和PLC發(fā)出兩種命令。這兩種命令是MC和PLC的命令。同時，軸的反饋運(yùn)動位置和PLC響應(yīng)將被送入CNC核心進(jìn)行進(jìn)一步處理。 圖3：數(shù)控核心的功能模塊。 數(shù)控核心是這樣工作的，每次當(dāng)操作者的要求到來時，其中一個最重要的模塊，數(shù)控核心邏輯會根據(jù)具體的操作要求和當(dāng)前的系統(tǒng)狀態(tài)，確定此刻應(yīng)該激活哪個功能模塊。然后，相應(yīng)的控制功能將在被激活的模塊中執(zhí)行。例如，如果操作人員希望通過選擇某個按鈕在自動操作模式下開始加工，自動控制主管模塊將被觸發(fā)，開始處理NC程序并將結(jié)果發(fā)送到另兩個模塊。運(yùn)動控制處理器和邏輯控制處理器。這兩個模塊將負(fù)責(zé)運(yùn)動插值和順序邏輯準(zhǔn)備，并與外部MC和PLC密切溝通。 凸輪軸芯建模 為了對數(shù)控核心進(jìn)行建模，需要澄清兩種數(shù)據(jù)。它們是與操作者要求有關(guān)的數(shù)據(jù)和與NC程序有關(guān)的數(shù)據(jù)。明確前者是為了建立數(shù)控核心的行為模型，以動態(tài)地觀察其行為。澄清后者是為了建立數(shù)控核心的DFD，以描述數(shù)控程序如何通過相應(yīng)的功能模塊進(jìn)行處理。 行為模型化 狀態(tài)機(jī)建模 數(shù)控核心是一個典型的離散事件系統(tǒng)（反應(yīng)式系統(tǒng)），其特點(diǎn)是：系統(tǒng)分為有限狀態(tài)，在特定的外部刺激下，經(jīng)常從一個狀態(tài)轉(zhuǎn)移到另一個狀態(tài)[1]。該行為這樣的系統(tǒng)完全取決于一段時間內(nèi)異步事件（操作員的請求）的發(fā)生。例如，當(dāng)系統(tǒng)工作在自動模式（狀態(tài)）和緊急停止按鈕被按下（事件）時，系統(tǒng)將從自動模式退出并進(jìn)入緊急停止模式。 狀態(tài)機(jī)是反應(yīng)式系統(tǒng)建模的經(jīng)典方法。使用狀態(tài)機(jī)方法，系統(tǒng)設(shè)計的考慮改變?yōu)椋簩⑾到y(tǒng)劃分為可能的狀態(tài)。然后，在傳入的事件中尋找其在各狀態(tài)之間的可能轉(zhuǎn)換，并確定在狀態(tài)中發(fā)生的或有轉(zhuǎn)換的具體行動。 有限狀態(tài)機(jī)（FSM）是最流行的狀態(tài)機(jī)方法之一。但當(dāng)系統(tǒng)變得復(fù)雜時，它往往是無法管理的。因此，一種對FSM的改進(jìn)，即狀態(tài)圖被引入。Statechart是由Davis Harel在1987年發(fā)明的[2]。這種方法統(tǒng)一了狀態(tài)機(jī)的符號并引入了三個新的特征。 · 它支持層次結(jié)構(gòu)，因此扁平狀態(tài)機(jī)可以用層次結(jié)構(gòu)的方式來表示。 · 它支持并行性；在狀態(tài)圖模型中可以表示兩個并行狀態(tài)。 · 它能夠表示歷史，這使它有可能根據(jù)歷史指定一個過渡的目標(biāo)狀態(tài)。 狀態(tài)圖符號 圖4顯示了Statechart模型的符號。如圖所示，有幾個圖形組件：狀態(tài)、過渡，還有幾個非圖形組件：事件、條件和行動。 一個顯示為圓角矩形的狀態(tài)描述了一個反應(yīng)式系統(tǒng)的模式。一個系統(tǒng)可以被分解成許多具有層次結(jié)構(gòu)的狀態(tài)。一個事件的發(fā)生會導(dǎo)致狀態(tài)的動態(tài)變化。在圖4中，第一層是StateA，它有兩個子狀態(tài)。狀態(tài)A1和狀態(tài)A2。狀態(tài)A1有三個排他性（OR）的子狀態(tài)。狀態(tài)A1a、狀態(tài)A1b和狀態(tài)A1c，這意味著在一個時刻只有一個狀態(tài)可以活動。狀態(tài)A2有兩個平行（AND）子狀態(tài)。StateA2a和StateA2b，這意味著兩個狀態(tài)可以同時激活。 圖4：狀態(tài)圖模型符號。 過渡是一條連接一個狀態(tài)和另一個狀態(tài)的曲線。源點(diǎn)是過渡開始的地方，終點(diǎn)是過渡結(jié)束的地方。一個過渡標(biāo)簽與一條過渡曲線一起描述了系統(tǒng)從一個狀態(tài)到另一個狀態(tài)的情況。一個過渡標(biāo)簽被表示為事件[條件]。 {condition action}/{transition action}。事件是導(dǎo)致過渡發(fā)生的刺激物。條件是確定過渡是否可以發(fā)生的保障。條件動作是當(dāng)條件得到滿足時要調(diào)用的函數(shù)。過渡動作是過渡發(fā)生時要調(diào)用的函數(shù)。 有幾個基于狀態(tài)圖符號的狀態(tài)圖建模軟件，如Matlab的Stateflow、WindRiver的BestState、IAR的VisualState等。 數(shù)控核心的狀態(tài)圖模型 圖5給出了用Matlab的Stateflow建立的數(shù)控核心的狀態(tài)圖模型。該系統(tǒng)是以分層方式組織的。第一層有三個狀態(tài)。關(guān)閉、ESTOP和開啟狀態(tài)。ON狀態(tài)有兩個平行的子狀態(tài)。Core_Logic和Parallel_Tasks狀態(tài)。Core_Logic狀態(tài)有三個獨(dú)占的子狀態(tài)。啟動、正常運(yùn)行和測試運(yùn)行。Normal_Operation是最重要的狀態(tài)之一，可以是分解為更詳細(xì)的工作模式相關(guān)的子狀態(tài)，如自動、手動、編輯等。平行任務(wù)（Parallel_Tasks）有三個平行子狀態(tài)。Task_MLC、Task_MCP 和 Task_LCP 分別描述 CNC 核心內(nèi) MC/PLC 命令分配、運(yùn)動控制處理和邏輯控制處理的行為。 狀態(tài)圖模型模擬 在建立了一個數(shù)控核心的Statechart模型后。應(yīng)用MDD方法的第二個問題是如何驗證這個模型以確保它是理想的模型。這就是模型檢查，它包含兩個步驟：驗證和確認(rèn)。 驗證消除了由于對規(guī)范的誤解而導(dǎo)致的狀態(tài)圖模型的邏輯缺陷。這些缺陷包括沖突的轉(zhuǎn)換、不可達(dá)的轉(zhuǎn)換等等。這個過程相對簡單，大多數(shù)狀態(tài)圖建模軟件都可以完成。 驗證檢查Statechart模型的行為是否與規(guī)范要求的一樣，甚至它在驗證后的邏輯上是否正確。有兩種方法來進(jìn)行這種檢查。一種是理論分析，另一種是模擬。理論分析是一種基于Statechart模型的詳盡狀態(tài)空間探索的形式化方法[3,4]。這個領(lǐng)域正在進(jìn)行大量的研究；但實際應(yīng)用仍有很長的路要走。仿真方法是一種更實用的方法，因此在現(xiàn)實中被廣泛使用。使用這種方法，通常要建立一個模擬環(huán)境。通過使用一組準(zhǔn)備好的場景，一系列的虛擬事件被送入Statechart模型，以驅(qū)動Statechart模型的執(zhí)行。通過比較模型與準(zhǔn)備好的場景的反應(yīng)，不準(zhǔn)確或不正確的設(shè)計結(jié)果可以很容易地被發(fā)現(xiàn)。 使用Simulink的CNC核心。用Matlab的GUI設(shè)計器建立的人機(jī)界面被用來準(zhǔn)備事件、條件和其他數(shù)據(jù)，這些數(shù)據(jù)被發(fā)送到Statechart模型中。在Stateflow環(huán)境中，Statechart模型的反應(yīng)可以根據(jù)規(guī)范的期望進(jìn)行評估。如果發(fā)現(xiàn)任何設(shè)計錯誤，Statechart模型可以被修改并再次模擬，直到證明它是正確的。 數(shù)據(jù)流圖 與NC程序處理有關(guān)的數(shù)據(jù)是另一個重要的數(shù)據(jù)，為了建立一個CNC核心模型，需要澄清。圖7是CNC核心的DFD，它表明了從程序區(qū)加載NC程序，經(jīng)過NCPP和NCPP Buf，由MCP&LCP協(xié)調(diào)器分配到LCP/MCP和PLC/MC Cache的路徑。詳細(xì)流程如下。 1) 一個NC程序從程序區(qū)加載。它首先由NCPP處理，生成相應(yīng)的典型加工函數(shù)（CMF）。CMF是直接的結(jié)果，由NIST定義。其目的是提供一套原始函數(shù)，以涵蓋機(jī)床可以提供的所有可能的功能。 2) 每個CMF將一條MC/PLC命令填入NCPP緩沖區(qū)。每條MC/PLC命令是一條原始指令，對應(yīng)一個機(jī)器動作。例如，MC6000設(shè)置進(jìn)給率，PLC3003打開主軸，等等。 3） NCPP緩沖區(qū)中的每個項目都是一個結(jié)構(gòu)，包括塊號、序列號、命令的完成類型和命令（操作符和操作數(shù)）。 4) 一個MCP&LCP協(xié)調(diào)器（MLC）被用來將這些MC/PLC命令分配給相應(yīng)的處理器。MC命令被發(fā)送到MCP，PLC命令被發(fā)送到LCP。每條命令都是在前一條命令執(zhí)行成功后分配的。 5) 然后，LCP中的PLC命令通過CNC-PLC共享存儲器直接發(fā)送到PLC，以觸發(fā)指定的機(jī)器邏輯控制。 6) MCP中的MC命令是按其功能處理的，主要是插值。插值后的位置被存儲在MC緩存中，由外部MC定期讀取，用于伺服控制。 7) LCP和MCP在執(zhí)行每條命令時都會給MLC以完成響應(yīng)。圖8顯示了MC/PLC的命令是如何在每條命令執(zhí)行后由MLC按順序分配給MCP/LCP的。 系統(tǒng)實施 按照MDD方法，實施的軟件代碼有望在最后階段直接從經(jīng)過驗證的系統(tǒng)模型中生成。對于基于狀態(tài)圖的行為模型，可以這樣做，但對于數(shù)控系統(tǒng)核心模型的DFD，則不能。因此，在本文中，實施軟件的框架首先從數(shù)控系統(tǒng)核心的狀態(tài)圖模型生成[5,6]。然后將數(shù)控核心模型的DFD作為Statechart模型的大部分動作來實現(xiàn)。此外，整個實施軟件由兩部分組成：一個通用處理引擎和規(guī)范相關(guān)數(shù)據(jù)。與規(guī)范相關(guān)的數(shù)據(jù)由一個生成器從StateChart模型中轉(zhuǎn)換而來，而處理引擎則被構(gòu)建為一個引用這些數(shù)據(jù)的不變程序。通過分離引擎和規(guī)范相關(guān)的數(shù)據(jù)，實現(xiàn)的復(fù)雜性并沒有簡單地消失；相反，大部分的復(fù)雜性都由處理引擎來處理。當(dāng)將來有修改過的或新的規(guī)范時，只有規(guī)范相關(guān)的數(shù)據(jù)需要重新生成以進(jìn)行新的系統(tǒng)設(shè)計。 規(guī)格相關(guān)數(shù)據(jù) StateChart模型中包含的信息可以用兩種數(shù)據(jù)結(jié)構(gòu)表示。StateChart拓?fù)浣Y(jié)構(gòu)和過渡。 拓?fù)浣Y(jié)構(gòu)數(shù)據(jù)結(jié)構(gòu) 圖9展示了一個簡單的StateChart例子及其相應(yīng)的樹狀結(jié)構(gòu)，反映了其拓?fù)浣Y(jié)構(gòu)所定義的層次性和一致性。狀態(tài)和樹的節(jié)點(diǎn)之間的對應(yīng)關(guān)系是一對一的關(guān)系。在樹中，每個狀態(tài)都有它的標(biāo)識符，它是該狀態(tài)的一個數(shù)字ID。同時，每個狀態(tài)都有它的直系子孫、兄弟姐妹和祖先。例如，狀態(tài)B的直系后裔、兄弟姐妹和直系祖先分別是狀態(tài)BA、狀態(tài)C和狀態(tài)A。根據(jù)這個樹狀結(jié)構(gòu)，數(shù)據(jù)結(jié)構(gòu)的定義，描述了StateChart模型的拓?fù)浣Y(jié)構(gòu)，在圖9的模型下面給出。它為每個狀態(tài)存儲了以下信息：它的標(biāo)識符（state），它的直接后代（descendant），它的下一個兄弟姐妹（sibling），它的直接祖先（anjestor），狀態(tài)信息（status）和兩個要調(diào)用的函數(shù)指針。 每當(dāng)進(jìn)入（Entry）或退出（Exit）相應(yīng)的狀態(tài)時。狀態(tài)信息表明相應(yīng)狀態(tài)中定義的歷史條件是否存在，并告訴人們該狀態(tài)是一個并發(fā)狀態(tài)還是一個層次狀態(tài)。 過渡期數(shù)據(jù)結(jié)構(gòu) 同樣地，過渡的數(shù)據(jù)結(jié)構(gòu)定義了一個過渡的所有信息，如圖10所示。它有兩個標(biāo)識符，分別指定為每個過渡的起始狀態(tài)（from）和目標(biāo)狀態(tài)（to），一個觸發(fā)事件標(biāo)識符（event），一個指向函數(shù)的指針，該函數(shù)返回一個表示過渡是否可以發(fā)生的布爾值（guard），一個指向函數(shù)的指針表示與過渡有關(guān)的行動（action）。 處理引擎 基于定義的狀態(tài)圖模型的數(shù)據(jù)結(jié)構(gòu)：拓?fù)浣Y(jié)構(gòu)和過渡，處理引擎也被設(shè)計出來。圖11給出了它的流程圖，它解釋了描述CNC核心的StateChart模型的拓?fù)浣Y(jié)構(gòu)和過渡的數(shù)據(jù)結(jié)構(gòu)。當(dāng)一個事件發(fā)生時，有四個步驟依次完成一個過渡。 1）該事件被發(fā)送到引擎。引擎查找過渡數(shù)據(jù)結(jié)構(gòu)，找出所有可能由事件觸發(fā)的過渡。然后檢查拓?fù)鋽?shù)據(jù)結(jié)構(gòu)中每個狀態(tài)的狀態(tài)，以確定當(dāng)前的活動狀態(tài)，只有活動狀態(tài)才是被觸發(fā)的過渡的起源狀態(tài)。一旦過渡的起源狀態(tài)和活動狀態(tài)相匹配，過渡就被確定了。 2）一旦過渡被確定，原初狀態(tài)就被確定。然而，如果原初狀態(tài)是一個分層的或并發(fā)的超級狀態(tài)，那么從原初狀態(tài)可到達(dá)的活動原子狀態(tài)首先需要被引擎識別為原初狀態(tài)。然后，引擎也可以停用從活動的原子狀態(tài)到最近的共同祖先的路徑上的所有狀態(tài)（不包括后者），以及這個路徑上的所有并發(fā)組件。在停用的過程中，引擎會調(diào)用退出動作函數(shù)。 3) 引擎執(zhí)行與過渡有關(guān)的行動。 4) 從最近的共同祖先到目標(biāo)狀態(tài)的路徑上的所有狀態(tài)以及并發(fā)的組件都被激活。一旦到達(dá)目的狀態(tài)，引擎就會搜索歷史條件，直到最后到達(dá)一個原子狀態(tài)。在激活的過程中，引擎會調(diào)用入口動作函數(shù)。 一旦處理引擎的軟件代碼和規(guī)范的相關(guān)數(shù)據(jù)被編譯，就可以得到一個實現(xiàn)[7]。 結(jié)論 為了進(jìn)行數(shù)控核心的設(shè)計，本文提出了一種MDD方法，以簡化和規(guī)范其設(shè)計流程。按照這種方法，首先使用狀態(tài)圖符號建立數(shù)控系統(tǒng)核心的可執(zhí)行模型。通過使用仿真，對這個Statechart模型進(jìn)行驗證和確認(rèn)，以確保該模型在邏輯上是正確的，并且與規(guī)范的預(yù)期行為一致。同時，建立一個DFD來描述數(shù)控核心內(nèi)的NC程序相關(guān)數(shù)據(jù)處理。在最后的實施階段，經(jīng)過驗證的數(shù)控系統(tǒng)核心的狀態(tài)圖模型被轉(zhuǎn)換為規(guī)范的相關(guān)數(shù)據(jù)，這些數(shù)據(jù)將被集成到一個不變的處理引擎中。之前建立的。有了這種結(jié)構(gòu)，每當(dāng)規(guī)范發(fā)生變化時，要找到軟件代碼進(jìn)行調(diào)試就容易多了?；谶@個解決方案，DFD被實現(xiàn)并嵌入到具體的功能代碼中。已經(jīng)建立了一個原型系統(tǒng)來證明所提出的方法的可行性。未來的工作將包括建立一個更現(xiàn)實的狀態(tài)圖模型，并研究將DFD模型有效地嵌入到實現(xiàn)中的方法。 參考文獻(xiàn) C. G. Cassandras and S. L. Lafortune, (1999), Introduction to Discrete Event Systems, Kluwer Academic Publishers. David Harel, (1987), “StateCharts: A Visual Formalism for Complex Systems”, Science of Computer Programming, No.8, pp.231-274. E. M. Clarke and W. Heinle, (2000), “Modular translation of Statecharts to SMV”, Technical Report, Carnegie-Mellon University School of Computer Science. Diego Latella, et al., (1999), “Automatic verification of a behavioural subset of UML statechart diagrams using the SPIN model- checker”, Formal Aspects of Computing, Vol. 11(6), pp.637–664. B.P. Douglass, (1998), Real Time UML – Developing efficient objects for embedded systems, Massachusetts, Addison- Wesley. E. Gamma, R. Helm, R. Johnson and J. Vlissides, (1995), Design patterns: elements of reusable object-oriented software, Massachusetts: Addison Wesley. M. Samek, P.Montgomery, (2000), “State- oriented programming”, Embedded Systems Programming, Vol.8, 22-43.