ReliaSim / Comparisons / ReliaSim vs BlockSim

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

ReliaSoft BlockSim, from HBK, and ReliaSim both simulate. They are built around different methods and different questions. BlockSim is a reliability engineering platform that analyzes systems drawn as reliability block diagrams and fault trees, using exact computations or discrete event simulation. ReliaSim is a production line simulator built on discrete rate simulation, where flow is modeled as rates and buffers, blocking, starving and per-failure-mode interrupts set line throughput and OEE. Which one fits depends on what you need to know, and plenty of teams are well served by both.

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 cannot 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 is 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. Constraints are unit operations with a rate limit and their own failure modes. Converters change the unit of flow, from liquid to bottles to cases to pallets. Buffers hold accumulation between operations, filling or draining whenever the rates on either side differ. Each constraint and converter carries multiple failure modes, and each failure mode is an interrupt with its own time-to-failure and time-to-repair distribution, triggered on competing, cumulative or wall-clock criteria.

The engine runs the line forward through time, so blocking and starving emerge from the model instead of being assumed. It reports throughput, line efficiency and OEE, and each machine’s time up, down, blocked and starved. ReliaSim does not do fault tree analysis, and it is not a maintenance or spares planning system.

Discrete event vs discrete rate simulation

Both methods are event-based: the simulation clock jumps from one event to the next. They differ in what counts as an event.

• Discrete event simulation (DES) changes the model’s state at discrete points in time. In a model that tracks individual items, each unit’s arrival, start and finish is an event. In a reliability simulation, events are typically changes of component state: a failure, a repair, a maintenance action.
• Discrete rate simulation (DRS) models flow as rates. Events happen only when a rate changes: a failure or repair, a changeover, a buffer reaching full or empty, a machine becoming blocked or starved. Between events every rate is constant, so buffer levels change linearly and 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 rather than averaged. Andy Siprelle created discrete rate simulation in 1990 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 rather than 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. A model of your line can match measured OEE within 1% when the model and data are handled correctly: per-failure-mode time-to-failure and time-to-repair data, fitted distributions, and validation against the line’s history. The published Fischel & Lange (WSC 2020) 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 1,200× faster on the same laptop. The detail is in within 1% of measured OEE. ReliaSim vs ExtendSim sets out the same validated discrete rate model in both engines.

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 Fischel & Lange 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 does not, ReliaSim’s Interrupt Designer lets you enter them directly. The method-level argument is in reliability block diagram vs line simulation.

Frequently asked questions