Car Repair Shops - Pooling Inventory Across a City

96 views
Skip to first unread message

Ralph Asher

unread,
Sep 19, 2022, 3:36:34 PM9/19/22
to simmer-devel
I'm looking to code a discrete-event simulation for an upcoming project, and I don't know if I can use simmer because it's not a typical process simulation.  If Inaki or anyone else can provide some insight on the "art of the possible," I'd appreciate it.

Client is a chain of auto repair shops.  In a large city, they may have twenty locations, and they service a wide variety of makes and models.  In a given repair, there may be one or more repair parts required (out of hundreds of parts possibly needed in a repair).

In the simulation, cars arrive at the different repair shop locations (time-stamped) and each car has different repair part needs.  

If the location the car is at has the part, then the shop repairs the car, and puts in an order to a centralized warehouse to replenish the used part.   The part arrives from the centralized warehouse after a time, and are put into the shop's inventory.

If the location the car is at does not have the part, a shop worker searches the inventory of the other shops in the city.  If multiple shops have the required part, then a preference order is used to select the shop that will be used to transfer the part.  The part is transferred to the requiring shop, then the shop that the repair part was transferred from, will put in an order to the centralized warehouse.  The part arrives from the centralized warehouse after a time, and are put into the shop's inventory.

If no shops in the city have the required part, then the shop where the car went, puts in an order from the centralized warehouse.  The part arrives from the centralized warehouse after a time, and are immediately put into the car to repair it.

We treat the centralized warehouse as if it has infinite inventory.

Key to the project is to understand how pooling inventory across all the repair shops, will speed up time-to-repair as well as inventory levels.

I know this isn't a typical simmer project, but if I can use simmer I would definitely prefer to do so.  Thanks!

Iñaki Ucar

unread,
Sep 21, 2022, 4:16:44 AM9/21/22
to simmer...@googlegroups.com
On Mon, 19 Sept 2022 at 22:34, Ralph Asher <ralph....@gmail.com> wrote:
I'm looking to code a discrete-event simulation for an upcoming project, and I don't know if I can use simmer because it's not a typical process simulation.  If Inaki or anyone else can provide some insight on the "art of the possible," I'd appreciate it.

Client is a chain of auto repair shops.  In a large city, they may have twenty locations, and they service a wide variety of makes and models.  In a given repair, there may be one or more repair parts required (out of hundreds of parts possibly needed in a repair).

In the simulation, cars arrive at the different repair shop locations (time-stamped) and each car has different repair part needs. 

I believe this can be done with a single trajectory + generator of cars. At the beginning of the trajectory, you must generate some data and put them into attributes:
  1. The location identifier.
  2. The number of parts to repair.
  3. Identifiers for such parts in separate attributes.
If the location the car is at has the part, then the shop repairs the car, and puts in an order to a centralized warehouse to replenish the used part.   The part arrives from the centralized warehouse after a time, and are put into the shop's inventory.

Parts are resources for each location (so n_parts x n_locations). They are seized by the car (using the location id + the part id), decreased by one using set_capacity, then immediately released. Then there's a timeout modelling the repairing time. And this is done in a loop (using rollback), accessing the separate part attributes using the number of parts to repair until this is = 0.
 
If the location the car is at does not have the part, a shop worker searches the inventory of the other shops in the city.  If multiple shops have the required part, then a preference order is used to select the shop that will be used to transfer the part.  The part is transferred to the requiring shop, then the shop that the repair part was transferred from, will put in an order to the centralized warehouse.  The part arrives from the centralized warehouse after a time, and are put into the shop's inventory.

Before each seize, there should be a signal to a shop worker to check if there are parts missing and order them to the centralized warehouse. The worker trajectory models this process with the appropriate seize->set_capacity->release->set_capacity to remove a part from a shop and put it in the current one.
 
If no shops in the city have the required part, then the shop where the car went, puts in an order from the centralized warehouse.  The part arrives from the centralized warehouse after a time, and are immediately put into the car to repair it.

This is part of the worker's trajectory too.
 
We treat the centralized warehouse as if it has infinite inventory.

So we don't need a resource for this.
 
Key to the project is to understand how pooling inventory across all the repair shops, will speed up time-to-repair as well as inventory levels.

I know this isn't a typical simmer project, but if I can use simmer I would definitely prefer to do so.  Thanks!

I think it's very doable. It will be certainly easier if we implement this, to avoid the whole seize->set_capacity->release dance, but the latter achieves basically the same functionality.

--
Iñaki Úcar

Ralph Asher

unread,
Sep 21, 2022, 7:53:37 PM9/21/22
to simmer-devel
Thank Inaki.  The morning after I posted, I thought of a similar approach - but certainly not in this level of detail.  I had to deviate a bit from your recommendation but I think I have it working now.

Ralph

Iñaki Ucar

unread,
Sep 22, 2022, 5:38:16 AM9/22/22
to simmer...@googlegroups.com
Excellent. This is an interesting project. Please let us know your experience. ;-)

Iñaki

--
You received this message because you are subscribed to the Google Groups "simmer-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simmer-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/simmer-devel/7d4e2236-64b4-452c-a825-b52b699cac39n%40googlegroups.com.


--
Iñaki Úcar

Ralph Asher

unread,
Sep 22, 2022, 2:31:16 PM9/22/22
to simmer-devel
One enhancement request from this project:

When we add resources, we can reference a dataframe column for the names.  How about capacities? I have a dataframe of resources, each row represents one unique permutation of repair part, and shop.  (almost 700K rows).  The capacity represents how many units of that part, are on hand at that shop, at the beginning of the simulation.  Because these values aren't uniform, I have to add resources one at a time via a for-loop, which takes a long time.  It would be great to just reference a column name in a a dataframe for the resource name, and another column for the capacity, similar to how add_dataframe allows us to reference column names for arrival attributes.

Iñaki Ucar

unread,
Sep 22, 2022, 3:22:51 PM9/22/22
to simmer...@googlegroups.com
Good point. Currently, we don't have any means to add a dataframe of resources.

The add_resource method does support a vector of names for the same capacity, so for now you could group together all the resources with the same capacity and then add them in batches. That would hopefully speed things up if there are many repetitions.

In a next iteration, we could support a vector of capacities (and queue sizes) too, matching the length of the names. I'll try to implement this when I find some time. Tracking here: https://github.com/r-simmer/simmer/issues/288. Thanks for the suggestion!



--
Iñaki Úcar

Ralph Asher

unread,
Sep 22, 2022, 3:31:36 PM9/22/22
to simmer-devel
Thanks for the suggestion on grouping resources with identical capacities, as a batch - there are not all that many different on-hand quantities so that should speed things up quite a bit.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages