arena中文教程第5章

1、第5章 詳細作業(yè)建模在第四章里展示了用“基本操作”面板里的模塊可以創(chuàng)建的模型種類。這些模塊都是一些相對高層而且容易使用的模塊，但離建立足夠詳細的模型還有很長的距離。有時這些高層模塊對讀者們來說已經(jīng)足夠了。但有時還不行。在建模獲得一些經(jīng)驗、所建模型越來越大、越來越復雜、越來越詳細時，可能會發(fā)現(xiàn)需要對較低層的、更詳細的、或者與“基本操作”面板的模塊所提供的對象不同的事物進行控制或者建模。Arena不會讓你被迫接受這些固定的建模構(gòu)件，也不會強迫你為考慮模型的各個方面而不得不學習一門編程語言或編程語法。相反地，它提供了幾個不同的建模層次，從而為建立一些特殊邏輯結(jié)構(gòu)的模型提供了較大靈活性。一種好的辦法就

2、是從高層模塊開始，它們能走到哪兒你就建到哪兒（可能自始至終就是一層）。當你需要比它們更高的靈活性時，就到更低、更詳細的層次中去。這種結(jié)構(gòu)允許你隨意開發(fā)容易的高層建模結(jié)構(gòu)，也允許你在需要的時候到低層建模。標準的Arena提供了所有這些建模能力，你能熟練掌握它們的用法。這一章探討了一些（當然不是所有）在“高等操作”（Advanced Process）面板和“操作塊”（Block）面板中包含的低層詳細建模構(gòu)件；后一種面板提供了最底層的建模邏輯，其中的模塊與作為Arena基礎(chǔ)的SIMAN仿真語言中的程序塊一致。這里我們采用的例子是一個很復雜的汽車修理與維護車間的模型。我們也會談到一點非平穩(wěn)（時間相關(guān)）

3、到達過程，模型調(diào)試，以及更高層的動畫定制等重要問題。5.1節(jié)中給出了這個系統(tǒng)的描述，5.2節(jié)討論了如何用一些新的Arena建模概念對這個系統(tǒng)建模，5.3節(jié)描述了一些基本的建模策略，5.4節(jié)給出了模型邏輯，5.5節(jié)討論了模型調(diào)試問題，5.6節(jié)給出了一些調(diào)整動畫細節(jié)的方法，以得到一些非標準的效果。在5.7和5.8節(jié)，我們對模型進一步完美化，并提出了幾種新的Arena建模概念。在5.9節(jié)，我們向你展示了如何修改原始模型，以創(chuàng)造出更精美的模型。本章于5.10節(jié)結(jié)束，我們在這一節(jié)中提出了一種完全不同的模型，庫存系統(tǒng)，并借此機會展示了如何使用Arena最底層和最詳細的建模層次，即包含了SIMAN仿真語言的

4、“操作塊”面板。在讀完本章后，你應(yīng)該可以建立非常詳細和復雜的模型，也可以探索出Arena建模的豐富而又深入的層次結(jié)構(gòu)。 模型5-1：汽車維護與修理車間位于某中等城市市區(qū)的大型汽車修理商，由于其維護與修理業(yè)務(wù)增長太快而使得當前的設(shè)施不足，因此決定要擴建其汽車維護與修理車間。由于當前所處的位置的限制，他們考慮在郊區(qū)再建一個有三個修理間的新車間。新建的車間不僅應(yīng)能提供額外的維護與修理能力，而且應(yīng)位于現(xiàn)有多數(shù)顧客的附近。為了能夠?qū)ぷ髁鬟M行更好的控制，由位于市區(qū)的車間對兩個地方的工作進行安排，而且主要的修理工作也將繼續(xù)在市區(qū)車間進行。根據(jù)該計劃，允許顧客最多提前三個工作日在新的郊區(qū)車間打電話提出預約服

5、務(wù)（在預約的當天不提供服務(wù)）。例如，在周三打電話預約的顧客可以在周四、周五或周一得到服務(wù)。如果無法為顧客在給定的后續(xù)三天時間安排服務(wù)的話，他們可以第二天再打一次電話，或者在市區(qū)預約要進行的工作。該汽車修理商具有顧客服務(wù)需求的大量數(shù)據(jù)，對這些數(shù)據(jù)的分析表明，顧客要求服務(wù)的呼入電話平均每天29次，全天都服從（平穩(wěn)的）泊松過程（也就是說，呼入電話的時間間隔獨立、且服從相同的指數(shù)分布）。對數(shù)據(jù)的分析還表明，55%的呼叫者希望在第二天得到服務(wù)，30%希望在第三天；剩下的15%希望在第四天。如果不能安排在其選擇的某一天內(nèi)提供服務(wù)的話，他們有90%的可能性希望安排在之后的一天。大部分顧客（80%）會選擇全天

6、將車輛放在這里，而少數(shù)顧客（20%）愿意一直等到服務(wù)完成。如果顧客選擇等待，他們將會給定一個近似的等待時間。這個等待時間等于預計的完成工作的服務(wù)時間（被稱作預定時間（Book Time）再加上放寬因子（一個小時）。建立這個新車間的目標之一就是使顧客具有很高的滿意度。因此，公司決定每天最多安排5個希望就地等待服務(wù)完成的顧客預約。無論實際服務(wù)時間是多少，該汽車修理商都用一組標準的估計服務(wù)時間（Book Times）來計算服務(wù)成本。各類服務(wù)活動的預定時間可用一個帶有位移和比例因子的-分布來表示（44+90*BETA(2，3)，單位為分鐘，且截斷取整）。實際的服務(wù)時間與預定時間（Book Times）

7、有些不同，它服從伽馬分布GAMM（Book Times/1.05，1.05）。該汽車修理商想使新車間盈利，但不知道每天應(yīng)該安排多少預約服務(wù)，現(xiàn)在的處理是基于每天所能安排的預定時間（Book Time）小時數(shù)的最大數(shù)量來進行的。這個值是基于三個修理間、每間每天可用的服務(wù)時間是8小時來計算的。因為實際服務(wù)時間往往與預定時間有所不同，所以最后確定每天可供安排的時間為24小時。假定每周有五個工作日，每天工作八個小時，每個修理間每小時的成本估計為45美元（包括所有的資本和勞動）。對顧客按預定時間的每小時78美元收費。因為實際服務(wù)時間與預定時間有一定的不同，所以該汽車修理商希望在修理開始的當天完成已安排好

8、的服務(wù)。為了補償服務(wù)時間的差異，每一個修理間每天最多可以加班3個小時。但是，加班的成本是每車間每小時120美元。如果服務(wù)在這個時間內(nèi)無法完成，顧客的車輛就會在修理間放置過夜，服務(wù)在第二天完成。如果發(fā)生此事，那么汽車修理商會為顧客提供一輛替代車，為每輛替代車每天將花費修理商35美元。如果修理商的負荷較大，導致某車在當天的預約服務(wù)不能開始，此時假設(shè)顧客將自己的車開回家，第二天再開過來，因而就不需要替代車輛了。對該系統(tǒng)所關(guān)心的統(tǒng)計量有：每天的利潤，每天的預定時間，每天的實際服務(wù)時間，每天的加班時間，以及每天安排就地等待服務(wù)的顧客中沒能完成的作業(yè)數(shù)量。5.2 新的建模特性從仿真的觀點來看，這個問題與我

9、們在第三章和第四章所研究的非常不同。最明顯的區(qū)別是這個系統(tǒng)是一種服務(wù)性質(zhì)的企業(yè)，而前面的系統(tǒng)是面向制造業(yè)的。雖然SIMAN仿真語言最初的版本（Arena是以該仿真語言為基礎(chǔ)的）是為制造業(yè)的應(yīng)用而開發(fā)的，但是現(xiàn)在Arena的能力也應(yīng)用到了服務(wù)系統(tǒng)的精確建模，包括快餐店、銀行、保險公司、服務(wù)中心和很多其它的企業(yè)。盡管這些系統(tǒng)都有各自的一些特點，但是基本的建模需求很大程度上與制造系統(tǒng)相同?，F(xiàn)在，讓我們看一下汽車車間，然后找出新的需求。隨著工作的繼續(xù)進行，會發(fā)現(xiàn)我們已有的建模結(jié)構(gòu)還不足以完成如此詳細的系統(tǒng)建模。5.2.1 多路徑?jīng)Q策進行服務(wù)預約時，將它安排到合適的工作日，然后等待這一天的到來。為此，根

10、據(jù)預約日的要求，我們需要將實體或預約送到該模型的五個不同的部分。雖然我們可以通過用一系列的“決策”模塊（Decide）實現(xiàn)它，但是模型會變得難看而且也沒有必要。你也許仍然還不太清楚，其實在第四章前三個模型里用到的Decide模塊中可以含有三個或者更多的分支。5.2.2 集合隨著模型越來越復雜，經(jīng)常會發(fā)現(xiàn)需要模擬實體到達一個位置或站時，需要從幾個相似（但是不完全等同）對象中選擇一個。最常見的情況是從一組資源中選擇可用的資源。假設(shè)有三個操作員：Shelley、Lynn和Charity。他們中的任何一個都可以完成需要的任務(wù)，這時，只要他們當前都是空閑的，則可以選擇這三個中的任何一個?！凹稀蹦K（S

11、et）為實現(xiàn)這種功能性提供了基礎(chǔ)。Arena的集合包含了一組相似對象，這些對象可以通過集合名稱和相應(yīng)的下標來引用。這些對象構(gòu)成了集合，每個對象是集合的一個成員。特定集合的成員都必須是同種類型的對象，例如資源、隊列、圖形等等。根據(jù)建模需要，可以將幾乎任何一種Arena的對象收集到一個集合之內(nèi)。一個對象也可以出現(xiàn)在一個以上的集合之內(nèi)。例如在操作員集合（Operators）中包括了Lynn，但她又能作為一個調(diào)整人員，因此，可能會定義一個被稱為“調(diào)整”（Setup）的資源集合，其中包括Lynn和Doug（Doug不是一個操作員）。現(xiàn)在，如果需要一個操作員，就從名為Operators的集合中選取，如果需

12、要調(diào)整人員，就從名為Setup的集合中選取。因為Lynn是同屬于兩個集合中的一個成員，所以可能會在任何一個情景下選擇她。用戶可以按需要任意選擇集合的數(shù)目或集合間是否有重疊。對修理中心來說，我們用集合來建立修理間模型、描述實體圖形和預約隊列。5.2.3 變量與表達式在很多模型中，可能會在多個不同的地方重復使用數(shù)據(jù)。例如，在一個模型中有幾個地方可能需要生成來自相同分布的服務(wù)時間，并將它們輸入到需要的模塊中去。但是如果要在實驗中更改這個分布的參數(shù)（或者分布本身），就必須打開每一個包括該服務(wù)時間的對話框來改變參數(shù)值。有時，我們可能需要跟蹤系統(tǒng)中實體總數(shù)變化的情形。還有的時候，我們可能在整個模型中需要使

13、用很復雜的表達式，例如，可能根據(jù)零件類型來確定加工時間。Arena的“變量”（Variable）和“表達式”（Expression）模塊可以容易地實現(xiàn)這幾種要求?！白兞俊蹦K（Variable）允許用戶定義自己的全局變量并賦初始值，而且還可以按照它們的名稱加以引用。它們也可以被指定為一維或二維的數(shù)組?！氨磉_式”模塊（Expression） 允許用戶定義各類表達式和它們所關(guān)聯(lián)的值。與變量相似，表達式也可以在模型中以它們的名稱引用，可以被指定為一維或二維的數(shù)組。雖然變量和表達式看起來很相似，但是它們具有不同的功能。用戶定義的變量可以存儲一些能夠在仿真運行期間重新賦值的量。例如，我們可以定義一個叫做

14、Wait Time的變量（用以表示等待時間），其初始值為2，在需要使用該量的地方輸入變量名即可。我們也可以定義一個叫做Number in System的變量（用以表示系統(tǒng)中的零件數(shù)），其初始值為0。每次新零件進入這個系統(tǒng)，就在這個變量上加1；每次一個零件退出系統(tǒng)就減1。對汽車車間來說，我們用一個名位Day的變量來跟蹤這一周的當前日。我們還會用很多變量來控制如何獲得預約，如何在運行結(jié)束時收集用于計算統(tǒng)計量的信息。與此不同，用戶定義的表達式不能存儲數(shù)值，而是提供了一種將某個名稱和特定的數(shù)學表達式關(guān)聯(lián)起來的方式。當名稱在模型中被引用時，相關(guān)的表達式就會被計算出來，并返回其數(shù)值。例如，表達式可被用來計

15、算一些分布或復雜等式的值，而計算公式中又包含了實體的屬性值或者系統(tǒng)變量值的當前值。如果在模型中數(shù)學表達式只用在一個位置，將它輸入到相應(yīng)的位置可能會更容易。但是，如果表達式被用在幾個位置或者要用的表達式的形式依賴于實體的屬性，那么用戶定義表達式通常會更好。對汽車車間來說，我們會用Expression模塊（在“高等操作”面板中）來定義所生成的預定時間、實際服務(wù)時間和預定需求的類型（等待還是離開）這些表達式。變量和表達式有很多其它的用處，隨著你們對Arena的進一步熟悉，這一點會越來越明顯。5.2.4 子模型在開發(fā)龐大而復雜的模型時，通常將模型分割成小的模型是有好處的，這種小的模型被稱為原模型的子模

16、型（submodels），它們之間可能互相有交互，也可能沒有。這會為建模與測試過程提供便利。例如，我們可以將汽車車間模型分割成五個明顯的（我們認為它們很明顯）子模型：生成預約呼叫、進行預約、服務(wù)活動、更新性能變量和控制邏輯。Arena以子模型的形式提供了這種分解能力。這種特點允許將模型分成不同層次的視圖，也即子模型，每一個都在屏幕上有自己完整的工作空間。你既可以一次觀看一個子模型，也可以觀看模型全景（也即頂層 (Top-Level) 模型）。每一個子模型都可以包括常規(guī)的模型窗口（例如“電子數(shù)據(jù)表格”模塊、靜態(tài)圖形和動畫元素）所支持的各種對象。子模型本身也可以包括更低層的子模型；可以無限地嵌套下

17、去。子模型可以連接到其它的模塊中去，也連接到其它的子模型中去，或者孤立地處于一個Arena模型中。在頂層模型視圖和每一個子模型視圖中，為了在邏輯區(qū)和動畫區(qū)的不同區(qū)域中提供容易的導航，可以建立帶有相關(guān)熱鍵的“命名視圖”。工程工具欄的“導航”面板（Navigate）可顯示出列有頂層模型、所有的子模型、以及它們所以命名視圖的樹狀結(jié)構(gòu)。點擊一個命名視圖的或子模型視圖即可顯示該模型所在的區(qū)域，這使得在視圖內(nèi)和視圖間的導航變得非常容易。雖然以上汽車車間模型還不像很多實際模型那么大，也沒有那么復雜，但是我們?nèi)匀挥米幽Ｐ蛠斫M織流程，并闡明概念。5.2.5 實體副本在開始更復雜的建模時，通常會發(fā)現(xiàn)創(chuàng)建“實體復本

18、”的必要性。這些實體通常被用作控制實體，可以完成許多功能。這種用法的一個很好的例子將在9.3節(jié)介紹，在那里會講到實體的受阻離開和中途退出等現(xiàn)象。也有的時候需要在模型的某處將一批實體集合成一個實體（也即將零件裝盤），然后在模型的另一處再將成批實體分成單個。本書將在9.4節(jié)加以說明。在汽車車間模型里，我們需要創(chuàng)建實體副本，讓它代表要求預約的來電?？墒褂谩盎静僮鳌泵姘逯械摹胺蛛x”模塊（Separate）來創(chuàng)建或克隆實體的副本。 5.2.6 保持實體模型中有時需要將實體保持在某個位置，直到系統(tǒng)允許這些實體行進的特定情況發(fā)生為止。我們已經(jīng)看到其中的一種形式 實體在排隊等待資源空閑。但在此我們考慮更一般

19、的情況，實體被保持的位置是由模型中其它地方的活動所決定的，如系統(tǒng)時間或系統(tǒng)條件。Arena提供了兩種不同的保持實體的方法。第一種方法是實體被保持到由另一個實體發(fā)出行進信號為止；第二種方法是實體被保持到某些系統(tǒng)條件出現(xiàn)為止。在汽車車間模型中我們將采用第一種方法，可通過使用“保持”模塊（Hold）和“信號”模塊（Signal）來實現(xiàn)，也即將顧客的預約一直保持到安排對他進行服務(wù)的那一天為止。第二種方法將在9.4節(jié)介紹。5.2.7 統(tǒng)計量和動畫我們需要的統(tǒng)計量也是比較平常的，與前面模型中收集到的沒有很大不同。但是，系統(tǒng)的類型和分析需求卻截然不同。先看一下分析需求。在分析服務(wù)系統(tǒng)時常見的目標是利潤最大化

20、或顧客滿意度最大化，還有成本最小化（當然，從極端意義上講，它們是相互矛盾的目標）。該汽車修理車間顧客滿意度的關(guān)鍵測度的是在所承諾的完成服務(wù)時間以外的等待服務(wù)的顧客數(shù)。很明顯，我們的目標就是使其最小化。影響這些測度的關(guān)鍵因素是各天所安排的等待服務(wù)的最大顧客數(shù)。創(chuàng)建模型后，我們可以很容易地增加或減小這個數(shù)，并確定其對性能指標的影響。我們需要認真考慮仿真要運行多長時間，以及所要建立的系統(tǒng)的類型。下一節(jié)會涉及到這些。分析和提高利潤是一個更加困難的問題。預約是基于Book Time的，而各天所需要的實際服務(wù)時間可能有很大的不同。因此，我們?nèi)绻胍刂颇Ｐ妥兞恳蕴岣呃麧?，那么就需要知道改變這些變量所造成的

21、影響。通常的仿真輸出總結(jié)報告是不會直接給出這個信息的。但是我們可以通過增加一些統(tǒng)計量來收集和提供所需信息，這不難做到。查看動畫運行應(yīng)該是很有幫助的，就像在觀測實際系統(tǒng)一樣。遺憾的是，與以前的模型不同，一般很難為這種系統(tǒng)加上動畫效果以使其展示出系統(tǒng)運行狀況。我們可以用動畫模擬預約的隊列和資源，但是相應(yīng)的動畫卻是非常跳躍的，而且也不能提供我們所需要的時間方面的信息。雖然經(jīng)常也觀看這類系統(tǒng)的動畫，但是這些動畫一般都是用來“展示”而不是進行分析的。不過既然已經(jīng)提及，我們還是會在5.6節(jié)介紹如何給這種模型加上動畫的。5.2.8 終態(tài)仿真和穩(wěn)態(tài)仿真大部分（盡管不是所有的）仿真可以被分為終態(tài)仿真和穩(wěn)態(tài)仿真兩

22、大類。這主要是仿真研究的意圖或目的方面的問題，與模型內(nèi)部的邏輯或架構(gòu)沒有多大關(guān)系。終態(tài)仿真（terminating simulation）是模型規(guī)定了特定的開始和結(jié)束條件的仿真，這些條件是對實際系統(tǒng)需求的真實反映。正如它的名字所體現(xiàn)的，仿真會按照模型規(guī)定的特定規(guī)則或條件終止運行。例如，一個商店在上午9點開門，開門時店內(nèi)沒有顧客；在晚上9點關(guān)門，并繼續(xù)服務(wù)到所有的顧客都離開。再看一個加工車間的例子，它則運行到生產(chǎn)出訂單所規(guī)定的500個裝配件為止。這一類型的關(guān)鍵是仿真有一個明確定義的（雖然在開始時可能是未知的）、自然的結(jié)束的時間，也有一個明確定義的啟動方式。與終態(tài)仿真不同，穩(wěn)態(tài)仿真（steady-

23、state simulation）則是通過長時間仿真運行來對某些性能指標加以估計的仿真形式；也就是說，理論上的仿真時間應(yīng)該是無窮大。在原理上，這種仿真的初始條件是無關(guān)緊要的（雖然通常在實際中不是這樣）。當然，穩(wěn)態(tài)仿真也必須在某一個時間點停止，不過正如所想象的那樣，仿真會運行很長時間，因此需要設(shè)法保證它運行的時間足夠長。我們將在7.2節(jié)討論這個問題。有關(guān)穩(wěn)態(tài)仿真的例子也很多，例如一個兒科急診室在實際中永遠不會停止或重新開始，因此穩(wěn)態(tài)仿真對此會很合適。有時候某些系統(tǒng)在實際中會有終止狀態(tài)，但為了設(shè)計其某種最壞的或者負荷最大的情況，仍可以采用穩(wěn)態(tài)仿真模式進行?，F(xiàn)在為汽車修理車間模型選擇應(yīng)該用哪種仿真形

24、式。雖然根據(jù)定義能看出終態(tài)系統(tǒng)和非終態(tài)系統(tǒng)的差別很明顯，但在實際很少如此。一些系統(tǒng)剛開始時采用一種類型，但是更進一步檢驗后卻發(fā)現(xiàn)它們實際上屬于另外一種。再加上有些系統(tǒng)同時包括兩種類型的因素，這就使得這一更加復雜了，此時往往依據(jù)分析人員所處理的問題的類型來確定仿真的分類。例如，考慮一個在上午11點開門，晚上11點關(guān)門的快餐店。如果對該快餐店的日常運作問題感興趣，就可用非平穩(wěn)泊松到達過程，并將系統(tǒng)看成是終態(tài)仿真進行分析。如果只對發(fā)生在午飯前后兩個小時內(nèi)的高峰期的運作感興趣，則可以假設(shè)系統(tǒng)是一個以峰值到達率到達的平穩(wěn)過程，并可將這個系統(tǒng)作為穩(wěn)態(tài)系統(tǒng)進行分析。乍一看，汽車修理車間很像是一個終態(tài)系統(tǒng)，這

25、個系統(tǒng)似乎可以以空閑狀態(tài)開始和終止。但也有可能某天不能完成所有的工作（記住我們只允許三個小時的加班）。需要在車間放過夜的車輛會對第二天的初始條件有很大影響，因此我們可以將系統(tǒng)考慮成穩(wěn)態(tài)的。假如情況并非如此，我們將會繼續(xù)在第六章將汽車車間問題作為終態(tài)系統(tǒng)進行分析。5.3 建模方法在第一章的圖1-2中，簡要討論了Arena的層次結(jié)構(gòu)。這種結(jié)構(gòu)允許將任何層次的建模構(gòu)建組合在一個仿真模型中。在第三章和第四章中，我們基本上都是利用“基本操作”面板中的構(gòu)件來開發(fā)我們的模型，盡管在處理故障或其它特殊統(tǒng)計量時確實也用到了幾種在“高等操作”面板里的數(shù)據(jù)模塊。 在創(chuàng)建模型時，我們推薦一般情況下要盡可能維持在最高的

26、層次上構(gòu)建模型。但是，當發(fā)現(xiàn)這些高層構(gòu)件已無法描述必要的細節(jié)時，你就應(yīng)該將模型的某些部分移到下一層，而不能犧牲仿真模型的準確性。你可以將不同層次和面板中的的建模構(gòu)件同一個模型中混合使用。隨著對各種面板（和建模層次）的進一步熟悉，你會發(fā)現(xiàn)自己能夠很自然地這么做。在繼續(xù)建模工作進行之前，先簡要討論一下可用的面板。“基本操作”面板（Basic Process）提供了最高層環(huán)境。使用該面板可以既迅速又容易地創(chuàng)建大部分系統(tǒng)的高層模型?！皠?chuàng)建”模塊（Create）、“操作”模塊（Process）、“決策”模塊（Decide）、“賦值”模塊（Assign）、“記錄”模塊（Record）、“分批”模塊（Bat

27、ch）、“分離”模塊（Separate）和“清除”模塊（Dispose）的綜合運用可具有很大的靈活性。實際上，如果研究一下這些模塊，就會發(fā)現(xiàn)有很多其他的特點我們還沒有探討。在很多情況下，僅單獨使用這些模塊就能提供仿真項目需要的所有細節(jié)。因為這些模塊提供了幾乎所有模型都需要用到的常見功能，因此不管所希望的建模細節(jié)處于哪一層，你都有可能用到以上模塊?！案叩炔僮鳌泵姘澹ˋdvanced Process）提供了其他一些更詳細的建模能力，補充了“基本操作”面板的功能。例如，“占用-延時-釋放”模塊（Seize-Delay-Release ）的組合就提供了與Process模塊基本相同的建模邏輯?！案叩炔僮?/p>

28、”面板中的模塊的一個有用特點就是你可以將它們放在模型中幾乎所需要的任意組合體中。實際上，很多有經(jīng)驗的建模人員都是從這一層開始，因為他們感覺由此建立的模型對用戶來說會更明晰?！案叩冗\送”面板（Advanced Transfer）提供用于物料搬運活動方面的構(gòu)件（如運送設(shè)備和傳送設(shè)備）。與“高等操作”面板提供的一般的建模能力相似，“高等運送”面板中的模塊在為物料搬運系統(tǒng)建模時也具有很高的靈活性?！安僮鲏K”面板（Blocks）提供了更低層次的建模能力。實際上，它提供了用來創(chuàng)建“基本操作”面板、“高等操作”面板和“高等運送”面板中所有模塊的基本功能。另外，它還提供了很多在高層模塊中不能實現(xiàn)的其它特殊用途

29、的建模構(gòu)件。如“while”循環(huán)、概率和邏輯組合分支、以及自動搜索等特征。你可能注意到其中的幾個模塊與那三個高層面板中的模塊有相同的名稱。盡管名稱一樣，但模塊卻是不同的，能夠通過顏色和形狀來區(qū)分這兩種模塊。如果你以前用過SIMAN仿真語言，并在其中分別定義過模型文件和實驗框架（即使在Arena中你也可以這么定義），那么“操作塊”面板和“基本操作”面板、“高等操作”面板以及“高等運送”面板之間的差別就很容易解釋了。這些差別最好通過兩類面板中的Assign模塊來闡明。在使用“基本操作”面板的Assign模塊時，你可以隨意選擇合適的賦值類型。如果給一個新的屬性賦值，Arena會自動定義這個新的屬性并

30、將它加入到模型各處的“屬性下拉列表”中。盡量在最高層建模的一個原因就是“操作塊”面板中的模塊沒有這么方便，其中的Assign模塊只能完成簡單的賦值，不能定義新的屬性。雖然有這樣的缺點，但在“操作塊”面板中的模塊仍具有一些其它面板所不具備的強有力的特征。 另外，“構(gòu)模元素”面板（Elements）中也有實驗框架方面的模塊。例如，在這里可以利用Attributes模塊定義新屬性。由于建模時可與更高層次面板中的模塊相混合使用，所以實際中很少需要這些功能。但是如果某些特殊問題需要建立一個最低層的模型（如使用Visual Basic、C、和FORTRAN等程序設(shè)計語言的功能），則也可通過Arena接口加

31、以調(diào)用?！安僮鲏K”面板和“構(gòu)模元素”面板也提供了為連續(xù)系統(tǒng)建模而設(shè)計的模塊，這些內(nèi)容將在第11章介紹?，F(xiàn)在讓我們返回到汽車維修車間模型中，該模型確實要用到“基本操作”面板中的模塊所不具備的特點。在開發(fā)模型時，我們會同時用到“基本操作”面板和“高等操作”面板中的模塊（在本章的結(jié)尾，會用“操作塊”面板和“構(gòu)模元素”面板開發(fā)一個庫存模型）。在一些情況下，確實需要用到較低層的構(gòu)件；而在其它情況下，就只是展示一下它們的特性。在創(chuàng)建含有低層構(gòu)件的模型時，開發(fā)模型的方式會稍有不同。 如果僅有較高層的構(gòu)件，一般可對活動進行分組，然后再使用適當?shù)哪K加以建模。而如果含有較低層的構(gòu)件，就需要對實際活動有細致的描述

32、。從某種意義上說，你的模型要能成為刻畫這些活動的詳細的流程圖。不過要做到這一點并不容易，除非你對各種模塊的邏輯非常熟悉。5.4 建模在此，我們把模型分成幾個部分，分別直接對各個部分進行開發(fā)，同時介紹各部分的功能。以下按順序分別介紹七個部分： 5.4.1節(jié)：定義數(shù)據(jù)， 5.4.2節(jié)：創(chuàng)建子模型， 5.4.3節(jié)：生成預約呼叫， 5.4.4節(jié)：進行預約， 5.4.5節(jié)：服務(wù)活動， 5.4.6節(jié)：更新性能指標變量， 5.4.7節(jié)：控制邏輯。 數(shù)據(jù)一節(jié)包括建模所需要的數(shù)據(jù)模塊，接下來一節(jié)會說明如何創(chuàng)建子模型，剩下的五部分每一個都將作為子模型加以開發(fā)。最后得出的頂層模型窗口外觀上類似于圖5-1。因為以后才

33、給模型加上動畫，所以我們這里先刪除包含在模塊中的所有動畫對象。 P186 圖5-1 模型5-1：汽車維修車間模型的頂層模型視圖當讀完下面有關(guān)建模的七個部分后，你可能能感覺到，這是開發(fā)一個模型所遵循的基本步驟。理想情況下，人們總希望能夠先對模型的結(jié)構(gòu)有一個比較好的規(guī)劃，以使其比較容易建立。但是在實際中，你會常常返回到先前完成的部分，不斷對模塊或數(shù)據(jù)加以增、刪、及修改。因此在開發(fā)復雜模型時，一定不要指望能一次就成功（我們當然也不會）。5.4.1 定義數(shù)據(jù)讓我們從RunSetup菜單對話框開始。在Project Parameters表頁中的Project Title欄內(nèi)輸入項目名稱。在Replica

34、tion Parameters表頁中，我們隨便設(shè)定為重復仿真運行10次，每次仿真20天。因為希望輸出報告中的單位是小時，所以這里選擇Hours作為基準時間單位（Base Time Unit）。由于實際系統(tǒng)開始時都是空的（除非有車輛放過夜，以及在隨后3天有預約）， 因此可令預備運行時間的長度（Warm-up Period）為0。因為設(shè)定了多次重復仿真運行，所以需要告訴Arena在相鄰兩次重復仿真運行之間要做什么。有四種可能的選項。選項1：初始化系統(tǒng)（是），初始化統(tǒng)計量（是） 這會進行10次統(tǒng)計上獨立而且相同的重復仿真運行并生成相應(yīng)的報告，每一次都是在時間0時開始且系統(tǒng)初始狀態(tài)為空，每一次都運行2

35、40個小時。隨機數(shù)發(fā)生器（見12.1節(jié)）在重復仿真運行之間連續(xù)產(chǎn)生獨立同分布的（IID）隨機數(shù)。在前一次仿真結(jié)束時可能需要放過夜的車輛在下一次重復仿真開始時將不被保留。選項2：初始化系統(tǒng)（是），初始化統(tǒng)計量（否）這會進行10次獨立重復仿真運行，每一次都在時間為0時開始且系統(tǒng)初始狀態(tài)為空，每一次都運行240個小時，但輸出報告中的統(tǒng)計結(jié)果是各次累積的。因此，報告2會包括前兩次重復仿真運行的統(tǒng)計結(jié)果，報告3會包括前三次重復仿真運行的統(tǒng)計結(jié)果等等。這里的隨機數(shù)發(fā)生器的運行也象在選項1中一樣。選項3：初始化系統(tǒng)（否），初始化統(tǒng)計量（是）這會進行10次仿真運行，第一次從時間0開始，第二次從240開始，第三

36、次從480開始等等。因為系統(tǒng)在多次重復仿真運行之間沒有進行初始化，所以時間會連續(xù)增加，任何放過夜的車輛都會被帶到下一次重復仿真運行中。報告只包括單獨一次重復仿真運行的統(tǒng)計量，而不是多次累積的結(jié)果。選項4：初始化系統(tǒng)（否），初始化統(tǒng)計量（否）這樣也會進行10次仿真運行，第一次從時間為0開始，第二次從240開始，第三次是從480開始等等。因為系統(tǒng)在多次重復仿真運行之間沒有初始化，所以時間將連續(xù)增加，任何放過夜的車輛都會被帶到下一次重復仿真運行中。但這時輸出報告中的結(jié)果是累積的。第10次報告的結(jié)果將與做一次時間為2400個小時的單次仿真運行是一樣的。理想情況下，我們不希望有很多車輛在修理間過夜，因而

37、希望采用獨立的重復仿真運行模式。這意味著要么選擇選項1，要么選擇選項2。此處將選擇選項1（有關(guān)的詳細情況見第6章）。本例共有三項資源（三個修理間）。所有這三項資源都是可變?nèi)萘康模ㄔ?.2節(jié)已作過討論）。我們可以為每一種資源單獨定義一個容量調(diào)度；但是由于它們的容量調(diào)度形式是一樣的，所以可以簡單地重復使用單個調(diào)度（盡管這么做會使你的模型在將來可能產(chǎn)生變化時減少了靈活性）。在建立這種容量調(diào)度時，可使用圖示調(diào)度編輯器（Graphical Schedule Editor），在Options對話框中將time slots的個數(shù)設(shè)定為12，將圖中y軸的maximum capacity設(shè)定為2（我們實際上可以

38、設(shè)定它為1）。容量調(diào)度如圖5-2所示。你可能注意到，該容量調(diào)度要求這3個修理間每天有11小時可用，每天工作8小時，再加上可能有3個小時的加班。資源在每天的第一個小時都不能用，因為要用這一個小時來調(diào)度未來的預約，并允許當天的顧客在這個時候到達。下一步就是定義資源。我們?yōu)槿萘空{(diào)度類型選擇“優(yōu)先搶占”（Preempt）選項，因為車輛在標準的8小時工作和允許的3小時加班后有可能仍未完成服務(wù)。在這種情況下，將停止對該車輛上的工作，并選擇在第二天完成該項工作。最后的電子數(shù)據(jù)表格視圖如圖5-3所示。P188圖5-2 圖示調(diào)度編輯器：修理間容量調(diào)度定義完資源以后，就可以用“基本操作”面板中的“集合”模塊（Se

39、t）來定義集合了。利用Set模塊可以定義資源集合、計數(shù)器集合、計數(shù)型統(tǒng)計量集合、實體類型集合以及實體圖形集合，也可以利用“高等操作”面板中的“高等集合” 數(shù)據(jù)模塊（Advanced Set）來定義其它的Arena對象集合。點擊Set模塊，然后在電子數(shù)據(jù)表格視圖中雙擊相應(yīng)位置以添加一個新的條目，這樣就可以定義一個集合。我們會帶你詳細了解創(chuàng)建該集合的細節(jié)。在Name單元格中輸入Bays，從Type單元格的下拉列表中選擇Resource。接下來定義集合中的成員，點擊Member欄的“0 Rows”按鈕，打開包含所定義的各項資源的電子數(shù)據(jù)表格，然后雙擊相應(yīng)位置打開一個新的空行。因為已經(jīng)定義了資源，所以

40、可以用下拉列表中選擇每個成員的資源名稱。已完成的Bays集合成員的電子數(shù)據(jù)表格視圖如圖5-4所示。P188圖5-3 資源電子數(shù)據(jù)表格窗口P189圖5-4 Bays集合成員的電子數(shù)據(jù)表格窗口下面定義兩個實體圖形的集合，Customer（顧客）和Vehicles（車輛）。每一個集合都有兩個成員，分別表示在等待的顧客和將車輛留下來的顧客。已完成的Set數(shù)據(jù)模塊如圖5-5所示。P189圖5-5 Set模塊的電子數(shù)據(jù)表格窗口我們還需要創(chuàng)建一個隊列集合以存放將來的預約。首先，需要用“基本操作”面板中的“隊列”模塊（Queue）定義五個隊列（周一預約隊列到周五預約隊列）。然后，利用“高等操作”面板中的Adv

41、anced Set模塊來定義隊列集合。在Name單元格中輸入Appointment Queues，從Type單元格的下拉式列表中選擇Queue。然后在電子數(shù)據(jù)表格中輸入五個隊列成員的名稱，類似于前面的資源集合。該集合的五個成員如圖5-6所示。P189圖5-6 高等集合模塊成員的電子數(shù)據(jù)表格窗口下一步，用“基本操作”面板中的“變量” 數(shù)據(jù)模塊（Variable）來定義變量。應(yīng)該指出的是我們沒有必要一定利用這個模塊定義變量。當你在所需的某處（例如Assign模塊）定義一個新變量時，Arena會將這個新變量的信息自動輸入到Variable數(shù)據(jù)模塊中。但是，如果需要定義數(shù)組變量或所定義變量的初始值不為

42、零，那么就必須要使用這個模塊來設(shè)定所需要的數(shù)組大小或變量初始值。本例將總共定義15個變量。前六個變量是用來控制模型的：保存當前日期的變量（Day），令其初值為4（后面再詳加敘述）；用來保存當天預約作業(yè)的預定時間（Book Time）當前值的數(shù)組變量（Day Load）；預定時間小時數(shù)的最大值（Max Load），令其初值為24；等待服務(wù)完成的顧客數(shù)的最大允許值（Max Wait），令其初值為5；用來保存當天等待作業(yè)數(shù)的當前值的數(shù)組變量（Wait Load）；以及每天打入電話要求預約的平均顧客數(shù)（Calls Per Day），令其初值為25。下面三個變量（以及最后兩個變量）將在仿真運行結(jié)束時用來

43、計算累積輸出值：到現(xiàn)在為止完成的預定時間小時數(shù)的總數(shù)（Day Book Time）；到現(xiàn)在為止完成的實際服務(wù)時間小時數(shù)的總數(shù)（Day Actual Time）；到現(xiàn)在為止完成的加班時間小時數(shù)的總數(shù)（Day Overtime）；當前在修理間存放過夜的車輛的存放總天數(shù)（Total OT）；被延期的等待作業(yè)的當前數(shù)量（Day Wait Late）。中間的四個變量將被用于控制邏輯：仿真中當前工作日的序號（Work Day）；當日的工作開始時間（Day Start Time）；當日的正常工作（不包括加班）結(jié)束時間（Day End Time）；用來決定等待作業(yè)是否被延期的寬放量（Wait Allowanc

44、e），令其初值為1。最后的電子數(shù)據(jù)表格視圖如圖5-7所示。P190圖5-7 變量定義的電子數(shù)據(jù)表格窗口我們還需利用 “高等操作”面板中的“表達式” 數(shù)據(jù)模塊（Expression）來輸入模型所需的幾個表達式，包括用于確定每個呼入顧客的預定時間的表達式，用于確定顧客是否想要等待自己的車輛的表達式，以及確定實際服務(wù)時間的表達式。這樣就可以很容易地根據(jù)需要將這些分布直接輸入到模型中去。從上一段討論的第一個表達式開始。打開Expression模塊，在Name單元格為第一個表達式輸入名稱Book Time Expression，然后在Expression Values單元格輸入AINT (44+90*

45、BETA (2,3) ) /60?？梢院唵蔚貙⑸鲜接面I盤敲入，或者用“表達式構(gòu)造器”為其輸入。因為大部分汽車修理車間的預定時間都是以整數(shù)分鐘表示的，所以我們用Arena中的表達式AINT截去小數(shù)部分，返回一個不大于且緊鄰該數(shù)的整數(shù)（AINT函數(shù)是Arena的很多內(nèi)置數(shù)學函數(shù)之一，這些函數(shù)完整的清單可以在幫助菜單中的“數(shù)學表達式”（Mathematical Expressions）主題下找到）。注意，我們將結(jié)果除以60，以把時間轉(zhuǎn)化為小時。第二個表達式（Wait Priority Expression）用來決定顧客是否會一直等到其服務(wù)完成。其表達式為DISC（0.20,1,1.0,2），它將會以

46、0.2的概率返回1，以0.8的概率返回2。在這種情況下，1就意味著顧客會等到服務(wù)完成。最后一個表達式與前面的表達式有關(guān)，因為它需要用到第一個表達式得出的值。在生成預定時間時，將它存儲在一個叫做Book Time的實體屬性中。隨后將把Book Time屬性值帶入表達式Actual Service Time，用于生成實際服務(wù)時間，其表達式為GAMM（Book Time/1.05, 1.05）。最終的數(shù)據(jù)項需要“高等操作”面板中的“統(tǒng)計”模塊（Statistic）。其中所有的條目都是輸出類型的（Output Type），這就意味著這些值只能在每次重復仿真運行結(jié)束時求取。前面三個條目以小時為單位計算每

47、天服務(wù)所需的平均預定時間、平均實際服務(wù)時間和平均加班時間。利用前面定義的變量就可以計算這些值。第四個表達式是求取平均每天被延期的等待作業(yè)數(shù)量。最后一個統(tǒng)計量由三項組成，用于計算平均每天的利潤。第一項（Day Book Time / Work Day）*78，表示根據(jù)預定時間按每小時收費78美元計算的已完工工作的收入。第二項（Day Overtime / Work Day）*120，表示因加班而導致的成本。最后一項的前半部分（Total OT / Work Day）*35是由于需要為沒能在預定時間內(nèi)完成服務(wù)的顧客提供替代車輛而造成的損失，第二部分24*45是資金和人力成本。這些表達式可以直接輸入

48、，也可以用“表達式構(gòu)造器”輸入。最終的電子數(shù)據(jù)表格視圖如圖5-8所示。P192圖5-8 Statistic模塊電子數(shù)據(jù)表格窗口以上完成了所需的數(shù)據(jù)定義工作，現(xiàn)在可以建立模型邏輯了。5.4.2 創(chuàng)建子模型通過選擇菜單ObjectsSubmodelAdd Submodel可創(chuàng)建子模型。此時鼠標指針將會變成十字形，將它移到你想放置子模型的那個模型窗口中，點擊一下就可將其放好，如圖5-9所示。這個子模型對象的名字是Submodel跟著1個數(shù)字，該數(shù)字隨著子模型的添加而遞增。若要將子模型對象的名字按自己的要求定義，則鼠標右擊該子模型，選擇Properties項打開子模型屬性窗口，如輸入界面5-1所示。我

49、們將第一個子模型命名為Generate Appointment Calls（生成預約呼叫）。新的子模型默認有一個進入點和一個離開點。對第一個子模型來說，將進入點數(shù)量改為0，因為這個特殊的子模型僅被用來利用Create模塊為模型的其它部分生成呼叫?？梢栽贒escription欄輸入對子模型的一些描述，不過由于這個模型很簡單，僅用名字就描述得足夠清楚了，所以此處就不輸入更多的描述了。按照以上過程創(chuàng)建剩下的四個子模型，使得最后的視圖看起來如圖5-1所示。在創(chuàng)建過程中，你可能需要注意該圖中每一個子模型進入點和離開點的個數(shù)。一旦將所有子模型放在合適的位置，并賦予它們正確的屬性，就可以開始構(gòu)造模型邏輯了。

50、若要打開子模型并添加或編輯模型邏輯，只需要雙擊子模型或者用“工程欄”中的的“導航”（Navigate）面板在子模型和頂層模型之間來回切換即可，如圖5-10所示。若要關(guān)閉子模型窗口，你可以用Navigate切換，或在子模型窗口中的空白處右擊鼠標，并選擇Close Submodel即可?，F(xiàn)在我們已經(jīng)可以建立實際模型了。P192圖5-9 新建的子模型P193輸入界面5-1 子模型屬性窗口5.4.3 生成預約呼叫這個子模型會生成每天的預約呼叫，并將它們傳送到下一個預約處理的子模型。除了第一天以外，邏輯過程都是非常直觀的。在子模型中將生成單個的實體（每12個小時一個），確定當天呼叫的次數(shù)，變量Day遞增

51、，創(chuàng)建足夠多的實體副本使當天的離開實體數(shù)量等于呼叫的數(shù)量，最后為每一個離開的實體賦必要的屬性值?；貞浺幌?，顧客只允許預約未來三個工作日中的某一天。因為我們假定沒有預備仿真時間（Warm Up），所以我們應(yīng)當認為在第一天仿真開始時已經(jīng)有預約了。因此我們首先需要檢查一下是否處在第一天。如果是的話，就創(chuàng)建三個實體副本當作將要處理的預約。因為Day變量初值為4（周四），所以它將被遞增到5（周五），并且初始時相當于包含了三天的顧客預約呼叫（周一、周二或周三）。接下來會將變量Day重置為周一，并讓初始實體生成預約呼叫。P193圖5-10 Navigate面板生成預約呼叫、并為變量和屬性賦值的模塊如圖5-1

52、1所示。我們已經(jīng)使用過這些模塊類型中的大部分，其中兩個新的模塊，“延時”模塊（Delay）和“分離”模塊（Separate），分別來自“高等操作”面板和“基本操作”面板。P194圖5-11 生成預約呼叫該子模型的邏輯過程可以總結(jié)如下：p194（程序代碼）第一個模塊是Create，用以在每天的開始時創(chuàng)建實體，如輸入界面5-2所示。在Name和Entity Type欄輸入相應(yīng)的名稱和實體類型，常數(shù)12小時表示的到達間隔時間（每天的仿真時間長度），以及第一次創(chuàng)建實體的時間（第0.01小時）。剩余數(shù)據(jù)接受默認值。我們希望在建立了控制邏輯子模型后，再解釋為什么在創(chuàng)建第一個實體時加入了微小的延遲，要不然等

53、到那里時你可能就已經(jīng)忘了這件事了！P195輸入界面5-2 Create模塊在第一個Assign模塊中，對變量Day遞增1，并令變量Call Number（呼叫數(shù)）的值為1，如輸入界面5-3所示。P195 輸入界面 5-3 第一個Assign模塊然后，這個實體被送到名為Check for Startup的Decide模塊，這個模塊能使實體的運動按照某種可能性或條件而產(chǎn)生分支。分支的目的地是由圖形連接定義的。到達實體將檢查每一個所定義的分支選項，并前往滿足條件的第一個分支的目的地。如果所有的指定條件都沒滿足，實體將會自動從模塊底部的False離開點離開。在此處的Decide模塊中（如輸入界面5-4

54、所示），我們在Type處選擇了2-Way by Condition選項，以檢驗當前是否處在仿真運行的開始時間，也即當前的仿真時間是否是小于1的。如果是，就將實體送到下面的Separate模塊；否則，就將它送到為呼叫數(shù)量賦值的Assign模塊。P195輸入界面5-4 Decide模塊表5-1 Decide模塊中的條件符號描述語法選項描述語法選項與.AND.或.OR.大于.GT. 大于等于.GE. =小于.LT. 小于等于.LE. =等于.EQ. = =不等于.NE. 一個條件可以是任何有效的表達式，但是典型情況下會包含一些比較運算。這些條件可以包括表5-1中的任何符號，以及邏輯表達式。如果是處在

55、仿真開始時刻，實體將被送到后面的Separate模塊（在“基本操作”面板中），如輸入界面5-5所示。Separate模塊可以對到達實體進行復制，也可以將組合成批的實體分拆成為其初始的單個實體（更多內(nèi)容詳見9.4節(jié)）。在模型中，我們將創(chuàng)建三個實體復本，以生成仿真前三天的預約。要實現(xiàn)這一點，可在Type中選擇Duplicate Original選項，在# of Duplicates欄輸入3作為副本數(shù)量。注意，該模塊有兩個離開點，原先的實體將從上面的點離開，而三個實體復本將從下面的點離開?，F(xiàn)在跟著這三個實體復本，它們被送到后面的Assign模塊，在這個模塊中用泊松分布來生成呼叫數(shù)量（Number o

56、f Calls），泊松分布的均值儲存在前面定義的變量Calls per Day中，如輸入界面5-6所示。P196輸入界面5-5 第一個Separate模塊P197輸入界面5-6 第二個Assign模塊然后，實體被送到第二個Decide模塊，在這個模塊里，檢驗變量Day的當前值有沒有超過5，如輸入界面5-7所示。這個變量保存了當前處于本周的第幾個工作日，范圍從1到6。在第一個Assign模塊中曾對此變量增加了1，現(xiàn)在則需要檢驗它是否達到了6。P197輸入界面5-7 第二個Decide模塊如果這個變量的當前值為6，那么該實體就被引導到隨后的Assign模塊中，在這里該變量會被重置為1，然后，這個實

57、體被送到第二個Separate模塊。如果前面的Decide模塊的條件是False，那么實體將會繞過后面的Assign模塊，被直接送到第二個Separate模塊。在最初的Create模塊中創(chuàng)建的單個表示了這一天的所有呼叫。雖然在仿真運行開始時就對這個實體制作了副本，但是這個實體在目前仍然代表了一天所有的呼叫。我們用第二個Separate模塊來復制剩下的呼叫。在這里只需要復制所需要的數(shù)量減1，因為初始實體將會被當作所有呼叫中的一個來看待，如輸入界面5-8所示。然后，這些實體被送到最后一個Assign模塊，在該模塊中要對一系列的屬性賦值。Day Inc屬性表示顧客希望進行預約服務(wù)的第一天（可在三天內(nèi)

58、進行預約服務(wù)）。對于在服務(wù)時選擇等待的顧客來說，其Priority屬性被賦值為1；而對愿意把車留在維修車間的顧客來說，其Priority屬性被賦值為2（可用前面建立的Wait Priority Expression表達式來為Priority屬性賦值）。期望服務(wù)時間被賦給Book Time屬性。Try Day屬性表示顧客愿意在當周進行預約服務(wù)的第一天（后面將檢驗此值是否大于5），其值為Day Inc屬性值加上Day的當前值。最后，利用前面定義的圖形集合為實體圖形賦值，并將實體送到子模型的離開點。P197輸入界面5-8 第二個Separate模塊5.4.4預約服務(wù)隨著對Arena的能力學得越來越多，開發(fā)的模型越來越復雜，你會發(fā)