ChiAha builds simulation models of production lines, plants, and supply chains — and validates every one against your own production data before anyone uses it to make a decision. Capacity, bottlenecks, buffers, line design, OEE, networks, staffing: the questions that are too expensive to answer by trial and error on the plant floor.
Averages hide interactions. A production line is a coupled system: a stop on one machine starves the next and blocks the one before it, and a buffer in between changes the whole picture. Simulation modeling is how you see those interactions before you spend money on them.
What the plant will actually produce under next year’s mix, a new shift pattern, or a 20% demand increase — and where it breaks first.
The loss tree points at the machine with the most downtime. In the cascade example we publish, that is the Labeler — but 120 one-minute micro-stops on the Filler cascade through the system, and eliminating them recovers 56% more throughput than fixing the Labeler.
Accumulation decouples machines. Too little and every stop propagates; too much and you have paid for floor space and inventory that does nothing. Simulation finds the knee.
New equipment, a consolidated line, a new product: test the configuration before the purchase order, and check whether the stated ROI survives contact with the rest of the line.
OEE tells you how much you are losing; it doesn’t tell you which losses are recoverable or in what order. A validated model ranks improvements by what they return at the end of the line, not at the machine.
Inventory allocation, safety stock, run lengths, and distribution design — modeled as a system over time, pairing optimization with simulation to test what an optimizer proposes.
Operators, maintenance crews, and service lines are queues. M/M/c models and simulation size staffing against service levels when arrivals don’t follow the average.
If the decision is expensive and the system is too coupled to reason about on paper, it is probably a modeling problem. Tell us about it.
Every engagement follows the same discipline: data, then a validated model, then decisions. The order matters. A model that hasn’t reproduced the past has no business predicting the future.
A capital request, a capacity commitment, an improvement roadmap. We scope the model to answer that decision, not to model everything.
Historian downtime records, machine rates, buffer capacities, product mix, schedules. Failure and repair times are fitted per failure mode where the data supports it; gaps are flagged, never silently defaulted.
Discrete rate simulation for high-speed, high-volume, and bulk flow lines; discrete event simulation where individual items matter; optimization and queueing where the question calls for them.
The model must reproduce what the system actually did — OEE, throughput, blocking and starving, availability by failure mode — before it is allowed to predict anything. This is the gate, and we show you the comparison.
Hundreds of what-if scenarios instead of the three you had time for, including sensitivity to the inputs you are least sure of.
You get the recommendation and the evidence. Engagements run on the same engines as our products, so your team can license the tools and keep the model working, we can train your analysts, or we stay on as modeling capacity.
Most simulation accuracy claims are a vendor’s word. Ours are measured against the plant’s own history, and the method is in the peer-reviewed literature.
At the 2020 Winter Simulation Conference, Lawrence Fischel and Tom Lange published a discrete rate and reliability model of a multi-line food plant, with up to twenty failure modes on each of more than twenty unit operations. Over a one-year simulated run, it agreed with the plant’s actual OEE to within one percentage point — validated failure mode by failure mode, not just in aggregate.
That distinction is the point: a single overall number can be right for the wrong reasons, with errors quietly cancelling. Mode-by-mode comparison can’t hide that. It is the standard we hold our own models to.
That ExtendSim model was rebuilt in ReliaSim and independently validated by Tom Lange: within 1% of both the plant’s measured OEE and the original ExtendSim model, running the same one-year simulation roughly 1,200× faster on the same laptop. When a run costs seconds instead of an overnight, you stop choosing three scenarios and start exploring the whole space. Read the published-validation case study.
“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.”
In 1990, Andrew Siprelle created the modeling approach now known as discrete rate simulation — originally called “bulk flow” — to model high-speed and bulk manufacturing without tracking every item. Through Simulation Dynamics, the firm he founded in the early 1990s, he developed one of the earliest libraries for building models of multi-stage plants that produce powders and bulk solids, and the team published the work at the Winter Simulation Conference from 1995 onward.
The same team took the method from the production line to the supply chain — inventory allocation, run lengths, safety stock, logistics networks, a food manufacturing merger — and customers and partners have published their own peer-reviewed papers about work done with these tools.
ChiAha brings that history together with consulting partners from Technology Optimization & Management and our Doctors of Reliability — retired industrial reliability engineers and R&D leaders with 32 to 36 years each in manufacturing. The result is a team that has spent 35 years building models for 300+ organizations, and that treats validation as non-negotiable. See the full publications list.
“We leveraged the model to recommend solutions that saved $21.7M in inventory carrying costs and reduced transit time by 19%.”
“Instead of taking a snapshot, this is more like a video. Your ability to actually see the activity in action while the supply chain is running lets you understand impacts much better.”
“The team went above and beyond the project scope, proactively brainstorming ways to make our project better.”
A few of the 300+ organizations we’ve built for since 1995:
The engines behind our consulting work are available as products. If your team wants to build the model in-house, here is where each kind of question lives. Comparing vendors? Start with how to choose manufacturing simulation software.
| Your question | Where to start |
|---|---|
| Throughput, capacity, and buffer sizing on a production line | ReliaSimManufacturing simulation software — production line simulation software with per-failure-mode reliability, blocking and starving. |
| Which losses to attack first, and what OEE is really achievable | ReliaSimOEE simulation — rank improvements by what they return at the end of the line. |
| Finding the constraint that actually governs output | ReliaSim GuideTheory of constraints simulation — when the bottleneck moves with the failures. |
| Whether a block-diagram availability calculation is good enough | ReliaSim GuideReliability block diagram vs. simulation — what multiplying availabilities misses about buffers. |
| Turning downtime logs and historian exports into model inputs | ReliaStatsDowntime data analysis — fit time-to-failure and time-to-repair distributions. |
| High-speed, high-volume, and bulk flow systems | DiscreteRateDiscrete rate simulation — the rate-based paradigm, explained with runnable examples. |
| Queues, service lines, and staffing levels | QueueSimQueueing simulation — M/M/c models for staffing against service levels. |
A computer model of a production line, plant or supply chain that reproduces how the system behaves over time: machines failing and recovering, buffers filling and draining, units starving and blocking. Because it captures those interactions, it answers questions a spreadsheet or downtime Pareto cannot, such as which improvement actually moves throughput.
Software gives your team the capability; consulting gives you the answer and the model behind it. We can build and validate the model, train your analysts to build their own, or both, and engagements run on the same engines as our products. If you are evaluating tools, our buyer’s guide to simulation software lists the questions worth asking.
Usually data the plant already keeps: downtime or line event data from the historian, machine rates, buffer capacities, product mix and schedule. Failure and repair times are fitted into distributions, per failure mode where the data supports it. Missing inputs are flagged and agreed, never quietly assumed.
Before it predicts anything, the model must reproduce what the system actually did over a historical period: OEE, throughput, and availability by failure mode, not just one aggregate figure that can match for the wrong reasons. Our production models are validated to within about 1% OEE.
Discrete event simulation tracks individual items, so high-speed models run slowly. Discrete rate simulation, created by Andrew Siprelle in 1990 and originally called bulk flow, models flow rates and only fires events when a rate changes, which suits high-speed, bulk and process lines. We use whichever paradigm fits the problem.
Yes. The team has published on supply chain simulation, inventory allocation, safety stock and logistics network design since the late 1990s. We also apply optimization to network design, M/M/c queueing models to staffing, reliability statistics to downtime data, and theory of constraints to finding the real bottleneck.
Tell us about the line, the plant, or the network and the decision in front of you. We’ll tell you honestly whether simulation is the right tool — and what it would take to get a validated answer.