Model Building with Markdown
Last updated
Last updated
This video explains how to use Aidos's markdown-based model editing:
Aidos's markdown-based editing allows for quick editing with real-time model validation to streamline the process.
In the editor, each section is easily distinguishable with their headers being placed inside of brackets. For example, the model below has three sections: [Buffers], [Constraints], and [Links].
Here, the [Buffers] and [Constraints] sections serve to define all of the nodes within the model, as well as their types. The [Links] section defines how the model flows from node to node.
The most descriptive node definition involves declaring the node name, followed by a colon and the node description. In the block above, that would mean that the first node is named b1, and its description is Buffer 1. This way you can give shorthand names to your nodes to make linking them in the Links section easier. You will see that the model preview to the right populates the nodes with their description.
Alternatively, you can opt for just one of either the description or name for the node, such as changing b1 to buffer1 and removing the description, or removing the description from node b2 as seen below:
If opting to just use the description as the node name, spaces cannot be used and the description must start with a lowercase letter.
It's also worth noting that if you forego adding a description, the preview on the right will simply just label the node with its name instead.
To add nodes to the model, simply add lines to the markdown and define them in each section similar to the example, and then make sure they are connected to something in the [Links] section at the end. If a node is not connected via the [Links] section, the model preview on the right will warn you that the node must have a target or source. For example, the following block will validate correctly with the new nodes, as they are present in [Links]:
This video explains how to use splits and merges:
Splits and Merges are used to either create or consolidate multiple paths in Aidos Performance Predictor.
To create a split in our model, we first have to add a node to the [Splits] section, and then create additional nodes to be used at this split. Using the example from before, let's say that we have two different machines that material can flow to after the In-Process Materials node. We will add a 4th [Buffer], as well as a 3rd [Constraint] so that the [Split] flows into both Constraint 2 and Constraint 3, which each respectively flow into Buffer 2 and Buffer 4:
Remember that the model flow must end in a [Buffer].
Adding [Merges] is similar to adding [Splits]. The main difference between the two is that [Merges] can have multiple [Links] going into them, while [Splits] have multiple [Links] going out from them.
For our example, let's make it so that after Split 1 flows into Constraint 2 and 3, it then merges together before flowing into Buffer 2. We will also need to remove Buffer 4 since we do not need that in this example anymore:
This video explains how to use units and conversions:
Sometimes, certain sections of our model require specific units to better represent a process.
We can work off of the example we just created in the Splits & Merges section. First, let's go into Buffer 1 and change our Output Units to Pounds. After doing so, clicking into downstream nodes will show that they have also adopted the unit.
If we want to change units further down the line, we must add a [Conversion] node. Let's add a [Conversion] u1 after [Buffer] b3 and before [Split] s1:
If we click into our [Conversion] node u1, we can assign it a conversion factor of 2 and name the new unit to FinishedProducts. Note that units cannot have spaces in them. After doing so, you can see that just like before, the unit for FinishedProducts will populate to the downstream nodes in our model.
This video explains buffers:
Buffers are places in the process where material can be stored. They can be the start or end nodes in the process of material, and can even collect the outputs after processing. Within the model, they can be used to handle material surges if upstream processes are running faster than downstream or to prevent starvation if the reverse is true and the upstream begins running slower than the downstream.
Within Aidos, we can edit buffer settings in two different places. The first is one we have seen before in our Units and Conversions demo, where we just need to click the buffer itself and can edit the capacity, initial level, and units.
Capacity is the maximum number of units that a buffer can hold. Generally, starting and ending buffers have a capacity set to infinity. In-line buffer capacities can be set to match your real life process, or you can use Aidos's built in functionality to determine optimal buffer size; this feature will be discussed in the future when going over the different types of experiments you can set up in Aidos.
The Level is the amount of units present in the buffer at the start of model runtime. This can help the model reach a steady state faster whenever doing a new run, and is a more realistic simulation of l lines that don't clean out buffers between runs.
If you want to edit all the buffers at once, you can click the Buffers tab on the left, and it will show you all 3 fields for every buffer at once.
Let's start with the following example:
Clicking on a constraint in the node view shows only one editable setting: the limit. The limit is the maximum rate that a constraint can handle. If we click on [Constraint] c1 in the example above, we see that it is set to handle 1 pound per some unit of time.
Clicking on the Interrupts button below will take us to a different view with more information. Interrupts are the reasons that a line stops. To add interrupts to the model, we can either import them from elsewhere like from Aidos's own Wishbone tool, or manually from directly within the application via the Add Interrupt button. Interrupts can be removed via the button all the way to the right of them.
We have a few different settings for Interrupts. You can provide descriptive names for the interrupts to make it easier to interpret how they affect the results of the simulation. For the Interrupt Type we have three options: Wall Clock, Uptime - Competing, or Uptime - Cumulative; we will go over these in more detail in a later video. For Uptime Distribution, we currently have seven available options; we will also go into them in more depth later, or you can read about them more on our website at https://resources.chiaha.ai/.
The next four fields are parameters for the Uptime Distribution. The Downtime fields we see next mirror the Uptime fields, but downtime is how long it takes to fix the failure and get the process running again. We also have the Downtime Max, which is the maximum length of a downtime. The Restart Probability is the chance that there will be a random factor that causes the remediation process to restart, extending the downtime.
Just like we saw with [Buffers], you can also use the dropdown at the top left to navigate to the Constraints tab, allowing us to see these fields for all of the constraints in the model.
For this demo on the different experiments available in Aidos, we will be using the Hummus Demo file below:
After loading the file, you can go to the Experiments tab via the "Experiments" button at the top of the screen. On this page, you can add or delete various experiments, and select the experiment you want to run at a given time. Our demo file comes preloaded with one of each of the four available experiment types in Aidos.
Each experiment will have a Name, Seed, Duration, and Start Time. Name is where you can enter your description for the experiment. The Seed field is there so that you can avoid the inherent randomness of simulations and guarantee that subsequent runs will show the same results. Duration is how long the simulation will run for, and can be specified in units of days, hours, or minutes. Start Time is when the experiment starts; this does not affect the results of the experiment, but can give you a good frame of reference.
The first type of experiment (Experiment 0 in our demo file) is a Single Run experiment; this is a simple, single pass through the simulation for the chosen duration. It's a nice experiment to run to ensure your model is set up correctly and quickly get results. You can run an experiment either by clicking the Run button below the Experiment Parameters in this page, or at any time by pressing the Run button at the top of the window. Let's run Experiment 0 now.
Each experiment run will have an analysis page with various tabs for System Analysis. The Production Summary shows things like the System OEE, as well as the throughput and availability at each node. A Single Run Experiment has a Production Chart which can be viewed in granularity of weekly, daily , or hourly. Each experiment also has a Constraint Summary and Interrupt Summary table. Lastly, there is the Consolidated Line Events option that includes all of the line events.
If we go back to our Experiment tab, we can look now to Experiment 1. This experiment's type is a Multi run, which is multiple Single Run experiments averaged together. Multiple Run experiments are often done to increase the confidence in results. We can see that this experiment type has the additional Replications parameter, which is just how many single run experiments we want it to perform and average.
If we run Experiment 1, on the results page we can now see that the Summary report includes the average results. We also now have the OEE Histogram report, which shows the different OEEs for different runs of the experiment. There is also the OEE Box & Whisker report, which shows the same information in the box & whisker plot format. We have the Throughput Box & Whisker report, as well as the Throughput Scatter report to show throughput throughout the runs. And finally, just like with the Single Run experiment, we have the Constraint and Interrupt summaries, which now additionally label which run the data represents.
Back in the Experiments tab, Experiment 2 is of the type Gain/Loss. Just like with Multi, we have a field for Replications. Gain/Loss experiments focus on seeing the impact of different interrupts on OEE. If we run Experiment 2, we see our OEE Loss report shows the percentage Loss we see from each interrupt. OEE Gain/Loss chart takes the Loss chart and adds in additional bars to show the Gain that would be achieved for fixing the interrupts. Different interrupts have varying Gain returns, with some showing a Gain even higher than the Losses. Lastly we have a Box & Whisker distribution across all the runs.
Our final experiment in the Experiments tab, Experiment 3, is of the type Buffer Tradeoff. This type focuses on finding the optimal size for a specified buffer. In our experiment here, we can see that the Experiment Buffer is set to b2, which represents Roasted Chickpeas in our Hummus demo. In addition to the Replications field, we now have the Min Capacity and Max Capacity fields — which set the lower and upper bounds of the buffer size — and the Step Size between them. A very small Step Size or a large range between Min and Max Capacity lead to more experiments, which in turn increases run time. Let's go ahead and run Experiment 3.
In addition to our usual Summary, our results now have the Buffer/Interrupt Tradeoff chart. Here we can see the average OEE based on the buffer size. In our results, we can see that going from a buffer size of 0 to 20 shows significant gains in OEE, but increasing beyond that has diminishing returns. This means that a buffer size around 20 is probably our goal. To refine these results, you can rerun the Buffer Tradeoff experiment with a smaller Step Size and a smaller range. We can look to the Box and Whisker plot to see that again 20 looks to be our best buffer size, as there is not much meaningful change beyond that buffer size.