1. Introduction
Supervisors and planners on a shop floor make a steady stream of decisions with incomplete information: which job to release, whether to hold a machine for maintenance, how to reroute work around a breakdown, when to stop a process that is drifting. Simulation has long been used to study such questions off line (Negahban and Smith, 2014). The digital twin proposes to bring the model to the decision, by keeping it synchronised with the plant so that its answers refer to the situation as it stands and not to an average week.
The idea arrived in manufacturing together with the wider programme of cyber-physical production systems and Industrie 4.0 (Kagermann et al., 2013; Monostori et al., 2016). Publications multiplied quickly, and with them the meanings of the term. Vendors apply it to three-dimensional plant models, researchers to anything from a spreadsheet fed by sensors to a self-adjusting production cell. For someone who must decide whether to invest, the useful questions are plain ones. They concern what kinds of twin exist, how mature they are, what stands in the way, and what is still unknown.
This review takes up those questions for one field of use, decision support on the shop floor. It leaves aside twins of products in service and of supply networks except where they clarify the concept.
2. Scope and Approach
The article is a narrative review. It is built on the review papers and conceptual contributions that are most often used as reference points in the manufacturing literature, on the international standard for digital twins in manufacturing, and on older work in simulation and human-automation interaction that the digital twin literature tends to overlook. It does not attempt a systematic search and makes no quantitative claims about the number or distribution of publications. Where it reports how reviewers have characterised the field, the characterisation is theirs.
3. Concept and Definitions
Grieves (2014) attributes the concept to his teaching on product lifecycle management in the early 2000s and describes it as having three parts: a physical product, a virtual product, and the connections of data and information that tie them together. The term itself gained currency through aerospace. Glaessgen and Stargel (2012) defined the digital twin of a vehicle as an integrated, multi-physics, probabilistic simulation that uses the best available models, sensor updates and fleet history to mirror the life of its flying counterpart. Grieves and Vickers (2017) later stressed its use for anticipating undesirable behaviour before it occurs in the physical system.
Manufacturing researchers adapted the idea in several directions. Rosen et al. (2015) presented the twin as the carrier of the knowledge that autonomous production modules need in order to plan their own actions. Schleich et al. (2017) proposed a reference model for design and production engineering and named scalability, interoperability, expansibility and fidelity as its required properties. Tao and Zhang (2017) described a digital twin shop floor made up of the physical shop floor, its virtual counterpart, a service system and the data that fuse them, and Tao et al. (2018) set the idea within data-driven design, manufacturing and service. Surveys of definitions by Negri et al. (2017) and of industrial practice by Tao et al. (2019) document how far usage had diverged within a few years.
Two contributions brought order. Kritzinger et al. (2018) classified implementations by the direction and automation of data flow. In a digital model, data pass between the physical and the digital object only by manual transfer. In a digital shadow, data flow automatically from the physical object to the digital one. Only when the flow is automatic in both directions, so that a change in the digital object can alter the state of the physical one, do they speak of a digital twin. Jones et al. (2020) derived a set of characteristics from the literature, among them the physical and virtual entities, their environments, the parameters exchanged, fidelity, and the twinning process and its rate. The standard ISO 23247 gives a framework for manufacturing with a reference architecture and requirements for representing manufacturing elements and exchanging information (ISO, 2021). Wright and Davidson (2020) add a caution: a model is not a twin unless it is tied to a particular existing object and updated from it.
4. Decisions a Shop Floor Twin Can Support
Four groups of decisions recur in the literature. The first is scheduling and dispatching, where a synchronised simulation is used to evaluate alternative job orders or routings from the actual state of queues and machines. The second is maintenance, where the twin combines condition data with models of degradation to advise when to intervene; this is the use closest to the aerospace original. The third is process and quality control, in which a model of the process predicts the outcome of the current settings and suggests corrections. The fourth concerns changes to the system itself: layout, the introduction of a new product, and virtual commissioning of control software before it is loaded on real equipment.
The architecture that underlies these uses is described in similar terms by different authors. The five-level scheme of Lee et al. (2015) for cyber-physical systems runs from connection and data conversion through a cyber level, where the twin resides, to cognition and configuration, where decisions are presented or enacted. Uhlemann et al. (2017) concentrate on the lowest levels and on the acquisition of production data, which they treat as the precondition that smaller firms most often lack. Reviews with an applications focus, such as those of Cimino et al. (2019) and Liu et al. (2021), indicate that monitoring and prediction are reported more often than closed-loop control.
5. Maturity
Maturity can be judged along two lines. One is integration, for which the classification of Kritzinger et al. (2018) serves well. Applying it to the publications they examined, those authors found that most described concepts and not implementations, and that what was implemented was more often a digital model or a digital shadow than a twin in their strict sense. Later reviews have not overturned that reading. Cimino et al. (2019) observe that the applications they analysed were seldom integrated with the plant's control and execution systems, and Fuller et al. (2020) list the enabling technologies that are still immature.
The second line is the kind of help the twin gives. Human factors research offers a framework that the digital twin literature rarely cites. Parasuraman et al. (2000) divide a task into information acquisition, information analysis, decision selection and action implementation, and observe that each may be automated to a different degree. A twin that displays the state of the shop automates acquisition. One that forecasts queue lengths or remaining tool life automates analysis. One that ranks alternative schedules automates part of decision selection, and one that releases the chosen schedule to the machines automates action. The Industrie 4.0 Maturity Index describes a comparable progression at company level, from visibility through transparency and predictive capacity to adaptability (Schuh et al., 2017).
Table 1 combines the two lines into five stages, and Figure 1 pairs each stage with the barrier that most often holds an implementation there. The stages are a reading aid proposed in this review and not an established scale.
| Stage | Data flow, plant to model | Data flow, model to plant | Role in the decision |
|---|---|---|---|
| Offline simulation model | Manual, occasional | None; results read by analysts | Studies of design and policy, not of today's situation |
| Digital shadow | Automatic | None | Shows current state; acquisition automated |
| Advisory twin | Automatic | Recommendations on a screen | Forecasts and what-if comparison; human chooses |
| Supervised twin | Automatic | Automatic after human approval | Proposes and executes the action once it is confirmed |
| Autonomous twin | Automatic | Automatic | Selects and implements within set limits; human monitors |
6. Barriers
The reasons why implementations stop short of the later stages fall into four groups.
6.1. Technical barriers
A shadow needs data, and plants contain machines of many ages and makers, a good number of which expose little beyond a few signals. Retrofitting sensors and gateways is feasible but laborious, and the data then have to be cleaned, time-aligned and given context from the execution and planning systems. Uhlemann et al. (2017) identify this acquisition layer as the first obstacle. Interoperability is the second. Models built in one simulation tool do not readily exchange state with another vendor's execution system, which is the gap that ISO 23247 and related efforts aim to close (ISO, 2021). Closing the loop adds requirements of latency, reliability and cyber security that monitoring does not impose.
6.2. Methodological barriers
A twin used for decisions must be valid for the decision at hand and must stay valid as the plant changes. Both conditions are hard. Simulation models of production systems are costly to build and age quickly as products, routings and staffing change, which is a long-standing concern of the simulation literature (Negahban and Smith, 2014). Automatic updating of parameters from data helps with processing times and failure rates but not with changes of structure. Rasheed et al. (2020) argue that neither purely physics-based nor purely data-driven models are adequate and that hybrids are needed, and Wright and Davidson (2020) stress that predictions without stated uncertainty invite misplaced confidence. Shao and Helu (2020) draw the practical conclusion that scope and fidelity should be fixed by the purpose and not by the ambition to mirror everything.
6.3. Organisational and economic barriers
A recommendation that planners do not trust will not be followed, and one that they follow blindly is dangerous when the model is wrong. The human factors literature on automation describes both failures (Parasuraman et al., 2000), and they apply directly to advisory and supervised twins. Responsibility also needs settling: if the twin releases a schedule that causes a late delivery, the plant must know whose decision that was. On the economic side, the costs of connection, modelling and upkeep are borne early and locally, while the benefits are diffuse and hard to attribute. The reviews consulted here report few studies in which the benefit of a shop floor twin was measured against a baseline, a gap that Jones et al. (2020) also record.
7. Open Questions
Several questions follow from this reading of the literature. The first concerns fitness for purpose. If a dispatching decision needs only queue lengths and due dates, a high-fidelity model adds cost without adding value. A method for deriving the least model that supports a given class of decisions would do more for adoption than further reference architectures.
The second concerns validation in operation. A twin could in principle check itself by comparing its forecasts with what subsequently happens, and withdraw or flag its advice when the two diverge. How such self-monitoring should be designed, and what divergence is tolerable for which decisions, is largely unexplored. The third is the allocation of functions between twin and human. The stages in Table 1 are not a ladder that every plant should climb; for many decisions the advisory stage may be the right place to stop, and the conditions under which more automation helps need study with real users. The fourth is evidence. Controlled comparisons of decisions made with and without a twin, in plants and not only in laboratories, are needed before claims of benefit can be assessed. A fifth question is how smaller firms, which lack modelling staff, can obtain and maintain twins at all.
8. Conclusion
For shop floor decision support the digital twin is better established as a concept than as a practice. The literature offers workable definitions, a standard, and a clear way of telling a model from a shadow and a shadow from a twin. Measured by integration, and by the stage of the decision that is automated, most reported systems inform people and few act. The barriers that explain this are partly technical and yielding to effort, such as connectivity, and partly more stubborn: keeping models valid, fixing responsibility, and showing that the investment pays. Progress now depends less on new architectures than on purpose-driven modelling, validation in use, and measured comparisons.
Conflict of interest
To be declared by the author(s) before publication.
Funding
To be declared by the author(s) before publication.