tags: Simulation Arena Discrete-Event Simulation
製造系統模擬05-建構離散事件模擬步驟
前言:
系統模擬的教科書《Simulation with Arena》介紹為何需要模擬、基礎模擬相關理論後，在第二章其實就進入用Arena Model的介紹了，用簡易的模型，講解一些常見的像是物件、屬性、變數等。
但對於使用者、研究人員來說還有兩個重要過程，一是從問題界定到決定使用模擬來解決，二是要如何按部就班完成模擬模型建構，產生一個符合有代表性的模型，因此，有了今天這一篇的教學。本文特別感謝實驗室諸多學長在文獻閱讀後，留下珍貴的參考資料。
正文
本日正題，建構模擬模型的步驟，不囉嗦先上圖。
圖片中的各個說明，各位可以點以下標籤瀏覽:
以下是圖一、圖二這張圖的各個步驟解釋，依照標號依序說明。
圖片太長，考量到呈現出來的大小與解析度問題，就把它截成兩張圖了，請見諒。
1. 問題界定
每個模擬案例都需要有問題的描述.如果描述是被那些有問題需要解決的人(服務端/客戶)提供，則模擬的分析師需要縝密地去確認問題是否夠詳細了。如果問題是由模擬分析者自己準備，則這時如何讓服務端/客戶充分了解且同意界定是很重要的。通常建議由模擬分析者所準備一系列的假設且服務端/客戶要同意。即使採用了所有這些預防措施，隨著模擬研究的進展，也可能需要重新制定問題。
2. 設立目標與全盤計畫:
這個步驟又可以稱為準備提案。這個步驟無論是分析與客戶的位置如何，換句話說，無論是內部或外部顧問，都需要完成此步驟。
目標就是指這個模擬專案要深究的問題。專案計畫應該要包含我們要調查的許多的情境。案例的規劃根據所需的時間，將需要用到的人員，客戶想要運行模型和進行分析要用到的軟硬體要求，以及調查的各個階段及各階段的產出，研究的成本與費用(如果有需要)。
3. 模式概念化
正在調查下的真實世界系統會被抽象化成考量了系統的組成、結構的一連串數學、邏輯關係的概念性的模型。這裡建議模型建構要從簡單地模型開始發展，逐漸成長直到成為一個有適當複雜度的模型。
舉例來說，如果說我們要建構一個製造與物料搬運系統。
1.最基礎模型會先建構好到達(Arrival)、佇列(Queues)、伺服器(Server)。然後再考量機台故障(failure)與排班表(shift schedule)。
2.接著，再增加物料搬運的功能。
3.最終，再添加特別的功能-建構比較複雜的模型會包含有研究的成本以及完成的時間，而這些都不會增加產出。
此步驟也建議，我們要保持顧客的參與才可以增強產出的模型的品質，且增加顧客使用他的信心。
4. 資料蒐集
在提案被接受不久後便應該要向客戶提交資料需求的時程表。在最好的情況下，客戶已經以需要的資料型式收集資料且可以將這些資料以電子型式交給模擬分析師。通常，客戶所提出的資料是可以使用。然而，當資料被傳遞過來才會現跟預期完全不一樣。例如，模擬一個航空的訂票系統，模擬分析師說:”他們需要有過去五年之間有的所有資料”。當17個研究開始進行實，所遞交的資料則是每一個負責預定的人員的每一年”平均”通話時間。然而我們可能實際需要的是獨立的資料，而不是匯總過後的數值。
從圖上顯示出模型建構(步驟四)與資料蒐集(步驟三)是可以同時進行的。這說明瞭模擬分析師可以建構模型當資料正在蒐集的時候。
5. 模式轉換
我們在第三步所建構的模型會編碼為電腦可以理解的型式，也就是一個作業模型。
編註:在過去的經驗，我們實驗室內稱呼在建模階段，就是模式轉換的過程。而前述的模型建構在問題描述階段通常就已經有個雛形了。以生產系統模擬的過程來說，通常我們要熟悉製造現場的作業流程對應的資訊流與物流，就能夠建構出概略的模型，而詳細的資料則需要依據蒐集的資料輸入模型的參數位置。
6. 信度驗證
驗證模型的運作。有沒有正常的運作?
即便是教科書中的範例大小的模型，他也有可能是存在驗證的困難。而這些模型比起實際模型小很多數量級(程式碼可能少很多倍)。因此，高度的建議要在持續過程中都要進行驗證，如果我們等到整個模型都建構完成模擬分析師才開始驗證是非常不明智的。
此外，推薦可以用使用互動式的運型控制器(interactive run controller)與除錯器(debugger)來輔助驗證過程。
編註:以Arena這套軟體來說，我們有幾種方法進行驗證:
- 透過建構動畫觀看物件流動。
- 透過像是Record模組來記錄Entity流經的數量，檢驗我們設定的Decide模組有沒有發揮作用。
- 透過變數來監控數值的變化。
7. 效度驗證
效度驗證是決定概念模型是否可以精確地呈現現實系統。模型是否可以因應實驗的目的去代替現實系統。如果有一個實際存在的系統，我們可以將他稱為基準系統(Base system)。不幸的是不一定總會有一個基準系統。還有很多方法可以用於進行效度驗證。
製造系統比較常看的就是
- 週期時間(Cycle time)、
- 在製品數量(Work in Process, WIP)、
- 產出數量(Throughput)
這些績效指標。而如果有一個現實系統可以作為基準系統，則我們會建構一個現況模型，用此模型來驗證上述這些績效指標跟現實系統的誤差會不會很大，至於誤差的計算方式通常是:
8. 實驗設計
針對我們要模擬的每一個情境，我們進行決策，考量需要模擬長度多長、要跑的模擬次數(稱之replications)以及初始化的方式等。
模擬的長度、模擬次數與初始化方式，後續有章節詳談，有機會會再整理給各位。
模擬的結果很大一部份是用於統計推論上，因此，我們需要多高的準確度(誤差要多小)，會影響到模擬的長度與模擬的次數。
初始化方式則是系統開始之初會沒有WIP，需要等待一陣子後績效指標才會穩定。常用的方法有像是暖機(Warm-up)來處理之後文章有機會也會講解這一塊。
9. 重複執行模擬和分析
生產運行與接續的分析都可以用來評估我們模擬的情境的績效表現。
10. 需要更多模擬結果?
根據已經完成的運行分析，模擬分析師可以決定是否需要額外的運行結果或是有其他的情境要被模擬。
在製造現場要推行方案前，經理人、管理者(manager)通常都會衡量成本、效率，因此，可能原先模擬分析師提出的方案設計資源數(例如:機台、搬運設備的數量)會超出他所估計的成本或是實務上可能有限制是沒被模型考慮到(例如:現場空間)。這時候很可能就需要有更多的模擬結果。
11. 模擬結果分析報告
有很多裡有我們需要執行文件化的理由。如果模擬模型需要給相同或是不同的分析師再次執行，則可能需要一些必要了解的模擬模行運作。這樣可以增加對模擬模型的信心使得客戶能夠根據分析結果進行決策。而且，如果模型需要被修改，則可以透過適當的文件來加速進行。
所有分析的結果應該要被清楚且精確地作成報告。這樣會使得客戶能夠審查最終的陳述、被提出的替代方案、有準則可以比較替代系統、實驗的結果以及分析師的建議等任何有需要的內容。
12. 實施
模擬分析師需要扮演一個報告者而非倡導者。在步驟11所準備的模擬分析結果會寫出他的優點，以及額外的資訊讓客戶能夠進行決策。如果客戶在整個研究的期間都有參與且模擬分析都有遵照步驟嚴謹地執行，則實施成功的可能性就大大地增加。
我自己的模擬經驗不算多，但也算經手過幾個案子了(眼鏡公司生產排程、半導體廠的無人搬運車評估等)，顯而易見的是工廠內大家各司其職，如:設備工程師可能對機台參數很了解、製造課長可能對產線生產的產品與流程倒背如流。
然而模擬需要不僅只是單一部門的資料，而需要有人負責整合這些資料作為評估的基礎，進而建構一個模擬系統，因此如何從訪談、詢問的過程中，得到需要的資料(步驟4資料蒐集)、找出實施的限制(步驟3與步驟5)加入模型當中，都是相當關鍵的。
結論
從這張圖來看，不難理解上述的兩個過程，為何問題界定會放在首位。有清晰的問題描述，才能夠知道我們要建構什麼模型(步驟3、步驟5)、蒐集什麼資料(步驟4)、定義什麼績效指標(步驟3、步驟5)。
在過去實驗室執行的專案，通常資料蒐集(步驟4)是由我們這些派去產學公司學習的實習生(~~廉價勞工? ~~)執行，因此，在完成模式概念化(步驟3)後，需要花時間想需要想:
- 蒐集哪些資料?
- 從哪些系統可以獲得?我們有權限取得嗎?還是需要請現場工程師、主管協助
- 如果系統不能獲得，則我們要怎麼進行現場觀察?
當然，如果資料真的無法蒐集，還有假設一個途徑，只是這樣可能到信度與效度驗證(步驟6、步驟7)就可能會碰到難以自圓其說的問題，因為有可能是假設偏離現實又或者模型有錯誤，變成驗證時候要多花一些功夫(或者就要接受現實，模型可能就比較不精確)。
如果系統不能獲得，則要怎麼瞎掰?(開玩笑的，請不要拿學術生涯賭)
分享一個我親身看過的例子，Arena裡面有一個函數教作三角分配(不是三角函數)，寫法是TRIA(最小值,眾數,最大值)，在《Simulation with Arena》一書中說到，如果資料數不多，可以用這個函數。
然而，產學為期一年到一年半，而那位同學的案例是自行車的車架，他研究範圍只做一個站的四道製程，分別為:
- 點焊
- 補焊
- 滿焊
- 打頭管
調整(我自己認為這不算製程，這應該屬於附帶作業，故用刪除線)
結果他的模擬竟然是用三角分配，那現場觀察一年半是觀察辛酸的…蒐集一年半跟我說資料不夠。又不像是有人的案例有8~9個工作站，產品非常複雜根本不能現場觀察完。
最妙的是她的指導教授認為他有理論基礎…，但我自己是認為沒有實事求是(能做到的事情，為什麼不做，從實務面上講不通)
而這樣的結果就會導致變異係數(Coefficient of Variation，CV極小)。換言之，這個系統沒有什麼變異性(Variation)。在我看來，這樣的研究，其實用模擬就有點殺雞用牛刀，而且更妙的是，工作站的人員分配竟然是用Excel作程的山積圖(作業者平衡表對應的圖片)推算出來的…那模擬的用途更顯得定位不明。
因此，要提醒大家，問題定義的重要性，在搞清楚問題後，就會知道哪樣做是殺雞用牛刀(用試算表就知道的結果，還建構什麼模型?用公式算一算就好了)；如果碩士論文題目的內容這麼簡單又狹隘，那比廢文還廢
通常，我們會把模擬用在變異性很高、充滿不確定性的製造現場，而非簡易的單一產品、單一產品途程(Routing)的分析上。
過去5~7年實驗室內學長、姐的文章大多沿用這個方法，所以從這樣的建構流程來看，建構模型不事件很困難的事情，蠻多時候建模的難處反而變成了對模擬軟體的熟悉程度…身為模擬助教的我感慨良多。最後，放兩個笑話給大家聽聽(感謝大家觀看至此)
笑話一:
- 畢業的那個學期，我編寫論文邊當模擬課程助教，當年只有3個人修課，兩位博士班一個碩士一年級新生，結果第一份作業收回來，老師問作業的內容，一個是不敢，另外兩個不會回答
- 從那次開始分成三份作業，然後三份作業收回來，除了字體大小不太一樣，圖片截圖大小不一致外，其餘像是答案、錯字都一樣。
結語:那這樣就派一位代表來聽課，反正，再轉述就好了?
笑話二:
- 畢業後聽說有博士班被當的學長，回來重修這門必修課，然後學期末專案的模型建構問了第一個教學模型上的一個模組(module)怎麼用…
- 該學長忙著做專案、準備考試，說考完會幫忙建模型，結果…啥都沒做，報告還搶著報告，收割成果。
社會險惡阿…
結語:碩士一年級的同學們都辛苦了
參考文章
Banks, J., J.S. Carson, B.L. Nelson, and D.M. Nicol 2000. Discrete Event System Simulation, 3rd
Ed., Upper Saddle River, New Jersey: Prentice-Hall.
留言
張貼留言