Multi-Model Simulation

A plant raises different questions. How long does a cycle take? Do bottles jam in front of the labeller? Does a part land in the bin or bounce out? How many units does the line deliver in a week? No single simulation method answers all of them well. Different questions need different levels of detail and computing effort.

In realvirtual, you build one model and choose the simplest simulation approach that answers your question. The simulation runs in your browser on an ordinary PC.

The model can be simulated in two groups, and you switch between them deliberately:

Real-time simulation updates motion and signals in small time steps and normally runs at wall-clock speed. It offers several approaches: kinematic simulation, 2D physics, rigid-body physics and detail physics. Usually a model uses one of them. You combine them only for special cases.
Discrete-event simulation (DES) advances time from event to event. It answers throughput and capacity questions far faster than real time.

One model, two simulation groups. You usually choose one real-time approach; the illustration shows a special case that combines approaches by zone. DES runs the same layout on event time.

Real-time simulation

In real-time simulation, motion and signals are updated in small time steps, normally at wall-clock speed. Parts move visibly, signals change as they would in the plant, and you can connect your PLC. The group offers four approaches, each with a different balance of speed and fidelity. Usually you pick one for the model: the lightest one that answers your question. You combine approaches only in special cases, when most of the model needs high performance and a small critical area needs very high detail.

The real-time approaches are levels you choose from, usually one per model. Kinematics scales to whole plants, and each level below adds physical detail for a smaller system.

The drawing and the tables below use the same scale. The drawing puts the largest system at the top and the most detail at the bottom. The tables start with the most detailed approach and end with the largest system.

Approach	Strengths	Limits	Data needed	Use it for
Detail physics (MuJoCo, Beta)	Joints, contacts and dynamics of robots; sensors that depend on simulated gravity and forces (force/torque, weighing, contact and gripping force) and vision sensors	Highest cost, few bodies	Rigid-body inputs plus joint damping, actuator and contact parameters	Legged robots, adaptive grippers, force-sensor and weighing checks, controller tests
Rigid-body physics (Rapier)	Falling, sliding, tipping, stacking, pushing	Tuned for speed; does not validate force predictions	Geometry, mass, centre of gravity, inertia, friction, restitution, collider shapes	Transfer points, chutes, bins, pushers
2D physics (Box2D, Beta)	Dense flow, thousands of parts, low computational cost	Flat only; parts do not fall or tip	Geometry, part footprints, friction, damping	Jams, buffer tables, merges, diverters
Kinematic simulation	Exact timing, repeatable, fastest, PLC-driven	No contact between parts; accumulation (parts queueing on conveyors) is calculated, not physically simulated	Geometry, axes, speeds, PLC signals	Sequences, cycle times, robot paths, virtual commissioning

Choose the level your data supports. Every level below kinematics needs more input data. Kinematics runs on geometry, axes, speeds and PLC signals. For 2D physics, you add part footprints, friction and damping. Rigid-body physics needs mass, centre of gravity, inertia, friction, restitution and collider shapes. Detail physics also needs joint damping and actuator and contact parameters. Physics with guessed values only looks real. If you do not have the data for a part of the model, use the lighter level for it.

One example on every level: an AGV

An automated guided vehicle (AGV) shows what each level means in practice. The AGV counts below are rounded order-of-magnitude estimates for a current desktop PC (a 2025 desktop CPU such as the AMD Ryzen 7 9700X or Intel Core Ultra 7 265K) in a desktop browser. The real-time estimates assume a simulation update rate of 60 Hz; DES advances by events. Results depend on your model and hardware.

Level	What you simulate for the AGV	AGVs in parallel	Speed
Detail physics (Beta)	One AGV in full detail: wheels and wheel friction, suspension, drive controller, contact forces, load sensors, vision system	About one	Real time
Rigid-body physics	An AGV with loads that can slip or tip	A few to tens	Real time
2D physics (Beta)	AGVs passing and queuing in a zone, interacting with each other	Tens	Real time
Kinematic simulation	AGVs on paths with exact timing, driven by a PLC or a fleet controller	Hundreds	Real time
Discrete-event simulation	The fleet: dispatching, traffic, charging, throughput	100 and more	Far faster than real time: days of operation in minutes

Typical orders of magnitude on a current desktop PC (a 2025 desktop CPU such as the Ryzen 7 9700X) in a desktop browser at 60 Hz: about 4,000 parts move on kinematic transport. A 2D zone handles thousands of flat parts, about 12,000 awake at once with more at rest in a jam. Rigid-body physics handles on the order of 800 bodies. One robot cell in detail physics costs about 0.5 to 1 ms per frame.

These figures were measured on a 2019 desktop CPU and scaled by single-thread performance. Actual numbers depend on your CPU, browser, model complexity and render load.

Kinematic simulation

Kinematics is the base of every model. It simulates motion without forces: every part moves exactly as the model prescribes. You get exact, repeatable timing for the motion you model, and the cost is so low that large plants run in real time. This is the level of virtual commissioning, where you test a PLC program against a model of the machine. The approach has four parts that work together.

Forward kinematics and drives. A drive moves a node along or around an axis. Axes in a hierarchy form a kinematic chain, and the pose of the whole chain follows from the axis values. Use drives for everything with a defined motion: cylinders, lifts, doors and the joints of a robot. PLC signals control them. See Drives.

Robot inverse kinematics. You give the robot a target pose and the solver finds the joint values. Use it to teach paths, check reach and move a robot to targets in the plant without calculating joint angles by hand.

Kinematic transport. Transport surfaces carry parts along belts, rollers and chutes without physics. A part on a surface moves with it and stays where the conveyor puts it. Sources, sinks, sensors and grippers work on this transport, so it covers the complete material flow of a line. See Material Flow.

Mechanisms. Mechanisms cover motion where parts constrain each other: cams, gears and couplings, and closed linkages such as a four-bar linkage, a scissor lift or a delta picker. The joints are solved together, so one driven axis moves the whole linkage correctly. See Rigid-Body Mechanisms.

Kinematics does not simulate contact between parts. Parts do not push each other, fall or tip. When contact matters, choose physics; add a physics zone only when you need a combined model.

2D physics with Box2D (Beta)

Dense flow of bottles, cans and boxes is mostly a 2D problem. In a 2D interaction zone, Box2D simulates the parts from above: they push against each other, gather at a blocked outlet, spread over a buffer table and merge at a junction. The zone kinds are jam, buffer table, diverter and merge. Parts enter the zone from a conveyor and return to kinematic transport at its discharge.

Use it for accumulation, buffers and merges in beverage, packaging and bottling lines. It costs much less than 3D physics and is designed for thousands of containers. Parts do not fall or tip, so it fits flat flow and not drops or stacks. See 2D Interaction Zones.

Rigid-body physics with Rapier

Rapier simulates parts as 3D bodies with mass, friction and collisions. A part that leaves a conveyor falls, slides down a chute, tips over and stacks in a bin. Moving machine parts such as pushers, lift tables and gripper pads push and carry parts, and the weight they carry is added to the load on the drive.

Use it at transfer points, chutes, sorting stations and bins, for pushers, and to see whether a part sits securely. Run it for the whole scene, or only in physics zones so the rest of the plant stays kinematic. The behaviour is plausible, and you can calibrate it with masses and friction. It is tuned for speed and stability, so it does not validate force predictions or structural strength. It costs much more than kinematics. See Physics.

Detail physics with MuJoCo (Beta)

MuJoCo simulates articulated bodies with many joints and contacts, such as legged robots and grippers that adapt to a part. Motion comes from forces and contacts, not from a prescribed path, so a walking robot keeps its balance or falls depending on its control. You can use the simulated gravity and contact forces to model force and torque sensors, weighing, contact forces and gripping force, and combine them with vision sensors that see the simulated scene.

Use it for robotics work, for example to test a locomotion controller, to check what a force sensor in a gripper reads, or to weigh a load. For articulated motion and force-dependent behaviour, this is the most detailed and computationally demanding approach described here, so use it for the bodies that need that detail. In a combined model, the surrounding plant can remain kinematic. See Detail Physics (MuJoCo).

Combining the approaches

Usually one model uses one approach: a kinematic plant, or a physics model of one machine. Combine approaches only when most of the model needs high performance and a small critical area needs very high detail, such as a fast kinematic line with one physics zone or one MuJoCo gripper.

The approaches then share one model, and at any moment one method controls a part’s motion, so you can identify which method produced a result.

For a physics zone and a 2D interaction zone, the zone hands parts over: a part that enters it is taken over by the zone’s method, and at the discharge kinematic transport takes it back. A detail region does not work that way. It simulates what is authored inside it, and parts do not cross its boundary in either direction — there is no handover at the box. Everything a detail region is to resolve has to be inside it from the start.

Typical special cases:

Conveyor into a bin. Kinematic transport carries parts to the conveyor end; a physics zone simulates their fall and stacking in the bin.
Robot picks from a physics bin. Kinematics and inverse kinematics control the robot; physics determines how parts settle in the bin before pickup.
Jam in front of a labeller. The line stays kinematic, a 2D zone covers the accumulation section, and the parts return to the conveyor at the discharge.
Walking robot in a cell. A detail region holds the robot while conveyors and drives around it stay on kinematics.

A useful rule: start with the cheapest approach that answers the question, and add detail only where the answer depends on it.

Time and synchronisation

The approaches run with different time steps. They have to stay in step with each other and, when a PLC or a user is connected, with real time. You can couple simulation time in three ways:

Loose coupling over real time. This is the normal case in virtual commissioning. Every participant runs in its own cycle: the PLC in its program cycle, the simulation in fixed steps at 60 Hz, a physics engine in smaller sub-steps inside each step, and the HMI at its refresh rate. They stay in step only through the wall clock and exchange signals through the connection at its update rate. This works as long as each side reliably runs at least as fast as real time. The connection of realvirtual to a PLC works this way.
Tight coupling with synchronised time. All participants advance through coordinated simulation steps, and every step waits for the slowest one, as in time-synchronised stepping with PLCSIM Advanced. The model may then run slower than real time, but the timing is deterministic and reproducible. This is the principle for exact PLC-in-the-loop timing. Detail physics and force or sensor simulation also need suitably small, stable time steps. With coordinated stepping, execution can slow down while preserving those steps, rather than increasing them and risking numerical errors.
Decoupled execution. DES runs decoupled from the wall clock, as fast as the processor allows. A kinematic simulation without a connected PLC or user can run decoupled in the same way.

Discrete-event simulation

DES is the second group. It does not move parts continuously. It jumps from one event to the next: a part arrives, a station finishes, a machine fails. Depending on your model, you can simulate a week of production in seconds, compare many layouts and parameter sets, repeat runs with different seeds and read throughput, utilization and buffer levels with confidence intervals.

Use it for capacity planning, bottleneck analysis, buffer sizing and shift models. DES is the fastest approach for long periods and answers statistical questions. It models queues and blocking at the process level; its animation shows the flow, but it does not resolve contact-driven motion or physical jams. For DES, you describe process durations, capacities and routing rather than detailed motion and control. See Discrete Event Simulation and Experiments and Runs.

Both groups work on the same model: the same GLB and layout, the same sources, sinks, conveyors, stations, material units (MUs) and paths, the same statistics and the same 3D view and HMI. Material-flow components with both behaviours can take part in either simulation. The difference is the time model, and with it what you have to describe.

	Real-time simulation	Discrete-event simulation
Time	Small time steps update motion and signals	An event list: time jumps from one event to the next
Process logic	PLC signals, drives, sensors and motion	Durations, distributions, capacities and queues
A station	Drives, sensors and a controller	A delay with a capacity
Transport	Parts that move along the conveyor	A travel time from A to B
Speed	Normally real time; slower with tight coupling, faster when decoupled	As fast as the processor allows: days of operation in seconds or minutes
Answers	Does it work? Are the sequence and timing correct?	How much does it deliver? Where is the bottleneck?

You can run DES in three modes: fast-forward without intermediate visuals, animated in 3D at the pace of the clock, or step by step, one event per click. The animated run uses the same 3D view as the real-time simulation, so you can watch a DES result in the plant.

A typical path through both groups: start with DES to find out whether the layout reaches the required throughput and where the capacity is short. Then take the critical area, for example the transfer point or the jam in front of a station, and check it in detail in real-time simulation, where a physics zone shows why parts queue there.

The gap to reality

How close a simulation has to be to reality depends on your question, and more detail does not automatically close the gap.

For cycle time or sequence, kinematic simulation gives exact timing for the motion you prescribe, although nothing is simulated physically. Validate the motion and signal timing against your plant.
A question about gripping force or tipping needs physics and good data for mass, friction and contact.
A question about throughput is answered by DES without any geometry detail.

A detailed model with guessed friction or mass can be further from reality than a simple kinematic one. It looks real, but the data behind it is not. Each level on the detail and data axis of the drawing above closes the gap only for the questions it is built for, and only with the data it needs.

So work in four steps: define the question, pick the level that answers it, provide the data that level needs, and validate against the real plant where the result matters.

How these approaches fit into industrial simulation

Industrial simulation is often sorted into four categories, each with its own question, effort and gap to reality. They place the approaches of this page in a broader context and are separate from the four real-time levels shown above. The point is to apply the right category to the question and not to default to the heaviest tool.

Category	Typical question	In realvirtual
Exact engineering simulation, including high-end sensor simulation	Forces, stresses, deformation, perception	Not built in. You connect suitable external tools, for example as an FMU
Real-time and robotics physics	Contacts, falling parts, jams, articulated motion	Real-time group: MuJoCo (Beta), Rapier, Box2D (Beta)
Kinematic simulation and virtual commissioning	Sequences, cycle times, PLC logic	Real-time group: kinematic simulation, with virtual commissioning
Discrete-event simulation	Throughput, utilization, buffer sizes	DES group

realvirtual covers physics, kinematic simulation and DES in one model. The Editions page lists which features each edition includes.