Fronty na občerstvení
Úvodní odstavec
Definice problému
Model by simuloval tvoření front u stánků na občerstvení, které je možné často vidět na hudebních festivalech a dalších kulturních akcích akcích. Nejdříve si lidé kupují 1 až 2 položky (limonády, pivo...) a fronta poměrně ubývá. Postupem času, nebo při určité kritické velikosti fronty začne docházet k následujícím jevům:
- Lidé stojící ve frontě víc vepředu začínají být žádáni, aby vzali občerstvení i pro kamarády, ale i pro cizí lidi. Může to být za úplatu př. “Kup nám 3 točené limonády a tady máš ještě na jednu navíc pro tebe” => to má za následek delší čekání lidí stojících vzadu. Obsluha jednoho člověka trvá déle hlavně v případě piva, kdy je jedna pípa a je třeba čekat na natočení např. šesti kelímků.
- Může se objevovat předbíhání
- Může dojít i ke kombinaci předbíhání a kupování více kelímků.
Účelem simulace je zachytit dynamiku tvorby těchto front a zjistit kdy začne být odbavení velmi pomalé. Výsledkem by mohlo být doporučení pro způsob jak zajistit rychlejší obsloužení zákazníků. Dále model může sledovat při jakém nastavení frontu je prodáno nejvíce občerstvení.
Metoda
Model by bylo možné realizovat jako multiagentní simulaci např. v Netlogo. Další možností je model simulovat jako proces v SIMPROCESS. První metoda by byla složitější na realizaci a vyžadovala by mnoho náležitostí "frontového" chování programovat. V SIMPROCESS je možné využít mnoho již vestavěných funkcí a velkou část simulace lze realizovat jen v editoru bez nutnosti programování. Na druhou stranu je v SIMPROCESS obtížnější realizovat některé věci, jako např. předbíhání nebo změnu chování čekajících na základě rostoucí nervozity či netrpělivosti.
Pro realizaci bylo nakonec zvolen SIMPROCESS také z důvodu snažšího zpracování výstupů z velmi podrobných reportů.
Model
Celá simulace běží 48 hodin, tedy dva festivalové dny.
Zrod - lidé se do modelu generují dle normálního rozdělení v intervalu počtu sekund: Nor(16.0,2.0,1)
Nervozita - určuje prahovou hodnotu, kdy pohár trpělivosti (žízně) účastníků fronty přeteče a rozhodnou se pro předběhnutí a nebo požádají někoho více vepředu aby jim koupil limonádu (předají mu peníze, dále tedy jen "předávající"). Počet entit Clovek který musí do brány přijít aby začala generovat předbíhající/prosící se řídí dle: Nor(50.0,20.0,1)
Dále je na bráně Nervozita přidán výraz Expression spouštěný při události Accept Entity. Výraz upravuje chování brány tak, aby při větších frontách u pípy začala častěji vpouštět dávky předbíhajících a předávajících:
IF Model.Odchodovost <= 0.4 TrigFutureRelCount := DrawIntegerSample("Nor(30.0,15.0,1)"); IF Model.Odchodovost <= 0.2 TrigFutureRelCount := DrawIntegerSample("Nor(20.0,10.0,1)"); END IF ELSE TrigFutureRelCount := DrawIntegerSample("Nor(50.0,20.0,1)"); END IF
DeleniPredbehnuti Pro zjednodušení modelu je uvažováno, že 15% lidí se rozhodne předběhnout, zbytek bude předávající. Pravděpodobnost větve vedoucí do prodlevy RozestupyDopredu je tedy 0.85.
RozestupyDopredu
Slouží pro rozprostření předávajících v čase (sekundy) dle rozdělení Uni(5.0,25.0,1)
KupovaniZaOstatni Brána slučuje požadavky lidí na limonády do dávek. Jeden sloučený člověk reprezentuje stojícícho ve frontě, který byl lidmi požádán o to aby jim koupil Limonádu. Brána se otvírá po dosažení počtu lidí dle rozdělení Nor(8.0,5.0,1).
Rozestupy Určuje náhodně rozestupy, tak aby byli lidé co kupují velké dávky limonád lépe promícháni s ostatními. Opět dle rozdělení Uni(40.0,90.0,1)v sekundách.
GetObsluha Zajistí obsazení zdroje Obsluha, to má za následek hromadění limonád v Aktivitě ObjednavkaDavka. Tímto způsobem se simuluje větší zaneprázdněnost obsluhy, když si jeden člověk objednává více limonád.
NatoceniHodneLimonad je prodleva počítající delší prodlevu při větší objednávce v sekundách dle Uni(10.0,30.0,1). Aktivita Platba pak uvolní zdroj Obsluha. Aktivita objednavkaCheck pak může pustit čekající dávku entit Limo do brány ObjednavkaDavka, kde se sloučí (batch) a umožní odchod čekajícího zákazníka (entita Clovek) na bráně Pipa.
Obsluha Generátor slouží ke vytváření entit Limo představujících limonády které obsluha neustále točí v počtu sekund dle rozdělení Nor(20.0,15.0,1). kPipeProsim slouží jako Trigger pro bránu Cekani, která vpouští čekající zákazníky (Clovek) k pípě, kde mohou být obslouženi. LimoProdejCounter slouží k počítání prodaných limonád, objednavkaCheck slouží k zadržení dávky limonád, pokud není volná kapacita zdroje Obsluha.
Brana Cekani slouží k tomu, aby bylo možné zajistit odchod lidí, kteří ztratili trpělivost čekat. Při příchodu signálu z kPipeProsim. Lidé se dělí na větvení OdchodNetrpelivych dle hodnoty globální modelové proměnné Odchodovost. Tato proměnná je nastavována pomocí výrazu na bráně Pipa :
IF NumberOnHold >= 10 Model.Odchodovost := DrawRealSample("Nor(0.5,0.4,1)"); IF NumberOnHold >= 20 Model.Odchodovost := DrawRealSample("Nor(0.4,0.3,1)"); END IF ELSE Model.Odchodovost := DrawRealSample("Nor(0.6,0.1,1)"); {OUTPUT("Odchodovost 1"); } END IF
UslyZiskCounter počítá možné ušlé zisky lidí, co opustili frontu, jedna limonáda má cenu 10 jednotek.
Výsledky
Pokud je v modelu umožněno předbíhání je zisk z prodaných limonád větší (38030 oproti 37410) ale výrazně vzrostou také potenciální ztráty 10160 oproti 7620.
Activity Names | Entity Names | Absorption cost |
LimoProdejCounter | limo | 38030,00 |
UslyZiskCounter | clovek | 10160,00 |
Total | 48190,00 |
Activity Names | Entity Names | Absorption cost |
LimoProdejCounter | limo | 37410,00 |
UslyZiskCounter | clovek | 7620,00 |
Total | 45030,00 |
Počet lidí, kteří vzdali čekání
'''Model s umožněným "předáváním" a předbíháním''' Neobslouzeni clovek 1016 '''Model bez předbíhání''' - Neobslouzeni clovek 762
Průměrná doba obsloužení v modelu s předbíháním je 0.117 hod, v modelu bez předbíhání je to 0.091.
Závěr
Výsledky jsou poměrně překvapující. Pokud je umožněno předbíhání a předávání, prodá se více limonád ale více lidí také odejde z fronty. Při zakázání předávání a snížení prevalence "skupinových" nákupů je sice odbavení plynulejší ale nedojde k využití plného potenciálu obsluhy. Zvyšování intervalů mezi vlnami skupinových nákupů vede do překročení určité hranice k růstu počtu prodaných limonád a ale také rapidnímu růstu potenciálních zisků (UslyZiskCounter). To je možné učinit např. změnou rozsahu rozdělení v aktivitě Rozestupy. Nastavení rozestupů, tak jak je popsané v části Model se poměrně blíží optimu. Vzhledem k tomu, že v trial verzi SIMPROCESS nelze realizovat Experimenty a parametry modelů nelze měnit tak snadno jako např. v NetLogo je hledání optimálního nastavení prodlev a hromadných nákupů obtížnější.
Mým závěrem tedy je, že výskyt skupinových nákupů nemusí být nutně nežádoucím jevem, pokud nepřekročí určitou kritickou hranici. V mém modelu je to zhruba rozmezí vln skupinových nákupů v sekundách: Uni(40.0,90.0,1)
Otázkou je, zda se výsledky mohou shodovat s realitou. Pokud lidé kupují víc nápojů najednou, obsluha může ušetřit čas při přijímání plateb i objednávek. To je znatelné zejména pokud je obsluhující jeden (zároveň točí a zároveň přijímá platby a vrací). Výsledky modelu však spíš ukazují na efektivitu spojenou s četností odběru kontinuálně natáčených limonád.
Reference
- http://www.yousimul8.com/search.php?search_text=queue&x=0&y=0
- http://www.yousimul8.com/search.php?search_text=row&x=0&y=0
- http://en.wikipedia.org/wiki/Queueing_model