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

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