進階模型：醫療業-Emergency Department-Part 2-邏輯流程-檢傷分類

本篇是接續上一篇進階模型：醫療業-Emergency Department-Part 2-邏輯流程-註冊報到。
==========

流程簡述

  1. 病患已經完成報到註冊程序，且被移往等候室，等待檢傷分類作業。
  2. 檢傷作業由護士引領病患至檢傷室。
  3. 確認同時取得護士與檢傷室這兩種資源後，則將病患與護士一同送往檢查室。
  4. 進行檢傷作業。
  5. 完成檢傷後，離開檢傷室。
  6. 仍由護士將病患移往等候室。

現場佈置


  1. waitingRoom: 完成報到手續者，將被移動到此區域，等待檢傷分類流程。完成檢傷分類的病患也會回到此區域，等待處置作業流程。使用 space markup-Rectangular Node[待補連結]。
  2. rectangle3、rectangle4: 這兩個space markup-Rectangular Node[待補連結]，被用來定義檢查室(triageRoom: ResourcePool[待補連結])的HomeNode。這部份需要專門篇幅兩解講。簡單地說，可以利用節點空間來定義資源的數量。目前檢查室宣告了兩個空間(rectangle3、rectangle4)，就是表示檢查室有兩間的意思。
  3. nurseHomeRoom: 與前項意義同。被用來定義護士的資源數量。只是，這邊不是用空間數量來定義，而是直接使用數字。區域中有箭號的圖示是指Attractor，他可以設定3D圖的前方的方向。當然，也可用Attractor的數量來決定資源的數量。

邏輯流程

流程詳述(整合現場佈置與邏輯流程)

  1. 病患已經完成報到註冊程序，且被移往(gotoWaitingRoom1: MoveTo)等候室(waitingRoom: space markup-Rectangular Node[待補連結])等待檢傷分類作業。
  2. 檢傷作業需由護士(nurse: ResourcePool[待補連結])引領至檢傷室(triageRoom: ResourcePool[待補連結])。所以，必須先確認這兩項資源是否有空閒。
  3. 確認同時擁有(seizeTriageRoom: Seize)護士與檢傷室這兩種資源後，則將病患與護士一同送往檢傷室(triageRoom's HomeNode: space markup-Rectangular Node[待補連結])。
  4. 進行檢傷作業(triage: Delay)。
  5. 完成檢傷後，離開檢傷室。亦即釋放(releaseTriageRoom: Release)檢傷室這項資源。
  6. 在將病患移往(gotoWaitingRoom2: MoveTo)等候室(waitingRoom: space markup-Rectangular Node[待補連結])。
  7. 下一流程：處置作業[待補連結]。

元件屬性

1. seizeTriageRoom：Seize

    這個元件是用來幫Entity抓取資源。資源設定需要專篇討論。
  1. 設定如何抓取資源與數量。若只會抓一種資源，只是數量不同時，就是第二個選項。若要抓不同資源，且個別有不同數量時，則要點選第一個選項。
  2. 本案例是設定資源集。這塊有點複雜，也只有在前項選擇resource sets時，才會出現。這個是可以設定各種資源配對組合。本案例比較單純，只要有房間有護士各一個就好。如果，原始要求是說兩個護士與一個房間的這種資源組合。但沒有兩個護士時，有一個護理長也可形成一個資源組合。此時，你要決定哪一種組合為優先，List中排在前面者，只要條件符合就執行。
  3. 抓資源的策略。本案例是房間與護士必須同時抓取，若少其中一個，就不會成立。沒有任何資源會被佔用。但是，選擇第二個選項時，只要某一資源符合條件（有空閒），就會被抓取，這個資源被佔用了。但是整體條件未滿足，Entity並不會不釋放到下一個元件。
  4. 若注意看Seize的圖示，他也有一個Queue。主要是前項的設定，到底能接受幾個Entity是站著茅坑不拉屎的。
  5. 被抓到的資源是否要移動之。這要注意，能夠被移動的資源必須是被設定為Moving或P ortable。不可以為Static。像房間就是被設定為Static資源，所以，就算是這邊設定要移動資源，房間還是不會被移動。那Moving與Portable的差異呢？一個是自走(Moving)，一個要人牽(Portable)。
  6. 有前項選擇要移動，這個屬性才會出現。那要把資源移到哪裡去呢？本案例是將資源移到Entity處。此時就看Entity在哪裡。也就是說，護士會去等候室找到那個搶得資源的病患。這邊留下一個伏筆，若抓取政策是有就先抓的話，那病患離開可能就不會是你想像在Queue中的順序。要小心。
  7. 那被移動的資源，要不要跟Entity綁在一起。護士是自走型，故需要設定綁在一起，那這個護士資源才會與病患Entity走在一起。其實，這邊還有一個問題未解，綁在一起了，那走路是要算誰的速度呢？哈～要搞這個複雜，動用程式是免不了的。

2. gotoTriageRoom: MoveTo

  1. 無特殊性，跟之前的類似。把Entity移到triageRoom，只不過這邊是指定移動到這個Entity所抓取到的那一間triageRoom。

3. triage: Delay

無特殊性。

4. releaseTriageRoom: Release

    這個是幫Entity釋放資源用。釋放資源也不是想像中簡單，能設定的屬性不多，但選項很多，也就是說，得搭配實務情況來選擇。(這已不是技術問題，而是經驗問題)


  1. 選擇要釋放什麼(哪一個)資源。本案例是說要釋放特定的資源。
  2. 因為前項是選擇要釋放特定的資源型態，所以這邊可選擇資源。選這個要注意，此時若Entity身上有兩個以上相同此類型資源，那都會被同時釋放。這句話的另一個意思是說，我們可以設定要釋放幾個。若再加上程式的輔助，想想就多有趣。
  3. 此資源被釋放後，資源要去哪裡。本案例是讓此資源回到他的老巢(Home Node)，注意唷，若這個資源是Portal，他是沒有辦法自己回去的，你可能需要呼叫另一個資源來幫這個資源移回去。我被這個搞得很慘。例如棧板是有限資源，用完要歸還原處，但是，他不會自己移動呀，需要呼叫另一個堆高機來使用。問題來了，若用原本思維，在主流程中呼叫推高機，抱歉，那不是棧板呼叫的，而是Entity叫用的，會出錯的。講到這有感覺的人，恭喜了。問題是，推高機不會自己動呀，最後還是需要呼叫堆高機司機來開這台推高機。先不管呼叫的方式，光是釋放就是一門學問。資源不是隨便釋放的，要注意順序性。
  4. 設定使用這個資源時，是否有暖機時間。原則上是指回到老巢的使用。但是，有些可能需要充電呀，這時候就要給定一個時間函數了。
5. gotoWaitingRoom2: MoveTo


無特殊性。讓Entity回到等候區。

留言

張貼留言

這個網誌中的熱門文章

等候理論

圖片
等候理論( Queueing Theory )是非常實用且生活化的東西。生活周遭都有他的身影，舉凡你要排隊等著別人服務的事物都是，只是你沒有從作業研究或數學的角度來審視他而已。 這邊太學術的東西，我也談不起。只從系統模擬的角度切入，也先強調一下，等候理論只是系統模擬在離散事件或流程模擬中所需要的基礎。下圖是最基本的結構圖。 圈圈是代表提供服務的個體，注意，他並不一定是個人，像ATM也是一個提供服務者。 這個服務者就會衍生出一堆的問題，基本資料類，一次能服務多少人(還是要強調一下，接受服務的不一定非得要人)，每次服務要多久時間。資料分析類，他的產能是多少，要的效能是多少，他的稼動率是多少。 這邊再補充一下，一個提供服務者被佔用，但並不一定代表他都在認真工作中。所謂的被佔用的概念，就是這段期間內，他不能夠提供給其他人服務。這段期間內，他也有可能在等待被服務者所需要的一些前置作業等。總之，實務情況如何，就算是很複雜，模擬系統的模型都得想辦法實踐出來。 像是樓梯的圖形就稱之為等候線，或者是等候區。兩者是有差異，等候線是不抽號碼牌，先來先排隊，由被服務者端決定順序；而等候區是抽號碼牌的，服務順序是由提供服務者來決定。這個等候線/區也會衍生很多問題。基本資料類，例如他的容量是多少，也就是說能排幾個人，能排多長，能等多久；可否插單。資料分析類，平均要等多久才能被服務到，一條等候線上大概會有多少人。 等候線/區左方箭號的部分就是指被服務者進來的方向，而提供服務者右方的箭號代表被服務者離開的方向。 被服務者也會衍生出好多問題，基本資料類，多久會來一個，或者是說，間隔多久會有一個。「平均多久來幾個」有學問一點，這叫做Arrival rate；「平均間隔多久來一個」有學問一點，這叫做Interarrival time。這兩者是一般初學系統模擬者，常常會搞混的東西。從單位角度比較好理解。注意，既然說平均就不會是剛好。 「平均多久來幾個」白話一點就是說每分鐘平均來1個人，單位是1人/分鐘。 「平均間隔多久來一個」白話一點就是說平均一分鐘會來一個人，單位是1分鐘。 希望這張圖能有說幫助。 以上講的是指一個「單元」的概念，有「來源」、「等候」、「服務」、「離開」等四個元素所組成。 實務上就會有很多種單元組合與元素組合的變化，也就是等候理...
閱讀完整內容

AnyLogic簡單介紹

圖片
AnyLogic是目前模擬軟體中，唯一同時支援系統動力學、流程導向模擬與代理人模擬之產品。也因為如此，他可以涵蓋的應用範圍就相當廣泛。工業工程、供應鏈管理、人力資源、市場調查、策略規劃等，都可以利用AnyLogic達到預期之目標。從AnyLogic官網的圖中(圖 1)，可以理解其應用範圍。 圖1：AnyLogic應用範圍(來源：AnyLogic官網) 另外，本產品還有一個特色是採用Java 程式語言開發，並利用Eclipse Java開發平台為基礎所建置。這也使得AnyLogic可以在Windows, Mac與Linux等不同平台中使用。也可以產生Java applets，然後在不同平台上的瀏覽器中執行。（註： Chrome不再支援NPAPI，使得無法執行applets） 在系統整合的部分，AnyLogic也有很好的表現。可銜接GIS地圖資料，也能夠匯入CAD圖檔當作底稿，作為布置圖用。也可匯入其他3D模型，變成模擬3D物件，可以美化或更貼近模擬需求的情境。也可與最佳化組件或與分配最適性工具整合。也可與大部分的資料庫系統整合，可處理文字檔或XML檔。其整合能力請參考圖 2。 圖2：系統整合能力 官網：https://www.anylogic.com/
閱讀完整內容

機率分配 - Part 6 Poisson

圖片
Poisson分配在系統模擬中是非常重要的機率分配函數。因為，他確切與時間有關係。你要說他很難，還真難。有人喜歡把他跟 二項分配 ，或超幾何分配等有得沒有的作比較與轉換，這跟系統模擬無關，系統模擬要的是情境，要的是歷史資料。也就是說，情境符合命題，然後歷史資料看看顯不顯著，再經過「嚴謹」的適合度檢定，沒有什麼重大意外，就用吧。怎麼說呢？歷史資料不是母體，既然不是，就會有偏差。既然有偏差，你要怎麼知道這個偏差是哪兒發生。搞不好一開始你的抽樣就不對了，樣本根本無法代表母體。後面作一堆，都是作辛酸的。要不就是發表論文用，這兒不搞這。系統模擬最終成果也是資料，由自己產生的資料來驗證模型的正確性，所以，需要兩階段。這篇 發展模擬系統之五大循環  約略有提到這個概念。 先來看看命題，在單位時間內，發生成功事件的次數。滿足Poisson的條件有三個： 條件 (i)表示在時間 0 時，成功次數是 0。  條件(ii)說在互不相交的時段 (time intervals) 內的試行是相互獨立的。  條件(iii)說只要時段長度相同， 不同時段內成功次數有相同的機率分佈。 你可想像自己在坐在咖啡店內，透過櫥窗向外看。每五分鐘(單位時間)內，去算一下有幾台車經過。每五分鐘就要重新起算。若你每天早上同一個時段都來觀察收集資料，你會得到面前這條馬路的車流量，他會服從Poisson分配。而問題在ℷ是多少。好吧，簡單的說，如果你收集到的每五分鐘的車輛數，推估母體的平均數，這個ℷ就是平均數。想要有感覺，請參考 等候理論 這篇講到的到達率。 來看機率分配函數與累積分配函數之公式吧。 這公式不好懂(計算)了吧。唉～誰叫你有手算勒。在已知ℷ的前提下，要問單位時間內，車子通過x=0的機率是多少，通過x=1的機率是多少，通過....。 想一下，系統模擬要什麼。我要的是x呀。單位時間內，透過Poisson讓我取得來客數。到底會有幾個人，我不知道，隨機，一切隨機。(抱歉，又來了) 還是來看累積分配函數的圖，更有感覺。看資料的長相，勝過公式計算。 在系統模擬中，雖然設ℷ為3，但是取得2或4的結果，都不用太驚訝。若取得-1個，那才值得驚訝。因為，一切到0為止。到目前為止所講到的機率分配函數都是到0為止（繞口）。需要得到負數值的，就得使用其他機率分...
閱讀完整內容