元件詳解：離散事件 - 流程模型 - MoveTo

MoveTo是經常用元件，但從「邏輯流程」的角度，他不是重要元件。他的主要功能是讓Entity在NetWork中能「合理」的流動。也就是說，沒有這個元件，模型仍然可以跑，只是2D或3D的視覺中，Entity可能會用很奇怪的方式冒出來或移動。至於會如何呈現，端看各元件有無設定Entity的Location。
透過MoveTo，可以讓Entity在NetWork中的兩個Nodo間移動，且依據Path[待補連結]連結情況與此元件所設定的速度或時間方式。
另外，他還有一個非常重要的用途，就是移動Entity在兩個AgentType之間的NetWork。別忘了Main也是一個具有NetWork的Agent Type。你也可以自己創造一個Agent Type且擁有自己的NetWork。雖然是兩個Agent Type的NetWork，實際執行時，還是疊在同一個座標系統中。這兩個NetWork是無法畫一條Path，讓Entity流動。此時，必須使用MoveTo設定成Jump來移動。但是，這有一個前提，分屬兩個NetWork的Node必須在座標空間(2D)中重疊
，並不需要大小一致，只要有重疊到即可。

配對元件

無

類似元件

  • ResourceSentTo：MoveTo是用來移動Entity的。而ResourceSendTo則是用來移動Moving或Portable類的資源。

屬性

這個元件的屬性有點麻煩。會因為某欄位的選項不同，而冒出不同的欄位要填資料。

基本型

這是叫用此元件時，最基本的屬性要求。

  1. 決定移動Agent的目的。第一選項是在同一個NetWork，第二個選項是跨不同Agent Type的NetWork。注意，若選擇第二個選項，則編號5的屬性不會出現。編號6僅剩下Set agent's speed，勾選就可設定Entity移動的速度。
  2. 選擇移動目的地的定義方式。這個會連動到編號3，4，5的欄位需求。預設是Network /GIS Node。選擇Network/GIS上的某一個節點。
  3. 若2選擇Network/GIS Node，則需要選擇目標節點。
  4. 勾選此項，可設定位移座標，更精準表達位置。
  5. 勾選此項，則是要求Entity可不依照Path路徑前進，採最短路徑。說最短路徑也不對，其實是採兩點一直線的方式。
  6. 設定Entity移動速度的參考方式。有兩個選項(1) 用Entity的預設速度跟NetWork上的距離，來得知移動所需的時間。(2) 直接設定移動所需時間，然後看NetWork上的距離，來取得Entity速度。當然，這邊也可直接重新定義Entity的移動速度。
以下就針對編號2的選擇不同，進行個別的欄位描述。如果已經重複的部分，僅留編號不作解釋。

1. Network / GIS node

   即基本型。

2. Attractor

  1. 選擇Attractor。
  2. 在NetWork中，選擇指定要移往的Attractor。也就是去到一個固定的位置。

3. Seized resource unit

  1. 選擇Seized resource unit。用這個要注意，前面必須要有一個Seize元件，已經讓Entity抓取得Resource。
  2. 指定是什麼類型的資源。注意，若Entity並無抓取得這邊定義的資源類型，此MoveTo元件不會作用。若有抓取到，這時候就看，這個Resource目前在什麼位置上，此Entity就會移過去。一般而言，抓取Static的資源(房間，尤其是有好幾間時)，都會用這個方式把Entity移到他抓取到的那一個資源。

4. Home of seized unit

  1. 選擇Home of seized unit。用這個要注意，前面必須要有一個Seize元件，已經讓Entity抓取得Resource。
  2. 指定是什麼類型的資源。所有Resource在Network中，都會定義一個Home Node，也就是模擬起始時，這個Resource要在哪裡出現。前者是將Entity移到抓取到Resource的現在的位置。這個則是將Entity移到動到此Resource的原始位置。應用情境是此資源必須「歸還」的概念，要透過「櫃台」才能夠領取。

5. Agent / unit

  1. 選擇Agent / unit。
  2. 要將目前的Entity移動到哪一個Entity處。這個就得靠程式去找到那個Entity。一般而言，是有配對結合的概念。這邊要補充說明，稍具規模的模型，Entity不會只有一種Agent Type（這類Agent Type不會有NetWork）。有些加工件就是需要某一種特殊的模具。當然，你可以設計成模具是資源。但設成資源時他沒有生死的概念，有些情況，模具本身就是有生死(使用期限)，要抓的生命週期時，就要設成Entity。設成資源只能抓使用率。

6. (x, y, z)

  1. 選擇(x, y, z)。
  2. 給定座標位置。注意，AnyLogic是採3D座標系統，原點在左上角。X往右為正，Y往下為正。Z往前(接近使用者)為正。

7. Node +(x, y, z)

  1. 選擇Node + (x, y, z)。
  2. 選擇Node當作原點座標。
  3. 設定以前項的Node的左上角當原點，設定x, y, z的位置。這是確保這個Entity移動時，一定會在這個Node裡面。

8. (latitude, longitude)

  1. 選擇(latitude, longitude)。
  2. 直接給定經緯度。這個是用在GIS模型。一般在Supply Chain類的模擬才會用到。


9. Geographic place



  1. 選擇Geographic place。
  2. 設定此地理位置。沒用過，不好多說。

留言

張貼留言

這個網誌中的熱門文章

等候理論

圖片
等候理論( 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為止（繞口）。需要得到負數值的，就得使用其他機率分...
閱讀完整內容