Simulating a laptop assembly line in Simul8

The queue that isn’t the problem

Walk past an assembly line and you can usually guess where it hurts. There is always one station with a pile of work in front of it, someone visibly rushing, a queue that keeps growing. That is the bottleneck. Obviously.

Except it often isn’t.

That is the awkward thing about production systems: the station that looks busiest and the station that is actually limiting output are frequently not the same station. Fixing the visible queue feels productive. Sometimes it changes nothing at all.

So I built a discrete-event simulation of a simplified laptop assembly line to work out which was which. The idea is straightforward. Rather than reorganising a real factory and hoping, you build something that behaves like the factory, then break it repeatedly for free.

First, how long does anything take?

Before you can simulate a line, you need to know how long each task takes, and “about ten minutes” is not an answer a model can use. Some task-time distributions came with the problem. For the rest I had 200 historical observations and had to work out what they came from.

Arrivals

For inter-arrival times I assumed an exponential distribution, the usual starting point for orders turning up independently of one another. Estimating the rate is maximum likelihood:

for $n$ data points $x_i$. That gave $\lambda=0.158$.

Assuming a distribution is easy. Checking it is the part worth doing. A Kolmogorov-Smirnov test gave a test statistic of $0.56$ against a $95\%$ critical value of $1.094$, so I could not reject the null hypothesis. Exponential it is.

Keyboard and mouse placement

This one had no distribution attached, so I started where you always start: plot it and look. The histogram came out roughly bell-shaped, so I took the sample mean and variance and estimated $\mathcal{N}(8.11,\ 1.43)$.

A Chi-squared test gave $6.1$, comfortably under the $95\%$ critical value of $14.067$. Good enough to build on.

The other assembly tasks got the same treatment. It is unglamorous work, but every result later in this post rests on it. Get the input distributions wrong and you have built a very convincing model of a factory that does not exist.

Building the line

With distributions in hand, I built the model in Simul8, keeping the parts that actually drive flow and leaving out the rest.

Orders arrive at random and are accepted only if the number of laptops already in the system is below a set limit. That work-in-progress cap matters more than it sounds. Without it the model cheerfully accepts work forever and the queues run away to infinity, which is realistic in neither factories nor life. Each accepted order gets an ID and splits into two parallel branches, one per subassembly.

Every task draws its duration from the distributions above. Some need a specific worker or machine. A few also need stock: aluminium cutting and hard disk placement both stall if inventory runs low, tracked with global variables.

When both branches finish they synchronise, then move to final assembly and QA. QA needs two specific workers, and I treated the moment a laptop clears QA as the end of production for cycle-time purposes.

I also added small sub-models for aluminium plates and hard drives. Drop below a threshold, an order is triggered, and the system waits out a fixed delivery delay before stock reappears. This turned out to matter far more than I expected.

Running it for a year

I ran the model over a simulated year and tracked cycle time: how long a laptop takes to get from accepted order to cleared QA. Each unit is time stamped on the way in and again on the way out.

I left boxing out of that measurement. It happens after production is finished and depends on batching decisions that have nothing to do with the line itself. Including it would only have added noise to the number I cared about.

One detail that is easy to skip and should not be: a simulation does not start in a realistic state. It starts empty, which no working factory ever is. The first stretch of output therefore describes a factory that does not exist. I discarded a warm-up period of 600 minutes, chosen by watching a moving average of the last 10 completed cycle times until it settled, then used batch means for the averages.

Then I looked at the queues. QA had by far the longest, which made it the obvious suspect.

But the cycle times showed periodic spikes that did not line up with QA at all. Something else was going on.

Three things I tried

Order materials earlier

The original setup reordered aluminium plates and hard drives only when stock fell below 10 units, against a 15-hour delivery delay. That combination meant the line regularly ran dry and sat waiting for a van.

Moving the reorder point to 20 cut average cycle time significantly, confirmed with a paired t-test over 50 batched runs. This was the change that mattered, and nothing about walking the shop floor would have told you so.

Double the QA staff

QA had the queue, so this was the intuitive fix. It worked, in the narrow sense: the queue fell from 80 minutes to under 2.

Overall cycle time barely moved.

That is the whole lesson of the post in a single experiment. QA looked like the constraint because it was busy, and busy and constraining are different things. The laptops were not waiting on QA. They were arriving in bursts because the line upstream kept stalling on materials, and QA was simply where the bursts became visible.

Raise the WIP limit

Lifting the cap from 30 to 60 let more orders in and cut rejections. Average throughput did not budge.

Worth doing if you are losing customers at the door. Useless if what you want is faster delivery, because letting more work into a blocked system just gives you more work sitting blocked.

What the model got right and I didn’t

I went in expecting the answer to be QA. It had the queue, the visible pressure, the obvious story. It was wrong.

The real constraint was stockouts: quiet gaps in material availability with nobody standing around looking busy. No queue forms when a station is starved. It just sits there, which is much harder to notice and much more expensive.

That is the case for building the model rather than trusting the walk-past. Simulation lets you separate “this looks like the problem” from “this is the problem”, and test the difference before committing anyone’s budget to it. Two of my three interventions did approximately nothing. Finding that out in Simul8 cost an afternoon. Finding it out by hiring QA staff would have cost considerably more.