# Coffee Shop Proof of Concept
###### tags: `math-spec-mapping`
## Problem Summary
The following is a proof of concept for the math spec where we try to work through what a coffee shop model might look like.
<b>Problem Summary: You run a coffee shop and want to optimize your schedule of baristas to make sure queue length is not too long but you also do not spend too much money. Every epoch a certain amount of customers come in and a certain amount can be served. Anyone not served is waiting in line.</b>
## Types, States, Parameters & Entities
### Types
Primitive Types
1. USD = Float
2. Time = Datetime
3. consumers_served = Int
4. number_baristas = Int
5. consumer_id = Int
6. delta_time = Delta Time
7. number_consumers = Int
Derived Types
1. Currency = USD
Compound Types
1. barista_schedule: Dict[Time, number_baristas]
### State
System (Global) State
```
{"name": "System State",
"notes": "The system-wide state",
"variables": [{"type": TimeType,
"name": "Time",
"description": "System clock",
"symbol": "T",
"domain": "12AM-11: 59PM"}]}
```
Coffee Shop State
```
{"name": "Coffee Shop State",
"notes": "There should be only one instance of this state in a simulation",
"variables": [{"type": number_baristas,
"name": "number_of_baristas",
"description": "The current number of baristas on staff",
"symbol": ,
"domain": },
{"type": List[Consumer],
"name": "queue",
"description": "The queue of customers",
"symbol": ,
"domain": },
{"type": consumers_served,
"name": "customers_served",
"description": "The number of customers served in an epoch",
"symbol": ,
"domain": },
{"type": Currency,
"name": "wages_accrued",
"description": "The amount of wages that are accrued in an epoch",
"symbol": ,
"domain": }]}
```
Consumer State
```
{"name": "Consumer State",
"notes": "There will be 0+ of these states, based on queue length",
"variables": [{"type": consumer_id,
"name": "id",
"description": "The id of the customer, must be unique",
"symbol": ,
"domain": },
{"type": delta_time,
"name": "time_waited",
"description": "The time the customer has waited, init at 0",
"symbol": ,
"domain": }]}
```
### Stateful Metrics
System Stateful Metrics
```
{"name": "Global Stateful Metrics",
"notes": None,
"metrics": [{"type": delta_time,
"name": "time_passed",
"description": "state['current_time'] - params['start_time']",
"variables_used": ["current_time"],
"parameters_used": ["start_time"],
"symbol": ,
"domain": }]}
```
Coffee Shop Stateful Metrics
```
{"name": "Coffee Shop Stateful Metrics",
"notes": None,
"metrics": [{"type": number_consumers,
"name": "queue_length",
"description": "len(state['queue'])",
"variables_used": ["queue"],
"parameters_used": [],
"symbol": ,
"domain": }]}
```
Consumer Stateful Metrics
```
{"name": "Consumer Stateful Metrics",
"notes": None,
"metrics": []}
```
### Parameters
Coffee Shop Parameter Set
```
{"name": "Coffee Shop Parameters",
"notes": "Any parameters specific to the coffee shop",
"parameters": [{"variable_type": Currency,
"name": "employee_cost",
"description": "The $ cost per employee per hour"},
{"variable_type": barista_schedule,
"name": "barista_schedule",
"description": "A schedule of the number of baristas on shift at each time"}
]}
```
General Parameter Set
```
{"name": "General Parameters",
"notes": "Any general parameters on the system",
"parameters": [{"variable_type": time,
"name": "start_time",
"description": "The start of simulation time"}]}
```
### Entities
Coffee Shop
```
{"name": "Coffee Shop Entity",
"notes": "Only one in system",
"state": "Coffee Shop State"}
```
Consumer
```
{"name": "Consumer Entity",
"notes": "Multiple can be in system",
"state": "Consumer State"}
```
## Actions, Policies, Mechanisms
Behavioral Actions:
1. Distribution of serving time: the behavioral action that takes into account how many customers can be served given number_of_baristas
- Example 1: Sum of number_of_barista poisson distributions with mu = 1.
2. Distribution of customers coming in: The distribution of customers that get added in an epoch:
- Could be random all the way through
- Could be time varying
- Could come from a signal creation library
- Example 1:
- Assume that store hours are 6AM - 8PM.
- Between 6AM-9AM -> Poisson(1/3)
- Between 9AM-4PM -> Poisson(1/2)
- Between 4PM-8PM -> Poisson(1)
System/Control Actions:
1. Shift switching: An action that checks if we are at an hour where the number of baristas is different, and if so is passing a message for the policy of Modify Number of Baristas
2. Accrue Wages: An action that each epoch checks the number of employees and sends a message to pay employees to accrue what amount needs to be paid
3. Update Current Time: Meta step that simply passes to "Adjust Current Time" mechanism for updating what the current step
### Policies
1. Modify queue: given the inputs from the behavioral steps of serving + customer arrival, is calling mechanisms of "Update Queue Length" and "Track Customers Served"
2. Pay employees: Policy which takes the parameter of employee_cost and figures out what wages are accrued, calls the mechanism "Add Wage Accrual"
3. Modify number of baristas: Policy which possibly is calling the mechanism "Change Shift"
Mechanisms:
1. Update Queue Length: Mechanism which changes the length of the current queue
2. Track Customers Served: Mechanism that logs how many customers were served
3. Add Wage Accrual: Mechanism that updates the state for the current wages_accrued
4. Change Shift: Mechanism which changes shifts and modifies number_of_baristas
5. Adjust Current Time: Mechanism which changes the state for time.
## Metrics & KPIs
Metrics:
1. Average length queue: AVG(queue_length) over simulation
2. Total Employee Cost: SUM(wages_accrued) over simulation
3. Total Customers Served: SUM(customers_served) over simulation
4. Cost Per Customer: Total Employee Cost / Total Customers Served
KPIs:
1. Minimal/Low Queue Length: Average length queue < C
2. Minimal/Low Cost Per Customer: Cost Per Customer < C
Overall system success: 1 & 2 (both true)
Sign in with Wallet
Connect another wallet