Monte Carlo simulation is a modeling technique that runs a process model thousands of times, drawing random values for uncertain inputs on every run, so that instead of one average answer you get the full range of outcomes and how likely each one is. In manufacturing, where downtime, cycle times, and changeovers all vary from day to day, it turns questions like "can this line deliver 3,500 units a week?" from a guess into a probability.
Planning on averages assumes the plant behaves like its mean. It does not. Failures cluster, repairs run long, and a single bad week can sink a delivery promise even when the monthly average looks healthy. Deterministic math answers "what happens in the average week?" Monte Carlo answers the question operations managers actually care about: "how often will we miss?"
This is the same reason queueing theory matters: variability, not just utilization, drives waiting and lost output. The Kingman formula shows that effect analytically for one workstation. Monte Carlo extends the idea to whole systems that are too messy for a closed formula.
A packaging line runs 40 hours a week at 100 units per hour, so the theoretical ceiling is 4,000 units. Maintenance history says unplanned stops arrive about 1.8 times per week on average, and each repair takes between 1 and 3 hours, with 2 hours typical.
The average-based plan says: expected downtime is 1.8 stops times 2 hours, which is 3.6 hours, so expected output is 36.4 hours times 100, or about 3,640 units. A customer needs 3,500 a week, so the average says yes with room to spare.
A Monte Carlo run of 10,000 simulated weeks, sampling the number of stops and each repair duration separately, returns a distribution instead: the median week lands near 3,660 units, but roughly one week in three falls short of the 3,500 commitment, and about one week in ten ends below 3,280. The average was not wrong, it was just not the answer to the delivery question. With that visibility, the team can quote 3,300 with confidence, add a buffer shift, or attack the failure rate itself.
The quality of a simulation is decided before the first trial, by the distributions you feed it. Time between failures and repair durations should come from your own maintenance records, summarized through metrics like MTBF and MTTR. For failure-time behavior that changes with equipment age, a Weibull analysis tells you whether failures are random or wear-driven, which changes the shape of the distribution you should sample. Guessing these inputs, or copying textbook values, produces confident nonsense.
Monte Carlo is a technique, not a product category. It can live in a spreadsheet, a Python script, or inside discrete-event simulation packages. It is also narrower than a digital twin: a twin maintains a continuously synchronized virtual copy of an asset, while a Monte Carlo study is a repeated experiment you run when you need a decision. The comparison of digital twins versus simulation covers that distinction in depth.
Fabrico is not a simulation tool and does not run Monte Carlo models. What it provides is the part every simulation depends on: trustworthy input data. Real-time production monitoring records actual stop frequencies, durations, and speed losses as they happen, including on older machines without PLC access, and the CMMS work order history captures true repair times. Because OEE losses are logged automatically rather than estimated at shift end, the distributions you extract reflect the plant you actually run. Fabrico is EU-built with EU data residency, so that operational history stays under European governance.
Enough for the percentiles you care about to stop moving. For most factory questions, 5,000 to 10,000 trials is plenty and runs in seconds. Rare-event questions, like a failure combination you expect once a year, need more trials because the tail is sampled rarely.
Not quite. Monte Carlo refers to the random-sampling technique itself. Discrete-event simulation models a system as a sequence of events over time and usually uses Monte Carlo sampling inside it. A simple throughput risk model needs only the sampling; a full line redesign usually deserves a discrete-event model.
At minimum: stop frequency, repair duration, and cycle time records that are complete enough to fit distributions. If stops are logged manually and half of them are missing, fix data collection first. The simulation cannot be better than the history it samples.
Want simulation inputs your team can defend? Book a Fabrico demo to see how automatic OEE and downtime tracking build the reliability history your models sample from.
Iniciar sesión
Blog
