Manufacturing Operations Twin

A production manager asking whether to add a machine, add a shift or move a buffer is asking a question that averages cannot answer. Line output is decided by the interaction of cycle times, failure distributions, buffer capacity, operator availability and material supply, and those interact in ways a spreadsheet flattens. The constraint is frequently not where the utilisation figures suggest, and it moves as soon as it is relieved.

This system was built to demonstrate that class of question being answered from a running model. It is an internal system built and published by Alsadaany Industries. It is not a customer deployment, and the operation it models is illustrative.

A facility of three production lines, twenty-eight machines, thirty-eight people, four forklifts, a raw-material warehouse and a finished-goods dock. Units are released against a plan, travel a route of buffered stages, and are inspected, packed and shipped.

Each line is deliberately balanced so exactly one stage is its constraint, and the three constraints are different in kind: two assembly stages and one CNC machining stage. Each line also carries a standby cell at its constraint, offline at start, so the effect of commissioning capacity can be measured rather than argued.

Machines are state machines with a cycle time, an efficiency, a reliability, a maintenance schedule and six operating states: idle, processing, blocked, starved, breakdown and maintenance. Blocking and starvation are consequences of the model rather than parameters of it, which is what makes them useful readings.

Work in progress is physical: the units drawn on a conveyor are the units the model says are on it. Operators staff machines, technicians walk to failures rather than teleporting to them, and forklifts move stock between the warehouse, the lines and the dock. Any of the three can become the thing that limits output, and in a plant that is under-resourced in logistics rather than in machinery, the forklifts are what binds.

The plant runs continuously against a seeded random number stream, at time scales from 1x to 25x. Overall equipment effectiveness is decomposed into availability, performance and quality rather than reported as one number, because the three have different remedies.

The current constraint is found from stage capacity and corroborated independently by queue depth. Where the two disagree the model is telling you something about transient behaviour, which is the case a static capacity calculation cannot represent at all.

The simulation is separated from the renderer: the model runs, and can be tested, with no scene present. The scene is a viewer over model state, which is the same separation the satellite twin makes between its Python engine and its Unity client.

The plant, its equipment and its order book are defined as data rather than written into code, so a different facility is a different dataset rather than a different build.

A representative four-hour baseline run delivers 3,938 units at 985 units/hour against a designed ceiling of 1,055, with overall equipment effectiveness at 89.1 per cent, availability 98.7, performance 93.1 and quality 96.9. Machine utilisation sits at 66.2 per cent, downtime at 1.3 and blocking at 2.5, with starvation at 26.5 per cent and the constraint reported as a specific CNC machine.

Those figures describe this model. They are not a benchmark, a customer result or a claim about any real plant, and the value in them is that starvation at 26.5 per cent against blocking at 2.5 is a diagnosis: the line is waiting for material far more than it is waiting for the next stage. That is a supply and logistics finding, not a machine capacity finding, and it is the kind of conclusion a static calculation does not produce.

The scenario lab answers a capacity or staffing question by instantiating two complete additional plants from an identical starting state, one as configured and one with the proposed change, running both, and comparing the outcomes. The reported impact is measured rather than estimated.

Unity 6 with the universal render pipeline. A deterministic clock and seeded random number generator, plant and equipment definitions as data assets, a discrete-event core for production and machine state, agent behaviour for workers and vehicles, and a separate analysis layer for KPI, OEE, bottleneck detection, events and alerts.

The plant is illustrative and does not represent a real facility. Nothing in it has been calibrated against a real operation's history, so its absolute numbers carry no external meaning and are useful only as a demonstration of the mechanism.

It has no live data connection. A deployment reads its state from the systems the operation already runs, and that integration is engineering work scoped per site rather than a feature of this build.

The scenario lab compares configured alternatives. It does not search a design space, which is a different problem and is treated as such on the platform page.

Demonstration. Built, runnable and published so the modelling can be examined. It is the closest of the four public systems to the shape of a manufacturing deployment, and it is a demonstration rather than a product or a deployment.