Simulation - AnyLogic / NetLogo

本篇是接續上一篇 進階模型：醫療業-Emergency Department-Part 2-邏輯流程-註冊報到 。 ========== 流程簡述 病患已經完成報到註冊程序，且被移往等候室，等待檢傷分類作業。 檢傷作業由護士引領病患至檢傷室。 確認同時取得護士與檢傷室這兩種資源後，則將病患與護士一同送往檢查室。 進行檢傷作業。 完成檢傷後，離開檢傷室。 仍由護士將病患移往等候室。 現場佈置 waitingRoom: 完成報到手續者，將被移動到此區域，等待檢傷分類流程。完成檢傷分類的病患也會回到此區域，等待處置作業流程。使用 space markup-Rectangular Node[待補連結]。 rectangle3、rectangle4: 這兩個space markup-Rectangular Node[待補連結]，被用來定義檢查室(triageRoom: ResourcePool[待補連結])的HomeNode。這部份需要專門篇幅兩解講。簡單地說，可以利用節點空間來定義資源的數量。目前檢查室宣告了兩個空間(rectangle3、rectangle4)，就是表示檢查室有兩間的意思。 nurseHomeRoom: 與前項意義同。被用來定義護士的資源數量。只是，這邊不是用空間數量來定義，而是直接使用數字。區域中有箭號的圖示是指Attractor，他可以設定3D圖的前方的方向。當然，也可用Attractor的數量來決定資源的數量。 邏輯流程 流程詳述(整合現場佈置與邏輯流程) 病患已經完成報到註冊程序，且被移往(gotoWaitingRoom1:  MoveTo )等候室(waitingRoom: space markup-Rectangular Node[待補連結])等待檢傷分類作業。 檢傷作業需由護士(nurse: ResourcePool[待補連結])引領至檢傷室(triageRoom: ResourcePool[待補連結])。所以，必須先確認這兩項資源是否有空閒。 確認同時擁有(seizeTriageRoom: Seize )護士與檢傷室這兩種資源後，則將病患與護士一同送往檢傷室(triageRoom's HomeNode: space mark...

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個病患。 若...

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長大的。這部份，我還是喜歡直接連外部資料庫，哈～這是與其他系統進...

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，是將新進...