Supply Chain Simulation Tutorial
This tutorial introduces the concepts used in the Amalgama Platform and contains several parts:
-
In Part 1, a console application is created to run a basic scenario analysis.
-
Part 2 gives an introduction to graph-related features of the Amalgama Platform.
-
During Part 3, a desktop application is created, where the simulation code from the previously created console application is reused.
-
In Part 4, we show how to create a web service to run a simulation.
-
In Part 5, the web service is updated and a frontend application is added; the simulation is run via a web browser.
After each step, a working example project is created.
1. Problem definition
We will model a supply chain system: trucks transport cargo from warehouses to stores. We will use the term 'asset' to refer to both a warehouse and a store.
When a new transportation request appears, a free truck is chosen to take it. If requests appear too often, they are placed in a queue to be processed later. Requests have equal priority and are processed in the order in which they appear in the system. A transportation request does not 'expire': once created, it must be fulfilled, sooner or later.
Truck moving cargo between assets is considered busy. As soon as the delivery is over, the truck is free to take the next request. Truck is always available for a new transportation whenever it does not already participate in one. That is, there are no unavailability periods for trucks. Any truck can work with any request: at max one truck per transportation request and at max one request per truck.
All expenses are truck-related. Each truck is charged $10/hour (ownership cost), plus $25 per each hour when it moves (with or without cargo).

2. The goal of simulation
The simulation model should facilitate the decision making about the optimal number of trucks we need to perform the cargo transportation.
To find out what the term 'optimal' means, we need to look at the inputs (what we give) and outputs (what we get) of our system. As an input, we pay money to let the trucks run. These costs include ownership, maintenance, labor, etc.
In return we get the cargo transported. This is the output of our system, it can be measured as the fraction of transportation requests that have been fulfilled in time, otherwise called 'service level'.

The more trucks we employ, the more transportation requests will be done in time at the cost of more expenses, and the reverse is also true. We can combine both the service level and the truck-related costs into a single target indicator: costs per % of service level.
So, the goal will be to find the 'optimal number' of trucks that gives the lowest expenses per % of service level.