最簡模型-ATM-Part4-資料收集-實際操作

延續前一篇最簡模型-ATM-Part4-資料收集-觀念說明，依據策略規劃目標，我們找到了3個管理指標。
其公式分別為：

1. ATM平均使用率。分母是模擬起始時間的累積，分子是ATM處於Busy狀態的累積時間。
2. 等候線平均長度。設定取樣時間距，然後去抽樣目前等候線的人數。分母是模擬開始後的抽樣次數，分子是每次抽樣數之累加。
3. 提款人平均等候時間。分母是總提款人次，分子是個別提款人等候時間之累加。

有人也許會問，那為什麼不收集提款人使用ATM的平均時間呢？若你有這個疑問，請回去參考最簡模型-ATM-Part1-模型說明。這不就是我們給的隨機變數嗎？

ATM平均使用率

由於是使用Delay內建的statsUtilization這個變數，所以，可以直接處理Presentatioin的部分。

使用Bar Chart元件

1. 先確認目前是在Main這個Agent Type裡。
2. 切換至Analysis頁籤。
3. 選擇Bar Chart。
4. 將Bar Char拖曳到編輯區來。

使用好元件，接者是要設定參數。

設定Bar Chart參數

1. 在Bar Chart的屬性視窗中，有個Data頁籤。點選加號，即可設定資料來源。重複此動作，則可將相關數據資料放在同一個Bar Chart中作比較。

1. 資料源設定可以改名稱，改顏色。最重要的是資料源設定。這邊我們是用ATM這個物件(若沒有物件導向概念的人，我再說明一下Delay是類別，ATM目前是物件，是Delay的一個案例)所提供的統計變數。我們取mean這個函數。

1. mean這個函數有兩個同名異式。第二個是設定一個參數，指定說模擬啟動後多久才開始收集資料。這個觀念似乎在前面的篇幅中沒有特別強調過。為何要隔一段時間呢？因為要避開系統過渡期。一般系統模擬收集資料都會從穩定態才開始。越講越亂？那是因為，模擬啟動開始，所有的數據都是從0開始，而且，從第一個Entity產生，一直跑到最後一個Entity可能也要花費一段時間，而這段期間，後段的元件都是處理Idle狀態，用模擬啟動時間開始收集資料，那當然會產生很大的誤差。所以，要等Entity穩定的產生，然後每一個元件都穩定的產生數據(平均數不要太離譜)，這時候來收集資料才有意義。而且，不是取一次，穩定後還得要分段取。

等候線平均長度

這個操作流程與前項差不多，唯一差別是公式不同。改成queue.statsSize.mean()。也許有人會說，啊都一樣，為了不跟前者放在一起。這～有點在回答張飛打岳飛的問題。兩個資料呈現方式相同，但是本質不一樣呀，不能拿起來一起比。

提款人平均等候時間

這個有點小麻煩，先簡單描述作法。首先在Entity(本案例稱之為Customer)要放一個變數(假設為startWaiting)，來紀錄開始進入Queue的時間點，然後等到他離開Queue，再把現在的時間點減去startWaiting，就會得到時間距。並將此資料寫入Histogram Data元件中。拖曳Histogram Chart到編輯區，然後設定資料來源是Histogram Data。

1. 確認是在Customer這個Agent Type的編輯區中。
2. 移至Agent頁籤。這時候可以說了，AnyLogic是用Agent-Base貫穿整個模型。說穿了，也只是Java程式的開發而已，所有的元件，也都只是AnyLogic提供的Java程式庫而已。這部份又會是一系列Java於AnyLogic程式開發技巧篇。
3. 選擇Parameter元件。
4. 拖曳至編輯區
5. 修改名稱。
6. 設定資料型態為double。

1. 確認回到Main編輯區。
2. 選擇Analysis頁籤。
3. 選擇Histogram Data。顧名思義，我們是要收集能夠繪製直方圖的資料。
4. 拖曳到編輯區中。
5. 修改名稱。
6. 設定組數。目前是分成50組。組數很多，直方圖看起來會比較圓滑，但是，他的前提是你收集的資料要夠多。「資料夠多」這個事情，對系統模擬來說，根本就是一塊蛋糕。
7. 預設，計算累積分配函數
8. 自動調整組間距。也就是說，在現有收集資料情況下，我要分成50組，那每一組的間距應該是要多少，讓系統幫我們自動調整。
9. 那從兼具多少開始調整起呢？目前設定是0.01。

1. 在邏輯流程中選擇Queue。
2. 在Actions頁籤中On enter事件中，輸入agent.startWaiting = time(); 。agent代表目前進到這個Queue的Entity，這叫區域變數，在介紹Queue中已有提到。startWaiting是我們設在Customer身上的參數。Time()是AnyLogic所提供的時間方面函數。代表目前的模擬時間（這個跟你的模型單位時間無關，之後再轉換對應的），而且隨者模擬進行不斷地增加模擬時間。
3. 在Actions頁籤中On exit事件中，輸入waitTimeDistr.add(time() - agent.startWaiting);。waitTimeDistr是我們拖曳到編輯區的Histograme Data。Time()已經解釋過，只是，他現在所代表的時間，已經與當初Entity進入那時的時間變更大了。

1. 在Main中，切換至Analysis頁籤。
2. 選擇Histogram元件。
3. 拖曳至編輯區。
4. 新增資料來源。原始狀態只有這個按鈕。
5. 設定此圖之標題。目前為Waiting time distribution。
6. 設定資料來源。之前，我們已經把資料收集到waitTimeDistr中。

執行成果

這是跑了3322模擬時間。因為模型設定單位時間是分鐘，所以，此模型跑了3322分鐘。55.367小時的結果。

補充說明一下，因為我們是抓排隊的時間，不會呈現Normal。

抱歉，沒有仔細設計。單純把結果呈現，有些補充說明的文字敘述可以再加強。

結論

就目前的成果看來：

1. ATM的使用用才57.8%，尚足以應付需求。
2. 而且平均等候線人數平均才0.54人，並不造成對環境壓迫。
3. 平均每一位客人僅需等待1.82分鐘。經問卷調查，一般民眾可以忍受等候的時間為5分鐘，此數據遠低於此。皆為可接受範圍。抱歉，「遠低」還是要透過統計手法進行確認。

故，建議銀行針對此區的ATM服務設施，並無需要改變之處。

建議擴散調查並增加模型複雜度，確認周邊是否有其他銀行之ATM，或本行ATM是否有重疊之處，或可裁撤此ATM。