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
| ExtendSim | ReliaSim | Notes |
|---|---|---|
| Valve (Rate library), Activity (Item library) | Constraint | A rate limit with its own reliability. |
| Tank (Rate library), Queue (Item library) | Buffer | Accumulation between operations. |
| Interchange, unit changes along the line | Converter | Material measured one way in, another way out. |
| Shutdown blocks and downtime logic | Interrupt signature | One time-to-failure and time-to-repair pair per failure mode. |
| ExtendSim databases, linked spreadsheets | ReliaDB tables | Exported as CSV; parameter sets generated from them. |
Plant Simulation to ReliaSim
| Plant Simulation | ReliaSim | Notes |
|---|---|---|
| SingleProc, ParallelProc | Constraint | Processing time becomes a rate. |
| Buffer, accumulating conveyors | Buffer | Capacity carries over directly. |
| Assembly and packing stations | Converter | Bottles into cases, cases onto pallets. |
| Source and Drain | Buffers at the start and end of the line | Supply ahead of the line and the warehouse after it. |
| Failure profiles (availability and MTTR) | Interrupt signature | Each failure mode kept separate instead of one availability figure. |
| Table objects | ReliaDB tables | Exported 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.
That is the test every migration should pass: the new model agrees with the old one and with the plant. 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 came within 1% of 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.