# ReliaSim: full text > The full text of the reliasim.com guides, case studies and product pages listed in https://reliasim.com/llms.txt. ReliaSim is production line throughput and bottleneck simulation software by ChiAha, from a team modeling production lines since 1990. Generated 2026-11-04. # Why Simulation Belongs in the Capital Plan Source: https://reliasim.com/guides/why-executives-simulate.html ## Why Simulation Belongs in the Capital Plan Executive Guide ## Why Simulation Belongs in the Capital Plan A capital request for a production line comes down to a payback estimate. The payback depends on what the line will produce once the change is in, and that’s the hardest number to know ahead of time. Your teams are smart, and even smart teams need a tool that can play a whole line forward through a year of stops before anyone signs. ### You get one shot at a capital decision A new crewing pattern or changeover sequence can be tried on the floor and rolled back. A second case packer can’t. Once the equipment is ordered and installed, the money is spent, whether the line responds the way the business case said or not. Most of the evidence behind those requests comes from the plant’s own reports. They’re accurate about what already happened. A capital request is a claim about a line that doesn’t exist yet, and nothing in last year’s numbers describes it. ### It’s the stops that drive your output Totals hide what matters about a stop. A timing belt that fails once a week for two hours logs 120 minutes. Bottle jams that stop a machine 120 times a week for a minute each also log 120 minutes, and the loss report gives the two the same priority. Micro stops versus breakdowns works through why they aren’t the same. The line treats them very differently. A buffer can ride through one long stop, because it has stock when the stop begins. Against a hundred short stops it never refills, so the losses spread downstream instead of being absorbed. ReliaSim® is the first simulation software built expressly for high-speed, high-volume lines and the stop data they produce. It models rates and flow, the way product actually moves on a fast line, rather than tracking pieces and parts one at a time. Each machine carries its own stops by cause, with how often each one comes around and how long it lasts. Blocking and starving come out of the run instead of being assumed. The question moves from which machine lost the most to which change gives the most back. ### What a loss tree can’t tell you A loss tree adds up downtime by machine and by cause. Anyone in the room can audit it, and it’s usually right about the total. Where it goes wrong is the ranking, because it treats each loss as if it stood alone. Losses don’t stand alone, because stops ripple. When one machine stops, the machine after it runs out of product and the machine before it has nowhere to send any. Those neighbors log starved or blocked time under their own names, and the machine that caused it looks moderate on the report. In our bottling line case study, Labeler Misalignment cost 6.79% and Filler Micro Stop cost 6.72%. The Pareto ranked them together, and most teams would fix the Labeler first because it’s the bigger single event. The model removed each one in turn and re-ran the whole line. The Labeler fix returned 5.0 points and the Filler fix returned 8.1, which is 62% more. The Labeler fix meant $400K of alignment tooling. The Filler fix was a $50K intervention, automated jam clearing. On a $50M/year line, following the loss tree instead of the simulation leaves $1.5M on the table. ### Why experience and spreadsheets run out Your people know which machine jams, which changeover runs long and who clears a fault fastest. What nobody can do is hold a whole line in their head through a year of random stops, with dozens of failure modes firing on their own rhythms and buffers filling and draining between them. A spreadsheet can’t either, because it has no clock. It shows how many minutes were lost but not the order they were lost in, and the order decides whether a stop costs anything. Arithmetic on averages also overstates what a buffered line will produce. A forecast built from the loss tree comes out optimistic however careful the people building it are. Risk only shows up over time, because everything on a line changes. The formula is where you start, and the model is where you find out. ### Simulate before you spend A model of the line is a playing field, the scope of the system you play scenarios out on. It lets your team ask what would happen if. What if we add a buffer before the capper, or fix the micro stops before the misalignment? The model changes one thing, runs the whole line forward and compares the result against the line you have. Speed decides how many of those questions get asked. On the five-machine bottling line, one simulated year takes 0.154 seconds on a laptop, so a thousand one-year runs finish in about two and a half minutes. When a run takes all night, a team tests a few scenarios picked in advance. When it takes seconds, they can test every failure mode and every buffer size. Each option runs a thousand times, repeatably, so anyone can check the answer and see the spread a single run hides. You can try this on a real bottling line in the ReliaSim Sandbox, where every number on screen comes from the engine. ### A validated model gives your team a defensible answer Validation is how you know a playing field gets the math right. The model has to reproduce a year you’ve already measured, failure mode by failure mode, since one overall number can be right for the wrong reasons. A published plant model built this way came in within 1% of measured OEE, and so did its rebuild in ReliaSim. Matching a year you can check is what lets the model speak for a configuration nobody has built. When someone in the capital review asks why this fix and not that one, your team can show the topology, the assumptions and the sensitivity check behind the answer. ### What plants found when they simulated first A soap manufacturer consolidating several plants into one facility, with over 300 products, modeled the whole plant before moving. The planned machine assignments would have held some products in the system too long, causing a quality problem that needed a $4 million retrofit. Other routings, tested in the model, avoided it. The company now requires a simulation study before any major capital expenditure. At a major food manufacturer, Malcolm Beaverstock, its manager of advanced control and simulation, estimates $5 million saved from 40 models. Of that, $3 million comes from scrapping projects that would have been counterproductive. “Cost avoidance is a concept accountants hate, but it’s real,” he says in Food Engineering. A specialty olive packer tests scheduling rules in a model of its plant and finds 15% more throughput without new equipment. The team behind ReliaSim did these projects with the same rate-based method, before ReliaSim was a product. ### From a single machine to the whole supply chain The playing field scales to the size of the decision. It can hold one machine’s failure modes, a full line with its buffers or a whole plant. It can also hold a supply chain, for questions like where to hold stock across a network. There, perfect delivery has a price nobody wants to pay, so you agree the service target first, then find the cheapest way to hit it. The Sandbox has four tiers: Flow · Discrete Rate, Stats · ReliaStats®, Lines · ReliaSim and Networks · Supply chain. #### Test one question on your own line We model one question about your line on your data and send a two-page readout in about five business days. Free line assessments are open now. Apply for a free line assessment --- # How a ReliaSim Project Runs, Step by Step Source: https://reliasim.com/how-a-project-runs.html - 1Question - 2Data - 3Check - 4Fit - 5Build - 6Validate - 7What-ifs - 8Readout - 9Reuse - 1 Start #### Start with a question worth money Most fall into five kinds: which fix returns the most, whether to run faster or slower, how much buffer to carry, whether you need a second machine, and whether to automate resupply. You bring The decision you’re weighing, and when it gets made. What happens We agree on one question and the part of the operation it touches. A narrow question answered properly beats a broad one answered vaguely. What you learn Whether ReliaSim is a good fit for your process. You get One question, written down, and the scope that answers it. Time A 45-minute intake call on the free assessment. - 2 Data #### Send the stop history you already record An .xlsx or .csv export from your historian or downtime tracker is enough. It needs each stop, not shift or daily totals. You bring For each stop, the machine, the reason code, and when it started and ended, recorded to the second. Also machine rates, buffer sizes and changeover times. What happens You can strip product names first, because the model doesn’t need them. A mutual NDA is available, and your data is returned or destroyed when you ask. What you learn Where data is missing. We model those gaps with assumptions and label every one. You get A clear line between what was measured and what was assumed. - 3 Ingest and validate #### Check the data before it becomes a model Bad data gets caught here, before it turns into a model that’s confidently wrong. You bring Nothing new. This step runs on the export you sent. What happens Checks for gaps, time resolution and reason-code hygiene. Dates are read the right way round, planned stops come out, and weekends or idle shifts don’t count as run time. What you learn How far your stop records can be trusted, and where they need care. You get A clean event history, ready to fit. - 4 Fit #### Learn how each machine actually fails Every failure mode gets its own pattern: how often it happens, how long it lasts, and how much that varies. You bring Nothing new. What happens ReliaStats® fits a time-to-failure and a time-to-repair pattern to each failure mode. It tries eight distribution types and ranks them by goodness of fit. What you learn Which stops are frequent and short, and which are rare and long. MTBF and MTTR averages hide that, and it decides how often a stop outlasts a buffer. You get An interrupt file with one row per failure mode, ready for the model. - 5 Build #### Build the playing field The playing field is the part of your operation we model and play scenarios out on. It scales from a single machine to the whole supply chain. You bring People who know the floor, to confirm the machines, their order and where the buffers physically sit. In published projects, plant operators, engineers and the production scheduler checked the model with the modelers. What happens We sketch the line node by node, set rates and buffers, and attach each machine’s failure patterns. Every playing field is a choice about what to leave out. Start simple, then add detail where the question needs it. What you learn Perfect Production, the most the line can make if nothing ever stops. You get A model of your line that someone on the floor would recognize. Time A typical build takes 15 minutes. - 6 Validate #### Prove the model matches your history Before anyone uses it for a decision, the model has to reproduce a year you already measured. You bring Your measured OEE for the same period. What happens We run the model over that year and compare it with what your historian recorded, overall and failure mode by failure mode. What you learn Whether the model can be trusted. A total can match for the wrong reasons, so each failure mode is checked on its own. In a published plant study, the model landed within 1% of measured OEE. You get A model-versus-history chart with one point per failure mode. - 7 Run scenarios #### Run the what-ifs on the validated model Try the plan on the model before you try it on the plant. Change one thing at a time and see what the whole line does, not just the machine you touched. You bring The options on the table. Every what-if pulls one of two levers: change the structure, or change the policy. A second machine or a bigger buffer is structure; a fix, a speed or a resupply method is policy. What happens Gain/Loss removes each failure mode and reruns the line. Sweeps test every buffer size and speed. Repeat runs show the range of outcomes rather than one number. Where options trade output against cost, hold service at your target, then see what each option costs to get there. What you learn Which fix returns the most, which often isn’t the biggest loss. Where buffer beats reliability, the best speed, and whether a second machine pays. You get Charts and tables for each option, with the best and worst cases. Same loss on the Pareto, different return in the model Labeler misalignmentrare, longer stops 6.79% loss +5.0 pts gain Filler micro stopfrequent, short stops 6.72% loss +8.1 pts gain From the five-machine bottling demo. Fixing the Filler’s jams recovers 62% more throughput than fixing the Labeler, for the same effort. - 8 Recommendation #### Get a written recommendation, with the evidence A readout your team can take into a capital review. You bring Your questions, on a 30-minute readout call. What happens We write up the answer to your question with the evidence behind it. What you learn Where the constraint actually sits, your failure modes ranked by what fixing them returns, and how output responds to buffer size. You get The recommendation, with the model layout, every assumption and a sensitivity check. On the free assessment it’s two pages. Time About five business days from data to readout on the free assessment. - 9 Decision and after #### Make the call, then reuse the playing field The model doesn’t expire when the first question is answered. The next question reuses it. You bring The next question, and newer stop history when you have it. What happens Refresh the model from the new history and run the next decision. Anyone with the free demo can open the file and run the scenarios. What you learn Your team can learn the method in one-hour online sessions, a two-day course, or on-site training built on your own line. You get A model in a file you control. With a license, it stays usable even if the license lapses. ### Two ways to start Free #### The line assessment One line and one question. We model it on your data and send a two-page readout in about five business days. Your time is a 45-minute intake call and a 30-minute readout call. You receive the readout and run results, not the model file. Full project or license #### Every step, on your own playing field We can handle the data cleaning, fitting and model build with you. Or license ReliaSim, at $8,000 per user per year, and run the steps yourselves. Licensed, ReliaSim runs on your own machines with no cloud dependency, including on air-gapped networks. ### The detail behind the steps #### What the stop log needs One row per stop, and any of the three timing formats works. For the assessment, everything fits on one page or one spreadsheet tab. FieldWhat it holds MachineThe machine or place that stopped. ReasonThe cause or fault code for the stop. TimingStart and end time, or a start and a duration, or the uptime before the stop and the downtime in minutes. Recorded to the second. Line setupMachine rates, buffer sizes and changeover times. #### What the model reports ExperimentWhat it shows Single runProduction against ideal, each machine’s running, blocked and starved time, every stop and its effect on the line, and a replay. Multi runThe same scenario repeated, so you see the spread of throughput and efficiency, from best case to worst. Gain/LossWhat removing each failure mode returns to the whole line. Buffer trade-offOutput across buffer sizes, with and without each failure mode. RateOutput across machine speeds, with and without each failure mode. #### Where your data lives With a license, models, data and results stay in files on your own machines. ReliaSim has no cloud datastore, and only license and version checks go over the internet. For the assessment, you can anonymize the data first and have it returned or destroyed when you ask. #### Start with one question about one line Apply for a free line assessment. We reply within two business days. Apply for an assessment Or explore the Sandbox first --- # Manufacturing Simulation Software Source: https://reliasim.com/manufacturing-simulation-software.html ## Manufacturing Simulation Software for High-Speed Production Lines Rate-based, reliability-driven, validated before it predicts ~1,200×faster than the original tool, rebuilding that same published model 1995the year Andrew Siprelle created discrete rate simulation ### What manufacturing simulation software is for A plant already knows a great deal about its line. The historian records every stop, the loss tree attributes the minutes, and OEE grades each shift against the plan. All of that describes what happened. None of it can tell you what a change will do, whether that’s a buffer you haven’t installed, a line speed you haven’t run, or a failure mode you haven’t eliminated yet. Manufacturing simulation software answers those what-if questions about a production system before you spend money on them. Which machine is actually costing throughput? Is the fix at the top of the Pareto worth more than the one below it? How big should the accumulation table be? Would a second capper pay back, or would better reliability on the first one do the same job for less? Those questions are hard because machines on a line are coupled. A stoppage on one blocks the machines upstream of it and starves the ones downstream. Buffers absorb some stops and not others, and the cost of any single loss depends on where it sits. A spreadsheet adds losses as if they were independent, and arithmetic on averages overstates what a line will produce. A simulation plays the line forward through time, so that interaction emerges from the model instead of being assumed away. ### Why high-speed lines break item-based simulation Most general-purpose simulation tracks every item as its own entity, which is the right design for a job shop. Point it at a filler running hundreds of units a minute and the model has to move every unit individually. ReliaSim models material as flow instead, the idea Andrew Siprelle arrived at in 1990 as “bulk flow.” The engine only works when a rate changes, so run cost follows how often rates change, not how many units the line makes. A full year of the five-machine demo bottling line simulates in about a third of a second. The full argument is on capabilities and at discrete rate simulation. Item-based versus rate-based, on a high-speed line QuestionItem-based (discrete event)Rate-based (ReliaSim) What the engine tracksEvery unit as an entityFlow rates, and the events that change them Cost of higher line speedMore entities, longer runsUnchanged, since rate is a parameter What drives run timeHow many units are madeHow often a rate changes Experiment size in practiceThe few scenarios someone pickedExhaustive sweeps of thousands of runs Best fitJob shops, routed parts, item identityFilling, packaging, bulk and continuous flow ### How ReliaSim models a production line A model is built from a deliberately short vocabulary of constraints, converters and buffers, with every failure mode carried as its own interrupt. The capabilities page describes it in full. Models are text-based, so they diff and version like source code. ### Build, validate, predict The ReliaSim method is a fixed sequence. Build the line as it actually runs and parameterize each failure mode. ReliaStats fits the distributions from event data (downtime data analysis), or you use the Interrupt Designer for a line that doesn’t exist yet. Validate against the historian failure mode by failure mode, not just in total. Bivariate validation ships with every license. Only then do you predict, by changing one thing and re-running the whole system so the answer includes every knock-on effect. ### Validation evidence you can check Most simulation accuracy claims rest on a vendor’s word, but this one rests on a paper. A model of a multi-line food plant, published in a peer-reviewed Winter Simulation Conference paper, comes within 1% of measured OEE, and its ReliaSim rebuild is independently validated to the same bar. The full account is in the published OEE validation case study. Source vs. simulated availability on the bottling line demo model, one marker per failure mode, with 95% prediction and 99% confidence bands. The same per-mode comparison is built into the product, and it’s how you validate your own line. ### What you can ask of it #### Where is the real bottleneck? The constraint timeline shows which machine is limiting the line at each moment, and it’s rarely one fixed station. Finding the hidden bottleneck · theory of constraints simulation. #### How big should the buffer be? Sweep capacity with every interrupt in play and see where the curve bends. How big should a buffer be? #### Which failure mode first? Remove each one, re-run, and rank by throughput recovered instead of minutes lost. Which loss to fix first #### What will this do to OEE? Predict line OEE for a change before you make it, from per-machine interrupt data. OEE simulation #### Faster, or more reliable? Running faster makes more product and causes more failures, so there’s an optimal speed. Five decisions every line faces #### Block diagram, or simulation? Multiplying availabilities assumes machines fail independently, and buffers break that assumption. RBD vs simulation A constraint timeline across one simulated day, with each machine’s time split into up, down, blocked and starved. Downtime that looks identical on a loss report rarely lines up like this. Because runs are cheap, you can answer those questions exhaustively instead of for three hand-picked scenarios. The buffer sweep is one example. Every run starts from a fixed seed, so the same question asked twice gives the same answer. With the AI / MCP add-on, you can also ask the model questions in plain language, and every figure in the reply traces back to an engine run. ### Industries and results Rate-based simulation applies wherever material moves as flow instead of as a queue of parts. The method behind ReliaSim has been used by production teams in more than 300 organizations since the early 1990s, across food & beverage, packaging & CPG, chemicals, oil & gas, pharma & life sciences, electronics & automotive and aerospace & defense. - A bottling line finds $1.5M in hidden throughput by re-ranking two failure modes its loss report calls equal. - A specialty olive packer recovers 15% more throughput with no new equipment once the model shows the binding constraints are downstream in packaging. - A soap plant consolidation model catches a configuration that would need a $4M retrofit, before the plant is built. Much of that work predates ReliaSim as a product, and each case study says which tool ran the model. See all case studies. ### Desktop, air-gap compatible, yours ReliaSim runs on Mac (Apple Silicon) or Windows 11. Models, historian extracts and results stay on your machine, inside your firewall. Only license and version checks touch the internet, and those can be deferred for air-gapped sites. There’s no SaaS version, by design, and the security page covers what IT reviewers ask. A model built on a licensed seat can be opened and run by anyone using the free demo, so a plant manager or a capital review board can check the scenarios themselves. ### When you need something else ReliaSim is opinionated, and it isn’t the right tool for every simulation problem. - Job shops and routed parts. If the question depends on the identity of individual items, such as complex per-part routings, serial-number tracking, or sequencing individual jobs through shared machines, a general-purpose discrete event tool is the more natural fit. - 3D layout and material-handling physics. If you need to see a proposed plant in three dimensions, check clearances, or emulate robots and vehicle traffic, use a 3D layout or emulation package. ReliaSim’s animation replays model states. It isn’t a CAD view. - Last month’s losses. That’s the loss tree’s job, and simulation is for what happens next. - Someone to build it for you. That’s ChiAha’s manufacturing simulation consulting. ### Frequently asked questions What is manufacturing simulation software? It’s software that builds a working model of a production system (its machines, rates, buffers and failure behavior) and runs it forward through time. You can test changes such as a new buffer, a faster line speed or an eliminated failure mode before making them on the real line. How is ReliaSim different from discrete event simulation software? Discrete event tools track every item as an entity, which suits job shops. ReliaSim’s discrete rate engine works only when a rate changes, so year-long runs on high-speed lines stay fast. How accurate is it? It matches measured OEE on a published, independently validated one-year model. See the published OEE validation case study. What data do I need to build a model? You need line event data (a CSV of machine stop and start times, recorded to the second), plus nominal rates and the line’s layout. Named failure modes give the most useful answers. Without history, the Interrupt Designer lets you enter failure and repair distributions directly. Does ReliaSim run in the cloud? No. It’s desktop software for Mac (Apple Silicon) and Windows 11. Your models and data stay on your machine, and it works on air-gapped networks. Can I try it before buying? Yes. The browser Sandbox shows four tiers of models, including a real bottling line, with saved engine results and no download or sign-up, and the desktop demo is free. Full licenses are annual per user (see the pricing page), and academic licenses for teaching and non-commercial research are free. #### Open a production line model now The bottling-line models in the Sandbox’s Lines tier each come with the engine’s saved results, and you can ask questions about them in plain language. There’s nothing to download and no sign-up. Open the Sandbox → See pricing Want to see it on your own line? Schedule a call. --- # OEE Simulation: See Line OEE Before You Change It Source: https://reliasim.com/oee-simulation.html ## OEE Simulation: See What a Change Does to OEE Before You Make It From per-machine interrupt data, validated before you rely on it 44%line OEE from five 85% machines in series, no buffers ~1,200×faster, rebuilding that published model in ReliaSim® ### Why measured OEE can't predict a change OEE multiplies three factors (Availability × Performance × Quality) and grades execution against planned production time. It's a good scorecard. As a forecasting tool it has three structural problems, and more care with the data won't fix any of them. - It has no history for the change. The questions worth spending money on are about things you haven't done yet, like a buffer you haven't installed or a speed you haven't run. No trend line on last year’s OEE contains them. - Losses interact. Ten minutes down on a machine feeding a full buffer costs nothing. The same ten minutes on a starved constraint costs ten minutes of finished product, yet the OEE report records both the same way. - Averages run optimistic. Multiplying average rates and availabilities overstates throughput, so spreadsheet forecasts of OEE come out predictably too high. So when an improvement project promises a number of OEE points, the number usually came from subtracting a loss from a loss report. What actually comes back is often different, in both directions, as which loss to fix first explains. ### Machine OEE isn't line OEE The world-class benchmark of 85% is a single-machine figure. Carry it to a line and the topology decides what it's worth. Five machines at 85% OEE, in series BufferingLine OEEWhy None0.855 ≈ 44%every stoppage propagates to the whole line Infinite85%stages fully decoupled; the slowest sets the pace Realsomewhere betweendepends on buffer size versus stoppage length, and only simulation gives the number The real row is the one that matters, and no formula reaches it. Multiplying machine availabilities assumes the machines fail independently, and buffers break exactly that assumption. So a plant that multiplies out to 46.7% can measure 54.3%, because the arithmetic can't see the decoupling the physical line has. Is 85% OEE achievable on your line? works through the consequences. ### How OEE simulation works In ReliaSim, each factor of OEE lands somewhere concrete in the model. #### Availability Interrupts. Every machine carries its own failure modes, and each one has a time-to-failure and time-to-repair distribution fitted from line event data. #### Performance Rates. Nominal rates, conversions and rate losses, plus the blocking and starving that emerge when coupled machines interact. #### Quality Scrap and rework. Nodes can remove or recirculate rejected units the way the line does, so the model counts good output. The interrupt data decides accuracy. With a Line Event Data system or a historian, ReliaStats fits each failure mode’s distributions from the raw events and hands ReliaSim parameters it reads directly (downtime data analysis is its job). For a line that doesn't exist yet, the Interrupt Designer lets you enter the shapes by hand. Named failure modes matter more than they look. One lumped downtime figure per machine still gives a working model, but the answer comes out flat, with nearly identical gains and losses, as the WSC 2020 study found. Per-mode detail lets the model tell one improvement from another. Then the engine runs the line forward through time, for a year or for many years across replications, and reports the efficiency it produced for each machine and for the line. The result is a distribution instead of a single figure, so you see the spread a single year of history can hide. Throughput across a multi-run experiment in ReliaSim. The same line and the same data give a distribution of outcomes, and that's the honest shape of a prediction. ### Validate against measured OEE first A simulated OEE is worth nothing until the model has reproduced the OEE the line actually delivered. ReliaSim holds that standard for each failure mode, not just in aggregate. Every interrupt’s simulated availability is compared with its observed availability, and each should land on the match line inside its confidence band. A single overall number can be right for the wrong reasons, with one mode overstated, another understated, and the errors canceling. A per-mode comparison can’t hide that. Source vs. simulated availability on the bottling line demo model, one marker per failure mode, with 95% prediction and 99% confidence bands. At plant scale the evidence is published. A peer-reviewed multi-line food plant model came within 1% of measured OEE, and so did its ReliaSim rebuild. See the published OEE validation case study. ### Simulated efficiency and your reported OEE Put a simulated figure next to a plant dashboard and they may differ by twenty or thirty points. Usually neither is wrong. OEE divides by planned production time. ReliaSim’s efficiency uses the stricter convention and divides by every minute of the modeled period, staffed or not. On a plant that runs 24/7 the two denominators are the same and the numbers should agree. On a one-shift plant they differ by exactly the time left unscheduled. Reconciling them is simple. Multiply the scheduled-time figure by the share of calendar time you actually scheduled, and any difference left over is about the model. Asset efficiency vs OEE covers the arithmetic, and how big is your hidden factory? covers what the gap is worth. ### What you can predict Once the model reproduces the line, every question becomes the same experiment. You change one thing, re-run, and compare. - Remove a failure mode. The OEE that comes back isn't the loss the report recorded. Some modes return less because a buffer was already absorbing them, and others return more because they were cascading downstream (micro-stops vs breakdowns). - Resize a buffer. Sweep capacity and see where the OEE curve flattens (how big should a buffer be?). - Change line speed. Running faster raises the failure rate too, so OEE and output peak at some speed instead of rising with it. - Find the ceiling. Turn every interrupt off and the model reports the most this topology can produce, so you know how much OEE is actually available to recover. Deciding which of those improvements to fund, and what each trades away, is its own question, covered in OEE improvement tradeoffs. This page covers the tool that prices them. Runs are cheap enough to compare every candidate instead of the three someone nominated. It all runs in ReliaSim’s manufacturing simulation software on your own desktop, and the discrete rate simulation engine makes that speed possible. ### Frequently asked questions What is OEE simulation? It's a model of the line, validated against measured OEE, that you run forward to predict how OEE responds to a change before you make it. Can you predict OEE before making a change? Yes, once the model reproduces the line’s measured performance. Change one thing, re-run, and compare with the baseline. Why can’t I multiply machine OEEs to get line OEE? Multiplying assumes machines fail independently. Buffers decouple them, so real line OEE sits between the multiplied figure and the best single machine. How accurate is simulated OEE? It matched measured OEE on a published one-year food-plant model, with interrupts kept per failure mode and the model validated before it predicted. See the published OEE validation case study. Why does simulated efficiency differ from my plant’s OEE? Usually it's the denominator. OEE counts planned production time, and ReliaSim’s efficiency counts every minute of the modeled period. What data do I need to simulate OEE? You need line event data (machine stop and start times recorded to the second, ideally with named failure modes), plus nominal rates and the line layout. ReliaStats can fit the failure and repair distributions from that data. Does OEE simulation include quality losses? It can. Nodes remove or recirculate rejected units, so the simulated output is good output. #### See OEE predicted on a real line model The bottling-line models in the Sandbox’s Lines tier come with the engine’s saved results. Their Gain/Loss results show how much OEE comes back when each interrupt is removed, and the Buffer-Options models add a buffer-size sweep. Open the Sandbox → See pricing Want to see it on your own line? Schedule a call. --- # Capacity Planning Simulation for Production Lines Source: https://reliasim.com/capacity-planning-simulation.html ## Production Capacity Planning Simulation Will the line make the volume, and what’s the cheapest way to get there? 15%more throughput at an olive plant, with no new equipment, once the model found the real constraints 19.8%more effective production in key demand periods from decoupling a cereal plant, with no new lines $4Mretrofit avoided when a plant consolidation model caught a configuration before it was built ### Rated capacity isn’t effective capacity Rated capacity is what a machine can do while it’s running, fed and unblocked. Effective capacity is what the line ships over a week, a season or a year. Between the two sit losses that a capacity spreadsheet usually folds into one planning factor. - Interrupts. A hundred one-minute stops and one hundred-minute stop cost the same minutes, but very different throughput once there’s storage between machines. - Blocking and starving. A stopped machine idles its neighbors, and how far the stop travels depends on the buffers between them. See starved vs blocked. - Changeovers and mix. Size, flavor, label and allergen changes are part of the schedule. A schedule that’s efficient for one product mix can be badly wrong for another. - Rate against reliability. Running faster makes more product until failures that rise with rate eat the gain, so output has an optimum speed. - Seasonality. A plant sized for average demand is idle part of the year and constrained the rest. The useful question is capacity during the peak, given how the line actually behaves. Those losses don’t add up neatly. Five 85% machines in series can make a 44% line (is 85% OEE achievable?), and arithmetic on averages makes spreadsheet capacity plans come out predictably high. Throughput vs capacity works through the distinction. ### The constraint is rarely where the plan puts it A capacity plan usually names a bottleneck and sizes everything around it. The project record on this site keeps showing that the named bottleneck isn’t the one deciding throughput. - At a specialty olive packer, a full-plant model confirms the pitting bottleneck and finds other choke points downstream in packaging. Scheduling rules tested in the model raise throughput 15% with no new equipment, and the team tests proposed capital against it before committing it. - A craft brewery planning to add kegging and bottling finds that neither new line is the limit. Either would over-run the fermenting and serving tanks unless capacity is added there first. - In a coffee Make-Store-Pack operation, changing packaging size moved the bottleneck, which defeats any plan built around a fixed constraint. The real constraint was already installed and already looked adequate for the mix the plant ran before. Finding it means running the whole line with the change in place. Finding the hidden bottleneck covers the mechanics. ### Capex, overtime or reliability: three ways to buy capacity When a line falls short of the volume, there are three broad ways to close the gap, usually argued in different meetings with different numbers. #### Buy equipment A second machine, another line, or more storage. It’s durable and expensive, and only worth it if it relieves the stage that’s actually binding. #### Buy hours Overtime, an added shift, or weekend runs. They’re quick to start and easy to reverse, but every added hour runs at the line’s current efficiency, losses included. Asset efficiency vs OEE #### Recover capacity Fix the failure mode that costs the most output, resize a buffer, decouple two stages, change the scheduling rule. This is often the cheapest option, and the hardest to size without a model. A simulation puts all three on the same footing. A specialty chemicals plant asks how many new bag lines to buy against how much overtime to accept. The model answers over a ten-year horizon, splitting each bag line’s weekly hours into production, repair, changeover, idle and overtime. It also shows that short-term storage between bulk production and packaging would decouple two operations the layout ties together, which surfaces low-capital growth options nobody had costed. Decoupling is the lever most often missed. A cereal plant stabilizes partially cooked grit so it can be stored and later reconstituted, instead of throttling its cookers to what the toasting ovens can take. The model sizes that at 19.8% more effective production in key demand periods, with no new cooking or oven capacity. It’s a peak-period figure, since in a slack period there’s nothing to recover. The same comparison works at machine level, weighing a second machine against a reliability improvement on the first. It’s one of the five decisions every production system faces. ### New plants and consolidations Capacity mistakes are most expensive before anything is built. A soap manufacturer consolidating several plants and more than 300 products into one facility uses a model to predict the buffer size between processing and packaging. The model also finds that one planned set of machine assignments leaves material in the system too long, a quality problem that would need a $4 million retrofit. Alternative routings are tested in the model instead, and the company now requires a simulation study before any major capital expenditure. Spreadsheet capacity model or line simulation? QuestionRough-cut spreadsheetLine simulation What it usesAverage rates, availability and a planning factorPer-failure-mode distributions, buffers, conversions and sequence How losses combineAdded or multiplied as if independentEmerge from the line running through time Where the constraint isAn input assumptionAn output, which can move with the mix The answerOne numberA distribution across replications Best useScreening many products and months quicklyCapital commitments, buffer sizing, peak-period capacity Both have a place. Use the spreadsheet for the first pass and simulation when coupling decides the answer. A major food manufacturer uses simulation to settle how many packaging lines to buy for a product line, where too few throttles a product and too many strands capital. ### How a capacity study runs in ReliaSim® #### 1 · Build Draw the line as it runs, or as proposed, with storage where it physically sits. Give each failure mode its distributions, either fitted by ReliaStats (downtime data analysis) or entered in the Interrupt Designer for a line that doesn’t exist yet. Turn every interrupt off and the model reports the most this topology can produce. #### 2 · Validate Compare the model with the historian failure mode by failure mode before you trust it. The method has been validated within 1% of measured OEE on a real plant (published OEE validation). #### 3 · Predict Change one thing at a time. Raise demand, add a machine, resize surge storage, change the changeover sequence, or remove a failure mode. Read capacity as a distribution across replications. Runs are cheap enough to compare candidate plans exhaustively instead of three picked in advance. The ReliaSim method covers each step. Most of the project work above predates ReliaSim as a product. It was done with the same method ReliaSim now packages, and each case study says which tool ran the model. ### What simulation doesn’t replace - A production schedule. A model can test a scheduling rule against variation before deployment, but writing tomorrow’s schedule is a planning system’s job. - Rough-cut planning across the portfolio. Use simulation on the lines where coupling decides the answer. - Data. The Interrupt Designer makes failure assumptions explicit, but it doesn’t make them right. - Someone to build it. That’s manufacturing simulation consulting from ChiAha. ### Frequently asked questions What is capacity planning simulation? It means modeling a production line or plant with its rates, storage, changeovers and per-failure-mode downtime. You then run it forward to see how much it produces under a given demand and mix, before capital or overtime is committed. What’s the difference between rated capacity and effective capacity? Rated capacity is what the machines can do while running, fed and unblocked. Effective capacity is what the line delivers after interrupts, blocking and starving, changeovers, rate losses and mix. Can I plan capacity for a line that doesn’t exist yet? Yes. Build the topology from the design, enter failure and repair distributions in the Interrupt Designer, and test configurations against demand. Validate the model against event data once the line runs. Should we buy equipment, add overtime or improve reliability? It depends on where the binding constraint is and how losses interact, which is what a simulation compares on one validated model. In several case studies on this site, the answer was a scheduling, storage or reliability change instead of new equipment. What data does a capacity study need? It needs machine stop and start times recorded to the second, ideally with named failure modes. It also needs nominal rates and conversions, the layout and storage capacities, and the demand or production plan with its changeovers. How accurate is capacity planning simulation? Close enough to act on, when built from per-failure-mode data and validated against line history. See the published OEE validation. #### See capacity questions answered on a line model The bottling-line models in the Sandbox’s Lines tier come with the engine’s saved results for each. On the Buffer-Options models you can see how much each buffer size adds and what the line gets back when each failure mode is removed. There’s nothing to download and no sign-up. Open the Sandbox → Read the case studies Want to see it on your own line? Schedule a call. --- # OEE Software: Monitoring vs Simulation Source: https://reliasim.com/oee-monitoring-vs-oee-simulation.html ## OEE Monitoring vs OEE Simulation One measures the line you ran. The other predicts the line you're about to change. ### Two kinds of OEE software #### OEE monitoring Collects machine states, counts and stop reasons from the line, through an MES, a historian or a dedicated OEE tracking system. It calculates Availability × Performance × Quality against planned production time, ranks the losses, and puts them in front of operators and supervisors while there's still time to act. #### OEE simulation Builds a model of the line from its rates, buffers and per-failure-mode downtime, and checks the model against measured OEE. Then it runs the model forward with a change in place, such as a buffer, a line speed or an eliminated failure mode. The output is a prediction, with its spread. Monitoring and simulation, side by side OEE monitoringOEE simulation The questionWhat happened, and what's happening now?What will happen if we change this? Time directionPast and presentFuture and counterfactual InputsMachine signals, counts, operator reason codesStop history, rates, layout, storage OutputsOEE by shift, loss Pareto, downtime logPredicted throughput and OEE, gain per fix, buffer curves Used byOperators, supervisors and CI teams, every shiftEngineers, CI and capital planning, per decision What it can’t doTest a change that hasn’t been madeWork without good input data ### What monitoring does well Nothing in a simulation replaces a good monitoring system. It shows a stop as it happens, attributes the lost minutes, gives each shift a number to beat, and builds the event history every later analysis depends on. Accounting for what already happened is a loss tree’s job, and it does it well. ### Where measured OEE stops A monitoring system describes the line you ran. It has no history for a change you haven’t made, and it records interacting losses as if they were independent, so removing a loss rarely gives back what the report says. Why measured OEE can’t predict a change works through it. Line OEE vs machine OEE covers why five 85% machines can make a 44% line, and which loss to fix first covers the ranking problem. ### From monitoring data to a validated prediction The two kinds of software meet in the event data. Here’s a typical path. #### 1 · Export the stop log The log has one row per stop, with where (the machine), why (the reason or interrupt code) and when (a start and an end, or a start and a duration). Most historians and downtime tracking systems already record it. #### 2 · Fit failure and repair distributions ReliaStats separates the log into failure modes and fits a time-to-failure and a time-to-repair distribution to each. It tries eight distribution types and checks the fit with Kolmogorov-Smirnov and Anderson-Darling tests, then exports the parameters for ReliaSim®. This step is called downtime data analysis. #### 3 · Build and validate the line model ReliaSim models the line with those interrupts, then compares simulated availability with observed availability for every failure mode. Here the monitoring data gets a second job as the reference the model has to reproduce before it predicts anything. #### 4 · Predict, then measure Change one thing in the validated model and read the predicted OEE and throughput. Once the change is made on the line, the monitoring system shows what actually came back, and that becomes the next check on the model. More on OEE simulation. ### Making monitoring data simulation-ready - Timestamps to the second. Short stops vanish in rolled-up minutes, and they often cost the most throughput. - Named failure modes, not one downtime bucket per machine. One averaged mode per machine flattens the gains and losses (published OEE validation). - Planned stops flagged. Rows marked as planned or excluded need to come out, and long non-operating gaps such as a weekend shouldn’t count as time a machine ran without failing. - Unambiguous dates. Many plants export dates day-first, which a parser expecting month-first will silently scramble. - A known denominator. OEE divides by planned production time, and ReliaSim’s efficiency divides by every minute of the modeled period. On anything but a 24/7 plant they differ by the unscheduled time. Asset efficiency vs OEE has the arithmetic. ### Which do you need? - No reliable stop records yet. Start with monitoring. Without event data, a simulation is limited to failure assumptions entered by hand in the Interrupt Designer. - Monitoring in place, and the question is operational. Monitoring tells you which machine stopped, who responds, and how the shift did. - Monitoring in place, and the question is a decision. Use simulation, fed by the data you already collect. It answers questions like which loss to fund, how big a buffer, faster or more reliable, whether the line will make next year’s volume (capacity planning simulation). ### Frequently asked questions Is OEE simulation software a replacement for OEE monitoring? No. Monitoring records what the line did and is the data source. Simulation uses that record to predict the effect of a change before it’s made. A plant that simulates still needs to monitor. What data from an OEE monitoring system does simulation need? It needs the stop log, with the machine, reason code, and start and end time of each stop recorded to the second. It also needs nominal rates, the line layout and the storage between machines. Why doesn’t fixing the top loss on the Pareto return all its minutes? Losses interact. Buffers absorb some stops, so removing them returns less, while other stops cascade downstream and return more. Why does simulated efficiency differ from my OEE dashboard? Usually it’s the denominator. See the Asset Efficiency vs OEE guide. Can I simulate OEE for a line with no monitoring data? Yes, by entering failure and repair distributions directly in the Interrupt Designer. The predictions are then only as good as those assumptions, so validate the model against event data once the line is running. How close can simulated OEE get to measured OEE? The method has been validated within 1% of measured OEE on a real plant, with the model built from per-failure-mode data and checked against the line’s own history. See the published OEE validation. #### See OEE predicted on a line model The bottling-line models in the Sandbox’s Lines tier come with the engine’s saved results, including what the line gets back when each interrupt is removed and how efficiency changes with buffer size. There’s nothing to download and no sign-up. Open the Sandbox → OEE simulation Want to see it on your own line? Schedule a call. --- # The ReliaSim Method: Build, Validate, Predict Source: https://reliasim.com/method.html Methodology ## From production graph to confident decision How ReliaSim® turns a production graph into an OEE prediction you validate against your own measured year, without needing simulation expertise. Build Step 1 Validate Step 2 Predict Step 3 Introducing ReliaSim · 1:25 ### How do you increase production? Every system has multiple ways to improve. Add Buffer? Improve Reliability? Automate the Process? How do you decide? Gut feel? Spreadsheets? Past experience? Consultants? Or you can model the system, parameterize it from real data, and predict which lever pays off before you pull it. The three steps below show how. Step 1 · Build #### Sketch out the equipment/process steps. Parameterize what matters. Sketch the line as it actually runs, as a graph of nodes in whatever topology it has, then give each machine its own interrupt signature. Perfect Production comes out of the model. Your model reflects the real system from day one. #### Step 1 · Build → Sketch out the equipment/process steps. Draw your production line node by node. Set rates, add buffers, mark decoupling points. Modeling projects usually go wrong at this step, without anyone noticing. A graph drawn from a spec sheet describes the line the vendor sold you. A graph drawn from the plant describes the one you actually run. The difference doesn't show up here. It shows up three steps later as a model that’s confidently wrong. At the end of this step you want a topology someone on the floor would recognize, with the right machines in the right order and the buffers where they physically are. The ahaEqual speeds don’t mean no bottleneck. On the bottling demo every machine runs 100 bottles a minute, so nothing looks like the limit. Perfect Production says what the line could make; the gap between that and what it ships is stops, not speed, and the drawing is where that gap starts to show. Duration: 90.00 Days Efficiency: 100.0% PerfectProduction: 130,896 pallets Bulk Storage Filler A Capper A Labeler A Filler B Capper B Labeler B Case Packer Palletizer Warehouse See it in action: model build video ▼ Drawing the production graph node by node #### Step 1 · Build → Parameterize what matters. Fit the line event history in to find each machine’s failure distributions. Nominal rates are the easy part, and they don't decide output. How each machine actually fails decides it, meaning how often, for how long, and with how much spread. ReliaStats fits those distributions from your own event history instead of asking you to pick one, so every unit operation carries its own interrupt signature instead of a shared average. Try it in the Sandbox, where the ReliaStats® tools sit next to the bottling-line models. The ahaAverages erase the answer. Two failure modes can cost the same hours and behave nothing alike: frequent short stops versus rare long ones. Fischel and Lange found that with one averaged failure mode per operation, the gains and losses come out “essentially identical to each other”. The detail is what makes the ranking possible. TTF / TTR distribution designer Source-to-fit: distribution matching For a line that doesn’t exist yet, the Interrupt Designer lets you choose the shapes deliberately, which makes the assumption explicit. Infant Mortality Decreasing failure rate Wear-out Age-related failures Scheduled Fixed-duration maintenance #### Step 2 · Validate → Validate against history. Compare to your historian, interrupt by interrupt. Validation separates a simulation from an opinion, and it’s the step most often skipped. It isn’t a sanity check on the total. Every interrupt is compared individually against what the historian recorded, and each should land on the diagonal inside its confidence band. A model that matches annual OEE while getting the individual failure modes wrong will still answer your questions, but incorrectly, and you won’t find out until the capital is committed. The ahaThe line isn’t the product of its machines. Multiply the five machines’ availabilities on the bottling demo and you get 46.7%. The line actually runs at 54.3%, because some stops overlap and some are covered. That is also why the model has to match every interrupt, not just the total: a published food-plant model matched measured OEE within 1%. Model vs. historian: simulated availability vs. actual Each point is an interrupt. A point on the diagonal means the model matches reality. "The only way to predict this accurately is through simulation." — Tom Lange, 36 years in manufacturing R&D #### Step 3 · Predict → Gain ≠ Loss. Each machine is an actor with its own rhythm. When the ensemble performs together, blocking and starving emerge from the interaction. Gain ≠ Loss is the part that surprises people, and it’s why a loss report isn’t a plan. Remove a failure mode and you don’t simply get its downtime back. Some of that loss was absorbed, because the line caught up in a buffer or the machine was starved during the stop anyway. Some of it was cascading into the machines downstream, so removing it returns considerably more than it appeared to cost. Which of the two you’re looking at depends on where the failure sits in the system, and no ranking of losses can tell you. The simulation removes each one individually and re-runs the whole system to find out. The ahaThe biggest loss isn’t the biggest gain. Labeler misalignment costs 6.79% and gives back 5.0 points when fixed. Filler micro stops cost almost the same, 6.72%, and give back 8.1: 62% more. A loss report ranks them as a tie. Lean, TPM and TOC each pick a different first fix on this line, and none finds the best one. Loss → Gain detail Labeler Misalignment Loss 6.79% → Gain +5.0 pts 0.73× recover less than you lost Filler Micro Stop Loss 6.72% → Gain +8.1 pts 1.21× 62% more recovery Same loss, very different recovery. Why the engine works this way ### Flow, not pieces and parts Everything above rests on a rate-based engine. Because ReliaSim models material as flow instead of tracking every item, a thousand year-long runs of the five-machine bottling demo finish in the time it takes to read this page. Why the engine works that way → Get Started ### Now see it on your line. Get notified, or book a call to see it live and scope your system. Schedule a call or get notified × --- # ReliaSim Capabilities: The Engine and the Experiments Source: https://reliasim.com/capabilities.html Capabilities ## Capabilities What the Engine Can Represent ReliaSim® is a composable simulator. A model is a graph of nodes (constraints, buffers, converters, conveyors, splits, merges and batch nodes), and the nodes connect in almost any topology: one straight line, parallel machines, lines that split and merge, or a whole plant of making, storage and packing. However complex the operation, the model is built in its shape instead of being forced into a template. The Methodology covers how you get from line data to a defensible decision. This page covers what sits underneath it: why ReliaSim models flow instead of individual items, the handful of node types a model is built from, and what that design buys you in speed and fidelity. Why the engine works this way ### Pieces and parts, or rates and flow Most simulation was built for discrete assembly, where every item is tracked as its own entity. Point that at a filler running hundreds of units a minute and the model becomes slower than the line it describes. "For years, simulation has worked well in discrete industries like automotive, where each piece of material is treated as an entity. The models are based on item architecture, which is all about pieces and parts. But if you apply that to food production, the model will take longer to run than the actual product, which would make it useless." — Andrew J. Siprelle, founder, in Food Engineering The answer was to model flow instead of items. That rate-based architecture suits high-speed packaging and continuous process, and Fortune-listed companies have trusted it for decades. It’s why the sweeps on the Methodology page finish in seconds instead of overnight, and why a statistical answer is affordable at all. A thousand one-year runs of the five-machine bottling line finish here in about two and a half minutes on a laptop, measured at 0.154 seconds per simulated year. When the published WSC 2020 model was rebuilt in ReliaSim and validated within 1%, the original ExtendSim version of that model ran about 1200× slower. Both ran on the same laptop, for the same one-year simulation. At that rate a single one-year run takes roughly three minutes, and a thousand runs would still be going two days later. Both tools model the same line, and the answers aren’t different. The difference is that one lets you ask a thousand questions before the meeting, and the other makes you pick three and defend the choice. ### The nodes a model is built from A production graph is built from three constructs. The list is short on purpose. A small, opinionated vocabulary is easier to reason about, and it makes a model something you can still read a year later. #### Constraint A unit operation with a rate limit and its own reliability. It runs at its nominal rate until something interrupts it, and it blocks or starves its neighbors when it can’t keep up. On the bottling line: the capper and the labeler. #### Converter Changes the unit of flow. Material arrives measured one way and leaves measured another, and the conversion ratio stays in equilibrium across the change. On the bottling line: the filler turns liquid into filled bottles, the case packer turns bottles into cases, the palletizer turns cases into pallets. #### Buffer Accumulation between operations. A buffer decouples what’s upstream from what’s downstream, so one machine’s stop doesn’t immediately become everyone’s stop. On the bottling line: bulk storage ahead of the fillers, and the warehouse after the palletizer. Every constraint and converter carries its own interrupt signature, which is where the reliability data lands. It has multiple failure modes per unit operation, with a time-to-failure and time-to-repair distribution for each. The signature lets blocking and starving emerge from the model instead of being assumed, and the dominant cause of failure is resolved during simulation. Interrupt data · ReliaStats® ### Where the interrupt numbers come from Every interrupt needs two distributions. Time to failure says how long a machine runs before that stop comes around again, and time to repair says how long the stop lasts. Each failure mode gets its own pair, so a jam and a changeover never share an average. One interrupt: how long the machine runs between stops (blue) and how long each stop lasts (red, dashed). In ReliaSim #### Enter them directly The Interrupt Designer ships with every license. Choose a distribution for time‑to‑failure and time‑to‑repair, set the parameters, and the unit operation carries them from then on. Use it for a line that doesn’t exist yet, or a failure mode nobody has clean history on. In ReliaStats® #### Fit them from line event data When you have historian or event‑log data, ReliaStats fits it. It groups the raw stops by cause, fits all eight distribution types to each group, ranks them with Kolmogorov-Smirnov and Anderson-Darling tests, and exports a file ReliaSim reads directly. Here you measure the shape instead of choosing it. #### Eight distribution types These are the shapes ReliaSim can run, with parameters exactly as ReliaSim stores them. Try any of them in the Designer. Weibull Wear-out and random failures LogNormal Repair times, compounded delays Normal Consistent human-driven processes Exponential Random, independent failures Uniform Limited data, a bounded range Triangular Expert estimates, quick modeling Johnson SU Skewed, heavy-tailed data Fixed / Schedule Shift changes, planned maintenance #### Which shape, and why Most equipment follows the bathtub curve over its life. Early on, defects and installation errors fail out, so the failure rate falls (Weibull with κ below 1). Through its useful life, failures come at random and the rate holds flat (Exponential, or Weibull with κ of 1). Near the end, fatigue and wear push the rate up again (Weibull with κ above 1, or LogNormal). Knowing which phase a machine is in tells you which distribution to fit, and which fix to reach for. ReliaStats is optional. Nothing in ReliaSim depends on it, and a model parameterized by hand is still a valid model. It earns its place once you have event data worth fitting, because a measured interrupt signature is what makes validation possible. It runs as a desktop application of its own or as a feature inside ReliaSim, and the fitting is the same either way. Both tiers are on the pricing page. Try the ReliaStats® tools in the Sandbox About ReliaStats® ### The science of continuous improvement Most improvement plans are a list of projects someone ranked by judgment, tried one at a time on the plant floor. ReliaSim runs fast enough to try every option in the model first, so the plan comes from experiments rather than opinion. ✓ Gain/Loss: what to fix first Rank failure modes by the output a fix gives back, not the minutes they cost. On the demo bottling line, the Labeler’s misalignment and the Filler’s micro stops cost almost the same time, but fixing the micro stops gives back about 60% more output. Try it: what should we fix first? → · Guide ✓ Buffer Sizing Experiment Size every buffer on the line together, in every combination. On the demo bottling line that is three buffers at eleven sizes each, a full design of experiments: 1,331 runs of 90 days. You see where storage pays, where it does nothing, and how much is enough before you pour concrete. On that line, one 50-case buffer before the Palletizer lifts efficiency from 54.3% to 60.1%. Try it: where should the buffer go, and how big? → · Guide ✓ Improvement Roadmap Which fixes, in what order, to reach your target. The roadmap comes from engine runs on the model, not judgment. On the demo line, seven fixes take it from 54.3% to 85.2% with no capital spent. Of 2,000 seven-fix plans picked at random, none reaches 85%; the best gets to 79.8%. Spend capital on one buffer, 100 cases before the Palletizer, and five steps get there: the buffer and four fixes. Try it: the Improvement Roadmap → · Guide ### What that gets you ✓ Pre-Built Components Modular, reusable constructs (Constraints, Converters, and Buffers) let you build production models quickly, with rate control and accumulation behavior built in. ✓ Reliability-Focused Design Built-in reliability interrupts with multiple failure modes per unit operation drive high-fidelity behavior, using competing, cumulative, and wall-clock criteria. ✓ No-Code Model Building You don’t need drag-and-drop. Models are built from text-based markdown and click-connect, so they diff and version like source code. ✓ Unit Conversions Flow stays in equilibrium automatically through unit conversions at any stage in the process, and you can add in-line additions or losses if you need them. ✓ Model-Literal Animation Every run produces its own animation automatically. Playback and scrub controls let you review all nodes' states through time. ✓ ReliaDB The database behind every model. Your rates, products, changeovers and stop data live in tables, and parameter sets are generated from them, one per product or configuration. Migrating a model starts here. Your data never leaves your network. Models, historian extracts and results all stay inside your firewall, and nothing but license and version checks crosses the internet. The full posture is on the security page. ### Now see it on your line The bottling-line models in the Sandbox’s Lines tier run in the browser, with the engine’s saved results for each and no download or license. It’s the fastest way to judge whether this approach fits the way your plant actually behaves. If you’d rather start from the method, the three-step sequence walks Build, Validate and Predict end to end. --- # Five Decisions Every Production System Faces Source: https://reliasim.com/decisions.html ## Five Decisions Every Production System Faces And What It Costs to Guess Decision Engine ### ReliaSim® answers all five decisions every production system faces These are the real capital and operational questions that decide whether your next investment pays off. Predictable wear-out is only 2–4% of downtime on a high-speed line. The other 95% of events aren't predictable before they happen, like bathroom stops and traffic jams on a road trip. You can't schedule around them, so you have to design around them, and these five decisions are how you do it. 1% Published OEE validation 15 min Model construction 0.154 s Per simulated year 3× Typical ROI multiplier 300+ Organizations since the early 1990s Face validity vs. statistical validity 3D animated models look like your line, but they can take 6–8 hours to run a single scenario. Looking like the line is face validity. A playing field for strategic capital decisions needs statistical validity, which means a model validated against your actual OEE and fast enough to run a thousand one-year what-ifs in about two and a half minutes (measured on the bottling demo). Capital decisions (high cost, irreversible) Operational decisions (frequent, hidden impact) 🔧 Which fix yields the biggest gain? Rank by system-level recovery, not downtime hours. The biggest loss on your Pareto is rarely the biggest improvement. ⚡ Run faster or slower? Running faster makes more product but causes more failures, and you don't repair any faster. So there's a best speed for each line. 📦 How much buffer? Protect the bottleneck so upstream and downstream processes never shut it down. Too little starves it and too much ties up capital, and simulation finds the right size. 🔁 Do we need a second machine? Compare equipment redundancy with reliability improvement on equal statistical footing before you spend capital. 🔄 Manual or automatic resupply? Shutting down a perfectly running line every 15 minutes for a manual splice? Downtime analysis says fixing it is worth half a percent, but the simulation usually says 1.5%, which is enough to justify the automatic splicer. "The only way to predict this accurately is through simulation." — Tom Lange, 36 years in manufacturing R&D All you need to start is line event data, meaning a CSV of machine stop-and-start times recorded to the second rather than summaries or rolled-up totals. We handle data cleaning, parameterization and the model build. #### See the evidence behind one of these decisions The case study follows a single throughput decision from Loss Tree to validated model and shows where the two disagree. Open the Sandbox → Read the case study --- # Production Line Simulation Videos Source: https://reliasim.com/videos.html Start here ### What ReliaSim is and why you'd use it #### Introducing ReliaSim A virtual copy of your production line, with every machine, every buffer and all the ways those machines stop. See where the downtime went, then try a change before you spend money on it. 1:25 · Captions #### Simulate Before You Spend The big line decisions, like a new oven or a faster packaging line, come around once every few years. ReliaSim simulates your line from the stop history it already records, so you see what each option returns before the capital is committed. 1:41 · Captions · Plays from YouTube Learn the method ### How simulation works #### New to Simulation? A simulation is a working copy of your line that you can run a thousand times before you commit to anything. It's built from the stop and start times your line already records. 2:29 · Captions · Also on YouTube #### New to Discrete Rate? Most simulation tracks every item as it moves. Discrete rate models the flow as rates between machines and buffers, which is how a high-speed line actually behaves, and why a model runs a year in seconds. 2:18 · Captions · Also on YouTube #### Run the lines from these films The bottling-line demos in these videos run free in your browser. Open one, click a machine, and ask what would happen if you changed it. Open the Sandbox Or apply for a free assessment of your own line --- # Security and Deployment: Desktop, Air-Gapped Source: https://reliasim.com/security.html ## Security & Deployment Your Data Never Leaves Your Network Built for the shop floor, not the cloud ### Your process data never leaves your network. ReliaSim® is desktop-native by design. In a market rushing to move everything to the cloud, we built ReliaSim for the reality of modern manufacturing: segmented networks, isolated OT environments, and IP that should never have left the plant in the first place. Plant Engineers & Operations #### Install and run. No procurement cycle. No SaaS vendor approval. No security review queue. No waiting on IT to greenlight a new cloud service. Download the installer, open your model, simulate in minutes. IT & Security #### No outbound data flow. Air-gap compatible. Runs entirely on the user's machine, inside your firewall. No cloud uploads, no third-party data processor agreements, no exfiltration risk. Operates in physically or logically isolated networks — only license and version checks touch the internet, and even those can be deferred. Executives & Legal #### Your IP stays on-premises. Your simulation models encode proprietary process knowledge — that's trade-secret territory. Keeping it local removes an entire class of vendor risk and shortens compliance review. Friendly to ITAR-, CMMC-, and GxP-bound deployments. Air-gap compatible No cloud dependency Runs inside your firewall ITAR- & CMMC-friendly No SaaS account required Deployment & Data Handling ### Common questions from IT and security reviewers Does ReliaSim require internet access to run? No. After install and license activation, ReliaSim runs entirely offline. The application makes no outbound calls to load data, run simulations, or persist results. Periodic license and version checks occur over HTTPS when a connection is available; these can be deferred for air-gapped deployments. Does the AI / MCP add-on send my model to a third party? Not if you do not want it to. The add-on speaks MCP, so it works with any MCP-compatible assistant — including models running locally on your own hardware, such as Gemma. In that configuration the assistant, the model and your data all stay inside your network, and the air-gap holds. Can ReliaSim run in an air-gapped environment? Yes. ReliaSim is compatible with air-gapped (physically or logically isolated) networks, including OT segments, defense facilities, and validated GxP environments. Offline licensing is available for installations that never touch the internet. Where is my production data stored? On the user's machine, in locations the user controls. Models, input data (CSV / historian extracts), and simulation results are read from and written to local files. ReliaSim has no cloud datastore, no telemetry of model contents, and no third-party data processor. Is there a SaaS or web version? No — and that is deliberate. Manufacturing process knowledge is trade-secret IP, and the operating environment of our buyers is segmented networks. We will not ship a SaaS version that compromises that. Need to share results across a team? You share files, not data exposure. What about the AI / MCP features — does that send my data anywhere? The MCP server is local. It exposes your model to whichever AI assistant you point at it — and you control that choice. If you connect to a hosted assistant, the data your assistant sees is governed by that assistant's policy. If you connect to a local model, nothing leaves the machine. The choice is yours, not ours. How are updates delivered? New releases are announced, and you install them on your own schedule. Updates are not pushed to the modeler's machine, so nothing changes in the middle of quarter-end. How are models backed up? A model is a file. Wherever your laptops and desktops are already backed up, the model is backed up too, and there is no separate backup system to integrate. Data residency works the same way, because the model sits wherever the machine already complies. How does a team share models? Through the tools you already operate, such as Git, OneDrive, SharePoint or a shared drive. Models are shared as files, not through a vendor account. What happens when a modeler leaves? The work is recoverable. Models live in files you control, so the standard handoff applies, and the license is re-issued to the replacement modeler. Is the public website or Sandbox part of the product? No. The website and the Sandbox are marketing surfaces that run demos on sample data. The product is desktop software that runs offline on the modeler's machine. Will you sign our MSA, DPA or NDA? Yes. ChiAha has signed the standard agreements at large enterprises. For a specific compliance regime, such as a regulated industry or a restricted network, a call is the quickest way to work through the details. #### Questions this page did not answer? Deployment, data handling and licensing specifics are quickest to settle in a conversation. Open the sandbox → Schedule a call --- # ReliaSim Training: Six Guided Sessions Source: https://reliasim.com/training.html ## Upcoming Training Two Days at UT Knoxville, or an Hour at Your Desk A two-day public course that counts toward the RMIC® credential, one-hour online sessions on each part of the workflow, and on-site training built around your own line. Next public course ### From Reliability Data to Asset Utilization Making Smarter Decisions with Simulation, a two-day hands-on workshop When Spring 2027 Dates to come. Check back for the schedule. Two days, 14 hours. Where UT Conference Center, Knoxville Reliability & Maintainability Center Fee $1,200 Taught by Andrew & Amber Siprelle of ChiAha, who also teach ExtendSim and Plant Simulation Tell me when dates are set → Registration will open through the University of Tennessee once the spring dates are set. Taught at the Reliability & Maintainability Center, UT Knoxville. This course counts toward the Reliability & Maintainability Implementation Certification (RMIC®). That’s the RMC’s professional credential, earned through a mix of RMC and partner courses plus a guided implementation project. Certification requirements → Reliability programs often mature without throughput improving. Reliability metrics explain what broke, not how the production system responds when something changes. Using full-factory production data, participants evaluate reliability, operational and capital decisions at the system level. That’s where failures, buffers, operating policies and shared resources actually interact. By the end of day two you’ll have built a validated system model from real production data. You’ll have seen why interdependencies rather than isolated failures drive utilization, and you’ll be able to defend a reliability, operational or capital decision with evidence. You don’t need any prior simulation experience. ### Lunch & Learn Sessions Each session is one hour in a small group, live with an instructor, for $60 a session. Bring lunch and leave knowing how to do the task. Six sessions cover the whole workflow, from the discrete-rate worldview through to experiment design, and you can take them in any order. Course 1 #### Discrete Rate Worldview and Modeling Introduction Learn the fundamentals of discrete rate simulation and why it's the preferred approach for high-speed and high-volume production systems. Understand the core concepts behind rate-based modeling and how ReliaSim® applies them. Live Online Small Group Schedule Session Course 2 #### Model Building with Markdown and Click Connect Hands-on training in building production flow models with ReliaSim's markdown syntax and click-connect interface. Build your first model from scratch and learn the text-based model building workflow. Live Online Hands-On Schedule Session Course 3 #### Modeling Interrupts and Reliability An in-depth look at interrupt modeling. It covers failure modes, time-to-failure and time-to-repair distributions, competing vs. cumulative clocks, and how reliability data drives what the simulation does. Live Online Intermediate Schedule Session Course 4 #### Raw Data Parameterization Learn how to take raw historian and event log data and fit it to statistical distributions using ReliaStats. Turn your operational data into the parameters that drive accurate simulation models. Live Online ReliaStats Schedule Session Course 5 #### Model Verification and Validation Make sure your model is accurate and trustworthy. Learn techniques for verifying model logic and validating simulation output against real production data. Live Online Validation Schedule Session Course 6 #### Model Experimentation Put your validated model to work. Run gain/loss experiments, explore trade-offs between buffer capacity and reliability improvements, and identify the failure modes that actually move throughput, rather than the ones that dominate the loss report. Live Online Advanced Schedule Session ### Simulation Capabilities ReliaSim's discrete rate engine models high-speed production systems as flow rather than as individual items. ✓ Rate-Based Modeling Discrete Rate Simulation has been trusted by Fortune-listed companies for decades to simulate high-speed and large-volume bulk flow systems. ✓ Parsimonious Construction A handful of simple, opinionated concepts makes it easier to think about your production process model. Build faster with fewer abstractions. ✓ Pre-Built Components Modular, reusable constructs (Constraints, Converters, and Buffers) let you build production models quickly, with rate control and accumulation behavior built in. ✓ Integrated Factory Physics Nodes automatically simulate blocking and starving based on the dynamics of the line over time. The simulation works out the dominant cause of failure as it runs. ✓ Reliability-Focused Design Integrated reliability interrupts with multiple failure modes per unit operation drive high-fidelity behavior using competing, cumulative, and wall-clock criteria. ✓ No-Code Model Building No drag-and-drop required. Models are built from text-based markdown and click-connect, so they diff and version like source code. ✓ Unit Conversions Flow stays in equilibrium automatically through unit conversions at any stage in the process, and you can add in-line additions or losses if you need them. ✓ Model-Literal Animation Every run produces its own animation automatically. Playback and scrub controls let you review every node's state over time. ✓ Data Stays In Your Firewall All data lives inside your firewall. Only license and version checks go over the internet. It's a full desktop application with no cloud dependency. ### On-site and custom training Lunch & Learn covers the workflow an hour at a time. For teams who want it in one block, or want it taught on their own line, we run full in-person classes and custom on-site programs. #### Full in-person class A complete instructor-led course covering the discrete-rate worldview, model building, interrupt modeling and experiment design end to end. It’s taught in one block rather than an hour at a time. #### On-site custom training At your plant, built around your line and your data. Your team leaves having modeled their own operation rather than a demo, and that’s usually what makes a course get used afterward. #### A simulator for your plant team For operators, supervisors and planners rather than modelers: a game built on your own line, where people practice what to fix first, where storage goes and how the schedule plays out. How it works → Discuss a training plan → ### Ready to Get Started? Schedule a training session or book a demo to see ReliaSim in action on your production data. Contact Us or schedule a call --- # ReliaStats: Reliability Statistics From Downtime Data Source: https://reliasim.com/reliastats.html ## Parameterize the real-world disruption layer of ReliaSim® Most line models simulate what machines are designed to do. ReliaSim’s interrupts model what actually happens, the random failures and repairs that override nominal behavior. ReliaStats® is the tool for setting those interrupts up. It’s desktop software for Mac and Windows that runs entirely on your own machine. Launch the Designer ReliaStats pricing The Designer is free and opens in the ReliaSim Sandbox, next to the line models it feeds. Fitting runs offline, and your event data never leaves your machine. The parameterization job ### Every interrupt needs a time-to-failure and a time-to-repair distribution Every interrupt captures a real-world disruption, a random event that overrides a machine’s nominal behavior. Each one is defined by two distributions: how long a node runs before the event occurs (TTF) and how long recovery takes (TTR). If these are wrong, the simulation will be wrong too. #### TTF controls how often the line is interrupted Time to failure is how long a node operates before an interrupt occurs. That covers random breakdowns, scheduled downtime, wear-out and volume-based triggers. #### TTR decides how disruptive each stop is Time to repair is how long a node is unavailable once interrupted, for maintenance, resets, refills or operator response. TTF and TTR together are the machine’s reliability profile. #### Build and compare distributions yourself Design distributions from scratch, explore fitted parameters, or compare versions side by side. You don’t need a statistician, and nothing is uploaded. “Traditional methods of parameterizing interrupts require dedicated time and attention from an expert to manually manipulate the tape and use their knowledge to distill line event data into cause groups, each with unique TTF and TTR distributions. The process is time-consuming, expensive, and requires an expert.” ReliaSim documentation on interrupt parameterization The fitting workflow ### From line event data to validated ReliaSim parameters The fitting engine turns raw line event data (LEDS) into TTF and TTR distributions, fitted per failure mode and mapped to cause groups, with goodness-of-fit output you can check. They’re ready for ReliaSim. Input #### Line event data One row per stop from a historian or downtime system: where, why, when, or the uptime and downtime in minutes. Engine #### Fitting engine Finds the cause groups automatically, fits all eight distribution types to each, and ranks them with Kolmogorov-Smirnov and Anderson-Darling tests. Output #### Validated parameters A TTF and TTR pair for every interrupt, exported as a file ReliaSim imports directly, then checked against the line’s own history. The loop closes when ReliaSim’s output comes back to ReliaStats and is checked against the same history, interrupt by interrupt. #### Seven tools, one workflow Explore, design, view, compare and validate interrupt distributions in the browser, and fit them automatically in the ReliaStats desktop app. Explorer, Quick Start and Designer are free. Viewer, Comparison, Validation and desktop fitting need a ReliaStats subscription. The five tools with links open in the Sandbox, beside the bottling-line models. Interrupt Quick Start Free The guided way in. Pick an equipment failure pattern and ReliaStats sets a sensible TTF and TTR pair for you, with the availability and stops per shift it implies. Interrupt Designer Free Build a TTF and TTR pair from scratch. See PDF, CDF and survival curves, a p5 to p95 box-and-whisker, a working and failed timeline over a shift, and the availability the pair implies. Interrupt Explorer Free with sign-in Pareto-rank every failure cause at once and overlay their survival curves R(t), straight from .xlsx or .csv stop logs. It runs locally, so your data never leaves your machine. Interrupt Fitting Subscription · desktop app Import raw historian event logs. ReliaStats identifies cause groups, fits and ranks all eight distribution types with K-S and Anderson-Darling tests, and exports a ReliaSim-ready file. Interrupt Viewer Subscription Load any ReliaSim interrupt file and click through every interrupt’s uptime and downtime distributions, a fast audit of a full model’s parameters. Interrupt Comparison Subscription Two interrupt files side by side, with every numeric difference shown, rows marked by size of change and the curves overlaid. Interrupt Validation Subscription Source against simulated availability, interrupt by interrupt, with 95% prediction-interval and 99% confidence-interval bands. Points on the diagonal match history, and points outside the bands show where to refine. Where it fits ### Where ReliaStats fits in the ReliaSim process ReliaStats owns the data step. It turns raw event history into interrupt distributions, then closes the loop by checking the simulation’s results against the same history. 1 #### Build Define the production line in ReliaSim and parameterize each machine’s interrupt behavior from raw historian event data. This is the ReliaStats step 2 #### Validate Check the simulation against the line’s measured performance. A published food-plant model rebuilt in ReliaSim matched measured OEE within 1% (case study). 3 #### Decide Run what-if scenarios and commit capital where the validated model says it belongs, without touching the line. The ReliaSim method covers all three steps. #### Reliability statistics guides - Downtime data analysis for production lines - Weibull analysis of downtime data - MTBF vs MTTR: outputs, not inputs - Downtime Pareto: frequency, duration and lost throughput - Availability vs reliability Distribution support ### All 8 ReliaSim distribution types Every distribution ReliaSim supports, with parameters exactly as ReliaSim stores them, including real-space mean and standard deviation for LogNormal. #### Weibull λ scale, κ shape, γ location Shape κ < 1 is infant mortality, κ = 1 is random, κ > 1 is wear-out. The most versatile reliability distribution. Wear-out and random failures #### LogNormal mean x̄, std dev s Right-skewed: most values small, with occasional large outliers. A good fit for variable repair times. Repair times, compounded delays #### Normal μ mean, σ std dev Symmetric around the mean. Use it carefully for TTF, since it allows negative values unless constrained. Consistent human-driven processes #### Exponential λ rate, mean = 1/λ Memoryless: the chance of failure doesn’t grow with age, so the failure rate is constant. Random, independent failures #### Uniform min, max Equal probability across a range. Useful when a value can fall anywhere in a range and none is preferred. Limited data, bounded range #### Triangular min, max, mode A simple three-point estimate, easy to explain when only expert estimates are available. Expert estimates, quick modeling #### Johnson SU γ, δ, ξ, λ A flexible four-parameter family that handles skewed and heavy-tailed data simpler distributions can’t capture. Complex empirical data #### Fixed / Schedule x value Deterministic: it always returns the same value. Models predictable scheduled events with no variance. Shift changes, planned maintenance Reliability fundamentals ### The bathtub curve Every component follows a failure-rate pattern over its life. Knowing which phase your equipment is in tells you which distribution to use, and which fix to reach for. #### Infant mortality Weibull (κ < 1) Defects, installation errors and manufacturing variation cause early failures that decrease over time. The component is most likely to fail soon after it goes into service. In the Designer, a Weibull with κ < 1 captures this. The hazard is highest at t = 0 and falls as the weak units fail out. Burn-in testing, strict incoming QA, early replacement schedules #### Random failure Exponential, Weibull (κ = 1) Failures occur independently of age: external shocks, operator error, voltage spikes. The failure rate is constant, so knowing how long a component has run tells you nothing about when it will fail next. This is the useful-life phase, and the memoryless Exponential distribution is the standard model. Redundancy, condition monitoring, failure mode analysis #### Wear-out Weibull (κ > 1), LogNormal Fatigue, corrosion, erosion and material degradation make the failure rate rise with age. Failures become more predictable, and more preventable, near end of life. Weibull with κ > 1 fits wear-out well. κ of 2 to 3 is common for mechanical fatigue, and a higher κ means failures cluster more tightly. Scheduled replacement, life-limit programs ### Try the Designer Set any TTF and TTR pair and see the curves, percentiles and availability move. It runs in the Sandbox with no account, right beside the line models, so you can click a machine and open its curves. Launch the Designer Book a live walkthrough Ready to fit your own event data? Buy & download ReliaStats for Mac or Windows. --- # Pricing: ReliaSim and ReliaStats Licenses Source: https://reliasim.com/pricing.html ## Pricing ReliaSim® is downloadable desktop software, licensed per user each year. It doesn't depend on the cloud or need any integration. Your production data never leaves your network, and it works air-gapped for OT, defense and validated environments. ### Every price is on the page Published prices, so you can budget before you talk to anyone. Tax is applied at checkout, and purchase orders are welcome. - $8,000ReliaSim desktop license, per user per year - $1,800ReliaStats distribution fitting, per user per year - $28,000ReliaSim CLI cloud add-on, per user per year (Early Access) - $60Lunch & Learn session, one hour, live - $0Sandbox, desktop demo and ReliaStats Designer - $0Line assessment: one question about your line, answered on a model Want to see it on your own line first? Apply for a free line assessment → #### Start free Three ways to use ReliaSim without paying anything. Most people should start here. Start here Browser Sandbox Four tiers of models, from flow to a real bottling line, with the engine’s saved results and no download, sign-up or install. Open the Sandbox → Desktop demo The real application, playing our pre-built models. Run them and explore the results, with no license key needed. Download → Academic licenses Free for teaching and non-commercial research. Terms → One license, Mac or Windows. The full ReliaSim simulation engine on your desktop. ReliaSim Mac (Apple Silicon) or Windows 11 $8,000 USD per user / year · billed annually Buy Now demo (player of pre-built models) -> trial (full product, X days; not built yet) -> purchase (Amber, 2026-09-28) --> Not ready to buy? Try the demo first → #### What the license covers - ✓ Mac (Apple Silicon) or Windows 11 desktop - ✓ Node-locked license - ✓ Annual subscription · auto-renews - ✓ Phone & cloud-based messaging support - ✓ Share models with the free demo, with no seat needed to view - ✓ Converts to the free demo if the license lapses ReliaSim CLI Cloud add-on to ReliaSim · Early Access $28,000 USD per user / year · billed annually Talk to us or email reliasim@chiaha.com for a quote or PO #### What the add-on covers - ✓ Run your models from the command line, scripts and scheduled jobs - ✓ Set the experiment, parameter set and seed on each run - ✓ Results as JSON, plus constraint and interrupt summaries as CSV - ✓ Runs in a private ChiAha cloud, separate from other customers - ✓ One named user, with a personal access key - ✓ Enterprise application, customizable to your operation Early Access runs Single Run experiments. Multi Run and Gain/Loss experiments are in development. The CLI sends your models to our cloud, so if your data has to stay on site, use the desktop license. It's licensed for your own operations. Engineering and consulting firms doing client work, please talk to us first. #### Included with every license - ✓ Full ReliaSim simulation engine - ✓ Click-connect model builder - ✓ Interrupt Designer - ✓ Gain/Loss experimentation - ✓ Multi-run analysis - ✓ Bivariate validation - ✓ Phone & cloud-based messaging support - ✓ All updates during subscription Tax is applied at checkout as required by state jurisdiction. License is node-locked to a single machine. Contact us to transfer between machines. ### Free Designer, paid fitting ReliaStats® is ReliaSim’s companion for interrupt parameterization. It fits time-to-failure and time-to-repair distributions from your line event data and hands ReliaSim the parameters. Start free with the Designer, then add the desktop app for automated fitting and the Viewer, Comparison and Validation tools. Mac and Windows desktop · per-user annual license · runs offline · what ReliaStats does #### ReliaStats Designer Free, no account or credit card needed $0 per user, forever - ✓ Interrupt Designer: a TTF and TTR pair with a shift timeline - ✓ Box-and-whisker percentile view, p5 to p95 - ✓ All 8 ReliaSim distribution types - ✓ PDF, CDF and survival curves - ✓ Availability from mean TTF and mean TTR - ✓ Download it and run it offline Launch the Designer #### ReliaStats The full fitting and review suite $1,800 USD per user / year · billed annually · purchase orders welcome · node-locked · tax applied at checkout - ✓ Everything in the Designer - ✓ Import raw failure and repair event logs - ✓ Automatic cause-group identification - ✓ Automated fitting to all 8 types, ranked by Kolmogorov-Smirnov and Anderson-Darling - ✓ Export a fitted CSV for ReliaSim import - ✓ Interrupt Viewer, Comparison and Validation - ✓ Phone and dedicated support Buy & download ReliaStats Fitting runs inside the downloaded desktop app, with no cloud dependency, so your event data never leaves your computer. Both plans keep your data on your machine, run offline for air-gapped sites, and get updates while the subscription is active. #### Compare ReliaStats plans FeatureDesignerReliaStats Visualization and design Interrupt DesignerTTF and TTR pair with shift timeline and box-and-whisker✓✓ All 8 distribution typesWeibull, LogNormal, Normal, Exponential, Uniform, Triangular, Johnson SU, Fixed✓✓ PDF, CDF and survival curves✓✓ AvailabilityFrom mean TTF and mean TTR✓✓ Review and comparison Interrupt ViewerBrowse any ReliaSim interrupt file—✓ Interrupt ComparisonTwo files side by side, every difference shown—✓ Interrupt ValidationSource vs simulated availability with PI and CI bands—✓ Distribution fitting Import raw event logsHistorian data, failure and repair timestamps—✓ Automated distribution fittingFits all 8 types and ranks them by goodness of fit—✓ Goodness-of-fit testsKolmogorov-Smirnov and Anderson-Darling—✓ Export fitted CSV for ReliaSim—✓ License and support LicenseNone neededNode-locked, per user BillingFreeAnnual SupportCommunityPhone and dedicated messaging #### ReliaStats questions Do I need an account for the free Designer? No. The Designer runs in your browser, or as a downloaded file, with no account and no credit card. Signing in with a free account adds the Interrupt Explorer and lets us tell you about new releases. What is ReliaStats replacing? ReliaStats is the evolution of Wishbone, ChiAha’s original distribution fitting tool. It automates the expert-heavy job of turning raw historian event data into TTF and TTR distributions ready for ReliaSim. How does ReliaStats compare to JMP? General-purpose statistical suites run about $1,300 to $1,900 or more per user per year. JMP starts around $1,320 a year and Minitab around $1,851. ReliaStats is built for reliability engineers working with ReliaSim. It understands the interrupt model and writes ReliaSim-ready CSVs, at $1,800 per user per year. Is my data safe? Yes. ReliaStats is desktop software that runs entirely on your own machine. Fitting and analysis happen inside the downloaded application, no event data is uploaded to any server, and it runs fully offline, so it suits OT and validated environments. What does node-locked mean? The license is tied to a single machine. If you need to move to a different machine, contact us. For team licensing, see Enterprise and purchase orders below. Is ReliaStats available now? Yes. It’s shipping today for Mac and Windows. A purchase includes the full fitting toolset, and subscribers get updates throughout their subscription year. ### Coming soon: one model, from the network down to the machine ReliaSim is becoming one product in four tiers. Each tier is a whole product, not a part you add to something else. Every tier does both manufacturing and supply chain simulation, and what changes is how deep it goes in each. Not yet available to buy. Pricing will be announced at launch. Basic Both disciplines, any size, one interrupt deep. - Basic manufacturing and basic supply chain - No size limit, with as many nodes and sites as you like and every node type - One interrupt per constraint, simple failure behavior - A reduced experiment set - Resources assumed sufficient; no sourcing optimization or greenfield siting Plant Your plant at full resolution, with no cap on how much of it you model. - Unlimited interrupts per constraint, so a dozen named failure modes instead of one rolled-up failure - Finite resources, meaning the operators, tools and changeover crews the plant actually has - Flow and item nodes - The full experiment set, including gain/loss - Reliability structure per unit operation, fitted per failure mode Supply Chain Every site and the lanes between them, plus everything Basic assumes away. - Every site, and the lanes between them - Finite resources, meaning the trucks, bays and forklifts that move the product - Shipping and receiving at real resolution - Labor and cost accounting - Sourcing optimization by supplier, lane and volume - Greenfield analysis of where capacity should sit Plant & Supply Chain The full network toolkit pointed at a plant that fails the way yours does. - Sourcing decisions made against real failure behavior, not a per-SKU average - Finite resources, shipping and receiving, and cost accounting, all seeing your real plant model - Network → site → line → this machine, this interrupt, this day AI / MCP add-on Connect an assistant to your validated model. Goes on top of any tier. - MCP tools to inspect, simulate and analyze - Natural-language questions via Claude - Run scenarios conversationally - Works with any MCP-compatible AI - Runs against a local model (Gemma and others), so air-gapped sites stay air-gapped You can try it now, free, on the Sandbox’s sample models. See ReliaSim in Claude or ChatGPT. Line event data fitting is ReliaStats, above, and goes on top of any tier. Robust optimization, which searches the solution space rather than scoring the plan you already chose, is quoted on a call. A supply chain study on your own network is scoped with you as a project; talk to us. Join the wait list One list covers every tier and the AI add-on. Tell us which one interests you and we’ll let you know at launch, with no call needed. #### You license modelers, not viewers Anyone using the free demo can open and run a model built on a licensed seat. Send the file to a plant manager, a controls engineer or a capital review board, and they can run the scenarios themselves without a license. Your own license turns into that free demo if you ever stop subscribing, so the models you build stay usable either way. #### What the license has been worth elsewhere A bottling line finds $1.5M in hidden throughput by re-ranking two failure modes its loss report calls equal. An olive plant recovers 15% more throughput with no new equipment. A soap plant consolidation catches a configuration that would need a $4M retrofit, in the model, before the plant is built. The $4M retrofit alone is 500× the annual license. All case studies → ### Training Lunch & Learn sessions are one hour, live with an instructor, and $60 each. The six sessions cover the workflow from your first model through to experiment design. Full in-person classes and on-site custom training are quoted directly. See the schedule → ### Enterprise & Purchase Orders Volume discounts apply from five licenses upward. Purchase orders, multi-user and site licensing are quoted directly, so contact the ChiAha team. Schedule a call or email reliasim@chiaha.com for a quote or PO --- # Can I Build a Production Line Simulation With ChatGPT? Source: https://reliasim.com/guides/build-a-simulation-with-chatgpt.html ## Can I Build a Production Line Simulation With ChatGPT? Yes. Getting One That Matches Your Plant Is the Work Method Guide ## Can I Build a Production Line Simulation With ChatGPT? Yes. Getting One That Matches Your Plant Is the Work Ask ChatGPT, Claude or any capable assistant for a simulation of a filler, a capper, a labeler and a palletizer with buffers between them, and you’ll get code that runs, often in a few minutes. Anyone can get a simulation that runs. The hard part is one that matches your plant, and that part doesn’t happen in the chat. ### The honest answer: yes, it can write one A language model has read a great deal of simulation code. Asked for a discrete event model of a packaging line in Python or another language, it will usually produce something reasonable: machines with speeds, random failures and repairs, buffers that fill and drain, and a report of output and utilization at the end. It runs, and it produces numbers. That’s useful. It’s a fast way to learn how a simulation is put together, to sketch an idea, or to explain to a colleague why a buffer helps. The trouble starts when the numbers are used to decide something about a real line. ### Running isn’t the same as right The code needs inputs: how often each machine stops, for how long, how fast it runs, how big each buffer is. The assistant doesn’t have your line’s stop history, so it fills those in with plausible guesses, such as a round mean time between failures, an exponential repair time, or a rated speed from a brochure. The code runs just the same. Code that runs produces numbers, and numbers look like answers. Nothing in the conversation compares them with what your plant actually made. And if you ask for a change and the assistant regenerates the code, the model’s logic can change with it, so whatever you checked last week may not hold for this week’s version. The question isn’t whether the code runs. It’s whether the model reproduced a period your plant already measured, before anyone asked it to predict one. ### What validation takes Validation is most of the work in a real simulation study, and it’s the same whether a person or an assistant wrote the code. - Measured data from the real line. Line event data or stop logs (when each machine stopped, why and for how long), speeds, buffer sizes and production counts. Textbook defaults aren’t measurements. Downtime data analysis shows how a stop log becomes model inputs. - A distribution for each failure mode. Not one average per machine. Frequent short stops and rare long ones cost a line very differently, and a single average hides that. See MTBF and MTTR are outputs, not inputs. - A check against measured output over a period. Run the model over months to a year the plant has already measured, and compare simulated output or OEE with what the plant produced over the same span. - Accuracy cause by cause. Each machine’s availability, the stops for each failure mode, and starved and blocked time should match, not only the line total. A total can match while one cause is overstated and another understated. - An out-of-sample check. Fit the inputs on one period and score the model on another it has never seen, or freeze the model before looking at the scoring data. - A stated accuracy measure. Percentage points or percent, one run or the average of many replications, each product or only the total. None of these steps is exotic. They just need data the assistant doesn’t have and a comparison the conversation never makes. ### How to check any model, whoever built it The same questions work on a model an assistant wrote, one a consultant built, or one a vendor is selling. How to check a digital twin’s accuracy claim sets out six of them: accurate against what, over what period, tested out of sample, matched part by part, what “within N” means, and who checked it. If a model can’t answer them, its predictions haven’t been earned yet. ### What a published validation looks like A food plant model that Fischel and Lange published at the 2020 Winter Simulation Conference is a discrete rate model with per-failure-mode reliability. Before it was used for a decision, a one-year simulation had to land within 1% of the plant’s measured OEE, and it did. The model was rebuilt in ReliaSim® and independently validated by Tom Lange. The 1% figure comes from that one published plant validation; it isn’t a guarantee for every model. Details: the case study. ### The alternative: let your AI drive a validated engine You don’t have to choose between an assistant and a validated model. The assistant can be the interface, and the engine can do the simulating. Ask in plain English; the answers come from a validated model, not from the language model. Two ways to use an assistant What produces the numberChecked against a plant? Assistant writes the simulationcode it generated, with parameters it guessedOnly if you do the validation yourself Assistant drives ReliaSimthe ReliaSim engine, running a model built from the line’s own stop historyThe engine has a published plant validation; each model is checked against its own line before it predicts - The public MCP server at https://reliasim.com/mcp is free, with no account or key. Claude, ChatGPT, Cursor and other MCP clients can ask about eight reference bottling-line models and get saved ReliaSim engine results back. How to connect it. - The ReliaSim CLI, a cloud add-on in Early Access, lets an assistant that can run commands, such as Claude Code, run your own ReliaSim models, set the experiment, parameter set and seed on each run, and read the results as JSON. Early Access runs Single Run experiments; Multi Run and Gain/Loss experiments are in development. Models themselves are built in the ReliaSim desktop app from your line’s stop history. The assistant runs and experiments with the model; it doesn’t invent the line. ### Questions people ask #### Is the code ChatGPT writes wrong? Not necessarily. The logic may be sound. What’s missing is evidence that its inputs and behavior match your line, and that only comes from comparing it with measured output. #### Can I validate an AI-written model myself? Yes, with the steps above: real stop data, a distribution per failure mode, a comparison over a measured period, cause by cause, out of sample. Freeze the code before you score it, so a regeneration doesn’t change what you checked. #### Where does the assistant help most? Asking a validated model questions without learning its interface, reading results back in plain language, and writing the summary for the people who make the decision. See why an LLM can’t answer what-if on its own. Use of ReliaSim, its MCP server and the CLI is governed by the ChiAha Software License (/license), including its restrictions on reverse engineering, AI training on outputs and scraping. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Production Line Simulation Guides Source: https://reliasim.com/guides.html Learn ## ReliaSim® Guides Throughput, Explained Properly Practical explanations of what decides throughput on a real line, written for the people who have to defend the number in a meeting. Also in Learn - Methodology - Videos - Discrete rate simulation - Supply chain simulation - Training - Events - Academic - Docs Looking for worked examples? The case studies cover real lines with real numbers, including a bottling line that found $1.5M, an olive plant that found 15%, and a soap plant that avoided a $4M retrofit. For leaders · Start here ### Why Simulation Belongs in the Capital Plan Capital gets one shot. It’s the stops that drive your output, and the loss report ranks them wrong. How a playing field shows what a change returns before you spend. Read the guide → For leaders ### How a ReliaSim Project Runs From the first question to the decision: what you bring, what happens, what you learn and what you get at each step. See the steps → For buyers · Validation ### How to Check a Digital Twin’s Accuracy Claim Six questions that turn any vendor’s accuracy claim into something you can test: against what, over what period, out of sample, part by part, and what “within N points” should mean. Read the guide → AI · Validation ### Can I Build a Production Line Simulation With ChatGPT? Yes, it can write code that runs. Getting one that matches your plant is the work: what validation takes, how to check any model, and how to let your AI drive a validated engine instead. Read the guide → OEE · Calculator ### Line OEE vs Machine OEE How to calculate OEE, why a line is never the average of its machines, and a calculator for up to six machines in series. Open the guide and calculator → Throughput ### How Big Should a Buffer Be? Lean says inventory is waste. Theory of Constraints says protect the constraint. Here’s why the argument never settles, and how to settle it for your line. Read the guide → Comparison ### Spreadsheet, Dashboard, AI or Simulation? A loss tree averages away interactions, a dashboard only reports what already happened, and a model trained on history can’t answer for a line that doesn’t exist yet. Here’s what each tool can tell you. Read the guide → Capacity ### The Hidden Factory: Asset Efficiency vs OEE Capacity you already own that OEE can’t see, because it leaves unscheduled time out. Also why Asset Efficiency and OEE can agree within 1% on a 24/7 line and differ by 30 points on one shift. Read the guide → Prioritization ### Which Loss to Fix First Ranking by minutes lost ranks occurrence, not cost. A stoppage on a buffered machine costs nothing. Rank by what comes back instead. Read the guide → Prioritization ### Lean, TPM or TOC: Which Fix First? Three schools, three different first fixes for the same bottling line. A validated model scores all three, and none finds the best move. Read the guide → Prioritization ### The Improvement Roadmap: Which Fixes, in What Order Engine runs on a model find the order. With no capital, seven fixes take our demo line from 54% to 85%; spend capital on one buffer, 100 cases before the Palletizer, and five steps do it. Of 2,000 random plans, none gets there. Read the guide → Benchmarks ### Is 85% OEE Achievable on Your Line? It’s a single-machine benchmark. Five world-class machines in series with no buffering give a line OEE near 44%. Read the guide → Diagnostics ### Find the Bottleneck: Starved vs Blocked The busiest-looking machine is rarely the constraint. Read starved and blocked time, and the buffers beside each stop, to find the step that actually limits output. Read the guide → OEE ### OEE Improvement Tradeoffs Speed against stops, downtime against buffers, machine OEE against line output. Loss/gain analysis and buffer tradeoff price each fix before you spend. Read the guide → Method ### Test a Line Change Across Every Product A packing, staffing or equipment change has to work for every product a line makes. One food plant ran about 30,000 simulations, every line in every configuration for every product, from the command line. Read the guide → Constraints ### Theory of Constraints Simulation The five focusing steps assume you can find the constraint. On a real line it moves with downtime, mix and schedule. This guide shows how to find it, buffer it and see where it goes next. Read the guide → Throughput ### Capacity Without Capital What to change before you buy: the failure mode that gives most back, where storage goes, and a schedule that stops fighting the plant. Engine-run figures from the demo lines. Read the guide → Training ### A Flight Simulator for Your Plant Let your team practice on a playing field built from your own line: what to fix first, where storage goes, the shift ahead. A game on your own stop data. Read the guide → Reliability ### Reliability Block Diagram vs Simulation An RBD gives availability, not throughput. This covers why a series diagram misstates a line with storage between machines, and where RBDs still belong. Read the guide → Reliability ### RAM Analysis Reliability, availability and maintainability, defined. What a RAM study answers, how established RAM tools approach it, and where discrete rate simulation fits on high-speed lines. Read the guide → Capacity ### Throughput vs Capacity Rated speed never shows up on the report. This covers where capacity goes before it becomes output, and why only the constraint sets throughput. Read the guide → Method ### An LLM Will Answer Your Question. That’s the Problem. A chatbot will tell you whether a second palletizer gets you to volume. It answers fluently, with a number, and with no model of your line. That’s worse than being wrong, and this guide explains why. Read the guide → Losses ### Why Predictive Maintenance Can’t Answer What-If Condition monitoring forecasts when a machine fails, from the plant you already have. It can’t say what a change returns. Read the guide → Losses ### Micro-Stops vs Breakdowns The recorded loss is the same, but the recovery isn’t. Frequent short stops can cost more throughput than rare long ones, and they hide in performance loss. Read the guide → Lean ### Value Stream Map Simulation A static map of averages has no clock, so it hides the moving constraint and what buffers are doing. Here’s how to turn a current-state VSM into a model you can validate. Read the guide → ### Reliability statistics Turning stop logs into the time-to-failure and time-to-repair distributions a line model runs on. Fitting them from line event data is the job of ReliaStats®. Start here ### Downtime Data Analysis for Production Lines From a stop log to failure-mode distributions a simulation can run: event data, cause groups, TTF and TTR, fitting and validation. Read the guide → Downtime ### Downtime Pareto: Frequency, Duration and Lost Throughput Rank stops by count, by minutes or by production recovered. Why the three charts disagree and how to get from a Pareto to root cause. Read the guide → Reliability ### MTBF vs MTTR: Outputs, Not Inputs MTBF and MTTR summarize what happened. A model needs TTF and TTR distributions per failure mode, and MTBF, MTTR and OEE come out of the run. Read the guide → Reliability ### Weibull Analysis of Downtime Data What the shape and scale parameters mean, why to fit each failure mode separately, goodness of fit, and how fits feed a line simulation. Read the guide → Reliability ### Availability vs Reliability The share of time up versus the chance of running without a stop. Inherent vs operational availability, and why buffers change which one matters. Read the guide → ### Supply chain Network design above the plant: where facilities go, how product is sourced, and whether the design holds up once demand and lead times vary. The demos run in the Networks tier of the Sandbox, and each has its own page in the free supply chain simulator index. Start here ### What Is Supply Chain Simulation? An optimizer picks the network. A simulation checks whether it survives variable demand, late suppliers and long lead times. Why a redesign needs both, plus greenfield vs brownfield design. Read the guide → Tariffs ### Tariff Network Redesign Treat the tariff as one more cost in the network model, re-optimize sourcing and footprint, then simulate the redesign on the same model before you move a plant. Read the guide → Simulation ### How Supply Chain Simulation Works The event list, ordering policy and inventory position behind a discrete-event network model, what a run shows, and the limits of the demos. Read the guide → Optimization ### Supply Chain Optimization vs Simulation Decision variables, a landed-cost objective and constraints: the mixed-integer model behind network design, its classic problem types and where it stops. Read the guide → Network design ### Greenfield Network Design Where would the DCs go if you started over? The siting math, location-allocation for several sites, and how greenfield differs from brownfield and footprint rationalization. Read the guide → Validation ### How to Know Your Supply Chain Model Is Right Reproduce a period you lived through before trusting any scenario: what to compare, why the parts matter more than the total, and holding out a period. Read the guide → Siting method ### Center of Gravity Analysis The balance point of your demand, in plain terms: how to run one, a worked example, what it leaves out, and how to test the answer. Read the guide → Network design ### How Many Distribution Centers Do You Need? Distance falls with each added DC while fixed cost and inventory rise. Reading the elbow, the square root law, and testing the count. Read the guide → Inventory ### The Bullwhip Effect Why a small rush at the shelf becomes a big wave at the plant: the four causes, the bullwhip ratio, fill rate vs on-time fill, and why common fixes backfire. Read the guide → Inventory ### Safety Stock Simulation Where the safety stock formula stops: its assumptions, pooling at a central DC against holding stock near customers, and testing a policy over time. Read the guide → Network Design ### Distribution Network Design How many DCs, where, which customers each serves and where stock sits. Redesign the network you have, then watch it run. Read the guide → Inventory ### Multi-Echelon Inventory Set stock across plant, DC and regional tiers together. Why site-by-site targets over-stock, and how simulation tests the result. Read the guide → Reference ### Supply Chain Glossary Short definitions of network design, inventory and simulation terms, each linked to the guide that goes into it. Read the guide → ### Simulation methods How the main simulation methods differ, and where discrete rate simulation, the method ReliaSim is built on, fits among them. The demos run in the Discrete Rate tier of the Sandbox. Start here ### What Is Discrete Rate Simulation? Flow modeled as rates between machines and buffers, with work done only when a rate changes. The three primitives (constraints, buffers and interrupts), where the method fits and where it came from. Read the overview → Comparison ### Discrete Rate vs Discrete Event Simulation What counts as an event in each, where discrete event struggles on high-speed lines, how to choose, and which tools use which method. Read the guide → History ### History of Discrete Rate Simulation Created by Andrew Siprelle in 1990 as bulk flow simulation: the 1995 paper, the rename in the late 2000s, and three decades of published work. Read the guide → History ### The Lineage of Discrete Rate Simulation Five decades from Pritsker’s SLAM to today: what each era contributed, what carried forward, and the full bibliography. Read the guide → Migration ### Migrating a Simulation Model Move a model from ExtendSim or Plant Simulation: its data into ReliaDB, the layout rebuilt, and parity proved against the old model and the plant. Read the guide → Methods ### Which Simulation Method Fits? Discrete event, discrete rate, continuous, agent-based, system dynamics and Monte Carlo, compared by what each treats as state and how its clock moves. Read the guide → Comparison ### Monte Carlo vs Discrete Rate Simulation A Monte Carlo spreadsheet has no clock. When that’s fine, and when buffers, blocking and the length of each stop mean you need a dynamic model. Read the guide → Definitions ### Digital Twin vs Simulation The difference is the data connection and whether the model is validated, not how realistic it looks. Digital model, shadow and twin, and when a live feed is worth it. Read the guide → Looking for product reference instead, like menus, file formats and node parameters? You’ll find it in the ReliaSim documentation. #### See the ideas on a real line model Every guide above describes something a line model can show. The Sandbox’s four tiers cover flow models, fitting stop data, a real bottling line and supply-chain networks, each with saved engine results. Open the Sandbox → Read the case study --- # How to Check a Digital Twin's Accuracy Claim Source: https://reliasim.com/guides/check-a-digital-twin-accuracy-claim.html ## How to Check a Digital Twin’s Accuracy Claim Six Questions to Ask Before You Trust a Line Simulation Buyer’s Guide ## How to Check a Digital Twin’s Accuracy Claim Six Questions to Ask Before You Trust a Line Simulation Every line simulation vendor says its model is accurate. Very few say accurate against what, over what period, or how it was checked. This guide gives you the questions that turn an accuracy claim into something you can test, whoever the vendor is, us included. ### Why the claim needs checking A model can be made to match almost any single number. Tune enough parameters against last month’s OEE and the model will reproduce last month’s OEE, whether or not it understands the line. That match tells you the model can be fitted. It doesn’t tell you the model can predict, and prediction is the only reason to buy it. You’ll use it to ask what happens if you add a buffer, speed up a filler or fix a failure mode, and none of those futures has been measured yet. The questions below separate a model that has been fitted from one that has been validated. ### 1. Accurate against what? The only reference that counts is the plant’s own measured performance: OEE, or good output against scheduled time, taken from the line’s own records. A match against rated speeds, a vendor benchmark, another model or a demonstration line says nothing about yours. Ask: What measured figure was the model compared with, and where did that figure come from? ### 2. Over what period? Lines lose most of their output to stops, and the stops that matter most are often the rare, long ones. A one-shift or one-week comparison can miss them entirely. The comparison period should be long enough to include the line’s normal mix of products, changeovers and long repairs. Months is a reasonable floor, and a year covers seasonal mix. The simulated period should match the measured one too. A one-year simulation compared with a year of plant data is a like-for-like test, and a single short run compared with an annual average is not. Ask: How long was the comparison period, and did the simulated run cover the same span? ### 3. Was it tested out of sample? This is the question that matters most. If the failure and repair data were fitted on the same weeks the model was scored on, a good match is partly guaranteed. The stronger test fits the model on one period and scores it on another the model has never seen. Failing that, the model should be frozen, with no more tuning, before the scoring data is looked at. Ask: Which period was used to build and fit the model, and which period was used to score it? Was anything adjusted after the scoring data was seen? ### 4. Does it match part by part, not just in total? A line-level OEE can match while the parts underneath are wrong. One machine’s stops can be overstated and another’s understated, and the errors cancel. That model will still give the wrong answer the first time you ask what fixing one of those machines is worth, which is exactly the question you bought it for. A validated model should also reproduce the parts: - Each machine’s availability, and the stop counts and durations for each failure mode. - Starved and blocked time for each machine, which shows whether the model’s buffers and speeds interact the way the line’s do. Finding the bottleneck explains why these two figures matter. - Output by product or product category, because a line that runs several formats rarely runs them all equally well. Per-failure-mode detail is also what makes the model’s gains believable. The published paper below puts it plainly: with one averaged failure mode per machine, the gains and losses of different fixes would be “less accurate and essentially identical to each other.” Micro-stops vs breakdowns shows why. Ask: Show me the comparison for each machine and each product category, not just the line total. ### 5. What does “within N” mean? “Within 2%” can mean several different things, and the difference is large. - Points or percent. At 60% OEE, two percentage points is 58% to 62%. Two percent relative is 58.8% to 61.2%. Ask which one is meant. - One run or many. A simulation with random stops gives a different answer on every run. A fair claim compares the average over many replications with the measured figure and reports the spread. A single lucky run proves little. - Line total or every category. “Within N points for the plant” is a weaker claim than “within N points for each product category.” - Before or after tuning. See question 3. A precise claim reads something like this: the average of the replications of a one-year run differs from a year of measured OEE by less than N percentage points, for each product category, with the model built from a period other than the one it was scored on. The closer a vendor’s claim comes to that sentence, the more it’s worth. Ask: Points or percent, how many replications, and at what level of detail? ### 6. Who checked it, and can you see it? A claim made in a sales deck is weaker than one made in a peer-reviewed paper. A model checked by the vendor is weaker than one checked by someone who doesn’t sell it. The best evidence is a published method, an independent validator and data you can inspect. Ask: Is the validation published? Who did it? Can I see the comparison, and better still, run the same test on my own line? ### The checklist QuestionA weak answerA strong answer Against what?Rated speeds, a benchmark, another modelThe plant’s own measured OEE or output Over what period?A shift or a weekMonths to a year, simulated over the same span Out of sample?Fitted and scored on the same dataFitted on one period, scored on another, or frozen first Part by part?Line total onlyEach machine, failure mode and product category Within N of what?Unstated, or one runPercentage points, averaged over replications, with the spread Who checked it?The vendor, in a deckPublished, independently validated, open to inspection ### Our published validation Here is how ReliaSim answers the same questions. Fischel and Lange modeled a real multi-line food plant and published the work at the 2020 Winter Simulation Conference. Their model is a discrete rate and reliability model with up to twenty failure modes on each of more than twenty unit operations. Before anyone used it for a decision, a one-year simulation had to land within 1% of the plant’s actual OEE for each product category, and it did. That published model was then rebuilt in ReliaSim and independently validated by Tom Lange, a co-author of the paper. The ReliaSim model came within 1% of the plant’s measured OEE, and within 1% of the original model as well. Here “within 1%” means the simulated OEE differs from the measured OEE by less than one percentage point. - Against what: the plant’s measured OEE. - Over what period: a one-year simulation compared with a year of plant data. - Part by part: per failure mode in the model, and scored for each product category. - Who checked it: published at a peer-reviewed conference, and the ReliaSim rebuild validated by one of the paper’s authors. The full write-up is the published OEE validation case study, and ReliaSim vs ExtendSim covers the rebuild and the run times. The same build, validate, then predict order is the ReliaSim method, and it applies to every model we build. #### Run the test on your own line Apply for a free line assessment: bring one question about your line, and we answer it on a model of a line like yours. Apply for a free assessment → The published validation --- # Starved vs Blocked: How to Find Your Production Bottleneck Source: https://reliasim.com/guides/find-production-bottleneck.html ## How to Find Your Production Bottleneck Starved vs Blocked Throughput Guide ## How to Find Your Production Bottleneck Starved vs Blocked The slowest machine on your line is rarely the constraint that's costing you throughput. A stopped machine is either starved or blocked, and those two states point in opposite directions. Here's how to read them, find the machine that sets your output, and prove the fix before you spend a dollar on it. Walk any plant floor and people will point you to "the bottleneck": the machine with the pile of work in front of it, or the one with the slowest cycle time on the spec sheet. Sometimes they're right, but usually they're not. The station with the biggest pile is often just downstream of the real problem, and the slowest rated machine often isn't the slowest effective one once you account for how often it stops. Find the true constraint and you can make a much smaller fix where the line is actually losing time. Miss it and you pay for a faster machine that doesn't move throughput at all. ### The bottleneck you can see vs. the one that's costing you A production line is a chain of dependent stations with variability at every one. Because the stations are coupled, a problem at one shows up as a symptom at another. Here's the classic trap. - WIP piles up in front of Station B, so everyone "knows" B is the bottleneck. - But B is piling up because Station C downstream keeps micro-stopping. B is blocked, not slow. - Speed up B and nothing changes. The constraint was C all along. The pile of WIP tells you where flow is interrupted, not where the cause lives. To find the cause, you have to look at starvation and blocking, two things the WIP pile won't show you. ### Starved vs blocked: same symptom, opposite cause From the aisle, both look like a machine sitting still. Which way to walk to find the cause depends on which of two states it’s in. - Starved means the machine has nothing to work on. It’s ready to run, but no material is arriving. The cause is upstream. - Blocked means the machine has finished a unit and has nowhere to put it. It’s ready to run, but the exit is full. The cause is downstream. Send a technician the wrong way and they’ll spend twenty minutes inspecting a perfectly healthy machine. Starved (top) and blocked (bottom). #### The buffer tells you which one it is You don’t need instrumentation to tell them apart. Look at the storage on either side of the stopped machine. Reading the line What you seeStateWhere the cause is Buffer feeding it is emptyStarvedupstream (something isn’t delivering) Buffer after it is fullBlockeddownstream (something isn’t accepting) Both have material and it still isn’t runningDownthis machine, so now you can look at it Only the third case justifies inspecting the machine in front of you. In the first two, the equipment is healthy and waiting. A buffer that’s chronically full or empty says the same thing about the line as a whole, with the constraint downstream of a full one and upstream of an empty one. The same check finds the bottleneck. The true constraint on a line is the machine that’s neither starved nor blocked, the one still running while everything around it waits. Everyone watches the stopped machines, so bottlenecks get misidentified again and again. #### Measure the time split, not one moment On a real line these states blur. A machine flickers between starved, blocked and running many times an hour, and a supervisor walking past captures one instant of it. What you need is the proportion of time each machine spent in each state across a full run. The constraint is the station with the highest running time and the lowest starved-plus-blocked time. No amount of floor observation gives you that reliably. Because buffers and constraints interact directly, a rate-based model produces blocking and starvation on its own, with no rules to write or logic to configure. Set the rates, the capacities and the interrupts, and the states come out of the flow. You get back the time split per machine, so an argument about who’s holding up the line becomes a reading. The split also shows where capacity is wasted. If a machine is mostly blocked, adding capacity there would produce nothing, because it’s already making more than the next step can take. #### One day of the line, event by event The replay steps through a completed run and shows the state of every node as the flow moves: capacity, volume, fill percentage, inlet and outlet rate, and whether the node is up. The strip underneath is the constraint timeline for the same window, so you can scrub to any moment and read what each machine was doing. One frame, 12:00:59 on 1 August. The Capper is down, and the model names the reason, Capper_Glue Station. Read along the line from there. The Labeler, the Case Packer and the Palletizer each report Starved by Capper, and every buffer between them shows Volume: 0.00. So one stoppage leaves three downstream machines idle, each attributed to the machine that caused it. The Filler upstream is idle too, but the model gives it a different cause, Starved by Bulk Storage. Replay of one 24-hour window on the Buffer-Options bottling line. Watch the buffer volumes and fill percentages move. A buffer filling means the node after it can’t take the flow, and a buffer emptying means the node before it isn’t supplying one. You see blocking and starvation as they happen, rather than as a total at the end of the run. ### Effective rate, not rated rate A machine rated at 60 units/min that goes down for a 90-second jam every 12 minutes isn't a 60/min machine. Its effective rate is far lower, and the variability of those stops ripples downstream. The bottleneck is set by effective throughput under real failure behavior. Two lines with identical nameplate capacity can have very different output for that reason. A constraint timeline. The station that's actually limiting the line changes over the run, and it's rarely one fixed machine. ### When the bottleneck moves with the product A coffee plant ran a Make-Store-Pack layout. Making ran into intermediate storage, and packing lines drew from it into finished formats. A quality initiative added a new stage to that chain, and scheduling broke. Nothing had failed. Each packaging size draws from the store at a different rate, so every format change moved the bottleneck. The plant’s Advanced Planning System assumed a fixed constraint, and its schedules slipped whenever the mix changed. The team’s discrete-rate model reproduced the moving bottleneck instead of assuming it away. With it they designed and tested a new scheduling algorithm, and checked it across a range of demand scenarios before it went into use. If your constraint seems to change with the product mix, it probably does, and a schedule built around one fixed constraint won’t hold. From a ChiAha project record, reported without a throughput or cost figure; client not named. ### Why averages hide the bottleneck Spreadsheets trip up here. If you model each station at its average rate, the line looks balanced and the math says you're fine. Real lines don't run on averages. They run on distributions, and the way variability interacts across coupled stations destroys throughput in ways an average-based calculation can't represent. Your line's output is a distribution, not a single number, and the lost throughput hides in the spread. A real example. On one packaging line, the labeler and the filler had nearly identical average rates, so on paper the line was perfectly balanced. But the labeler had frequent, short micro-stops, and each one briefly blocked the filler upstream. Each stop was trivial on its own. Added up, those cascading micro-stops were costing real throughput, even though on average nothing was wrong. To find loss that lives in variability and coupling, you need a model that plays the line forward through time, with each station's real failure behavior, and watches where flow actually breaks. ### How to prove it before you spend Once you suspect a constraint, the expensive mistake is to act on the suspicion. The better move is to simulate the line. Build a model where each station carries its real cycle time and its real interrupt behavior (how often it fails and how long it's down). Run it forward and read the starvation/blocking and effective-throughput signals directly. Then test the fix in the model. Add the buffer, speed up the suspected station or change the maintenance interval, and see whether throughput moves. A simulation is only worth acting on if it matches reality, and a model whose numbers nobody validated is just a more elaborate guess. The standard to hold it to is a model validated against your actual production data, close enough that you'd bet a capital decision on it. The published benchmark is within 1% of measured OEE. Simulated vs. observed, tight on the diagonal. ### The short version - The biggest WIP pile shows you where flow breaks, not why. - A starved machine points upstream and a blocked one points downstream. The constraint is the machine that’s neither. - Use effective rate under real failure behavior, never nameplate rate. - Validate the model against real data before you act on it. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### Start free in the browser The ReliaSim® Sandbox has curated production-line models in your browser, with no signup. Each one shows every machine's availability from a saved engine run, and you can ask it where the bottleneck is and why. When you're ready to model your own line, that's the full version. Open the sandbox → See pricing Want to see it on a real line first? Read the case study or schedule a call. --- # Line OEE vs Machine OEE: OEE Calculator Source: https://reliasim.com/guides/line-oee-vs-machine-oee.html ## Line OEE vs Machine OEE The Line Isn’t the Average OEE Guide ## Line OEE vs Machine OEE The Line Isn’t the Average Every machine on the line reports OEE in the high 80s, and the line reports something in the 50s. Nobody has made a mistake. OEE calculated for a machine and OEE calculated for a line are different quantities, and the gap between them is set by how the machines are connected. ### OEE calculation, defined properly Overall Equipment Effectiveness is three ratios multiplied together, each measured against planned production time: The OEE formula FactorCalculationWhat it charges Availabilityrun time ÷ planned production timebreakdowns, setups and changeovers Performance(ideal cycle time × total count) ÷ run timeminor stops and running below rated speed Qualitygood count ÷ total countscrap, rework, startup rejects OEEA × P × Q= good count × ideal cycle time ÷ planned time The last row is the useful check. Multiply the three factors and run time and total count cancel, leaving the good units made, expressed as a share of what an ideal machine would have made in the planned time. If your A, P and Q don’t multiply back to that figure, one of them is using a different denominator. Illustrative arithmetic, not plant data A machine rated at 60 units per minute is planned for 480 minutes. It’s down for 60 and runs for 420, which gives Availability 87.5%. In those 420 minutes it makes 23,000 units against an ideal 25,200, which gives Performance 91.3%. Of the 23,000, 22,540 are good, for Quality 98.0%. OEE is 0.875 × 0.913 × 0.980 = 78.3%, and the check agrees. At an ideal 60 per minute, 22,540 good units is 375.7 minutes of fully productive time out of 480. Two decisions change the number without changing the machine. The first is the rate used as “ideal,” which might be a nameplate speed nobody runs or a speed set per product. The second is the denominator. OEE excludes time that was never scheduled, so cutting a shift can raise it while the asset makes no more. TEEP measures against the full calendar instead. Asset Efficiency vs OEE reconciles the two. ### Machine OEE and line OEE measure different things Machine OEE is the formula above applied to one machine’s run time, count and rejects. Line OEE is the same formula applied at the end of the line, using good units out against the line’s rated speed and planned time. The two part company because a machine on a line can stand still for reasons that aren’t its own. When the machine feeding it stops, it’s starved. When the machine after it stops, it’s blocked. Depending on how your monitoring system codes those states, that time is either charged to the machine or excluded as an external loss. Either way, the line pays for it. So the line number collects every machine’s losses plus the losses that pass from one machine to the next. ### Why line OEE isn’t the average of machine OEEs Averaging machine OEEs is the most common shortcut and the most misleading one. An average treats the machines as alternatives, as if product could reach the end of the line through whichever machine happens to be running. On a series line, every unit passes through every machine. If one machine is down and nothing sits between it and its neighbors, the whole line is down. Five machines at 85% OEE average 85%, but with no buffering the line runs only when all five run, and 0.855 ≈ 44%. Is 85% OEE achievable on your line? works through what that does to the world-class benchmark. ### Series topology, where every loss propagates The multiplication is exact only under specific conditions, and it pays to know which factor behaves how on a close-coupled line (no storage between machines): - Availability multiplies if machines fail independently and on a wall-clock basis, meaning a machine can fail while it’s starved or blocked. If failures only accrue while a machine is actually running, the close-coupled line does somewhat better than the product, because idle machines stop wearing. - Quality multiplies. A unit rejected at machine 2 never reaches machine 5, so yields compound through the line. - Performance depends on what the loss is. Minor stops behave like short availability losses and multiply. Pure slow running doesn’t. The line runs at its slowest machine’s pace, so only the lowest performance counts. Real lines are rarely close-coupled all the way through. On a five-machine bottling line whose machine availabilities multiply out to 46.7%, the line runs at 54.3%, because buffers kept many stops from reaching the whole line (see reliability block diagram vs line simulation). ### Line OEE calculator Enter availability, performance and quality for up to six machines in series. The calculator shows each machine’s OEE and the line figures that arithmetic can give: the misleading average, the ceiling set by the weakest machine, and the close-coupled estimate. The example values are illustrative. Machines in series Number of machines 234 56 Reset example values # AvailabilityAvail. % PerformancePerf. % QualityQual. % OEE M1 Machine 1 availability, percent Machine 1 performance, percent Machine 1 quality, percent — M2 Machine 2 availability, percent Machine 2 performance, percent Machine 2 quality, percent — M3 Machine 3 availability, percent Machine 3 performance, percent Machine 3 quality, percent — M4 Machine 4 availability, percent Machine 4 performance, percent Machine 4 quality, percent — M5 Machine 5 availability, percent Machine 5 performance, percent Machine 5 quality, percent — M6 Machine 6 availability, percent Machine 6 performance, percent Machine 6 quality, percent — Enter every value as a percentage from 0 to 100. —Average of machine OEEs (not a line figure) —Weakest machine, the ceiling no buffering can beat —Close-coupled, if all performance loss is slow running rather than stops —Close-coupled line estimate (every loss propagates) Line availability — · line performance — · line quality — (each the product across machines) Arithmetic, not simulation. This assumes no buffers and failures on a wall-clock basis. A buffered line does better, and only a simulation says how much. It also assumes every machine is rated at the line’s speed. How OEE simulation gets the real number → With the example values, every machine sits between 85% and 93%, the average is near 88%, and the close-coupled estimate is about 52%. None of those three figures is the line’s actual OEE. ### Buffers decouple, so the arithmetic overstates losses A buffer lets the downstream machine keep running while the upstream one is stopped, so on a line with storage the close-coupled product overstates the losses and understates line OEE. How much depends on buffer size against the distribution of stop lengths, which is why buffer size has a knee. The opposite shortcut, assuming complete decoupling and taking the minimum of average rates, comes out too high. Spreadsheet, AI, or simulation? explains why. Two bounds, both wrong in known directions EstimateAssumesError on a buffered line Average of machine OEEsmachines are alternatives, not a seriestoo high, often by a wide margin Weakest machineinfinite buffers, perfect decouplingtoo high: a ceiling, not a forecast Product of machine OEEsno buffers, every loss propagatestoo low: a floor Simulationthe line as built, stop by stopvalidated against measured OEE ### Getting the real line number The floor and the ceiling are still useful. If measured line OEE sits near the close-coupled product, the buffers are doing little. They’re too small for the stops, or they’re empty when stops arrive. If it sits near the weakest machine, the line is well decoupled and the lever is that machine. Anywhere between, the question is which machine’s losses are actually reaching the end of the line. Answering that means playing the line forward through time, with each machine’s rate, each failure mode’s time-to-failure and time-to-repair distributions, and the buffers between them. That’s what OEE simulation does, and a model validated against the line’s own history can come within 1% of measured OEE. Once the model reproduces the line, the calculator’s gap closes into a single number, and every change you’re considering can be tested against it before you spend. ### Frequently asked questions #### How do you calculate OEE? Multiply Availability (run time ÷ planned production time), Performance (ideal cycle time × total count ÷ run time) and Quality (good count ÷ total count). The result equals good count × ideal cycle time ÷ planned production time, which is a useful check that all three factors use the same denominator. #### How do you calculate line OEE? Apply the same formula at the end of the line, using good units out, the line’s rated speed and the line’s planned production time. Estimating it from machine figures takes assumptions about buffering, and that’s where arithmetic runs out. #### Is line OEE the average of machine OEEs? No. On a series line every unit passes through every machine, so losses compound rather than average. #### Why is my line OEE lower than every machine’s OEE? Because losses pass from machine to machine. Starved and blocked time reaches the end of the line even when it’s left out of each machine’s own OEE. #### Do buffers improve line OEE? They can. A buffer lets the next machine keep running while the previous one is stopped, so line OEE rises above the close-coupled product of machine OEEs. It can never exceed the weakest machine, and how far it rises depends on buffer size against the length and frequency of stops. #### Is the calculator on this page a simulation? No. It’s arithmetic that assumes no buffers, independent failures on a wall-clock basis and every machine rated at line speed. It gives a floor and a ceiling, and a validated simulation of the line gives the number in between. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See a buffered line beat its arithmetic The ReliaSim® Sandbox has the five-machine bottling line, with no signup. Each model shows every machine’s availability from a saved engine run next to the line’s efficiency, and the Buffer-Options models add a buffer-size sweep. Open the sandbox → OEE simulation Want to see it on a real line first? Read the case study or schedule a call. --- # Buffer Sizing: How Big Should a Buffer Be on a Production Line? Source: https://reliasim.com/guides/how-big-should-a-buffer-be.html ## How Big Should a Buffer Be? We Ran Every Combination on One Bottling Line. Buffer Sizing Experiment ## How Big Should a Buffer Be? We Ran Every Combination on One Bottling Line. Most buffer sizes start as a guess. We took the bottling line that ships with ReliaSim®, sized its three buffers together in every combination, and ran each one for 90 days. That is a full design of experiments: eleven sizes for each buffer, 1,331 runs at each scale. We call it the Buffer Sizing Experiment. Here is what it showed, and how we can run the same study on your line. The request usually arrives already sized: "we want a bigger accumulator after the capper." The number is rarely checked, and a wrong buffer costs money in both directions. Too small and the line still stalls. Too big and you pay for floor space and product sitting still, for gains the line can't deliver. Every result on this page is a ReliaSim run of one model. The runner reproduces the ReliaSim Player desktop app run for run, so you can open the same model and get the same numbers. ### One stop stops the whole line The model is the demo bottling line. It runs on failure data at the level of named failure modes, 36 of them, over 90 days. Bulk Storage→Filler→Capper→Buffer 1→Labeler→Buffer 2→Case Packer→Buffer 3→Palletizer→Warehouse The Capper runs 100 bottles a minute, and the line is balanced to that rate. The Case Packer makes 10 cases a minute and the Palletizer makes 1 pallet a minute. Buffers 1 and 2 hold bottles. Buffer 3 holds cases. With no buffers, the line runs at 54.26% efficiency and makes 70,320.87 pallets in 90 days. Efficiency here is pallets made divided by 129,600, the same figure the ReliaSim Player shows. Here is why it's that low. At 18:09:56 in the run, the Capper's glue station goes down. In the same second the Labeler, Case Packer and Palletizer run out of bottles, and the Filler stops too. The stop lasts 4.2 minutes, and the whole line waits the whole time. Nothing sits between the machines, so every machine's stops become every other machine's stops. A buffer keeps the next machine running while the one before it is down. It adds no speed and removes no failures. ### Size a buffer in minutes, not units A buffer is worth the time it can keep the next machine running. So the useful unit is minutes of line output. On this line, 100 bottles or 10 cases is one minute. Buffer size in line time 10 bottles6 seconds of output 500 bottles5 minutes of output 50 cases5 minutes of output That rules some sizes out fast. A 10-bottle buffer after the Capper holds 6 seconds. Against a 4.2-minute stop it does almost nothing. Over 90 days it moved the line by well under a point: 69,875.79 pallets, against 70,320.87 with no buffer at all. Convert every candidate to minutes before you compare them. A 500-bottle table and a 50-case accumulator look nothing alike on a drawing. On this line both hold 5 minutes. ### Where it goes matters as much as how big First, each buffer on its own, from 0 to 500, with the other two at zero. - Buffer 1, after the Capper, reaches 63.65% at 500 bottles. - Buffer 2, after the Labeler, reaches 60.90% at 500 bottles. - Buffer 3, before the Palletizer, reaches 63.39% at 500 cases. Swipe sideways to see the whole chart. Loading the runs… Buffer 1, after the Capper (bottles) Buffer 2, after the Labeler (bottles) Buffer 3, before the Palletizer (cases) One buffer at a time, the other two at zero. Each point is one 90-day run. The two scales under the axis show the same sizes in minutes: 500 bottles is 5 minutes, and 500 cases is 50 minutes. One buffer at a time, efficiency % Buffer size050100250500 Buffer 1 (bottles)54.2655.8357.1360.5463.65 Buffer 2 (bottles)54.2655.4256.5458.7460.90 Buffer 3 (cases)54.2659.9361.6463.0363.39 Buffer 3 climbs fastest. It reaches 61.64% by 100 cases and then flattens. Buffers 1 and 2 are still climbing at 500 bottles. Now compare them at the same number of minutes. At 5 minutes each, Buffer 1 (500 bottles) gives 63.65%, Buffer 2 (500 bottles) gives 60.90% and Buffer 3 (50 cases) gives 59.93%. Same time, three different results, because each position sits between a different set of stops. ### Buffers overlap, so their gains don't add up The next question is what happens with two or three at once. The easy mistake is to add up the one-at-a-time gains. - Buffer 1 at 500 adds 9.39 points on its own. With Buffer 3 already at 500, it adds 6.01. - Buffer 2 at 500 adds 6.64 points on its own. With Buffer 1 already at 500, it adds 3.09. Much of the time one buffer wins back, another buffer wins back too. Once a stop is covered, a second buffer can't cover it again. So each buffer is worth less when the others are already in place, and a plan built from single-buffer studies will promise more than the line delivers. Swipe sideways to see the whole chart. Loading the runs… 54.26% to 69.40% 60% and 65% lines 5-minute limit Buffer 1 across (bottles), Buffer 3 up (cases), Buffer 2 at zero. Each cell is one 90-day run, printed as efficiency %. The lower white line marks 60%, the upper one 65%. The red box holds every size up to 5 minutes: 500 bottles and 50 cases. Inside it the best cell is 66.58%, at 500 bottles and 50 cases. The top right corner, 500 bottles and 500 cases, reaches 69.40%. Read the map along a row and you see Buffer 1's gain at a fixed Buffer 3. Read it up a column and you see Buffer 3's. Both flatten as the other one grows. ### There's a ceiling, and a realistic maximum below it How far can buffers take this line? We ran them effectively unlimited: 100,000 bottles, 100,000 bottles and 10,000 cases. The line reached 71.72%, 92,949.53 pallets. At 5,000, 5,000 and 1,000 it made exactly the same. Past that point more storage buys nothing. Each machine's own stops cap the line. Nobody builds that much storage. On this site we use 5 minutes per buffer as the realistic maximum: 500 bottles, 500 bottles and 50 cases. That gives 68.20%, 88,385.12 pallets, the best combination inside that limit. Three reference points 54.26%no buffers, 70,320.87 pallets 68.20%5 minutes each, 88,385.12 pallets 71.72%unlimited, 92,949.53 pallets Everything above 71.72% belongs to the machines themselves, and only fixing the failure modes reaches it. ### What this says about Lean and Theory of Constraints Lean treats inventory as waste. Work-in-process ties up cash, hides defects and lets a broken process keep running without anyone noticing. Theory of Constraints protects one spot on purpose, because an hour lost at the constraint is an hour lost for the whole plant. Factory Physics adds the rule underneath both: variability gets buffered by inventory, by capacity or by time, and you only choose which. This line shows both sides. Buffers took it from 54.26% to 68.20% inside the 5-minute limit. That's the case for buffers. They also stop at 71.72% however big they get. After that the only lever left is the stops themselves, which is Lean's point. Which side matters more on your line depends on your stops, and that's measurable. ### What a buffer costs The model tells you what each size buys. The cost comes from the plant, and in food and beverage it's more than a rack and some floor. - Shelf life runs while product waits. Work-in-process is product spending its dating in your building instead of on a shelf. - Sanitation grows with what holds product. Every accumulator and surge table is a surface to break down, clean and verify, and that time comes out of the same window the buffer was meant to protect. - Changeovers get bigger. Product in the line at a changeover has to be run out, held or thrown away. - Recall scope follows work-in-process. The more product in the system when a problem is found, the bigger the window to account for. - Cold space is expensive space. If the buffer has to be refrigerated, "where space is available" means "where you'll build more cold storage." A generous buffer can also hide the failure it absorbs. The line runs well enough, the root cause never gets attention, and the buffer becomes permanent. ### Why you can now afford to sweep “I’ve never seen anything like this.” VP of Food Production “This is so cool.” Food production employees Buffer sizes get guessed because sweeping them used to be expensive. When every candidate costs an overnight run, you pick three. The published validation model was rebuilt in ReliaSim and independently validated within 1% of measured OEE. On the same laptop and the same one-year simulation, the original ran about 1200× slower than the ReliaSim rebuild. Below is a buffer sweep on the Buffer-Options model, the bottling line with inline buffers. It's one of the demo models that ships with the trial and the full version. The sweep crosses every capacity from 0 to 100 with every interrupt, at ten replications and a 90-day horizon. You can open the same model in the browser sandbox. Buffer Tradeoff on the Buffer-Options bottling-line model. Each curve is the line with one interrupt removed. The tight band along the bottom is the baseline. What that sweep cost MeasureValue Runs in the sweep7,770 Wall-clock time31.8 seconds Simulated time covered1,864 years Rate58.68 simulated years / sec The progress dialog and status bar, straight from the run behind the table above. #### Watch the sweep run Here's the same Buffer Tradeoff experiment on the Buffer-Options model, recorded unedited on a laptop at a one-year horizon instead of 90 days. It covered 2,160 simulated years in 31.6 seconds, or 68.32 simulated years per second. Buffer Tradeoff at a one-year run length: the line, then the sweep, then the answer. Take the timing as one measurement, not a specification. It moves with the model, the machine and the run length. What generalizes is that you can bring the curve to the meeting instead of three candidates. ### Run it on your line We can run this study on your line. Send your stop data and where storage could go. Start with a free line assessment. You can try this on the demo line now. The buffer explorer in the Sandbox lets you move all three buffers across every run in this study. The Buffer Options model in the Sandbox is the same line. Part of the science of continuous improvement. The Buffer Sizing Experiment sits beside Gain/Loss (what to fix first) and the Improvement Roadmap (which fixes, in what order, to reach a target). On the demo line, adding 100 cases before the Palletizer as the roadmap’s second step passes 85% in five steps instead of seven fixes, and reaches 88.9% in seven. See all three → Try it on a real bottling line: the Sandbox question Where should the buffer go, and how big?, or one move in Beat the Bottleneck. #### Try the sizes before you buy the storage Move all three buffers across every run in this study and watch where the gains overlap and where the ceiling sits. Explore the buffer runs → Open the Buffer Options model Want this run on your own line? Start with a free line assessment. --- # Throughput vs Capacity on a Production Line Source: https://reliasim.com/guides/throughput-vs-capacity.html ## Throughput vs Capacity Why Rated Speed Never Shows Up Throughput Guide ## Throughput vs Capacity Why Rated Speed Never Shows Up The line is rated at 60 a minute. The shift report says it averaged well under that, and every machine on it can run at 60. Capacity is what the line could make, and throughput is what it does make. The difference is the line’s losses, and most of them sit where a capacity sheet never looks. ### Throughput vs capacity: the definitions The two words get used interchangeably, and most confusion about line performance starts there. Three quantities are worth keeping apart: Three rates for one line QuantityWhat it meansWhere it comes from Rated capacitythe rate the line is designed to run with nothing going wrongnameplate speeds, the slowest machine in the chain Effective capacityrated capacity after the losses you plan forchangeovers, sanitation, planned maintenance, breaks Throughputgood units actually delivered per unit of timethe end of the line, after everything Throughput is always the smallest of the three. Capacity is a property of the equipment and the plan. Throughput is a property of the line as it runs, including every unplanned stop, every slow stretch, every rejected unit and every minute a healthy machine spent waiting on another one. ### The throughput formula For a single machine the throughput formula follows directly from OEE: Throughput from OEE Good units= rated rate × planned production time × OEE Throughput rate= rated rate × Availability × Performance × Quality For a line, the same formula holds with the line’s rated speed and line OEE. Line OEE isn’t any machine’s OEE or their average (see line OEE vs machine OEE), so here the formula stops being useful as a prediction. You can measure line OEE after the fact. You can’t compute it in advance from the machines alone, because it depends on how their losses interact. Illustrative arithmetic, not plant data Take a machine rated at 60 units per minute that goes down for a 90-second jam every 12 minutes. Out of every 13.5 minutes it runs for 12, so it’s available 88.9% of the time and its effective rate is about 53.3 per minute before any other loss. Over a 480-minute shift that’s 25,600 units against a rated 28,800. The rated figure never shows up on the report, because the machine never runs for 480 uninterrupted minutes. ### Where capacity goes before it becomes throughput Between rated capacity and throughput, capacity leaks away in five places. The first three are the familiar OEE losses. The last two don’t appear on any single machine’s report. #### 1. Changeovers and planned stops Every format change, sanitation cycle and planned stop takes the line out of flow. These losses take you from rated to effective capacity, and they’re usually the best documented. They aren’t always the ones that matter. The theory of constraints guide has a plant where the visible changeover wasn’t the constraint. #### 2. Breakdowns Unplanned downtime is the loss everyone sees. What it costs in throughput depends on where it happens. A stop on a machine feeding a full buffer can cost almost nothing, while the same stop on the constraint costs its full length in finished product. #### 3. Micro-stops and speed loss Short stops and running below rated speed land in Performance, and a report often records them as a slower rate rather than as stops. They’re frequent enough to keep buffers from refilling, so they can cost more throughput than their minutes suggest. Micro-stops vs breakdowns covers why. #### 4. Starving and blocking A machine that’s starved has capacity and nothing to work on. A machine that’s blocked has capacity and nowhere to put its output. Either way, the capacity is real and paid for, but it can’t be used. It never shows as downtime on the machine that loses it, so a line can report healthy machines and poor output at the same time. Starved vs blocked explains how to read which is which. #### 5. Quality losses A rejected unit consumed capacity at every machine it passed through. Scrap near the end of the line costs more capacity than scrap near the start. ### The constraint sets throughput A series line can deliver no more than its most limiting resource allows at that moment. That’s the premise of the theory of constraints. For capacity, it means that adding capacity anywhere except the constraint adds nothing to throughput. A faster machine upstream of the constraint fills the buffer and then blocks. A faster machine downstream starves. A constraint timeline from a ReliaSim® run: each machine’s state through a day (up, down, blocked, starved). Capacity is lost in every white and black stripe, on machines that were working perfectly well. The constraint also moves with downtime, product mix and the schedule. The hidden bottleneck and starved vs blocked cover how to locate it. ### Why rated capacity never shows up A capacity spreadsheet takes each machine’s rate, applies an average availability and takes the minimum. The answer comes out too high, because averaging removes the stops that outlast a buffer and cascade down the line. Spreadsheet, AI, or simulation? explains why. On ReliaSim’s Buffer-Options demo bottling line, the same five machines and three buffers make 525,600 pallets in a year with every failure mode removed. That’s the line’s capacity. With its real failure modes the line makes 286,423 pallets and runs at 54.5% efficiency (The Hidden Factory). Nothing about the rated speeds changed between the two runs. The difference is losses, and how they interact across the line. Throughput isn’t one number. The same line with the same data produces a different output every week, because stops arrive at different times. A plan built on the average week comes up short in roughly half of them. A validated model run many times gives the distribution, so you can plan against the weeks you actually get. ### Planning capacity against throughput The useful questions are about throughput, not capacity. Will this line make next year’s volume? If not, which change closes the gap? Answering them means modeling the line as it runs: each machine’s rate, each failure mode’s time-to-failure and time-to-repair distributions, the buffers and conveyors between them, and the schedule. Validate that model against the line’s own history, then test each option: a faster machine, a bigger buffer, a removed failure mode, an extra shift. With a model built from per-failure-mode interrupt data and validated against line history (salad dressing plant case study), capacity planning becomes a set of runs instead of a set of assumptions. See capacity planning simulation for the method. ### Frequently asked questions #### What is the difference between throughput and capacity? Capacity is the rate a line could produce. Throughput is the rate of good units it actually delivers after every stop, slow stretch, reject and minute spent starved or blocked. #### What is the throughput formula? For a single machine, good units = rated rate × planned production time × OEE, so the throughput rate is rated rate × Availability × Performance × Quality. For a line the same formula holds with line OEE, which has to be measured or simulated because it depends on how machine losses interact. #### Why is throughput lower than rated capacity? Because capacity leaks away first: changeovers, breakdowns, micro-stops and slow running, starving and blocking, and quality losses. #### Does adding capacity increase throughput? Only at the constraint. Anywhere else, the extra capacity shows up as more blocked or starved time. #### How do you calculate the capacity of a production line? Rated capacity is set by the slowest machine’s rated speed, and effective capacity subtracts planned losses. Neither one is throughput. A validated simulation run many times gives the throughput distribution to plan against. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See what the interrupts cost The bottling-line models in the ReliaSim Sandbox’s Lines tier need no signup. Their Gain/Loss results show how much OEE the line gets back when each interrupt is removed. Open the sandbox → Find the bottleneck Want to see it on a real line first? Read the case study or schedule a call. --- # Micro Stops vs Breakdowns: Which Costs More? Source: https://reliasim.com/guides/micro-stops-vs-breakdowns.html ## Micro-Stops vs Breakdowns Why the Short Ones Cost More Losses Guide ## Micro-Stops vs Breakdowns Why the Short Ones Cost More A breakdown gets a work order, a root-cause meeting and a line on the downtime Pareto. A one-minute jam gets cleared by the operator and forgotten. Put the two side by side with the same recorded loss, and the frequent short stops can take more throughput off the line than the rare long one. Here’s why, and how to tell which you have. ### Micro-stops, minor stops and speed loss In the Six Big Losses, equipment failure is an Availability loss and minor stops and reduced speed are Performance losses. The split matters more than it looks. A breakdown is logged as a stop with a start, an end and usually a cause. A micro-stop, a jam cleared in under a minute or a sensor fault reset at the panel, often falls below whatever threshold the plant’s system uses to record a stop. It shows up only as a machine that made fewer units than its run time allowed. So micro-stops hide in performance loss. They get recorded as speed loss, which reads like a machine running a little slow, not one stopping a hundred times a shift. Nobody writes a work order for speed loss, which is the first reason they get ranked too low. The second reason is structural, and it applies even when every stop is logged perfectly. ### The ranking a loss report gives you In our bottling line case study, a five-machine line (Filler, Capper, Labeler, Case Packer, Palletizer) has two failure modes with nearly equal direct losses. Labeler Misalignment is infrequent, longer stops at 6.79% direct efficiency loss. Filler Micro Stop is frequent, short stops at 6.72%. On a Pareto they rank level, and most improvement teams would pick the Labeler, because it’s the bigger single event and easier to see. ### What removing each one gives back A loss report can tell you what each failure mode cost. It can’t tell you what comes back when you remove it. For that you remove one failure mode in a validated model, re-run the whole line, and measure the recovered output. ReliaSim®’s methodology page shows the pair: Loss vs gain, same line Failure modePatternLossGain when removedGain ÷ loss Labeler Misalignmentrare, longer stops6.79%+5.0 pts0.73× Filler Micro Stopfrequent, short stops6.72%+8.1 pts1.21× 1.21×recovered by removing the micro-stops 0.73×recovered by removing the long stops The losses are almost identical and the recoveries aren’t. Removing the Labeler’s long stops returns less than they appeared to cost, because the line was already absorbing part of them. Removing the Filler’s micro-stops returns more than they appeared to cost. The case study describes 120 one-minute micro stops whose effects landed as idle time on the Labeler, Case Packer and Palletizer, never under the Filler’s own name. ReliaSim’s Efficiency Gain/Loss report on the Buffer-Options demo bottling line, a different line from the case study, run for one year with ten replications. Blue is each failure mode’s loss, and orange is what comes back when it’s removed. Orange taller than blue means the mode was cascading. Shorter means something was absorbing it. ### Why frequent short stops can cost more A buffer absorbs a stop only if it has stock when the stop begins. That condition explains most of the gap, and it’s exactly what frequency attacks. #### 1. They never let the buffer refill A buffer refills only as fast as the machine feeding it can outrun the machine it feeds. On a high-speed line where every machine is rated near the same speed, that margin is small, so refilling is slow. Short stops that arrive faster than the buffer refills drain it step by step. Illustrative arithmetic, not plant data An upstream machine can run at 66 units per minute. The machine after the buffer draws 60, so the buffer refills at 6 a minute while both run. A one-minute upstream stop drains 60 units, which takes 10 minutes to put back. If a one-minute stop comes every five minutes, the buffer regains 24 units between stops and loses 60 in each. It falls by 36 units per cycle, so a 240-unit buffer is nearly empty after half an hour. From then on it holds about 24 seconds of stock when a stop begins. #### 2. They take the buffer away from every other stop Gain can exceed loss for this reason. Once short stops have drained a buffer, it can’t protect against anything else either, such as a stop on the machine feeding it, a longer jam or a changeover overrun. Those losses pass straight through and get charged to other failure modes. Remove the micro-stops, and the buffer is full again for all of them. That recovered protection is the part of the gain the loss report never showed. #### 3. They cascade on close-coupled sections Where there’s little or no storage between machines, every micro-stop starves the machine after it and blocks the one before. The cost lands as idle time on neighbors that did nothing wrong (Starved vs Blocked). The same pattern shows up on packaging and electronics and automotive lines. What a buffer does, and what defeats it. ### Why long stops still matter None of this means micro-stops always outrank breakdowns. A long stop outlasts any practical buffer. On the Buffer-Options demo line, removing the dominant long stoppage on the constraint beats adding storage at every buffer size (How big should a buffer be?). What decides it on a given line is how stop lengths compare with buffer size, how quickly buffers refill, and where each machine sits relative to the constraint. So a line model takes stop distributions per failure mode rather than averages (MTBF and MTTR are outputs, not inputs). ### Speed loss isn’t the same as a stop Reduced speed also lands in Performance, and it has its own interaction with buffers. A machine running slower than the one before it fills the buffer between them and then blocks the faster machine. A machine running slower than the one after it drains the buffer and then sets the pace of everything downstream. Either way, a slow machine defeats the buffer beside it, just as frequent stops do. Where the slow machine sits decides what it costs. Speed loss on the constraint costs output directly. Speed loss on a machine with plenty of spare rate may cost nothing at all. The OEE report charges both the same Performance points. ### How to rank short and long stops on your line - Log short stops as stops. Record them by cause, not as a lower rate. A micro-stop you can’t see as an event can’t be modeled or ranked. - Fit distributions per cause. Use time-to-failure and time-to-repair for each failure mode, not a pooled average per machine. Downtime data analysis in ReliaStats does this from line event data. - Validate before you rank. Check the model against the line’s own history first (salad dressing plant case study). - Rank by gain, not loss. Remove each failure mode in turn and read what comes back. Which loss to fix first covers the method. Following the Pareto points the budget at alignment tooling for the Labeler. Following the model points it at the Filler’s jams, which recover 62% more throughput. ### Frequently asked questions #### What is a micro stop? A very short stoppage, such as a jam cleared by the operator or a fault reset at the panel, often too short to be logged as downtime. OEE counts minor stops as a Performance loss, not Availability, so they tend to show up as speed loss rather than as stop events. #### Why can micro stops cost more than breakdowns? They drain buffers faster than the buffers refill, so the buffers are empty when the next stop of any kind arrives. Removing them can return more output than their recorded loss. #### What is speed loss? It’s running below the rated or ideal rate, and it counts as a Performance loss in OEE. On a line, a slow machine drains or fills the buffer beside it and then sets the pace, so its cost depends on whether it’s at or near the constraint. #### Do breakdowns still matter more sometimes? Yes. A long stop outlasts any practical buffer. A loss/gain experiment on a validated model shows which matters more on your line. #### How do you find out which stops to fix first? Validate a line model built from per-cause stop data, then remove each failure mode in turn and rank by the output that comes back. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See what each stop costs the line The bottling-line models in the ReliaSim Sandbox’s Lines tier need no signup. On three of the LEDS models, saved Gain/Loss results rank the named failure modes, micro-stops included, by what the line gets back when each is removed. Open the sandbox → Read the case study Want to talk it through for your line? Schedule a call. --- # ReliaSim Heritage: 35+ Years of Rate-Based Simulation Source: https://reliasim.com/heritage.html ## 35+ years of rate-based simulation ReliaSim is the third engine from the team that started it ### Where discrete rate simulation started A filling line moving product at high speed is a flow, not a queue of separate parts. Andrew Siprelle created discrete rate simulation in 1990 as “bulk flow” simulation, built to model that flow directly. Models of packaging, food and bulk-handling lines ran far faster than item-by-item models, and the same idea now appears in every major simulation package. The first paper on the method, with David Parsons at the Winter Simulation Conference in 1995, was built using Extend. The full history, with sources, is on the discrete rate lineage page. ### The libraries we wrote for Extend Andy Siprelle adopted Extend, now ExtendSim, before it even had a discrete event library, and worked closely with Bob Diamond, who founded Imagine That and created Extend. The team went on to write many of the libraries Extend modelers built on: - SDI Industry and Bulk Flow (Rate): the first commercial discrete rate library, for continuous and high-speed operations. - SDI Database (SDI DB): models driven by tables instead of hand-set parameters. - Supply Chain Builder: network-scale blocks. The first VINLogic vehicle distribution model was built with it (read the case). The Bulk Flow (Rate) and Database libraries sold more than 700 licenses and were the origin of ExtendSim’s Discrete Rate and Database libraries. Andy also created the first official ExtendSim training program, and the team has since trained thousands of simulation professionals. ### Built in ExtendSim, rebuilt in ReliaSim ReliaSim is the third generation of the method, rebuilt from scratch by the same team. These case studies were first built in ExtendSim (or in our Supply Chain Builder for ExtendSim) and have since been rebuilt in ReliaSim: - Soap plant consolidation: the model catches a $4 million quality problem first. - Olive plant capacity study: 15% more output from scheduling, before buying equipment. - Brewery expansion: the tanks, not the new lines, set the limit. - Chemical bag lines vs overtime and a cereal plant that runs its model before every shift. - Pack at the plant or the DC and sizing capacity before the peak is known. The rebuild is checked against outside work too. A food plant model that Fischel and Lange published at the 2020 Winter Simulation Conference, originally built in ExtendSim, was rebuilt in ReliaSim and independently validated by Tom Lange. It came within 1% of the plant’s measured OEE and ran about 1,200× faster on the same laptop (the comparison, the case study). ### Who we are today ReliaSim is made by ChiAha in Maryville, Tennessee. Our team also builds custom models and teaches ExtendSim. Customers have always come to us with the hardest line problems, the ones their own teams couldn’t untangle, and they come back because we get to the right answer fast. Bring us your line. We’ll show you where the constraint really sits. Book a call → All case studies ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. --- # Lean, TPM or TOC: Which Would Fix This Line First? Source: https://reliasim.com/guides/lean-tpm-toc-which-fix-first.html ## Lean, TPM or TOC Which Would Fix This Line First? Improvement Methods Guide ## Lean, TPM or TOC Which Would Fix This Line First? Ask three improvement schools what to fix first on the same line and you get three different answers. Each one follows a sound rule. We scored all three on a validated ReliaSim® model of a bottling line. None of them found the move that adds the most output, and the model could test every one of them on equal terms. ### The line Five machines in a row: a Filler, a Capper, a Labeler, a Case Packer and a Palletizer, fed from bulk storage and feeding a warehouse. Every machine runs at 100 bottles a minute, so on paper there is no slow machine to blame. Running 24/7 with no stops, the line would make 129,600 pallets in 90 days. It doesn’t. Thirty-six different interrupts stop it, each with its own pattern of how long the machine runs before it stops and how long it stays down, fitted from the line’s own stop data. Across ten randomized 90-day runs the line delivers 54.3% of what it could. The model matches the line’s own uptime interrupt by interrupt before anyone trusts what it says. Each school gets one move, starting from the line as it is: fix one problem, or add buffers between the machines. ### What each school recommends #### Lean: cut the biggest waste Lean ranks the losses and goes after the biggest one on the downtime chart. Here that’s the Capper’s Upper Plow Area, which kept the line down 198 hours in 90 days, more than any other interrupt. Lean also treats buffers as inventory, and inventory as waste, so it adds none. #### TPM: fix the worst machine Total Productive Maintenance looks after the equipment and goes after chronic losses on the machine that’s down the most. That’s the Capper, available 75.9% of the time, and its most frequent stop is its micro stops: 5,816 of them in 90 days. TPM’s pick is the Capper’s minor stops. #### TOC: protect the constraint The Theory of Constraints finds the constraint and protects it. With every machine at the same speed, the constraint is the machine that’s down the most, again the Capper. TOC protects it with a buffer: all four buffer slots right after the Capper. ### How each one scored Each recommendation went into the same model and ran ten times, 90 days each, with every other stop on the line still in place. The score is line efficiency: pallets made, as a share of the 129,600 a line that never stops would make. Ten 90-day runs per recommendation SchoolFirst moveLine efficiency The line as it isnothing changed54.3% Leanfix the Capper’s Upper Plow Area61.5% TPMfix the Capper’s minor stops57.1% TOCall four buffer slots after the Capper62.6% ReliaSim’s experimentsevery fix and every buffer placement, tested66.1% All three schools improve the line. None of them finds the best move. The model tried every one of the 36 fixes and every legal way to place the buffers, and its best move beats the best school by 3.5 points, on the same line, with the same one move. We leave that move out here, because it’s the answer to the game. ### Why each rule stops short #### The biggest loss isn’t the costliest Lean’s chart counts hours down. On a line with no buffers, what an hour costs depends on what the stop does to the machines around it. The Upper Plow Area is a sound pick, and still not the best fix: removing a different interrupt, one that costs fewer hours, gives back more. A downtime chart ranks occurrence; the line ranks what each stop does to output. See which loss to fix first. #### The worst machine isn’t where the best fix is TPM goes to the machine with the lowest availability, and to the most frequent stop on it. Frequency is real, but the Capper’s micro stops are short, and fixing them moves the line only from 54.3% to 57.1%, the lowest of the three. Looking after the equipment is right; choosing the target by availability alone is what misleads it here. See micro stops vs breakdowns. #### TOC is right about the constraint, not about the buffer TOC protects the right machine and scores best of the three schools. What it doesn’t say is how much buffer, or where. Putting all of it straight after the Capper is a fair reading of “protect the constraint”, and the model shows a better placement exists. With every machine at the same speed, the constraint also moves from stop to stop. See theory of constraints simulation and how big should a buffer be? None of the three rules is wrong. Each looks at one part of the line: the loss chart, the machine, the constraint. The line answers as a whole, with every stop interacting with every other. ### Not a fourth school: a test bench for all of them ReliaSim doesn’t compete with Lean, TPM or TOC. It doesn’t ask you to drop the method your plant runs on. It gives that method a place to be tested before the line pays for it. Whatever the rule says, the model can run it. Cut a waste and the interrupt comes out of the model. Do a maintenance project and the failure pattern changes: stops come less often, or end sooner. Protect the constraint and a buffer goes in where the rule puts it, at the size it calls for. A SMED project shortens a changeover, a speed-up raises a rate, and a new shift pattern changes the calendar. Each one is a change to the model, and each runs on the same line with every other stop still in place. That also means the schools stop being an argument. A Lean team, a maintenance team and a TOC advocate can each bring their first move, and the line scores all of them the same way: what each one gives back in output. The rule that wins on one line can lose on the next. Testing is how you learn which one holds on yours. Keep your philosophy. Test its next move. ReliaSim can model whatever change your method recommends, compare it with every alternative, and show which one the line actually rewards, before anyone touches the floor. ### Try it on this line Beat the Bottleneck runs this exact comparison. You get one move on the same line, it’s scored over ten 90-day runs, and then you see what Lean, TPM and TOC would have done. #### Can you beat the bottleneck? One move. A few minutes. Free. Play Beat the Bottleneck → Open the Sandbox Want this on your own line? We can build the same game from the stop data your machines already record. Start with a free line assessment. --- # Six Big Losses: Which to Fix First? Source: https://reliasim.com/guides/which-of-the-six-big-losses-first.html ## Which Loss to Fix First The Biggest One Is Rarely the Costliest Prioritization Guide ## Which Loss to Fix First The Biggest One Is Rarely the Costliest The Six Big Losses give you a complete inventory of where production goes. They don’t give you an order. Almost everyone ranks them by minutes lost, and that ranking is usually wrong. ### The inventory is the easy part The six categories come out of TPM and cover the full range of losses: equipment failure, setup and adjustment, idling and minor stops, reduced speed, process defects, and reduced yield at startup. Mapped onto OEE, the first two land in Availability, the middle two in Performance, and the last two in Quality. Most plants can produce that breakdown from their event data in an afternoon. Then the improvement meeting starts, someone points at the largest bar, and the budget follows it, which is where the money gets misdirected. ### Why the biggest loss is usually the wrong target There are three reasons, and they compound. #### Losses aren’t independent A loss inventory adds minutes as though each stoppage cost the same, and they don’t. Ten minutes of downtime on a machine feeding a full buffer costs nothing at all. The same ten minutes on a starved constraint costs ten minutes of finished product. The report records both identically, so the ranking it implies is a ranking of occurrence, not of cost. #### Position matters more than magnitude Where a loss sits relative to the constraint decides whether it matters. A large loss on a machine with slack either side may be almost free. A small, frequent loss on the constraint is paid in full every time. Two plants with identical loss tables and different topologies have different correct answers. #### Averaging erases the difference This one has been observed in print. Fischel and Lange modeled a food plant with over twenty unit operations and up to twenty failure modes each. They noted that had they taken the conventional averaged, single-failure-mode-per-operation approach, "the gains and losses would be less accurate and essentially identical to each other." Coarse loss accounting doesn’t just blur the ranking. It flattens it until every candidate looks about as good as every other. Then the decision falls to whoever argues most confidently, and the analysis has added nothing. ### The ranking that actually holds The question you want answered isn’t "how many minutes did this cost?" It’s "how much production comes back if I remove it?" Those are different numbers, and only the second one justifies a budget. A model answers it by subtraction. Take the validated line, remove one failure mode, re-run, and read the difference in output. Repeat for every failure mode. You get a ranking by recoverable throughput. It accounts for position, for interaction, and for the buffers that absorb some losses and not others. Two rankings of the same line Ranked byWhat it measuresWhat it misses Minutes lost the loss reporthow often and how longwhether the line noticed Recovered throughput remove it and re-runwhat you get backnothing, since it’s the answer #### Both numbers, side by side Start with the ranking you already have. The Efficiency Loss report is a Pareto of what each failure mode cost. It’s the same shape as the loss tree on your wall, and just as persuasive. Efficiency Loss on the Buffer-Options bottling line (one year, ten randomized replications, averaging 57.5% efficiency). Read it and you’d fund the three bars on the left, at 9.05%, 6.95% and 6.85%. It’s the ranking by minutes lost, and it’s the one almost everybody acts on. Now put the recovery beside it. The Efficiency Gain/Loss report keeps the same order and the same blue loss bars, and adds an orange bar for each, showing what the line actually gets back when that failure mode is removed. The same run, both numbers. Blue is the loss, the identical series from the chart above. Orange is the gain. They routinely disagree. The second failure mode recovers more than its recorded loss, because removing it also stops the cascade it was setting off downstream. The third recovers noticeably less, because a buffer was already absorbing part of it. Near the middle, a bar barely worth a line on the Pareto has an orange partner several times its height, a cheap fix no loss report would ever surface. Hovering any pair names the failure mode and both figures, so the disagreement is readable one at a time rather than inferred from bar heights. Efficiency Gain/Loss on the Buffer-Options bottling line (90 days, ten randomized replications, averaging 55.5% efficiency). Because it’s ten replications, the line view reports availability as a range rather than a point (the Case Packer runs 97.81–99.97%, the Capper 74.65–88.55%). Hovering one bar pair reads Labeler::Labeler_Misalignment: Loss 6.67%, Gain 4.85%. Those aren’t the same number, and across the chart they don’t rank in the same order. This whole 90-day Gain/Loss sweep on the Buffer-Options line runs 88.77 simulated years in 2.8 seconds. ### The counterintuitive ones Exhaustive sweeps surface findings that nobody nominates in a meeting: - Frequent short stops beat rare long ones. A stoppage measured in seconds looks negligible on a loss report. On a tightly coupled line it never lets buffers refill, so its cost is carried continuously rather than occasionally. - Faster isn’t always more. Raising line rate raises failure rate too, so throughput has an optimum rather than rising steadily. The Fischel and Lange study found exactly this, and any analysis that treats rate and reliability as separate can’t see it. - Some losses are already absorbed. Fixing them returns nothing, because a buffer was covering them, and it’s better to know that before funding the project. ### What this needs from your data The ranking is only as good as the failure-mode detail underneath it. One lumped downtime figure per machine gives a flat ranking. Named failure modes from a Line Event Data system give one you can spend against. The bottling line demo models show both on the same line, and they give a different answer about where the bottleneck is. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See losses ranked by what comes back The sandbox has saved Gain/Loss results that remove interrupts one at a time and show what the line gets back from each. Open the sandbox → How the method works Want to see it on a real line first? Read the case study or schedule a call. --- # World-Class OEE: Is 85% Achievable? Source: https://reliasim.com/guides/is-85-percent-oee-achievable.html ## Is 85% OEE Achievable on Your Line? The Benchmark Was Never About Lines Benchmark Guide ## Is 85% OEE Achievable on Your Line? The Benchmark Was Never About Lines World-class OEE is quoted as 85%. It's a real number with a real derivation, but it applies to a single machine. For a line of machines in series it isn't a stretch target. The arithmetic puts it out of reach, and chasing it wastes budget on the wrong thing. ### Where 85% comes from Seiichi Nakajima's benchmark for world-class equipment effectiveness is three factors multiplied: The world-class benchmark FactorWorld-class Availability90% Performance95% Quality99% OEE≈ 85% The number is sound and widely cited. The problem is what happens when it's carried from a machine to a line. ### What series topology does to it Take five machines, each individually world-class at 85%. What's the line worth? With no buffering between them, every stoppage spreads immediately and the line runs only when all five run, so availability multiplies. Five world-class machines in series BufferingLine OEEWhy None0.855 ≈ 44%every stoppage propagates to the whole line Infinite85%stages fully decoupled; the slowest sets the pace Realsomewhere betweendepends on buffer size versus stoppage length 44%five world-class machines, no buffers 85%the benchmark being aimed at Those two figures describe the same five machines. The difference is entirely topology and buffering. So "our line runs at 55% against a world-class 85%" often isn't a performance gap at all. It can be a line whose every machine is already excellent, assembled in a configuration where 85% was never available. Reported as a shortfall, it funds equipment projects that can't deliver, because the constraint is the arrangement rather than any of the parts. ### The right question The question isn't "are we at 85%?" It's "what's the ceiling for this line, with this topology, this buffering and this failure profile, and how far below it are we?" You can answer it with two runs of a model of the line as built. First run it with its real interrupts. That's what this topology, buffering and failure profile should deliver, and comparing it with your measured OEE shows how much you're losing to execution. Then remove every interrupt and run it again (the perfect-calendar run). That's the most this configuration can produce. The gap between the two runs is the most that reliability work could ever recover on this line, measured against your line rather than a single machine in a textbook. Two lines can be equally far from 85% with completely different amounts of available improvement, and only one of them has a problem worth funding. ### What the ceiling tells you to do - If measured OEE sits well below the as-built run, the shortfall isn't in the failure data. Look at execution: response times, speed losses and changeovers the model doesn't carry. - If the as-built run sits well below the interrupt-free run, failures are costing you real output, and the equipment work is justified. The recoverable-throughput ranking tells you which machine. Where one machine's stops spread down the line, buffering or decoupling can be cheaper than fixing the machine. - If even the interrupt-free run falls short of the target, no amount of maintenance reaches it and the conversation is about capital, not effectiveness. It's better to find that out before a year of improvement projects. None of this argues against the benchmark. It argues against applying an equipment benchmark to a system without adjusting for what the system does to it. Treating interacting parts as independent is the same error that makes loss trees misrank projects. ### An improvement roadmap to 85% Once you know the ceiling, the next question is the path: which fix first, which next, and how many it takes. The answer comes from engine runs on a model of the line, not judgment. We call the result an Improvement Roadmap. Line efficiency after each fix, the demo bottling line. Solid: no buffers. Dashed: one buffer, 100 cases before the Palletizer, added as the second step. On our demo bottling line it takes seven fixes to go from 54.3% to 85.2%, or five steps with one 100-case buffer before the Palletizer: the buffer and four fixes. None of 2,000 random plans of seven fixes reached 85%; the best got to 79.8%. The full walk-through is in The Improvement Roadmap: which fixes, in what order, and you can build it yourself in the Sandbox. Try it on a real bottling line: the Sandbox question How do we get to 85%?, or one move in Beat the Bottleneck. #### See how much one line could recover The sandbox has the demo bottling line at four levels of detail, up to five machines with converters and buffers. Its Gain/Loss results show what each interrupt costs and the total OEE the line could recover. Open the sandbox → The demo models Want to see it on a real line first? Read the case study or schedule a call. --- # OEE Improvement Roadmap: Which Fixes, in What Order Source: https://reliasim.com/guides/improvement-roadmap.html ## The Improvement Roadmap Which Fixes, in What Order, to Reach Your Target Improvement Guide ## The Improvement Roadmap Which Fixes, in What Order, to Reach Your Target Every plant has a list of improvement projects. The hard part is the order: which fix first, which next, and how many it takes to hit the target. An improvement roadmap answers that with experiments in a model instead of judgment, and on our demo bottling line it reaches 85% in seven fixes, or in five steps if one of them is a 100-case buffer, where 2,000 random plans never get there. ### Why the order is hard to guess Our demo bottling line has five machines and 36 failure modes. There are millions of ways to choose seven of them to fix, and far more ways to put those seven in order. Nobody ranks that by hand. The usual shortcut is the downtime report: fix whatever lost the most minutes. But a line isn’t a list of machines. A stop on one machine can be absorbed by storage, or hidden behind a bigger stop next door, so the minutes a failure costs and the output a fix gives back are different numbers. We cover that in which loss to fix first. Once one fix is in, the ranking of everything else changes, which is why a single ranking isn’t a plan. ### Where the roadmap comes from The roadmap comes from engine runs on the model, not judgment. Every run on this page is 90 days of the demo line. On that line the roadmap reaches 85.2% in seven fixes. With one buffer, 100 cases before the Palletizer, it passes 85% in five steps and reaches 88.9% in seven. ### The roadmap for the demo bottling line Line efficiency after each fix. Solid: the line as built, with no buffers. Dashed: the same line with one buffer, 100 cases before the Palletizer, added as the second step. Improvement Roadmap · no buffers StepFixLine efficiencyPallets back in 90 days StartThe line as it is54.3%– 1st fixFiller: Micro Stop62.1%+10,034 2nd fixCapper: Upper Plow Area69.6%+9,762 3rd fixLabeler: Misalignment75.3%+7,366 4th fixCapper: Picker Tree Assembly78.6%+4,279 5th fixPalletizer: Hoist Area81.1%+3,204 6th fixPalletizer83.3%+2,851 7th fixFiller: Capacity Constraints85.2%+2,456 - Each fix gives back less than the one before. The 1st is worth about 10,000 pallets over 90 days; the 7th, about 2,500. Budget for the whole roadmap, not the first step. - One buffer in the right place gets there sooner, and higher. Add 100 cases of storage before the Palletizer as the second step and the line passes 85% at step five, the buffer and four fixes, instead of after seven fixes. Seven steps with the buffer reach 88.9%, 3.7 points more than seven fixes alone. Where to put storage, and how much, is its own experiment: see the Buffer Sizing Experiment. ### How does it compare with other plans? We ran 2,000 plans of seven fixes picked at random, every one in the engine. None of them reached 85%. The best got to 79.8%, and the average to 63.0%. The roadmap (blue) against 2,000 random plans of seven fixes, every one run in the engine. The white line is the average random plan. ### The order matters as much as the fixes The same seven fixes end at the same place in any order: which fixes you make decides where the line ends up. The order decides how fast it gets there, and so how much you produce along the way. In the worst order, the line is at 62.5% after four fixes. On the roadmap it is at 78.6%. The same seven fixes in the roadmap’s order (blue) and in the worst possible order (amber). ### Build one for your line We can build this roadmap for your line from your stop data. Start with a free line assessment. Part of the science of continuous improvement. The Improvement Roadmap sits beside Gain/Loss (what to fix first) and the Buffer Sizing Experiment (where storage pays). See all three → ### Questions #### What is an improvement roadmap? The fixes that take a production line from where it is to a target, in the order to make them. It comes from engine runs on a simulation model of the line, not from judgment or a downtime report. #### How many fixes does it take to reach 85% OEE? It depends on the line. On our demo bottling line, five machines with 36 failure modes and no buffers, it takes seven fixes to go from 54.3% to 85.2%. Add one buffer, 100 cases before the Palletizer, as the second step, and it takes five steps: the buffer and four fixes. Seven steps with the buffer reach 88.9%. #### Does the order of improvements matter? The same set of fixes ends at the same place in any order, but the order decides how fast the line gets there. In the worst order of our seven fixes, the line is at 62.5% after four fixes; in the roadmap order it is at 78.6%. #### Can you just pick improvement projects at random? Not if you want to reach the target. Of 2,000 plans of seven fixes picked at random on our demo line, none reached 85%. The best got to 79.8%, and the average to 63.0%. Try it on a real bottling line: the Sandbox question How do we get to 85%?, or one move in Beat the Bottleneck. #### Explore the roadmap yourself The Sandbox has the demo bottling line with every run behind this page. Compare the roadmap with every option at each step, with 2,000 random plans, and with other orders of the same fixes. Open the Improvement Roadmap → Is 85% OEE achievable? --- # Hidden Factory: Asset Efficiency vs OEE Source: https://reliasim.com/guides/how-big-is-your-hidden-factory.html ## How Big Is Your Hidden Factory? Asset Efficiency vs OEE, and Why the Answer Depends on the Denominator Capacity Guide ## How Big Is Your Hidden Factory? Asset Efficiency vs OEE, and Why the Answer Depends on the Denominator The hidden factory is the production you could get from equipment you already own, without buying anything. Everyone agrees it exists. Very few plants can put a number on it, and the reason is the metric they use to look for it. OEE and Asset Efficiency can describe the same shift and differ by thirty points, and nothing but the denominator changes. ### The idea, and why it keeps resurfacing Armand Feigenbaum's original observation was that a plant contains a second, invisible plant inside it: the capacity consumed by rework, waiting, and everything else that isn't production. Sixty years later the term has broadened to mean the whole gap between what your equipment could physically make and what it actually made. It keeps coming back because it's the cheapest capacity in manufacturing. A recovered hour on existing equipment needs no capital request, installation, commissioning or floor space. ### Why your OEE can't find it OEE measures against planned production time. Time you deliberately didn't schedule, like the unstaffed shift, the quiet week or the plant holiday, is left out of the denominator by design. That's correct for OEE, which exists to grade execution against a plan. The hidden factory lives largely in that time. Where the hidden factory hides LayerWhat it isDoes OEE see it? Unscheduled timehours the asset existed and you chose not to runNo, excluded by definition Downtime in scheduled hoursbreakdowns, changeovers, minor stopsYes (Availability) Running below rateslow cycles, reduced speedYes (Performance) Product not made rightscrap, rework, startup yieldYes (Quality) 3 of 4layers OEE reports on 1 of 4invisible, and often the largest A plant running two shifts of a possible three is holding roughly a third of its capacity in the layer its headline metric can't see. On a five-day operation the invisible layer is nearer 29% of the calendar before a single breakdown is counted. ### Measuring it: production over a perfect calendar The measurement isn't complicated once you accept the denominator. Take everything the asset could have produced running perfectly for every minute it existed, and compare it against what it actually produced. That ratio is what we call Asset Efficiency, and its complement is the hidden factory. The section on Asset Efficiency vs OEE below explains why we use that denominator and why it parts company with OEE on any plant that doesn't run 24/7. The denominator isn't a theoretical construct, because you can run it. Turn every interrupt off and simulate the same line over the same calendar, and the model reports the ceiling directly. The Buffer-Options bottling line with every failure mode removed, over 90 days. Every node reports 100.00% internal availability, the line reports 100.0% efficiency, and the warehouse receives 129,600 pallets. That's the perfect calendar. Since 90 days is 129,600 minutes, this line's ceiling is exactly one pallet a minute, every minute, for three months. That number is the denominator, and you can check it against the same line running with its real failure modes. Run both over a full year and the two screens report the answer directly, with no arithmetic needed. The same line, view and one-year calendar. Above, every failure mode is removed, every node is at 100.00% and the line makes 525,600 pallets. Below is the line as it actually behaves, with the Capper at 75.57%, the Labeler at 88.57% and 286,423 pallets. The toolbars read 100.0% and 54.5%. The line made 286,423 of a possible 525,600 pallets. The other 45.5% is the hidden factory. It's one run divided by another, with both numbers on screen. ### Asset Efficiency vs OEE vs TEEP: when they match and when they won't On a plant that runs around the clock, a simulated Asset Efficiency and a reported OEE can land within a point of each other. On a plant that runs one staffed shift, the same two numbers can differ by thirty. The industry has never fully agreed on which minutes belong in the denominator. A plant engineer once asked us whether our Efficiency figure was based on 24/7 possible asset utilization, the way their TEEP metric is, or on 24/5 production time. It's a sharper question than it looks, and it's the one to settle before anybody compares a model against a dashboard in a meeting. If you don't, someone will put a simulated Efficiency next to the plant's OEE, see a gap of twenty or thirty points, and conclude that the model is broken. #### One shift, two denominators Take a line that runs at an ideal rate of 100 units per minute. It's staffed for a 900-minute operating window, which leaves out sanitation and the unstaffed shift. Over one day it produces 72,000 units. Now measure that same output two ways. The same 72,000 units, measured twice BasisTime countedPotential outputResult Staffed operating window what the line was asked to do 900 min 100 × 900 = 90,000 80.0% A perfect day what the asset could theoretically do 1,440 min 100 × 1,440 = 144,000 50.0% Nothing about the shift changed between those two rows. Only the amount of time in the denominator moved, and that alone is worth thirty points. #### OEE counts the time you planned to run OEE multiplies three factors: Availability × Performance × Quality. Its denominator is planned production time, so the unstaffed third shift, the sanitation window and the plant holiday don't count against it. That makes OEE the right measure of how well you executed the plan you made. It says nothing about whether the plan itself left capacity on the floor. #### TEEP counts all the time there is TEEP takes OEE and multiplies it by Utilization, the share of calendar time you chose to schedule. Its denominator is every hour the asset existed, whether staffed or not. A line running beautifully on one shift can post excellent OEE and mediocre TEEP at the same time, and both are true. TEEP answers the capital question of how much of this asset you're actually using. #### Asset Efficiency counts production over potential for the modeled period A simulation reports the ratio it can defend: units produced, divided by units the line would have made at its ideal rate with no interruptions, over the period modeled. It's built like TEEP, since it counts time you weren't staffed. It isn't textbook TEEP, though, because the horizon is the modeled period rather than a rolling 24/7 calendar. Model one production day and no weekend hour is credited or debited. Efficiency tells you how much the line made out of everything it could physically have made. ### Which minutes count? Under the arithmetic is a choice people rarely make out loud, and it splits the industry much the way buffer sizing does. The real question is which minutes belong in the denominator at all, not how to compute the ratio. - Scheduled-time accounting. Count only the hours you planned to produce. A shift you chose not to staff, a line you idled for a slow week and a plant holiday don't count against the number. - Every-minute accounting. Count every hour the asset existed. If the line could physically have run and didn't, that shows up. Both are defensible and both are in wide use, but they behave differently. The difference that matters most is that a scheduled-time number can be improved by scheduling less. Cut the third shift and availability against plan goes up, while the asset produces no more than it did before. The figure answers "how well did we execute the plan" and not "how much of this asset are we using". Where we land. ReliaSim® follows the convention many round-the-clock global manufacturers already use, where every minute counts. In a simulation the denominator is the full modeled period, staffed or not. It's the stricter basis. On the same line it gives a lower headline number than scheduled-time accounting, and we want it that way. A model exists to answer questions about the asset, and the asset doesn't stop existing when the schedule does. If your plant reports on scheduled time and you want to compare, reconciling the two is simple. Multiply the scheduled-time figure by the share of calendar time you actually scheduled. That puts it on the same basis the model uses, and any difference left after that is about the model, not the bookkeeping. ### What about quality? OEE's third factor is Quality, the share of output that was actually saleable. It's easy to assume a simulation ignores this and counts every unit the line pushed out. It doesn't have to. Several node types, and sets of nodes arranged as a construct, can be designed to represent scrap or rework. Model it and the simulation removes or recirculates rejected units the way the line does, so what it reports is good output. The Quality factor is then already inside the numerator, exactly where OEE puts it. So a simulated Efficiency with scrap modeled is the same measurement as OEE with a different denominator, not a loosely related figure. Availability shows up as interrupts, Performance as rate loss and Quality as modeled scrap or rework. All three factors are there, and only the time basis differs. If quality isn't modeled, the gap runs both ways. The simulated numerator then counts units the plant would have rejected, which pushes Efficiency up, while the wider denominator pushes it down. Two errors in opposite directions are far harder to explain in a meeting than one. Before comparing anything to a plant number, check whether scrap or rework is represented at all. Scrap and rework aren't interchangeable here. A scrapped unit leaves the count; a reworked one comes back and is eventually good. If the plant's Quality factor is first-pass yield, a model that recirculates rework will read slightly high against it, so check that before you set the two side by side. ### When the two numbers converge The gap disappears completely in one case, a plant that really does run 24/7. Schedule every hour and Utilization goes to 100%. TEEP collapses onto OEE, because there is no unscheduled time left for the wider denominator to count. A simulated Efficiency measured against a perfect calendar and a plant's OEE measured against planned time are then dividing by the same number, and they should agree. A published validation of a multi-line food plant shows that they do. It matched a one-year simulation to measured OEE within 1%, first in ExtendSim and then in a ReliaSim rebuild (the full validation is written up here). That validation checks each failure mode, not just the total. A single overall number can be right for the wrong reasons, with one mode overstated and another understated so the errors cancel out. Comparing observed against simulated availability for every failure mode separately can't hide that. ReliaSim builds that comparison in. Below, it's run on the bottling line demo model, which you can open yourself. Source vs. simulated availability, one marker per failure mode, against a y = x match line with 95% prediction and 99% confidence bands. The bottling line demo model, validated 2023–24. Points on the match line across the full range mean each failure mode was reproduced on its own terms, so the total is right because the parts are. It's also how you'd validate your own line. ### Which number to use, and when - To judge the shift you ran, use OEE. It measures execution against the plan, which is what a shift team controls. - To judge whether to buy another line, use Efficiency or TEEP. If you're at 50% of physical potential, a second line may be the most expensive way to solve a scheduling problem. - To size the hidden factory, use Efficiency against a perfect calendar, as in the 286,423-of-525,600 run above. - To compare a model to history, use neither ratio and compare the quantities instead. Units produced against units produced needs no denominator at all, so there is nothing to disagree about. The practical rule. Never put a simulated Efficiency and a reported OEE on the same axis against the same 100% line. A footnote explaining the difference won't survive contact with the chart. People trust the picture over the caption, and the picture will be wrong. When a model and a dashboard disagree, check the denominator before you check the model. That's nearly always where the gap is. ### Not all of it is recoverable A number nobody can act on is worse than no number. Some of the hidden factory can't be recovered at any price, and a credible estimate says which parts. - Physics and regulation. Sanitation windows, mandated changeover procedures, planned maintenance. These aren't waste. They're the cost of operating legally and safely. - Demand. Capacity you can't sell isn't an opportunity. A third shift that produces inventory nobody ordered converts one problem into another. - Labor and supply. The staffing or raw material for the extra hours may not exist, and that constraint may be firmer than the equipment one. What's left is the hidden factory you can actually recover. It's usually still large, because the interruptions inside the hours you already staff are rarely as small as they look. Frequent short stoppages do more damage than their minutes suggest, since a line with no slack passes every one of them along. You can't read from a loss report which fix returns what, because losses interact. The guide on which of the Six Big Losses to fix first covers the experiment that ranks them. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See the losses on a real line The bottling-line models in the Sandbox’s Lines tier come from a real line and need no install or signup. Their Gain/Loss results show how much OEE each interrupt costs and how much the line could recover in total. Open the sandbox → How the method works Want to see it on a real line first? Read the case study or schedule a call. --- # OEE Improvement: The Tradeoffs Behind Each Fix Source: https://reliasim.com/guides/oee-improvement-tradeoffs.html ## OEE Improvement Every Fix Is a Tradeoff OEE Guide ## OEE Improvement Every Fix Is a Tradeoff Most advice on how to improve OEE is a list: cut changeovers, fix breakdowns, eliminate minor stops, run at rated speed. Every item on it is sensible, and every item trades against something else on the line. The plants that raise output, rather than just the metric, are the ones that price the tradeoff before they spend. ### Why a list of fixes isn’t a plan OEE is Availability × Performance × Quality, and the Six Big Losses map onto those factors: equipment failure and setup onto Availability, minor stops and reduced speed onto Performance, process defects and startup yield onto Quality. That invites treating each loss as an independent lever. The levers are connected. Speed changes failure rates. Buffers change what a stoppage costs. A machine’s OEE and the line’s output are different quantities. And the metric itself can move because the schedule changed rather than the equipment. Five tradeoffs come up on nearly every line, and two experiments price most of them. ### Tradeoff 1: speed vs stops Performance loss is the gap between actual and rated speed, so the obvious fix is to run faster. On many machines, running faster also means more jams, misfeeds and minor stops, because failure rate rises with rate. Performance goes up, Availability comes down, and output follows whichever moved more. Fischel and Lange’s published model of a food plant, in which each unit operation’s failure rate scales with its production rate, finds that throughput has an optimum rather than rising steadily with speed. An analysis that treats rate and reliability as separate numbers can’t see it. ### Tradeoff 2: downtime vs buffer capacity On a loss report, downtime is downtime. On the line, what it costs depends on where it happens. Ten minutes down in front of a well-stocked buffer can cost almost nothing, while the same ten minutes on a starved constraint costs ten minutes of finished product (why the two rankings differ). So two levers compete. You can add storage so stoppages stay local, or make the machine stop less. Storage costs capital, floor space and work-in-process. Reliability work is often harder, but fixing a failure helps every machine downstream at once. The buffer tradeoff experiment puts both on one axis by sweeping a buffer’s capacity while dropping interrupts (Buffer Tradeoff results in the docs). The sweep, the knee where storage stops paying, and what storage really costs in a food plant are in How big should a buffer be? ### Tradeoff 3: machine OEE vs line OEE The 85% world-class figure is a single-machine benchmark. Where a line of such machines lands depends on its topology and buffering (Is 85% OEE achievable on your line?). For improvement work, that means raising a machine’s OEE raises line output only to the extent that machine’s losses were reaching the end of the line. A machine whose stops a buffer already absorbed, or which was starved or blocked by something else, can post a better number while the line makes the same product. The machine that limits the line also moves with downtime, product mix and schedule, which is the subject of theory of constraints simulation. ### Tradeoff 4: changeovers vs responsiveness Changing over less often cuts setup loss but trades it for inventory and responsiveness to the order book. Faster changeovers trade engineering effort instead, and what they return depends on where the changeover sits relative to the constraint. At a specialty olive packer, two-hour olive-size changeovers make the pitting machines a known bottleneck, and the model finds other choke points downstream in packaging (case study). Product mix can also move the bottleneck, a second-order effect a loss report can’t show. On a Make-Store-Pack coffee operation, changing the packaging size relocated the constraint, and a planning system that assumed a fixed constraint couldn’t schedule it until a rate-based model reproduced the behavior (The Shifty Bottleneck). There’s a tradeoff inside the metric, too. Because OEE is measured against planned production time, it can be improved by scheduling less. See Asset Efficiency vs OEE and the hidden factory. ### Tradeoff 5: maintenance spend vs recovered throughput Maintenance and reliability budgets are usually allocated from a downtime Pareto, largest bar first. That ranks losses by minutes (how often and how long something stopped), not by whether the line noticed. Frequent short stops on a tightly coupled line tend to cost more than their minutes suggest. Long stops on a buffered machine often cost less. Loss/gain analysis asks the question a budget needs answered, which is what comes back if we fix it. In a validated model of the line, disable one failure mode, re-run the whole line, measure the production recovered, and repeat for every interrupt. In ReliaSim® this is the Efficiency Gain/Loss experiment, with a reference version for the bottling-line demo models on ReliaSim’s public MCP server. The method, the demo results and why it needs failure-mode detail are in Which loss to fix first. ### Pricing the tradeoffs before you spend Every tradeoff above has the same structure. There are two levers that both raise some number, costs you already know, and a throughput effect you don’t. OEE simulation supplies the throughput side, as long as the model deserves trust. The published bar for that is within 1% of measured OEE. The five tradeoffs, and how to price each LeverWhat it improvesWhat it can costHow to price it Run fasterPerformanceAvailability, if failure rate rises with speedModel failure rate tied to rate; compare speeds Add buffer capacityOutput through short stopsCapital, space, WIP, shelf lifeBuffer tradeoff Raise one machine’s OEEThat machine’s numberNo line gain if its losses were absorbedStarved/blocked time; constraint timeline Fewer changeoversAvailabilityInventory, responsivenessModel the schedule and the mix Fix the biggest downtime barAvailabilityBudget, if the line never noticedLoss/gain analysis ### Frequently asked questions #### How do you improve OEE? Rank the Six Big Losses by the production each fix recovers across the line, not by minutes lost. Then weigh each fix against what it trades away before committing budget. #### Why did OEE improve but output didn’t? Usually it’s one of three reasons. The improved machine’s losses weren’t reaching the end of the line, a buffer was already absorbing the loss that was fixed, or planned time changed rather than the equipment. #### Does running a machine faster improve OEE? It raises Performance, but if failure rate rises with speed it lowers Availability, so throughput has an optimum speed rather than rising steadily. #### What is loss/gain analysis? It’s disabling each interrupt in a validated line model one at a time and measuring the production recovered, so losses are ranked by recoverable throughput instead of minutes lost. #### What is a buffer tradeoff analysis? It’s a sweep of a buffer’s capacity against line efficiency, with interrupts selectively removed, to find where extra storage stops buying throughput. #### Is 85% OEE a realistic target for a line? 85% is a single-machine benchmark. Five such machines in series with no buffering give a line near 44%. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See two tradeoffs priced on a line model The bottling-line models in the ReliaSim Sandbox’s Lines tier need no signup. The Sandbox also has two capital options run side by side, a buffer against a more reliable machine and one shared palletizer against two. Open the sandbox → Which loss to fix first Want to see it on a real line first? Read the case study or schedule a call. --- # Theory of Constraints Simulation Source: https://reliasim.com/guides/theory-of-constraints-simulation.html ## Theory of Constraints Simulation Finding a Constraint That Moves Throughput Guide ## Theory of Constraints Simulation Finding a Constraint That Moves Goldratt’s five focusing steps begin with “identify the constraint.” On a whiteboard that’s one step. On a line with breakdowns, buffers and a changing product mix, the constraint rarely sits still long enough to be identified once. So in practice it makes sense to simulate the constraint instead of assuming it. ### The five focusing steps Theory of Constraints (TOC) comes from Eliyahu Goldratt’s The Goal. Its premise is that one constraint at a time limits a system’s output, so improving anything that isn’t the constraint doesn’t improve output. The method is five steps, repeated: - Identify the constraint, the resource that limits the throughput of the whole system. - Exploit it. Get the most out of it as it stands, with no idle time, no wasted capacity and no defective work reaching it. - Subordinate everything else. Run every other resource to the constraint’s pace, not to its own local efficiency. - Elevate it. If it’s still binding, add capacity: another machine, a faster one, more hours. - Repeat. Once a constraint is broken, something else becomes the constraint. Go back to step one, and don’t let inertia (rules written for the old constraint) become the new one. None of that is controversial. The hard part is almost entirely step one, and whatever goes wrong there carries into the other four. ### The assumption hidden in step one The five steps read as though the constraint is a fixed property of the line: one machine, found once, then managed. On a paced line with reliable equipment, that’s close to true. On a high-speed packaging or process line it usually isn’t, for three reasons. #### Downtime moves it When a machine stops and the storage beside it runs out, that machine limits the line, whatever its rated speed. Minutes after it restarts, something else is. Which machine is limiting output at any moment depends on what failed last and how much storage sat between it and its neighbors. #### Product mix moves it Different formats run at different rates on different machines. Change the package size and the machine that was binding on one SKU may have slack on the next. #### The schedule moves it Changeovers, sanitation windows and staffing each take a resource out of the flow for a period, and for that period the constraint is whatever they took out. A constraint timeline from a ReliaSim® run: which station is actually limiting the line at each point. On a line with interrupts it’s rarely one fixed machine. Step one is a distribution, not a name. The useful question isn’t “which machine is the constraint?” It’s “what share of the time is each machine the constraint, and under what conditions?” The answer depends on how the line behaves through time, and a simulation answers it directly. ### Two plants where step one went wrong #### The constraint that moved with the package A quality initiative added a stage to an existing Make-Store-Pack coffee operation. The problem turned out to be scheduling, not the new stage. As packaging sizes changed, the bottleneck moved, because a different format draws from the store at a different rate and shifts which stage is binding. The plant’s Advanced Planning System was optimizing against a constraint that wouldn’t hold still. A discrete rate model that reproduced the moving bottleneck, rather than assuming it away, let the team test and verify a new scheduling algorithm across a range of demand scenarios before deploying it. In TOC terms, the model made step one honest, because the constraint was identified per format instead of once. It also let step three be tested before it was trusted. The account is qualitative, from our project record. See The Shifty Bottleneck. #### The constraint everyone could see At a specialty olive packer, the pitting machines take about two hours to change over between olive sizes. They are a known bottleneck. A capacity model of the whole plant confirms it and finds other choke points downstream, in packaging after the cans are filled and retorted. Scheduling rules tested in the model, including a Theory of Constraints-based daily schedule, recover 15% more throughput with no new equipment. That work predates ReliaSim as a product. The same team did it with the same rate-based method, and it’s written up in the olive plant case study. ### Step 1 by simulation: identify Simulation replaces the walk-around with a measurement. Build the line with each machine’s rate and its real interrupts (time to failure and time to repair for each failure mode), plus the buffers and conveyors between machines. Run it over a horizon long enough to include the rare events as well as the common ones. Then read three things: - Starved and blocked time per machine. The constraint is the machine that’s neither, the one still running while everything around it waits. See Starved vs Blocked. - Buffer levels. A buffer that runs chronically full points to a constraint downstream. One that runs chronically empty points upstream. See The Hidden Bottleneck. - When each machine holds the role. The constraint timeline shows whether you have one dominant constraint or several machines trading it. If one machine holds the role most of the time, classic TOC applies almost as written. If several share it, the steps apply to the set, and the “drum” has to be chosen deliberately. ### Step 2: exploit it by ranking losses on what comes back Exploiting the constraint means not wasting its time. On a production line most wasted constraint time is its own interrupts, plus the starvation and blocking its neighbors impose on it. The tempting shortcut is to attack the biggest downtime bar on the report. The measurement that holds up is to remove one failure mode in the model, re-run the whole line, and read how much output comes back. Those two numbers routinely disagree. Two failure modes with nearly identical direct losses can return very different amounts of output, as micro stops vs breakdowns shows on our bottling line. Which loss to fix first covers the method in full. ### Step 3: subordinate with drum, buffer, rope Drum–Buffer–Rope is TOC’s scheduling form of subordination. The drum is the constraint’s pace, which sets the rate for the whole line. The buffer protects the drum. It’s stock placed ahead of the constraint so upstream stoppages don’t starve it, and in TOC it’s sized and managed in time rather than in units. The rope ties material release to the drum, so the rest of the system doesn’t overproduce into inventory the constraint can’t use. On a continuous or high-speed line the buffer is physical, such as an accumulation table, a surge tank or an accumulating conveyor. That has two consequences, and simulation earns its keep on both. - Protect both sides. A constraint loses time by being starved from upstream or blocked from downstream. Stock ahead of it covers the first; free space after it covers the second. - Size on the stoppage distribution, not the average. A buffer covers a stoppage only while it has stock to give. Illustrative example, not a result QuantityValueMeaning Constraint draw rate60 / minwhat drains the buffer Typical upstream stoppage4 minhow long it must be covered Buffer to cover it240 units60 × 4 Double the buffer480 unitscovers an 8-minute stop, which is worth little if few stops run that long Plot efficiency against buffer capacity and the curve always bends, steep at first and then flat. Where the knee falls is specific to the line, so buffer size should be swept rather than guessed. How big should a buffer be? runs that sweep. ### Step 4: elevate, then see where the constraint goes next Elevation is where static TOC analysis is most likely to over-promise. Add capacity at the constraint and output rises only until the next-most-limiting resource starts to bind. After that, extra capacity at the old constraint produces nothing except more starved and blocked time elsewhere. The gain from elevating is the distance to the next constraint, not the size of the upgrade. A model shows that distance before you pay for it. Raise the constraint’s rate or remove its dominant interrupt, re-run, and take the step-one readings again: which machine is now the constraint, how often, and how much output came back. If the next machine takes over almost immediately, the proposal is a two-machine project or a smaller one. Watch for a machine that ends up mostly blocked. After an upgrade, a machine that spends most of its time blocked is making more than the next step can take, so the upgrade has already been used up. ### Step 5: repeat, and keep the model current Goldratt’s warning about inertia is the step most often skipped. Product mix changes, a machine is rebuilt, or a buffer is removed to free floor space, and the constraint moves without anyone announcing it. A line model kept current turns step five into a re-run rather than a new study. That only works if the model is validated against the line’s own history, per failure mode rather than only in aggregate. See the salad dressing plant case study. ### Why dice games and spreadsheets stop short TOC is usually taught with a dice game or a capacity spreadsheet, and both teach the principle well. Variability in a chain of dependent steps loses output, and the constraint governs. Neither can tell you about your line. A capacity spreadsheet takes each machine’s average rate and finds the minimum, which assumes the constraint is fixed and the variability averages out. A dice game has the right mechanism but none of your machines, failure modes or buffers. Simulation keeps the mechanism and adds the specifics (each machine’s rate, each failure mode’s distribution, each buffer’s capacity), played forward through time. ReliaSim uses discrete rate simulation, which models flow as rates rather than individual items, so sweeps of thousands of runs finish in seconds. Try the twist yourself: Beat the Bottleneck. On a bottling line, either improve reliability (fix one problem) or add buffers, and ReliaSim runs your line for 90 days, ten times over. The machine with the most downtime is the obvious fix. See whether it wins, and whether any fix beats buffer. Play Beat the Bottleneck → ### Frequently asked questions #### What is theory of constraints simulation? It means using a simulation model of a production system to carry out TOC’s five focusing steps by measurement rather than assumption. The model identifies which resource limits throughput and how often that changes. It tests ways to exploit and protect that resource, and it shows where the constraint moves after it’s elevated. #### Can the bottleneck on a production line change? Yes. Downtime, product mix and the schedule all move it, and a simulation run shows what share of the time each machine is the constraint. #### What is drum-buffer-rope on a production line? The drum is the constraint’s pace, the buffer is stock (measured in time) that protects it from upstream stoppages, and the rope ties material release to the drum. #### How big should the buffer in front of the constraint be? Big enough to cover the upstream stoppages that actually occur, sized on their distribution rather than the average. A capacity sweep in a model shows where more storage stops paying. #### Does elevating the constraint always increase throughput? Only until the next-most-limiting resource becomes the constraint. Simulating the upgrade first shows how much output it buys before then. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### Find the constraint on a demo line The bottling-line models in the ReliaSim Sandbox’s Lines tier need no signup. Each shows every machine’s availability from a saved engine run, and you can ask which station limits the line. Open the sandbox → The Shifty Bottleneck Play Beat the Bottleneck Want to see it on a real line first? Read the case study or schedule a call. --- # Capacity Without Capital Source: https://reliasim.com/guides/capacity-without-capital.html ## Capacity Without Capital What to Change Before You Buy Throughput Guide ## Capacity Without Capital What to Change Before You Buy When a line can’t keep up, the first proposal is usually equipment: a faster machine, bigger storage, a second line. Sometimes that’s the right call. But most lines have capacity the plant already paid for and isn’t getting, and the cheap changes are often worth more than the expensive ones. The hard part is knowing which is which before anything is spent. ### Where the capacity you’ve paid for goes Output gets lost in four places that don’t take capital to fix: - The wrong failure mode gets the attention. Maintenance hours go to the biggest bar on the downtime report, which isn’t always the one that gives the most back. - Storage sits in the wrong place. The same amount of buffer can be worth a lot or very little, depending on where it is. - The schedule fights the plant. Run lengths and sequences that don’t match what comes next lock up storage the plant already has. - Habits on the floor. Small, frequent stops that everyone has learned to live with. None of these shows up on a capacity spreadsheet. A spreadsheet works with averages, and these losses come from timing: when stops happen, how long they last and what’s in storage at the time. A line model plays that timing out. Here’s what each change is worth on our demo models and in plants we’ve modeled. ### 1. Fix the failure mode that gives the most back Maintenance and operating practice cost hours, not capital. The question is which hours. Ranking problems by downtime is the usual approach, and it’s often wrong, because some stops hurt the whole line and others are mostly absorbed. Demo bottling line · no buffers · 90 days, ten runs each Problem removedHours downLine efficiency None (the line as it is)–54.3% Capper: upper plow area, the biggest problem on the constraint198 h61.5% Labeler: misalignment143 h59.2% Filler: micro stops148 h62.1% The Filler’s micro stops cost fewer hours than the Capper’s plow-area stops, and removing them gives back more. The published gain/loss for the same line makes the same point from the other side. The Labeler’s misalignment costs 6.79% on paper and gives back 5.0 points; the Filler’s micro stops cost 6.72% and give back 8.1. See micro stops vs breakdowns and which loss to fix first. The fixes in the order to make them, worked out with engine runs on the model, are an Improvement Roadmap. On this line it takes seven fixes to reach 85%, or five steps with one 100-case buffer before the Palletizer: the buffer and four fixes. Try it in the Sandbox. ### 2. Put storage where it protects the constraint Accumulation isn’t free to move, but it costs far less than a new machine, and where it sits matters as much as how much there is. Same line · the same twelve slots of buffer (600 in all) · 90 days, ten runs each Where the buffer goesPalletsLine efficiency No buffer70,43254.3% Worst placement: 2 slots at Buffer 1, 10 at Buffer 281,25562.7% Best placement: 9 slots at Buffer 1, 3 at Buffer 388,22768.1% That’s the same amount of storage, with 8.6% more pallets from where it goes. Pair the Filler fix with its own best placement and the line reaches 77.2%. How big should a buffer be? runs the full sweep. ### 3. Fix the schedule before the plant In a make-store-pack plant, the bins between making and packing only help if the right product is in them when packing needs it. The Sandbox’s demo vegetable plant has a packing schedule timed to 24-hour making runs. Cut the making runs to 12 hours and making moves on to the next vegetable before packing is ready for it. Its bins fill, making blocks, and packing waits for product nobody is making. That’s bin lock. Demo vegetable plant · same packing schedule in every run PlanCases packedMinutes the plant is stuck Making runs cut to 12 hours27,916654 The capital answer: 12-hour runs, bins twice as big31,455571 The schedule answer: making runs timed to packing36,8320 Doubling the bins wins back about 40% of the lost cases, and the plant still locks up. Fixing the schedule costs nothing and wins it all back. You can try it yourself in the Sandbox’s bin lock question. Real plants show the same thing. A specialty olive packer tests scheduling rules on a model of the whole plant, including a Theory of Constraints-based daily schedule, and gets 15% more throughput with no new equipment (case study). A cereal plant runs its model before every shift so the planners can change the plan before trouble reaches the floor. ### 4. Change habits on the floor Some of the cheapest gains come from the people running the line. At a salad dressing plant, a model built from the plant’s own downtime records finds that at least two failure modes on the labeler have high leverage, and that closer attention from the operators can address them. No single machine turns out to be the answer. Many small improvements add up to “many points of %OEE,” and operators who see on screen how their own stops move the line become more vigilant (case study). A flight simulator for your plant covers training on the model. ### 5. Don’t fund the project that wouldn’t have worked The cheapest capital is the capital you don’t spend on the wrong thing. A major food manufacturer saves an estimated $5 million across 40 models, mostly by stopping bad projects (case study). A soap maker consolidating plants finds that its planned machine assignments would cause a quality problem needing a $4 million retrofit, and tests other routings in the model that avoid it (case study). When capital is the answer, it’s a smaller answer. The salad dressing model also flags two machines worth doubling up. Running the no-capital changes first doesn’t rule out spending. It means the request that’s left is smaller and aimed at the right machine. ### The order to work in - Build the line from its own stop records, one failure mode at a time, and check it against what the line actually measured. - Find the ceiling. Run the line with no stops to see the most it can make, then see where the gap goes. - Rank the failure modes by what comes back, not by hours lost. - Sweep buffer placement before buffer size. - Test the schedule: run lengths, sequences, changeovers. - Then price capital against whatever gap is left. Try changes 1 and 2 yourself: Beat the Bottleneck. On the demo bottling line, either improve reliability (fix one problem) or add buffers, and ReliaSim® runs the line for 90 days, ten times over. The biggest problem on the constraint is the obvious fix. See whether it wins. Play Beat the Bottleneck → ### Frequently asked questions #### How do you increase production capacity without capital investment? Fix the failure modes that give the most throughput back, put existing storage where it protects the constraint, match run lengths and sequences to what the next stage needs, and work on operating habits. A model of the line shows what each change is worth before you make it. #### Will bigger storage fix a line that keeps locking up? Not always. If the schedule fills storage with product the next stage doesn’t need yet, bigger storage only delays the lock. On our demo vegetable plant, doubling the bins still leaves the plant stuck 571 minutes; fixing the schedule takes it to zero. #### How do I know which downtime to fix first? Remove each failure mode in a model of the line, run it, and rank by how much output comes back. That ranking often differs from the downtime Pareto. #### When is new equipment the right answer? When the gap that’s left after the no-capital changes is still bigger than the target. The model then shows which machine to spend on and how much that buys before the next constraint takes over. Try it on a real bottling line: the Sandbox question Where should the buffer go, and how big?, or one move in Beat the Bottleneck. #### Find the capacity you already own Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Try bin lock in the Sandbox --- # A Flight Simulator for Your Plant Source: https://reliasim.com/guides/flight-simulator-for-your-plant.html ## A Flight Simulator for Your Plant Training on a Playing Field Built From Your Own Line Training Guide ## A Flight Simulator for Your Plant Training on a Playing Field Built From Your Own Line Pilots don’t learn what to do after an engine failure by waiting for one. They practice in a simulator until the right response is a habit. Most plants still train the other way, so people learn what a stopped capper does to the rest of the line by watching it happen, one expensive shift at a time. A model of your own line lets your team try a move, watch what the line does over the next 90 days, and try again, all before anything changes on the floor. ### Why plants need practice, not only procedures Standard work tells people what to do when a machine stops. It doesn’t teach them how the line behaves: how a stop on one machine spreads, which storage covers it and for how long, or why the machine with the most downtime isn’t always the one to fix. That understanding usually takes years on the floor, and a lot of it leaves when experienced people retire. It’s also where good people guess wrong, in the same few ways in plant after plant. Three examples from our demo models: - “Fix the biggest bar.” On our demo bottling line, the Capper’s upper plow area is the biggest single problem on the constraint, at 198 hours down over 90 days. Removing it takes the line from 54.3% to 61.5%. Removing the Filler’s micro stops, at 148 hours, takes it to 62.1%. - “More storage will fix it.” On the demo vegetable plant, cutting making runs from 24 hours to 12 locks up the bins. Doubling the bin size still leaves the plant stuck for 571 minutes. Timing the making runs to packing gets it to zero. - “Buffer is buffer.” Put the same twelve slots of buffer on the bottling line in the best spots and it makes 88,227 pallets in 90 days. Put them in the worst spots and it makes 81,255. None of these is hard to understand once you’ve seen it happen. A simulator lets people see it happen without losing a shift. Beat the Bottleneck, built on our demo bottling line. Each machine shows its availability from an engine run. Pick one problem to fix, and the line runs 90 days, ten times over. The same screens can be built on your line. ### What a playing field is We call the model a playing field. It covers the scope you choose, a line or a whole plant, built from your own data, and you play moves out on it before making them for real. It isn’t a live copy of the plant. It’s somewhere to practice. ReliaSim® is a composable simulator. A model is a graph of nodes (machines, buffers, conveyors, splits and merges) connected in almost any topology, so the playing field is built in your line’s shape, however complex it is. For training, the playing field has to be right before anyone practices on it, because people learn whatever the model teaches them, mistakes included. So a training model gets the same check as a study model. It’s built from your own stop records, one failure mode at a time, and it has to reproduce what the line actually measured before anyone uses it. Our published validation model lands within 1% of the plant’s measured OEE (the case study). ### What people practice on it #### How variation adds up: the dice round Before the model, the mechanism. Everyone gets a blue and a red 20-sided die. The blue die is the time until the next stop, and the red one is how long the stop lasts. Both come from a real machine’s stop log: line the run times up from shortest to longest, and the die picks a spot in the line. Roll them through a four-hour shift and the group sees that no two shifts come out the same, and that the “average machine” isn’t a machine anyone has ever run. It takes ten minutes, and nobody needs a statistics background. #### What to fix first Pick one failure mode, take it away in the model, run the line and read what comes back. Then try another. Operators and maintenance planners learn to rank fixes by what the line gets back, not by the hours on the downtime report. Which loss to fix first covers the method. #### Where storage goes Place a fixed amount of buffer and run the line. Move it and run it again. People see why storage that protects the constraint pays and storage in the wrong spot does very little. How big should a buffer be? runs the full sweep. #### The shift ahead Planners run the next shift’s plan on the model and look for trouble: a packing line about to run dry, a bin about to fill, a changeover landing at the wrong time. If they find it, they change the plan before the shift starts. One cereal plant runs its model before every shift. #### Run lengths, changeovers and new products Try a different run sequence, a shorter campaign or a new package size, and see what it does to the rest of the plant before the schedule goes out. The bin lock question in the Sandbox shows one schedule change on a demo vegetable plant. ### What changes on the floor When the model shows operators how their own stops move the whole line, the way they work changes. At a salad dressing plant, the plant’s engineering team reports that operators who saw this on screen became more vigilant and took more ownership of the improvements. Some of the best fixes needed no capital at all, only closer attention from the operators to two failure modes on the labeler. The details are in the salad dressing case study. The same goes for new supervisors. Someone who has run the line through a bad week on the model has a feel for it that usually takes years on the floor. Build a game on your own line. Beat the Bottleneck is our demo of the format: improve reliability or add buffers, and ReliaSim runs the line for 90 days, ten times over, with a leaderboard for each choice. The same format works inside a plant, with your machines, your stop records and a leaderboard for your shifts or sites. Play Beat the Bottleneck → ### What a build includes - Your stop log, turned into failure modes for each machine and fitted with ReliaStats®. - A model of the line or plant, checked against what it actually measured before anyone trains on it. - The moves your people should practice, chosen with you: fixes, buffer, run lengths, staffing, changeovers. - Engine runs behind every answer. Every result the game shows comes from a ReliaSim run of your model. - Screens that run in a browser on a training-room TV, a laptop or a phone, plus a dice round for the classroom. The playing field is an ordinary ReliaSim model, so it doesn’t end with the training. Your engineers can keep using it for their own studies, and we can teach them how. ### Who builds it We’ve been delivering training and building simulators for 35 years. Andy Siprelle wrote the original official ExtendSim training course, and our team trained hundreds of simulation professionals through it. Today we teach a two-day course at the University of Tennessee’s Reliability & Maintainability Center that counts toward the RMIC® credential, along with one-hour online sessions on each part of the workflow (training). The method underneath, discrete rate simulation, comes from the same team, and ReliaSim is its third generation. ### Frequently asked questions #### What is a training simulator for a manufacturing plant? It’s a model of your own line or plant that people can practice decisions on, such as what to fix, where to keep storage and how to run the schedule. They see the result over weeks of production in seconds, instead of learning it on the floor. #### How is it different from a digital twin? A digital twin is usually connected live to the plant. A training playing field doesn’t need a live feed. It needs to be validated, so that it behaves the way your line behaves. #### Do people need to know simulation or statistics? No. The game asks plant questions in plant terms, like which problem to fix and where to put storage, and answers in output. The dice round explains variation with two dice and a stop log. #### What does it run on? The game screens run in a web browser on a TV, laptop or phone. Building and changing the model itself uses the ReliaSim desktop software. #### Can our engineers keep using the model afterwards? Yes. The playing field is a ReliaSim model, so it carries on as a study model after the training is done. #### Want a playing field for your plant? Tell us about the line and who needs to learn it. We’ll show you what a game built on your own data would look like. Schedule a call → Play Beat the Bottleneck Training courses --- # Spreadsheet, AI or Simulation for What-If? Source: https://reliasim.com/guides/spreadsheet-ai-or-simulation.html ## Spreadsheet, Dashboard, AI or Simulation? Which One Can Answer What-If Comparison Guide ## Spreadsheet, Dashboard, AI or Simulation? Which One Can Answer What-If Four tools get pointed at the same question: where is our throughput going, and what should we change? A spreadsheet and a dashboard both describe what already happened. A model trained on history can’t answer for a line it has never seen. Each one fails in a different way, and how they fail matters more than their feature lists. ### The spreadsheet, or loss tree Almost every plant starts here, and for good reason. A loss tree is transparent, it costs nothing, anyone in the room can audit it, and it’s usually right about the total. If you want to know how many minutes were lost last month and roughly to what, a spreadsheet answers that well. Where it breaks is interaction. A loss tree adds losses as if they were independent, and they aren’t. Where a stoppage sits in the line decides what it costs, so two stoppages of equal length can cost completely different amounts. The spreadsheet has no column for that. Which Loss to Fix First works through what that does to a ranking. Loss trees misrank improvement projects. The ranking is what you act on. An averaging model can point the maintenance budget at the wrong machine while the arithmetic looks spotless. ### AI, on its own and on top of a model A model trained on your historian is good at pattern-finding that a spreadsheet can’t do, like spotting a signature that comes before a failure, or two events that show up together more often than chance. But a model learned from history can only answer questions about configurations that appear in the history. Ask about a fifty-pallet accumulator between the labeler and the case packer and it’ll still answer, with an extrapolation dressed as a prediction (see why predictive maintenance can’t answer what-if and why an LLM will answer anyway). The useful setup is AI running a validated simulation instead of standing in for one. You ask in plain language, the engine computes the answer, and every figure traces back to a run you can reproduce. ### Simulation, and what it costs A discrete-rate model answers counterfactuals because it computes the answer instead of learning it. Rates, capacities and interrupts interact mechanically, so blocking and starvation emerge from the flow rather than being assumed. Change the buffer and the model has never seen that line before either, and it doesn’t need to. The cost is real: - You have to build a model, which means describing the line's structure rather than just exporting its data. - You need failure data good enough to parameterize it. Lumped downtime gets you a working model; named failure modes get you one that tells you which machine to fix. - It has to be validated before it’s worth anything. An unvalidated simulation is a confident answer with no more standing than the AI's. Our models are checked against measured production per failure mode, not just in aggregate. See Asset Efficiency vs OEE for what that comparison involves and why the denominator has to be agreed first. What’s changed is how long it takes. A conventional study ran for months and ended with the three scenarios someone picked in advance. With ReliaSim®’s engine speed, a sweep like How big should a buffer be? takes minutes. ### Two things a spreadsheet structurally can’t do A loss tree is a static, mean-value model, and a production line is neither static nor deterministic. #### It has no clock A spreadsheet has no representation of when. A table of totals has no way to show a buffer filling and then draining, a stoppage propagating upstream three stations later, or a machine starved for the first hour of a shift and blocked for the last. You can add a column for downtime. You can’t add a column for sequence, and sequence decides whether ten minutes of downtime cost anything at all. #### It computes with averages, and averaging is biased This is the more serious of the two, because you can’t be careful around it. For machines in series with buffers between them, expected throughput is strictly less than the figure you get by multiplying average rates and average availabilities. The mean of the output isn’t the output of the means, and the error always runs the same way. Loss-tree forecasts run optimistic in a consistent direction. Averaging removes the very variability that makes a real line underperform its nameplate, and no amount of care with the inputs corrects it. The arithmetic is exact in only one case, a single resource with no upstream or downstream interaction, when all you want is the long-run mean. That describes very few packaging lines. Add a second stage and a buffer and the exactness is gone. ### What a loss tree is actually for A loss tree is the right tool for accounting. It gives a shared, auditable statement of what happened last month. The mistake is carrying it over into prediction. ### The dashboard, and the what-if it can’t answer A plant dashboard is a rear-view mirror with excellent resolution. It’ll show you yesterday’s OEE by line, this week’s top five stoppages and the shift that underperformed. Every figure on it sums up something that already happened, and that’s why every plant has one. A disruption question isn’t a measurement. Take “what if this supplier is two weeks late,” “what if we lose the second line for a shift,” or “what if demand is 20% above plan in October.” Each one asks about a plant that hasn’t existed. Nothing in a table of last month’s numbers can answer it, no matter how many ways you slice it. The usual fallback is to reason from averages, and that runs into the same bias as the loss tree above. #### Keep the dashboard None of this argues for replacing it. The dashboard is how you know how the plant is doing today, spot a drift and run a shift. It’s also where the raw material comes from, since a model is built from the stop and start times your historian already records. The mistake is asking the record a question only a model can answer, then acting on the answer because it showed up in a familiar format. #### Four questions to ask in your next review - “Is this a measurement or an estimate?” Both appear on dashboards, usually in the same typeface. - “What would we get back if we fixed it?” Ask that instead of what it cost. - “Where did this stoppage actually originate?” Costs get logged against the machines around the cause. In our bottling line case study, two failure modes with nearly the same direct loss differed by 62% in the throughput a fix recovered (how to spot it). - “Have we ever checked this against a year we already lived through?” A tool that can’t reproduce the past hasn’t earned a question about the future. A peer-reviewed plant model and its ReliaSim rebuild landed within one percentage point of measured OEE across a full year. Which tool for which question QuestionReach forWhy What did we lose last month?Spreadsheetcounting, not modeling How is the plant running today?Dashboardmeasurement, not a model Which tag predicts this failure?AI on historypattern-finding at scale Which machine is actually costing us?Simulationinteraction decides the ranking What if we add a buffer / a line / a shift?Simulationno history exists for it What if a supplier is two weeks late?Simulationa plant that hasn’t existed yet All of the above, quicklyAI + validated modelmechanism, asked conversationally #### Ask a model instead of a spreadsheet The bottling-line models in the Sandbox’s Lines tier come with the engine’s saved results, and you can ask about them in plain language with no install or signup. Open the sandbox → How the method works Want to see it on a real line first? Read the case study or schedule a call. --- # Reliability Block Diagram vs Line Simulation Source: https://reliasim.com/guides/reliability-block-diagram-vs-simulation.html ## Reliability Block Diagram vs Line Simulation Availability Is Not Throughput Reliability Guide ## Reliability Block Diagram vs Line Simulation Availability Is Not Throughput A reliability block diagram answers one precise question, which is what fraction of the time a system is able to run. On a production line, people often ask it a different question, which is how much the line will make. The diagram answers that one poorly as soon as there’s storage between the machines. ### What a reliability block diagram calculates A reliability block diagram (RBD) draws a system as blocks, each with its own reliability or availability. The blocks are connected in series (the system needs every block) or in parallel (the system needs at least one, or some k of n). For repairable equipment, each block’s steady-state availability is its share of time up, and the diagram combines the blocks: The RBD arithmetic ArrangementFormula One blockA = MTBF / (MTBF + MTTR) Series (all blocks needed)A = A1 × A2 × … × An Parallel (any one block suffices)A = 1 − (1 − A1)(1 − A2)…(1 − An) 81%two 90% blocks in series (illustrative) 99%the same two blocks in parallel That arithmetic is exact under its assumptions, and everything depends on those assumptions. Every block fails and is repaired on its own clock, independently of the others. In a series diagram, the system is down whenever any block is down, starting at once and lasting exactly as long. ### A production line isn’t a series diagram Draw a bottling line as an RBD and it looks like a textbook series system. The line needs all five machines (Filler, Capper, Labeler, Case Packer, Palletizer), so you multiply their availabilities. On the five-machine bottling line in our case study, the per-machine availabilities are 84.3%, 75.9%, 88.5%, 97.9% and 84.3%. They multiply to 46.7%. The line’s tracked OEE was 54.3%. OEE also carries speed and quality losses, so any such loss on that line would make the availability gap even wider. Top: the per-machine availabilities from the case-study line, multiplied as a series RBD. Bottom: a schematic of what the multiplication leaves out. Storage between machines lets neighbors keep running through a stop. The lower diagram shows decoupling in general. It isn’t a picture of that line’s layout. A gap of seven and a half points is too big to be rounding error. Gaps like it come from two things the multiplication can’t see. #### Storage decouples failures When there’s storage between two machines, such as a buffer, a surge table or an accumulating conveyor, a stop on one doesn’t immediately stop the other. The downstream machine keeps drawing on stock; the upstream machine keeps filling space. The series diagram charges every stop to the whole line the instant it happens. The physical line charges it only once the storage runs out, so for any stop shorter than that, the series product overstates the loss. #### Idle machines don’t wear on the running clock A machine that’s starved or blocked isn’t running. If its failures build up with operating time (jams, misfeeds, wear), it isn’t moving toward the next one while it waits. The product formula assumes every block keeps failing on its own clock regardless of the others. So even a close-coupled line with no storage at all tends to do better than the product predicts. Illustrative example, not a result Five identical machines, close-coupled with no storage, each 90% available (MTTR/MTBF = 1/9). Two textbook answers for line availability: AssumptionLine availability Failures on wall-clock time, independent (series RBD)0.95 ≈ 59.0% Failures only while running (a stopped line pauses every clock)1 / (1 + 5 × 1/9) ≈ 64.3% Whether a failure mode runs on operating time or on the calendar depends on the failure mode, not the line, so it has to be decided mode by mode. ReliaSim®’s interrupts support competing, cumulative and wall-clock criteria for that reason. Decoupling has limits too. A buffer covers a stop only while it has stock to give, so long stops still propagate. Sorting out which stops get through takes a simulation, not a better formula. How much storage that takes is in How big should a buffer be?, and the range between no buffering and unlimited buffering is in Is 85% OEE achievable on your line? ### Availability isn’t throughput, even when the RBD is right Suppose the availability figure were exact. It still wouldn’t be line output, because a block diagram leaves out most of what sets output: - Rates. An RBD has no rates. Output is set by the flow the line can sustain. Machines with different speeds don’t appear in a block diagram at all, and neither do converters that change the unit from bottles to cases to pallets. - Starved and blocked. A block is up or down. A stopped machine on the floor may be down, starved or blocked, and only the first is its own fault. See Starved vs Blocked. - Which fix pays. Because the diagram treats every block’s downtime as line downtime, it ranks improvements by availability. On a real line the same minutes cost different amounts, depending on where and how they happen. See micro stops vs breakdowns. - Speed against failure rate. Running faster raises output only until failures that rise with rate eat the gain. The Winter Simulation Conference study below finds that throughput has an optimum rather than rising steadily. A static availability number has no rate to trade against. ### Where the reliability block diagram is the right tool None of this makes RBDs wrong. They’re the tool for a different level of the system, and the published study behind our validation work used them at exactly that level. Fischel and Lange’s Winter Simulation Conference paper models a multi-line food plant with a reliability block diagram inside each rate-affecting unit operation. Each diagram carries that unit’s failure modes, up to twenty on each of more than twenty unit operations, and lets its failure rate scale with production rate. The line itself doesn’t come from a block diagram. It comes from discrete rate coupling through the valves, tanks and conveyors between the units. That model agrees with measured OEE to within 1% over a one-year run (salad dressing plant case study). RBDs fit well in these places: - Inside a unit operation. A machine with several failure modes behaves like a series of modes, since any one of them stops it. Its availability is the block’s natural output. - Where nothing decouples. A shared utility or a control system with no storage behind it stops everything it serves, and series/parallel arithmetic describes that honestly. - Early redundancy questions. Does a second unit in parallel pay for itself in availability? An RBD answers quickly, before there’s enough detail for a line model. - Per failure mode, never averaged. The paper is blunt about why: “Had an averaged, single-failure-mode-per-unit-operation approach been followed, the gains and losses would be less accurate and essentially identical to each other.” ### Where line simulation takes over The handoff is storage and rate. Once the question is output from a line with buffers, accumulating conveyors, differing speeds or a product mix, the answer depends on the sequence of events. It matters which machine stopped, for how long, and how full the storage was at the time. A simulation plays that sequence forward. It takes the same per-failure-mode inputs an RBD uses and adds what the diagram leaves out. Which tool answers which question QuestionRBDLine simulation Availability of a machine or redundant subsystemYes, its natural outputYes, carried as an input Line throughput with storage between machinesNot from block-diagram arithmetic. Some RAM packages add a throughput simulation on top of the diagramYes Starved and blocked time per machineNoYes Which failure mode to fix firstBy availability onlyBy output recovered How big a buffer should beNoSwept against efficiency Speed against failure rateNoYes, where failure rate is tied to rate The inputs are the same for both: time to failure and time to repair for each failure mode. When a plant has event history, fitting them is downtime data analysis. When it doesn’t, ReliaSim’s Interrupt Designer lets you enter them directly. If you’re weighing tools for the line model itself, see manufacturing simulation software. ### Frequently asked questions #### What is a reliability block diagram? A diagram of a system as blocks, each with its own reliability or availability, arranged in series (every block needed) or parallel (at least one needed). It calculates system reliability or availability from the blocks’ values, assuming they fail independently. #### Can a reliability block diagram calculate production line throughput? Not directly. An RBD produces availability. Throughput also depends on machine rates, unit conversions and the storage between machines, and a block diagram represents none of those. #### Why does a series RBD understate a line’s output? It charges every stop to the whole line immediately and keeps every machine failing on its own clock, while storage and idle time let a real line do better. #### How do you calculate series and parallel availability? Series: multiply the block availabilities, A = A1 × A2 × … × An. Parallel, where any one block suffices: A = 1 − (1 − A1)(1 − A2)…(1 − An). Each repairable block’s steady-state availability is MTBF / (MTBF + MTTR). #### When should I use an RBD instead of line simulation? Inside a unit operation, where nothing decouples, and for early redundancy decisions. Use line simulation once output depends on buffers, differing rates or a product mix. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See decoupling on a real line model The bottling-line models in the ReliaSim Sandbox’s Lines tier need no signup. The Buffer-Options models carry a saved sweep for each inline buffer, and the Buffer/Reliability comparison sets a buffer against a more reliable machine. Open the sandbox → The published validation Want to see it on a real line first? Read the case study or schedule a call. --- # RAM Analysis: Reliability, Availability, Maintainability Source: https://reliasim.com/guides/ram-analysis.html ## RAM Analysis Reliability, Availability and Maintainability for Production Lines Reliability Guide ## RAM Analysis Reliability, Availability and Maintainability for Production Lines A RAM analysis asks whether a system will deliver the production it was designed for once its equipment fails, gets repaired and gets maintained. It’s usually done while the design is still cheap to change. It rests on three quantities that are easy to blur together. This guide defines them and covers what a RAM study answers and how established tools approach it. It also shows where discrete rate simulation fits for high-speed production and packaging lines. ### Reliability, availability and maintainability, defined - Reliability is the probability that an item performs its function, under stated conditions, for a stated period without failing. It’s described by the item’s time-to-failure distribution. It says nothing about how long a failure lasts. - Maintainability is the probability that a failed item is restored within a given time when maintenance is done with the prescribed procedures and resources. It’s described by the time-to-repair distribution. In practice, downtime also includes waiting for a crew, a spare part or a permit. So RAM studies usually model maintenance logistics separately from the repair itself. - Availability is the share of time an item is able to perform when required. It combines the other two. An item can fail often and still be highly available if it’s restored quickly. Inherent availability counts only repair time; operational availability counts every source of downtime, including logistics and planned maintenance. Many RAM studies of production systems report production availability, the share of planned production actually delivered, rather than time-based availability. The distinction matters as soon as a failure reduces capacity instead of stopping everything, or as soon as storage lets part of the system keep producing through a stop. Distributions in, averages out. A RAM model takes a time-to-failure and a time-to-repair distribution for each failure mode. MTBF and MTTR are outputs, not inputs, so they can be checked against history. Two machines with the same means but different distributions can behave very differently in a system. ### What a RAM study answers A RAM study turns equipment behavior into decisions. It’s usually asked to answer these questions: - Production availability forecasts. What the system is expected to deliver, and how widely that varies from year to year. - The biggest loss contributors. Which equipment, failure modes or events account for most of the lost production. - Redundancy. Whether a standby pump, a parallel train or a spare machine pays for itself. - Maintenance strategy. Preventive intervals, inspections, and which items to run to failure. - Spares. Which parts to hold on site, weighed against their lead times and the cost of capital tied up in stock. - Crews. How many technicians, on which shifts, and how long they take to reach a failure. Most RAM studies happen at the design or capital-planning stage, when those choices are still open, and the model is refined and reused as the asset moves into operation. ### How RAM analysis is done today The workflow is broadly shared. Define the system boundary and its configuration. Collect failure and repair data for each failure mode, from field history, the plant’s maintenance system or reliability databases. Build a model of how failures combine: a reliability block diagram, a fault tree, or a network of equipment with capacities and storage. Then either compute the result exactly or simulate many operating lifetimes, and read out availability, loss contributors and sensitivity to design and logistics changes. Three established tool families show the range. Each is described here only as its publisher describes it. #### ReliaSoft BlockSim (HBK) HBK describes BlockSim as a platform for system reliability, availability, maintainability and related analyses that uses “exact computations or discrete event simulation” for repairable and non-repairable systems. Its listed analyses include reliability, maintainability and availability analysis, reliability optimization, throughput calculation, resource allocation and life cycle cost estimation (Intro to BlockSim). Systems are modeled as reliability block diagrams, fault trees or Markov diagrams, and the questions it lists include optimum maintenance strategy, spares holdings and crew capacity (Quick Tour). Its throughput analysis assigns each block a processing rate and routes items along the diagram’s path. Items a block can’t process are kept in backlog, and failures and repairs are tracked over time (Throughput Analysis). #### DNV Maros and Taro DNV positions Maros for upstream assets and Taro for downstream ones. DNV says Maros “employs an event-driven simulation technique using RAM analysis,” accounting for equipment reliability, configuration and capacity, maintenance logistics and operational logic. It identifies the assets or events with the highest contribution to performance losses. DNV’s page also covers crew mobilization time, alternative spares strategies against long lead times, and production compensation such as storage. DNV recommends starting early, at concept screening (Maros). Taro is built for complex networks such as refineries and petrochemical plants, where production efficiency depends on reliability, blending and yield rules, flow routing and intermediate storage. Its results include criticality, buffer statistics, unit production and outage (Taro). #### Isograph Availability Workbench Isograph’s write-up of an advanced RAM modeling webinar describes Monte Carlo simulation in Availability Workbench, including wear-out failures, maintenance schedules and rotating equipment. The same page covers spares and labor, and a capacity analysis for failures that degrade a system rather than stop it. It also covers a buffer model with time to fill and time to empty for temporary backup such as a tank, multiple product streams, and cost profiles with net present value and escalation. Availability Workbench also lists a Life Cycle Cost module (Isograph). ### Where discrete rate simulation fits On a high-speed production or packaging line, the RAM question takes a particular shape. Availability becomes throughput through the line’s dynamics. Accumulation conveyors and surge tables fill and drain in minutes. A stop downstream blocks the machines upstream; a stop upstream starves the machines downstream. Machines run at different rates, converters change the unit from bottles to cases to pallets, and a large share of the losses are short stops measured in seconds. How much of each machine’s downtime reaches the end of the line depends on all of that, moment by moment. Discrete rate simulation, created by Andrew Siprelle in 1995, models that directly. Flow is represented as rates. Events occur only when a rate changes: a failure, a repair, a changeover, a buffer reaching full or empty, a machine becoming blocked or starved. Between events, buffer levels change linearly, so accumulation is computed exactly rather than approximated. The method-level comparison with a block diagram is in reliability block diagram vs line simulation, and the tool-level comparison with BlockSim is in ReliaSim® vs BlockSim. The inputs are the same raw material every RAM study uses, at failure-mode resolution. Each machine in ReliaSim carries multiple interrupts, each with its own time-to-failure and time-to-repair distribution, triggered on competing, cumulative or wall-clock criteria. Where a plant has event history, those distributions come from Weibull analysis of downtime data. The output is OEE, the number a line is already measured on. Forecasting a line’s OEE from a validated model is covered in OEE simulation. ChiAha runs RAM-style studies for production lines on this basis. If you’d rather have the study done than build the model yourself, see manufacturing simulation consulting. ### Which approach fits which question Most RAM questions can be answered more than one way. The table lists where each approach is most direct, not where the others stop. Question, approach, and why QuestionMost direct approachWhy Reliability of a product or system design, repairable or notReliability block diagram, exact or simulatedReliability is the diagram’s natural output Combinations of causes behind an undesired eventFault tree analysisWorks top-down from the event Early redundancy decisionsReliability block diagramFast, before layout and rates are settled Production availability of an energy or process facility, with logistics and storageRAM simulation built for those assetsConfiguration, capacities, crews, spares and storage in one model Maintenance strategy, spares, labor and life cycle costRAM simulation with maintenance and cost modelingTasks, resources and costs are modeled explicitly Throughput and OEE of a high-speed line with accumulation between machinesDiscrete rate line simulationBuffers, blocking, starving and rate changes drive the answer How big a buffer or accumulation conveyor should beDiscrete rate line simulationBuffer capacity can be swept against line efficiency Which failure mode to fix first for line outputDiscrete rate line simulationEach interrupt can be removed and the output recovered measured Time-to-failure and time-to-repair distributionsLife data (Weibull) analysisEvery approach above needs them as inputs ### Running a RAM study on a production line - Fix the question and the measure. Production availability, throughput, OEE, or cost of a decision, stated before any modeling starts. - Gather events per failure mode. Line event logs and maintenance records, kept at failure-mode resolution rather than rolled up to one downtime number per machine. - Fit distributions. Time to failure and time to repair for each mode, with the fit checked, not assumed. - Build the model at the right level. Block diagrams where nothing decouples; rates, buffers and converters where accumulation sets output. - Validate against history. Run the model over a period the plant has measured and compare OEE and throughput before trusting any scenario. - Run the decisions. Redundancy, buffer capacity, maintenance changes and failure-mode fixes, each compared on the production it returns. ### Frequently asked questions #### What is RAM analysis? RAM analysis is the study of a system’s reliability, availability and maintainability. It looks at how often the equipment fails, how quickly it’s restored, and what share of the time, or of planned production, the system delivers as a result. A RAM study models the system’s configuration, failure and repair behavior, and maintenance. It’s typically used at the design or capital-planning stage to test whether a design will meet its production target. #### What is the difference between reliability and availability? Reliability is the probability an item runs a stated period without failing. Availability is the share of time it’s able to run, which also depends on how quickly it’s restored. #### When should a RAM study be done? Usually early, while design choices such as redundancy, storage and maintenance strategy are still cheap to change. Do it again when a major change is being considered for an operating asset. The same model can be refined as the project moves from concept to operation. #### What software is used for RAM analysis? Established RAM tools include ReliaSoft BlockSim, DNV Maros and Taro, and Isograph Availability Workbench. For high-speed production and packaging lines, discrete rate simulation such as ReliaSim models how availability becomes line throughput. #### Do RAM models use MTBF and MTTR as inputs? They’re better treated as outputs. The model takes a time-to-failure and time-to-repair distribution per failure mode, and MTBF, MTTR and OEE come out of the run. #### Can a RAM model predict line OEE? Yes, when it’s built from per-failure-mode data and validated against the line’s history. A validated model has come within 1% of measured OEE. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See availability become throughput The bottling-line models in the ReliaSim Sandbox’s Lines tier need no signup. Each schematic shows every machine’s availability from a saved engine run next to the line’s efficiency, and the buffer sweeps show what each inline buffer adds. Open the sandbox → ReliaSim vs BlockSim Want a RAM study of your own line? Talk to ChiAha or schedule a call. --- # Value Stream Map Simulation: VSM With a Clock Source: https://reliasim.com/guides/value-stream-map-simulation.html ## Value Stream Map Simulation A Static Map Hides the Constraint Lean Guide ## Value Stream Map Simulation A Static Map Hides the Constraint A value stream map is one of Lean’s best tools for getting a room to agree on how material and information actually move. But it’s a photograph, and everything on it is an average or a snapshot. The behavior that decides throughput on a high-speed line happens between the snapshots. Value stream map simulation adds the clock the map leaves out. ### What a value stream map captures A current-state value stream map, in the form set out in Rother and Shook’s Learning to See, is drawn by walking the process. Each process box carries a data box: cycle time, changeover time, uptime, operators, available time. Inventory triangles record how much material was sitting between steps. Customer demand sets takt time. A timeline along the bottom sets production lead time against processing time, and the gap between them is usually the headline. That’s a lot of value from a pencil and a walk. The map makes waste visible, puts information flow next to material flow, and gives everyone the same picture. An illustrative current-state map of a high-speed bottling line. Every figure in a data box is a single average, and the timeline sets 4.5 days of production lead time against 0.377 seconds of processing. ### What a static map can’t show The limits come from what a map is, not from how carefully it was drawn. #### Every number is an average “Uptime 88%” in a data box is one figure for what’s really a pattern of stops: how often, how long, and how the lengths vary. Two machines at 88% can behave nothing alike on a line. One stops briefly and often, the other rarely and for a long time, and a buffer beside them protects against one and not the other. #### It has no clock An inventory triangle records the stock on the day of the walk. It says nothing about the buffer filling while the next step is down, draining while the previous one is, or sitting empty for the first hour of a shift. A spreadsheet has the same limit, as Spreadsheet, AI, or simulation? explains. You can add a column for downtime but not a column for sequence, and sequence decides whether ten minutes down costs anything at all. #### The constraint looks fixed On a map, the constraint is the process whose cycle time comes closest to takt, or the one with the biggest pile in front of it. Both treat the constraint as a property of one box. On a line with breakdowns, buffers and a changing mix it moves. See theory of constraints simulation. #### Losses don’t add up Summing each process’s downtime, or multiplying uptimes along the map, assumes the steps are independent. Buffers and starving and blocking make them dependent. For machines in series with buffers between them, arithmetic on averages overstates throughput. The pile in front of a process can mean the process is slow, or that the one after it keeps stopping. The map can’t tell those apart, and Starved vs Blocked explains how to. ### The future-state map and the buffer question A future-state map usually removes inventory, while Theory of Constraints protects the constraint with a deliberate buffer. How big should a buffer be? sets out both. It also explains why a triangle taken out without the variability behind it comes back as lost capacity or longer lead time. A map can’t tell you which triangle is waste and which is a decoupling buffer holding the line together. The difference depends on the stop patterns on either side and where the constraint sits, and a static picture leaves out both. ### Turning a current-state VSM into a rate-based model Almost everything on the map carries over into a simulation model, as long as each average is replaced by what it summarizes. For a high-speed line the natural form is a rate-based model, which represents flow as rates rather than moving every unit individually. ReliaSim® uses that approach, which is why large experiments finish in seconds. From map to model On the mapIn the modelWhat changes Process box, cycle timea machine with a rateconvert cycle time to units per minute; add rate losses Uptime %interrupts, per failure modetime-to-failure and time-to-repair distributions from event data, not one percentage Changeover timeplanned stops tied to the schedule and mixwhen changeovers happen matters as much as how long Inventory trianglea buffer with a capacitythe count on the map is one moment’s level; the model needs the maximum Push arrow, conveyora conveyor with travel time and accumulationtransport can be storage Customer demand, taktdemand on the linetest against the weeks you get, not the average week Scrap, reworkquality loss or recirculationcount good output the way the line does The step that takes real work is the second row. Uptime percentages come from somewhere, usually a line event data system or a historian, and the raw stop records underneath are what the model needs. Downtime data analysis in ReliaStats fits distributions per failure mode from those records. For a line that doesn’t exist yet, the shapes can be entered by hand and refined later. ### Validate the current state, then test the future state A current-state map is checked by walking the floor. A current-state model is checked against the line’s own history. Run it over the same period, compare each failure mode’s simulated availability with what the historian recorded, and compare line efficiency with measured OEE (salad dressing plant case study). Once the current state reproduces the line, each kaizen burst on the future-state map becomes an experiment. Remove an inventory triangle and see whether output holds. Cut a changeover and see whether the constraint moves. Raise one machine’s uptime and see how much reaches the end of the line. Sweep a buffer’s capacity instead of picking one. The future state stops being a drawing of what should happen and becomes a result you can check. ### Where the map still belongs Simulation doesn’t replace the walk, the conversation or the map. The map is still the fastest way to agree on scope, show information flow, and see lead time against processing time. A model adds nothing to those. It answers the question the map raises and can’t settle, which is what the line will actually produce if we make this change. Draw the map first, then give it a clock. ### Frequently asked questions #### What is value stream map simulation? It means turning a value stream map into a simulation model that runs through time. Process boxes become machines with rates, uptime becomes failure-mode distributions, and inventory triangles become buffers with capacities. The model is validated against the line’s history and then used to test the future state. #### Why isn’t a static value stream map enough? Its numbers are averages and snapshots with no clock, so it can’t show buffers filling and draining, stoppages propagating, or the constraint moving. #### Is simulation compatible with Lean? Yes. The map stays the tool for scoping, information flow and lead time. Simulation answers the question the future-state map raises, which is what the line will actually produce if the change is made. That includes whether removing an inventory triangle costs capacity. #### What data do you need to simulate a value stream? Process rates, time-to-failure and time-to-repair records per failure mode, buffer and conveyor capacities, changeovers and schedule, and demand. Uptime percentages alone aren’t enough. #### Should inventory in the future-state map be removed? Only where the variability it absorbs is removed too. A validated model shows which inventory is waste and which is protecting the constraint. Try it on a real bottling line: the Sandbox question Where should the buffer go, and how big?, or one move in Beat the Bottleneck. #### See a value stream as a line model The bottling-line models in the ReliaSim Sandbox’s Lines tier need no signup. Each one shows the line’s schematic and the engine’s saved results, and you can ask how a stop at one machine affects the rest. Open the sandbox → Lean vs TOC on buffers Want to see it on a real line first? Read the case study or schedule a call. --- # Why Predictive Maintenance Can't Answer What-If Source: https://reliasim.com/guides/predictive-maintenance-cannot-answer-what-if.html ## Why Predictive Maintenance Can’t Answer What-If Losses Guide ## Why Predictive Maintenance Can’t Answer What-If Condition monitoring is good at the question it was built for, which is when will this machine fail? By design, it can’t answer a second question, what do we get back if we fix it? Those questions aren’t the same, and on a real line the answers can point at different machines. ### Two different questions A predictive-maintenance system learns from sensor data, such as vibration, temperature and current draw, collected from your plant as it runs today. From that it forecasts a failure before it happens. That works, and it’s worth having. But every one of those readings comes from one specific plant, with the buffers you have, at the speeds you run, in the order your machines are arranged. Ask what happens if you add a buffer, run the filler slower, or fix a different failure mode first, and the data is describing a line that no longer exists. Nothing in the sensor history of the plant you have describes a plant you haven’t built. ### Even a perfect failure prediction ranks the wrong thing Suppose the prediction is flawless, with every failure caught and every hour of downtime attributed correctly. You still have a loss report, and a loss report ranks failure modes by what they cost. What you need is a ranking by what comes back when you remove them. Those are different numbers, and the gap isn’t small. In our bottling line case study, a five-machine line had two failure modes that a downtime Pareto ranks level: Same loss, different return Failure modeDirect lossReturned when removedReturn ÷ loss Labeler Misalignment (rare, long stops)6.79%+5.0 pts0.73× Filler Micro Stop (frequent, short stops)6.72%+8.1 pts1.21× Most teams pick the Labeler, because it’s the bigger single event, the one people remember and the one with a work order attached. The one beside it recovers 62% more throughput when it’s fixed instead. ### Why these aren’t two similar things The Labeler stops rarely, for a long time. When it does, the buffers do their job. Stock upstream of it gives the machines before it somewhere to send product, and stock downstream keeps the machines after it fed. The line absorbs part of the stop. So removing it returns less than it appeared to cost. The Filler stops constantly, for seconds at a time. In the case study, it had 120 one-minute micro stops. A buffer absorbs a stop only if it has stock when the stop begins, and at that frequency the buffers never refill between events. So the losses stop being absorbed and start spreading. Any report built on machine-level data misses the next part. Those 120 micro stops landed as idle time on the Labeler, the Case Packer and the Palletizer, recorded under their names and never under the Filler’s. The Filler starves the machines after it and blocks the machines before it. The Filler’s own record looks moderate. No amount of sensor accuracy on the Filler recovers a cost that was written down against three of its neighbors. No Pareto ordered by machine finds it either, because the evidence has been scattered across the line under the wrong headings. ### What actually crosses the boundary To answer what if, you need a model of the whole line that reproduces output you’ve already measured. It has to include every machine, its failure modes and the buffers between them. Then you change one thing, re-run and compare. The change can be one you’ve never made, because the model works out the behavior rather than recalling it. You can trust that step because the method has been checked against reality. A peer-reviewed WSC 2020 plant model matched measured OEE within one percentage point over a full year, and so did its ReliaSim® rebuild. Validation and prediction are two different claims, and the order matters. Matching a year you can check is what earns a model the right to be believed about a configuration nobody has built yet. ### What this doesn’t say It doesn’t say condition monitoring is wrong. If a bearing is failing, you want to know before it does, and a vibration signature will tell you sooner than a model will, so keep your condition monitoring. It says there’s a question condition monitoring was never built to answer. That question, what does this change return, is the one standing between a maintenance budget and a defensible business case. ### How to tell which you have - Look for stops recorded against machines that weren’t the cause. Idle, starved and blocked time on the machines around a suspect is the signature of a cost that has been redistributed. - Compare stop counts, not only stop hours. A hundred short stops and one long stop can log identical downtime and behave nothing alike. - Check whether your buffers ever refill. A buffer that’s empty when the next stop starts isn’t a buffer anymore. - Ask what a fix returns, not what the failure costs. If nobody can answer that with a number, the ranking is a guess. Related: micro-stops vs breakdowns takes the same pair further, and how big a buffer should be covers the absorbing side. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Why an LLM Can't Answer What-If for Your Line Source: https://reliasim.com/guides/why-ai-cannot-answer-what-if.html ## An LLM Will Answer Your Question That Is the Problem Method Guide ## An LLM Will Answer Your Question That Is the Problem Ask a chatbot whether a second palletizer gets Line 3 to next year’s volume and it’ll tell you, fluently and with a number, in seconds. It has no model of your line. It has read a great deal about palletizers and is producing the most plausible continuation of your sentence. You can’t tell that answer from a correct one by looking at it. ### What it’s actually doing A language model predicts text. Given your question, it produces what a well-informed answer to that question tends to look like, assembled from everything it has read. It’s a remarkable capability, and for a lot of tasks it’s the right tool. But your line isn’t in its training data. It doesn’t know about the buffer between your filler and your capper, the changeover you lose forty minutes to on Tuesdays, or the fact that your palletizer is starved rather than slow. It has never seen your historian. When it returns “roughly a 12–15% throughput improvement,” that figure isn’t a calculation. It’s the kind of number that shows up in sentences like the one you asked for. ### Why that’s worse than being wrong A tool that fails visibly is manageable, because you see the error, stop, and find another way. Here the wrong answer looks just like a right one. It has the right shape, the right units and a confident tone, and often a plausible-sounding justification underneath. So the usual defense, “we’d check it,” doesn’t work, because there’s nothing to check it against. Checking means comparing to something that knows your line, and if you had that, you wouldn’t have asked the chatbot. In most contexts a confidently wrong answer costs you an afternoon. In a capital decision it costs you the decision, and you find out two years later when the line still can’t make the volume. The question isn’t whether the model is clever. It’s whether anything it said was derived from your plant. ### What we do instead, and where we do use AI We offer an AI / MCP add-on that connects an assistant to your validated model. You can ask it questions in plain language and run scenarios conversationally, against a local model if you want one. Use ReliaSim® from Claude or ChatGPT shows how to connect one to the public reference models. The difference is what produces the number: Two different jobs What produces the answerCan you check it? A chatbot answering directly text prediction over things it has read No, there’s nothing underneath it ReliaSim a discrete-rate and reliability model of your line, built from your own stop history, run thousands of times Yes, against the output you already measured We don’t use a language model to build the model. The model is built from your line event data (the stops and starts your historian is already recording), with distributions fitted per failure mode. An assistant helps you ask questions of it and read the answers back in plain language. It’s the interface, never the engine. ### The test that separates them One question is worth asking of any tool that offers to answer a what-if about your plant. What did it reproduce before it predicted? A peer-reviewed WSC 2020 plant model matched a full year of measured OEE within one percentage point, and so did its ReliaSim rebuild. The claim isn’t about cleverness. It could have been falsified, and it wasn’t. A chatbot can’t make that kind of claim, because it didn’t reproduce your year. It only produced a sentence about it. ### Where a language model helps The add-on is for jobs like these: - Asking the model questions without learning its interface. “Which failure mode costs the most on Line 2?” is a better way in than a menu. - Reading results back in plain language, including the ones you didn’t think to ask for. - Getting oriented in an unfamiliar field, such as what a buffer does, why micro-stops matter, or what OEE leaves out. - The writing around the work: the summary, the business case, the email to your plant manager. Every one of those sits on top of something that knows your line. So the assistant is an add-on to a validated model, not a product of its own. ### What to ask a vendor - “What is this answer derived from?” If the honest answer is “a language model,” it’s a guess in a confident voice. - “What did it reproduce before it predicted?” A tool that can’t match a period you already measured hasn’t earned a question about one you haven’t. - “Would it give me the same answer twice?” A simulation run again on the same inputs behaves the same way, and text generation doesn’t. - “Can I see the assumptions?” A model has inputs you can argue with, and a sentence doesn’t. Related: why predictive maintenance can’t answer what-if makes the same argument about a different tool. That tool knows your plant intimately and still can’t tell you what a change returns. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Test a Line Change Across Every Product Source: https://reliasim.com/guides/test-every-configuration-every-product.html ## Every Configuration, Every Product Testing a Line Change Across the Whole Product Range Guide · Method ## Every Configuration, Every Product Testing a Line Change Across the Whole Product Range A packing, staffing or equipment change has to work for every product a line makes, and a few scenarios on a representative product won’t show where it breaks. Here’s how one food plant, making about 15 million units a year for 17 distribution centers and direct-store delivery, tested every line in every configuration for every product. That added up to about 30,000 replications, executed from the command line. The example~15M units a year · 17 DCs + direct-store delivery Products12–24 per line Line models15, current and future state Replications~30,000 · 100 per scenario ### Every product runs differently Each product has its own manufacturing physics: its rates, pack size, changeovers and the station that limits it. A configuration that works for one product can fail for the next, and the line’s stops and micro-stops interact with all of it. A few scenarios on a representative product would have averaged away the variation the decision depends on. ### Current state against future state In the current state the lines pack eaches. The future state case-packs everything. Three ways of getting there were tested on each line, on one or two shifts: manual case packing, or an automated case packer with overflow either shipped as eaches or packed by hand. Every line in its current and future state configurations, run for every product it makes. ### How it ran - Parameter sets generated from the plant’s own data (time studies, planning rates and line event data) for every product, instead of entered by hand one scenario at a time. - Executed from the command line. Each model is loaded once and run across all of its products, 100 replications each, with one result row per replication. - The same engine as the ReliaSim® desktop application. Command-line runs reproduced the desktop results in 20 of 20 replications, within 0.005 units. When each scenario is built and run by hand, the analyst’s time limits how many questions get asked. On this project it didn’t. The findings belong to the client and aren’t published here. The method applies to any plant weighing a packing, staffing or equipment change across a wide product range. #### See the engine’s results The bottling-line models in the Sandbox’s Lines tier show saved results from the same engine, with no download or sign-up. Open the sandboxSchedule a call --- # Downtime Data Analysis for Production Lines Source: https://reliasim.com/guides/downtime-data-analysis.html ## Downtime Data Analysis for Production Lines Line event data → distributions ## Downtime Data Analysis for Production Lines A Pareto of downtime minutes tells you where the time went. It does not tell you what the line will do when you change it. For that you need the stop-by-stop event data, separated by failure mode and turned into time-to-failure and time-to-repair distributions a simulation can run. ### What line event data looks like Any line with a historian or a downtime tracking system already records the raw material for this analysis: one row per stop. ReliaStats calls it line event data (LEDS), the event tape. Formats vary from one system to the next, but the useful content is always the same: - Where: the machine, place or unit operation that stopped. - Why: the interrupt or cause code, such as "Misalignment", "Photo Eye" or "Micro Stop". - When: a stop start and a stop end, or a start and a duration. - Or already derived: the uptime before the stop and the downtime of the stop, in minutes. Here are the first rows of the Bottling Line demo file that the ReliaStats tools load by default. It holds 6,000 stop events across five machines, with uptime and downtime already in minutes. LocationInterruptUptimeDowntime FillerFiller_Micro Stop0.0141.644 PalletizerPalletizer_Triangle/Palletizer0.7660.508 CapperCapper_Micro Stop1.8610.103 FillerFiller_Micro Stop2.6251.142 CapperCapper_Lower Plow Area0.0040.535 LabelerLabeler_Misalignment0.7707.446 First six rows of bottling-line-demo.csv. Uptime is the run before the stop and Downtime is the length of the stop, both in minutes. Real exports are messier. Some systems write the end column as a date with no clock time, so the end has to be rebuilt from start plus duration. Many plants export dates day-first (13/10/2024), which a parser expecting month-first will silently scramble. Rows flagged as planned or excluded need to come out. Long non-operating gaps, like a weekend or an idle shift, should not count as time the machine ran without failing. The Interrupt Explorer handles each of these. It reads .xlsx and .csv, works out whether a date column is day-first, rebuilds end times from durations, and offers an optional exclude filter and an abnormal-uptime cutoff. ### Why downtime totals and a Pareto aren't enough The standard downtime report ranks causes by total minutes lost. That is a good place to start and a poor place to stop, for three reasons. #### Totals merge frequency and duration A hundred one-minute stops and a single hundred-minute stop cost the same minutes. On a line with accumulation between machines they are different problems. A buffer rides out the short stops completely and does little about the long one. ReliaSim®'s guide How big should a buffer be? works through that arithmetic. #### Totals ignore when stops happen A machine that stops again within two minutes of every restart behaves differently from one that runs for an hour between stops, even with the same stop count. Chronic re-stops are a pattern in the timing, and a total can't show a pattern. #### Loss is not gain Removing a failure mode does not simply hand back its downtime. Buffers absorbed some of that loss, and some of it happened while the machine was starved anyway. Some of it cascaded downstream. In ReliaSim's methodology example on the bottling line, Labeler Misalignment accounts for a 6.78% loss but returns a 5.10% gain when removed. Filler Micro Stop accounts for 6.67% and returns 7.97%. The losses are close, but no ranking of losses could have told you which removal returns more. Questions like that need a model of the line driven by the statistical behavior of each failure mode. Building one starts with the event data. ### Separate failure modes before you fit anything A machine rarely fails in just one way. In the demo file the Capper stops for twelve different interrupt codes, the Palletizer for twelve and the Filler for seven. A glue-station fault, a jam at the plow and a sub-minute micro stop have different causes, different fixes and different statistical shapes. If you pool them into one "Capper" distribution, you get a blend that fits none of them. You also get a model that can't tell you what happens when you fix one. So downtime analysis works at the level of the cause group: the place and interrupt code that behave as one failure mode. The ReliaStats desktop app identifies cause groups automatically, and the Explorer lets you drill down from a place to the modes within it. The causes compete When one line has several failure modes, whichever fires first ends the run. Measured the usual way, that inflates every time to failure and pushes survival curves toward 100% for every cause, hiding the very differences you are looking for. The Explorer sets up each cause's runs correctly when it rebuilds them from timestamps. ### TTF and TTR: two distributions per interrupt Each failure mode becomes an interrupt with two distributions: - Time to failure (TTF): how long the machine runs before this interrupt occurs. It controls how often the line is interrupted. - Time to repair (TTR): how long the machine is unavailable once it happens. It controls how disruptive each interruption is. Their means are the MTBF and MTTR, and availability follows from them: MTBF / (MTBF + MTTR). But a simulation doesn't sample the means. It samples the distributions, and the spread and tail of each one decide how often stops outlast a buffer and how often they cluster. The distributions are the model's inputs; MTBF and MTTR are outputs, summaries of what happened that you check a model run against. The companion guide, MTBF vs MTTR: outputs, not inputs, shows why two machines with identical MTBF and MTTR can run a line very differently. ### Fitting distributions to downtime data Once runs and repairs are separated by cause, each sample is fitted against candidate distributions. ReliaStats® fits all eight distribution types ReliaSim supports: Weibull, LogNormal, Normal, Exponential, Uniform, Triangular, Johnson SU and Fixed. It tests goodness of fit with Kolmogorov-Smirnov and Anderson-Darling and ranks the candidates. Parameters come out exactly as ReliaSim stores them, including real-space mean and standard deviation for LogNormal, so there is nothing to convert by hand. A good statistical fit still needs an engineering read. For uptime, the Weibull shape parameter κ tells you where the failure mode sits on the bathtub curve. κ < 1 means early-life failures whose rate falls over time, κ = 1 means random failures at a constant rate, and κ > 1 means wear-out. If a fit puts a mature, well-maintained machine in infant mortality, check the data again before the fit goes into a model. For repair time, check the right tail. A handful of very long stops often matter more to throughput than the typical one. ### The ReliaStats workflow: explore, fit, inspect, simulate, validate - Explore Interrupt Explorer Load a stop log and get an Interrupt Pareto by place, with drill-down into modes. For each cause it shows stops per 24 operating hours, the share of runs that end within a reliability window of the previous restart (2 minutes by default) and the resulting chronic stop rate. It also overlays survival curves R(t) for the whole line and selected causes. Everything runs locally in your browser. - Fit ReliaStats desktop app Import the raw failure and repair event log. The app identifies cause groups automatically, fits and ranks distributions, and exports a fitted interrupt file for ReliaSim. - Inspect Interrupt Designer & Viewer Look at any TTF + TTR pair: PDF, CDF and survival curves, a p5–p95 box-and-whisker, a working/failed timeline over a shift and the availability the pair implies. - Simulate ReliaSim Run the line with each machine carrying its own interrupt signature instead of a shared average. - Validate Interrupt Validation Plot source availability against simulated availability, interrupt by interrupt, with fixed 95% prediction-interval and 99% confidence-interval bands. Points on the diagonal match history, and points outside the bands show where to refine and re-run. This is the loop ReliaSim's methodology describes: build from real data, validate that the model matches the line’s measured OEE (a published case matched within 1%), and only then use it for what-if decisions. Quick Start and Designer are free with no account. The Explorer opens with the Bottling Line demo after you sign in. Working with your own files, and desktop fitting, are part of a ReliaStats subscription. ### How the output parameterizes a ReliaSim model The end product of downtime data analysis is an interrupt file with one row per interrupt. Each row carries an uptime distribution type with up to four parameters, a downtime distribution type with up to four parameters, and a maximum downtime. ReliaSim imports it as CSV. From there the simulation reports availability, throughput and efficiency. Blocking and starving emerge from how rates, buffers and interrupts interact, not from rules someone had to write. An OEE report describes the losses you had, and an OEE simulation predicts the losses you will have after a change. For the same reason, a reliability block diagram falls short for a buffered line. Series and parallel reliability math tells you whether a path is up, not what the accumulation between two machines is holding. For the modeling itself, see ReliaSim's production line simulation software. For help scoping a line, ChiAha offers manufacturing simulation consulting. ### Frequently asked questions #### What is downtime data analysis? Turning the record of when, where and why a production line stopped into something you can act on. At its simplest that is a downtime Pareto. For simulation it means separating failure modes and fitting a time-to-failure and a time-to-repair distribution to each one. #### What data do I need to analyze machine downtime? A stop-event log. For each stop: the machine or place, the cause code, and either start and end times (or a start and a duration) or the uptime and downtime in minutes. An .xlsx or .csv export from a historian or downtime tracking system is enough. #### What is line event data (LEDS)? The stop-by-stop event record of a production line: the raw tape that interrupt distributions are fitted from, as opposed to rolled-up shift or daily totals. #### Why not just use MTBF and MTTR for each machine? They are averages, and a simulation samples the whole distribution. How many stops are very short and how many are very long decides how often a stop outlasts a buffer, so two machines with the same MTBF and MTTR can affect line throughput differently. #### Which distribution fits downtime data best? There is no universal answer, which is why ReliaStats fits all eight ReliaSim distribution types and ranks them with Kolmogorov-Smirnov and Anderson-Darling tests. Weibull is the usual starting point for uptime because its shape parameter maps onto the bathtub curve. Right-skewed distributions such as LogNormal are common for repair times. #### Does my event data leave my machine? No. The browser tools process files locally, and distribution fitting runs inside the downloaded desktop application. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See what a TTF + TTR pair does to availability Start in the free ReliaStats® Designer. It opens in the Sandbox, with no account and no data upload. Launch the Designer → Or book a live walkthrough of ReliaStats. --- # Weibull Analysis of Downtime Data Source: https://reliasim.com/guides/weibull-analysis-downtime-data.html ## Weibull Analysis of Downtime Data Shape, Scale and Failure Modes Reliability guide ## Weibull Analysis of Downtime Data Shape, Scale and Failure Modes Weibull analysis is life data analysis applied to a production line. You fit a distribution to the runs between stops and read what its parameters say. Done per failure mode, it shows whether stops come early, at random or with wear, and it produces the time-to-failure and time-to-repair inputs a line simulation needs. Published 13 September 2026 · ChiAha ### What Weibull analysis is, on a production line Classic life data analysis starts from the ages at which parts failed. On a production line the equivalent record is the stop log: for each failure mode, the runs between stops are time-to-failure (TTF) samples and the stop durations are time-to-repair (TTR) samples. The three-parameter Weibull distribution is: F(t) = 1 − exp(−((t − γ) / λ)κ) - Shape κ (often written β): how the failure rate changes with running time. - Scale λ (often written η): the characteristic life, in the same time units as the data. - Location γ: an optional failure-free period. With γ = 0 this is the two-parameter Weibull. ReliaSim® stores a Weibull as λ, κ and γ, and ReliaStats uses the same parameters. Weibull is the usual starting point for uptime because one shape parameter spans all three phases of the bathtub curve, but it is not always the best fit, so it is tested against other candidates. ### The shape parameter: κ < 1, κ = 1, κ > 1 The shape parameter sets the hazard rate, the rate of stopping for a machine that has run t minutes since restart: h(t) = (κ / λ) · (t / λ)κ − 1 - κ < 1, falling hazard: early-life failure, or on a line, stops that cluster just after a restart. - κ = 1, constant hazard: the exponential distribution. Running time says nothing about the next stop. - κ > 1, rising hazard: wear-out. A stop becomes more likely the longer the machine runs. Illustrative arithmetic, not fitted to data Three failure modes, each with an MTBF of 60 minutes: the chance of a stop in the next 10 minutes, by how long the machine has already run. Already runningκ = 0.5κ = 1κ = 2 Just restarted43.9%15.4%2.2% 30 min14.3%15.4%14.2% 60 min10.7%15.4%24.7% 120 min7.8%15.4%42.0% Computed from Weibull distributions with a mean of 60 min: λ = 60 / Γ(1 + 1/κ), R(t) = exp(−(t/λ)κ), and P(stop within 10 min | running t) = 1 − R(t + 10) / R(t). Same MTBF, opposite risk profiles, and different actions: - κ > 1: time-based inspection or replacement can prevent stops, because risk builds with running time. - κ = 1: time-based maintenance does not lower the failure rate, so the effort belongs in removing the cause or shortening the repair. - κ < 1: every restart puts the machine back into its riskiest period. Look at setup, adjustment and the minutes after a jam clears. The Interrupt Explorer's reliability window (2 minutes by default) measures the share of runs that end that soon after a restart. A shape estimate describes the data, not the machine. A mature machine that comes back with κ < 1 may have pooled failure modes or stops logged twice, so check the data before the fit goes into a model. ### Scale and location Scale λ is the characteristic life: whatever the shape, 63.2% of runs have ended by t = λ, because F(λ) = 1 − e−1. It is not the mean, which is λ · Γ(1 + 1/κ). With λ = 60 minutes, κ = 0.5 gives a mean of 120 minutes, κ = 1 gives 60 and κ = 2 gives 53.2. Compare fits on shape and mean together. Location γ shifts the distribution right, so no failure occurs before γ. Use it when the data shows a real failure-free period after restart; otherwise it is one more parameter to overfit. ### Fit each failure mode, not each machine The most common Weibull mistake on a production line is fitting one distribution to all of a machine's stops. The failure modes compete, each run ending at whichever fires first, so the machine's hazard is the sum of the modes' hazards. No single Weibull can follow a falling hazard and a rising one added together. Illustrative arithmetic, not fitted to plant data A machine has two failure modes. Mode A is a restart problem: Weibull κ = 0.7, λ = 150 min. Mode B is a wearing part: Weibull κ = 3, λ = 80 min. Neither mode is random. Now fit one Weibull to every run on the machine, whichever mode ended it. Two modes (true)One pooled Weibull Shapeκ = 0.7 and κ = 3κ = 1.3 Mean run49.9 min49.2 min Runs ending within 10 min14.1%10.5% Runs lasting over 120 min1.5%5.5% The pooled column is the maximum-likelihood Weibull for the exact two-mode run distribution, computed numerically and checked against 200,000 sampled runs. The pooled fit gets the mean about right, so it passes an MTBF check. Its shape of 1.3 reads as mild wear-out, not far from random, and hides both real findings: early re-stops are about a third more common than it predicts, and runs over two hours nearly four times rarer. A maintenance plan built on κ = 1.3 would miss both. That is why ReliaStats works at the level of the cause group, the place and interrupt code that behave as one failure mode, identified automatically in the desktop app. The modes also compete: one mode's stops cut short the runs of every other, and the usual way of measuring each mode's runs makes every fit look better than the line really is. ReliaStats sets up each mode's runs for you (see competing risks). #### Censored runs Some runs end before a mode has had its chance to occur, or are still going when the record ends. Reliability texts call these censored observations, or suspensions. How they are handled changes the fitted parameters, most of all for a rare mode. ReliaStats handles them for you. ### Goodness of fit: is Weibull the right model? A fitting routine returns parameters even for a distribution that describes the data badly. ReliaStats® fits all eight distribution types ReliaSim supports (Weibull, LogNormal, Normal, Exponential, Uniform, Triangular, Johnson SU and Fixed), tests each with Kolmogorov-Smirnov and Anderson-Darling, and ranks them. - Kolmogorov-Smirnov (K-S) measures the largest vertical gap between the empirical and fitted CDFs, and is most sensitive in the middle of the distribution. - Anderson-Darling (A-D) weights the tails more heavily. In downtime work the tails often matter most: chronic re-stops and repairs that outlast a buffer. Read the results as a ranking, not a verdict. With thousands of stops a formal test can reject every candidate over differences too small to matter; with a few dozen it may reject none. Two checks help: - Plot it. On a Weibull probability plot, ln(−ln(1 − F)) against ln t, a two-parameter Weibull sample falls on a straight line with slope κ. A bend or dogleg suggests mixed modes, a location offset or another distribution. Plotting positions usually come from Bernard's median-rank approximation, (i − 0.3) / (n + 0.4), which the Interrupt Explorer also uses for its survival curves. - Check the numbers the line cares about. The fitted mean should land near the sample mean. Compare the share of very short runs, and the share of stops longer than the downstream buffer covers. ### From fitted distributions to a line simulation In the ReliaStats workflow a fit's larger job is to parameterize a model. Each failure mode becomes an interrupt with uptime and downtime distributions and a maximum downtime, exported as a CSV that ReliaSim imports. ReliaSim draws individual runs and repairs from them, and blocking and starving emerge from how the stops interact with rates and buffers. The distributions are the inputs; MTBF and MTTR are outputs of the run, summaries you check against history (see MTBF vs MTTR: outputs, not inputs). Two fits with the same mean give the same availability but different numbers of early re-stops and long stops. The model is then validated interrupt by interrupt against history, and a close match to measured OEE depends on correctly fitted TTF and TTR distributions for each failure mode (case study). A validated model can then rank failure modes by production recovered; see the downtime Pareto guide. ### Run Weibull analysis on your own stop data - Interrupt Designer (free): set a Weibull TTF, change κ, and watch the curves, percentiles and availability move. - Interrupt Explorer: survival curves R(t) by cause from an .xlsx or .csv stop log, plus the reliability-window share. - ReliaStats desktop app: import event logs, identify cause groups, fit and rank all eight types and export for ReliaSim, as part of a ReliaStats subscription. For the product, see Weibull & TTF/TTR Distribution Fitting. For the whole path from stop log to validated model, see downtime data analysis. ### Frequently asked questions #### What is Weibull analysis used for in manufacturing? Fitting Weibull distributions to failure data to learn whether a failure mode is early-life, random or wear-out, to plan maintenance, and to supply time-to-failure inputs to line models. On a production line the data is the runs between stops for each failure mode. #### What does a Weibull shape parameter below 1 mean? The failure rate falls with running time, so a stop is most likely soon after a restart. On a line that often points to restart or setup problems, but it can also signal pooled failure modes or duplicate stop records. #### What is the difference between the Weibull scale parameter and MTBF? Scale λ is the running time by which 63.2% of runs have ended, whatever the shape. MTBF is the mean, λ · Γ(1 + 1/κ). They are equal only when κ = 1. #### Can I fit one Weibull to all of a machine's downtime data? You can, but it usually misleads. Competing failure modes add up to a hazard no single Weibull can follow, so the pooled shape can look close to random when no mode is. Fit each cause group separately. #### How do I know whether a Weibull fits my data? Rank it against other distributions with goodness-of-fit statistics such as Kolmogorov-Smirnov and Anderson-Darling, look for a straight line on a Weibull probability plot, and compare the share of very short runs and very long stops. #### Are the numbers in this guide from real plant data? No. The tables are illustrative arithmetic computed from the Weibull distribution. None of them is a fit to plant data or a simulation result. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See what κ does before you fit it Explore Weibull and seven other distribution types in the free ReliaStats® Designer. It opens in the Sandbox, with no account and no data upload. Launch the Designer → Or book a live walkthrough of ReliaStats. --- # MTBF vs MTTR: Outputs, Not Inputs Source: https://reliasim.com/guides/mtbf-mttr-distributions.html ## MTBF and MTTR Are Outputs, Not Inputs Model the TTF and TTR Distributions Reliability guide ## MTBF and MTTR Are Outputs, Not Inputs Model the TTF and TTR Distributions MTBF and MTTR summarize what happened, on the line or in a model run. They are the right numbers for a report and the wrong ones to feed a model. A model of a machine or a line needs the time-to-failure and time-to-repair distributions for each failure mode as its inputs. MTBF, MTTR, availability and OEE then come out of the run, where you can check them against history. Published 13 September 2026 · ChiAha ### MTBF and MTTR summarize; they don't generate For one interrupt on one machine, the event data gives you two samples. The uptimes are the runs before each stop, or time to failure (TTF). The downtimes are the lengths of each stop, or time to repair (TTR). MTBF is the mean of the first sample, MTTR is the mean of the second, and availability follows: Availability = MTBF / (MTBF + MTTR) A machine with an MTBF of 60 minutes and an MTTR of 5 is available 60/65 of the time, about 92.3%. That number is correct and useful, and it is an output: a summary of runs and stops that already happened. It is the same for every pair of distributions with those two means, whatever their shape. A model doesn't run on summaries. Each run draws individual uptimes and downtimes, and the line responds to each draw, so the model needs the distributions the draws come from. Fourteen cycles, sampled from a Weibull(30, 1) uptime. The mean of those runs is 31 minutes — and almost none of the runs is anywhere near 31. Eight are under 20 minutes, one is 163. That single number is what “MTBF” keeps and what it throws away. This is the part a one-cycle diagram cannot show. An MTBF is a mean taken over many samples, so by construction it survives the spread being anything at all — and the spread is what a line responds to. A machine that stops predictably every 31 minutes and one that mostly runs 10 minutes but occasionally runs three hours report the same MTBF and do entirely different things to a buffer downstream. ### Same MTBF and MTTR, different line Illustrative arithmetic, not a simulation result Take two machines, each with an MTBF of 60 minutes and an MTTR of 5 minutes, feeding a buffer that holds 10 minutes of downstream consumption. To keep the arithmetic simple, assume the buffer is full whenever a stop begins. - Machine A: every stop lasts exactly 5 minutes. - Machine B: nine stops in ten last 1 minute and the tenth lasts 41 minutes. The mean is (9 × 1 + 41) / 10 = 5 minutes. Illustrative. Solid bars are stop time the buffer covers; the hatched section is stop time that outlasts it. Machine AMachine B MTBF60 min60 min MTTR5 min5 min Availability92.3%92.3% Stops longer than the 10-min buffer0 in 101 in 10 Downstream time starved, per 10 stops0 min31 min Illustrative arithmetic under the full-buffer assumption above. Feed a model MTBF = 60 and MTTR = 5 and it cannot tell A from B. The downstream machine can. None of A's stops reaches it, while B's long stop starves it for 31 minutes in every ten stops. A buffer covers stops up to its size and very little beyond, as ReliaSim®'s guide How big should a buffer be? explains. The simplifications cut both ways. A real buffer is not always full when a stop begins, and upstream starvation, blocking and the other machines' interrupts all interact. Working that out for a real line is what simulation is for. The arithmetic only shows that the averages can't settle it. ### An exponential built from the mean is still an assumption When all you have is MTBF and MTTR, the usual way to turn them into model inputs is the exponential distribution, whose only parameter is its mean. That doesn't recover the missing shape; it imposes one. The exponential is memoryless, which describes the random-failure stretch of the bathtub curve, and it commits you to two things: - Its standard deviation equals its mean. Choosing exponential still chooses a spread. - The tail is fixed by the mean. For any exponential repair time, about 13.5% of stops last more than twice the MTTR (e−2) and about 1.8% more than four times (e−4). Exponential is the right model when a failure mode really is random. The data can tell you whether it is. ### Weibull uptime: same MTBF, different clustering The Weibull distribution adds a shape parameter κ (often written β) to the scale λ. κ < 1 is a falling failure rate, κ = 1 is constant and identical to exponential, and κ > 1 is a rising rate, or wear-out (see the bathtub curve). Hold MTBF at 60 minutes and change only the shape: Shape κScale λMedian uptimeRuns ending ≤ 2 minRuns ending ≤ 10 min 0.530.0 min14.4 min22.8%43.9% 1 (exponential)60.0 min41.6 min3.3%15.4% 267.7 min56.4 min0.1%2.2% Illustrative values computed from the Weibull distribution with a mean of 60 min: λ = 60 / Γ(1 + 1/κ) and P(T ≤ t) = 1 − exp(−(t/λ)κ). Not fitted to any data. At κ = 0.5, more than one run in five ends within two minutes of a restart, the chronic re-stop pattern the Interrupt Explorer's reliability window is designed to expose. At κ = 2 almost nothing fails that soon. All three rows report the same MTBF. For more on reading the shape, see Weibull analysis of downtime data. ### LogNormal downtime: the heavy right tail Repair times are often right-skewed: most stops are quick resets and a few are real repairs. LogNormal captures that shape, and ReliaStats parameterizes it the way ReliaSim stores it, as a real-space mean and standard deviation. Two repair-time distributions with the same 5-minute MTTR: Exponential, mean 5LogNormal, mean 5, std dev 10 Median stop3.5 min2.2 min Stops over 10 min13.5%11.9% Stops over 20 min1.8%4.2% Stops over 40 min0.03%1.2% Illustrative values computed from the distributions. Not fitted to any data. Beyond 40 minutes the LogNormal machine has roughly 1 stop in 90, against about 1 in 3,000 for the exponential. If the downstream buffer covers 20 minutes, those long stops are the ones that reach the rest of the line. An input that gets the MTTR right and the tail wrong is wrong about exactly the stops that matter. ### Per failure mode, not per machine A machine's MTBF usually spans several failure modes, and pooling them hides shape in two ways. The pooled distribution is a mixture. Put quick resets and long mechanical repairs in one downtime sample and you get a shape neither mode has, so any single distribution fitted to it is a compromise. Fit TTF and TTR for each cause group separately. That is the purpose of the automatic cause-group identification in ReliaStats. The modes compete. Each run ends at the first failure of any mode, so one mode's stops cut short the runs of every other. Measured the usual way, every TTF comes out too long, survival curves flatten toward 100% and per-cause MTBF looks better than the line really is. ReliaStats and the Interrupt Explorer set up each mode's runs correctly for you. ### On a line, observed MTBF is shaped by the line There is a second reason MTBF belongs on the output side. When failures accrue on operating time, a machine that is starved or blocked isn't running, so it isn't failing either. How often it actually stops depends on the machines around it and the buffers between them. Illustrative arithmetic, not a simulation result Ignoring repair time for simplicity: a machine fails on average once per 60 minutes of running. In an 8-hour shift it spends a quarter of the time starved, so it runs 360 minutes and averages 6 failures instead of 8, and its stops arrive about every 80 minutes on the clock. Change the upstream machine or the buffer and that number moves, although the machine itself hasn't changed. So a machine's MTBF measured on the line, and the line's own MTBF and availability, are results of the whole system. A simulation that takes per-mode TTF and TTR distributions as inputs produces them, including the blocking and starving that shaped them. Feeding an MTBF measured on the line back in as an input can count those interactions twice. ### The workflow: distributions in, MTBF and OEE out - Line event data historian or stop log One row per stop: where, why, and when it started and ended. - TTF and TTR per failure mode Interrupt Explorer · ReliaStats Separate cause groups and measure each mode's runs correctly. - Fitted distributions ReliaStats® desktop app Fit the eight ReliaSim distribution types, rank them with Kolmogorov-Smirnov and Anderson-Darling, and export for ReliaSim. - Model ReliaSim Each machine carries its own interrupt signature; blocking and starving emerge from rates, buffers and stops. - Results checked against history Interrupt Validation MTBF, MTTR, availability and OEE come out of the run and are compared with the historian, interrupt by interrupt. The food-plant model from Fischel and Lange's WSC 2020 paper was rebuilt in ReliaSim and independently validated by Tom Lange to within 1% of both the plant's measured OEE and the original published model (case study). ReliaSim's methodology validates each interrupt individually, because a model can match the overall total while getting individual failure modes wrong. ### What MTBF and MTTR are still good for Keep them. They are the right KPIs for a report, they give availability directly, and they are a good sanity check: a fitted distribution's mean should land near the sample mean, and a validated model's MTBF and MTTR should land near history. What they can't do is stand in for the distributions as inputs. Distributions are what make OEE simulation predictive rather than descriptive. They are also the part a reliability block diagram can't carry through a buffer. To model the line, see ReliaSim's production line simulation software or ChiAha's manufacturing simulation consulting. For how the averages relate to uptime, see availability vs reliability. ### Check the shape in your own data - Interrupt Explorer: survival curves R(t) by cause, plus the share of runs that end inside the reliability window. - Interrupt Designer (free): set a TTF + TTR pair and see p5, Q1, median, Q3 and p95 in a box-and-whisker, the PDF, CDF and survival curves, and a working/failed timeline over a shift that you can switch between mean, median, Q1, Q3 and p95 scenarios. - ReliaStats desktop app: fit all eight ReliaSim distribution types per cause group, rank them with Kolmogorov-Smirnov and Anderson-Darling, and export for ReliaSim. For the full process, from event log to validated model, see downtime data analysis for production lines. ### Frequently asked questions #### Can I use MTBF and MTTR as simulation inputs? Only by assuming a distribution shape, usually exponential, that the averages themselves don't justify. Two machines with the same MTBF and MTTR can affect a line very differently, so a model should take TTF and TTR distributions fitted per failure mode as inputs, and report MTBF and MTTR as results. #### What's the difference between TTF and MTBF? TTF (time to failure) is each individual run before a stop, and its distribution describes how those runs vary. MTBF is the mean of that distribution, one summary number. A model samples TTF; a report shows MTBF. The same holds for TTR and MTTR. #### Why does a machine's MTBF change when the line changes? When failures accrue on operating time, a machine that is starved or blocked is not running and so is not failing. Its stops per clock hour, and any MTBF measured between stops on the clock, depend on its neighbors and buffers. Line-level MTBF and availability are results of the line, not properties you can feed into it. #### When is the exponential distribution a reasonable assumption? When a failure mode is random, with a failure rate that does not change with running time. That is the flat part of the bathtub curve, and a Weibull with shape κ = 1. If a Weibull fit comes back well away from κ = 1, the exponential assumption does not hold for that mode. #### Which distribution is best for repair times? It depends on the failure mode, which is why fitting and goodness-of-fit testing matter. Right-skewed distributions such as LogNormal are common for repair times because most stops are quick and a few are long. ReliaStats fits all eight ReliaSim distribution types and ranks them with Kolmogorov-Smirnov and Anderson-Darling tests. #### Are MTBF and MTTR still worth tracking? Yes. They are good reporting KPIs, they give availability directly, and they are a sanity check on any fit or model run: a fitted distribution's mean should land near the sample mean, and a validated model's MTBF and MTTR should land near history. #### Are the numbers in this guide from real plant data? No. Every number in this guide is illustrative arithmetic computed from the distributions themselves to show the effect of shape. None of them is a fit to plant data or a simulation result. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### Model the distributions, report the averages Explore any distribution pair in the free ReliaStats® Designer. It opens in the Sandbox, with no account and no data upload. Launch the Designer → Or book a live walkthrough of ReliaStats. --- # Downtime Pareto: Count vs Minutes vs Lost Output Source: https://reliasim.com/guides/downtime-pareto.html ## Downtime Pareto Analysis Frequency, Duration and Lost Throughput Downtime guide ## Downtime Pareto Analysis Frequency, Duration and Lost Throughput A downtime Pareto sorts failure modes from worst to least so the biggest problem sits on the left. But "biggest" can mean the most stops, the most minutes or the most production lost. On a real line those are three different charts with three different leaders. Published 13 September 2026 · ChiAha ### Three rankings of the same stops Every downtime Pareto starts from the same stop log and a choice of what to add up. - By frequency: count the stops for each cause. This shows what interrupts the line most often. - By duration: add up the downtime minutes for each cause. This shows where the time went, and it is the chart most downtime reports lead with. - By lost throughput: measure how much production the line would recover if the cause were removed. This shows what the stops cost at the end of the line. It can't be added up from the log, because it needs a model of the line. ### Frequency vs duration on one stop log The Bottling Line demo file that loads in the ReliaStats tools holds 6,000 stops across five machines and 36 interrupt codes. Rank its interrupts by count and by minutes and you get two different charts. Computed from bottling-line-demo.csv (6,000 stops, 13,112.5 downtime minutes). Demo data, used here only to show how the two rankings differ. InterruptStops (rank)Downtime min (rank)Mean stopStops over 10 min Capper_Micro Stop1,345 (1)200.6 (17)0.15 min0 Filler_Micro Stop967 (2)1,573.0 (3)1.63 min0 Capper_Upper Plow Area865 (3)2,920.3 (1)3.38 min53 Capper_Picker Tree Assembly701 (4)816.4 (4)1.16 min7 Labeler_Misalignment326 (5)1,876.2 (2)5.76 min6 Palletizer (no mode code)102 (12)644.8 (5)6.32 min17 Ranks are out of 36 interrupt codes in the demo file. Capper_Micro Stop leads by frequency, with more than one stop in five, and comes seventeenth by minutes with 1.5% of the downtime. Capper_Upper Plow Area leads by minutes with 22.3%. Labeler_Misalignment is fifth by count and second by minutes, because its stops average 5.8 minutes against 0.15 for the Capper micro stop. #### What a frequency Pareto is good for Frequent stops cost more than their minutes suggest. Each one is a restart, with whatever startup loss and operator attention a restart takes, and on a tightly coupled line a stream of short stops keeps buffers from refilling. Frequency is also where chronic problems show up: a cause that stops the machine again within a couple of minutes of each restart. The Interrupt Explorer's Pareto ranks causes by stop rate per 24 operating hours and puts the chronic stop rate beside it. #### What a duration Pareto is good for Minutes are the natural unit for availability, and long stops are the ones that outlast accumulation and reach the rest of the line. But a total mixes two kinds of problem. In the demo file, 53 of Capper_Upper Plow Area's 865 stops ran longer than 10 minutes, against 6 of Labeler_Misalignment's 326. A buffer that covers 10 minutes treats those two causes very differently, and the totals can't show it. Looking at the distribution of stop lengths for each cause, not just the sum, is the first step past the Pareto. The MTBF vs MTTR guide shows why. ### Why the top duration bar may not be the top throughput loss For a budget, the chart that matters is the third one, what comes back if you fix it. Removing a failure mode doesn't simply hand back its downtime. - Buffers absorb some stops. Downtime on a machine feeding a well-stocked buffer can cost almost nothing, because the next machine keeps drawing on stock. - Some stops overlap with waiting. Part of the downtime happened while the machine would have been starved anyway. - Some stops cascade. A stop that starves or blocks several other machines costs more than its own minutes. - Position matters. The same minutes cost differently depending on where the machine sits relative to the constraint. Loss/gain analysis measures this directly. In a validated model of the line, disable one failure mode, re-run the whole line and measure the production recovered, then repeat for each mode. In ReliaSim®'s methodology example on a bottling line, two failure modes lose almost the same share and return very different amounts: Failure modeLossGain when removedGain ÷ loss Labeler Misalignment6.78%5.10%0.75× Filler Micro Stop6.67%7.97%1.2× Published ReliaSim results from reliasim.com/method.html. They are not computed from the demo file above. By loss, the Labeler mode is slightly ahead. By what comes back, the Filler micro stop returns more than it appeared to cost, while the Labeler mode returns about three-quarters of its loss. No ranking of downtime minutes could have told the two apart. ReliaSim's guide Which loss to fix first walks through the method, and the loss/gain analysis section of OEE improvement tradeoffs sets it beside the other levers. ### From Pareto to root cause A Pareto tells you where to look. Getting to root cause takes a few more cuts of the same data. - Drill from machine to failure mode. "Capper" is not a failure mode. In the demo file the Capper alone stops for twelve interrupt codes, and each can have a different cause, a different fix and a different statistical shape. - Deal with vague codes. The demo file has 102 stops coded only "Palletizer" and 49 coded only "Filler". The bare Palletizer code is fifth by minutes. When a generic code ranks that high, better coding is the first fix, because a real failure mode is hiding inside it. - Look at timing, not just totals. Stops that follow closely on a restart point toward setup, adjustment or incoming material rather than a part wearing out. The Explorer's reliability window and survival curves show this for each cause. - Look at shape. A distribution fitted to each mode's runs tells you whether stops are early-life, random or wear-out, and so whether time-based maintenance can help. See Weibull analysis of downtime data. - Price the fix. Before committing budget, estimate what the line gets back, not what the bar lost. That needs a validated line model. Methods such as 5 Whys or a fault tree still do the diagnosis. These steps point them at the right mode. ### Build all three rankings with ReliaStats and ReliaSim - Interrupt Explorer: load an .xlsx or .csv stop log for a Pareto by stop rate, with drill-down from place to mode, chronic stop rates and survival curves. It runs in your browser. - ReliaStats® desktop app: fit TTF and TTR distributions for each cause group and export them for ReliaSim, as part of a ReliaStats subscription. - ReliaSim: build the line, validate each interrupt against history, then rank failure modes by recovered production. See OEE simulation. For the full path from stop log to model, see downtime data analysis for production lines. For why a machine with good availability can still hurt the line, see availability vs reliability. ### Frequently asked questions #### What is a downtime Pareto chart? A bar chart of downtime causes sorted from largest to smallest, usually with a cumulative line, so the few causes behind most of the loss stand out. It can rank causes by number of stops, by downtime minutes or by lost production. #### Should a downtime Pareto use frequency or duration? Both. Frequency shows what interrupts the line most often and where chronic re-stops are. Duration shows where the time went. In the demo stop log used in this guide, the most frequent cause is seventeenth by minutes. #### Why doesn't fixing the biggest downtime bar give back all its minutes? Buffers absorbed some of the stops, some happened while the machine would have been starved anyway, and others cascaded into other machines. The production recovered can be less or more than the downtime recorded. #### How do you rank downtime by lost throughput? With a validated model of the line. Remove one failure mode, re-run, measure the production recovered and repeat for each mode. ReliaSim calls this loss/gain analysis. #### How do I find the root cause of downtime from a Pareto? Drill from machine to failure mode, clean up generic cause codes, look at timing relative to restarts and at the spread of stop lengths, then investigate the modes that return the most production when fixed. #### Where do the numbers in this guide come from? The frequency and duration figures are computed from the Bottling Line demo file that loads in the ReliaStats tools. The loss and gain figures are published ReliaSim results from reliasim.com/method.html. Nothing on the page is a new simulation result. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### Rank your stops by more than minutes Start with the free ReliaStats® Designer, then see what a validated line model says about which fix pays. Launch the Designer → Or book a live walkthrough of ReliaStats. --- # Availability vs Reliability for Machines Source: https://reliasim.com/guides/availability-vs-reliability.html ## Availability vs Reliability Same Uptime, Different Machine Reliability guide ## Availability vs Reliability Same Uptime, Different Machine Availability and reliability often get used as if they meant the same thing, but they don't. Availability is the share of time a machine is up. Reliability is the chance it runs for a given time without stopping. A machine can score well on one and badly on the other, and a production line feels the difference. Published 13 September 2026 · ChiAha ### Two definitions Reliability is a probability tied to a length of time. R(t) is the probability that a machine runs for time t without a failure. It says nothing about how long a failure takes to fix, so a machine can have almost no chance of a full shift without a stop and still be up most of that shift, as long as each stop is short. Availability is a fraction of time: the share of time the machine is able to run. In steady state it follows from the two averages. Availability = MTBF / (MTBF + MTTR) Availability blends how often a machine stops with how long each stop lasts, so on its own it cannot tell you which of the two you have. ReliabilityAvailability Question it answersWill it run for time t without stopping?What share of the time is it up? Depends onTime to failure onlyTime to failure and time to repair Expressed asA probability over a stated timeA fraction of time Typical formR(t), the survival curveMTBF / (MTBF + MTTR) Improved byFewer failuresFewer failures or faster repair For an exponential time to failure, R(t) = exp(−t / MTBF). For other distributions R(t) comes from the fitted distribution, or straight from the data as a survival curve. ### Same availability, very different reliability Illustrative arithmetic, not a simulation result Two machines are both 92.3% available. Machine A runs 60 minutes between stops on average, and each stop averages 5 minutes. Machine B runs 600 minutes between stops, and each stop averages 50 minutes. To keep the arithmetic simple, both use exponential run and repair times over an 8-hour shift. Each feeds a buffer that holds 10 minutes of downstream consumption and is full whenever a stop begins. Machine AMachine B MTBF / MTTR60 / 5 min600 / 50 min Availability92.3%92.3% Downtime per shift36.9 min36.9 min Stops per shift7.40.74 Reliability over 30 min running, R(30)60.7%95.1% Reliability over 8 h running, R(480)0.03%44.9% Stops longer than the 10-min buffer, per shift1.00.6 Stop time the buffer can't cover, per shift5.0 min30.2 min Stops per shift = 480 / (MTBF + MTTR). R(t) = exp(−t / MTBF). P(stop > 10 min) = exp(−10 / MTTR). Stop time beyond the buffer = stops per shift × MTTR × exp(−10 / MTTR), using the memoryless property of the exponential. By availability, A and B are the same machine. By reliability, B is far better: close to an even chance of a whole shift without a stop, against almost none for A. On the line the picture turns over again. Most of A's stops are short enough for the buffer to ride out, while most of B's outlast it, so B passes about six times as much stop time to the next machine. Neither number alone picks the better machine. A's frequent restarts cost operator attention and, on many lines, startup losses. B's long stops are the ones that reach the rest of the line. Which matters more depends on where the machine sits and how much accumulation surrounds it, and a real buffer is not always full when a stop begins. ### Inherent vs operational availability "Availability" also changes meaning with what you count as downtime. Reliability engineering separates several versions: - Inherent availability, Ai = MTBF / (MTBF + MTTR), where MTTR is active corrective repair time only. It describes the equipment under ideal support, with a technician and parts ready the moment it fails. - Achieved availability, Aa = MTBM / (MTBM + M), adds preventive maintenance. MTBM is the mean time between all maintenance actions, corrective and preventive, and M is the mean active maintenance time. - Operational availability, Ao = MTBM / (MTBM + MDT), where the mean downtime MDT also includes waiting: for a technician, for parts, for sign-off. It describes what the plant actually experiences. A stop log records operational downtime. A logged stop runs until the machine restarts, response and waiting included, so an MTTR computed from line event data sits closer to mean downtime than to active repair time. The gap is a finding in itself: if much of a failure mode's downtime is waiting, faster response may return more than engineering the failure out. Machine availability in an OEE report is different again. OEE Availability compares run time with planned production time, so setups and changeovers count against it along with failures. And a machine that sits idle because it is starved or blocked is not down. It is waiting on another machine, and counting that time as its downtime charges it for somebody else's stops. ### Why line output depends on both, plus buffers A reliability block diagram combines machines with series and parallel rules. Five machines in series, each 95% available, with no buffering between them, give a line availability of 0.955, about 77.4%. That is the tightly coupled extreme, where any stop stops the line and every machine's downtime adds up. Buffers move a line away from that extreme. Accumulation between two machines absorbs stops shorter than it can cover, so short, frequent stops stop reaching the line, while stops longer than the buffer still pass through. With plenty of accumulation and matched speeds, output tends toward the limit set by the least available machine rather than the product of all five. Real lines sit between the two limits. Where a line sits depends on the run and repair distributions of each failure mode, the buffer sizes, the rates and where the constraint is. A line model therefore needs full distributions for each failure mode rather than one availability per machine. For the same reason, a reliability block diagram falls short for a buffered line. ReliaSim®'s guide How big should a buffer be? works through the buffer side, and OEE simulation covers the model that ties rates, buffers and interrupts together. ### Measure both from your stop data - Interrupt Quick Start (free): pick an equipment failure pattern and get an availability figure and a stops-per-shift readout. - Interrupt Designer (free): set a TTF + TTR pair and see availability alongside the PDF, CDF and survival curves and a working/failed timeline over a shift. - Interrupt Explorer: survival curves R(t) by cause from a stop log, with competing causes handled, plus the chronic stop rate. - ReliaStats® desktop app: fit TTF and TTR distributions for each cause group and export them for ReliaSim, as part of a ReliaStats subscription. To read what a fitted uptime distribution says about reliability, see Weibull analysis of downtime data. For the averages behind availability, see MTBF vs MTTR. ### Frequently asked questions #### What is the difference between availability and reliability? Reliability is the probability that a machine runs for a stated time without failing. Availability is the share of time it is up, which depends on both how often it fails and how long repairs take. #### Can a machine have high availability and low reliability? Yes. A machine that stops about once an hour for 5 minutes is 92.3% available but has almost no chance of a full 8-hour shift without a stop. #### How do you calculate machine availability? In steady state, availability = MTBF / (MTBF + MTTR), or total uptime divided by uptime plus downtime. Counting active repair only gives inherent availability; including waiting time gives operational availability. #### What is the difference between inherent and operational availability? Inherent availability uses active repair time only and describes the equipment under ideal support. Operational availability also counts delays such as waiting for a technician or parts, and describes what the plant experiences. #### Is OEE availability the same as machine availability? Not quite. OEE Availability compares run time with planned production time, so setups and changeovers count against it as well as failures. Starved or blocked time is not the machine's own downtime. #### Does higher machine availability always mean more line output? No. Line output also depends on run and repair distributions, buffers, rates and the constraint. A machine whose stops a buffer already absorbs can become more available without the line producing more. #### Are the numbers in this guide from real plant data? No. They are illustrative arithmetic from exponential distributions, not fits to plant data or simulation results. Try it on a real bottling line: the Sandbox question What should we fix first?, or one move in Beat the Bottleneck. #### See availability and reliability side by side Set any uptime and repair distribution in the free ReliaStats® Designer. It opens in the Sandbox, with no account and no data upload. Launch the Designer → Or book a live walkthrough of ReliaStats. --- # Supply Chain Simulation Software Source: https://reliasim.com/supply-chain-simulation-software.html ## Supply Chain Simulation Software Try a network design before you commit to it ### What it does A supply chain simulation plays a network forward in time. Demand draws stock, sites reorder when their position drops, suppliers fill what they can, and shipments take as long as their lanes take. Inventory levels and stockouts aren’t typed in. They come out of the run. That makes it the tool for questions about a network that doesn’t exist yet: a new DC, a different sourcing split, another place to hold safety stock. You try the move on the model, watch how stock and shipments behave, and decide with that in hand. What supply chain simulation is covers the idea in full. ### Why a spreadsheet can’t show it A spreadsheet or a static network model works from averages: annual demand, average lead time, capacity that’s always there. Averages hide timing. A site can look fine on average and still run dry for two weeks because three replenishments landed late in a row. A simulation keeps the clock and the randomness. The order of events decides the result, which is why the same average demand can produce very different stock curves. How supply chain simulation works walks through the event logic. ### Questions you can put to it #### Where should safety stock sit? Compare holding stock at the plant, the DCs or both across a three-tier network. Safety stock demo #### How does stock move day to day? Watch orders, shipments and inventory play out across a plant and its DCs, not as a monthly average. Cookie Production demo #### What happens when demand jumps? Run a simple chain through a demand spike and see where stock runs short and how it recovers. Simple Supply Chain demo #### Where should the DCs go? Site DCs from demand, or choose which existing sites to keep. Greenfield demo · Brownfield demo #### What does a tariff change? Toggle the duty and watch sourcing move between an offshore and a reshored supplier. Tariff demo #### Make it, or co-pack it? Weigh a co-pack contract against in-house production across a range of fuel prices. Coffee co-pack demo ### Simulation and optimization on one network Optimization finds the best design on paper. Simulation checks whether that design holds up once demand and lead times vary. A redesign needs both, and the Networks tier has both kinds of demo on the same kinds of network. Supply chain network optimization explains the optimization side, and greenfield network design covers the first siting pass. ### From the production line to the network ReliaSim started on the plant floor, modeling high-speed lines where the stops drive the output. The playing field scales to the size of the decision, from one machine’s failure modes to the network of plants and DCs above it. A network plan built on a plant’s rated capacity inherits every stop that plant has, which is why the two levels belong in one conversation. Why simulation belongs in the capital plan makes the case for executives. ### How a project runs A supply chain study on your own network is scoped with you as a project. It starts from your question, builds the playing field from your sites, lanes and demand history, checks the model against what your network actually did, and then tests the moves you’re weighing. How a ReliaSim project runs lays out each step, what you bring and what you get. The desktop tool runs on your own machine, so your network data stays with you. Security and deployment has the details for IT reviewers. ### Frequently asked questions #### What is supply chain simulation software? It’s software that runs a model of your supply network through time, with demand, ordering, shipping and lead times playing out event by event. It shows how inventory and service behave under a design or policy before you put it in place. #### Can I try it without installing anything? Yes. The Networks tier of the ReliaSim Sandbox runs eleven sample network demos in your browser, covering network design, stock over time and cost shocks such as a tariff. There’s no download and no sign-up. #### Does simulation replace network optimization? No. Optimization searches for the best design under averaged assumptions. Simulation tests a design through time with variable demand and lead times. A good network redesign uses optimization to find candidates and simulation to check them. #### Where does my network data live? On your machine. ReliaSim is desktop software, models are local files, and model contents aren’t sent anywhere. The public Sandbox uses sample data only. #### How do I get a model of my own network? Talk to us. A supply chain study is scoped with you as a project, starting from the question you need answered and the data you already have. #### Open a sample network now Eleven network demos run in the Sandbox’s Networks tier, with nothing to install and no sign-up. Open the Networks Sandbox → Want to see it on your own network? Schedule a call. --- # What Is Supply Chain Simulation? Source: https://reliasim.com/guides/supply-chain-simulation.html ## What Is Supply Chain Simulation? Test the Network Design Before You Commit Supply Chain Guide ## What Is Supply Chain Simulation? Test the Network Design Before You Commit An optimizer tells you what your network should be. A supply chain simulation tells you whether that design holds up against variable demand, late suppliers and long lead times. You can try both on sample networks in the Sandbox Networks tier. ### When to use supply chain simulation Simulation earns its place when the answer depends on timing, not just totals. Reach for it when: - You have a candidate design and need to know if it holds up. An optimizer or a planning team has proposed a footprint, and you want to see it run before anyone signs a lease. - Inventory policy is the question. Order points, order quantities and where safety stock sits all play out over time, not in an annual average. Safety stock simulation covers where the formula stops. - You’re adding, moving or closing a DC. The network after the change is one nobody has run yet. - Sourcing is moving. A tariff, a reshoring decision or a co-pack contract changes which lanes carry product and how long it takes to arrive. - Demand swings. Seasonal peaks and spikes decide where stock runs short, and averages hide both. If you’re still choosing among thousands of possible designs, start with optimization instead. How supply chain simulation works covers the mechanics, and the supply chain simulation software page covers what ReliaSim® does with it. ### What simulation answers that optimization can’t Network optimization answers one kind of question. Given a fixed set of choices, which combination is best? It decides which facilities open, which supplier serves which customer and how much moves on each lane, and it returns the best decision under the model’s assumptions. Those assumptions are where the gaps are. Optimization usually works from averaged annual or monthly demand and assumes capacity is fully usable. It has no view of time. A 75% service rate might mean a steady 75%, or 100% for 270 days and 0% for 90. A discrete-event simulation can tell those apart, because it runs the network forward through time. #### Demand that isn’t an average Day-to-day demand swings, stochastic lead times and supplier reliability all go into the run. The simulation tests the design against the variation the optimizer averaged away. #### When service fails, not just how often Fill rate and lead time come out of the run shipment by shipment. A design that stocks out for a month shows up before you commit to it. #### How stock actually moves Inventory draws down and replenishes at every site over the run, so you can see whether a DC drains faster than its supplier can refill it. ### What a demand spike does to a supply chain Here’s one of those timing questions, run on the engine. The model is the Simple Supply Chain demo in the Supply Chain Builder: one customer orders Material 1 from one plant, and the plant makes it from raw material. The run covers 200 days. Demand is a steady 50 a day, then triples to 150 a day on day 70 and holds for 9 days. #### The orders go out before the spike The customer’s demand forecast looks 10 days ahead, a setting in the Supply Chain Builder. So its orders climb before demand does. The amount it has on order peaks at 1,000 on day 68, two days before the spike starts. #### The plant orders more than the customer does On the same day, the plant has 1,675 of the same product on order. Both numbers count the same product in the same units. Each step up the chain orders more than the step below it. That’s the bullwhip effect, and you can try to beat it in Beat the Bullwhip. #### The plant runs out, the customer doesn’t The plant runs out of Material 1 on day 66. Its orders filled in full, counted so far this run, fall to 88.6% by day 69. The customer’s stays at 100%. The shortage lands at the plant, one step away from where the demand changed. #### Then the extra stock sits Raw material on hand at the plant peaks at 6,220 on day 79, the day demand drops back. With nothing left to use it on, it ages. Its average age climbs to 34.7 days. Swipe sideways to see the whole chart. Loading the run… Customer demand Customer 1, on order Plant 1, on order Plant 1, orders filled in full so far Plant 1, raw material on hand The published run, demand ×3 for 9 days from day 70 (shaded). One engine run of the Simple Supply Chain demo, 200 days. Customer and plant on-order amounts share one scale, since they count the same product. The filled-in-full lane runs from 80% to 100%. Make the spike bigger and every effect grows. These are four saved runs of the same model. Only the size of the spike changes. Spike size against what it does Demand spikeNone×2×3×5 Customer on order, peak4128411,0002,502 Plant on order, peak4001,1511,6754,299 Plant orders filled in full, lowest100%93.9%88.6%62.5% Customer orders filled in full, lowest100%100%100%98.7% Raw material on hand, peak2,2004,5906,22012,220 Raw material average age, peak (days)17.225.034.772.7 With no spike, the plant’s peak on order, 400, sits below the customer’s, 412, so the whip comes from the spike. At ×5 the plant has 4,299 on order against the customer’s 2,502, and it fills only 62.5% of its orders in full at the low point. Monthly averages hide all of this. The run shows when each shortage lands, where, and what stock is left behind. ### What optimization answers that simulation can’t A simulation evaluates the design you give it. It doesn’t search the alternatives for the best one. Ask a simulator how many DCs you need and it can only tell you how the configuration you entered performs. A well-run network design project uses both. Optimize to find the candidate design, then simulate it to check that it holds up under realistic variation. Supply chain network optimization explained covers the math and the classic problem types. Which tool for which question If you’re askingUse What’s the optimal X, given these constraints?Optimization How many facilities do I need?Optimization Where should DCs go if we started over?Greenfield design What would happen if we tried X, with real variation over time?Simulation Will this policy deliver 95% service under real demand variation?Simulation How does safety stock behave over a month of stochastic demand?Simulation ### Design, optimize, simulate and prove on one model Most network tools stop at optimization. Here every step works on one model, edited in place, so there’s no import and export between tools and no second copy to drift out of date. - Design the network. Lay out suppliers, plants, DCs, customers and lanes as a graph. Start from demand with greenfield siting, or from the footprint you already have. - Optimize it. The optimizer (AMOS) solves for sourcing and footprint, covering facility location, flow paths, landed cost, capacity and site-count constraints. Tariffs and duties are a direct cost in that solve, not a separate module. - Simulate it. The simulator (Supply Chain Builder) runs the optimized design as a discrete-event simulation on the same database, with stochastic lead times, supplier reliability and stockouts. - Prove it. When the executive committee asks whether it will work, the answer comes from the same model in the same tool. Data validation, base-case calibration and scenario analysis are part of the method rather than improvised for each project. How to know your supply chain model is right covers the validation step. ### What you get from it - A design you’ve seen run. The network has been played forward through time before the money moves, not just scored on an average. - Policy you can compare. Different order points and stock locations run on the same network, so the difference between them is the policy and nothing else. - A shared picture. Inventory curves and shipments on a map are easier to argue over in a meeting than a cost total. - Your data stays yours. Models are desktop files on your own machine. ### Greenfield vs brownfield network design Greenfield design places facilities from scratch where demand clusters. Brownfield design starts from the sites you have and chooses which to keep, with some pinned open. Footprint rationalization asks the brownfield question of a larger network that grew over time. Greenfield, brownfield and footprint explains the difference and links a demo of each. Narrower questions have their own guides. Center of gravity analysis covers the siting method in plain terms, and how many distribution centers do you need? covers the count. Distribution network design covers redesigning a network you already have, and multi-echelon inventory covers setting stock across tiers. Before trusting any scenario, validate the model against history. ### What would happen if… Each of these questions runs as a demo in the Sandbox Networks tier, in your browser, with no sign-up. - …we started over and placed DCs where demand is? Greenfield Design, US - …we kept only some of our existing DCs? Brownfield Design, EU - …we cut the network down to fewer DCs? Footprint rationalization - …a tariff made the offshore supplier more expensive? Tariff: Offshore vs. Reshore - …diesel prices changed the case for a co-packer? Coffee Co-pack Design - …we held safety stock at a different tier? Safety Stock Optimization - …demand spiked on a simple supplier-to-customer chain? Simple Supply Chain - …one plant fed 12 DCs through a month of random demand? Cookie Production - …our network looked like the one on our whiteboard? Sketch your network ### Network demos in the Sandbox The Networks tier of the Sandbox runs sample models on our engines, and you watch the results in your browser. Each demo has its own page in the free supply chain simulator index, with what it shows and what to change. Each demo exercises one part of the method. For a supply chain study on your own network, talk to us. Sandbox network demos DemoExercisesWhat it shows Simple Supply ChainSimulationSupplier to plant to customer, one SKU assembled from raw material. Cookie ProductionSimulationA Nashville plant, 12 regional DCs and 36 retail customer zones, with randomized daily demand over a 30-day run. Greenfield Design, USSiting189 demand points. The engine sites 2 to 8 DCs from scratch. Brownfield Design, EUSiting142 demand points and 10 candidate DCs, with pinned and optional sites. Tariff: Offshore vs. ReshoreOptimizationOffshore through the Port of LA against a Mexico reshore. Toggle the tariff and watch sourcing flip. Coffee Co-pack DesignOptimizationWhether to sign a US co-pack contract, and at what fixed cost, across the range of diesel prices. Safety Stock OptimizationOptimizationWhere in a three-tier network to hold safety stock, and how much, at a 95% Type-1 service level. Sketch your networkStructureA blank canvas. Add nodes and draw lanes to build your own shape. A simulation run shows inventory over time at every site against its order point, and every shipment on the map. You can also replay the simulated shipments along their lanes. ### Tariff scenarios A tariff is a cost on a sourcing or lane arc, and the optimizer weighs duties as one input among many. The hard part is showing that the redesign holds up. Re-optimize under the new rates, then simulate the redesign on the same model before any capital moves. The tariff network redesign guide walks through it. ### Where the model and the data live ReliaSim is desktop software. Models are files on the modeler’s own machine, there’s no cloud service for the product to call, and model contents aren’t sent anywhere as telemetry. The public Sandbox uses sample data only. Security and deployment covers the questions IT usually asks. ### Getting started - Try the sample networks. Open the Networks tier and run the demo closest to your question. - Write down the decision. One question, such as which DCs to keep or where to hold stock, makes a better first model than “model everything.” - Gather what you already have. Sites, lanes, transit times and demand history are enough to start. - Scope it with us. A supply chain study on your own network is set up as a project. How a ReliaSim project runs shows each step. ### When a different tool fits better Network simulation is built for strategic questions, such as what the footprint should be and whether it holds up. Some questions belong elsewhere. - Running today’s network day to day. Planning and execution belong in ERP, TMS and S&OP. They run the network you have, and simulation tells you whether it’s the right network. - Modeling inside the plant. Machines, buffers and downtime on a line are production line simulation, a finer level of detail. That’s the plant side of ReliaSim. - Having someone build and run the study. ChiAha does simulation consulting. - Only siting facilities from demand data. That narrower question is covered at Greenfield Analysis. - A cloud service. Models run on your own machines and your data stays with you. Network and tariff work runs on history. ### Frequently asked questions #### What is supply chain simulation? Supply chain simulation runs a network forward through time. Orders arrive, inventory draws down and replenishes, shipments move and lead times vary. A discrete-event simulation lets service, inventory and lead time change day by day instead of collapsing into one averaged number. #### What is the difference between supply chain simulation and optimization? Optimization searches the decisions (which facilities open, which supplier serves which customer, what flows on each lane) and returns the best combination under its assumptions. Simulation runs one design, with variation, over time. Optimization finds the candidate design, and simulation checks whether it holds up. #### Do I need both simulation and optimization? For a network redesign, yes. Optimization works from averaged demand and fully usable capacity, so it can’t tell a steady 75% service rate from 100% for 270 days and 0% for 90. Optimize to find the candidate design, then simulate it on the same model. #### What is the difference between greenfield and brownfield network design? Greenfield sites facilities from scratch, starting from where demand is. Brownfield starts from the sites you have and decides which subset to keep open. In the Sandbox’s Brownfield Design, EU demo you pin the DCs that must stay open, mark others optional and set a target count, and no new locations are sited. #### Does my network data leave my machine? No. ReliaSim is desktop software. Models are files on the modeler’s machine, there’s no cloud service for the product to call, and model contents aren’t sent as telemetry. The public Sandbox runs sample data only. #### Can I try supply chain simulation without installing anything? Yes. The Networks tier of the Sandbox runs sample models in your browser, with no install. The Simple Supply Chain and Cookie Production demos show engine output, including inventory over time and a replay of simulated shipments. #### Can you model tariff scenarios? Yes. A tariff is a cost coefficient on a sourcing or lane arc. Re-optimize sourcing and footprint under the new duty rates, then simulate the redesign on the same model. The Sandbox’s Tariff: Offshore vs. Reshore demo compares sourcing offshore through the Port of LA with a Mexico reshore. #### What happens when demand spikes? Open the Simple Supply Chain demo in the Supply Chain Builder. Change the spike, run it and watch the orders, the fill rate and the stock at each step. Run the demand spike → Open Cookie Production Redesigning for new duty rates? Read the tariff network redesign guide. --- # How Supply Chain Simulation Works Source: https://reliasim.com/guides/how-supply-chain-simulation-works.html ## How Supply Chain Simulation Works A Plan, Played Out Event by Event Supply Chain ## How Supply Chain Simulation Works A Plan, Played Out Event by Event Here’s how a discrete-event supply chain simulation runs a design through time, what to read in its output and where its limits are. ### What problem does it solve? Simulation answers a different question from optimization. Optimization asks “what is the best design?” Simulation asks “what actually happens if we run this design through time?” A network optimizer hands you a design that’s optimal on average, given aggregate demand, average lead times and capacity it assumes is fully usable. Simulation takes a design and plays it out event by event: this order is placed on day 14, this shipment leaves two days later, this DC runs dry on day 61 because three replenishments landed late in a row. The value is in what averages hide. A design that shows 97% service on an optimizer’s summary line can be 100% for ten months and very bad for two. Simulation is how you find that out before your customers do. ### When to use it, and when not to Reach for simulation when: - You have a candidate design and need to know whether it holds up under realistic variance. - The question is about time: when stockouts happen, how inventory moves, how the network recovers after a demand spike. - Policy is the variable: order points, order quantities, where safety stock sits, how often you replenish. - You need to see the shape of a failure, not just its probability. Don’t reach for simulation when: - You’re still choosing among thousands of candidate designs. Simulation evaluates a design; it doesn’t search the design space. Use optimization to narrow the field first. - You want a single provably best answer. Simulation gives you an outcome, not the optimum. - You don’t have a design yet. Simulating nothing tells you nothing, so start with greenfield or facility selection. The table in network optimization explained covers the split in more detail. Optimize to find the candidate, then simulate to confirm it holds up. Reach for both when: - You need good starting points for a simulation’s inputs. Reorder points, structure and sourcing are all simulation inputs, and optimization calculations can supply them. - You want to see the efficient frontier of a system and what each near-optimal choice implies. - You want an answer that rests on fewer assumptions. Optimization needs many. Simulation describes the system, so many of the things optimization assumes away, such as competition for scarce resources over time, can be explored. ### Under the hood: discrete-event simulation The engine is event-driven, not clock-driven. It doesn’t step forward an hour at a time asking whether anything changed. It keeps a future-event list ordered by time, takes the next event, applies it, schedules whatever that event causes, and jumps the clock straight to the following event. Long quiet stretches cost nothing. The event vocabulary for a supply chain model is small: - Consume: demand draws stock at a consuming site. - Check inventory: a site compares its position against its ordering policy. - Place order: the position has fallen below the order point, so an order goes upstream. - Fill order: the supplier allocates what it can against that order. - Ship and deliver: material moves along a lane and arrives after the lane’s transit time. Inventory position, not on-hand stock, drives reordering: on-hand, plus what’s already on order, minus orders still to fill (and, optionally, minus reserves for periods when demand runs above capacity), compared against the order point. That’s what stops a site from ordering five times while the first truck is still on the road. Everything downstream, including service level, stockouts and inventory curves, is emergent. Nobody sets a fill rate. It falls out of demand timing, lane transit times, order points and what the supplier happened to have on hand when each order arrived. ### What the Sandbox shows you A run in the Sandbox Networks tier gives you an inventory small-multiples grid (click any series to move it to the detail chart), lane widths on the map weighted by volume, and a replay control that animates shipments along their lanes from creation to delivery. The raw engine output sits under every result, so any number the Sandbox shows can be checked against the records it came from. ### Known limitations of the demos Be clear about what these runs are and aren’t: - One replication, not a distribution. Each model runs once. A real study runs many replications with different seeds and reports the range. A single trajectory can be lucky. - Results are deterministic. Running the same model again returns the same numbers. That’s deliberate, because it makes the demo quotable and reproducible, but it means you can’t re-roll to see variance here. - Warm-up is included. A 30-day run starts from a seeded inventory position, and the opening days reflect that seeding rather than steady state. Judge the trend, not day one. - Fixed parameters. The public demos run the sample models as authored. Changing order points, lead times or demand patterns is desktop work. - Simulation reports; it doesn’t choose. It shows how a policy affects inventory and stockouts. Picking the policy is up to you, or to an optimizer. - The model is only as good as its inputs. Lane transit times, demand profiles and starting stock are authored assumptions. Simulation carries them through faithfully, errors included. One modeling detail you’ll see: in the four-tier chains (plant to DC to customer zone), each DC carries a small base demand of 1 unit per day per SKU that no customer orders. It’s a simple heartbeat for consumption at the DC. ### The two simulation demos Two models run against the engine on request, not from a recorded answer: - Simple Supply Chain: our original teaching model. A single-SKU chain from a Long Beach supplier through Memphis to New York, run for 200 simulated days through a demand spike. - Cookie Production: a Nashville plant feeding 12 regional DCs and 36 retail customer zones, three per DC, over 30 simulated days. For simulation against your own network, with your lanes, your demand history and your policies, parameters you control and many replications, talk to us. The desktop tool runs on your data locally, so your network never leaves your machine. Sources: discrete-event simulation methodology as taught in OR/SCM courses and commercial supply chain tools; archived enterprise supply chain training material (2013–2015). Simple Supply Chain model: our team #### Run a network through 30 days of demand Cookie Production runs in your browser, with nothing to install and no sign-up. Open Cookie Production → Or start with what supply chain simulation is for. --- # Supply Chain Optimization vs Simulation Source: https://reliasim.com/guides/supply-chain-network-optimization.html ## Supply Chain Optimization vs Simulation What It Solves, How It Works, Where It Stops Supply Chain ## Supply Chain Optimization vs Simulation What It Solves, How It Works, Where It Stops Network optimization answers one kind of question: given a fixed set of choices, what’s the best combination? Here’s the math behind it, the problem types it covers, and where a supply chain simulation has to take over. ### What problem does it solve? Optimization doesn’t answer “what would happen if I did X?” That’s simulation. Optimization searches the space of possible decisions and returns the one with the lowest cost, the highest service or the best tradeoff. In supply chain network design, the choices are typically: - Which facilities should be open? - Which supplier should serve which customer? - How much should flow on each lane? - Which transport mode (truck, rail or ocean) on each lane? - How much of each SKU should each plant make? The optimizer evaluates millions of combinations against a single mathematical objective, usually “minimize total landed cost,” subject to constraints such as capacity, demand, service level and flow conservation. It returns one answer: the provably best decision under the model’s assumptions. ### The math: mixed-integer programming A network design optimization problem is expressed as three pieces. 1. Decision variables. What the solver is allowed to choose. There are two kinds: - Continuous variables: how much to ship on a lane (x_ij units, 0 to ∞) - Binary variables: whether to open a facility (y_i ∈ {0, 1}) The “mixed integer” in mixed-integer programming (MIP) comes from having both at once. 2. Objective function. What to minimize or maximize. For network design, it’s almost always total cost: Total landed cost minimize Σ produce_cost_i · q_i (production at each site) + Σ transport_cost_ij · x_ij (flow on each lane) + Σ operate_cost_i · y_i (fixed cost of running each facility) + Σ inventory_cost_i · stock_i (carrying cost, if modeled) The total landed cost a business actually pays is the sum of these terms. 3. Constraints. What the solver must respect: - Demand: every customer’s demand must be served, Σ_i x_ij = demand_j for each customer j. - Capacity: facilities can’t exceed their throughput, Σ_j x_ij ≤ capacity_i · y_i. - Flow conservation: whatever comes in must go out, so intermediate nodes can’t create or destroy product. - Logic: a closed facility ships nothing, x_ij ≤ M · y_i (the “big-M” trick). - Service: every customer must be within distance D of its assigned site, when that’s modeled. The solver searches the decision space using branch-and-bound: try one combination, prune branches that can’t beat the current best, and repeat. With binary y_i variables the problem is NP-hard in general, but at the scale most companies actually run (tens to hundreds of facilities), commercial solvers handle it routinely. ### The classic problem types Every real network optimization is a variant of one of these. Basic cost optimization. All facilities are open and fixed. The optimizer assigns lanes (which DC serves which customer) to minimize total transport and handling cost. The result is a customer-to-DC sourcing map. These are small problems, usually a few minutes of solve time. Facility selection (the open/close problem). Add binary variables for which facilities are open, and a fixed operating cost for each open one. The optimizer chooses how many and which facilities while it assigns customers. This is the highest-value optimization most companies run, because footprint decisions are 5-to-10-year commitments. It’s a hard problem, and modern solvers still handle hundreds of candidates. Greenfield analysis is the fast first pass that often comes before it. Flow constraints. Add must-flow or must-not-flow rules between specific sources and destinations. These are used when business rules override pure cost (for example, a SKU that by regulation can only ship from one country), or to test “what if we forced this routing?” Sourcing optimization. The decision is which supplier or suppliers to use for each input. It adds time, lead-time variance, tariffs and in-transit holding cost to the decision. The Tariff demo in the Sandbox is a sourcing optimization: an Asia-Pacific supplier against a Mexico supplier across a grid of tariff rates. The tariff network redesign guide covers that case in full. Multi-period optimization. Decisions over time. The solver chooses when to open or close, when to build inventory and how to phase capacity additions. Every variable gets a time index, so the problem grows with the number of periods. Production-modeling optimization. Add a bill of materials: making finished good A consumes 2 units of raw material B. The solver routes raw materials, runs production and distributes finished goods, all in one combined MIP. The Coffee co-pack demo in the Sandbox has this shape, with 2 raw beans, 1 finished blend and 3 candidate plants. Multi-objective optimization. Some questions don’t reduce to one number: cost vs service vs carbon vs risk. Multi-objective solvers either weight them into one combined objective (min α·cost + β·service_violations) or trace the Pareto frontier, the curve of best possible tradeoffs. ### Optimization vs simulation: which to reach for If you’re asking…Use “What’s the optimal X?” (one number, given constraints)Optimization “What would happen if I tried X?” (many states over time, with variance)Simulation “How many facilities do I need?”Optimization (facility selection) “Will this policy actually deliver 95% service under real demand variance?”Simulation “Where should I site DCs in a clean-slate analysis?”Optimization (greenfield) “How does my safety stock behave over a month of random demand?”Simulation Optimization gives you the answer. Simulation tells you whether the answer survives reality. How supply chain simulation works covers the other half. ### Known limitations of optimization Optimization models have four common gaps: - Static. Optimization typically uses aggregate annual or monthly demand, averaged. Real demand has day-to-day variance the model doesn’t see. - Costs assumed continuous. Real shipping costs step (full truckload vs less-than-truckload). MIPs can model this with piecewise functions, but most don’t. - Service projections are optimistic. Optimization assumes capacity is fully usable. Real facilities have downtime, surge limits and human factors. - No time-series visibility. “75% service rate” might mean always at 75%, or 100% for 270 days and 0% for 90. Optimization can’t tell the difference. A well-run network design project uses both. It optimizes to find the candidate design, then simulates it to check that it holds up under realistic variance. ### Try it in the Sandbox The Tariff and Coffee demos in the Sandbox Networks tier are real optimization runs against precomputed scenario inputs. The solver reads a network specification and returns the optimal sourcing, flow and facility decisions. For a network model on your own data, including capacity, lane, freight and labor constraints, talk to us. Real network design runs in a desktop tool, so your data stays on your own machine. Sources: archived enterprise network-optimization training projects (2013–2015): basic cost, facility selection, flow constraints, bill of materials, production modeling and multi-objective. Standard supply chain analytics methodology as taught in commercial tools and OR/SCM courses. #### Watch sourcing flip under a tariff Toggle the duty in the Tariff demo and see the optimizer move sourcing between the two suppliers. Open the Tariff demo → Or read the supply chain simulation guide. --- # Greenfield Network Design: Siting DCs From Scratch Source: https://reliasim.com/guides/greenfield-network-design.html ## Greenfield Network Design Where Would You Put the DCs If You Started Over? Supply Chain ## Greenfield Network Design Where Would You Put the DCs If You Started Over? Greenfield analysis is the clean-slate first pass of network design. It places facilities where demand clusters, fast and in a way anyone can follow, and then hands off to the harder facility-selection work. ### What problem does it solve? Greenfield analysis answers a narrow but very common question: “If we were starting from scratch, with no existing facilities and no historical commitments, where on the map would we put N distribution centers to be closest to demand?” The output is a set of locations where facilities should go, given where customers are and how much they buy. It doesn’t consider inbound freight, fixed operating costs, capacity tiers or supplier locations. It’s deliberately simpler than full network optimization, which is what makes it a fast, defensible starting answer that you then refine. ### When to use it, and when not to Reach for greenfield when: - You’re starting a network redesign conversation with “where would we even start looking?” - You want a baseline that ignores legacy facility locations, the “throw out the current footprint and start over” exercise. - You need a quick sanity check before a full network optimization. - You’re a new entrant deciding where to put your first facilities. Don’t use greenfield when: - You need to decide which existing facilities to keep open. That’s facility selection, a different problem (a full MIP with fixed costs), and it’s what brownfield network design means. - Inbound supply matters: suppliers in specific places, port constraints, customs. - Operating costs vary a lot from site to site. Greenfield ignores them. - You have capacity, mode or labor constraints to honor. A well-run network design project usually starts with greenfield (minutes of computation and an easy story for executives), then moves to facility selection, the harder MIP that includes the existing footprint and costs, once the candidates are on the table. ### The math: center of gravity The classic greenfield algorithm is the weighted Euclidean center of gravity. For a single facility serving a set of customers, you want the point (x, y) that minimizes: Weighted distance to demand minimize Σ_j d_j · sqrt( (x - x_j)² + (y - y_j)² ) where: - (x_j, y_j) is the location of customer j (usually latitude and longitude, or projected to flat coordinates if accuracy matters) - d_j is the demand at customer j, the weight - the sum runs over all customers This is sometimes called the Weber problem (Alfred Weber, 1909). It answers “where should the warehouse go to minimize average weighted travel distance?” Center of gravity analysis walks through the method in plain terms, with a worked example. There’s no closed-form solution, but a simple iterative algorithm converges quickly. Start at the demand-weighted centroid: Starting point x₀ = Σ d_j · x_j / Σ d_j y₀ = Σ d_j · y_j / Σ d_j Then iterate: Weiszfeld update x_{n+1} = Σ (d_j · x_j / dist_nj) / Σ (d_j / dist_nj) y_{n+1} = Σ (d_j · y_j / dist_nj) / Σ (d_j / dist_nj) Here dist_nj is the distance from the current point to customer j. It converges in about 5 to 20 iterations for well-behaved demand maps. This is Weiszfeld’s algorithm, a fixed-point iteration on the gradient of the objective. ### More than one facility: location-allocation When you want N facilities rather than one, the problem splits in two: assign each customer to one facility, and place each facility at the weighted centroid of its assigned customers. The two decisions are coupled. Change the assignments and the best locations shift; move the locations and the best assignments shift. The standard algorithm alternates: - Assign. Given the current facility locations, assign each customer to its nearest facility, by straight-line distance, weighted distance or road distance if you have it. - Locate. Given the assignments, move each facility to the weighted centroid of its customers, using the single-facility math above. - Repeat until the assignments stop changing. This is the same structure as Lloyd’s algorithm for k-means clustering, the one used in machine learning to cluster data points. The only difference is demand-weighted centroids, so a high-volume customer pulls the facility toward it. The algorithm is greedy and can get stuck in a local optimum. Practical implementations run several random starts and keep the best result. ### Service constraints: share served within a distance In practice, the question isn’t just “minimize average weighted distance.” It’s “how many facilities do I need so that 95% of demand is within 500 miles of some facility?” That adds a coverage constraint on top of location-allocation: - For each customer j, served_j(D) = 1 if customer j is within distance D of any facility, else 0. - Then require either Σ d_j · served_j(D) / Σ d_j ≥ p (share of demand served within D), or Σ served_j(D) / J ≥ p (share of customers served within D). The two give different answers when demand is uneven. Share of demand favors big customers, so a 500,000-unit customer outweighs a 5,000-unit one. Share of customers counts every site equally. Real network design conversations usually need both. With service constraints, the question becomes “what’s the smallest N that meets the constraint?” The solver tries N = 1 and checks service, tries N = 2, and stops at the smallest N that passes. ### Why results snap to the nearest city The algorithm minimizes weighted distance to a precise latitude and longitude, but that mathematical optimum can land in a cornfield, a lake or a restricted industrial zone. The Sandbox’s greenfield engine always snaps each result to the nearest city instead of reporting the raw centroid. There are three reasons: - It’s actionable. A real-estate team can search against “Atlanta, GA.” It can’t search against “33.7490, -84.3880.” - It’s honest about precision. The inputs (demand totals and distance approximations) carry their own uncertainty, so six decimal places would overstate how precise the answer is. - It matches how executives talk about the decision. Network design conversations happen at the city level. The tradeoff is that the nearest-city result sits a few miles from the unconstrained optimum. For strategic planning, which is what greenfield is for, that’s noise. If you need the exact centroid, for example to compare against a candidate site you’re already evaluating, the underlying algorithm has it, though the public demo doesn’t show it. ### Limitations Greenfield is fast and easy to explain, but it assumes a lot: - No inbound view. A site that’s best for customer service might be poor for supplier proximity. Real design tradeoffs need facility selection. - No cost detail. Greenfield uses distance as a stand-in for cost. Real freight cost has zone steps, mode breakpoints and minimum charges that distance alone doesn’t capture. - Static demand. Greenfield uses annual or average demand. Real demand has seasons, grows and shifts. Multi-period analysis belongs in network optimization. - No capacity check. Greenfield places a facility wherever the math points, without asking whether a four-million-square-foot DC will fit there. - Straight-line distance isn’t travel distance. Great-circle distance ignores roads, rivers, mountains and zone-based freight rates. For strategic analysis the approximation is usually good enough. For last-mile or terminal routing it’s wrong. Think of greenfield as a starting argument, not a final answer: “These N centroids are where customers cluster. Now let’s run facility selection to see which existing or candidate facilities best match them, while honoring everything greenfield ignores.” ### Greenfield, brownfield and footprint rationalization Network design questions come in three shapes, and they use different methods. The Sandbox has a demo of each. #### Greenfield: start from demand Greenfield ignores the current footprint and places facilities where demand clusters, using the methods above. It’s the right question for a new entrant, or for a “what if we started over?” baseline. The Greenfield · US demo sites two to eight DCs from scratch for 189 US demand points. #### Brownfield: choose which existing sites to keep Brownfield starts from the sites you have. No new locations are sited. Some DCs are pinned open because of a lease or a key customer, the rest are optional, and the engine chooses which optional sites to close to reach a target count. The Brownfield · EU demo has 142 demand points in France, Germany and Luxembourg and ten DCs. Its graph shows what your pins cost against a run where every site is optional. #### Footprint rationalization: consolidate a network that grew Footprint rationalization is brownfield on a bigger, older network. It starts from today’s footprint and asks how far you can consolidate, and which DCs go first. The Footprint rationalization demo opens on a North American network of 658 customer points and sixteen DCs. It also shows the saving from re-assigning customers to their best DC before anything closes. All three demos score demand times distance, not landed cost, so treat them as the first pass. Once fixed costs, capacity and freight rates matter, the question becomes facility-selection optimization. The count itself is covered in how many distribution centers do you need? ### Try it in the Sandbox The Greenfield Design, US demo runs on a 189-customer US sample. Step the DC count from 2 to 8 and watch the elbow in the cost-vs-DC-count curve, which is where a network design conversation usually starts. The Brownfield Design, EU demo shows the next step: pin some sites open and let the engine choose which optional sites to keep. For a greenfield analysis on your own demand data, including service-area constraints, multi-product weighting and the facility-selection work that follows, talk to us. Sources: archived enterprise greenfield-analysis project documentation and network optimization course material (2013–2015); standard site-selection methodology; the Weber location problem (Alfred Weber, 1909); Weiszfeld’s algorithm; Lloyd’s algorithm for k-means clustering. #### Site 2 to 8 DCs on a US demand map The Greenfield demo runs in your browser, with nothing to install. Open Greenfield Design → Or read how network optimization works. --- # Center of Gravity Analysis: Method, Example and Limits Source: https://reliasim.com/guides/center-of-gravity-analysis.html ## Center of Gravity Analysis Where Demand Pulls a Warehouse, and Where the Method Stops Supply Chain Guide ## Center of Gravity Analysis Where Demand Pulls a Warehouse, and Where the Method Stops Center of gravity analysis finds the spot on a map that sits closest to your demand, with each customer weighted by how much it buys. It’s the quickest defensible first answer to “where should the warehouse go?”, but it leaves out a lot. ### What the method does Picture your customers as weights on a flat map, each one as heavy as its annual volume. The center of gravity is the point where the map would balance. A big customer pulls the point toward it and a small one barely moves it. Put a single warehouse there and the total of volume times distance to customers is about as low as it can go. It answers one question well: if distance to customers were the only thing that mattered, where would one facility go? That’s a narrow question, but it’s often the right place to start a siting conversation, because anyone can follow the logic. ### How to run one - List the customers or delivery points with a latitude and longitude for each. Group small ones by ZIP or city if there are thousands. - Pick the weight. Annual units, weight shipped or shipments per year. Use whatever drives your outbound freight cost, and use the same measure for every customer. - Take the weighted average of the latitudes and of the longitudes. Each customer’s coordinate counts in proportion to its weight. - Refine it if you need to. The weighted average is close to the true minimum-distance point but not exactly on it. A few rounds of an iterative correction close the gap. The formulas are in greenfield network design. - Snap it to a real place. The math can land in a lake or a field. Move the answer to the nearest town with the roads, labor and buildings a DC needs. ### A small worked example Three customers on a simple grid, with made-up volumes to show the arithmetic: Weighted average of three customers CustomerxyVolume A00100 B100300 C010100 x = (0·100 + 10·300 + 0·100) / 500 = 6 y = (0·100 + 0·300 + 10·100) / 500 = 2 The point (6, 2) sits much nearer B than A or C, because B buys three times as much as either. Double C’s volume and the point moves up and to the left. The answer is only as good as the weights you give it. ### What it leaves out Center of gravity is a starting point. It ignores several things that decide real siting. - Inbound freight. It only looks at customers. A site close to demand but far from the plants or ports that supply it can cost more overall. - Cost differences. Freight rates, labor, land and taxes vary by location. Distance stands in for all of them. - Roads and geography. Straight-line distance ignores mountains, rivers and the highway network. - Capacity. It will put one building where the math says, however big that building would have to be. - More than one site. The single-point answer for a national network often lands somewhere no one would choose. Real networks need several DCs, and the question becomes how to split customers between them. - Time. It uses one year of volume. It says nothing about seasons, growth or what happens to stock and service when demand varies from week to week. ### More than one DC With several DCs, you assign each customer to a DC and put each DC at the center of gravity of its own customers, then repeat until the assignments stop changing. That’s the greenfield method. The Greenfield · US demo runs it on 189 US demand points for two to eight DCs. How many DCs to use is a separate decision, covered in how many distribution centers do you need? ### Run it in the Sandbox Greenfield · US lets an engine do the weighting a center of gravity does, on real demand points, one DC count at a time. ### Then simulate the answer A center of gravity tells you where demand is. It doesn’t tell you whether a network built around that point will keep customers supplied. Once you have candidate sites, put them in a network model with real demand, lead times and ordering policies and run it through a year. That run shows how stock moves at each site, which the static answer can’t. How supply chain simulation works covers what a run does, and the supply chain simulation guide covers when to use it. #### See the geography behind a siting decision DC placement shows one plant, four candidate DCs and five customer regions on a map of the US, in your browser. Open Greenfield · US → --- # How Many Distribution Centers Do You Need? Source: https://reliasim.com/guides/how-many-distribution-centers.html ## How Many Distribution Centers Do You Need? We Stepped One Network From 16 DCs Down to 1 Supply Chain Guide ## How Many Distribution Centers Do You Need? We Stepped One Network From 16 DCs Down to 1 Most networks weren’t designed. They grew, one DC at a time. We took the footprint demo in the ReliaSim® Sandbox, sixteen DCs serving North America, and asked the engine to re-plan it at every count from 16 down to 1. Here’s what the cost curve showed. ### Sixteen DCs, the way they run today The network serves 658 customer demand points across North America, with a total demand of 257,255,779. Sixteen DCs serve them, from Vancouver to Mexico City. Each customer is assigned to a DC as the network runs today. The engine scores a network by demand times distance: every customer’s demand, multiplied by how far it travels from its DC, added up. Today’s sixteen DCs score 62,946,533,361. The engine’s own table shortens that to 62,947M, and so do we from here on. Today’s sixteen DCs, saved from the engine. Each customer demand point is colored by the DC that serves it. Long lines are customers served from far away. ### The same sixteen, re-planned First, close nothing. Keep all sixteen DCs open and let the engine move each customer to its best DC. The score drops from 62,947M to 48,132M, a cut of 14,815M, with the same buildings. That’s worth checking before any closure talk starts. Part of what looks like a footprint problem can be an assignment problem. ### The cost curve, 16 DCs to 1 Next, the engine closes DCs one count at a time. At each count it picks which DCs stay open and re-assigns every customer. Swipe sideways to see the whole chart. Loading the engine results… Re-planned at each count Today’s sixteen DCs, 62,947M Demand × distance at each DC count, as the engine reports it. Lower is better. Sixteen DCs on the left, one on the right. The dashed line is the network as it runs today. Demand × distance by DC count DCs openDemand × distanceDCs openDemand × distance 16, today62,947M861,447M 16, re-planned48,132M765,841M 1548,477M672,116M 1448,959M581,530M 1350,196M495,530M 1251,458M3117,005M 1153,412M2145,038M 1055,568M1208,417M 958,218M ### Eight DCs, placed well, cost less than today’s sixteen With eight DCs open, the score is 61,447M. That’s 1,500M below today’s sixteen at 62,947M. The eight the engine keeps are Atlanta, Chicago, Dallas, Denver, Mexico City, Newark, Phoenix and Seattle. Seven DCs is where it stops beating today: 65,841M. Eight DCs open, as the engine placed them. Open DCs in green, closed DCs in red. Each customer is colored by the DC that serves it. The engine picks the set again at every count, so the best four aren’t just the best eight with four more closed. At four DCs it keeps Atlanta, Dallas, Reno and Toronto. Reno and Toronto aren’t in the best eight. At one DC it keeps Memphis. ### Past the bend, every closure costs more Near the top of the curve, a closure costs little. From 16 DCs to 15, the score goes from 48,132M to 48,477M, up 345M. Lower down, each closure costs far more: - 5 DCs to 4: 81,530M to 95,530M, up 14,000M. - 2 DCs to 1: 145,038M to 208,417M, up 63,379M. This score counts distance only. It has no rent, labor or inventory in it. Those costs fall as DCs close, so the right count sits somewhere on this curve where the savings from a closure still beat the added distance. The curve tells you what each closure costs in distance. Your finance team fills in the other side. ### What else changes when you add or close a DC More DCs shorten the trip to customers, so outbound freight falls and deliveries get faster. But each DC carries fixed costs for the lease, the staff and the systems. Inbound freight rises because full trucks from the plant get split across more destinations. Total inventory rises too, because every site needs its own buffer. #### The inventory penalty of more DCs Each DC has to cover the demand swings of its own customers. When one DC serves the whole country, a slow week in the West and a busy week in the East partly cancel out. Split the same demand across several DCs and each one faces its own swings alone, so each needs its own safety stock. A common rule of thumb, the square root law (Maister, 1976), says total safety stock grows with the square root of the number of stocking locations. Under its assumptions, going from one DC to four roughly doubles the safety stock needed for the same service. Those assumptions include demand split evenly, independent from region to region, and the same lead time and service target everywhere. Real networks break most of them, so treat the number as a warning, not an answer. #### Put the other costs on the curve - fixed cost per DC, including lease, labor and systems; - outbound freight by lane, with real rates in place of distance; - inbound freight from plants or ports to each DC; - inventory carrying cost at each site, including the safety stock each one needs; - any service rule you have to meet, such as next-day delivery to a share of customers. With those in the model, the question becomes a facility-selection optimization that weighs every cost together. Supply chain optimization vs simulation covers how that works, and greenfield, brownfield and footprint explains how the questions differ. ### Test the count before you commit An optimizer picks a count from averages. It can’t show how stock behaves when demand swings week to week, or whether a DC runs short while it waits for the plant. Before you sign leases, run the chosen network through a year of realistic demand in a simulation and watch stock at each site. How to know your supply chain model is right covers making that run trustworthy. #### How many distribution centers do we need? Open the footprint demo in the Sandbox. Mark DCs optional, step the count down and watch the cost curve and the map change. Step the count yourself → --- # Validate a Supply Chain Model: Reproduce History First Source: https://reliasim.com/guides/validate-a-supply-chain-model.html ## How to Know Your Supply Chain Model Is Right Reproduce History Before You Trust a Scenario Supply Chain Guide ## How to Know Your Supply Chain Model Is Right Reproduce History Before You Trust a Scenario A supply chain model earns trust the same way a new planner does, by getting last year right. Before you ask it what would happen if you closed a DC, make it reproduce a period you already lived through, and check it where it’s most likely to be wrong. ### Reproduce history before you run a scenario Every scenario is a change to a base case. If the base case doesn’t behave like your network, every scenario inherits the error, and the difference between two wrong answers can look perfectly reasonable. So the first run of any network model should be a period you already know: last year, or the last two quarters, with the demand, the sites, the lanes and the policies that were really in place. Then compare what the model did with what the network did. If they agree, you have a base case. If they don’t, you’ve learned something about either the model or the data, and that’s worth finding before anyone builds a decision on it. ### Freeze the inputs for the base period A fair test gives the model the same inputs the network had. Pull them for one period and don’t change them while you compare. - Demand as it was ordered, by customer or region, by product and by day or week. Use actual orders, not the forecast. - Sites and lanes as they operated in that period, including any DC that opened or closed partway through. - Policies as they were run, meaning order points, order quantities and review periods, not the ones in the planning manual. - Transit and production times as distributions from your shipment and production records, not single averages. - Starting stock at every site on the first day, so the model doesn’t spend its first weeks filling up. ### What to compare Compare the things the network records and the model reports, at the level where mistakes hide. #### Flows by lane Units shipped on each lane, by week or month. A model can match total volume while sending it down the wrong lanes. That usually means a sourcing rule or an assignment is wrong, and it shows up lane by lane long before it shows up in a total. #### Stock by site over time Inventory at each site through the period, not just the average. The shape matters. Look for the same reorder rhythm, the same peaks before a season and the same lows. A site that holds the right average stock with the wrong rhythm is being replenished by the wrong logic. #### Lead times Order-to-delivery time by lane or region, as a distribution. Compare the middle of the range and the long tail. The tail is where late suppliers and congested DCs show up, and it’s the part an average hides. #### Production by plant Output by plant and product, week by week. If plants make the right totals at the wrong times, the network downstream sees a different pattern of supply than it really had. ### Compare the parts, not only the total A model can match the total for the wrong reasons, with one lane overstated and another understated. Checking each lane, site and product separately rules that out. It’s the same rule the ReliaSim® Method applies inside a plant, where each failure mode is checked against the historian on its own rather than trusting the line total. The published OEE validation shows what that looks like on a real plant. Agree in advance on how close is close enough for each measure, and write it down before the first comparison. A tolerance chosen after you’ve seen the results tends to be exactly as wide as the gap. ### Hold out a period If you adjust a model until it matches last year, it will match last year. That shows you can tune it, not that it’s right. So split the history. Build and adjust the model on one period, then run it on a later period you didn’t touch and compare again. The held-out period should include something the first one didn’t, such as a peak season, a promotion or a new customer. When a model tracks a period it has never seen, you can start asking it about the future. ### Start the run where the network was A model that starts empty spends its first weeks filling up, and during that time it moves product faster than the real network ever did. For a long study you can discard that warm-up. For a short horizon you can’t, because the warm-up is most of the run. The fix is to start the model from where stock and shipments really were on day one. The vehicle network case study describes a vehicle network model started from the tracked position of every vehicle, and what that did to the first weeks of its forecasts. ### When the model doesn’t match Most gaps come from the data rather than the model logic. Check these before changing anything else. - Units. Cases in one table and eaches in another is the most common error there is. - Missing lanes. Emergency shipments and transfers between DCs often live outside the main shipment table. - Policies on paper. Planners override order points. The model has to run what they did, not what the system says. - Averaged times. A single transit time makes every shipment arrive on schedule, so the model never sees the late ones. Resist tuning a parameter just to close a gap. If you can’t explain why a number changed, you’ve hidden the problem rather than fixed it. ### After the base case holds Once the model reproduces history and the holdout, save that version as the base case. Every scenario is then a change to it, one change at a time where you can, so the difference between runs comes from the change and nothing else. What is supply chain simulation? covers the scenarios that come next. #### See what a simulation run reports The Simple supply chain demo runs the engine when you open it, and shows stock at each site against its order point through a demand spike. Open the demo → --- # Tariff Network Redesign: Optimize, Then Simulate Source: https://reliasim.com/guides/tariff-network-redesign.html ## Tariff Network Redesign Prove the New Footprint Before You Move a Plant Supply Chain Guide ## Tariff Network Redesign Prove the New Footprint Before You Move a Plant Tariff changes are forcing sourcing and footprint decisions that have to be made now and still make sense if the policy reverses in 18 months. The approach here is to re-optimize the network under the new duty rates, then simulate the redesign on the same model to see whether it holds up. ### A tariff is one more cost in the network model A tariff is a cost coefficient on a sourcing or lane arc, and a network optimizer already weighs duties as one input among many. The hard part is showing that the redesign holds up once demand, lead times and suppliers vary. ERP, TMS and S&OP can tell you what the current network does under the new costs. None of them redesign it. ReliaSim® redesigns the network and then tests the redesign by simulation on the same model, before any capital moves. ### Three steps on one model #### 1. Re-optimize the footprint under the new duty rates Sourcing optimization minimizes total landed cost, and tariffs and duties are a direct part of that cost rather than a separate module. Cross-border flows, duty-relief schemes and indirect-tax effects are in scope, using established enterprise sourcing-optimization methods. #### 2. Simulate the redesign on the same model The optimized footprint runs as a discrete-event simulation on one shared database, with stochastic lead times, variability and supplier reliability. The model the optimizer designed is the model the simulator tests, so there’s no export step and no second copy to drift. #### 3. Defend it with numbers When the executive committee asks whether the new footprint will work, the answer comes from the same model, in the same tool, that produced the recommendation. ### Why this approach suits a tariff decision #### Sourcing data stays on your machine Contract terms, unit costs and supplier strategy are some of the most sensitive data a company owns. The desktop product keeps them where they already live, and the Sandbox demo uses sample data only. Security and deployment has the details. #### Built for small teams Cuts to operations research and data science groups leave fewer people to drive a developer platform. The method is built into the tool, so a single modeler works with the discipline of a senior consultant. #### Built to outlast a policy cycle Tariff regimes change. A validated network model, and the habit of testing a redesign before acting on it, stay useful long after this regime settles. ### Set up a tariff scenario A tariff scenario is only as good as the rates and the lanes it uses. A few choices make most of the difference. #### Use the rates that apply to your goods Duty depends on the product’s classification and its country of origin, not on the supplier’s address. Pull the rate for each item and origin from the tariff schedule, and note any exclusion or trade-agreement treatment that applies. One blended rate for everything hides the items that decide the answer. #### Put the duty on the lane it applies to Model duty as a cost per unit on the sourcing lane that crosses the border. That way the optimizer sees it exactly where it’s paid, and a second source for the same item carries its own rate. #### Run the whole range, not one rate Run each rate you might face, from today’s rate through the proposals on the table and back to zero. The useful output isn’t the best network at one rate. It’s the rate at which the best network changes, and how much it costs to be on the wrong side of that line. #### Count the time as well as the cost Moving a source changes more than landed cost. A longer ocean lane means more stock in transit and slower recovery when demand jumps. A closer source can shorten both. The optimizer weighs costs, and the simulation shows what the lead-time change does to stock at each site. ### What the tariff demo shows The tariff demo puts that range on a small network. A supplier in China ships through the Port of Los Angeles to a central DC. A supplier in Mexico costs more per unit but pays no duty under current trade rules. The China tariff control offers the rates in US policy as of May 2026: 0%, 7.5%, 25%, 50% and 100%. Each is a saved run of the AMOS optimizer. At 0% and 7.5%, the optimizer buys everything from China. From 25% up, it moves all of the sourcing to Mexico. On this network the answer flips somewhere between 7.5% and 25%, and a sourcing team would want to know where. Adding rates in between, or a second product with its own duty, narrows it down. ### Run a tariff scenario in the Sandbox The Tariff: offshore or reshore demo compares sourcing offshore through the Port of LA with a Mexico reshore, which is the redesign question many teams face. Toggle the tariff and watch sourcing flip. The Coffee co-pack demo asks a related question: whether to sign a US co-pack contract, and at what fixed cost, across the range of diesel prices. For the wider case for pairing optimization with simulation, see supply chain simulation vs optimization. ### Frequently asked questions #### How do you model a tariff in a supply chain network model? As a cost coefficient on a sourcing or lane arc. The optimizer weighs duties alongside freight, production and other costs, so re-optimizing under new duty rates re-solves sourcing and footprint with the tariff as a direct part of landed cost. #### Why simulate a network after re-optimizing it? The optimizer works from averaged demand and assumes capacity is fully usable. A discrete-event simulation runs the redesigned network through time with stochastic lead times, demand variation and supplier reliability, which shows whether service holds up before capital moves. #### Does our sourcing data leave our machine? No. The desktop product keeps models as files on the modeler’s machine, with no cloud service for it to call. The public Sandbox uses sample data only. #### See optimize-then-simulate on a tariff scenario The tariff demo opens on the offshore vs. reshore question with sample data. Nothing leaves your browser. Open the tariff demo → Or read supply chain simulation vs optimization. --- # The Bullwhip Effect: Causes, How to Measure It, How to Reduce It Source: https://reliasim.com/guides/bullwhip-effect.html ## The Bullwhip Effect Why a Small Rush Becomes a Big Wave, and What to Do About It Supply Chain Guide ## The Bullwhip Effect Why a Small Rush Becomes a Big Wave, and What to Do About It The bullwhip effect is the way swings in orders grow as they move up a supply chain. Shoppers buy a little more, the store orders a lot more, and the plant and its suppliers chase a wave much bigger than the rush that started it. This guide covers the causes, how to measure it, and why the obvious fixes often make it worse, with every number taken from a simulated supply chain. ### What is the bullwhip effect? Each stage in a supply chain sees only the orders of the stage below it, not what end customers actually bought. When sales rise, each stage adds a little extra to rebuild stock and cover the time its next delivery takes, and then the stage above does the same to those inflated orders. The swing grows at every step, like a whip cracking from the handle to the tip. The effect has been studied since Jay Forrester’s industrial dynamics work in the late 1950s, and MIT’s Beer Game has made generations of students feel it first hand. The name stuck after Lee, Padmanabhan and Whang described it in 1997, using Procter & Gamble’s diapers as the example: steady sales to babies, but wildly swinging orders at the distributors and suppliers. ### A worked example: one rush, four stops Our Simple supply chain model, with a distribution center (DC) added between the plant and the store, has four stops: a supplier, a plant, a DC and a big-box store. The store sells 50 units a day. Each truck takes about four and a half days. Each stop forecasts its demand and orders when its stock drops below its order point. Then, from day 70, the store sells three times as much for nine days. ReliaSim runs the chain for 200 days. Units on order at the store (blue), the DC (violet) and the plant (amber) for the same product, from the 200-day run. The store’s orders peak at 1,000 units, the DC’s at 1,900 and the plant’s at 2,515. The rush at the shelf is 900 extra units over nine days. The store’s open orders peak at 1,000. The DC, reacting to the store’s orders rather than to the shelf, has 1,900 on order at its peak, and the plant, reacting to the DC, has 2,515: two and a half times the store’s peak, for the same product. That growth is the bullwhip. ### What causes it Lee and his colleagues named four causes, and they still hold: - Forecasting from orders, not sales. Each stage reads a jump in orders as a jump in demand, and adds its own safety margin on top. - Order batching. Ordering in big lots, or only once a week, turns smooth demand into lumpy orders. - Price swings. Promotions and deals pull orders forward, then leave a hole. - Shortage gaming. When a supplier rations stock, customers order more than they need, then cancel when supply recovers. Long lead times make all four worse, because every stage has to cover more days of uncertainty. ### How to measure the bullwhip effect #### The bullwhip ratio The standard measure is the variance of the orders a stage places divided by the variance of end-customer demand. Bullwhip ratio at a stage Bullwhip = Var(orders placed) ÷ Var(customer demand) A ratio of 1 means the stage passes demand on unchanged; above 1, it amplifies. Measure it at each stage to see where the swing grows. In the example, the store’s orders vary 25 times as much as its sales, the DC’s 31 times and the plant’s production orders 45 times. Much of that is batching: the store sells every day but orders only every few days. #### Service: which fill rate? The bullwhip shows up as poor service, but only if you measure service the right way. Two common measures tell different stories: MeasureWhat it countsExample Order fill rateStore orders the DC could fill from stock when they arrived91.6% On-time fill rateUnits that reached the store within the 5-day lead time62.0% By its own usual measure the DC looks fine. But more than a third of what the store orders arrives late: an order bigger than the DC’s largest shipment goes out in parts, and the last part misses the promise. Retailers measure what arrives, on time and in full, so that is the number the DC’s customer sees. ### Why the obvious fixes backfire Every row below changes one setting and leaves everything else as it was. Same model, same rush, 200 days each. ChangeOn-time fillDC order fillPlant bullwhipAvg DC stock As it runs today62.0%91.6%45×447 DC holds 12 days of safety stock (was 4)62.7%97.8%22×694 Store holds 3 days of safety stock (was 2)80.3%89.7%44×460 Store holds 1 day of safety stock (was 2)46.1%88.3%42×477 Store orders up to 10 days of demand (was 6)31.0%85.3%74×538 Store forecast looks 3 days ahead (was 10)58.1%80.9%76×555 Three lessons fall out of those runs: - Stock in the wrong place buys the wrong number. Twelve days of DC safety stock calms the DC’s own orders (its bullwhip ratio falls from 31× to 13×) and lifts its order fill rate to 97.8%, while 55% more stock sits at the DC and on-time fill barely moves, to 62.7%. - The two service measures can disagree. One more day of store safety stock raises on-time fill to 80.3% while the DC’s order fill rate drops to 89.7%. Judged by the DC’s number, a change that helped the customer looks like a mistake. - Bigger batches feed the whip. Letting the store order up to 10 days at a time raises the plant’s bullwhip ratio from 45× to 74× and drops on-time fill to 31%. Shortening how far the store’s forecast looks ahead made things worse too, and let its shelf run empty for about three days. None of these results is a rule. Some settings help at one value and hurt at another, because what matters is when orders land relative to stock, trucks and the next review. That is exactly what a formula can’t see and a simulation can. ### How to reduce the bullwhip effect - Share real demand. Point-of-sale or consumption data lets every stage plan from what customers bought, not from the orders of the stage below. - Order smaller amounts, more often. Smaller batches and shorter review cycles turn lumpy orders back into something closer to demand. - Shorten and steady lead times. Fewer days to cover means less safety margin added at each stage. - Steady the price. Everyday pricing removes the forward-buying spikes that promotions create. - Ration on history. In a shortage, allocate on past sales, so over-ordering doesn’t pay. - Test before you change. Run each change through your worst season on a model of your own chain, and judge it by what reaches the customer on time, not by each site’s own number. ### Frequently asked questions #### What is the bullwhip effect? The bullwhip effect is the way swings in orders grow as they move up a supply chain. A small change in what shoppers buy becomes a bigger change in what the store orders, a bigger one again at the plant, and the biggest at the supplier. #### What causes the bullwhip effect? Four causes are usually named: each stage forecasting from the orders it receives rather than from real sales, ordering in large batches, price promotions that pull orders forward, and customers over-ordering when they expect a shortage. Long lead times make every one of them worse. #### How do you measure the bullwhip effect? The standard measure is the bullwhip ratio: the variance of the orders a stage places divided by the variance of end-customer demand. A ratio of 1 means no amplification. Measure it at each stage to see where the swing grows. #### How do you reduce the bullwhip effect? The usual remedies are sharing point-of-sale data up the chain, ordering smaller amounts more often, shortening lead times, steadier pricing, and allocating scarce stock on past sales rather than current orders. Which one helps most depends on your chain, so test the change before you make it. #### What is the difference between order fill rate and on-time fill rate? Order fill rate counts the orders a site could fill from stock. On-time fill rate counts the units that reached the customer within the promised lead time. A plant can fill most orders from stock and still deliver much of the product late, which is why the two can tell different stories. #### Can you beat the bullwhip? Change one setting on this supply chain, or several, and ReliaSim runs 200 days to show what reached the store on time. ReliaSim’s experiments found a single move that gets 96.2% on time. Can you find it, or beat it with a few? Play Beat the Bullwhip → Open the three-stop model --- # Safety Stock Simulation vs the Safety Stock Formula Source: https://reliasim.com/guides/safety-stock-simulation.html ## Safety Stock Simulation When the Formula Is Enough, and When to Run It Over Time Supply Chain Guide ## Safety Stock Simulation When the Formula Is Enough, and When to Run It Over Time The safety stock formula is a good first answer for one item at one site. It gets less reliable as lead times vary, demand gets lumpy and stock sits at more than one tier. Simulation takes over where the formula’s assumptions stop holding. ### The formula and what it assumes The textbook formula sets safety stock from demand variation over the lead time: Safety stock, constant lead time SS = z · σd · √L Here z comes from the service level you want, σd is the standard deviation of daily demand, and L is the lead time in days. A version with variable lead time adds a second term for lead-time spread. Both rest on the same assumptions: - demand is roughly normal and independent from one day to the next; - the lead time is known, or varies in a simple, stable way; - the site reorders continuously, the moment stock crosses its order point; - the site stands alone, with a supplier that always has stock. For a steady item at a single site those are fair, and the formula is quick and good enough. ### Where the formula breaks down #### Lumpy or seasonal demand A few large orders, a promotion or a season don’t look like a normal curve. The formula sizes stock for an average week and misses the week that matters. #### Review periods and order sizes Most sites review stock weekly or on a schedule, and order in cases, pallets or full trucks. Stock can fall well below the order point before anyone looks, and a big order quantity changes how often the site is exposed at all. #### More than one tier A regional DC’s lead time depends on whether the central DC has stock when it orders. If the central DC runs short, every DC below it waits longer. The formula treats each site on its own and can’t see that chain. ### Plant, central DC or regional DC? The biggest safety stock decision in a network is often where to hold it, not how much. Holding it upstream, at the plant or a central DC, pools variation. A slow week in one region and a busy week in another partly cancel out, so one pooled buffer can be smaller than the sum of several. Holding it downstream puts stock next to customers and cuts the time to recover from a surprise, but each site has to cover its own swings. Multi-echelon optimization weighs those against each other across the whole network. The Safety stock demo shows saved output from one such optimizer on a three-tier US network: a plant, a central DC and three regional DCs, with three products. In that network the optimizer holds all of the safety stock at the regional DCs and none at the plant or the central DC. The highest-value product takes the largest share of the budget. A different network, with different lead times and costs, can come out the other way. ### Where to pack, and where to hold stock Where stock sits also depends on what form it’s in. The postponement case study is a consumer goods network that asked whether to pack at the plant or at the DCs, and where cycle stock should sit. Packing downstream helped some product categories and not others, and the model separated them product by product. ### Test the policy over time An optimizer or a formula gives you a number. A simulation shows what that number does. Run the network through a year of demand with the policy in place, with real review periods, order sizes and lead-time variation, and watch stock at every site against its order point. - Does stock at each site stay above zero through the peak, or does it drain before the replenishment lands? - When the central DC runs low, how long do the DCs below it wait? - Is some of the stock never touched, which means it can come down? Run the same demand against two or three candidate policies, so the only difference between runs is the policy. The Simple supply chain demo shows what that view looks like, with stock at each location plotted against its order point through a threefold demand spike. ### A practical sequence - Start with the formula for a first estimate by item and site. - Decide where stock should sit across tiers, with a multi-echelon optimizer if the network has more than one. - Validate the model against a period of history. How to know your supply chain model is right covers how. - Simulate the policy through a year that includes your worst season, and adjust where stock drains or sits idle. #### See where an optimizer puts safety stock The Safety stock demo breaks the answer down by product and site on a three-tier US network. Open the demo → --- # Distribution Network Design: Optimize, Then Simulate Source: https://reliasim.com/guides/distribution-network-design.html ## Distribution Network Design Redesign the Network You Have, Then Watch It Run Supply Chain Guide ## Distribution Network Design Redesign the Network You Have, Then Watch It Run Distribution network design decides how many DCs you run, where they are, which customers each one serves and where the inventory sits. Most of the time you’re changing a network that already exists. An optimizer proposes the new design. A simulation shows how it behaves week to week before anyone signs a lease or moves a customer. ### The four decisions A distribution network design comes down to four linked choices: - How many DCs. More sites put stock closer to customers. Each one also adds a building, a crew and its own pile of inventory. How many distribution centers do you need? covers the count in detail. - Where they are. Which buildings, cities or candidate sites. This includes which existing DCs stay open. - Which customers each DC serves. The allocation. Two networks with the same sites can perform very differently if customers are assigned differently. - Where inventory sits. At the plant, at a central DC, at regional DCs, or split across them. This decides how much stock the network carries and how fast it can recover from a surprise. The decisions pull on each other. Close a DC and its customers move to neighbors, those neighbors need more stock, and the plant’s shipments change shape, so it pays to look at them together. ### Most projects start from a network you already have A blank-sheet study asks where you’d put DCs if you started over. That’s greenfield network design, and it’s a useful baseline. But most companies aren’t new entrants. They have leases, automation, key customers and a footprint that grew by acquisition. The real questions sound like this: - Which of our DCs could we close, and where would their customers go? - If we add one site, which customers should move to it? - Are customers assigned to the DC that serves them best, or to the one that served them first? - Should the new regional DCs carry safety stock, or pull from a central one? That’s brownfield work. You pin the sites that can’t close, mark the rest optional, and re-draw the allocation. It often turns up savings before anything closes, just by moving customers to a better DC. The Footprint rationalization demo shows that step on a network of sixteen DCs. ### Optimization proposes, simulation tests Network design uses two kinds of tools, and they do different jobs. Optimization searches the choices and returns the best combination under its assumptions: which sites open, which customers go where, how much moves on each lane. It works from averaged demand, usually annual or monthly. Supply chain optimization vs simulation covers the math and where it stops. Simulation takes one candidate design and runs it forward through time. Demand varies day to day. Sites reorder on their own schedules and in real order sizes. Shipments take as long as their lanes take. You see inventory at every site over the run, and every shipment. An average hides the weeks that matter. A DC that looks fine over a year can run dry every peak season, because its replenishment from the plant can’t keep up with the customers it just inherited. The simulation shows that; the optimizer can’t. ### A worked example Illustration only. The network and numbers below are made up and rounded to show the method. They are not output from a customer model. A company runs one plant and six DCs serving about 300 customer points. An optimizer, working on annual demand, proposes closing two DCs and moving their customers to the nearest remaining site. On paper the four-DC network ships the same volume with two fewer buildings. Illustration: what the average says vs what the run shows DCCustomers after redesignIn a year of weekly demand Atlanta+60 from two closed sitesStock drops below its order point every week of the fall peak and touches zero in three of them Dallas+20Stays above half its order point all year Chicago+10Stays above half its order point all year RenoNo changeA lot of stock is never touched The average said Atlanta could take the extra customers. The run shows it can in most weeks, but not during the peak, when its weekly reorders from the plant arrive too late. Now there are three options to compare: - raise Atlanta’s order point and order quantity; - move twenty of Atlanta’s new customers to Dallas; - keep one of the two closing DCs open through the peak. Run each against the same year of demand, so the only difference between runs is the change. In this illustration, moving customers to Dallas fixes most of the peak without adding stock, and the idle stock at Reno can come down. Whatever the answer, you saw the problem and tested the fixes before the leases ended. ### What to look for when a candidate runs - Stock against the order point at every site. Does it stay above zero through the worst season, or drain before the replenishment lands? - The upstream tier. When the plant or a central DC runs low, the DCs below it wait. Multi-echelon inventory covers how stock at one tier buffers the next. - Stock that never moves. A site that never draws down is carrying more than it needs. - Shipments on the map. Lanes that carry far more or less than expected often point to an allocation problem. Before you trust any of it, check the model against a period of history. How to know your supply chain model is right covers how. ### How to do it with ReliaSim® ReliaSim’s supply chain tools keep every step on one model, so the design the optimizer proposes is the same design the simulator tests. - Lay out the network you have. Plants, DCs, customers and lanes as a graph, drawn from your site list and demand history. - Pin what can’t change. Mark the sites that must stay open and let the engine choose among the rest, the way the Brownfield · EU demo does. - Optimize the candidates. Solve for footprint, allocation and flow. Keep the two or three best designs, not just the top one. - Simulate each candidate through a year that includes your worst season, with its inventory policy in place. Adjust where stock drains or sits idle, and run it again. Models are desktop files on your own machine. The supply chain simulation software page covers what the tools do, and the supply chain simulation guide covers when to use them. #### Choose which DCs to keep Brownfield · EU starts from ten existing DCs. Pin the ones that must stay open, step the count down and see which sites close. Open Brownfield · EU → Or see all the network demos. --- # Multi-Echelon Inventory: Optimization and Simulation Source: https://reliasim.com/guides/multi-echelon-inventory.html ## Multi-Echelon Inventory Set Stock for the Whole Network, Not One Site at a Time Supply Chain Guide ## Multi-Echelon Inventory Set Stock for the Whole Network, Not One Site at a Time When stock sits at more than one tier, the tiers depend on each other. A regional DC is only as reliable as the central DC that refills it. Multi-echelon inventory sets stock across all the tiers together, and simulation shows what those settings do over time. ### What an echelon is An echelon is one tier of stocking locations. A typical consumer goods network has three: - The plant, which holds finished goods as they come off the line; - A central or national DC, which takes full loads from the plant; - Regional DCs or stores, which serve customers and reorder from the tier above. Each tier is the supplier of the tier below it. A regional DC’s order from the central DC ships right away if the central DC has stock, and waits if it doesn’t. ### Why setting stock one site at a time over-stocks The usual way to set targets is site by site. Each planner takes their own site’s demand and lead time and sizes a buffer, often with the safety stock formula. That formula treats the site as if it stood alone, with a supplier that always has stock. Do that at every tier and the network pays for the same uncertainty more than once. The regional DC buffers against a late refill from the central DC. The central DC buffers so the regional DC never waits. The plant buffers so the central DC never waits. Each buffer is sensible on its own. Together they cover the same risk two or three times. The opposite mistake happens too. A site that looks lean on its own can be exposed, because it assumed a supplier tier that is itself running close to empty. ### How stock at one echelon buffers the next Stock held upstream pools variation. A slow week in one region and a busy week in another partly cancel out at the central DC, so one pooled buffer can be smaller than the sum of the regional ones. Stock held downstream sits next to customers and answers a surprise right away, but each site has to cover its own swings. The upstream tier also sets the effective lead time for everyone below it. If the central DC keeps enough stock to ship most orders the same day, a regional DC’s lead time is just the transit time. If the central DC often runs short, the regional DC’s real lead time includes the wait, and it needs more stock to cover it. Multi-echelon optimization weighs those against each other and picks a target at every site at once. There’s no single right answer. In the Safety stock demo, the optimizer puts all of the safety stock at the three regional DCs and none at the plant or the central DC. A network with different lead times and costs can come out the other way. Where stock sits also depends on the form it’s in, which the postponement case study settles product by product. ### A worked example Illustration only. The network and numbers below are made up and rounded to show the method. They are not output from a customer model. One plant feeds a central DC, which feeds four regional DCs. Planners set targets site by site. Each regional DC holds two weeks of its own demand as safety stock. The central DC holds two weeks of the whole network’s demand, and the plant holds one more week. Illustration: safety stock under two policies, in units SiteSite by siteWhole network Plant2,0000 Central DC4,0002,500 Regional DCs (4, each)1,000600 Total10,0004,900 The whole-network policy holds about half the safety stock. The question is whether it holds up. So run both policies through the same year of demand, including a fall peak, and watch every site. In this illustration the leaner policy holds through most of the year. In the two busiest weeks the central DC drops close to zero. Regional orders placed that week wait a few days for stock, and two regional DCs fall below their order points before the refill lands. Raising the central DC’s target by 500 units fixes it in the re-run. At 5,400 units, the total is still close to half the site-by-site figure. Neither table alone told you that. The optimizer gave a starting point, and the run showed the one week where it was thin. ### What simulation shows across the tiers A simulation plays the whole network forward. Demand draws stock at the regional DCs. They reorder from the central DC on their own review schedule and in real order sizes. The central DC ships what it has and reorders from the plant, and nothing is averaged away. - Stock at every site against its order point, over the whole run, so you can see which site drains first and when. - The knock-on from upstream. When the central DC runs low, the regional orders that wait show up in the run. - Idle stock. A site whose stock never approaches its order point is holding more than it needs. - Orders and shipments on every lane, so you can see how the policy changes what moves and when. Run two or three candidate policies against the same demand, so the only difference between runs is the policy. That’s how you compare reorder points, order quantities and review periods across tiers, not just safety stock. The Simple supply chain demo shows what that view looks like, with stock at each location plotted against its order point through a demand spike. ### A practical sequence - Map the tiers and who reorders from whom. - Get a first set of targets from a multi-echelon optimizer, not from each site’s formula on its own. - Validate the model against a period of history. How to know your supply chain model is right covers how. - Simulate the policy through your worst season and adjust the tier that drains or the one that never moves. If the number or location of DCs is also changing, settle that first. Distribution network design covers the footprint and allocation side. The supply chain simulation software page covers what ReliaSim®’s tools do, and the supply chain simulation guide covers when to use them. #### See where an optimizer puts safety stock The Safety stock demo breaks the answer down by product and site on a plant, a central DC and three regional DCs. Open the demo → Or see all the network demos. --- # Supply Chain Glossary: Network and Inventory Terms Source: https://reliasim.com/guides/glossary.html ## Supply Chain Glossary Network Design, Inventory and Simulation Terms Supply Chain Guide ## Supply Chain Glossary Network Design, Inventory and Simulation Terms Short definitions of the terms used across the supply chain guides and the Networks demos. Each one links to the guide or demo that goes into it. ### Terms A to Z #### Base case The version of a model that reproduces a known period of history. Every scenario is a change to it, so the difference between runs comes from the change. How to know your supply chain model is right → #### Brownfield network design Network design that starts from the sites you already have and chooses which to keep. Some sites are pinned open, and an engine decides which optional sites to close to reach a target count. Greenfield, brownfield and footprint → #### Center of gravity The point on a map that balances your demand, with each customer weighted by how much it buys. The quickest first answer to where a single warehouse should go. Center of gravity analysis → #### Cycle stock Inventory that exists because product is made or ordered in batches. It rises when a batch arrives and draws down until the next one. Postponement case study → #### Discrete rate simulation A simulation that models flow as rates between machines and buffers, and does work only when a rate changes. It suits high-speed and bulk-flow production lines. What is discrete rate simulation? → #### Discrete-event simulation A simulation that moves from one event to the next (an order arrives, a shipment leaves, stock crosses its order point) and updates the network at each one. How supply chain simulation works → #### Echelon A tier of a supply chain, such as plant, central DC and regional DC. Multi-echelon inventory planning decides stock at every tier together rather than one site at a time. Safety stock simulation → #### Elbow The bend in a curve of cost or distance against the number of facilities, where each added facility starts to buy much less than the one before. How many distribution centers? → #### Fill rate The share of demand met from stock on hand, without a backorder or a lost sale. It can be counted by units, by order lines or by whole orders, and the three give different numbers. Safety stock simulation → #### Footprint rationalization Consolidating a network that grew over time: starting from today’s DCs and deciding which could close and where their customers would be served from. Footprint rationalization demo → #### Greenfield network design Placing facilities from scratch where demand clusters, ignoring the current footprint. A fast first pass before cost and capacity come in. Greenfield network design → #### Holdout period A stretch of history kept out of model building and used only to test the finished model. Matching it is stronger evidence than matching the period you tuned on. How to know your supply chain model is right → #### Inventory position Stock on hand plus stock already on order, minus backorders. Reorder decisions look at inventory position, not just what’s on the shelf. How supply chain simulation works → #### Landed cost The full cost of getting a unit to where it’s sold: purchase or production cost, freight, duty and handling. Tariff network redesign → #### Lead time The time from placing an order to having the goods available. It varies from order to order, and the long tail matters more than the average. How to know your supply chain model is right → #### Network optimization Solving for the best set of facilities, sourcing and flows under a model’s costs and constraints, usually as a mixed-integer program. It works from averaged demand. Supply chain optimization vs simulation → #### Order point The inventory position at which a new replenishment order is placed. Also called the reorder point. How supply chain simulation works → #### Playing field The scope a model covers, from one machine to a whole network, where you try a change before making it. ReliaSim® uses the term instead of “digital twin” because its models aren’t live-connected. Digital twin vs simulation → #### Postponement Delaying the final form of a product, such as packing or labeling, until it’s closer to demand, so less stock is committed to the wrong item or the wrong place. Postponement case study → #### (s,S) policy A reorder rule: when inventory position falls to s or below, order enough to bring it back up to S. The order size varies with how far below s the position fell. How supply chain simulation works → #### Safety stock Stock held above expected demand over the lead time, to cover variation in demand and supply. Safety stock simulation → #### Square root law A rule of thumb that total safety stock grows with the square root of the number of stocking locations. It rests on assumptions most real networks break. How many distribution centers? → ### Where to go next Start with what supply chain simulation is, or try the free network demos to see most of these terms in action. ### Line and reliability terms Terms from the plant side, such as constraint, buffer, interrupt, MTBF and OEE, are covered in the production line guides and in MTBF vs MTTR. --- # What Is Discrete Rate Simulation? Source: https://reliasim.com/discrete-rate.html ## What Is Discrete Rate Simulation? Model Flow as Rates, Not as Individual Events Method ## What Is Discrete Rate Simulation? Model Flow as Rates, Not as Individual Events Discrete rate simulation models a line as rates of flow between machines and buffers, instead of tracking every item. The simulator only does work when a rate changes. That makes it a natural fit for high-speed lines and bulk flow, where stops, buffers and blocking decide the answer. It’s the method ReliaSim® is built on. New to Discrete Rate? (2:18). Also on YouTube and the videos page. ### The idea in one tank Fill a tank from a pipeline and drain it at a slower rate. A continuous simulation recalculates the level at every time slice, whether anything changed or not. A discrete event simulation steps once for every unit in or out. A discrete rate simulation fires an event only when a rate changes, such as the tank starting to fill, filling up or emptying. Between those events the rates hold, so the level moves in a straight line and the simulator can compute exactly when the next change will happen. It does no work in between. The Fast-Slow Drain demo in the Sandbox draws one tank three ways on the same clock. The level ends in the same place, and the event counts don’t. Scale that up to a real line and the gap grows with line speed. In the Hamburger Duo demo, a five-stage burger line runs as discrete event and discrete rate side by side, with 2,993 events against 6 for the same 300 burgers. ### Three building blocks: constraints, buffers and interrupts Every discrete rate model is built from three primitives. #### Constraints A constraint is any point that limits the rate of flow, such as a filler, a labeler, a reactor or a processing stage. Each has a maximum rate that can change over time. It runs at that rate until something changes it. An interrupt can slow it or stop it, a full buffer downstream can block it and an empty buffer upstream can starve it. Examples: a filler at 1,200 cans a minute, a labeler at 850 bottles a minute, a reactor at 12 m³ an hour, a loading bay at 22 pallets an hour. #### Buffers A buffer is an accumulator between constraints. It fills when upstream runs faster than downstream and drains when downstream runs faster. Buffers are why a line doesn’t seize the moment one station hiccups. A well-placed buffer can absorb several minutes of downstream downtime, and a poorly sized one passes a stop straight through. Examples: an accumulation table between filling and labeling, WIP between machining and assembly, a holding tank between a reactor and a distillation column. #### Interrupts An interrupt is an event that changes a constraint’s rate, such as a failure, a jam, a changeover, a quality hold or a scheduled stop. Each interrupt carries its own time-to-failure (TTF) and time-to-repair (TTR) distributions. A three-second label misread is one distribution and a four-hour belt replacement is another. Keeping them separate, instead of rolling them into one availability number, is how the model captures the knock-on effects that decide real-line throughput. #### Why three are enough The three compose. A real plant is a network: constraints connected through buffers, changed by interrupts. No other building block is needed. Any process you can describe as rates, accumulation and disturbances reduces to these three, and that is what makes the method general. The same three primitives describe the bulk manufacturing system in the 1995 paper that introduced the method, the multi-line food plant validated in 2020, a fuel pipeline or a distillation column. ### Where event-by-event simulation struggles Discrete event simulation makes each unit its own event. That’s the right choice when unit identity matters, and it gets expensive as line speed rises. A station running 1,200 units a minute fires 1,200 events a minute. The usual fix is to lump short stops into one downtime factor, which removes the blocking and starving that often decide what a fast line actually produces. Discrete rate vs discrete event simulation covers the comparison in full. ### Where discrete rate simulation fits It fits any system where material flows at a rate and interruptions disrupt that flow. - Bottling and packaging. Filling, capping and labeling lines where a three-second stop spreads to the stations downstream. - Food and dairy. Continuous flow with CIP cycles and quality windows, where buffer sizing affects product integrity as well as throughput. - Pharma and life sciences. Tightly coupled, regulated processes where each interruption has to be modeled precisely. - Chemical and continuous process. Reactors and columns where fouling lowers the rate gradually, which the model treats as an interrupt. - Utilities and pipelines. Treatment stages with backwash cycles, generating plants with partial derating, and pipelines where line pack acts as the buffer. - Beyond manufacturing. Fleets, logistics and hospital patient flow, where availability and rates change through the day. ### Validated against a real plant Fischel and Lange’s 2020 Winter Simulation Conference paper modeled a multi-line food plant in ExtendSim®. That model was rebuilt in ReliaSim and independently validated by Tom Lange, and the ReliaSim model came within 1% of both the plant’s measured OEE and the original model. The published OEE validation case study has the details. ### How the method started Andrew Siprelle created the technique in 1990, originally under the name bulk flow simulation. It entered the peer-reviewed record at the 1995 Winter Simulation Conference. The name discrete rate simulation came into use in the late 2000s, as the method was built into commercial simulation software. The history of discrete rate simulation tells the story, and the lineage traces five decades of the method, from Pritsker’s SLAM in 1979 to today. Selected publications YearVenuePaper 2020Winter Simulation ConferenceHigh Accuracy Discrete Rate and Reliability Modeling to Drive Improvement of Plant OEE and Throughput (Fischel and Lange) 2020ResearchGateMesoscopic Discrete-Rate-Based Simulation Models for Production and Logistics Planning 2016SpringerComparison of Discrete Rate Modeling and Discrete Event Simulation 2014ResearchGateA Global Approach for Discrete Rate Simulation 2009Winter Simulation ConferenceExtendSim Advanced Technology: Discrete Rate Simulation (Krahl) 1995Winter Simulation ConferenceModeling a Bulk Manufacturing System Using Extend (Siprelle and Parsons) The full published record is on the lineage page, and more of ChiAha’s research is on chiaha.com/research. ExtendSim® is a registered trademark of Andritz Inc., referenced for identification only. ### Guides on simulation methods - Discrete rate vs discrete event simulation, including which tools use which method. - Simulation methodologies, from discrete event to agent-based and system dynamics. - Monte Carlo vs discrete rate simulation, and when a spreadsheet is enough. - Digital twin vs simulation, and what a validated model is. ### Frequently asked questions #### What is discrete rate simulation? Discrete rate simulation (DRS) models flow as a rate that changes only at discrete events, instead of tracking each unit as its own event. A model is built from constraints, buffers and interrupts. Between events the rates hold, so the simulator needs no recalculation until something changes. #### How is discrete rate simulation different from discrete event simulation? Discrete event simulation makes each unit an event the simulator schedules and processes, so its work grows with throughput. Discrete rate simulation makes each rate change an event (a failure, a repair, a changeover, a buffer filling or emptying), so its work grows with the number of rate changes instead of the number of units. #### How is discrete rate simulation different from continuous simulation? Continuous simulation integrates the state forward in small time steps whether anything changed or not. Discrete rate simulation is event-driven. It recalculates only when a rate changes or a buffer reaches full or empty, and because rates hold between events no numerical integration is needed. #### What are the three primitives of discrete rate simulation? Constraints limit the rate of flow. Buffers sit between constraints and absorb rate differences by filling and draining. Interrupts are events that change a constraint’s rate, each with its own time-to-failure and time-to-repair distributions. #### What is bulk flow simulation? Bulk flow simulation was the original name for discrete rate simulation. The 1995 Winter Simulation Conference paper that introduced it is titled Modeling a Bulk Manufacturing System Using Extend. The name discrete rate simulation came into use in the late 2000s. #### Why is discrete rate simulation faster on high-speed lines? In discrete event simulation a line running 1,200 units a minute produces 1,200 events a minute at each station. In discrete rate simulation the same line runs at a constant rate between interrupts, and the simulator does no work until a buffer fills, a failure fires or a changeover starts. #### What software supports discrete rate simulation? ReliaSim is ChiAha’s discrete rate simulator for production lines. ExtendSim offers discrete rate modeling in some editions. ChiAha’s free, browser-based Decoupling Buffer Simulator uses discrete rate simulation to explore buffer design. #### Who invented discrete rate simulation? Andrew Siprelle, founder of ChiAha, created discrete rate simulation in 1990. He called it bulk flow simulation. The first paper, Modeling a Bulk Manufacturing System Using Extend (Siprelle and Parsons), appeared at the 1995 Winter Simulation Conference. The history has the full story. #### When was discrete rate simulation invented? In 1990, under the name bulk flow simulation. The first peer-reviewed paper appeared in 1995. The name discrete rate simulation came into use in the late 2000s, in Damiron and Nastasi’s 2008 and Krahl’s 2009 Winter Simulation Conference papers, as the method was built into commercial software. #### Is discrete rate simulation validated against real production lines? Yes. Fischel and Lange’s 2020 Winter Simulation Conference paper modeled a multi-line food plant. That model was rebuilt in ReliaSim and independently validated within 1% of both the plant’s measured OEE and the original model. See the published OEE validation case study. #### What industries use discrete rate simulation? Any industry with rate-based flow: high-speed filling, bottling and packaging lines in food and beverage, consumer products and pharmaceuticals; chemical and continuous-process plants; bulk material handling; and pulp and paper. Published work has also applied it to logistics and supply chain planning. See industries. #### Watch one tank run three ways The Discrete Rate tier of the Sandbox runs the Fast-Slow Drain, the Hamburger Duo and five more models in your browser, with no signup. Open the Fast-Slow Drain → Or compare the methods in discrete rate vs discrete event simulation. --- # Discrete Rate vs Discrete Event Simulation Source: https://reliasim.com/guides/discrete-rate-vs-discrete-event-simulation.html ## Discrete Rate vs Discrete Event Simulation Same Family, Different Answers on a Fast Line Simulation Methods ## Discrete Rate vs Discrete Event Simulation Same Family, Different Answers on a Fast Line Both methods are event-driven. They differ in what counts as an event, and that decides how each one copes once a line runs faster than a few units a minute. Here’s what each does well, where each breaks down and how to choose. The Hamburger Duo demo in the Sandbox runs one line both ways and counts the events. ### What counts as an event Discrete event simulation (DES) models the system as a sequence of events involving individual entities. Each unit moving through the system is an event the simulator schedules, runs and cleans up, and the clock jumps from one event to the next. Discrete rate simulation (DRS) models flow as a rate. Between rate-changing events such as failures, changeovers, blocking and starving, the rate is constant and buffer levels change linearly. The simulator does no work until something actually changes. ### Side by side AspectDiscrete eventDiscrete rate Unit of analysisEach entity is an individual eventFlow is modeled as a rate Computational costGrows with throughput. A faster line means more events and a longer runIndependent of throughput, with one event per rate change Micro-stopsOften averaged into a single downtime factorEach interrupt explicit, with its own TTF and TTR distributions Blocking and starvingApproximated through entity-level eventsComputed by flow propagation through the buffers Buffer dynamicsEntities queueing and dequeueingLevels change linearly between events, and fill and empty times are computed directly Best fitLow-volume systems, unit-level logistics, queueing networks where unit identity mattersHigh-speed lines, continuous-process manufacturing and bulk flow ### When discrete event is the right tool Discrete event simulation is the right method whenever unit identity matters. That includes queueing networks where you care about specific customers and their waits, supply chain models that track individual orders, call centers where each interaction has its own attributes, and baggage handling where each bag routes through scanners and conveyors. Discrete rate adds a method for rate-based systems where DES struggles, rather than replacing it. ### Where discrete event struggles on high-speed lines #### Computational cost grows with throughput A bottling line running 1,200 cans a minute produces 1,200 events a minute per station in a DES model, so a six-station line produces about 7,200 events a minute. A shift produces millions, and real-line micro-stops such as three-second jams, label misreads and sensor faults add more. A model that takes overnight to run makes it hard to decide anything within days. #### Knock-on effects get averaged away The standard way out is to model at a coarser scale. Short stops get rolled into one downtime parameter, or the whole line is treated as one constraint with a reduced rate. That buys speed at the cost of the dynamics. You lose how a two-minute stop at station four shows up as starving at station two a little later, and those effects often decide real-line OEE. #### Blocking and starving are approximated DES handles blocking through entity logic. An entity finishes at one station, can’t enter the next and waits in a queue. The mechanics work, but the timing of how a stop spreads is approximated. Discrete rate computes blocking and starving by propagating flow through the buffer network. ### The validation evidence The 2020 Winter Simulation Conference paper High Accuracy Discrete Rate and Reliability Modeling to Drive Improvement of Plant OEE and Throughput (Fischel and Lange) reported a discrete rate model within 1% of a real food plant’s measured OEE. See the published OEE validation case study. ### Choosing between them #### Use discrete event simulation when - Individual identity matters, such as specific orders, customers or parts. - Throughput is low enough that per-unit events are cheap to compute. - You’re modeling queueing networks, call centers, baggage handling or dispatch. - You need to track unit-level attributes through the system. #### Use discrete rate simulation when - Flow rate matters more than the identity of individual units. - Lines run hundreds or thousands of units a minute, where DES becomes impractical. - The process is continuous or bulk flow, such as chemicals, food and beverage, paper or pipelines. - Knock-on effects from micro-stops drive performance, and buffer design and decoupling are central questions. ### Which tools use which method Simulation software is usually built around one primary method, even when it offers others. The table groups widely known tools by that primary method, using each vendor’s own description of its product. Most general-purpose packages are discrete event at their core, and several add flow, fluid or agent-based features. For discrete-part manufacturing, job shops, warehousing and material handling, a discrete event tool is usually the right choice. Discrete rate earns its place on high-speed and bulk-flow lines. ToolPrimary methodHow the vendor describes it ArenaDiscrete event“Discrete-Event, Flow, and Agent Based modeling methods” FlexSimDiscrete event, with 3D visualization“3D Simulation Modeling and Analysis Software” Simul8Discrete event“Simulation Software for Process Improvement” SimioDiscrete event“Discrete Event Simulation Software (DES)” Siemens Tecnomatix Plant SimulationDiscrete event“discrete-event simulation and throughput optimization” ExtendSim®Discrete event, discrete rate and reliability block diagrams (by edition)“ExtendSim Pro for Discrete Event, Discrete Rate, & Reliability Block Diagramming” AnyLogicMultimethod: discrete event, agent-based, system dynamics“the combination of system dynamics with agent-based and discrete-event methods” ReliaSim®Discrete rate, for production lines“Manufacturing simulation software for high-speed lines” Vendor descriptions are quoted from each product’s own web pages as of September 2026. Product lines change, so check the vendor for current capabilities. ExtendSim® is a registered trademark of Andritz Inc. Arena, FlexSim, Simul8, Simio, Siemens Tecnomatix Plant Simulation and AnyLogic are trademarks of their respective owners, referenced for identification only, with no affiliation or endorsement implied. ### What it looks like in code The two methods make different choices about the simulator’s main loop. A DES simulator keeps a priority queue of events ordered by time. The main loop pops the next event, processes it (which may schedule more events) and advances the clock. Every unit transit is its own event. A DRS simulator keeps the current rate of every flow, plus a queue of predicted rate changes. When will this buffer fill? When will this interrupt fire? When does the next changeover start? The main loop pops the next predicted event, recomputes the affected rates and buffer levels directly, and predicts the next event. Between events it does nothing, because rates are constant and buffers change linearly. ### Frequently asked questions #### Which simulation software uses discrete event and which uses discrete rate? Most general-purpose simulation packages are discrete event at their core. Arena, FlexSim, Simul8, Simio and Siemens Tecnomatix Plant Simulation are all primarily discrete event tools, and some add flow, fluid or agent-based features. ExtendSim offers discrete event, discrete rate and reliability block diagramming, depending on the edition. AnyLogic is multimethod, combining discrete event, agent-based and system dynamics modeling. ReliaSim is a discrete rate simulator built for high-speed production lines. For discrete-part manufacturing, job shops and material handling, a discrete event tool is usually the right choice. #### Count the events yourself The Hamburger Duo runs one five-stage line as discrete event and discrete rate side by side, in your browser. Open the Hamburger Duo → New to the method? Start with what discrete rate simulation is. --- # History of Discrete Rate Simulation Source: https://reliasim.com/guides/discrete-rate-history.html ## The History of Discrete Rate Simulation Created by Andrew Siprelle in 1990 Simulation Methods ## The History of Discrete Rate Simulation Created by Andrew Siprelle in 1990 Discrete rate simulation began in 1990 as bulk flow simulation, a way to model fast production lines as rates instead of one unit at a time. It entered the peer-reviewed record in 1995, took its current name in the late 2000s, and has been published on and validated for three decades since. ### 1990: The three primitives In 1990 the standard method was discrete event simulation, which treats every unit moving through a system as its own event. On a slow line, a few units a minute, that works. On a real production line running hundreds or thousands of units a minute, with micro-stops rippling downstream, discrete event models slowed to a crawl and averaged away the very behavior that mattered. Andrew Siprelle took a different approach. Instead of tracking units, model flow as a rate, and describe the system with three building blocks: - Constraints limit the rate of flow. - Buffers absorb the difference between upstream and downstream rates. - Interrupts change a rate: failures, changeovers, quality stops, each with its own time-to-failure and time-to-repair distributions. Between interrupts the rates hold, so the simulator has nothing to recalculate. When something changes, the flow is recomputed directly. That one shift made fast, high-volume lines practical to simulate in detail. The three building blocks are explained in more depth on the main discrete rate page. ### 1995: The first paper The method entered the academic record at the 1995 Winter Simulation Conference with Modeling a Bulk Manufacturing System Using Extend (Siprelle and Parsons). The paper applied the three-primitive approach to a real bulk-flow production problem and argued that rate-based modeling was a general method, not a special-purpose trick. ### From bulk flow to discrete rate For most of its first two decades the method wasn’t called discrete rate simulation. Andy’s original name, and the name on every foundational paper of the 1990s, was bulk flow simulation. The 1997 follow-up was Simulation of Bulk Flow and High Speed Operations (Siprelle and Phelps). The toolkit Andy released in the late 1990s carried the name SDI Industry. The new name took hold in the late 2000s, as the technique was built into commercial simulation software. It appears in Winter Simulation Conference paper titles from Imagine That: Damiron and Nastasi’s Discrete Rate Simulation Using Linear Programming (2008) and Krahl’s ExtendSim Advanced Technology: Discrete Rate Simulation (2009). By then the bulk flow approach had become a module of ExtendSim®. Constraints, buffers and interrupts are the same method under either name. The lineage page traces each era in detail, from Pritsker’s SLAM in 1979 to today. ### Since 1995: The published record Three decades of papers have extended, compared and validated the method. A selection: Selected publications YearVenuePaper 1995Winter Simulation ConferenceModeling a Bulk Manufacturing System Using Extend. The foundational paper. 2009Winter Simulation ConferenceExtendSim Advanced Technology: Discrete Rate Simulation. The method as a commercial module. 2014ResearchGateA Global Approach for Discrete Rate Simulation. A broader formal framework. 2016SpringerComparison of Discrete Rate Modeling and Discrete Event Simulation. A head-to-head comparison. 2020Winter Simulation ConferenceHigh Accuracy Discrete Rate and Reliability Modeling to Drive Improvement of Plant OEE and Throughput (Fischel and Lange). Validation against a real food plant. 2020ResearchGateMesoscopic Discrete-Rate-Based Simulation Models for Production and Logistics Planning. Extension to logistics planning. 2023Winter Simulation ConferenceChiAha Discrete Rate Simulation. Andrew Siprelle presents the method in the vendor track, at the conference where it was first published. The full bibliography, sixteen papers from 1995 to 2020, is on the lineage page. ### What it became Discrete rate simulation now ships in commercial simulation software, has been the subject of research at the Winter Simulation Conference and in Springer proceedings for three decades, and is used in manufacturing, process industries and logistics planning. The 2020 Fischel and Lange model of a multi-line food plant was later rebuilt in ReliaSim® and independently validated within 1% of the plant’s measured OEE. The published OEE validation case study has the details. “It would take me up to a month to develop a digital twin for a production line using traditional methods. ChiAha’s discrete rate approach streamlines this process while still delivering high-quality results.” Tom Lange, Technology Optimization & Management LLC, co-author of the 2020 validation paper ### The tools today The work continues at ChiAha, where discrete rate simulation runs: - ReliaSim, simulation software for production lines, built on time-to-failure and time-to-repair data, with blocking and starving analysis and gain-versus-loss experiments. - The Sandbox Flow tier, where you can run the classic discrete rate demos in your browser. - The free Decoupling Buffer Simulator, a browser-based model of how buffers absorb upstream failures. ### About Andrew Siprelle Andrew Siprelle is the founder of ChiAha and the creator of discrete rate simulation. He has spent thirty-five years applying simulation, operations research and high-performance computing to real industrial systems. He wrote the foundational 1995 Winter Simulation Conference paper and its 1997 follow-up on bulk flow and high-speed operations. #### See the method run The Sandbox Flow tier runs the classic discrete rate demos in your browser, no install. Open the Sandbox → New to the method? Start with what discrete rate simulation is. --- # Discrete Rate Simulation Lineage, 1979 to Today Source: https://reliasim.com/guides/discrete-rate-lineage.html ## The Lineage of Discrete Rate Simulation Five Decades, from SLAM to Today Simulation Methods ## The Lineage of Discrete Rate Simulation Five Decades, from SLAM to Today Discrete rate simulation grew out of work that runs from Pritsker’s combined discrete-continuous modeling in 1979, through Andrew Siprelle’s bulk flow blocks, to the linear-programming engines of the late 2000s and the engine ReliaSim® runs today. Here is what each era contributed and what carried forward, with the sources. The eras at a glance EraYearsKey contribution 1 · Academic1979–1983SLAM’s combined discrete-continuous framework; the Valdez Tanker example with published parameters. 1.5 · Commercial1998–2010SDI Industry, a commercial bulk flow product; the three primitives; separate item-to-flow and flow-to-item blocks. 2 · Imagine That2008–2014A linear-programming rate engine; the Interchange block; the ExtendSim Rate Library. 3 · Modern2024–todayA from-scratch engine with typed building blocks; separate item-to-flow and flow-to-item kept. ### Era 1: Pritsker’s SLAM (1979–1983) #### SLAM, the language A. Alan B. Pritsker and Claude Dennis Pegden introduced the Simulation Language for Alternative Modeling (SLAM) in 1979 with the textbook Introduction to Simulation and SLAM. SLAM brought three kinds of modeling that had needed separate tools into one language: network modeling, discrete event simulation and continuous simulation. Pritsker called the combination combined discrete-continuous simulation. Earlier languages such as GPSS, SIMSCRIPT, CSL and CSMP were usually committed to one approach. SLAM let one model use whichever approach fit each part of the system. #### The Valdez Tanker example The best-known SLAM teaching example became the Valdez Tanker problem. The standard published version, Koelling and Remy (1983), describes an oil export system: continuous pipeline flow fills a storage tank, and tankers arrive one at a time to load. Oil flow is continuous; tanker arrivals are discrete events. Koelling and Remy published exact parameters: tanker capacity of 330,000 barrels, a load rate of 45,875 barrels a day, a triangular interarrival distribution. Specific numbers make a model reproducible, and that habit still anchors the work. What carried forward: the combined framework, the Valdez Tanker as the standard example of mixing discrete and continuous behavior, and publishing exact parameters with every model. ### Era 1.5: Andrew Siprelle’s bulk flow blocks (1998) #### From paper to product Andrew Siprelle created the method in 1990, originally as bulk flow simulation. His 1995 Winter Simulation Conference paper with David Parsons put it in the academic record, and the 1997 follow-up with Richard Phelps, Simulation of Bulk Flow and High Speed Operations, extended it. The history page covers those years. By 1998 Siprelle’s team shipped SDI Industry, a commercial product built around bulk flow modeling. Damiron and Nastasi’s 2008 paper cites that work as the “ground-breaking technology” their linear-programming approach built on. #### Bulk flow blocks: separate item-to-flow and flow-to-item SDI Industry introduced what are now called the three primitives: rate-limiting constraints, level-accumulating buffers and random interrupts. It added two blocks for moving between item-based and rate-based parts of a model: - Item-to-flow: items entering a rate-based region become flow, and each item’s quantity adds to a buffer’s level. - Flow-to-item: flow leaves the rate region as discrete items, and the buffer’s level drains into each item. Siprelle kept these as two separate blocks, because items becoming flow and flow becoming items don’t behave the same way. Era 2 took a different approach; today’s engine returns to the separate pair. What carried forward: the three primitives, separate item-to-flow and flow-to-item blocks, the rule that items and flow are different things, and the practice of validating against real plants. ### Era 2: Imagine That and the ExtendSim Rate Library (2008–2014) #### Rates by linear programming Cécile Damiron and Anthony Nastasi, building on Siprelle’s work, recast the method in terms of linear programming. Their 2008 paper, Discrete Rate Simulation Using Linear Programming, solved for the rate of every flow in the network at each event. Between events the rates hold and the system moves forward exactly. That meant no time-stepping, no integration error and repeatable results. The principle carries through to today’s engine, which gets there its own way. #### The Interchange block Damiron’s design merged the separate item-to-flow and flow-to-item blocks into one bidirectional Interchange block in the ExtendSim Rate Library, which converts in whichever direction material moves. Today’s engine keeps the two blocks separate, following SDI Industry. #### Krahl’s 2009 paper David Krahl’s 2009 paper, ExtendSim Advanced Technology: Discrete Rate Simulation, documented the technique as a module of ExtendSim. By then the method Siprelle created in 1990 as bulk flow simulation had its new name. Krahl’s paper also became the standard teaching reference. Its Figure 4 extends the Valdez Tanker with tank, valve and interchange blocks, and its contrast of discrete rate with continuous and discrete event modeling became the field’s usual explanation. What carried forward: exact rates between events, Krahl’s three-way comparison, and the Valdez Tanker example. What changed later: a return to separate item-to-flow and flow-to-item blocks. ### Era 3: Today’s engine (2024–today) #### Typed building blocks, separate conversion blocks kept ChiAha’s current engine, the one behind ReliaSim, is a new implementation of the method, written from scratch rather than ported from any earlier engine. It has: - Typed building blocks for constraints, buffers, conveyors and interrupts, so model errors are caught before a run. - Separate flow-to-item and item-to-flow blocks, Siprelle’s original design. - Item-based and rate-based runtimes that share state, for combined models such as the Hamburger Duo and the Valdez Tanker. - Text-based model files in place of block-and-wire diagrams. You can watch the lineage run in the Sandbox. The Hamburger Duo runs one plant as discrete event and discrete rate side by side, and the Valdez Tanker shows item-to-flow and flow-to-item working together on the classic Pritsker and Krahl example. #### Validation Fischel and Lange’s 2020 paper, High Accuracy Discrete Rate and Reliability Modeling to Drive Improvement of Plant OEE and Throughput, modeled a multi-line food plant. That model was rebuilt in ReliaSim and independently validated within 1% of the plant’s measured OEE; the published OEE validation case study has the details. ### What we keep and what we changed We keep: - Pritsker’s insight that real systems need combined approaches (1979). - Koelling and Remy’s published parameters, because specific numbers make models reproducible (1983). - Siprelle’s separate item-to-flow and flow-to-item blocks (1998). - Damiron and Nastasi’s exact rates between events (2008). - Krahl’s clear comparison of discrete rate with continuous and discrete event modeling (2009). We changed: - Block-and-wire diagrams to text-based model files. - Small time steps to exact, event-driven rates. - Single-language tools to typed, modular packages with clear boundaries. - “The Interchange does both” back to separate item-to-flow and flow-to-item blocks. ### Primary sources - Koelling, C. P. and Remy, W. H. (1983). Determining Operational Policies for Oil Flow and Tanker Loading Through Simulation. Proceedings of the 1983 Winter Simulation Conference. The published Valdez Tanker example. - Pritsker, A. A. B. and Pegden, C. D. (1979). Introduction to Simulation and SLAM. John Wiley and Sons. The textbook that introduced SLAM and combined discrete-continuous simulation. - Siprelle, A. J. and Parsons, D. J. (1995). Modeling a Bulk Manufacturing System Using Extend. Proceedings of the 1995 Winter Simulation Conference, 813–817. The foundational paper. - Siprelle, A. J. and Phelps, R. A. (1997). Simulation of Bulk Flow and High Speed Operations. Proceedings of the 1997 Winter Simulation Conference, 706–710. - SDI Industry 0.6 Reference Manual (1998). Documents the bulk flow blocks and the separate item-to-flow and flow-to-item design. - Damiron, C. and Nastasi, A. (2008). Discrete Rate Simulation Using Linear Programming. Proceedings of the 2008 Winter Simulation Conference. - Krahl, D. (2009). ExtendSim Advanced Technology: Discrete Rate Simulation. Proceedings of the 2009 Winter Simulation Conference. - Fischel, L. B. and Lange, T. J. (2020). High Accuracy Discrete Rate and Reliability Modeling to Drive Improvement of Plant OEE and Throughput. Proceedings of the 2020 Winter Simulation Conference. ### The published record Three decades of peer-reviewed work on discrete rate simulation, in order, starting with the first bulk flow paper in 1995. - 1995: Modeling a Bulk Manufacturing System Using Extend. Winter Simulation Conference. - 1997: Simulation of Bulk Flow and High Speed Operations. Winter Simulation Conference. - 1998: SDI Industry: An Extend-Based Tool for Continuous and High-Speed Manufacturing. Winter Simulation Conference. - 1999: SDI Industry Pro: Simulation for Enterprise-Wide Problem Solving. Winter Simulation Conference. - 2002: Non-Item Based Discrete Event Simulation Tools. Winter Simulation Conference. - 2008: Discrete Rate Simulation Using Linear Programming. Winter Simulation Conference. - 2009: ExtendSim Advanced Technology: Discrete Rate Simulation. Winter Simulation Conference. - 2011: A Mesoscopic Approach to Modeling and Simulation of Logistics Processes. Winter Simulation Conference. - 2012: Mesoscopic Supply Chain Simulation. Harbour, Maritime & Multimodal Logistics Modelling. - 2013: Simulation of Mixed Discrete and Continuous Systems: an Iron Ore Example. Winter Simulation Conference. - 2014: A Global Approach for Discrete Rate Simulation. - 2016: Comparison of Discrete Rate Modeling and Discrete Event Simulation. Springer. - 2017: Comparison of a microscopic discrete-rate and a mesoscopic discrete-rate simulation model for planning a production line. European Modeling & Simulation Symposium. - 2017: Application of discrete-rate-based simulation models for production and logistics planning. Harbour, Maritime & Multimodal Logistics Modelling. - 2020: Mesoscopic Discrete-Rate-Based Simulation Models for Production and Logistics Planning. - 2020: High Accuracy Discrete Rate and Reliability Modeling to Drive Improvement of Plant OEE and Throughput. Winter Simulation Conference. ExtendSim® is a registered trademark of Andritz Inc., referenced for identification only. #### Watch the lineage run The Valdez Tanker and the Hamburger Duo run in the Sandbox Flow tier, in your browser. Open the Valdez Tanker → Want the short version? Read the history of discrete rate simulation. --- # Migrating ExtendSim and Plant Simulation Models Source: https://reliasim.com/guides/simulation-model-migration.html ## Migrating a Simulation Model From ExtendSim or Plant Simulation to ReliaSim® Simulation Methods ## Migrating a Simulation Model From ExtendSim or Plant Simulation to ReliaSim® A model you’ve relied on for years is worth keeping, even when the tool it lives in no longer suits you. Migration moves what the model knows, its rates, stops, products and rules, into ReliaSim and then proves the new model gives the same answers as the old one before you retire it. ### When migration makes sense - Only one person can run it. The model works, but the person who built it has moved on or is about to, and nobody else can open it with confidence. - It runs too slowly for the question. A fast line modeled unit by unit takes long enough per run that you can’t afford the replications or the scenarios you need. - Short stops got lumped together. To keep run times down, micro-stops were folded into one availability number, which removes the blocking and starving that decide a fast line’s output. Micro-stops vs breakdowns explains why that matters. - The license no longer fits the use. The model gets opened a few times a year, or by people who only need to change inputs and read results. If units must keep their identity through the system, as in a job shop or a line where each part is routed by its attributes, a discrete event tool is often still the right home. Discrete rate vs discrete event simulation covers how to tell. ### What carries over, and what doesn’t There’s no file converter. ReliaSim doesn’t open ExtendSim or Plant Simulation model files, and a converter would carry the old tool’s workarounds along with the model. What moves is what the model knows: - The data. Rates, speeds, buffer sizes, product and changeover tables, and every failure mode’s time-to-failure and time-to-repair. This is usually most of a mature model’s value. - The logic. Which machine feeds which, where material accumulates, where units change (bottles to cases to pallets), and the rules that decide what runs when. - The answers. The original model’s outputs for a set of known cases, which become the test the new model has to pass. The layout is rebuilt in ReliaSim. The data comes across as tables. ### Where the data goes: ReliaDB ReliaDB is the database behind a ReliaSim model. It holds the model’s data as tables, and the model’s parameter sets are generated from it, one per product or configuration if that’s what the question needs. Most of a mature model’s numbers already live in tables: ExtendSim’s internal databases or linked spreadsheets, Plant Simulation’s table objects. Exported as CSV, they load into ReliaDB tables. From there the rates and stop distributions reach the model without being retyped, and a change to the data regenerates the parameter sets instead of starting an edit session in the model. ### The steps - Inventory the model. List what it answers today, the inputs it reads, the outputs people use, and any logic that lives in code. - Export the tables. Product, rate, buffer, changeover and failure data, as CSV. - Load them into ReliaDB. One table per kind of data, keyed the way the model uses it. - Rebuild the layout. Constraints, converters and buffers in ReliaSim, with each machine’s interrupt signature holding its failure modes. - Prove parity. Run the same cases through both models and compare. Then compare the new model against the plant’s own history, the way the ReliaSim method validates every model. - Retire the old model. Only once the new one matches it and the plant. ### How the pieces map Typical mappings. Every model has its own habits, so each one is reviewed at the start of a migration. ExtendSim to ReliaSim ExtendSimReliaSimNotes Valve (Rate library), Activity (Item library)ConstraintA rate limit with its own reliability. Tank (Rate library), Queue (Item library)BufferAccumulation between operations. Interchange, unit changes along the lineConverterMaterial measured one way in, another way out. Shutdown blocks and downtime logicInterrupt signatureOne time-to-failure and time-to-repair pair per failure mode. ExtendSim databases, linked spreadsheetsReliaDB tablesExported as CSV; parameter sets generated from them. Plant Simulation to ReliaSim Plant SimulationReliaSimNotes SingleProc, ParallelProcConstraintProcessing time becomes a rate. Buffer, accumulating conveyorsBufferCapacity carries over directly. Assembly and packing stationsConverterBottles into cases, cases onto pallets. Source and DrainBuffers at the start and end of the lineSupply ahead of the line and the warehouse after it. Failure profiles (availability and MTTR)Interrupt signatureEach failure mode kept separate instead of one availability figure. Table objectsReliaDB tablesExported as CSV. Logic that depends on individual units, such as routing by attribute or custom code, is the part to look at first. On a high-speed line it usually becomes a rate rule or a split between lines. Where it can’t, that’s a sign part of the model belongs in a discrete event tool. ### The proof: a published model, rebuilt Fischel and Lange’s 2020 Winter Simulation Conference paper modeled a multi-line food plant in ExtendSim. That published model was rebuilt in ReliaSim and independently validated. The ReliaSim model came within 1% of both the plant’s measured OEE and the original ExtendSim model, and ran 1,200× faster on the same laptop over the same one-year run. The published OEE validation case study has the details, and ReliaSim vs ExtendSim compares the tools. ExtendSim® is a registered trademark of Andritz Inc. Plant Simulation and Tecnomatix are trademarks or registered trademarks of Siemens. Both are referenced for identification only. ### Frequently asked questions #### Can ReliaSim open ExtendSim or Plant Simulation model files? No. Migration is a rebuild: the model’s data comes across as tables into ReliaDB, and the layout is rebuilt in ReliaSim. That leaves the old tool’s workarounds behind. #### How do we know the migrated model is right? It has to match the original model on a set of known cases, and then match the plant’s own history. The published Fischel and Lange model was rebuilt this way and matched both. #### What is ReliaDB? The database behind a ReliaSim model. It holds the model’s data as tables, and the model’s parameter sets are generated from it. #### Will we lose detail? Not the detail that decides a fast line’s output. Each failure mode keeps its own time-to-failure and time-to-repair, which many older models had to lump together. Logic that depends on individual units is reviewed first, because it may belong in a discrete event tool. #### Do you do the migration for us? Yes. ChiAha rebuilds the model, loads its data into ReliaDB, and proves parity with the original and with your plant before you retire it. It starts with a free migration assessment. #### Have a model worth keeping? Book a free migration assessment. Tell us what the model answers today and what it runs in, and we’ll tell you what moving it involves. Book a free migration assessment → Want to see the method first? Read how ReliaSim validates a model. --- # Types of Simulation: DES, Discrete Rate and More Source: https://reliasim.com/guides/simulation-methodologies.html ## Which Simulation Method Fits? Discrete Event, Discrete Rate, Continuous and Agent-Based Simulation Methods ## Which Simulation Method Fits? Discrete Event, Discrete Rate, Continuous and Agent-Based Every simulation method makes two choices before any model is built: what counts as the system’s state, and when the model updates it. Choose to fit the system and the model is fast and faithful. Choose badly and you spend the project fighting the method. Here are the main types of simulation, side by side. ### Two questions that sort every method Is there a clock? A static simulation has no simulated time. Monte Carlo simulation is the standard example, where you sample the uncertain inputs, compute the result and repeat. A dynamic simulation carries state forward in time, so what happens at 10:05 depends on what happened at 10:04. Discrete event, continuous, discrete rate, agent-based and system dynamics models are all dynamic. How does the clock move, and what moves with it? Some methods jump from event to event. Others step forward in small increments of time. The state can be individual units, continuous quantities, rates of flow, autonomous agents or aggregate stocks. Randomness is a separate axis. Any of these methods can be deterministic or stochastic, and a stochastic model is run for several replications. The same buffer (the material held between two machines) as each dynamic method sees it: Discrete event State is a count of units. It changes by one at every arrival or departure, and each change is an event. Continuous State is a quantity that changes continuously. A numerical integrator advances it step by step (the dots). Discrete rate State is a level fed by rates. Between events the rates hold, so the level is a straight line. Events fire only where a rate changes (the dots). Agent-based State belongs to individual agents, each following its own rules. System behavior emerges from how they interact. ### Discrete event simulation Discrete event simulation (DES) assumes the system’s state changes only at distinct instants, such as a part arriving, a machine starting, a job finishing or a truck leaving. The simulator keeps a list of future events in time order. It takes the next one, updates the state, schedules any events that follow and jumps the clock forward. Nothing is computed between events, because by assumption nothing changes. The building blocks are entities (parts, orders, customers), resources (machines, operators, docks) and queues. Entities carry attributes and follow routing logic, so DES is excellent whenever unit identity matters. Fits: job shops and discrete-part assembly, warehousing and material handling, logistics, service and queueing systems, and anywhere priorities, routings or individual attributes drive the result. Watch out for: event count grows with the number of units. On lines running hundreds or thousands of units a minute, modelers often treat a case or a pallet as one entity to keep run times reasonable, which gives up some of the short-stop detail. Most general-purpose commercial packages are discrete event at their core. See which tools use which method. ### Continuous simulation Continuous simulation treats state variables (a tank level, a temperature, a concentration, a velocity) as changing continuously over time. The model is usually a set of differential equations, and a numerical integrator advances it in small time steps, either fixed or adaptive. Fits: physical and chemical process dynamics, control-system design, thermal and fluid behavior, and anywhere the physics between events is the question. Watch out for: the step size trades accuracy against run time. Sudden changes such as a valve closing or a machine failing need explicit event detection, and individual units have no natural home in the model. ### Discrete rate simulation Discrete rate simulation (DRS) models material as flow moving at a rate, not as individual units. The key assumption is that rates stay constant between events. Buffer levels therefore change linearly, and the simulator can calculate exactly when a buffer will fill or empty and schedule that moment as an event. At each event (a failure, a repair, a changeover, a buffer reaching full or empty) it recomputes the rates across the network and predicts the next event. Andrew Siprelle created the technique in 1990, originally under the name bulk flow simulation. A DRS model is built from three primitives: constraints that limit rate, buffers that absorb rate differences and interrupts that change rate. Fits: high-speed filling, bottling, packaging and converting lines, and bulk or process flow through tanks, pipelines and accumulating conveyors. It suits reliability-driven throughput questions, where blocking, starving and buffer sizing decide the answer. Watch out for: a rate that varies continuously, such as a tank draining under gravity or a reaction slowing down, has to be represented as a series of steps or handed to a continuous model. Inside a flow region units have no identity. Where identity matters, hybrid models convert items to flow and back. ### Agent-based modeling Agent-based modeling (ABM) gives each individual (a person, a vehicle, a firm, a robot) its own state and decision rules, and lets agents interact with each other and with their environment. The system’s behavior isn’t written down directly. It emerges from those interactions, and the clock can be event-driven or time-stepped. Fits: markets and product adoption, crowds and pedestrian movement, fleets that make their own decisions, and organizational behavior. Watch out for: behavioral rules have many parameters that are hard to measure, so validation takes real effort. Run time grows with the number of agents and interactions. ### System dynamics System dynamics (SD), developed by Jay Forrester at MIT from the late 1950s, models stocks, the flows between them, and the feedback loops and delays that connect them. It’s continuous and deliberately aggregate, describing total inventory rather than individual pallets. Fits: strategic, long-horizon questions such as capacity expansion over years, policy effects and aggregate supply chain oscillation. Watch out for: aggregation hides short-term operational behavior. It won’t tell you what a four-minute filler stop does to the case packer. ### Monte Carlo simulation Monte Carlo simulation repeatedly samples uncertain inputs from probability distributions, pushes each sample through a calculation and reports the distribution of results. With no clock and no state carried forward, it’s quick to build but can’t represent buffers filling or machines starving. See Monte Carlo vs discrete rate simulation. ### Comparison table MethodClockStateNatural fitCommon pitfall Discrete eventNext eventEntities, resources, queuesDiscrete parts, routing, queueing, logisticsEvent count grows with unit volume Discrete rateNext rate changeRates and buffer levelsHigh-speed lines, bulk and process flowContinuously varying rates must be stepped ContinuousTime stepsContinuous variablesPhysics, chemistry, controlStep size vs accuracy; discrete events need detection Agent-basedEvents or stepsIndividual agentsEmergent behavior of many decision-makersHard-to-validate behavioral rules System dynamicsTime stepsAggregate stocks and flowsStrategic, long-horizon feedbackHides short-term operational detail Monte CarloNone (static)Sampled inputsIndependent risks, one-period totalsCan’t represent timing, buffers or queues ### Combining methods Real systems rarely fit one method. Combined discrete-continuous simulation goes back at least to Pritsker’s SLAM language in 1979, and several commercial tools now support more than one method in a single model. A common pattern is item-based logic for orders, trucks or batches alongside rate-based flow for the high-speed or bulk section of the process. ### Where discrete rate sits Discrete rate simulation sits between discrete event and continuous simulation. From discrete event it takes the event-driven clock, with no work between events. From continuous simulation it takes the idea that material is a quantity rather than a stream of individual objects. Assuming rates stay constant between events is what lets it compute buffer levels exactly without numerical integration, and it’s also the method’s main limitation. For the detailed comparison, see discrete rate vs discrete event simulation. A quick rule of thumb. If you describe the system in units per minute and the argument is about stops and buffers, try discrete rate. If it’s about which part goes where and in what order, use discrete event. If it’s about how a physical variable evolves, use continuous. If it’s about how many independent decision-makers behave, use agent-based. If it’s about how a policy plays out over years, use system dynamics. If the question is only how uncertain a total is, Monte Carlo may be all you need. ### Frequently asked questions #### What are the main types of simulation? The methods most used for operations and engineering questions are discrete event simulation, continuous simulation, discrete rate simulation, agent-based modeling and system dynamics, which all model a system over time, plus Monte Carlo simulation, which is static. Monte Carlo samples uncertain inputs many times but has no simulated clock. The methods differ in what they treat as the system’s state and in how the model moves from one moment to the next. #### What is the difference between discrete event and continuous simulation? Discrete event simulation assumes the state changes only at distinct instants, such as an arrival, a start or a finish, and jumps the clock from one event to the next. Continuous simulation treats state variables such as a level, a temperature or a pressure as changing continuously, usually described by differential equations and advanced with a numerical integrator in small time steps. #### Is discrete rate simulation a type of discrete event simulation? It shares discrete event simulation’s event-driven clock but not its unit of analysis. Discrete event simulation typically makes each unit an entity. Discrete rate simulation models material as flow at a rate that stays constant between events, so buffer levels change linearly and the time a buffer will fill or empty can be calculated and scheduled. An event is a change in rate, not the passage of a unit, which places it between discrete event and continuous simulation. #### When should I use agent-based simulation instead of discrete event simulation? Use agent-based modeling when the behavior you care about emerges from many individuals that each make their own decisions and interact, such as buyers in a market, people moving through a space or a fleet of vehicles choosing routes. Use discrete event simulation when the system is better described as a process, where units follow defined steps, compete for resources and wait in queues. #### Can one simulation model combine several methods? Yes. Combined discrete-continuous simulation dates back at least to Pritsker’s SLAM language in 1979, and several commercial tools today support more than one method in the same model. A common pattern is item-based logic for orders, trucks or batches alongside rate-based flow for the high-speed or bulk part of the process. #### See three methods run the same tank The Fast-Slow Drain fills and drains one tank as continuous, discrete event and discrete rate, and counts the events each one needs. Open the Fast-Slow Drain → Or go straight to discrete rate vs discrete event. --- # Monte Carlo vs Discrete Rate Simulation Source: https://reliasim.com/guides/monte-carlo-vs-discrete-rate-simulation.html ## Monte Carlo vs Discrete Rate Simulation When Is a Spreadsheet Enough? Simulation Methods ## Monte Carlo vs Discrete Rate Simulation When Is a Spreadsheet Enough? Monte Carlo simulation is often the first tool an engineer reaches for. It fits in a spreadsheet and handles uncertainty well, but it has no clock. Here’s when that matters for manufacturing questions, and when it doesn’t. The Bottling Line demo in the Sandbox shows where the losses are on a six-station line. ### What Monte Carlo simulation is The Monte Carlo method was developed in the 1940s at Los Alamos, associated with Stanislaw Ulam, John von Neumann and Nicholas Metropolis. You describe each uncertain input with a probability distribution, draw one value from each, compute the result and repeat thousands of times. The results approximate the distribution of the output. In most manufacturing and business use, Monte Carlo is static. Each trial is a separate calculation with no simulated time inside it, only a formula. ### What a dynamic simulation adds A dynamic simulation has a clock and a state that evolves. The level in a buffer at 10:05 depends on its level at 10:04, on whether the upstream machine was running and on whether the downstream machine was taking material. Discrete event, discrete rate and continuous simulation are all dynamic. They differ in how they move the clock, as covered in simulation methodologies. Dynamic stochastic models also use random sampling. Failure and repair times are drawn from distributions as the model runs, and the model is replicated to get a range of results. So the real difference between Monte Carlo and a discrete event model isn’t randomness. It’s whether time and state are part of the model. AspectStatic Monte CarloDynamic simulation Simulated clockNoneYes, event to event State carried forwardNo, each trial is independentYes: buffer levels, machine states, queues RandomnessSampled inputs per trialFailures, repairs and arrivals sampled during the run, plus replications Buffers, blocking, starvingCan’t be representedRepresented directly Build effortHours, in a spreadsheetMore, since it needs structure, logic and data Typical outputDistribution of a totalDistributions over time: throughput, downtime, buffer behavior and where losses occur ### Where the static view breaks: two machines Take two machines in series, each available 90% of the time. A Monte Carlo spreadsheet samples each machine’s availability and multiplies them, so on average the line is available about 0.9 × 0.9 = 81% of the time. That arithmetic holds only if every stop on either machine stops the whole line at once, and the two machines fail independently. Now put a buffer between them. When the upstream machine stops, the downstream machine keeps running from the buffer until it empties. When the downstream machine stops, the upstream machine keeps filling the buffer until it’s full. Whether the buffer rescues a little output or a lot depends on how long the stops last compared with how many minutes of material the buffer holds. That’s a question about timing, and the formula has nowhere to put it. The independence assumption is weaker than it looks, too. A machine that’s blocked or starved isn’t running, and many failure modes only occur while a machine runs. Stops on one machine change how often its neighbors fail. A dynamic model represents that interaction, and a multiplication doesn’t. Spreadsheet, dashboard, AI or simulation? covers the same bias in a loss tree. ### When Monte Carlo is enough - Independent risks. Project cost and schedule risk, supplier delays that add up, or several risks that don’t interact. - One-period totals. Annual demand against nominal annual capacity, where the question is whether the volume fits at all rather than how the line behaves hour to hour. - Separate assets. Several independent lines where a stop on one doesn’t affect another. - Screening. A quick sensitivity check to find which uncertain inputs matter before investing in a detailed model. ### When you need a dynamic model - Buffers and accumulation between machines, and questions about how big they should be. - Blocking and starving, where a stop on one machine spreads up and down the line. - Short, frequent stops, where the length of each stop decides what’s lost, not just the total downtime. - Changeovers, schedules and sequences, where the order of events matters. - Moving bottlenecks, where the constraint shifts as machines fail and recover. - Any “what if we change X” question where X interacts with timing, such as a faster filler, a larger accumulation table or a new maintenance plan. ### Discrete rate or discrete event for the dynamic model? Both are dynamic, and both handle the interactions above. The difference is what they count as an event. Discrete event simulation typically treats each unit as an entity, so the work grows with the number of units. Discrete rate simulation treats flow as a rate that stays constant between events, so the work grows with the number of rate changes (failures, repairs, changeovers, buffers filling or emptying). On high-speed lines that makes discrete rate a natural fit. For discrete parts with routings and attributes, discrete event is the better tool. The full comparison is in discrete rate vs discrete event simulation. Speed matters, because every design alternative needs its own set of replications. The published example is the ExtendSim® model from Fischel and Lange’s WSC 2020 study of a food plant, which was rebuilt in ReliaSim® and independently validated by Tom Lange. The ReliaSim model came within 1% of both the plant’s measured OEE and the original model (case study). A practical sequence. Use Monte Carlo to scope the uncertainty and find the inputs that matter. If the answer depends on timing, build the dynamic model, fit its failure and repair distributions from your own event data, validate it against history, and then run the experiments. ExtendSim® is a registered trademark of Andritz Inc., referenced for identification only. ### Frequently asked questions #### Is Monte Carlo simulation the same as discrete event simulation? No. Monte Carlo simulation is static. It samples uncertain inputs and computes a result, with no simulated clock and no state carried forward. Discrete event simulation is dynamic. It moves a clock from event to event and tracks how the state of the system changes over time. The two are often combined, because a stochastic discrete event model is run for many replications and the spread of those results is summarized in a Monte Carlo fashion. #### Can Monte Carlo simulation predict manufacturing throughput? It can give a useful first estimate when machines are effectively independent, for example separate lines, or a line with no meaningful buffers where every stop halts the whole line. Once buffers, blocking and starving, changeovers or the length of stops matter, throughput depends on timing, and a static calculation can’t represent timing. That’s when a dynamic model such as discrete rate or discrete event simulation is needed. #### What is the difference between static and dynamic simulation? A static simulation represents a system at a single point, or over a period treated as one lump, so time plays no role. A dynamic simulation represents how the system evolves over time, so the state at one moment depends on the state a moment earlier. Monte Carlo spreadsheet models are static, and discrete event, discrete rate and continuous models are dynamic. #### Do dynamic simulations use Monte Carlo methods? Usually, yes. A stochastic dynamic model samples failure times, repair times and other random inputs as it runs, and it’s replicated with different random numbers so results can be reported as a range rather than a single figure. The difference is that each replication carries state through simulated time, which a static Monte Carlo model doesn’t. #### When is a spreadsheet model good enough? When the result is a sum or product of uncertain quantities that don’t interact through time, such as budget and schedule risk, annual demand against nominal capacity, or independent failure risks. If the answer depends on what happens while a buffer drains, how long a stop lasts or the order in which things occur, a spreadsheet will give a confident answer to the wrong question. #### Try a line with real downtime The Bottling Line demo shows why one availability number hides where the losses are. Open the Bottling Line → Or read digital twin vs simulation. --- # Digital Twin vs Simulation: What's the Difference? Source: https://reliasim.com/guides/digital-twin-vs-simulation.html ## Digital Twin vs Simulation What a Validated Model Is, and Isn’t Simulation Methods ## Digital Twin vs Simulation What a Validated Model Is, and Isn’t “Digital twin” has become the default label for almost any model of a factory, which makes it hard to know what you’re buying or building. The two terms do mean different things. The difference lies in the data connection and in whether the model has been validated against the real system, not in how realistic the graphics look. The Chocolate Processing demo in the Sandbox runs three systems in series as a campaign schedule. ### What a simulation model is A simulation model represents how a system behaves over time, so you can run experiments on the model instead of the real thing. What happens if the filler runs faster, the accumulation table doubles or preventive maintenance moves to a different shift? A model of a production line is built from the line’s structure (machines, rates, buffers) and its behavior (how often each machine stops and for how long), and it’s only as good as both. The model can be generic, a teaching example, or a detailed representation of one specific line built from that line’s own event data. Its inputs are refreshed when someone re-pulls the data. ### What a digital twin is A digital twin is a virtual representation of one specific physical asset, process or system that stays connected to it. The concept is usually traced to Michael Grieves’s product-lifecycle work in the early 2000s, and the name was popularized through NASA technology roadmaps around 2010. The core idea has three parts: the physical system, its virtual counterpart and the data link between them. A widely cited research classification (Kritzinger and colleagues, 2018) separates three levels by how the data moves. LevelPhysical → modelModel → physicalExample Digital modelManualManualA line simulation built from exported downtime logs, where a person acts on the results Digital shadowAutomaticManualThe same model fed on a schedule from the plant historian, where a person acts on the results Digital twinAutomaticAutomaticThe model receives live state and sends settings or schedules back to the line By that definition, many products sold as digital twins are digital models or digital shadows. For many questions a model is exactly the right tool. It’s still a reason to ask three questions of any twin: what is connected, how often, and in which direction? ### Simulation vs digital twin, side by side AspectSimulation modelDigital twin Main purposeExperiment by comparing what-if alternativesMirror and act on one live asset or process Data connectionLoaded from historical data, refreshed as neededAutomatic, continuing connection Time horizonWeeks to years of simulated operationOften the current state and the near future Typical decisionsBuffer sizing, line design, capital projects, maintenance policyNext-shift scheduling, live monitoring, control adjustments InfrastructureThe model and its input dataModel, data pipelines, integration and upkeep Must be validated?YesYes, and kept valid as the asset changes ### Validation comes first A live data feed doesn’t make a model correct. If the model’s structure is wrong, or a machine’s failures are averaged into a single number, a connected twin reproduces the error faster and with more confidence. Run the model over a period you’ve measured, and compare. Compare at the right level, too. An overall total can match for the wrong reasons, with one failure mode overstated and another understated so the errors cancel. Comparing simulated and measured behavior for each failure mode separately can’t hide that. Done that way, a discrete rate model can match a plant’s measured OEE closely. Each machine’s failure modes have to be kept separate, with time-to-failure and time-to-repair distributions fitted from the plant’s own event data, and the model validated against history. The published OEE validation case study shows a ReliaSim® rebuild of an ExtendSim® food-plant model from Fischel and Lange’s WSC 2020 paper coming within 1% of the plant’s measured OEE. ### When a live connection is worth it - Worth it: decisions made hour to hour or shift to shift, where the current state (what’s down right now, what’s in the buffers) changes the answer, and where someone or something will act on the output quickly. - Usually not needed: design and investment decisions such as buffer sizing, adding a machine or changing a maintenance policy. These depend on months of failure and repair behavior, and a validated model refreshed from that history answers them fully. - Either way: the model has to reproduce measured history before its predictions are worth acting on. ### Why ReliaSim calls it a playing field ReliaSim builds validated simulation models of production lines from the event data plants already record, using discrete rate simulation. We call the model a playing field. It’s the term our modelers have long used for the scope an experiment plays out on: the machines, buffers and stops that matter to the question, and nothing that doesn’t. The name says what the model is for. A twin’s job is to mirror the line as it runs today. A playing field’s job is to let you try moves you haven’t made yet, like a faster filler, a bigger buffer or a second case packer, and see what each one is worth before you commit. ExtendSim® is a registered trademark of Andritz Inc., referenced for identification only. ### Frequently asked questions #### What is the difference between a digital twin and a simulation? A simulation model is a representation of how a system behaves, used to run experiments on it. A digital twin is a virtual representation of one specific physical asset or process that stays connected to it, so data flows automatically from the real system to the model, and in the strict definition back again. Many digital twins contain a simulation model, and the connection is what makes it a twin. #### Is every simulation model a digital twin? No. A model of a specific line, built from that line’s data and refreshed when someone re-pulls the data, is a simulation model, which the research literature calls a digital model. It becomes a digital shadow when data flows into it automatically, and a digital twin in the strict sense when data flows automatically in both directions. Vendors often use the term loosely, so ask what is connected, how often and in which direction. #### Does a digital twin need real-time data? It needs an automatic data connection, but how fresh the data must be depends on the decision. Operational decisions about the next shift benefit from data that is minutes old. Design decisions such as buffer sizing, line layout or capital investment depend on months of failure and repair history, and a model refreshed periodically from that history answers them just as well. #### What does it mean to validate a simulation model? It means running the model over a period for which you have measured results and comparing the two before trusting any prediction. A strong validation compares each failure mode separately, not just the overall total, because errors in individual modes can cancel out into an aggregate that looks right for the wrong reasons. #### Can a simulation model become a digital twin later? Yes, in principle. A validated model can be connected to live data feeds once the data pipeline and the business case exist. Validating the model first means the connection carries a model already known to reproduce the real system, rather than feeding live data into a model that has never been checked. #### Explore a plant model in your browser The Chocolate Processing demo runs three systems in series, with equipment failures, as a campaign schedule. Open Chocolate Processing → Or read simulation methodologies. --- # ReliaSim vs ExtendSim: Same Model, 1,200× Faster Source: https://reliasim.com/compare/reliasim-vs-extendsim.html ## ReliaSim® vs ExtendSim The same validated model in both engines, 1,200× faster ~1,200×faster in ReliaSim, same laptop, same one-year simulated run 20+unit operations in the model, with up to 20 failure modes on each ### The same model, two engines In their 2020 Winter Simulation Conference paper, Fischel and Lange modeled a real multi-line food plant, not a teaching example. The model is a per-failure-mode discrete rate and reliability model. It carries up to twenty failure modes on each of more than twenty unit operations. Its structure matters for what follows. A reliability block diagram sits inside each rate-affecting unit operation, carrying that unit’s failure modes and letting its failure rate scale with production rate. The line itself comes from discrete rate coupling through the valves, tanks and conveyors between the units. The authors built it in ExtendSim, and it’s the featured case study on ExtendSim’s own reliability block diagram page. The validation bar they set was agreement within 1% of overall system OEE between a one-year simulation and the plant’s actual data. The model met it. The paper also explains why the per-mode detail is necessary. “Had an averaged, single-failure-mode-per-unit-operation approach been followed, the gains and losses would be less accurate and essentially identical to each other.” — Fischel & Lange, WSC 2020 ### The independent validation That published model was rebuilt in ReliaSim and independently validated by Tom Lange, a co-author of the paper. The ReliaSim model came within 1% of the plant’s measured OEE, the same bar the original met, and it agreed just as closely with the original ExtendSim model. Those are two different checks, and both matter. Agreement with the plant says the rebuild reproduces reality as well as the published model did. Agreement with the original model says the two engines, given the same structure and the same failure data, produce the same answers. So the comparison below isn’t about which tool is more accurate, because on this model they agree. It’s about what the same accurate answer costs in time. The paper is two pages and open access, so you can check the original model yourself. Our write-up of the study is the published OEE validation case study. ### The clock Both models were run on the same laptop over the same one-year simulated duration. ReliaSim finished roughly 1,200× faster in real clock time. Because the hardware and the simulated horizon were held the same, the ratio compares the engines, not the machines they ran on. The paper reports the validation, not run times. The timing comes from the independent validation of the rebuild. For a sense of scale on a smaller line, a thousand one-year runs of ReliaSim’s five-machine demo bottling line take about two and a half minutes on a laptop. That’s 0.154 seconds per simulated year. ### What the speed buys A one-year run that takes a long time is a run you do a few of, and the meeting becomes an argument about which candidates to pick. When the same run costs seconds, the hand-picked scenarios stop being a constraint. - Sweeps instead of guesses. The buffer sweep behind how big should a buffer be? is 7,770 runs, or 1,864 simulated years, in 31.8 seconds. - Every failure mode, removed one at a time. Ranking losses by what the line gets back takes one full re-run per failure mode, which means hundreds of one-year runs on a model the size of the food plant’s. Two failure modes with near-identical direct losses can return very different amounts. See micro-stops vs breakdowns and which loss to fix first. - Distributions, not single runs. Replications are cheap enough that every answer comes with its spread. The discipline doesn’t change with the clock. You still build the model, gather per-failure-mode data and validate before predicting. The engine itself is on capabilities. ### Where ExtendSim fits ExtendSim is a general-purpose simulation toolkit. Its product line covers discrete event simulation, discrete rate simulation and reliability block diagramming, and modelers can build their own custom blocks. If you need several modeling methods in one environment, item-level logic alongside flow, or a component library you extend yourself, it’s the broader tool, and ReliaSim doesn’t try to match it. ReliaSim is deliberately narrower. It covers high-speed and bulk-flow production lines with a short vocabulary of constraints, converters, buffers and interrupts, and a build, validate, predict method around it. The two tools also share a history. Andrew Siprelle created discrete rate simulation in 1990, as “bulk flow” simulation. Its first paper, with David Parsons at WSC 1995, was built using Extend. ExtendSim’s Rate Library later built a second generation on that work, including Damiron and Nastasi’s 2008 linear-programming approach and Krahl’s 2009 paper. The full account is on the discrete rate lineage page. Both discrete rate engines trace back to the same inventor. The team behind ReliaSim also wrote many of the libraries Extend modelers built on, among them SDI Industry, Bulk Flow (Rate), the SDI Database library and Supply Chain Builder. The Bulk Flow (Rate) and Database libraries sold more than 700 licenses and were the origin of ExtendSim’s Discrete Rate and Database libraries, and Andy Siprelle created the first official ExtendSim training program. SDI’s projects were built in ExtendSim and have since been rebuilt in ReliaSim: see the case studies and our heritage. ### Frequently asked questions Was it the same model in both tools? Yes. It’s the model Fischel and Lange published at the 2020 Winter Simulation Conference, originally built in ExtendSim, then rebuilt in ReliaSim and independently validated by Tom Lange, one of its authors. Who validated the ReliaSim model? Tom Lange, co-author of the original paper. He validated the ReliaSim rebuild against both the plant’s measured OEE and the original ExtendSim model, and it matched both. What does within 1% of measured OEE mean? It means a one-year simulation’s OEE differs from the plant’s actual OEE by less than one percentage point. That’s the bar the paper set, and the ReliaSim rebuild met it too. What hardware was the 1,200× speed difference measured on? Both ran on the same laptop, over the same one-year simulated duration, so the ratio compares the two engines, not the computers. Can a model of my line match measured OEE? Yes, when the model and data are handled correctly. Draw the line as it actually runs and keep interrupt data per failure mode instead of averaging it. Fit the distributions properly, and validate the model against the line’s own history before you use it to predict. Did the ReliaSim team build ExtendSim libraries? Yes. The team behind ReliaSim wrote many of the libraries Extend modelers built on, among them SDI Industry, Bulk Flow (Rate), the SDI Database library and Supply Chain Builder. The Bulk Flow (Rate) and Database libraries sold more than 700 licenses and were the origin of ExtendSim’s Discrete Rate and Database libraries. Is ReliaSim affiliated with ExtendSim or Andritz? No. ExtendSim is referenced here for identification and historical purposes only, and no affiliation or endorsement is implied. #### Look inside a validated line model The bottling-line models in the Sandbox’s Lines tier come with the engine’s saved results for each. Their Gain/Loss results show what the line gets back when each failure mode is removed. There’s nothing to download and no sign-up. Open the Sandbox → The published validation Want to see it on your own line? Schedule a call. --- # ReliaSim vs anyLogistix: When Each Fits Source: https://reliasim.com/compare/reliasim-vs-anylogistix.html ## ReliaSim® vs anyLogistix Two Tools for Supply Chain Decisions, Built Around Different Starting Points Comparison ## ReliaSim® vs anyLogistix Two Tools for Supply Chain Decisions, Built Around Different Starting Points anyLogistix is a dedicated supply chain design and planning platform with a wide set of built-in optimization experiments. ReliaSim is a simulation product that started on the plant floor and extends to the network. Both simulate supply chains. They suit different teams and different questions, and this page tries to say which is which. ### What anyLogistix is built for anyLogistix describes itself as supply chain optimization, simulation and design software (anyLogistix home page). Its feature list covers network design and optimization, greenfield analysis, what-if simulation, risk and stress testing, inventory optimization with a safety stock estimation experiment, and last-mile transportation optimization (anyLogistix features). Its network optimization runs on IBM ILOG CPLEX, which anyLogistix calls “the leading analytical solver” (features). The Studio edition adds a full AnyLogic modeling environment for custom policies, custom experiments and detailed facility logic such as order picking, layouts and forklift counts (Studio extensions explained). The Professional edition is sold as an annual subscription, with server installation as an option (purchase page). ### Where anyLogistix is the better fit - Optimization is the main job. If most of your work is solving large network design, sourcing and transportation problems, a platform built around a commercial MIP solver and a library of ready-made optimization experiments is the direct route. - Large networks and many experiment types in one place. Greenfield, network optimization, safety stock estimation, risk analysis and last-mile routing sit side by side in one interface. - You want to program your own logic. Studio’s AnyLogic environment lets a modeler write custom policies, statistics and optimization algorithms. - A dedicated supply chain design team. A group that runs network studies every quarter will use that breadth. ReliaSim doesn’t try to match anyLogistix’s range of optimization experiments or its scale on the largest networks. ### Where ReliaSim fits #### Try it without an account Eleven supply chain network demos run in the browser with no signup and nothing to install. They cover DC siting, footprint consolidation, stock over time, safety stock placement and tariff and fuel-price scenarios. You can see how the tool thinks before anyone schedules a call. #### Validation comes before scenarios The ReliaSim method makes a model reproduce a period of history, part by part, before it’s used to answer a what-if question. On the plant side that method is published. A food plant model matched the plant’s measured OEE to within 1% (the validation study). For networks the same rule applies to flows by lane, stock by site and lead times. How to know your supply chain model is right sets it out. #### One product from the line to the network Most supply chain models treat a plant as a capacity number. ReliaSim models production lines in detail, with every machine’s failure modes and the buffers between them, and it models networks. A network plan can use what the line model says a plant will really make, instead of its rated capacity. The plant side covers the line models. #### Your data stays on your machine ReliaSim is desktop software. Models are files on the modeler’s own machine, and the product doesn’t call a cloud service. Security and deployment covers the details IT usually asks about. ### At a glance anyLogistixReliaSim Built forSupply chain design and planning: optimization, simulation, risk, inventory, transportationProduction lines and the supply chains they feed OptimizationBuilt-in experiments on IBM ILOG CPLEXNetwork optimization used alongside simulation, on a narrower set of questions Custom logicAnyLogic environment in the Studio editionA short, fixed vocabulary; custom work is done as a project Plant detailFacility logic through Studio extensionsLine models with per-failure-mode reliability and buffers Try itDownload or online editionBrowser demos with no signup anyLogistix details from anyLogistix features, Studio extensions explained and the purchase page, read September 2026. ### Using both The two aren’t exclusive. A team can design a network in an optimization platform and then test a specific plant or DC decision in ReliaSim, where the line’s own stop data decides what the plant can supply. The supply chain simulation guide covers when to optimize and when to simulate. ### How to choose Start from the question. If you need to search thousands of network designs at scale, start with an optimization platform. If you need to know whether a design, or a plant inside it, will hold up, and you want the model checked against your own history first, start with simulation. Either way, try the network demos to see how ReliaSim approaches it. #### See the network demos Eleven supply chain demos run in your browser with sample data and no signup. Browse the demos → --- # ReliaSim vs BlockSim: Line Simulation vs RBD Source: https://reliasim.com/compare/reliasim-vs-blocksim.html ## ReliaSim® vs BlockSim Two simulators, two methods, two different questions The short answer - For reliability programs, fault trees, RAM analysis, maintenance and spares optimization, early redundancy decisions and life cycle cost, use a reliability engineering platform such as BlockSim. ReliaSim doesn’t try to be one. - For a high-speed production line where the question is output, and output depends on buffer dynamics, blocking and starving, use a line simulator such as ReliaSim. ### What BlockSim does, in ReliaSoft’s words HBK’s help describes BlockSim as “a comprehensive platform for system reliability, availability, maintainability and related analyses.” Using “exact computations or discrete event simulation,” it handles both repairable and non-repairable systems, and the analyses it lists include “reliability analysis, maintainability analysis, availability analysis, reliability optimization, throughput calculation, process flow diagrams, resource allocation, life cycle cost estimation.” Its event analysis flowcharts extend that to probabilistic or deterministic scenarios. (Intro to BlockSim) ReliaSoft’s Quick Tour names reliability block diagrams, fault trees and Markov analysis as the modeling approaches. Among the questions it lists: what the optimum maintenance strategy is, how many spares to keep on hand, whether crew capacity is sufficient, and where the critical components or bottlenecks are. (Quick Tour of BlockSim) BlockSim calculates throughput as well. In ReliaSoft’s throughput analysis, each block in the diagram processes items at a rate, the connections show the physical path of items through the process, and items a block can’t process are kept in backlog. Where a block can only accept a limited backlog, the rejected items are counted as “Excess Backlog.” Failures and repairs change what flows over time. (Throughput Analysis, Part I) So the difference between the tools isn’t whether they simulate, or whether they can produce a throughput number. It’s the simulation method, and the system each one is built to represent. ### ReliaSim: discrete rate simulation of a production line ReliaSim models a line as flow through constraints, converters and buffers (the vocabulary is on capabilities). Each failure mode is an interrupt carrying its own distributions, so blocking and starving emerge as the engine runs. It reports throughput, line efficiency and OEE, and each machine’s time up, down, blocked and starved. ReliaSim doesn’t do fault tree analysis, and it isn’t a maintenance or spares planning system. ### Discrete event vs discrete rate simulation Both methods are event-based, so the simulation clock jumps from one event to the next. They differ in what counts as an event (table below). In a discrete rate model every rate is constant between events, so the time to the next full or empty buffer can be calculated exactly. A schematic of the two ideas, not a model result. The top lane stands for any model that schedules an event per unit. The lower lane shows why a rate-based model needs only a handful of events for the same stretch of time. Why it matters on high-speed lines. At hundreds to thousands of units a minute, a model that schedules an event for every unit does work in proportion to line speed. A rate-based model’s event count depends on how often rates change, not on how many units pass. It also keeps short stops explicit. Each micro-stop is its own interrupt with its own distribution, and the partial fills and drains of the buffers between stops are calculated instead of averaged. Andrew Siprelle created discrete rate simulation in 1995 for exactly this kind of system. For more, see discrete rate vs discrete event simulation and how the simulation methodologies compare. The two methods in general AspectDiscrete eventDiscrete rate What is an eventA change of state: a unit moving, a component failing or being repairedA change of rate: failure, repair, changeover, buffer full or empty Between eventsState holds until the next eventRates hold; buffer levels change linearly Work grows withNumber of events, including unit volume when units are tracked individuallyNumber of rate changes, independent of line speed Natural fitSystems where the state or identity of individual items or components mattersHigh-volume flow with accumulation, blocking and starving This compares the methods, not any product’s implementation. A discrete event tool can represent flow in aggregate, and BlockSim’s throughput analysis works with per-block processing rates. ### When BlockSim is the better choice - Reliability programs. System reliability and availability targets, allocation, and the design reviews built around them, for repairable or non-repairable systems. - Fault tree analysis. Safety, risk and cause analysis that starts from an undesired event. - RAM, maintenance and spares optimization. Maintenance strategy, replacement and inspection timing, spares holdings and crew capacity are questions ReliaSoft describes BlockSim answering directly. See our RAM analysis guide. - Early redundancy decisions. Whether a second unit in parallel pays for itself, answered before layout and line rates are settled. - Life cycle cost. Cost estimation over the life of a system sits inside BlockSim’s list of analyses. ### When ReliaSim fits - A high-speed production or packaging line where the question is output, and output depends on buffer dynamics, blocking and starving. - How big the buffer, surge table or accumulating conveyor should be. - Where the real bottleneck is, and where it moves as downtime and mix change. - Which failure mode to fix first, ranked by throughput recovered instead of minutes lost. - What a change will do to line OEE. See OEE simulation and capacity planning simulation. A line model earns trust by matching the line. The published WSC 2020 food-plant model, rebuilt in ReliaSim, came within 1% of measured OEE (engine comparison in ReliaSim vs ExtendSim). ### Using both The cleanest division of labor is by level. Reliability engineering characterizes equipment: its failure modes, their distributions, and how redundancy, maintenance and spares change them. The line model takes those per-mode distributions and adds what line throughput depends on: rates, unit conversions, accumulation, and the order in which stops and buffer states interact. The WSC 2020 food-plant model is an example of the split, with a reliability block diagram inside each rate-affecting unit operation and the units coupled through discrete rate flow. The handoff is the data. However a failure mode was characterized, a line model needs its time-to-failure and time-to-repair distribution, not a pair of averages, because MTBF and MTTR are outputs, not inputs. When a plant has event history, the distributions come from Weibull analysis of downtime data. When it doesn’t, ReliaSim’s Interrupt Designer lets you enter them directly. The method-level argument is in reliability block diagram vs line simulation. ### Frequently asked questions Does BlockSim do simulation? Yes. ReliaSoft describes BlockSim as using exact computations or discrete event simulation to analyze repairable and non-repairable systems, and its event analysis flowcharts use Monte Carlo simulation. Can BlockSim calculate throughput? Yes. ReliaSoft documents a throughput analysis on the reliability block diagram, with a processing rate per block, backlog for items a block can’t process, and failures and repairs changing the flow over time. What’s the difference between discrete event and discrete rate simulation? In discrete event simulation an event is a change of state, such as a unit arriving or a component failing. In discrete rate simulation events occur only when a rate changes, so the work doesn’t grow with the number of units produced. Is ReliaSim a BlockSim alternative? For line questions such as throughput, buffer sizing and OEE, yes. For reliability programs, fault trees, maintenance, spares and life cycle cost, BlockSim is the better fit, and ReliaSim doesn’t replace it. Can I use both? Yes. Reliability analysis characterizes each failure mode, and the line model takes those distributions and adds the rates and accumulation that set line throughput. Is ReliaSim affiliated with HBK or ReliaSoft? No. BlockSim and ReliaSoft are trademarks of their respective owners, referenced on this page for identification only. No affiliation or endorsement is implied. #### See discrete rate results on a real line The bottling-line models in the ReliaSim Sandbox’s Lines tier come from one real line. On the Buffer-Options models, a saved sweep shows how much each inline buffer adds as it grows. You don’t need to sign up. Open the Sandbox → RAM analysis guide Want to talk through your own line? Schedule a call. --- # ReliaSim vs AnyLogic: When Each Fits Source: https://reliasim.com/compare/reliasim-vs-anylogic.html ## ReliaSim® vs AnyLogic A Multimethod Platform and a Purpose-Built Line Simulator Comparison ## ReliaSim® vs AnyLogic A Multimethod Platform and a Purpose-Built Line Simulator AnyLogic is a general simulation platform that supports discrete event, agent-based and system dynamics modeling in one tool. ReliaSim is built for one job: production lines and the supply chains they feed, modeled from each line’s own stop history. This page sets out where each fits. ### Price first ReliaSim’s price is published: $8,000 per user per year for the desktop license, on our pricing page. AnyLogic’s purchase page lists its editions without prices and offers a “Get a Quick Quote” form (AnyLogic purchase page). It also offers a free Personal Learning Edition “for evaluation and personal use only.” ### What AnyLogic is built for AnyLogic describes itself as “a single platform for all your business’ dynamic simulation modeling needs” and says it supports agent-based, system dynamics and discrete-event modeling, which it calls “true multimethod modeling” (AnyLogic features). Its libraries include a Material Handling Library for manufacturing, warehouse and intralogistics systems, and a Fluid Library for “bulk materials, fluids, and a large number of discrete items” (Fluid Library). The desktop editions are Personal Learning, University Researcher and Professional, and there are Private Cloud editions for teams (purchase page). ### Where AnyLogic is the better fit - You need several methods in one model. Agent-based behavior, system dynamics and discrete event logic together, for example a market model driving a factory model, is what AnyLogic is designed for. - Problems well beyond the production line. Pedestrian flows, transport, healthcare, policy and market models sit outside ReliaSim’s scope. - You want to program the model. A modeler who wants to write custom logic and build their own objects will use that freedom. - Detailed facility layout. Material handling equipment, layouts and 3D animation of a facility are a strength of a general platform. ReliaSim doesn’t try to match that breadth. ### Where ReliaSim fits #### The price is on the page A ReliaSim desktop license is $8,000 per user per year, and you can buy it online. ReliaStats, the companion tool that fits failure and repair distributions from your stop data, is $1,800 per user per year, and its Designer is free. The Sandbox and the desktop demo cost nothing. Every price is on the pricing page. #### Discrete rate, built for high-speed lines A discrete event model moves each unit through the line as its own event. On a line that makes hundreds of units a minute, that’s a great many events per simulated hour. ReliaSim uses discrete rate simulation, which models material as flow at rates and changes state only when a rate changes: a machine stops or restarts, or a buffer fills or empties. The work grows with the number of stops, not the number of units. A thousand one-year runs of the five-machine demo bottling line take about two and a half minutes on a laptop, or 0.154 seconds per simulated year. That speed is what makes sweeps practical: the buffer study behind how big should a buffer be? is 7,770 runs in 31.8 seconds. Discrete rate vs discrete event explains the difference in full. #### Validated before it predicts A published food plant model, from Fischel and Lange at the 2020 Winter Simulation Conference, was rebuilt in ReliaSim and independently validated by Tom Lange. It came within 1% of the plant’s measured OEE (the validation study). Every ReliaSim model follows the same order: reproduce the line’s own history, failure mode by failure mode, then ask what-if. How to check a digital twin’s accuracy claim sets out the test, for any vendor. #### Your data stays on your machine ReliaSim is desktop software for Mac and Windows. Models are files on the modeler’s own machine, and it works air-gapped. Security and deployment covers what IT usually asks. ### At a glance AnyLogicReliaSim Built forGeneral simulation across many domainsProduction lines and the supply chains they feed MethodsDiscrete event, agent-based, system dynamics; Fluid Library for bulk flowsDiscrete rate, with per-failure-mode reliability Building a modelA full modeling environment with custom logicA short vocabulary of constraints, converters, buffers and interrupts Published priceNo prices on the purchase page; quote form$8,000 per user per year, buy online Try itFree Personal Learning EditionBrowser Sandbox and desktop demo, no license key AnyLogic details from AnyLogic features, the Fluid Library page and the purchase page, read November 2026. ### Using both A team with an AnyLogic model of a wider system can still test a specific line decision in ReliaSim, where the line’s own stop data decides what the line will make, and feed that figure back into the bigger model. ### How to choose Start from the question. If it spans many kinds of system and you want to program the model, a multimethod platform is the direct route. If it’s about what a production line will really make, and what a change to it is worth, start with a model built from the line’s own stops and checked against its measured OEE. AnyLogic is referenced here for identification only; no affiliation or endorsement is implied. #### See a validated line model The bottling-line models in the Sandbox come with the engine’s saved results. There’s nothing to install and no sign-up. Open the Sandbox → Free line assessment --- # ReliaSim vs FlexSim: When Each Fits Source: https://reliasim.com/compare/reliasim-vs-flexsim.html ## ReliaSim® vs FlexSim 3D Process Simulation and a Rate-Based Line Simulator Comparison ## ReliaSim® vs FlexSim 3D Process Simulation and a Rate-Based Line Simulator FlexSim is 3D simulation software for modeling and improving almost any system or process. ReliaSim is built for production lines, especially high-speed ones, modeled as flow from each line’s own stop history. Both answer what-if questions before the real system changes. This page sets out where each fits. ### What FlexSim is built for FlexSim calls itself “3D Simulation Modeling and Analysis Software” and promises to help you “understand and improve any system or process” (FlexSim home page). It lists manufacturing, warehousing, material handling, supply chain, healthcare, airports and container terminals among its applications, with dedicated products for healthcare and container terminals. It presents its 3D view as a second level of validation, because people can see whether the model behaves like the real system. FlexSim is now an Autodesk product: the site is copyright Autodesk, and its free trial is offered through autodesk.com. ### Where FlexSim is the better fit - Layout and movement matter. Warehouses, material handling, AGVs and operators walking a floor are problems where space and travel decide the answer, and a 3D environment shows them directly. - Persuading people visually. A realistic 3D model is a strong way to win agreement for a layout change. - Systems beyond the line. Hospitals, airports and terminals are outside ReliaSim’s scope. ReliaSim doesn’t try to match FlexSim’s 3D environment or its range of applications. ### Where ReliaSim fits #### The price is on the page A ReliaSim desktop license is $8,000 per user per year, and you can buy it online. ReliaStats, the companion tool that fits failure and repair distributions from your stop data, is $1,800 per user per year, and its Designer is free. The Sandbox and the desktop demo cost nothing. Every price is on the pricing page. #### Discrete rate, built for high-speed lines A discrete event model moves each unit through the line as its own event. On a line that makes hundreds of units a minute, that’s a great many events per simulated hour. ReliaSim uses discrete rate simulation, which models material as flow at rates and changes state only when a rate changes: a machine stops or restarts, or a buffer fills or empties. The work grows with the number of stops, not the number of units. A thousand one-year runs of the five-machine demo bottling line take about two and a half minutes on a laptop, or 0.154 seconds per simulated year. That speed is what makes sweeps practical: the buffer study behind how big should a buffer be? is 7,770 runs in 31.8 seconds. Discrete rate vs discrete event explains the difference in full. #### Validated before it predicts A published food plant model, from Fischel and Lange at the 2020 Winter Simulation Conference, was rebuilt in ReliaSim and independently validated by Tom Lange. It came within 1% of the plant’s measured OEE (the validation study). Every ReliaSim model follows the same order: reproduce the line’s own history, failure mode by failure mode, then ask what-if. How to check a digital twin’s accuracy claim sets out the test, for any vendor. #### Your data stays on your machine ReliaSim is desktop software for Mac and Windows. Models are files on the modeler’s own machine, and it works air-gapped. Security and deployment covers what IT usually asks. ### At a glance FlexSimReliaSim Built for3D simulation of almost any system or processProduction lines and the supply chains they feed Strength3D layout, material handling and movementHigh-speed lines, buffers and per-failure-mode reliability EngineSimulation in a 3D environmentDiscrete rate: material as flow at rates Published priceNo price on flexsim.com when we read it$8,000 per user per year, buy online Try itFree trial through AutodeskBrowser Sandbox and desktop demo, no license key FlexSim details from the FlexSim home page and its links to Autodesk, read November 2026. ### Using both A layout study in a 3D tool and a throughput study in ReliaSim answer different questions about the same plant. One shows whether people and equipment fit and move well. The other shows what the line will make given its stops and buffers, and what each fix is worth. ### How to choose If the answer depends on space, travel and what people will see, start with 3D. If it depends on stops, buffers and line speed on a fast line, start with a rate-based model built from the line’s own stop data and checked against its measured OEE. FlexSim and Autodesk are referenced here for identification only; no affiliation or endorsement is implied. #### See a validated line model The bottling-line models in the Sandbox come with the engine’s saved results. There’s nothing to install and no sign-up. Open the Sandbox → Free line assessment --- # ReliaSim vs Simio: When Each Fits Source: https://reliasim.com/compare/reliasim-vs-simio.html ## ReliaSim® vs Simio A Digital Twin and Scheduling Platform and a Purpose-Built Line Simulator Comparison ## ReliaSim® vs Simio A Digital Twin and Scheduling Platform and a Purpose-Built Line Simulator Simio builds object-oriented, data-driven simulation models and extends them into planning and scheduling. ReliaSim is built for production lines and the supply chains they feed, modeled as flow from each line’s own stop history. This page sets out where each fits. ### What Simio is built for Simio says it “creates object-oriented, data-generated, and data-driven simulation models” and leads with “Intelligent Digital Twin Simulation” powered by Simio Discrete Event Simulation (Simio home page). Its products include the Simio Process Digital Twin, Advanced Planning & Scheduling (APS) and a DDMRP solution, with 3D visualization, Python integration and an NVIDIA Omniverse extension. Simio offers a “free, full-featured, time-limited” trial edition, and commercial use requires a purchased license (Simio commercial download). ### Where Simio is the better fit - Scheduling from the model. If you want the same model to produce detailed production schedules day to day, Simio’s APS is built for that. - Models generated from enterprise data. Building and refreshing large models from data tables and connected systems is central to Simio’s approach. - Demand-driven planning. Its DDMRP solution covers buffer positioning in the planning sense, which ReliaSim doesn’t address. - Many kinds of system. Simio is used across manufacturing, healthcare, warehousing and distribution. ReliaSim doesn’t try to be a scheduling system. ### Where ReliaSim fits #### The price is on the page A ReliaSim desktop license is $8,000 per user per year, and you can buy it online. ReliaStats, the companion tool that fits failure and repair distributions from your stop data, is $1,800 per user per year, and its Designer is free. The Sandbox and the desktop demo cost nothing. Every price is on the pricing page. #### Discrete rate, built for high-speed lines A discrete event model moves each unit through the line as its own event. On a line that makes hundreds of units a minute, that’s a great many events per simulated hour. ReliaSim uses discrete rate simulation, which models material as flow at rates and changes state only when a rate changes: a machine stops or restarts, or a buffer fills or empties. The work grows with the number of stops, not the number of units. A thousand one-year runs of the five-machine demo bottling line take about two and a half minutes on a laptop, or 0.154 seconds per simulated year. That speed is what makes sweeps practical: the buffer study behind how big should a buffer be? is 7,770 runs in 31.8 seconds. Discrete rate vs discrete event explains the difference in full. #### Validated before it predicts A published food plant model, from Fischel and Lange at the 2020 Winter Simulation Conference, was rebuilt in ReliaSim and independently validated by Tom Lange. It came within 1% of the plant’s measured OEE (the validation study). Every ReliaSim model follows the same order: reproduce the line’s own history, failure mode by failure mode, then ask what-if. How to check a digital twin’s accuracy claim sets out the test, for any vendor. #### Your data stays on your machine ReliaSim is desktop software for Mac and Windows. Models are files on the modeler’s own machine, and it works air-gapped. Security and deployment covers what IT usually asks. ### At a glance SimioReliaSim Built forProcess digital twins, planning and schedulingProduction lines and the supply chains they feed EngineDiscrete event, object-orientedDiscrete rate, with per-failure-mode reliability SchedulingAdvanced Planning & Scheduling productNot a scheduler; tests schedules and line changes Published priceNo price on the pages we read$8,000 per user per year, buy online Try itFree, time-limited trial editionBrowser Sandbox and desktop demo, no license key Simio details from the Simio home page and its commercial download page, read November 2026. ### Using both A plant that schedules in one system can still test a line change in ReliaSim first: what a new buffer, a faster machine or a fixed failure mode returns, given the line’s own stop history. The schedule then runs on a line whose real capacity is known. ### How to choose If you need the model to run the plant’s schedule every day, start with a scheduling platform. If you need to know what a production line will really make, and what each fix is worth, start with a model built from its stops and checked against its measured OEE. Simio is referenced here for identification only; no affiliation or endorsement is implied. #### See a validated line model The bottling-line models in the Sandbox come with the engine’s saved results. There’s nothing to install and no sign-up. Open the Sandbox → Free line assessment --- # ReliaSim vs Plant Simulation: When Each Fits Source: https://reliasim.com/compare/reliasim-vs-plant-simulation.html ## ReliaSim® vs Plant Simulation A Factory-Wide 3D Platform and a Purpose-Built Line Simulator Comparison ## ReliaSim® vs Plant Simulation A Factory-Wide 3D Platform and a Purpose-Built Line Simulator Siemens Tecnomatix Plant Simulation models, simulates and analyzes production systems and logistics, with 3D models, energy and cost analysis and optimization. ReliaSim is built for production lines, especially high-speed ones, modeled as flow from each line’s own stop history. This page sets out where each fits. ### What Plant Simulation is built for Siemens describes Plant Simulation as software to “model, simulate, visualize and analyze production systems and logistics processes” (Plant Simulation product page). It builds object-oriented, hierarchical 3D models of plants and lines, from included libraries or CAD data, and covers discrete and continuous processes. Its analysis tools include automatic bottleneck detection, throughput, utilization of machines, resources and buffers, energy consumption, cost analysis, Sankey diagrams and Gantt charts. Optimization uses experiment management, neural networks and genetic algorithms, and it connects through OPC UA, MQTT, ODBC, JSON and XML and to other Siemens tools. Plant Simulation X comes in three preconfigured packages and has a 30-day free trial (plans page). ### Where Plant Simulation is the better fit - A Siemens digital factory. If your engineering already runs on Teamcenter and TIA Portal, a simulation tool in the same family has obvious advantages. - Factory-wide logistics and layout. Material flow across a whole plant, in 3D from CAD, is its core use. - Energy and cost alongside throughput. Energy consumption and cost analysis are built in. - Connected systems. Its industrial interfaces suit teams linking the model to automation and shop-floor data. ReliaSim doesn’t try to match that factory-wide scope. ### Where ReliaSim fits #### The price is on the page A ReliaSim desktop license is $8,000 per user per year, and you can buy it online. ReliaStats, the companion tool that fits failure and repair distributions from your stop data, is $1,800 per user per year, and its Designer is free. The Sandbox and the desktop demo cost nothing. Every price is on the pricing page. #### Discrete rate, built for high-speed lines A discrete event model moves each unit through the line as its own event. On a line that makes hundreds of units a minute, that’s a great many events per simulated hour. ReliaSim uses discrete rate simulation, which models material as flow at rates and changes state only when a rate changes: a machine stops or restarts, or a buffer fills or empties. The work grows with the number of stops, not the number of units. A thousand one-year runs of the five-machine demo bottling line take about two and a half minutes on a laptop, or 0.154 seconds per simulated year. That speed is what makes sweeps practical: the buffer study behind how big should a buffer be? is 7,770 runs in 31.8 seconds. Discrete rate vs discrete event explains the difference in full. #### Validated before it predicts A published food plant model, from Fischel and Lange at the 2020 Winter Simulation Conference, was rebuilt in ReliaSim and independently validated by Tom Lange. It came within 1% of the plant’s measured OEE (the validation study). Every ReliaSim model follows the same order: reproduce the line’s own history, failure mode by failure mode, then ask what-if. How to check a digital twin’s accuracy claim sets out the test, for any vendor. #### Your data stays on your machine ReliaSim is desktop software for Mac and Windows. Models are files on the modeler’s own machine, and it works air-gapped. Security and deployment covers what IT usually asks. ### At a glance Plant SimulationReliaSim Built forProduction systems and logistics across a plantProduction lines and the supply chains they feed ModelsObject-oriented, hierarchical 3D, from libraries or CADA short vocabulary of constraints, converters, buffers and interrupts AnalysisBottlenecks, throughput, utilization, energy, cost; genetic-algorithm optimizationBottlenecks, buffer sizing, and what each failure mode costs the line Published priceThree packages; no prices on the plans page when we read it$8,000 per user per year, buy online Try it30-day free trialBrowser Sandbox and desktop demo, no license key Plant Simulation details from the Siemens product page and plans page, read November 2026. ### Using both A plant modeled end to end in a factory platform can still send one line’s question to ReliaSim: what a buffer, a speed-up or a fixed failure mode returns, given that line’s own stop history, with replications cheap enough to show the spread. ### How to choose If the question spans a whole plant’s logistics, layout and energy, and you work in the Siemens ecosystem, a factory platform is the direct route. If it’s about what a production line will really make and what each fix is worth, start with a model built from the line’s stops and checked against its measured OEE. Siemens, Tecnomatix and Plant Simulation are referenced here for identification only; no affiliation or endorsement is implied. #### See a validated line model The bottling-line models in the Sandbox come with the engine’s saved results. There’s nothing to install and no sign-up. Open the Sandbox → Free line assessment --- # Production Simulation Case Studies Source: https://reliasim.com/case-studies.html Case Studies ## Case Studies Real Lines, Real Numbers, Published Where We Can Production systems modeled with the rate-based approach that became ReliaSim®. Most began as a capacity planning question about what to buy and where the real constraint sat. Where the work was published, we link the paper so you can read it for yourself. IndustryAllFood & beveragePackaging & CPGChemicalsElectronics & automotive Used forAllCapacity & capitalFinding the bottleneckOEE improvementBuffers & decouplingSchedulingSupply chain Food & beverageFinding the bottleneckWorked example ### How a bottling line finds $1.5M in hidden throughput Two failure modes show identical downtime on the loss report. Fixing the bigger one returns less than it costs, while fixing the smaller one returns 62% more. Read the worked example → Food & beverageOEE improvement ### More Salad Dressing Without Another Line Demand for a national brand of salad dressing is rising. A plant model built from its own downtime records, matched to a year of actual OEE within 1%, finds many small fixes worth many points of OEE. Rebuilt in ReliaSim, it runs roughly 1200× faster. Fischel & Lange · open access → Food & beverageCapacity & capital ### Growing an Olive Plant’s Output Sales are rising and the whole crop arrives in six weeks. A full-plant model shows what the plant can handle, and scheduling rules tested in it raise throughput 15% without new equipment. Olive packer · published paper → Packaging & CPGOEE improvement ### Modeling Every Failure Mode at Once A consumer-products maker with hundreds of failure modes on every line models them all together. Productivity rises up to 44% and savings pass $2 billion, by the company’s figures. It is the approach ReliaSim is built on. Read the case study → Packaging & CPGCapacity & capital ### Consolidating a Soap Maker’s Plants Into One A soap maker is consolidating several plants into one making 300+ products. A whole-plant model shows the planned machine assignments would cause a quality problem, and other routings avoid a $4 million retrofit. Read the case study → ChemicalsBuffers & decoupling ### Weighing New Bag Lines Against Overtime At a specialty chemicals plant, each bag line is tied to one bulk production line. A ten-year model weighs the configurations against overtime, including short-term storage between the two, and turns up low-capital options for growth. Specialty chemicals · client quote → Food & beverageScheduling ### The Cereal Plant That Runs Its Model Before Every Shift A major cereal maker’s planners run a model of their make-store-pack plant before each shift to see what could go wrong, and change the plan first. The pieces built for it are standardized as our Plant Builder library. Cereal plant · shift model → Food & beverageBuffers & decoupling ### Sizing Grit Storage Between a Cereal Plant’s Cookers and Ovens Stabilizing partially cooked corn grit decouples a cereal plant’s cookers from its toasting ovens. The modeled configuration gives 19.8% more effective production in peak periods with no new capacity, and you can run the model in a browser. Run the simulator yourself → Food & beverageCapacity & capital ### From a Snapshot to a Video A major food manufacturer moves production decisions from spreadsheets to a dynamic model. It runs six months of data in minutes and returns results in as little as 15. Company-wide, its simulation manager estimates $5 million saved across 40 models. Food manufacturer · published article → Electronics & automotiveSupply chain ### Forecasting New-Vehicle Flow Across a Continental Network A rail and truck network moving 2.5 million vehicles a year is simulated every week from where every vehicle actually is. One set of recommendations saves $21.7M in carrying costs and cuts transit time 19%. Vehicle-logistics company · published paper → Packaging & CPGSupply chain ### Postponement: Choosing Where to Pack and Where to Hold Cycle Stock A consumer goods maker runs bulk on cycles of up to 91 days, then packs it early and allocates it on a forecast. Moving packing downstream pays off for some product categories but not others, and cycle stock belongs at the plants. Read the case study → Electronics & automotiveSupply chain ### Sizing Overseas Capacity Before the Peak Is Known An electronics maker has to commit overseas component capacity months ahead for a two-year product. A model crosses three capacity levels with three sales outcomes, and even a correct forecast calls for a moderate prebuild at the peak. Read the case study → Food & beverageFinding the bottleneck ### A Brewpub Plans Kegging and Bottling Either new line would overrun the fermenting and serving tanks unless more tank capacity goes in too. The model shows it before the equipment is bought. Published paper → ### On attribution Most of this work predates ReliaSim as a product. Our team did it with the same method ReliaSim now packages, and each page says which tool ran the model. Where an account rests on our project record rather than a published paper, the page says so. We describe each client by its business, not its name. The software in the Sandbox didn’t produce these results. The same method now runs a thousand one-year simulations of the Buffer-Options bottling demo line in about thirty seconds. Looking for the explanations rather than the examples? Those are in the guides. --- # OEE Simulation Validated Within 1%: Food Plant Case Study Source: https://reliasim.com/case-studies/published-oee-validation.html ## More Salad Dressing Without Another Line A Plant Model That Matches Its OEE to Within 1% Case Study · Food & beverage ## More Salad Dressing Without Another Line A Plant Model That Matches Its OEE to Within 1% Demand for a national brand of salad dressing is rising, and the plant needs more output. New lines are expensive and slow to arrive, so the team looks for the capacity in the equipment it already has. They build a simulation from the plant’s own downtime records and check it against a year of real performance. Then they use it to decide which fixes are worth making. The model finds many small improvements that together add many points of OEE, and it changes how the operators work. The businessA household-products company’s salad dressing plant · several products, process and packaging lines The questionHow much more can we make without adding a line? The model20+ unit operations, up to 20 failure modes each Checked againstA year of the plant’s actual OEE, within 1% OutcomeMany small fixes, many points of OEE; two machines flagged for redundancy ### What the plant is up against Demand is climbing, and a sudden surge pushes it higher still. Some of the plant’s lines run below industry benchmark OEE. A new line means a large capital bill and a long lead time. The company’s own engineering team and consultant Tom Lange set out to find how much more the existing equipment can make, and which changes will get it there. The work is published as a Winter Simulation Conference paper. ### How the model is built The plant already records every stop and start on its lines. From those records the team works out how long each machine runs before each kind of failure, and how long each failure takes to clear. They do this for every product category. That comes to up to twenty failure modes on each of more than twenty unit operations, about four hundred in all. They fit a distribution to each failure mode in JMP. Then they build a discrete rate and reliability model of the plant in ExtendSim, using the real tank volumes, conveyor speeds and buffer sizes. Plant operators help map the model to the equipment and help test it. The detail matters because each machine’s failure modes sit inside that machine, and the buffers between machines decide how a stop on one spreads to the rest. That’s why multiplying machine availabilities understates what a buffered line produces (more in reliability block diagram vs simulation). The paper puts it this way: “Had an averaged, single-failure-mode-per-unit-operation approach been followed, the gains and losses would be less accurate and essentially identical to each other.” — Fischel & Lange, Winter Simulation Conference ### Checking it against the plant Before anyone uses the model for a decision, a one-year simulation has to land within 1% of the plant’s actual OEE for each product category, and it does. The check also compares observed and simulated availability for each failure mode, not only the total. A single overall number can be right for the wrong reasons, with one mode overstated and another understated. Checking every mode separately rules that out. ### What the model shows For every machine and failure mode, the team compares two numbers. One is the availability it costs on paper. The other is what the whole plant gains in the simulation when that loss is removed. Where the whole-plant gain is bigger than the loss, that fix is worth doing first. - Two machines are worth doubling up. The Case Erector and the Palletizer affect the whole plant enough to justify looking at a second machine for each. - Some fixes need no capital. On the Labeler, at least two failure modes have high leverage, and closer attention from the operators can address them. - Buffer can beat reliability. More conveyor space at one point shields the rest of the plant from the less reliable section beside it. Where there’s floor space, more buffer can cost less than making equipment more reliable. - Faster is better, up to a point. Running faster makes machines fail more often, but throughput still rises until it reaches an optimum speed. - Short stops aren’t harmless. Frequent, brief stoppages look minor, but the linked line magnifies each one. No single machine is the answer. The gain comes from many small improvements, which together add “many points of %OEE,” in the paper’s words. The model also lets the team weigh staffing, capital and material changes against each other. ### What changes on the floor The operators can see on screen how their own actions move the whole line. The paper reports that this makes them more vigilant and gives them more ownership of the improvements. It also builds enthusiasm and commitment for the improvement work. ### The same model in ReliaSim® The published model is rebuilt in ReliaSim and independently validated by Tom Lange. It comes in within 1% of both the plant’s measured OEE and the original ExtendSim model. On the same laptop, over the same one-year run, the ReliaSim model runs roughly 1200× faster. See ReliaSim vs ExtendSim: the same validated model in both engines. Speed changes how a study like this one runs. If a one-year run takes all night, you test a few scenarios picked in advance. When it takes seconds, you can test every failure mode and every buffer size. The buffer sweep behind How big should a buffer be? is 7,770 runs. ### About the source This case study is built on a published, peer-reviewed paper written by the plant’s engineering team and Tom Lange, at his own consulting practice. The paper is two pages and open access, so you can read it for yourself. It’s also the featured case study on ExtendSim’s own reliability block diagram page. Both tools use discrete rate engines from the same inventor. ReliaSim is the third generation, rebuilt from scratch (lineage and comparison). ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Bottling Line Simulation Case Study Source: https://reliasim.com/case-study.html Case Study · Worked example ## How a bottling line finds $1.5M in hidden throughput The fix the Loss Tree pointed to recovered less throughput than the loss it removed. The fix ReliaSim® found, ranked lower on the Pareto, recovered 62% more. 54.3% Baseline OEE 15 min Model built in 5 Machines modeled ### The line This is a high-speed bottling line with five machines: Filler, Capper, Labeler, Case Packer, and Palletizer. It runs 90-day production cycles at a nominal rate of 60 bottles per minute per machine, and historian data is available for all machines. The production team tracked OEE at 54.3%. Multiplying the five machines’ availabilities predicts 46.7%, because that math ignores the buffers between them. ### Two failure modes that looked the same Two failure modes appeared nearly equal in the Loss Tree: Labeler Misalignment 6.79% Direct efficiency loss Infrequent, longer stops. The Loss Tree says to fix this first. Filler Micro Stop 6.72% Direct efficiency loss Frequent, short stops. The Loss Tree gives it about the same priority. The direct losses are similar, so your Pareto ranks them equally. Most CI teams would fix the Labeler first because it's the bigger single event. ### What the simulation finds ReliaSim modeled the full line with interrupt distributions fitted in ReliaStats. The method behind it has a published validation on a real plant. We then removed each failure mode one at a time and re-ran the whole line. Efficiency Gain/Loss: evaluate each interrupt, one at a time ### What each fix actually recovers Labeler: fix the big event 0.73× Loss 6.79% → Gain +5.0 pp You recover less than you lost. The line absorbs the rest. Filler: fix the micro stops 1.21× Loss 6.72% → Gain +8.1 pp This fix recovers 62% more. Removing it also removes the losses it was cascading into the machines downstream. The Labeler fix meant $400K of alignment tooling. The Filler fix was a $50K intervention (automated jam clearing). On a $50M/year line, following the Loss Tree instead of the simulation leaves $1.5M on the table. The same loss/gain report on the Buffer-Options demo line that ships with the product. It’s a different line, so the numbers differ. The run covers 90 days with ten replications. Blue is the loss and orange is the gain, and Labeler_Misalignment reads Loss 6.67%, Gain 4.85%. More in Which of the six big losses to fix first. ### Why the same downtime can cost different amounts Two weeks with the same 120 minutes of downtime Two failure modes, one production week each. Running Stopped Timing belt1 stop × 120 min Bottle jams120 stops × 1 min day 1day 2day 3day 4day 5day 6day 7 Each jam lasts one minute. It’s drawn at a minimum width so it stays visible at this scale. What the loss report records Timing belt 120 minutes Bottle jams 120 minutes The two records are identical, with the same tier and the same priority. A simplified example, not a simulation result. Each of the 120 one-minute micro stops blocks and starves the machines around it. The damage lands as idle time on the Labeler, Case Packer and Palletizer rather than under the Filler’s name (see line OEE vs machine OEE). "Those 120 one-minute interruptions are creating cascading problems throughout your system that don't show up under the original problem's name. When you eliminate them, you often recover 180–220 minutes of uptime — significantly more than the original downtime suggests." — Tom Lange, 36 years in manufacturing R&D ### Other plants that find the same thing A specialty olive packer simulates a full harvest year of its plant and finds 15% more throughput by testing scheduling rules before buying equipment. At a major food manufacturer, a model built to confirm that conveyors would beat manual carts from dryer to packaging shows productivity would fall. Across forty models, the return comes to $5 million, with $3 million of it from scrapping projects that would have been counterproductive. Related: Which Loss to Fix First · The Hidden Factory · Starved vs Blocked · Why Simulation Belongs in the Capital Plan · All guides ### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Reliability Simulation of Every Failure Mode: Case Study Source: https://reliasim.com/case-studies/every-failure-mode-at-once.html ## Modeling Every Failure Mode at Once A Consumer-Products Maker Saves Billions Case Study · Packaging & CPG ## Modeling Every Failure Mode at Once A Consumer-Products Maker Saves Billions A global consumer-products maker runs extremely complicated production lines. Each line has hundreds of ways to stop, and the company collects mountains of stop data without knowing what it says. Reliability engineers and statisticians build models that handle every failure mode at once, then use them to decide what to fix, how to maintain it and how to run the line. By the company’s own figures, plant productivity rises up to 44% and savings pass $2 billion. It is the approach ReliaSim® is built on. The businessA global consumer-products maker · lines making consumer paper products, in plants worldwide The questionWith hundreds of failure modes on every line, which ones matter, and what should engineers do about them? The modelStatistical reliability models of every failure mode together, built from the lines’ own stop data What it is worthUp to 44% more plant productivity; more than $2 billion saved, by the company’s figures SourcePublished accounts of the project ### Data rich, knowledge poor The company’s lines make consumer paper products. Their automated systems routinely collect loads of reliability data, far more than anyone can read. By the company’s own admission it is “data rich but knowledge poor”: overwhelmed by the volume, it can’t tell what the data contains. The hard part is the number of ways a line can stop. “Their manufacturing processes literally had hundreds of failure modes, all of which they wanted to simultaneously model.” Harry Martz, reliability statistician on the project Looking at one failure mode at a time doesn’t answer the question. On a line, failure modes compete: while one has the machine down, the others aren’t wearing, and a stop on one machine idles the machines around it. What a fix is worth depends on all the others. ### How it is modeled The company’s reliability engineers work with a team of statisticians under a cooperative research agreement. Together they build reliability models that take in every failure mode on a line at the same time, fitted from the stop data the plants already collect. The models learn and adapt as new data comes in from running lines. The work becomes a software tool for the plants. With it, engineers set up both the machines and their maintenance schedules around reliability. They can see product jams, component breakages and machine speed variations coming, and sometimes avoid them. In some cases they rearrange how product flows through the line. ### What it is worth By the company’s figures, the methods: - increase plant productivity by up to 44% - cut controllable costs by up to 33% - improve equipment reliability by 30% to 40% - cut line changeovers from as much as an hour to as little as six minutes - make new equipment and product start-ups 60% to 70% faster - save the company more than $2 billion The company runs the method at all of its plants worldwide. The work wins an R&D 100 Award and a Council for Chemical Research collaboration award. ### Where ReliaSim comes in ReliaSim is built on the same idea: model every failure mode of every machine from the line’s own stop history, together, and let the simulation show what each fix is really worth. ReliaSim adds what a reliability model alone can’t show: the line itself, with its rates, buffers and converters, so stops on one machine starve and block the others the way they do on the floor. One of the reliability engineers on this work later checked ReliaSim’s approach against a real plant and found it matches measured OEE within 1%. To see it on a line, play Beat the Bottleneck: 36 interrupts from a real line’s history, and one move to beat its line efficiency. ### Where this work comes from The project is described in a national laboratory’s news release, “From detonation to diapers”, on its computer codes in advanced manufacturing; in an ExtendSim case study; and in an interview with the project’s lead statistician in Statistical Science (“A Conversation With Harry Martz”), which gives the figures above as the company reported them. Reliability models of every failure mode at once, built from the plants’ own stop data · sources: national laboratory news release, ExtendSim case study, Statistical Science interview. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Plant Consolidation Simulation: Soap Plant Case Study Source: https://reliasim.com/case-studies/soap-plant-consolidation.html ## Consolidating a Soap Maker’s Plants Into One The Model Catches a $4 Million Quality Problem First Case Study · Packaging & CPG ## Consolidating a Soap Maker’s Plants Into One The Model Catches a $4 Million Quality Problem First A household-products manufacturer is moving its soap production from several plants into one facility that will make over 300 products. Its logistics manager needs to know whether the plan will work once demand, product mix, breakdowns and schedules all come into play. A simulation of the whole plant shows that the planned machine assignments would hold some products in the system too long and cause a quality problem. Other routings, tested in the model, avoid it and the $4 million retrofit it would need. The businessA household-products manufacturer · soap plants consolidated into one, 300+ products The questionWill the consolidated plant work, given how demand, mix and equipment vary over time? The modelThe whole plant, run from multi-stage production schedules What it is worth$4 million retrofit avoided; simulation required before major capital spending Sourceour project sheet ### What the plant is up against The company is collapsing manufacturing from multiple sites into a single optimized facility. Between them, the existing sites make over 300 different products, and the new plant has to absorb all of them. Whether the plan is feasible depends on equipment design and sizing together with how the plant will be run. It also depends on conditions that change over time: - Variable demand and seasonality - Product mix - Breakdowns and equipment variability - Crewing patterns - Product run sequencing The logistics manager chooses simulation to see how these play out together and to understand the plant as a whole. It wins over other analysis tools because it captures real-world variability and the way events in one part of the plant affect another. A spreadsheet can size a machine, but it can’t show what happens when a seasonal peak, a changeover sequence and an unreliable upstream stage land in the same week. ### How it is modeled The manager partners with our team to build a model of the entire plant. It uses discrete rate technology, which is built for high-volume processes. An embedded database feeds the model the dynamic factors that affect throughput. Production schedules are defined in multiple sequential stages, and the model plays them out across every line. The plant view shows the status of all lines as the schedule ran: blocking and starving, changing over, emptying and surge. Each line opened into a more detailed sub-model nested inside it. The model of the whole plant, from the project, showing the status of every line as the production schedule plays out. Making lines feed a bank of surge tanks, then the packing lines, and finished cases run to the warehouse. The legend covers the flow states blocked, satisfied, starved and rate = 0, and control states for running, emptying and changing over. Packing 3 is mid-changeover in this frame. ### What the model shows Running the model gives the team confidence in the consolidation strategy. It shows the balance of the plant and gives the optimal buffer size between processing and packaging. The costliest finding is about time in system. For a given set of products, the planned machine assignments would leave material in the system too long, and for these products excess time in system means a quality problem. One configuration shows severe long-term quality problems that would require a $4 million retrofit. The team tests other product routings and machine assignments in the model and shows how to avoid the problem, so the retrofit is never needed. One line opened up: the detailed sub-model nested inside its node on the plant view above. It holds the containers, filler, sealer, conveyor and case packer. ### What changes The project changes how the company spends capital. It requires a simulation study before committing to any major capital expenditure. The logistics manager then widens the simulation’s scope to the supply and distribution policies across the division. ### Where this work comes from The project is recorded in our project sheet, “Soap Manufacturer Saves Over $4 Million.” Built by our team, built in ExtendSim and rebuilt in ReliaSim, with an embedded database for the dynamic factors and multi-stage sequential schedules · source: our project sheet. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Brewery Capacity Expansion: Simulation Case Study Source: https://reliasim.com/case-studies/microbrewery-expansion.html ## A Brewpub Plans Kegging and Bottling The Tanks, Not the New Lines, Set the Limit Case Study · Food & beverage ## A Brewpub Plans Kegging and Bottling The Tanks, Not the New Lines, Set the Limit A brewpub wants to add kegging and bottling equipment to sell its beer off-premise, and it expects sales to grow, which means significant capital. A model of the brewery shows that either line would overrun the fermenting and serving tanks unless more tank capacity goes in too. After comparing several simulated scenarios, management is more confident about the return on the investment. The businessA brewpub with its own brewhouse, fermenting and serving tanks The questionCan the brewery keep up if it adds kegging or bottling, and is the capital worth it? The modelBulk flow through every tank, with ale and lager times and costs tied to each change What it is worthFound the tank shortfall before the purchase; more confidence in the return SourcePublished paper, Andrew J. Siprelle ### What the brewery is up against Craft brewers often start as brewpubs, selling on the premises for a quick return. As they succeed, they add kegging and bottling to sell their own brands off-premise, and some take on contract brewing for other breweries. Growing that way calls for a more flexible operation that can switch quickly between flavors and packages. Beer moves through a chain of tanks. Grain and hot water are mashed in the mash/lauter tun, and the wort goes to the kettle for hops and a boil, then to a whirlpool to clear out solids. It’s cooled through a heat exchanger into one of several fermenting tanks. After fermentation the yeast is blown down, and the beer ages in the same tank for days. It’s then filtered into a serving tank that feeds the bar, a kegging line or a bottling line. Each beer spends very different amounts of time in those tanks. Ales ferment for about 5 days and age about 5 more. Lagers ferment for about 10 days and can age for as long as 14. In this brewpub about 18 barrels of wort go into the kettle, and about 14.5 barrels reach a serving tank after evaporation. The schedule has to meet demand and fit the labor available. It also has to keep each beer separate and leave time to sanitize the pipes and hoses between them. Adding kegging and bottling makes that puzzle harder. The brewery needs answers to five questions: - Can the brewing equipment keep up with both off-premise and on-premise sales? - Is it wise to spend capital on kegging or bottling? - How should labor be scheduled for brewing, kegging and bottling? - What’s the best sequence for the different flavors? - How much extra storage is needed for kegging and bottling? ### How it is modeled Beer is a fluid, so the model tracks rates of flow and tank levels rather than individual items. Pumps, tanks with setpoints and branching paths define the routes. Control logic attached to each tank chooses which tank to fill or draw from, shuts off flow for schedules, maintenance and changeovers, and holds beer for its fermenting and aging time. This rate-based approach keeps a bulk process model fast enough to run many scenarios. A database inside the model ties each beer to its process data, and a central control panel sets up and runs the experiments. Adding another fermenting or serving tank is a matter of dropping in one more block. Cost and revenue are linked to the process changes, so each scenario shows its financial result along with its operating one. ### What the model shows The new kegging and bottling equipment, together with the expected sales growth, needs more storage than the brewery thought. The brewing steps in the mash/lauter tun and kettle are short. Fermenting and aging take so much longer that the brewery would need more fermenting and serving tanks to keep serving a variety of beers. The tank utilization trace shows that installing either a kegging line or a bottling line would overrun the fermenting and serving tanks unless capacity is added there too. That’s hard to see by looking at the plant, where the lines under discussion look like the equipment that will decide throughput. The model shows that the time beer spends in tanks sets the limit. ### What changes The capital plan has to cover more fermenting and serving tanks, not only the packaging lines. Because the model ties cost and revenue to each change, management can compare the financial and operating results of several scenarios before spending. In the paper’s account, that leaves management more confident about the return on the investment. Testing a capital plan this way is what capacity planning simulation is for. ### Where this work comes from Built by our team, built in ExtendSim and rebuilt in ReliaSim. The bulk flow blocks come from several years of modeling in food and consumer products, adapted for this brewery. Evidence: Modeling a Microbrewing Facility Using Discrete Event Simulation (PDF), Andrew J. Siprelle. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Decoupling Buffer Sizing: Cereal Plant Simulation Case Study Source: https://reliasim.com/case-studies/cereal-decoupling.html ## Sizing Grit Storage Between a Cereal Plant’s Cookers and Ovens 19.8% More Effective Production at Peak, With No New Cooker or Oven Case Study · Food & beverage ## Sizing Grit Storage Between a Cereal Plant’s Cookers and Ovens 19.8% More Effective Production at Peak, With No New Cooker or Oven A food-process technology developer has a patented way to shelf-stabilize partially cooked corn grit, so a cereal plant can store it and flake it later. That means a plant doesn’t have to hold its cookers back to whatever the toasting ovens can take. Before a cereal maker will invest, someone has to size the system: how many off-ramps and on-ramps, and how much storage. Our team and the developer build a discrete-rate model of the process to answer that. The modeled configuration gives 19.8% more effective production during key demand periods, with no new cooking or oven capacity. The businessA food-process technology developer with a corn grit reconstitution technology, and its cereal-maker customers The questionHow should the off-ramp, storage and on-ramp be sized, and what is the system worth? The modelCooking, grit stabilization, in-process storage and reconstitution, run over a year of production What it is worth19.8% more effective production in key demand periods, from one off-ramp and one on-ramp Sourceour project record · live model you can run ### What the plant is up against In flaked-cereal production, corn grits are cooked, dried, flaked and toasted, then packed. Those stages are physically tied together. If the toasting ovens can’t take what the cooker is making, the cooker slows down. During peak demand that costs real output on equipment the plant has already paid for. The usual fixes all take capital. A plant can add oven capacity, add a cooker, or add conventional wet storage. For a partially cooked product, wet storage brings a shelf-life problem of its own. ### The technology the developer brings The developer holds patented technology that shelf-stabilizes partially cooked corn grit. Processing can pick up later, even at a different location. Picking the grit back up is called reconstitution. In the plant it works in three stages: - Off-ramp. Excess production goes to a dryer that stabilizes the grit to roughly 10–11% moisture. - Store. The stabilized grit goes into totes. At this point the two halves of the line are decoupled. - On-ramp. When oven capacity frees up, a module reconstitutes the stored grit and feeds it back into production. A conventional buffer decouples two stages only as long as the material can sit there, and partially cooked grit can’t sit for long. Stabilizing it stretches a buffer measured in minutes into one measured in weeks. The cooker can run through a peak, and the toasting ovens can catch up afterward. The developer sees this as a way for cereal makers to find more production capacity without building it, with possible savings in the tens of millions of dollars across the industry. Customers need to see what it means for their own plants first. ### Why sizing it needs a model Intuition can’t answer the sizing questions. Run the off-ramp too eagerly and the plant pays to dry grit the ovens could have taken anyway. Run it too cautiously and the cooker still throttles. The right size depends on how the demand pattern, the changeover schedule and the reliability of both halves of the line play out together over a full year. ### How it is modeled Our team and the developer build a discrete-rate simulation of the process and wrap it in a web application. The app uses the plant’s terms, not the simulator’s. Its inputs cover cooking, grit stabilization for off-ramping, in-process grit storage, and reconstitution and on-ramping. Its results show what each configuration does to inventory and production capacity. ### What the model shows The modeled configuration has one off-ramp and one on-ramp, with no new cooker or oven capacity. It gives 19.8% more effective production during key demand periods. Running the simulation across a range of conditions shows the throughput gain can be reached with high confidence. The 19.8% is a peak-period figure, not an annual average. Decoupling pays when the line is demand-constrained and the cookers and ovens disagree. In a slack period there’s nothing to store and nothing to recover. ### What changes The model lets the developer design and size the system to run over a range of conditions before a customer commits. The developer then uses the cloud version to explore the options with customers, on their own production data. Neither side has to be a simulation modeler. The model is live. The Decoupling System Simulator runs in a browser, and you can set the configuration and run annual production scenarios yourself. ### Where this work comes from Built by our team, with the technology developer, as a web application on the ReliaSim discrete-rate engine · evidence: our project record and the live model. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Postponement Simulation: Pack at the Plant or the DC? Source: https://reliasim.com/case-studies/pack-at-plant-or-dc.html ## Postponement: Choosing Where to Pack and Where to Hold Cycle Stock Packing at the DCs Pays for Some Product Categories, and Cycle Stock Stays at the Plants Case Study · Packaging & CPG ## Postponement: Choosing Where to Pack and Where to Hold Cycle Stock Packing at the DCs Pays for Some Product Categories, and Cycle Stock Stays at the Plants A consumer goods manufacturer makes bulk product on cycles as long as 91 days and packs it at the plant. Every run becomes a large block of finished goods, allocated to items and distribution centers on a forecast. The company wants to know whether packing at its major distribution centers would do better, and where cycle stock should sit. A model of the network shows that packing downstream cuts finished-goods inventory and ends redeployment between distribution centers while holding customer service. For many product categories, though, the new bulk inventory offsets those gains, and the model shows which categories those are. Cycle stock is most cost-effective held at the plants. The businessA consumer goods manufacturer with plants and major distribution centers The questionShould packing move to the distribution centers, and where should cycle stock sit? The modelTwo network models on historical forecast, demand and production rates, scored product by product What it’s worthA product-by-product answer on where downstream packing paid, instead of one network-wide call Sourceour project record · original model output ### What the company is up against The plants make bulk material on cycles of 7, 14, 28 or as many as 91 days. Each production run is allocated straight away to packaging runs of finished items. Packing at the plant turns every long run into a large block of finished-goods cycle stock, and the forecast decides which item and which distribution center each case goes to. When the forecast is wrong, the cost shows up twice. Bulk is packed into the wrong items, and finished goods go to the wrong distribution centers and have to be redeployed between them. Product that ages too long is disposed of. The company is weighing postponement: ship bulk to its major distribution centers and pack there, closer to demand. It also wants to know whether each run should be pushed out to the distribution centers or held at the plant. ### How it’s modeled Our team builds two related models on the same inputs, historical forecast and demand plus production rates by system and product. One tested where packing should happen. The other tested where cycle stock should sit. QuestionAlternativesExperiment factors Where should packing happen?Pack at the plant, or ship bulk to the distribution centers and pack there weekly against next week’s local forecastReorder policy; which product categories to pack downstream Where should cycle stock sit?Push each run out to the distribution centers, or hold it at the plant until a distribution center reordersReorder policy; which product categories to push downstream Both models report total inventory, customer order fill rate, redeployment cost and the cost of disposing of aged product. The cycle stock model also splits inventory into finished goods and bulk. The two packing scenarios, and original model output from one item: cycle stock on a two-week production cycle (top) and the customer-facing inventory it feeds under daily pull ordering (bottom). ### What the model shows #### Packing downstream helps some categories and not others Packing weekly at the distribution center, against that location’s own forecast for the next week, almost eliminates finished-goods cycle stock. It ends redeployment of finished product between distribution centers, and customer service holds. The price is bulk inventory at the plants and at every distribution center. Pack at the plantPack at the distribution center GainsNo bulk inventory anywhere; it becomes finished items as it’s madeFinished items packed weekly close to demand, which limits the damage from forecast error. No redeployment between distribution centers. CostsBulk allocated to items on a forecast, and items allocated to distribution centers on a forecast. Misallocation means redeployment.Bulk inventory at plants and at every distribution center, which can raise total inventory cost For many product categories, the new bulk inventory offsets the gains. For others it doesn’t. The model lays out the trade product by product, so the answer isn’t simply “pack downstream” or “don’t.” #### Pushing cycle stock downstream backfires when it’s misallocated Pushing each run out to the distribution centers looks protective, because the extra stock backs up their safety stock. But a misallocated run leaves some distribution centers short while others hold plenty, and redeployment between them isn’t always feasible. The locations that run out early trigger the next production run early. Hold cycle stock at the plantPush cycle stock downstream GainsLess redeployment for high-variability products; fewer early production triggersCycle stock at the distribution center protects its safety stock CostsSafety stock at the distribution centers gets no help from cycle stockMisallocation leads to redeployment and early production triggers The team concludes it’s most cost-effective to keep all cycle stock upstream at the plants and fill the distribution centers on a pull basis. That includes the bulk material shipped downstream for packing. Original model output, all plants and all products for one scenario. The top chart tracks sales, forecast and inventory; the bottom tracks the share of demand that goes unfilled, is redeployed or is disposed of. The same view is available for one plant, one category, one brand or one finished item. ### What else the model settled #### An adjusted textbook safety stock formula holds up Packing on a fixed weekly schedule changes how much safety stock a location needs. The baseline safety stock calculation, modified for that weekly schedule, accurately predicts the safety stock the model needs at the customer-facing inventories. #### Capacity shortfalls have a set order of response When a plant can’t keep up with demand, the model first moves that demand to another, less efficient plant. Only when capacity falls short across the whole system does it schedule prebuilds. ### Where this work comes from Our team builds these models with our Supply Chain Builder library for ExtendSim, using the same rate-based method ReliaSim® is built on. Production run length is a plant decision, while redeployment, fill rate and disposal are network outcomes. ReliaSim’s supply chain modeling holds both in one model. The simplest version of the question, where to hold safety stock across a multi-tier network, runs in the browser. Open the safety stock demo Built by our team, built in our Supply Chain Builder for ExtendSim and rebuilt in ReliaSim · evidence: our project record and original model output. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Capacity Planning Simulation: Sizing Capacity Before Peak Source: https://reliasim.com/case-studies/lifecycle-capacity-commitment.html ## Sizing Overseas Capacity Before the Peak Is Known Every Mix of Capacity and Sales Scored Before the Capital Goes In Case Study · Electronics & automotive ## Sizing Overseas Capacity Before the Peak Is Known Every Mix of Capacity and Sales Scored Before the Capital Goes In A consumer electronics manufacturer has to commit capital to overseas component capacity before it knows how big the product will be. Lead times run three to six months, and the product line has a two-year life cycle. A simulation of the supply chain crosses three capacity levels with three sales outcomes. It shows the cost of guessing wrong in either direction before the money is spent, and tests what flexible ordering and expediting can win back. The businessA consumer electronics manufacturer The questionHow much component capacity to commit before demand is known The modelOverseas component plant, ocean freight, assembly, distribution, over the full product life cycle What it is worthThe cost of over- and under-committing capacity, seen before the commitment Sourceour project record ### What the company is up against Key components are made overseas and shipped to an assembly plant, which feeds the distribution centers. The plan allows 30 days for loading, ocean transit and unloading, including customs. Our team works with the company on three problems that fed into each other: - Demand is hard to forecast. Both the total and the peak of a two-year consumer electronics life cycle are uncertain, and monthly peak sales are what size the plant. - Capacity has to be committed in advance. The life cycle is too short to add capacity once the market shows how strong demand really is. - Lead times are long. At three to six months, short-term surprises have to be covered by a large safety stock at the assembly plant, and that inventory costs money every month it sits there. Undersize the plant and the company has to prebuild stock and can still miss orders. Oversize it and the extra capital would eat into the product’s profit. Make componentsOverseas plant; capacity committed before launch → Ship by sea30 days allowed, including customs → Assemble unitsAssembly plant; safety stock sits here → DistributeDistribution centers to customer inventory Expedite: air freight straight to assembly when demand spikes ### How it is modeled The model follows components from the overseas plant through shipping, assembly and distribution to customer inventory. Its inputs are combinations of life-cycle demand and forecast. Three capacity commitments are crossed with three ways actual sales can turn out, including the one where the forecast is right. Three capacity commitments against three sales outcomes over the product’s life. Redrawn from the project figure. When demand runs over capacity, the only way to cope in the model is to prebuild stock ahead of the peak. Every combination is simulated through the life cycle and scored on capital equipment cost, prebuild cost and total shipping cost. Each is also scored on inventory at the overseas plant and the assembly plant, and on customer service. ### What the model shows What each combination does Sales A (high)Sales B (medium)Sales C (low) Capacity 1 (high)Moderate prebuild during peakNo prebuild; capital somewhat excessiveNo prebuild; capital very excessive Capacity 2 (medium)Massive prebuild during peakModerate prebuild during peakNo prebuild; capital somewhat high Capacity 3 (low)Capacity cannot keep pace with salesMassive prebuild during peakModerate prebuild during peak Idle capital Moderate prebuild Massive prebuild Lost sales Even where capacity matches the forecast peak and sales come in on forecast, the model still shows a moderate prebuild during the peak. Each step of under-commitment turns into more inventory built and paid for ahead of the peak, until the lowest capacity can’t keep pace with high sales at all. Over-commitment avoids prebuilding and pays in idle capital instead. ### What flexible ordering and expediting are worth With capacity fixed, the model tested two ways to live with forecast error. #### Flexible ordering If the assembly plant could adjust its orders closer to the time of need, it could hold less safety stock against the long lead times. The model asks how much flexibility is enough, since flexibility helps the customer but adds cost for the supplier. #### Expedited shipments Air freight answers an unexpected demand spike faster than a month at sea. The model weighs combinations of flexible ordering and expediting by what they do to inventory and customer service, and counts the extra shipping cost. ### What changes The company can weigh its capacity commitment against the full grid of outcomes, with the consequences of each wrong guess assessed before the capital is committed. Flexible ordering becomes the main tool for cutting the large safety stock at the assembly plant. The same kind of decision turns up well beyond electronics, anywhere capacity has to be committed before demand is known and the peak sizes the plant. A seasonal product, a limited-time flavor or a launch with a short window all raise it. ### Modeling this kind of supply chain in ReliaSim® ReliaSim’s supply chain modeling represents the sites, lanes, demand, inventory and ordering behind this question in one model. The simplest version of that chain, a supplier feeding a plant feeding a customer, runs in the browser. Open the supply chain demo Built by our team, built in our Supply Chain Builder for ExtendSim and rebuilt in ReliaSim · source: our project record. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Food Plant Capacity Study: Olive Plant Simulation Source: https://reliasim.com/case-studies/olive-plant-capacity-scheduling.html ## Growing an Olive Plant’s Output 15% More From Scheduling, Before Buying Equipment Case Study · Food & beverage ## Growing an Olive Plant’s Output 15% More From Scheduling, Before Buying Equipment A specialty olive packer expects sales to rise sharply. The whole crop arrives in a six-week harvest, so the plant processes a year of olives out of storage. Managers need to know what the current plant can handle and where capital should go. A simulation of the full plant answers both. Testing scheduling rules in it finds 15% more throughput without new equipment. The businessA specialty olive packer · olive processing and canning The questionWhat can the current plant handle, and what should we buy? The modelA full harvest year, every olive variety and can size What it is worth15% more throughput from scheduling; capital tested before purchase SourcePublished paper · trade-press coverage · our project record ### What the plant is up against The plant pits, sorts, fills, seams and cooks olives into consumer-size cans. Every olive is harvested in about six weeks, then stored and processed through the rest of the year. That makes inventory and scheduling central to everything downstream. Each variety pits at its own speed and has its own defects to sort out. A changeover between olive sizes on the pitting machines takes about two hours. Different areas run different shift patterns. With sales forecasts rising, the question is whether the current plant can keep up, and if not, what to buy. ### How it is modeled Our team builds a rate-based model of the plant from the plant’s own data. That covers the capacities of the pitters, continuous cookers and still retorts, yields by variety, shift patterns, routing by variety and can size, and changeover and downtime records. The model runs a full year from the plant’s production schedule and reports the overtime each schedule would need. Plant engineers and the production scheduler review the logic with the modelers, and the team checks the model against a year of the plant’s historical schedule before using it. The plant as modeled, from the published study. Grading feeds two facilities, each with its own can lines. Pitting sits early in that flow. The can lines and packaging are at the right-hand end. ### What the model shows The model confirms the bottlenecks the plant suspects, starting with the pitting machines, and shows which operations have capacity to spare. It also finds other choke points further downstream, in packaging, after the olives are filled into cans and retorted. “…they’re not in the places you would expect them to be.” — Robert Rugeroni, MIS director, on the plant’s other choke points, in Food Engineering With the model in hand, the team tests scheduling rules, product mix, buffer sizes, and shift and crewing policies before trying any of them on the floor. It also puts a number on how much harvest variability matters. ### What changes New scheduling rules, tested in the model first, raise throughput 15% without new equipment. The plant then runs a Theory of Constraints-based scheduling system day to day, after verifying it with the model. The model also sets the plant’s capital spending priorities. It is the place to test proposed spending over short and long horizons before committing the money. “The model confirmed bottlenecks at certain operations in the plant … an effective tool to evaluate proposed capital expenditures and scheduling changes over short and long-term periods.” — Capacity Planning Simulation of an Olive Processing Plant, Barnes, Phelps & Rugeroni Built by our team, built in ExtendSim and rebuilt in ReliaSim · source: Capacity Planning Simulation of an Olive Processing Plant (PDF). ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Throughput Analysis: Spreadsheet vs Simulation Case Study Source: https://reliasim.com/case-studies/food-manufacturer-spreadsheets-to-simulation.html ## From a Snapshot to a Video Why a Major Food Manufacturer Moves from Spreadsheets to Simulation Case Study · Food & beverage ## From a Snapshot to a Video Why a Major Food Manufacturer Moves from Spreadsheets to Simulation Engineers at a major food manufacturer work through production decisions with spreadsheets, and the answers keep falling short. A dynamic model lets them watch the system behave, test far more alternatives, and get results in as little as 15 minutes. Across the company, its simulation manager estimates $5 million saved from 40 models, most of it by stopping projects that would have backfired. The businessA major food manufacturer The questionWhich production changes are worth making, from plant capital out to the network? The modelThe production system run as a video, not a snapshot What it is worthResults in as little as 15 minutes; $5M saved across 40 models company-wide SourceIIE Solutions · Food Engineering · project record ### How the work starts The project most people remember is the supply chain one, but it begins on the plant floor. At one site, the company uses the same simulation approach to decide how many packaging lines to buy for a particular product line. ### What the tool needs to do The next goal is to take cost out of a major product line by improving the production system. The engineers have been working through scenarios at an aggregate level with spreadsheets. As the director of engineering puts it, the company needs a tool that can model complex relationships across the full production system and draw “the feasible kind of conclusions that helped whittle down alternatives.” “Instead of taking a snapshot, this is more like a video. It’s more than just a point solution. Your ability to actually see the activity in action and plot out the results allows you to understand impacts much better while the supply chain is running. We can run six months of supply chain data in a matter of minutes.” — Mike Geddis, Director of Engineering ### What building the model teaches them “What we really found to be very powerful was the actual building of the model. It forced a certain diligence in terms of saying, if we change the system here this happens over here. We had not gone to that level of understanding the interconnections of our systems before.” — Mike Geddis, Director of Engineering A value stream map is the snapshot; value stream map simulation is the video. ### Getting answers quickly “This definitely saves us time. It gives the ability to let the tools follow our questions and follow them rapidly, so once we have the model constructed, we can get results in as little as 15 minutes. There’s no question we will explore substantially more alternatives than we would have if this were a more laborious process like before. As a result, we end up with much more thorough and novel solutions.” — Mike Geddis, Director of Engineering ### What simulation is worth across the company The company uses simulation well beyond this project. Its manager of advanced control and simulation tells Food Engineering he estimates the company has saved $5 million from 40 simulation models. Of that, $3 million comes from scrapping projects that would have been counterproductive. “Cost avoidance is a concept accountants hate, but it’s real.” — Malcolm Beaverstock, manager of advanced control and simulation, in Food Engineering One of those projects is at a cereal plant that moves product from a dryer to packaging on carts. Management assumes conveyors will do the job better. The model shows productivity would drop with the conveyors as first designed, because the carts give the plant flexibility the conveyors take away. Further tests in the model lead to a conveying system that does work better. Another comes when the company acquires a barbecue business. A simulation of the smokehouse shows it can meet the demand from wider distribution without new equipment. ### Where this work comes from This study is done by our team, using our Supply Chain Builder library for ExtendSim. It starts as a plant capital decision and grows to cover multiple plants, product portfolios and locations. ReliaSim® covers the production side of that work, and supply chain modeling for the network side is coming to ReliaSim. Published as IIE Solutions (PDF), reprinted with permission of the Institute of Industrial Engineers. The company-wide figures are the simulation manager’s, from Kevin T. Higgins, “Virtual Engineering’s New Frontier,” Food Engineering. They cover the company’s simulation work in general, not only this project. Project by our team, built in our Supply Chain Builder for ExtendSim and rebuilt in ReliaSim. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Intermediate Storage Sizing: Chemical Packaging Case Study Source: https://reliasim.com/case-studies/chemical-bag-lines-vs-overtime.html ## Weighing New Bag Lines Against Overtime Decoupling Packaging From Bulk Production Shows Low-Capital Ways to Grow Case Study · Chemicals ## Weighing New Bag Lines Against Overtime Decoupling Packaging From Bulk Production Shows Low-Capital Ways to Grow At a global specialty chemicals company’s plant, each bag line is tied to one bulk production line and has to pack off product as it is made. Overtime is the central cost, and the company has to choose between alternative bag line configurations. A model run over a ten-year horizon weighs each option against the overtime it would need, including a layout with short-term storage between bulk production and packaging. The company comes away with low-capital options for growth it hadn’t seen, and keeps using the model for its own scheduling and production decisions. The businessA global specialty chemicals company · bulk chemical production and bagging The questionWhich bag line configuration, weighed against the cost of overtime? The modelCustomer orders driving bulk production and bag lines over a ten-year horizon What it is worthLow-capital growth options; a model the company keeps using Sourceour project record · client testimonial ### What the plant is up against The company is restructuring its manufacturing network and needs to judge capital investments and asset use without trying them on live operations. On the packaging side, each bag line is dedicated to a bulk manufacturing line. Bagging has to take product as it comes off bulk production, so neither side can be scheduled on its own. Overtime is the central issue. In some demand scenarios, demand runs ahead of manufacturing capacity. The plant can cover that with overtime, or it can spend capital on a different bag line configuration. Reorder quantities and batch sizes feed into the same decision. ### What the model is built to answer - What’s the tradeoff between the cost of alternative bag line configurations and the cost of overtime? - Which combinations of scheduling parameters work best, measured in inventory levels and overtime cost? ### How it is modeled Our team builds a model-based application that ties ordering policy, planning and production capacity together, using a library for modeling supply chain dynamics. A stream of customer orders drives the model. Experiments vary the demand and forecast scenarios, the scheduling parameters and the bag line configuration. Two configurations anchor the study. In the current setup, each bag line is tied to its bulk line. In the “To-Be” setup, short-term storage between bulk production and new high-speed packaging lines breaks that tie, so packaging can run on a different schedule from bulk production. Safety stock at the customer-facing inventories uses the basic calculation, unchanged. Each run covers a ten-year experiment horizon. The model tracks total inventories, customer order fill rate and overtime hours, with overtime as the critical measure for each bag line scenario. For every bag line it reports average weekly hours split into production, repair, changeover, idle and overtime. That lets the team judge a configuration by how it spent its time rather than by nameplate capacity. ### What the model shows The model weighs the capital cost of each bag line configuration against the overtime it would need, across the demand scenarios. It also shows what the “To-Be” storage is worth. With bulk storage between production and packaging, the two can be scheduled separately. That kind of postponement gives the plant more flexibility in scheduling both production and packaging resources. “We have uncovered additional options for low capital cost business growth, some of which were not readily apparent beforehand.” — Rick Dougherty, Senior Manufacturing Analyst ### What changes The company’s analyst calls the modeling “extremely successful.” After our first round of experiments, the company keeps using the model on an ongoing basis to assess schedules and production. It shows the same rate-based method at work well outside food, on bulk chemical production and bagging. ### Where this work comes from Built by our team, built in ExtendSim and rebuilt in ReliaSim. Source: our project record and the client’s testimonial. The results are reported in words, with no published throughput or cost figure. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Shift Planning Simulation: Cereal Plant Case Study Source: https://reliasim.com/case-studies/cereal-plant-shift-model.html ## The Cereal Plant That Runs Its Model Before Every Shift A Make-Store-Pack Plant Checks the Plan Before the Floor Does Case Study · Food & beverage ## The Cereal Plant That Runs Its Model Before Every Shift A Make-Store-Pack Plant Checks the Plan Before the Floor Does A major cereal maker runs a make-store-pack plant around the clock. Our team builds a model of the plant, and the planners put it to daily work: before each shift, they run the model to see what could go wrong during that shift, so they can change the plan before the trouble reaches the floor. The model treats cereal as flow, not as individual items. That is what makes it fast enough to run every shift. The businessA major cereal maker · a make-store-pack cereal plant The questionWhat is likely to go wrong on the next shift, and what should the plan do about it? The modelThree to four making lines, about four large storage bins plus small portable totes, and six to seven packing lines How it is usedRun by the planners before every shift Sourceour project records · our team’s Winter Simulation Conference paper ### What the plant is up against The plant is a make-store-pack plant. Three to four making lines produce the cereal. Between making and packing sit about four large storage bins and a fleet of small portable totes. Six to seven packing lines fill the boxes. Making and packing run to different clocks. Making thinks in pounds per hour and long runs. Packing thinks in cartons per minute, package sizes and changeovers. The bins and totes absorb the difference, as long as the right cereal is in the right place when a packing line needs it. When it isn’t, a packing line sits idle while storage is full of product nobody is packing yet, or making has to slow down because there’s nowhere to put what it’s making. Whether that happens on a given shift depends on the schedule, the state the last shift left the plant in, and which lines are running which sizes. All three change from shift to shift. ### Why it needs a flow model Many simulation tools move product through a model one item at a time. Cereal isn’t items. Counting every piece, or even every box, makes a model far too slow for a plant that runs around the clock. Our team models the cereal as flow instead: rates through the machines and levels in the bins, with an event only when a rate changes. This is discrete rate simulation, the method ReliaSim® runs on. our team’s Winter Simulation Conference paper puts it plainly: discrete rate simulation is “driven by early experience trying to model such commodities as dog food and Cheerios in the discrete event world.” ### How the plant uses it This is an operating model, not a one-time study. Before each shift, the planners run the model on the shift ahead and look for trouble coming: a packing line about to run out of cereal, storage about to fill, a changeover landing at the wrong moment. If the model shows a problem, there is time to change the plan before the shift starts, instead of finding out on the floor. A model is only useful that way if it runs fast and speaks the plant’s language. Rates, bin levels and schedules are what planners already talk in, and a flow model answers in the same terms. ### What changes - A plan checked before every shift. Our project history lists this plant among its successes: the plant puts the model to work instead of shelving it after a study. - Trouble caught in the model first. A starving packing line, a full bin or a badly timed changeover shows up while the plan can still change. - Parts other plants can use. The building blocks made for this model are shared with the company’s other plants. We standardize them as our Plant Builder library. ### Try the same kind of plant The Sandbox has a demo vegetable plant with the same make-store-pack shape, built the Plant Builder way: two making lines, eight surge bins and five packing lines, with campaigns, changeovers and bins that can only feed lines packing the same product. Is the problem the plant, or how it’s scheduled? → ### Where this work comes from Built by our team, built in ExtendSim and rebuilt in ReliaSim · evidence: our project records; R. A. Phelps, D. J. Parsons and A. J. Siprelle, “Non-Item Based Discrete-Event Simulation Tools,” Winter Simulation Conference. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Supply Chain Simulation With Live Data: Vehicle Network Source: https://reliasim.com/case-studies/vehicle-network-live-data-forecast.html ## Forecasting New-Vehicle Flow Across a Continental Network A Network Model That Starts From Where Every Vehicle Actually Is Case Study · Electronics & automotive ## Forecasting New-Vehicle Flow Across a Continental Network A Network Model That Starts From Where Every Vehicle Actually Is A vehicle-logistics company, part of a major railroad, runs a major automaker’s new-vehicle shipments from assembly plants to dealers across a continent. Its job is to cut order-to-delivery time, and its carriers and ramps need to know what is coming and when. A model that starts empty takes weeks to settle, which is most of a two-week forecast. The network model, built with our team, starts each run from the tracked location of every vehicle, railcar and truck, and settles within a day or two. By the company’s own figures, one set of recommendations from it saved $21.7M in inventory carrying costs and cut transit time by 19%. The company runs it every week for more than ten years. The businessA railroad-owned vehicle-logistics company running a major automaker’s new-vehicle distribution · ~16 plants, 78+ rail facilities, 10 ports, ~3,500 dealers The questionWhat’s coming at each ramp and carrier over the next few weeks, and which network changes pay off? The modelPlants, ramps, railcars, trucks, parking and holds, started from that day’s vehicle records What it’s worth$21.7M in carrying costs and 19% less transit time (the company’s figures); weekly use for 10+ years SourceWinter Simulation Conference paper · the company’s own figures · our project record ### What the company is up against According to the published paper, the network has about 16 assembly plants, 18 rail loading facilities, more than 60 rail unloading facilities, 10 ports and roughly 3,500 dealers. The dealers are grouped into about 60 dealer service areas. Around 2.5 million vehicles a year move through it, and at any moment more than 100,000 are somewhere between a plant and a dealer. Our project record puts the goal as cutting the number of vehicles in the network by 20%. Each vehicle rolls off the line and waits near the plant. Dealers within a couple of hundred miles are served by truck. Everything else goes to a rail loading ramp, waits for a railcar it physically fits on, and can cross more than one railroad before reaching a destination ramp. There it is unloaded, parked, and loaded onto a haulaway truck for the dealer. Four things limit how fast vehicles move: - Transport pools. Haulaway trucks and railcars come from carrier pools sized once a year across the whole industry. They are ordered as production and empty return times demand. - Parking. When spaces run out at a plant or loading ramp, vehicles go to temporary remote lots. When a destination ramp is full, unloading stops, and the rail network backs up behind it. - Loading rules. Railcar types, vehicle heights, route clearances, shifts and holiday calendars all set how fast vehicles can be loaded. - Holds. Model-year rollouts, promotions, quality holds and planned shutdowns hold vehicles back and then release them, sometimes all at once. Production pushes vehicles into the network, and trucks and railcars are pulled in to move them. With that mix of push and pull, a spreadsheet of average transit times can’t show where the network will jam. ### Why a model that starts empty can’t forecast two weeks out The company plans on two horizons. Strategic planning looks three to twelve months out: promotions, inventory built ahead of a launch, closing or moving a rail facility. Tactical planning looks one to four weeks out. It answers the questions carriers and facility operators actually ask, which the paper quotes as “What’s coming at me?” and “When will it get here?” A simulation that starts empty is fine for the first kind of question and poor at the second. It spends its first weeks filling up, and during that time resources sit idle and vehicles move unrealistically fast. For a two-week forecast, that warm-up period is most of the forecast. ### How it’s modeled The company and our team build the model in our Supply Chain Builder. Production comes from the automaker’s weekly plan, turned into daily output at each plant. Dealer demand comes from historical patterns and marketing assessments. Routes live in the model’s database, so a route change doesn’t mean changing the model. Parking, railcar spots, truck and railcar pools, loading rules and holds are all modeled as the constraints they are. For tactical runs, the model starts warm. The company’s vehicle-tracking system follows every vehicle from planned production to dealer delivery, updated by EDI messages from every carrier and facility. A utility pulls every open vehicle record from it, usually set to run each day just before the business day starts. The model then places each vehicle where it really is: in a plant lot, at a ramp, or on a specific railcar or truck in transit. The live data is never clean. Late or missing EDI reports leave gaps. Some vehicles left the plant long ago but are still undelivered. Some railcars are due at their next stop before the extract is even taken. Some vehicles are on routes that don’t exist because weather forced a detour. The import step checks each record for a believable current state, a believable next event and a known last-event time, estimates what it can, and reports the rest. The paper calls this grooming the data, and calls the import’s robustness crucial given the millions of records it handles. ### What the model shows Started empty, the model takes weeks to fill the network, and average transit time creeps up for the first week or so because resources are free and nothing is congested. Started from the tracking data, the network begins near its normal inventory and transit time begins near its long-run level. The paper puts the remaining start-up effect at one to two days for most measures, once the three days used to fill the plant pipelines are set aside. From the paper. Top: the model started empty, with network inventory and transit time taking weeks to reach normal levels. Bottom: the same model started from live tracking data, running at a normal pace almost at once. The paper says the warm start allows a more accurate short-term analysis. Each run reports bottlenecks as they emerge, daily throughput at every plant lot, loading ramp and destination ramp, transit time by route segment, and where every truck and railcar is. It also gives a daily picture of where vehicles sit in the pipeline, so surges show up before they arrive. Model output tracking where vehicles sit in the network over eight months: in total, not on hold, on hold, at loading facilities and on railcars. The paper’s conclusion points past the model to the data feeding it. It says faster event reporting into the tracking system would have a significant impact on how accurate the projections can be. ### How the company uses it Our project record adds what the paper doesn’t cover: - Every week, analysts run a two-week forecast of vehicles arriving at each rail unloading facility, and use it to plan staff shifts there. - Every year, the company’s CFO runs the model to set the budget for network resources from projected vehicle production. - In a crisis, when a major hurricane disrupts the network, the team uses the model to reroute vehicles and estimate how long recovery will take. - For speed, our team rebuilds the model as a standalone application. That cuts a run from six hours to about twenty minutes, fast enough for scenario work during the hurricane response. ### What it’s worth “[We] leveraged VINLogic to recommend solutions that saved $21.7M in inventory carrying costs and reduced transit time by 19%.” Manager, Network Analysis & Engineering, the vehicle-logistics company That figure is the company’s, and it comes from one set of recommendations. Savings from the weekly use that follows come on top of it. “VinLogic is at the heart of what we do. Our analysts run it every week. I run the model to more accurately predict our annual budget! The reason we never call you is because the model just works.” CFO, the vehicle-logistics company ### Where this sits in ReliaSim® This model’s limits are finite resources that move product (trucks, railcars, parking, loading crews) and shipping and receiving that take time. In ReliaSim’s supply chain simulation, sites and routes are kept in tables, the same way. ReliaSim models are built from a company’s own records and aren’t started from a live feed the way this one is. The network half of the story, which sites to keep and where demand should be served from, runs in the browser on a sample distribution network. Open the footprint demo ### Where this work comes from Built by the company’s team and ours, first in our Supply Chain Builder for ExtendSim, then as a standalone application, and rebuilt in ReliaSim · the network, the model design and the start-up comparison come from the paper Initializing a Distribution Supply Chain Simulation with Live Data, Winter Simulation Conference · the savings and transit figures are the company’s own · later use comes from our project record. ExtendSim® is a registered trademark of Andritz Inc. It is referenced here for identification and historical purposes only; no affiliation or endorsement is implied. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Simulation by Industry: Where Rates Rule Source: https://reliasim.com/industries.html Industries ## Industries The Same Method, Six Different Kinds of Constraint Rate-based simulation works wherever material moves as flow rather than as a queue of parts. What limits throughput differs a lot by sector. A cereal plant is limited by shelf life, a pharmaceutical line by quality release, a launch site by assembly fixtures. Each page below covers what usually limits throughput in that industry and the work we've published there. Kellogg’s · General Mills · Nestlé · Tyson · Cargill · Hershey ### Food & Beverage Bulk flow, changeovers, sanitation windows, shelf life and seasonal supply. Read more → Unilever · Estée Lauder · Rich Products · Hewlett-Packard ### Packaging & CPG Five machines at 85% OEE in series give a line near 44%. Surge sizing, SKU changeovers, micro-stops and reblend. Read more → Rohm & Haas · ICI Paints · Glidden · Elf AtoChem ### Chemicals, Oil & Gas There are no parts, only material moving at a rate. Intermediate storage, campaign scheduling and shared vessels. Read more → Eli Lilly · Genentech · Glaxo Wellcome · Pfizer ### Pharma & Life Sciences The constraint is usually a wait, not a machine, such as quality release, validated cleaning or batch integrity. Read more → Delphi · Ericsson · Lucent · Bosch · JTEKT ### Electronics & Automotive Takted lines with minimal inventory, where every stoppage propagates immediately in both directions. Read more → Boeing · Lockheed Martin · Raytheon · NASA · Sandia ### Aerospace & Defense Low volume over a long horizon, limited by fixtures, bays and qualified people rather than machine rates. Read more → ### Not on this list? The method cares about structure rather than product. If your operation has stages that must run in step, storage between them, changeovers, and failures that arrive unpredictably, it's the same problem. The same buffer arithmetic sizes a surge tank in a chemical plant and an assembly fixture at a launch site. The browser Sandbox shows a bottling line and its engine results with no download and no sign-up, and the guides cover the arguments without reference to any particular industry. Related: All case studies · Supply chain simulation · Guides · Methodology --- # Food and Beverage Manufacturing Simulation Source: https://reliasim.com/industries/food-and-beverage.html ## Simulation for Food & Beverage Production Where the Material Is a Flow, Not a Queue of Parts Industry ## Simulation for Food & Beverage Production Where the Material Is a Flow, Not a Queue of Parts Most simulation software was built for discrete manufacturing, where parts move through workstations. Food and beverage plants work differently. Product is bulk, liquid or paste for most of the process, and it has a shelf life. The line stops for sanitation whether or not it's running well, and demand arrives in seasons nobody controls. ### Five things that make a food line hard to model #### 1. The material is a rate Grain flowing into a cooker, syrup into a filler and olives through a grader aren't queues of entities. The usual approach is to lump bulk into pseudo-entities. The usual result is a model that either runs too slowly to be useful or is too coarse to trust. Rate-based simulation treats flow as flow, so a full year of a line runs in under a second here. #### 2. Changeovers are the schedule Lines change over for sizes, flavors, labels and allergen sequences. In an olive plant, a two-hour changeover between olive sizes makes the pitters a bottleneck. A shifty bottleneck that moves whenever packaging size changes will defeat an Advanced Planning System optimizing against a fixed constraint. Both are real cases on this site. #### 3. Sanitation isn't downtime you can eliminate Clean-in-place windows and changeover cleans are the cost of operating legally and safely. They belong in the model as scheduled structure, not as losses to attack. Mixing the two up is how improvement programs end up chasing something they can't have. #### 4. Shelf life turns storage into a time limit In discrete manufacturing a buffer decouples two stages for as long as you have space. With partially-cooked or unpasteurized product it decouples them for as long as the material stays good, which may be minutes. In the cereal case on this site, stabilizing the intermediate turned a buffer measured in minutes into one measured in weeks. #### 5. Supply arrives when it arrives Harvest windows, crop variability and seasonal demand set the pace. A plant sized for the average is idle half the year and constrained the other half. The real question isn't "what is our capacity" but "what is our capacity during the peak, given how the line actually behaves." In every one of these, the constraint isn't where the loss report says it is. Downtime that looks identical on a Pareto has very different consequences depending on where it sits, what's buffering it, and what the line was running at the time. Who has used it Kellogg’s · General Mills · ConAgra · Tyson Foods · Hormel · Rich Products · Nestlé · Cargill · Hershey · Frito-Lay · McKee Foods · Bell-Carter Foods “I’ve never seen anything like this.” VP of Food Production ### Food and beverage work on this site Beverage · Bottling ### $1.5M in hidden throughput Two failure modes have near-identical downtime. Removing the smaller one returns 62% more. Read the case study → Salad Dressing · Published ### More output without another line A plant model built from its own downtime records matches a year of actual OEE within 1% and finds many small fixes worth many points of OEE. Fischel & Lange · open access → Olive Processing ### 15% more throughput, no new equipment At a specialty olive packer, sales are rising and the whole crop arrives in six weeks. Scheduling rules tested in a full-plant model raise throughput 15%. Olive packer · published paper → Cereal ### 19.8% more effective production Stabilizing partially-cooked grit decouples the cookers from the toasting ovens. The model is live in a browser. Run the simulator → Coffee ### The Shifty Bottleneck A new stage in a Make-Store-Pack line meant the constraint moved with packaging size. Read the example → Brewing ### The expansion is limited upstream Kegging or bottling would over-run the fermenting and serving tanks either way. Published paper → Food Manufacturing ### From a snapshot to a video A major food manufacturer’s move to simulation starts with a plant capital decision: how many packaging lines to buy for a product line. Food manufacturer · published article → #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Packaging Line Simulation Software Source: https://reliasim.com/industries/packaging-and-cpg.html ## Simulation for Packaging & Consumer Products Five Good Machines Don’t Make a Good Line Industry ## Simulation for Packaging & Consumer Products Five Good Machines Don’t Make a Good Line A packaging line is a series. The filler, capper, labeler, case packer and palletizer can each hit their targets while the line still misses badly. What matters is how their stoppages interact, not how each machine performs alone. The arithmetic is harsh, and it's why so many well-run CPG lines sit far below the number their machine reports suggest. ### The arithmetic nobody likes 85% OEE is the world-class benchmark, and it's a single-machine benchmark. Put five machines at 85% in series with no buffering between them and the line comes out near 44%, even though nothing has gone wrong. Buffering, sequencing and constraint management exist to recover that gap. How much you can recover depends on which machine stops, for how long, how often, and what's sitting between it and its neighbors. Those are dynamics, not averages, so a spreadsheet can't answer it. Is 85% OEE achievable on your line? works through the arithmetic in full. ### What makes CPG lines their own problem #### Making and packing keep different time The upstream process is continuous or batch, while packaging is a series of discrete machines. They rarely want to run at the same rate, so the surge capacity between them is the main design question. Too little and the making process stops, and that's usually the expensive end. Too much and you've paid for storage that buys nothing. #### SKU count multiplies changeovers Every size, format, label and allergen sequence adds changeovers, and changeovers interact with everything else. A schedule that's efficient for one product mix can be badly wrong for another. When the mix moves, the constraint can move with it. #### Micro-stops beat rare long ones A stoppage measured in seconds looks negligible on a loss report. On a tightly coupled line it never lets buffers refill, so its cost is carried all the time rather than now and then. Eliminating it can return much more uptime than its recorded downtime suggests. It's the most common misranking on a CPG loss tree. #### Rework and reblend make storage circular Material re-introduced into the process is good economics and terrible for capacity planning, because the flow into storage is no longer just the making rate. Scheduling changes the recycle volume, the recycle volume changes the storage requirement, and the storage requirement constrains what can be scheduled. All four lead to the same result. The loss report ranks by minutes lost, the plant funds the top of that list, and the throughput doesn't come back. What you want ranked is recoverable throughput, meaning what the line actually returns when a failure mode is removed. That's a different number and often a different order. Who has used it Unilever · Estée Lauder · Rich Products · ConAgra · Hormel · Pitney Bowes · Hewlett-Packard ### Packaging and consumer products work on this site Bottling · Worked Example ### $1.5M in hidden throughput A filler, capper, labeler, case packer and palletizer line. Two failure modes had near-identical downtime, and removing the smaller one returned 62% more. Read the case study → Consumer Products ### The $4M retrofit that was never built Consolidating multiple plants across 300+ products. The model sized the surge between processing and packaging and caught a configuration that would have created a quality problem. Read the case study → Consumer Products ### Too little storage stops the expensive end In-process storage that moved with scheduling rules and reblend volume. Re-implemented at 12+ similar factories. Read the example → Make-Store-Pack ### The Shifty Bottleneck Changing the packaging size moved the constraint, which defeats any planning system optimizing against a fixed bottleneck. Read the example → #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Simulation Software for Chemicals, Oil and Gas Source: https://reliasim.com/industries/chemicals-oil-and-gas.html ## Simulation for Chemicals, Oil & Gas The Case Rate-Based Simulation Was Built For Industry ## Simulation for Chemicals, Oil & Gas The Case Rate-Based Simulation Was Built For Most simulation software models a queue of parts. A chemical plant has no parts. It has material moving at a rate through reactors, tanks and pipes, in campaigns that change grade and in batches that can't be interrupted. Rate-based simulation was created for this, and in this industry the difference in approach matters more than anywhere else. ### Why entity models struggle here To model bulk material as discrete entities you have to chop it into pseudo-parts. Make them small and the model runs too slowly to explore anything. Make them large and the answer is too coarse to act on. The alternative, a combined discrete/continuous language, means writing differential equations, which puts the model out of reach of the people who understand the plant. Rate-based simulation represents flow as flow and fires events only when a rate changes. So a full year of a plant runs in under a second, and a thousand scenarios take an afternoon rather than a project. ### What tends to be binding #### Intermediate storage between production and packaging Bulk production and packaging rarely want to keep the same time. When packaging has to take output as it's made, neither can be scheduled on its own terms. Sizing the store between them is a capital question with a scheduling answer. The gain from decoupling is often larger than the gain from buying more of the constrained stage. #### Campaign scheduling and grade changes Changeovers between grades carry cleaning, purge and off-spec cost, so campaign length trades directly against inventory and responsiveness. Move the product mix and the binding constraint can move with it, which defeats a schedule optimized against a fixed bottleneck. #### Tank farms and shared vessels Shared intermediate capacity couples processes that look independent on a flowsheet. A vessel committed to one campaign is unavailable to another, and the interaction only shows up over time. #### Capital against overtime The recurring question is whether to buy equipment or run the existing plant harder. Answering it needs the time split (production, repair, changeover, idle, overtime) under demand that varies, including the periods when demand exceeds capacity. Each of these is a dynamic interaction rather than a rate calculation. A plant balanced on paper can be badly unbalanced in operation, and the difference comes from how the stages couple to one another over time. Who has used it Rohm & Haas · ICI Paints · Glidden · Elf AtoChem · BICC General Cable ### Chemicals work on this site Specialty Chemicals ### The bagging lines are tied to bulk production At a specialty chemicals plant, packaging is dedicated to individual bulk lines and has to pack off as product is made. Modeling intermediate storage decouples them and turns up low-capital growth options the company hadn't known it had. Specialty chemicals · client quote → Same Mechanism, Different Industry ### Buying time instead of buying a line Stabilizing a partially-processed intermediate decouples two stages that have to run in lockstep. 19.8% more effective production in peak periods, and the model runs live in a browser. Run the simulator → Recirculating Material ### Too little storage stops the expensive end In-process storage sized against a recycle stream that scheduling itself changes. Undersize it and expensive upstream processing shuts down. Read the example → ### Adjacent work The method has also been applied to resource and logistics problems in this sector and in government. Examples include long-horizon transport and storage planning for Department of Energy waste programs, and facility-maintenance resource modeling used to build long-term service contract proposals. Those are network and resource studies rather than production-line studies, but the treatment of flow is the same. #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Pharmaceutical Manufacturing Simulation Source: https://reliasim.com/industries/pharma-life-sciences.html ## Simulation for Pharmaceutical Manufacturing Where Batch Rules Limit Capacity as Much as Line Rates Industry ## Simulation for Pharmaceutical Manufacturing Where Batch Rules Limit Capacity as Much as Line Rates A pharmaceutical line is a manufacturing system with a regulatory system wrapped around it. Batches can't be interrupted, and changeovers carry validated cleaning. Material waits on quality release rather than on a conveyor. The constraint is often a step where nothing physical is happening at all. Who has used it Eli Lilly · Genentech · Glaxo Wellcome · Pfizer · Teleflex · BioPharm Services ### Why the usual throughput analysis misses here Most capacity arithmetic assumes the constraint is a machine running too slowly. In pharma the binding step is often a wait, such as a hold for quality release, a validated clean between products, or a stability or sterility check that takes as long as it takes. None of those go faster when you buy more equipment, and none of them show up as downtime on a machine report. So the plant is a coupled system whose couplings are procedural rather than mechanical, and averages mislead badly here. A step that's idle 80% of the time can still be the constraint, because what matters is when it's available relative to when the batch needs it. ### What tends to be binding #### Quality hold and release Material that's physically finished but not yet releasable takes up space, ages, and blocks the step behind it. Release time is variable and mostly outside operations’ control. That kind of variability has to be modeled rather than averaged. #### Validated changeover and cleaning Changeovers aren't a setup time to squeeze. They're a validated procedure, which makes campaign length a real commercial lever. Longer campaigns amortize the clean but build inventory and reduce responsiveness, and the best length moves with product mix. #### Batch integrity A batch that can't be split or interrupted couples upstream and downstream far more tightly than a continuous flow does. Buffering between them is limited by hold times and stability, so the usual answer of adding storage is bounded by chemistry and by the filing. #### Shared suites and utilities Suites, vessels and clean utilities shared across products couple lines that look independent on a flowsheet. The interaction only appears over time, under a real campaign schedule. It's the same pattern as everywhere else on this site, in a stricter setting. The loss report ranks by minutes lost, but what you want ranked is recoverable throughput, meaning what the line actually returns when a constraint is relieved. In a regulated plant, several of the biggest entries on that report can't be relieved at all, so ranking by recovery matters even more. ### Related work on this site The same mechanisms show up on these other lines. Decoupling · Hold Time ### Buying time instead of buying a line Two stages that had to run in lockstep were separated by stabilizing the intermediate. It's the direct analog of a hold-time constraint, where a buffer's worth depends on how long material may legally sit in it. Run the simulator → Campaign Scheduling ### The Shifty Bottleneck Changing the product format moved the constraint and defeated a planning system built on a fixed bottleneck. It's the campaign-scheduling problem in another industry. Read the example → #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Simulation for Electronics and Automotive Lines Source: https://reliasim.com/industries/electronics-automotive.html ## Simulation for Electronics & Automotive High Volume, Tight Coupling, No Room to Absorb a Stop Industry ## Simulation for Electronics & Automotive High Volume, Tight Coupling, No Room to Absorb a Stop Automotive components and electronics assembly are the high-volume discrete case. Cycles are fast, many stations run in series, and takt times leave almost nothing spare. When a line runs to a takt and inventory between stations is kept low on purpose, a stoppage anywhere spreads right away in both directions, in a way averages can't describe. Who has used it Delphi Automotive Systems · Ericsson Wireless Communications · Lucent · Bosch · JTEKT · Hewlett-Packard · BICC General Cable ### Lean removed the inventory, not the variability Pulling inventory out of a line is good practice, but it doesn't make the line more reliable. The variability is still there, and now it spreads down the line instead of being absorbed. Every lean program makes this trade, usually without putting a number on it. The question isn't whether to hold buffer but which form to hold it in (inventory, spare capacity or time). How big should a buffer be? works through why the buffer never really disappears. ### What tends to be binding #### Series length punishes good machines 85% OEE is a single-machine benchmark. Five machines at 85% in series with no buffering give a line near 44%, and an assembly line is far longer than five stations. The arithmetic is here. #### Micro-stops, not breakdowns On a tightly coupled line a stoppage measured in seconds never lets the small buffers refill, so its cost is carried all the time rather than now and then. It looks negligible on a loss report and is often the largest recoverable item on the line. #### Mix and sequence Model mix changes station-level work content, so the constraint moves with the build sequence. A line balanced for one mix is unbalanced for another. The balance is only true on average, and the line is never actually running at the average. #### Supplier and inbound variability On a machine report, a station starved by a late delivery looks the same as a station that broke. The cause is outside the plant, and only a model that represents both can assign it correctly. All of these lead to the same misreading. The loss report ranks by minutes lost, the line funds the top of that list, and the throughput doesn't show up. What you want ranked is recoverable throughput. On a tightly coupled line the two rankings differ even more. ### The same mechanisms, documented Five Machines in Series ### $1.5M in hidden throughput Two failure modes with near-identical downtime on the loss report. Fixing the bigger one returns less than it costs. The smaller one returns 62% more because it cascades into the stations downstream. Read the case study → Propagation ### Starved vs blocked Both look like a stopped machine, but they have opposite causes. On a takted line the machine you're looking at usually isn't the one with the problem. Read the guide → Automotive Logistics ### “What’s coming at me, and when will it get here?” A new-vehicle rail and truck network simulated from where every vehicle actually is. One set of recommendations saves $21.7M in carrying costs and cuts transit time 19%. Vehicle-logistics company · published paper → Electronics ### Sizing capacity before you know the peak Component capacity has to be committed overseas, months ahead, for a product with a two-year life. A model prices being wrong in either direction before the money is spent. Read the case study → #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up. --- # Simulation Software for Aerospace and Defense Source: https://reliasim.com/industries/aerospace-defense.html ## Simulation for Aerospace & Defense Low Volume, Long Horizon, Constrained by Resources Industry ## Simulation for Aerospace & Defense Low Volume, Long Horizon, Constrained by Resources Aerospace and defense production is the opposite of a bottling line. Units are few, cycles are long, and what runs short is rarely machine capacity. It's fixtures, bays, cranes, transport and qualified people. Throughput depends on how those resources are shared over months and years, so it's a scheduling and contention problem rather than a rate problem. Who has used it Boeing · Lockheed Martin · Raytheon · NASA · Electric Boat · SAIC · Los Alamos National Laboratory · Sandia National Laboratories · Westinghouse Savannah River · United States Marine Corps ### How many fixtures buy how many rockets? Delta IV launch vehicles are shipped to Cape Canaveral in parts and assembled near the launch site. Assembly needs specialized fixtures, each one expensive and each one occupied for a long time by a single vehicle. Buy too few and vehicles queue for a fixture; buy too many and capital sits idle between launches. Boeing used a model to weigh that tradeoff, the number of specialized assembly fixtures against the throughput of assembled rockets. This is the buffer question again. A fixture is a resource that decouples one stage from the next. Its cost is capital, and the right number depends on variability rather than on averages. The arithmetic that sizes a surge tank in a chemical plant also sizes an assembly fixture at a launch site. ### The method is cited in the field In 2010, Steven E. Saylor and James K. Dailey of Boeing Research & Technology presented BALANCE (the Advanced Logistics Analysis Capabilities Environment) at the Winter Simulation Conference. It builds on the non-item-based approach, citing Phelps, Parsons and Siprelle (2002). A major aerospace research organization built its own logistics analysis capability on this modeling approach and said so at the field’s flagship conference. ### Long horizons and shared resources #### Programs measured in decades Transport and storage resource planning for Department of Energy transuranic waste was assessed over a 35-year horizon. At that timescale the question stops being "can we do it" and becomes "what do we need, when, and what happens if it arrives late." Answering that across scenarios takes a model that can run a whole program quickly. #### Facility maintenance as a bid input Resource requirements for long-term facility maintenance were modeled to support contract proposals. The model showed how much crew, plant and float a multi-year service commitment needs, given failures that arrive unpredictably. #### Contention between programs Bays, cranes, clean rooms and qualified technicians are shared across programs that are planned independently. A schedule that works for each program alone can be infeasible for all of them together, and that only shows up when they're simulated on the same resources. ### Deployment Everything runs on the desktop, with no outbound data flow and no cloud dependency, and it works air-gapped, so your process data never leaves your network. In this sector that's usually the first question asked. ### The same mechanisms, documented on other lines The Fixture Question ### How big should a buffer be? How much decoupling capacity is worth buying, and why the answer depends on variability rather than on average rates. The fixture-count question in its general form. Read the guide → Capital vs Utilization ### The bagging lines are tied to bulk production How many lines to buy, traded against running the existing ones harder. The answer comes from the time split rather than nameplate capacity. Read the case study → Related: Chemicals, oil & gas · Pharma & life sciences · All case studies #### A free line assessment Bring one question about your line. We model it on your own data and send back a two-page readout in about five business days. Apply for a free line assessment → Or explore the Sandbox first, with no sign-up.