Manufacturing models scoped by the decision they have to support, with the required fidelity derived from that decision rather than chosen in advance.
Test the change before the factory has to live with it.
This distinction is the first conversation to have, and having it properly saves the largest single sum of money available on this page. The two are usually priced as one thing and they are not one thing.
Limited visibility into complex manufacturing systems
A line with ten stations, shared resources, variable cycle times and three product routings cannot be reasoned about on a whiteboard. The interactions are where the behaviour comes from, and intuition handles interactions badly.
Difficulty evaluating production changes before implementation
The change gets made, and then everyone discovers whether it worked. The cost of being wrong is a line reconfiguration and a quarter of lost output.
Uncertain capacity expansion decisions
A capital request built on a spreadsheet of average cycle times will overstate achievable capacity, because averages have no queues in them.
Production bottlenecks and resource constraints
Shared resources, operators covering multiple stations and tooling constraints produce behaviour that no single-station analysis predicts.
High cost of physical experimentation
Trialling a layout change means stopping production. Trialling three means stopping it three times, so in practice only one option is ever tested and it is the one somebody already preferred.
Disconnected engineering and operational data
Engineering has the standard times and the layout. Operations has what actually happens. Models built on the first and validated against nothing are the normal failure mode.
Limited ability to test alternative operating scenarios
The question is rarely one change. It is which of five options, under which demand assumptions, and that comparison is exactly what a model is for.
Model accuracy and real-world synchronisation challenges
A model that was accurate at build time drifts as the line changes. Without an owner and a recalibration trigger it becomes confidently wrong, which is worse than having no model.
Difficulty scaling digital twin initiatives
A model built for one line by one consultant, with undocumented assumptions and no version control, cannot be extended or trusted a year later. This is a documentation and ownership problem rather than a technical one.
Fidelity is a cost. The useful question is how wrong the model can be while still supporting the decision, and that question has a real answer that can be worked out in a conversation.
If the decision is whether to add a station, and the options differ by twenty per cent in throughput, a model accurate to five per cent is sufficient and anything beyond that is spending without buying. If the options differ by three per cent, the model has to be much better or the decision has to be made on other grounds.
Step 1
Digital twin opportunity and feasibility assessment
The decision, the options, the margin between them, and whether the data exists to resolve that margin. Some decisions are not resolvable by simulation and saying so is part of the assessment.
The decision, the options, the margin between them, and whether the data exists to resolve that margin. Some decisions are not resolvable by simulation and saying so is part of the assessment.
Step 2
Manufacturing system and process mapping
Stations, routings, shared resources, buffers, operators and constraints. Mapped from observation as well as from documentation, because the two always differ.
Stations, routings, shared resources, buffers, operators and constraints. Mapped from observation as well as from documentation, because the two always differ.
Step 3
Digital twin scope and fidelity definition
What is in the model, what is abstracted, and the required accuracy derived from the decision margin. Written down and agreed, because this is what the model will be judged against.
What is in the model, what is abstracted, and the required accuracy derived from the decision margin. Written down and agreed, because this is what the model will be judged against.
Step 4
Data source and model readiness assessment
Which distributions are available, which exist only as averages, and which have to be measured. This stage usually generates a short measurement exercise on the floor.
Which distributions are available, which exist only as averages, and which have to be measured. This stage usually generates a short measurement exercise on the floor.
Step 5
Simulation and model architecture design
Model structure, the random elements and their distributions, the warm-up period, the number of replications and how results will be reported with their confidence.
Model structure, the random elements and their distributions, the warm-up period, the number of replications and how results will be reported with their confidence.
Step 6
Digital twin development and integration
Built, with the assumption register maintained as a first-class artefact alongside the model rather than written up afterwards.
Built, with the assumption register maintained as a first-class artefact alongside the model rather than written up afterwards.
Step 7
Model calibration and validation
Calibrated on one period, validated on a different one it has not seen, and validated on the distribution rather than only the mean.
Calibrated on one period, validated on a different one it has not seen, and validated on the distribution rather than only the mean.
Step 8
Scenario testing and decision-support deployment
The options run, compared with confidence intervals, and reported as a range with the assumptions that drive the differences made explicit.
The options run, compared with confidence intervals, and reported as a range with the assumptions that drive the differences made explicit.
Step 9
Continuous model synchronisation and optimisation
For models that remain in use: an owner, recalibration triggers, and version control so that the number in a board paper can be traced to the model that produced it.
For models that remain in use: an owner, recalibration triggers, and version control so that the number in a board paper can be traced to the model that produced it.
Each is named with the decision it exists to inform, since a model without a decision attached is an expensive diagram.
Production line digital twins
A model of a line with its stations, buffers, routings and variability. Supports: capacity, balancing and change evaluation. This is the workhorse and most engagements start here.
Equipment and asset digital twins
A model of a single machine’s behaviour and its interaction with what feeds and follows it. Supports: configuration, duty and replacement decisions.
Manufacturing process simulation
Process steps with their yields, rework loops and quality gates. Supports: understanding how rework consumes capacity, which is usually underestimated.
Discrete-event simulation
The core method for anything with queues, resources and variability. Supports almost every capacity and flow question in manufacturing, and it is where the value concentrates.
Production capacity simulation
Achievable output under a given mix, staffing and reliability, reported as a range. Supports: capital requests, customer commitments and expansion decisions.
Material flow and logistics simulation
Internal movement, storage and handling resource. Supports: layout, handling equipment count and warehouse interface decisions.
Factory layout and resource optimisation
Alternative layouts compared on flow, distance and achievable output. Supports: a layout decision before the floor is marked out rather than after.
What-if scenario modelling
Structured comparison of options under varying assumptions. Supports: any decision where the answer depends on an assumption somebody disputes, which is most of them.
Production scheduling simulation
Sequencing and batching rules tested against the real variability. Supports: a scheduling policy change, which is cheap to make and expensive to get wrong.
Digital twin visualisation and analytics
Results presented so the decision is clear, including animation where it genuinely helps understanding. Budgeted as communication, because visualisation persuades and does not improve accuracy.
Each is stated with its data requirement, because the requirement is what determines whether the question is answerable this quarter or next year.
Production line capacity evaluation
What this line can actually produce under a given mix and staffing.
Bottleneck and throughput simulation
Which constraint binds under which conditions, and what removing it would be worth.
Factory layout optimisation
Comparing layouts on flow, travel and achievable output before anything is moved.
New production line planning
Designing a line to a target rate, with the buffers and station count that make the target achievable.
Production scheduling scenario analysis
Testing sequencing and batching policies against real variability.
Material flow and warehouse simulation
Internal logistics, storage and handling resource sizing.
Equipment configuration evaluation
Comparing machine options, speeds or configurations before purchase.
Maintenance shutdown impact simulation
What a planned shutdown costs in output, and whether a different window or sequence costs less.
Workforce and resource allocation scenarios
Staffing levels, coverage patterns and multi-station operators.
Product mix and demand change simulation
What a shift in mix does to achievable capacity and changeover load.
A simulation model is not just the file. It is the file, the assumptions it encodes, the data it was calibrated on and the version that produced any given result. Delivered as a file alone, it becomes unusable within months and unchallengeable immediately.
Digital twin reference architecture
Model, input data, scenario definitions, results store and assumption register, with the dependency between them explicit so a result can always be traced back to its inputs.
Manufacturing process and asset models
Built per asset class and reused, so a second line of the same type is a configuration rather than a new build. This is what makes a second model cheap.
Discrete-event and physics-based simulation
Discrete-event for flow, queues, resources and capacity, which covers most manufacturing questions. Physics-based only where the decision depends on the physics, since the cost difference is large and the benefit is narrow.
Real-time and historical data integration
Historical data for calibration and validation. Real-time integration only for a live synchronised twin, which is a separate business case under the section 2 distinction.
ERP, MES, PLM, SCADA and historian connectivity
Routings and bills of material from ERP and PLM, order history from MES, event and cycle data from SCADA and the historian. Read-only in every case.
Simulation engines and optimisation algorithms
Selected against the problem class and against what your engineering team can maintain. A model nobody in-house can open is a consulting dependency rather than an asset.
Cloud and edge integration
Scenario runs are compute-heavy and bursty, which suits cloud execution well. Nothing in an offline model needs to run near the plant.
3D visualisation where useful
Animation is excellent for finding modelling errors and for explaining a result to people who will not read a distribution. It does not improve accuracy and it should be budgeted as communication, not as modelling.
Scenario management and model versioning
Every scenario stored with its model version, its inputs and its results. Six months after a decision, the question is always which model produced that number, and without this the answer is unavailable.
Model calibration and validation frameworks
A repeatable calibration and validation procedure with the accuracy criterion from section 3 written into it, so revalidation after a change is a routine task rather than a project.
Simulation models fail quietly. The line changes, the mix changes, a station is added, and the model keeps producing plausible numbers based on a factory that no longer exists. Nothing alerts anybody, because nothing is monitoring it.
Digital twin model ownership
A named owner in engineering for every model that remains in use, responsible for recalibration and for retiring it when it is no longer maintained. An unowned model should be marked as unmaintained rather than left available.
Simulation assumptions and limitations
The assumption register travels with every result. It states what was assumed, what was abstracted away, and what the model is not valid for. This is the deliverable people argue with, which is exactly its purpose.
Model calibration and validation
Calibrated and validated on separate periods, validated on distribution as well as mean, with the validated range stated. Any scenario outside that range is labelled as such on the result.
Data quality and synchronisation
Input data checked for completeness and for the known distortions: excluded exceptional changeovers, downtime recorded against lines rather than machines, and standard times used where actuals were unavailable.
Model confidence and uncertainty
Results reported as ranges with confidence intervals and the number of replications stated. A single number from a stochastic model is a misrepresentation of what the model produced.
Version control and change management
Models, scenarios and input sets versioned together. A result is only reproducible if all three are recoverable, and reproducibility is what makes a model usable in a capital case.
Human review of simulation recommendations
Engineering reviews every result before it informs a decision, and the review covers the assumptions rather than only the output. A model does not make a recommendation; it supports one.
IT and OT cyber security and access controls
Read-only access to operational systems through a controlled conduit. Models and results contain commercially sensitive capacity and cost information and are access-controlled accordingly.
Operational safety and engineering approval
No simulated result is implemented without engineering approval through your normal change process. Nothing we build connects to a control system or alters a machine parameter.
Digital twin lifecycle governance
A register of live models with their owners, last validation date and validated range, reviewed on a stated cadence. This is the control that prevents the quiet failure described in the heading.
A model is a claim about how the factory behaves. The only honest way to maintain it is to keep checking that claim against what the factory actually did.
Model accuracy against actual operations
The primary measure. Predicted against actual output, on periods after the model was built, reported on both mean and spread. A model that has never been checked this way has an unknown accuracy, whatever it was validated at originally.
Simulation execution performance
Run time per replication and total time for a scenario set. It matters because it decides how many options can be explored in a decision cycle, and exploring more options is where most of the value is.
Model synchronisation and data freshness
For live twins only, and it is the measure that makes a live twin expensive. For offline models the equivalent measure is time since last recalibration.
Scenario prediction error
Where a modelled change was actually implemented, the predicted effect against the realised effect. This is the strongest available evidence about the model and it requires deliberately going back to check.
Throughput and capacity simulation accuracy
Specifically on the capacity question, since that is where the model is used for capital decisions and where being optimistic is most expensive.
Model drift and recalibration
Triggered by a change to the line, the mix, the staffing or the equipment, rather than by a calendar. The trigger list is maintained with the model.
Scenario evaluation effectiveness
How many options were evaluated per decision, and whether the chosen option was one the modelling identified. A model that only ever confirms the preferred option is not being used to decide.
User adoption and decision impact
Which decisions used the model, and whether any decision changed because of it. A model that has informed no decision has produced no value, however accurate it is.
Continuous digital twin improvement
The live model register reviewed on cadence: still used, still owned, still valid, still worth maintaining. Retirement is a normal outcome and should be recorded rather than avoided.
Better manufacturing investment decisions, because the capacity number in the capital case has variability in it rather than averages
Reduced risk of production changes, since the options are compared before the floor is reconfigured rather than after
Improved capacity and resource planning, with the answer given as a range and the assumptions that drive it made explicit
Faster evaluation of operating scenarios, which is where most of the value sits: five options assessed in the time it previously took to trial one
Improved bottleneck identification, including the finding that the constraint is often not where the plant believed it was
Reduced physical experimentation cost where a trial would have meant stopping production. Where a trial is cheap, we will say that a trial is better
If you have been quoted for a digital twin, the first question worth asking is which of the two products in section 2 you are buying, and what live decision justifies the second one.
CaliberFocus builds manufacturing models scoped by the decision they support, with fidelity derived from the margin between the options. We separate the offline scenario model from the live synchronised twin, model variability rather than averages, report results as ranges across replications, and deliver every model with its assumption register and validated range.
- The offline model and the live twin scoped as separate products
- Variability modelled from distributions, not average cycle times
- Results reported as ranges with confidence intervals
- An assumption register and validated range with every model
Security & Compliance
