Most factory simulation is optimised for the wrong thing

In scheduling, visual realism is often mistaken for decision relevance.

For scheduling, the factory is not fundamentally a 3D scene. It is a time-based decision system. Machines finish. Jobs wait. Buffers fill. Routes block. Transport becomes available. Disturbances occur. Priorities change. That is the operational reality that matters.

Much of the traditional simulation market still optimises for what looks convincing in a demo: a robot moving from one 3D object to another. Platforms such as Visual Components, FlexSim, Simio, and similar tools built strong products for visual modelling and offline studies. That is a valid category. It is just not the category I care most about.

If your goal is event-driven industrial control, the problem is not rendering a robot moving through a 3D world. The problem is simulating the time-based operational decision logic fast enough to train, benchmark, and validate scheduling behaviour at scale.

The mistake I see again and again

A lot of legacy simulation software was built for:

• consultant-led studies
• offline what-if analysis
• project reviews and workshops
• visual validation
• management presentations

None of that is useless. But it creates a bad habit: people start confusing visual detail with decision quality.

That confusion gets expensive very quickly.

A beautifully rendered warehouse can still be the wrong tool for evaluating dispatch logic. A detailed 3D robot path can still tell you almost nothing about whether your control policy will hold up under congestion, disturbances, blocking, starvation, release constraints, or changing order mix.

For scheduling, those are the questions that matter.

What I actually care about in simulation

My core claim is simple: for scheduling, everything operationally relevant can be modelled time-based.

That is not a universal claim about every engineering problem. If you are validating robot reachability, collision envelopes, mechanical layout, or detailed physics, geometry matters a great deal. But if your question is scheduling, dispatching, congestion, waiting, release logic, and throughput, the decisive abstraction is usually temporal, not visual.

When I look at a simulation stack for scheduling, I care about five things:

1. Does it model the operational state that drives decisions?
2. Does it preserve the real feasibility constraints?
3. Can it run enough scenarios to support meaningful benchmarking?
4. Can it support training and replay loops, not just one-off studies?
5. Can it become part of a deployment workflow rather than a presentation layer?

That is a very different standard from "does the AGV animation look convincing?"

The hard part in industrial scheduling is not making a robot look realistic on screen. The hard part is deciding, under constant variability, what should happen next.

A real example: a high-bay warehouse

One of the clearest examples for us came from a real high-bay warehouse workflow.

The operational question was not whether we could render every movement beautifully in 3D. The operational question was whether we could evaluate dispatch behaviour fast enough to actually improve the system.

Once we stopped treating the warehouse primarily as a 3D rendering task and modelled it for what it actually was — a time-based operational decision system — we could strip away the irrelevant 3D-heavy overhead and focus on execution-relevant event dynamics. In that setup, we measured a speed-up on the order of 10^6 compared with the conventional simulation workflow previously used in that context.

That is not a cosmetic improvement.

That is the difference between:

• running a few scenarios and discussing them in a workshop, and
• building a real optimisation, replay, and validation loop around the operating logic.

A million-fold speed-up changes the category of what is possible.

Why speed matters so much

A slow simulation is not just inconvenient. It changes the kind of engineering and product loop you can support.

If simulation is too slow, then you inevitably do less of the work that actually creates confidence:

• fewer benchmark runs
• fewer disturbance cases
• less replay against history
• slower policy iteration
• weaker pre-deployment validation
• more reliance on intuition and less on evidence

That is why I do not see simulation performance as polish. I see it as infrastructure.

In our world, simulation has to do three jobs at once:

1. represent the customer system credibly enough
2. generate enough throughput for training and evaluation
3. act as the validation gate before live deployment

If it fails on the second point, it usually becomes weak on the third as well.

Why traditional 3D-first workflows break here

The issue is not that 3D is evil. The issue is that in many scheduling problems, 3D detail is simply not the dominant variable.

Scheduling is not a rendering problem. It is a time-and-constraints problem.

What actually drives scheduling quality is usually some combination of:

• job readiness
• precedence constraints
• resource capability
• transport reachability
• buffer occupancy
• tool or fixture availability
• release logic
• queue interactions
• disturbance handling

Those things determine whether the next dispatching decision is good or bad.

A simulator that spends too much of its computational budget on visual state often ends up optimising the wrong abstraction. That may still be acceptable for communication or design review. It is much less acceptable if the simulator is supposed to support control, training, or runtime validation.

Our design principle: simulate what matters for the decision

Our view is simple: if the goal is scheduling, then simulation should be built around the decision problem, not around the rendering problem.

That means we prioritise:

• event-driven progression over heavyweight scene updates
• operational state over visual state
• hard feasibility constraints over unconstrained action generation
• scenario throughput over presentation fidelity
• replayability over showmanship

This is also why I think many people underestimate simulation speed. They treat it as an optimisation detail. It is not. It sits right in the middle of whether modern scheduling intelligence is practical at all.

This matters even more if you believe in learning-based scheduling

As soon as you move toward adaptive, learning-based scheduling, the performance question gets sharper.

You do not get robust policies by running three nice-looking scenarios.

You get them by repeatedly exposing the decision logic to:

• different disturbances
• different mixes
• different release conditions
• different contention patterns
• different historical replays
• different baseline policies

That loop only works if the simulation layer is fast enough to support it.

So when I hear someone say simulation performance is a secondary issue, I mostly hear that they are still thinking in terms of offline studies, not in terms of operational intelligence.

To be clear: this is not anti-visualisation

Visualisation absolutely has a place.

It is useful for communication, debugging, onboarding, and sanity-checking models with customers. We use visualisation too.

But visualisation should serve the operational model. It should not define it.

The mistake is not using 3D. The mistake is treating 3D richness as proof that the simulator is good at scheduling.

Those are completely different claims.

The broader shift I expect

I think the old boundary between simulation software and operational scheduling software is starting to break down.

That is a good thing.

If simulation becomes the place where you:

• model the operating area
• benchmark policies
• replay historical operations
• validate changes before release
• and build confidence before live rollout

then simulation is no longer an isolated project tool.

It becomes part of the control stack.

And once that happens, performance stops being a nice-to-have engineering metric. It becomes a strategic capability.

Final thought

I do not need a beautiful animation of the wrong abstraction.

I need a simulation built around the right abstraction: time, constraints, events, and decisions.

If the scheduling question is temporal, the simulation should be temporal first.

That is the standard we build against.

References and category examples

• Visual Components
• FlexSim
• Simio

These links are included as category examples of established visual simulation platforms, not as claims about any specific customer deployment or benchmark result.