Capabilities

What the Line Simulator does — and what it doesn't, and why

Know the boundary before you buy. Every row was checked against the product itself; where something is out of scope, the row says why.

Included in the product today Simplified modeled, common case Out of scope by design
Line Simulator

"How much will this line actually make?"

A discrete-event simulator for serial and assembly production lines. Some things are deliberately left out, so that anyone who knows the line can run it.

Configuration / capabilityStatusWhy / our stance
What the Line Simulator models
Serial flow line — up to 49 stations + a line feederIncludedCore. 49 is the app's own limit; the line feeder is configurable as a station, the warehouse is not.
Parallel identical machines (M/M/c) — PLC-style dispatchIncludedEach part goes to one of the parallel machines by committed load (its buffer plus parts already on the way), the way a line PLC would — not blind rotation. A starving machine is fed first; full buffers are skipped.
Synchronized assembly · multi-BOM feedersIncludedThe assembly waits when a component line can't keep up — a real merge, not just costing.
Finite buffers + blocking & starvationIncludedThe core Factory-Physics coupling most spreadsheets miss.
7 statistical distributions (fit to data)IncludedNormal, lognormal, triangular, uniform, exponential, gamma, Weibull — with auto-fit. The curve can be set per product, not only per station: in a real line it is the product that governs variability.
Breakdowns — MTBF/MTTR, per cycle or per timeIncludedInterval and duration are both distributional; failures accrue with usage, not idle time.
Scrap & at-station reworkIncludedRework re-runs the cycle where the defect happens — the common case.
Setups & multi-product campaignsIncludedProduct and material setups; campaign sequencing.
Re-entrant route (a part returns to a station)IncludedA part can return to a station as many times as its product route says (1 > 2 > 3 > 2 > 3 > 4). The machine waits for the part to come back, so its capacity is divided by the number of passes, and the bottleneck ranking shows it. The route is fixed per product; a path that changes piece by piece is job-shop (next row).
Conveyors with transit timeIncludedLength ÷ speed delays material and acts as a moving buffer.
Batch / container transport between stationsIncludedA finite, shared fleet of returnable carts carries parts in batches (capacity, min-load, reorder point / kanban overlap); the cart is the buffer, so transfer-batch size and fleet limits both affect flow — not just one-piece movement.
Branched conveyors (fork & merge)IncludedShared trunk with exclusive branches, fork and merge, with documented modeling recipes. (Mid-trunk accumulation is approximated — see the beta notes below.)
Replications · 95% CI · CRN · warm-upIncludedStatistical discipline — a run is not an anecdote. Replications with a 95% interval run in the paired A→B comparison and in the DOE; a single run is one run, and the report says so.
Factorial DOE & automatic improvement studyIncludedDOE on up to 6 factors (full factorial up to 4, a half fraction at 5 or 6): main effects, significance Pareto, recommended settings among those tested. The improvement study takes your two biggest losses and the constraint's cycle time, at three levels each, and draws the response curve of each, at the line's own horizon. The gains do not add up, and the report says so: fix one, then run again.
Recorded run you can rewindIncludedPlay from 1× to 300×, pause, and drag back to watch the same jam again. Before recording, the app tells you how many hours fit your connection.
Financials — payback · ROI · ROIC · NPV · IRR · EVAIncludedThe app labels this an engineering estimate for screening: no working capital, financing, sales taxes, inflation, FX, ramp-up or residual value. Your finance function reviews the case before any money is committed.
Engine checked vs M/M/1 · Little's LawIncludedThe engine reproduces the closed-form results for WIP, flow time and Little's Law within ~2%, in every run (worst case 2.24% at ρ = 0.9; Little's Law within 0.02%). Automatic tests also check the laws of a line: series adds, parallel is the maximum, the operator limits, variability never creates capacity. This validates the engine, not your data.
Runs in the browser — no specialist, no installIncludedThe interface is in your browser; the simulation runs on a secure server — see "What your connection needs" below.
WIP cap / CONWIP (pull) — "Max WIP"IncludedA line-level WIP cap: a new part is released only while WIP is below the cap (pull). Per-stage kanban stays out of scope.
Shared operators or loading robots, with travel timeIncludedOne operator or robot serves several stations and travels between them at a set speed. The machine waits for it to arrive, and walking counts as waste, so a tighter layout shows a real gain. A robot carries no labour cost.
Shift calendar & break stopsIncludedThe whole line pauses between shifts and during breaks (real availability), separate from the labor-cost side.
Sequence-dependent setup (from→to)IncludedAn optional sparse from→to changeover matrix, consulted when a station switches product in a campaign.
Accumulating conveyorIncludedSet a product size and each belt gets a real capacity (length ÷ size); parts accumulate when blocked — toggle synchronous vs accumulating.
Advanced stochastic reliability (optional)IncludedOptional, off by default, labelled experimental: Weibull time-to-failure, micro-stops, imperfect repair, wear and learning curves. On a line whose shortest cycle is under 5 s the micro- and medium-stop tiers switch off, and the app says so.
Flow view over a plant photoIncludedLay your stations over a plant photo or drawing, draw the conveyor paths, and watch per-product markers, buffer queues and the live bottleneck.
Check line before every runIncludedCatches what would make the result meaningless — a station with no time, a routing error, a feeder that caps output, WIP that grows without end — and says how to fix each.
Station table and levels of detailIncludedThe whole line in one table, one row per station, for fast entry. On the station card, Basic, Standard and Advanced only show or hide fields — no value changes, and a setting in use is never hidden.
2D and 3D view of the runIncludedThe recorded run as the 2D diagram, a 3D view, or both side by side on one clock. The 3D layout is saved with the line.
Short-term study — what one event costsIncludedInject one event — a stop, a slower cycle — in a short window; two runs on the same random seed give its cost in lost pieces. It is the cost of that event, not the expected output.
Calibration to measured stop dataIncludedPaste one row per station from your stop-collection system, and the model takes its stop parameters from what was measured instead of an estimate.
Eleven interactive guided tutorialsIncludedFrom the first line to the report, a priced change, campaigns, ramp-up and DOE — on the real screens, step by step.
Automated diagnosis + executive reportIncludedFindings ranked by $/year, each with its cause and a Lean, TOC, 6σ or TPM action; a one-page summary to print.
Deliberately out of scope
Queue priority (non-FIFO · SPT / EDD)FIFOIt doesn't move throughput, OEE or $/year — any work-conserving discipline yields the same throughput and mean WIP (Little's Law). It only changes per-order lateness, a scheduling concern outside our money-first purpose.
Rework routed to another station / repair areaAt-stationAt-station rework (the common case) is fully modeled and hits the bottleneck correctly. Routing defects back upstream is a rarer topology; leaving it out keeps the model simple without changing the throughput logic where rework actually bites.
Cumulative gain of elevating two constraints in a rowOut of scopeRemoved in August 2026: it only fitted a short horizon, which overstates the main lever by ~25%. The improvement study runs at the line's real horizon and states that gains do not add: fix one, then run again.
Job-shop / arbitrary routingOut of scopeA different tool class. This is a flow-line simulator; arbitrary routing belongs to general-purpose platforms and would trade away the simplicity that lets anyone run it.
Disassembly / split (1 → N)Out of scopeNot our market (meat, primary cutting, recycling). It inverts the part model and adds user-facing complexity for a vertical we don't target.
Probabilistic / conditional routingOut of scopeRare in the serial and assembly SME lines we serve; branch logic would complicate modeling for the majority who don't need it.
AGV fleets / detailed material handlingOut of scopeWe model the material handling that actually drives flow — conveyor transit time and parts moving between stations in batches (containers). What we leave out is full AGV-fleet dispatch and routing: a heavy modeling layer that's uncommon in the SME lines we serve.
Secondary constrained resources (tools / fixtures / molds)Out of scopeOut of scope to preserve simplicity; multi-cavity capacity covers the common case.
Sub-second cyclesDown to 1 msAccepted, but a run's time grows with the pieces it makes: halving a cycle doubles the run. Model a fast machine by its batch cycle and pieces per cycle. Below 5 s the advanced micro-stops switch off, and the app says so. Out of scope: piece-by-piece study of high-speed packaging, bottling or tablet presses.

✔ Your data stays yours

Your lines and products live in your browser and in files you export. The server computes and does not store, and your financial configuration — prices, margins, demand — is never sent to it.

While RASQI is in beta

Current limitations that aren't design decisions — the honest state of the beta, being worked on.

Single-user, browser-local

No accounts, cloud storage or multi-user yet — your lines and products live in your browser. Portability is via file export/import.

Languages

The Line Simulator interface is in English, Português and Español.

Gated access

Access is behind a one-time email code — nothing to create, nothing to lose. A running copy auto-detects a newer build and offers to update.

Approximated shared-trunk conveyors

A shared conveyor trunk is modeled as the receiver's input buffer — exact for capacity and blocking; mid-trunk accumulation and junction re-routing aren't physically modeled.

No API / batch runner

The simulator runs in a browser tab; there is no public API or batch runner yet.

What your connection needs

The Line Simulator's simulation runs on a secure server while the interface runs in your browser. These numbers are measured, not estimated.

Opening the app

About a 1.7 MB compressed transfer (measured on 7 October 2026), repeated on every visit so you always get the current build. About 1.5 s on a 10 Mbps link, 15 s on 1 Mbps.

Running a simulation

Almost no bandwidth — the line definition goes up, the results come back. A normal office link or 4G is plenty.

Watching the animation

About 145 KB per simulated hour on a reference line and about 230 KB on a large customer line, measured against production (the response arrives uncompressed). An 8-hour run is about 1.2 MB; 50 hours of the large line, about 12 MB. The whole run keeps loading in the background, with a progress bar. The app tells you, before recording, how many hours fit your connection with full playback controls.

⚠ Continuity matters more than speed

A long study keeps running on the server while your browser checks on it. If the connection drops for more than ~25 s, the study in progress is lost — you start it again. This is the one requirement that changes the decision on an unstable link.

What stays on your machine

Your saved lines, products and backups live in the browser. Your financial configuration — prices, margins and demand — is never sent: the money side of your business case does not leave your computer.

The boundary between a model and a plant

Is RASQI right for your line?

Answer 9 short questions about how material flows through your line and get an honest verdict — the Line Simulator is a flow-line simulator, not a fit for every layout, and we'll tell you straight.

Check compatibility →

Where RASQI sits

Between the OEE spreadsheet and the general-purpose simulators: finite buffers, real variability, blocking and starvation, for serial and assembly lines. It gives up job-shop routing and AGV fleets on purpose, so anyone who knows the line can run it.

The rationale
Start here · the purpose Make a better line decision — before the money is spent.

Buy a machine, add a shift, rebalance, expand — the expensive moves should be tested first.

Path A · Optimize Improve a running line → better financial results
1Model the line exactly as it runs today.
2Find the true bottleneck and price every lost hour in $/year.
3Test each fix as a paired scenario A→B — payback isolated from luck.
4Compare settings with DOE and keep the best one tested.
5Estimate ROI · NPV · IRR for your finance team to review.
More throughput and margin from assets you already own.
Path B · Design Engineer a new line → hit the project target, balanced
1Model the proposed line (to-be), station by station.
2Compare each station with takt and the target output.
3Size buffers, feeders and operators for smooth flow.
4Stress-test against real variability and breakdowns.
5Check capacity, and the payback of the CAPEX, before a machine is bought.
A right-sized line that meets the target — no over- or under-investment.