ReliaSim® vs BlockSim
Two simulators, two methods, two different questions

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.

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.

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