Simulation - AnyLogic / NetLogo

AnyLogic是非常逼真於真實世界，一個模型可能會包含好幾個議題，甚至可以有好幾種解法。想要有個好架構來講解，的確不容易。在此，也只能試圖去建立一個講解案例架構。 ========= 流程簡述 病患到達時，會先設定出現門口。 先移動病患至報到櫃台。 報到櫃台有一位常駐服務人員，每次僅能處理1個病患。 若報到櫃台處於忙碌狀態，其他病患需等候於等候線。 若報到櫃台處於空閒狀態，則從等候線釋出1個病患，移動註冊報到服務。 完成報到後，病人將移往等候室。 現場佈置 entryDoor: 當病患到達時，會先出現在此區域。使用space markup-Rectangular Node[待補連結]，並以隨機方式呈現在此區域中。 polyQueueAtReg: 當服務櫃台處於Busy狀態時，病患需在此等候線上等待。使用space markup-Polygonal Node[待補連結]。 registrationDesk: 當病患開始接受服務時，會出現在此區域中。使用space markup-Rectangular Node[待補連結]，並採Attractors[待補連結]方式，限定病患面向櫃台。 person_sitting: 櫃台人員。使用3D物件呈現出櫃台狀況。 使用Path[待補連結]將上述space markup物件串連成一個 NetWork 。如此，病患才能依循路線移動。 waitingRoom: 完成報到手續者，將被移動到此區域，等待下一個檢傷分類流程。使用 space markup-Rectangular Node[待補連結]。 邏輯流程 流程詳述(整合現場佈置與邏輯流程) 病患(Patient: Agent Type)到達(arrive:  Source )，會設定在門口(entryDoor: space markup-Rectangular Node[待補連結])。 移動病患(gotoRegistration:  MoveTo )至報到櫃台(registrationDesk: space markup-Rectangular Node[待補連結])。 此報到櫃台有一位常駐的服務人員(person_sitting: 3D Object)。每次僅能處理1個病患。 若報到櫃台處於Bus

本系列是參考官方範例來改寫的。本案例會使用到的元件、功能與技巧更多了。 本案例是模擬醫院的急診部門，想了解各項資源之使用情形。 情境說明 設施類資源 有1個報到櫃台。 有1區候診室。 有1間放射室。 有2間檢傷分類室。 有5間治療室。 有1間超音波室，最多可放5台超音波設備。超音波設備是可以被移動的。 人力類資源 有護士。 有助理醫師。 有放射師。 作業流程 病人到達後，至報到櫃台註冊報到。 註冊完成後，自行前往候診室。 依序由護士協助下，進入檢傷分類室。 確認後，病人前往治療室。依需求會用到X-ray，或者是超音波。上述設備由放射師與助理醫師操作執行。 病人若需要照X-ray，需前往放射室。 病人若需使用超音波設備，則將設備移動至病人所在之治療室。 策略規劃 依據現有來客數與固定設備下。護士、助理醫師、放射師，應配置幾人。 超音波設備應配置幾台。 資料收集 向工程單位取得急診室布置圖，各空間所佔面積與距離皆可參考。 依據歷史資料，每分鐘約有0.14個急診病人。 報到註冊的時間約為triangular( 0.5, 1, 1.5 )。 等候室最多僅能容納20人。 依據歷史資料，檢傷分類所需時間約為triangular( 5, 8, 15 )。 操作超音波設備的時間約為triangular( 10, 25, 30 )。其移動速度依賴助理醫師而定。 X-ray作業，分為兩階段。(1) 初步檢查、(2) 照射X-ray。其時間分別為triangular( 3, 4, 6 )與triangular( 5, 7, 10 )。 急診室佈置圖

延續前一篇 最簡模型-ATM-Part4-資料收集-觀念說明 ，依據策略規劃目標，我們找到了3個管理指標。 其公式分別為： ATM平均使用率。分母是模擬起始時間的累積，分子是ATM處於Busy狀態的累積時間。 等候線平均長度。設定取樣時間距，然後去抽樣目前等候線的人數。分母是模擬開始後的抽樣次數，分子是每次抽樣數之累加。 提款人平均等候時間。分母是總提款人次，分子是個別提款人等候時間之累加。 有人也許會問，那為什麼不收集提款人使用ATM的平均時間呢？若你有這個疑問，請回去參考 最簡模型-ATM-Part1-模型說明 。這不就是我們給的隨機變數嗎？ ATM平均使用率 由於是使用Delay內建的statsUtilization這個變數，所以，可以直接處理Presentatioin的部分。 使用Bar Chart元件 先確認目前是在Main這個Agent Type裡。 切換至Analysis頁籤。 選擇Bar Chart。 將Bar Char拖曳到編輯區來。 使用好元件，接者是要設定參數。 設定Bar Chart參數 在Bar Chart的屬性視窗中，有個Data頁籤。點選加號，即可設定資料來源。重複此動作，則可將相關數據資料放在同一個Bar Chart中作比較。 資料源設定可以改名稱，改顏色。最重要的是資料源設定。這邊我們是用ATM這個物件(若沒有物件導向概念的人，我再說明一下Delay是類別，ATM目前是物件，是Delay的一個案例)所提供的統計變數。我們取mean這個函數。 mean這個函數有兩個同名異式。第二個是設定一個參數，指定說模擬啟動後多久才開始收集資料。這個觀念似乎在前面的篇幅中沒有特別強調過。為何要隔一段時間呢？因為要避開系統過渡期。一般系統模擬收集資料都會從穩定態才開始。越講越亂？那是因為，模擬啟動開始，所有的數據都是從0開始，而且，從第一個Entity產生，一直跑到最後一個Entity可能也要花費一段時間，而這段期間，後段的元件都是處理Idle狀態，用模擬啟動時間開始收集資料，那當然會產生很大的誤差。所以，要等Entity穩定的產生，然後每一個元件都穩定的產生數據(平均數不要太離譜)，這時候來收集資料才有意義。而且，不是取一次，穩定後還得要分段取。

資料收集從技術角度來說，很容易。問題在於，收集什麼資料。這部份一定要與建構此模型之目的要緊密結合在一起，也就是說，要從策略出發。有時候，資料收集的對象很直觀，有時候卻是需要收集某些原始資料，然後進行處理，之後甚至要與其他資料結合後，才能發揮其真正目的。 回顧 最簡模型-ATM-Part1-模型說明 的內容，一開始我們建ATM模型之目的，是想要知道在現有來客數之下，一台ATM夠不夠，等候空間15人夠不夠。反過來說，我們也有可能想知道，在有資源設備下，能夠支撐最大的來客數是多少。這些都是沒有考慮到成本問題。一台不夠，再加一台，可是再加一台等候空間是否需要調整，成本效益又是如何？這些就會演變成最佳化的問題，收集資料方式與對象就有可能會轉變。總之，資料收集與分析是相依於策略規劃。 策略規劃與資料收集轉換 策略規劃是敘述性描述，需要轉換成「指標」。有指標才會有「公式」，有公式才知道「變數」，有變數才知道要從哪裡收集什麼樣的資料。 需不需要增添一台ATM，也就是一台ATM夠不夠。那你要先定義什麼叫做夠不夠。因為是設備，在正常運作下，他應該是24小時皆能使用。問題來了，有三點需要注意，(1) 人不會平均分散於24小時來。(2) 有人使用，ATM才叫有在工作。(3) 雖然是24小時運作，但是機器也有需要休息保養，甚至損壞等因素。 人不會分散24小時來，人可能會集中在某些時點來的人特別多。櫃台還有上下班時間，ATM是24小時營業，這點反而單純。還好，這些問題對AnyLogic來說，都可以輕易設定。只要使用Schedule(待補)元件，就可以搞定。也就是說，櫃台的資源可透過Schedule來設定上班(Avariable)還是下班(Unavariable)。Arrival Rate也可以依據Schdule設定，不同時段有不同的來客數。只是，本系列是「最簡模型」，所以這部份，就不予考量。 有人使用才叫做有使用。這部份，從管理角度搞了一大堆的「率」。這個「率」說穿了就是搞定「分母」與「分子」應該要放什麼變數。然後，得到的結果，再想辦法解釋(然後硬生成論文)。有設備使用率、產能利用率、稼動率等等。我這邊想解釋的是說，有些數據千萬不要相信。就以ATM為例，如果設備使用率之分母為24小時，分子是有人提款使用的時間，那這台ATM「平均」使用率一定很低。永遠不會有需要再增購一台的

隨著個人電腦的運算能力精進，近年系統模擬的最大差異就是採用3D動畫來呈現模型。 3D技術博大精深，這篇僅能提到一些空間佈置(Space Markup)應用。至於詳細的內容，得參考空間佈置系列的文章。若要詳談3D的話，又得再開另一系列才行。 ========== 首先我們知道模型中的元件，在真實世界裡是否需要呈現。例如說Source，可以僅設定一個點，當作Entity Arrival時，要出現的位置。如果，你的模型設計是一次Arrival事件發生，會同時來很多個Entity，用點來表示，就無法感受多個Entity，就需要設定一個空間。再複雜點，你還可以設計一個門放在那兒，如時間很夠，你還可以加上動畫，用來顯示人進來是開門關門的動作。工作站也是，你可以僅僅用一個方型區間來代表，可是，若你想明確表達這空間中，工作人員等候時站在哪，操作時站在哪，Entity進來時先放哪，加工時會在哪，結束後會放哪。甚至你可以設計加工前Entity的外觀樣式，加工中，加工後，都可以不同。總之，彈性甚大，也因為如此AnyLogic很強大，也正因為如此，想學好AnyLogic真的不容易。 1. 設定ATM ATM是一個服務點，此方案的Entity是提款人，他不會跑進ATM裡面，所以，用「點節點」來代表就可以了。 可從Process Modeling或者是專用的Space markup頁籤中取得Point Node，將其拖曳到編輯區中。 接下來的動作是要把邏輯流程的元件與Space markup的元件進行連結。回到ATM這個物件，他是Delay這個類別的案例。設定Agent Location指向剛剛拖曳的Point Node(預設名稱為point)。右方兩個按鈕，左邊那個是協助你在Space Markup網路中，點選對應的元件。右邊那個是當你設定完成後，點選之後，系統會告訴你他是在Spacke Markup中的哪個元件。前者是新增，後者是查詢。 2. 設定等候線 ATM的排隊模式是先到先贏，每個人都得乖乖排在線上，所以，會使用Path來設定這條等候線。Path可提供很複雜的操控模型，讓你可以呈現真實世界的動線。一樣用拖拉入編輯區，然後移動至適當位置（預設名稱是path）。 接著就是進行連結。選擇queue，再設定Agent location的屬性。記得

空間佈置相關元件是用來定義實體世界之物件與虛擬物件在空間中的對應關係。例如說一個等候線應該要長什麼樣子，從哪裡到哪裡。或者是工作站應該要長什麼樣子，他的範圍是從哪裡到哪裡。然後，Entity的流動路線應該是從哪裡到哪裡等問題。 不過，要談這一系列之前，首先要搞清楚尺規。AnyLogic之所以可以對應於真實世界，是因其畫布(編輯區)可定義與真實世界之比例尺。 編輯區在正常的視圖下，上方位置會有一個比例尺。而編輯區也可以看到有格線。我們就是利用格線來定義實際尺寸。 把編輯區放大至400倍，透過圖中格線與右方屬性設定，我們發現到目前這個專案的定義是100px相當於10公尺。當然，你可以任意調整成適當的比例尺。 這個是要提醒，當我們設定一個等候線或等候區，一個加工站，一個櫃台等等，都不是亂放的。有些模擬軟體雖然號稱3D，但與實務的空間關係是無法真實對應的。 從圖中我們要知道格線的一格其長寬為5px，是0.5公尺。 接者要確認的是，你的模型展示的精密度。一般建議是用Entity的大小作為最基礎單位。這樣子，比較能夠感受到等候線與空間的相對感，以及Entity在加工區應有的位置。但若，實務的Scall很大，例如是搞GIS，那就不能夠這樣子搞，也僅能用抽象比率。否則，就算是一台車也是一個點，那就不好搞視覺差異。

AnyLogic的下載安裝請參考 此篇 。不過，AnyLogic經常改版，可能也只能當作參考之用。雖然如此，八九不離十。 此篇是接續 最簡模型-ATM-Part1-模型說明 的內容。 =========== 1. 新建模型  當然，新增模型也可從 [File->New]取得。 2. 模型屬性 模型名稱。 選擇專案位置。 選擇此專案的Package名稱。一般都採預設值。除非，你的版本考量。再說明一次AnyLogic就是一個基於Eclipse的特用型Java開發環境。 選擇模型的單位時間。這個選擇非常重要，若模型要跑一年以上，卻把單位時間設成秒，那就把電腦放著，好好去睡覺，確保電腦不要過熱就好。還好，模型建完後，發現不對，還可以改。至於模擬的相關時間概念，請看 這篇 。 填完，就按[Finish]，來到編輯狀態。 3. 編輯區  專案目錄區：若你有其他程式開發，有使用IDE的經驗，其實，Anylogic就是開發一個Java的專案。 BankATM稱之為專案。AnyLogic可以同時開啟數個專案。 Main是程式進入點？對AnyLogic來說，他只是一個Agent Type，主類別。系統內可以有好幾個Agent Type，其實無主、副之分。 Simulation: Main這個才是真正的程式進入點，也就是一個執行方案（這個概念與Visual Studio不同）。有趣的是，你可以有好幾個程式進入點(執行方案)。對AnyLogic來說，只要參數設定不同，就可以是一個實驗計畫，就是一個執行方案，然後宣告這個執行方案的主Agent Type。然後，執行此實驗計畫，也就是依據Agent Type 產生案例(Instance)，就是產生物件。每跑一次，就是一次的試行。不同實踐計畫，就是你的方案比較。或者是用來作敏感度分析，或作最佳化模擬。 Run Configuration是讓你在雲端執行。抱歉，還沒試過。 Database這是內部資料庫。可以讓你先把外部的資料匯入，然後讓模擬直接存取。這樣子效能比較好。之前的版本，大都是讀取EXCEL資料表，後來有支援資料庫，然後變成內建資料庫。想想，自己也是陪著AnyLogic長大的。這部份，我還是喜歡直接連外部資料庫，哈～這是與其他系統進行整合的關鍵。也是

需要讓Entity停留一段時間的請境，都可以用這個元件來處理。 這個元件的核心在時間。所有可以產生數字的方式都可以拿來套用。當然，最常用的還是隨機變數。 有Inbound與Outbound Port，這部份應該沒有什麼問題了。一進一出，乾淨俐落。 配對元件   無 類似元件  Service。這個元件是把Queue與Delay合併在一起處理，再加上資源應用的部分。  Hold。這個元件也會把Entity暫留住。只是這個元件比較像是關口閘道。可設定開跟關。關時，所有元件都過不去。開時，所有元件都過去。 屬性 Delay的屬性也很單純。 設定「設定時間」的方式。一個是給定特定的時間，一個是在別的地方(可能是另一個元件，流程、函數，反正是可以寫程式的地方)呼叫這個元件的stopDelay()，就會直接放行Entity。 若勾選Specified time時，就要給定Delay時間長度。 設定這個Delay可以同時處理幾個Entity。在ATM範例中，一台在同一時間只能服務一個客人。但是，有些服務櫃台，他會同時放兩隻椅子，讓同一位服務人員，在同一時間內，可以服務兩個客人。 若勾選這個，表示Queue送來幾個Entity都可一塊處理。 一般而言，模擬都是走拉是(Pulling)，也就是說，後面的元件有空閒了。專業的說法是其Inbound port為可得狀態時，在前面元件裡的Entity就順理成章的進到下一個元件去。這邊補充一下Queue篇中所提到的問題。若這個Delay前面是Queue，當然順理成章是沒有問題，Entity都會乖乖地照順序進入Delay。但是，若前面是判斷式類的元件，就不一定了。有時候程式沒寫好的話，還會造成系統當機。我吃過很多次虧。 事件 On enter [code] ： Local variables:                            agent - the agent                    double delayTime - the delay time for the agent (already evaluated) On at exit [code] ： Local variable:                  

Queue是非常重要的元件，雖然他的設定很簡單。但是，放對地方上天堂，放錯地方住套房。這部份是經驗談，需案例說明才能體會。 Queue就是用來代表真實世界中關於排隊等候的情境。排隊等候的情境有等候線，等候區的概念，但就Queue來說，其實沒有差異。主要是在畫Layout時，設計對應方法不同而已。這邊設定純粹只有兩個目的，一個是capacity，一個是Queuing Policy。不過，在實務應用時，往往會利用他「排隊」特性，將流竄Entity彙整起來。這是有實作經驗後才發現的問題，尤其是經由判斷Entity迴轉等處理情境時，此Entity並不如你以為的順序進行中。透過Queue，可避免這個問題。 Queue除了有Inbound與Outbound Port之外，又多了兩個Outbound port，分別是outPreempted與outTimeout。不過，Entity會從這兩個Port出去的前提是，有兩個屬性Enable preemption與Enable exit on timeout要勾選起來。 配對元件   無。其實，他應該是跟每個元件都能配對。 屬性 Queue的屬性很單純。 Capacity代表這個Queue最大的容量。這塊有麻煩。模型建立之初，當然不會正確。可能後面的元件出了問題，就會在Queue卡住而無法釋出。這時候，超過Queue所設定的Capacity時，元件不是自動消失，而是給你當機出現錯誤。 設定這個Queue為無限大容量。如前項所言，為了避免麻煩，模型建立之初，都會先勾選起來。另外，拿來當作彙整Entity的Queue當然也要勾選起來。 這是定義Entity來到這個Queue時，要用什麼方式呈現。這就會有所謂等候線與等候區的差異了。 定義這個Queue的排隊政策。有FIFO、Priority-based、Agent comparison與LIFO。FIFO與LIFO比較熟悉，不多說。Priority-based是根據Entity的某個屬性越大者越優先。也就是說，當一個新進Entity設定用來比較屬性大於所有在Queue中Entity的話，他就會優先離開QUeue。注意，日期是越舊越小。若Queue設定是老人家先行，這時候日期要想辦法轉換成越舊越大。至於Agent comparison，是將新進的Eni

Sink 在離散事件中，Sink也是必要元件，他必須依賴Source而存在。一個模型中，可以有數個Sink。 Sink只有一個Inbound Port。 從程式的角度，他就是解構元。 配對元件 Source 。Entity在模型中必須要有生有死。Source負責生，Sink負責死。 類似元件 Exit。 屬性 Sink屬性很單純。Entity都要死了，還能搞什麼？ 事件 是的，不能搞什麼，但是死也要有意義。Entity最後得將身上所背負屬性的最後狀態給記錄下來，作最後貢獻。 On enter [code] ：當Entity進入Sink元件時，可以寫程式。一般就是把Entity的最終狀態，記錄下來。可寫入資料庫、寫入EXCEL或文字檔。 Local variable: agent - the agent. 方法 long count() - 經由Sink離開的Entity數量。

Source 在離散事件中，Source元件是必要元件。(也就是說，其他代理人與系統動力學就不需要了)一個模型中，可有數個Source，並可建立彼此依賴關係。 小綠圈圈叫Port代表與其他元件的連接點，一個元件可能會有1到數個。Port就元件本身而言，有Inbound與Outbound兩種類型。Source只有一個Outbound Port，所有Entity由此而生。就程式的角度，他就是建構元。協助你產生模擬中所需要用到的Entity與你所預期的數量與各別時間點。 配對元件 Source必須與 Sink 配對。一個模型中，一定至少要有一組Source與Sink，才能讓Entity有生有死。 屬性 元件的屬性結構有點複雜，不容易講解。某些屬性是相依於其他屬性。有些屬性是下拉清單，因選擇不同，又會冒出不同的屬性需進一步填寫。這麼複雜的結構，還是可以讓你自訂屬性。從系統發展的角度，這是非常好的機制。 因為難講解，只能挑重點講，細節得看手冊。手冊非常重要，就算我研究他已經三年多，還是得常常去翻手冊。只是，手冊真的不容易閱讀，這部份也會有專篇來討論。下圖是Source的基本屬性。逐行解釋，若後續元件有重複的屬性，就不再說明。 Name：元件的名稱。這個取名非常重要，因為程式會用到。你可以想像他就是宣告一個物件名稱(Source是類別，希望你有OOP的觀念)。一般為了辨識且容易在城市中呼叫，這個類別名稱(source)會保留，然後再輸入你的識別字。因為AnyLogic的城市編輯部分，有支援Code Completion。 Show name或者Ignore。很單純的功能，就是在AnyLogic的模型編輯區中是否要顯示Name。因為，有些元件可能是過渡的，或者不是重點，你就可選擇Ignore，讓編輯區保持清爽。 Arrivals defined by：這是source獨有，決定要用什麼方式來定義Entity的到達模式。其選項有[Rate], [ Arrival table in Database ],[ Arrival  schedule ],[ Calls of inject() function ],[ Rate schedule ],[ Arrival  schedule ]。不同選項，會衍生出不同的動態屬性。圖中是配合Rate

前面談了一些機率分配函數，得趕快跟模型扯上關係，否則目標就不對了。 雖然說是最簡模型，可能也要分好幾次才能說完。這個案例是關於銀行作業，屬離散事件模型，採用AnyLogic的內建教學內容，只是我有改寫成中文投影片。不過，這邊還是將其簡化，使得更容易上手。 情境說明 1. 有一家銀行在某地擺設一台ATM。 2. 使用者需排隊，先到先用。但，周邊空間有限。 3. 僅提供領款，操作流程變化不大。 策略規劃 銀行主管想知道，現有的來客數下，一台ATM的使用量為何？是否需要增添一台。有多少人，因不耐久候而離開，是否需要調整空間位置。以上，皆暫不考慮成本問題。 資料收集 派員收集資料後發現： 1. 每分鐘會來0.3人。 2. 僅能容納15個人排隊。 3. ATM操作時間平均約1.5分鐘，最多3.5分鐘，最快0.8分鐘。 模型建立 說明： source他提供了很多種方法，讓你產生Entity。Entity就是在模型上流竄，然後觸發事件，讓你可以寫程式，收集資料。 queue就是代表等候線/區。可設定Capacity來代表空間，當然可以設定無限空間(Maximum capacity)。排隊準則(Queuing)預設是FIFO（First In First Out）,當然也可以改成其他如LIFO(Last In First Out)，甚至可使用Piority等。 ATM這個物件的原名就delay，代表耗用時間，也就是代表提供服務，進行作業的地方。需要設定的有作業時間(Delay time)與作業能力(Capacity)。 sink是讓Enity離開的地方。一般會在這兒將掛在Enity身上的資料給搜刮下來。 參數設定 1. source 2. queue 3. delay 4. sink：暫時沒有。 ==== 就先到這。 哈～冒出一個Triangular的機率函數，沒什麼反正就是大概大概啦。在意就用Normal。 寫到這也是我有點難取捨之處。到底，重點是放在軟體的操作面上呢，還是放在策略應用面上。還是，哈～根本就是兩本書。操作真的沒什麼好講的，但是，可以擴張頁數，市面上的書都是這樣。而我真的想講的是這個模型到底要怎麼應用在策略規劃上。您看我的內容，已經