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

Realizace modelu v SIMPROCESS

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.

Model s umožněným "předáváním"

Activity Names	Entity Names	Absorption cost
LimoProdejCounter	limo	38030,00
UslyZiskCounter	clovek	10160,00
Total		48190,00

Model bez předávání

Activity Names	Entity Names	Absorption cost
LimoProdejCounter	limo	37410,00
UslyZiskCounter	clovek	7620,00
Total		45030,00

Další statistiky pro porovnání modelů

	Model s umožněným "předáváním"	Model bez předbíhání
Počet lidí, kteří vzdali čekání	1016	762
Průměrná doba obsloužení	0.117 hod	0.091 hod

Průměrná doba obsloužení v modelu s předáváním je 0.117 hod, v modelu bez předává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

</references>

• 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

Kód

File:Xsamm12 9resource.spm

Další soubory:

reporty SIMPROCESS

File:Xsamm12 StdRpt.zip