1. Introduction
A job shop with a dozen machine tools, some of them older than the people who run them, is now told that it needs a digital twin. The advice comes from equipment vendors, software houses, trade fairs and public support programmes, and it is seldom accompanied by a clear statement of what the thing is. The owner who asks finds that one supplier means a three-dimensional model of the factory, another a screen showing spindle load, and a third a subscription service that promises to predict failures.
The confusion is not only commercial. The concept was introduced for product lifecycle management, as a virtual counterpart linked to a physical product by flows of data and information (Grieves, 2014), and was taken up for aerospace vehicles as an integrated, high-fidelity simulation that mirrors the life of its flying twin (Glaessgen and Stargel, 2012). Since then the academic literature has multiplied definitions, and reviews continue to report that there is no settled one (Negri et al., 2017; Jones et al., 2020).
This perspective takes the position of the small manufacturer and asks what, out of everything offered under the name, such a firm has reason to want. The argument is that the answer is less than a twin and that saying so plainly would serve these firms better than the present vocabulary does.
2. A Term That Has Outgrown Its Meaning
The most useful clarification in the literature is the three-way distinction drawn by Kritzinger et al. (2018). A digital model has no automatic data exchange with the physical object. A digital shadow receives data automatically from the object but does not act on it. A digital twin exchanges data automatically in both directions, so that a change in either is reflected in the other. Their review found that much of what was published as digital twin research was, by this test, concerned with models or shadows. Wright and Davidson (2020) make a related point: a model does not become a twin by being detailed, only by being kept in step with a particular physical thing.
The distinction matters for a small firm because cost rises sharply from one level to the next. A model can be built once on a laptop. A shadow needs connected machines and a place to keep the data. A twin needs, in addition, a route by which the model's output changes what the machine or the schedule does without a person in between, and the confidence to let it. The reference architectures written for cyber-physical production systems describe that last step as the top of a pyramid whose lower levels are connection and conversion of data into information (Lee et al., 2015). Most small manufacturers stand at the bottom of it.
Standardisation has begun to give the term a firmer shape. ISO 23247 sets out a framework for digital twins in manufacturing, with entities for data collection, device control, the twin itself and its users (ISO, 2021). It is a framework and not a product specification, and it leaves open how much of the structure a given application needs. That openness is an opportunity. A small firm can use the framework's vocabulary to describe a modest system exactly, and to ask a supplier which entities an offer actually contains.
3. The Starting Point of a Small Manufacturer
Research on Industry 4.0 in smaller firms describes a consistent situation. Moeuf et al. (2018) found that reported applications in such firms were concentrated on monitoring and on a few low-cost technologies, with little evidence of the advanced uses that fill the general literature. Mittal et al. (2018) examined the maturity models used to assess readiness and concluded that they presuppose a starting level that many small firms have not reached, so that the lowest rung of the ladder is already above them. Neither finding is a criticism of the firms. They describe organisations with limited capital, few specialised staff, a mixed machine park and a short planning horizon.
The published demonstrations of manufacturing twins start from another place. They assume machine controllers that expose their data, a manufacturing execution system that knows where every order is, engineering models of products and resources, and people to maintain all of it (Tao et al., 2019; Cimino et al., 2019). The gap was recognised early. Uhlemann et al. (2017) observed that the lack of real-time data acquisition was the practical obstacle to digital twins in smaller production systems. The vision of autonomous, self-organising production in which the twin is one component (Kagermann et al., 2013; Rosen et al., 2015) is a long way from a shop where job progress is tracked on paper travellers.
4. What These Firms Need
If the label is set aside and the question is put in terms of decisions, the needs of a small manufacturer can be stated in four parts. Figure 1 arranges them as a stack that is built from the bottom and justified from the top, and Table 1 contrasts each need with what is commonly offered in its place.
| Need | What is sufficient | What is often offered instead |
|---|---|---|
| Know the present state | Automatic record of machine states and order progress | Three-dimensional factory visualisation |
| Answer one planning question | Simple capacity or flow model fed by recorded data | General simulation platform needing specialist modellers |
| Keep the data usable | Open protocols and export in plain formats | Proprietary platform with data held by the vendor |
| Sustain the system | A named employee who owns data and model | Remote service with no internal competence built |
| Grow when justified | Framework vocabulary to specify the next step | Full twin architecture bought in advance of need |
4.1. A trustworthy record of the present
The first need is to know, without walking the floor, which machines are cutting, which are waiting and why, and where each order stands. This is a digital shadow of machine states and order progress, and nothing more. It can be obtained from modern controllers through open interfaces such as OPC UA and MTConnect, and from older machines by retrofitting a current sensor or reading a stack light. Its value lies in honest figures for availability, performance and quality, the three factors of overall equipment effectiveness as defined by Nakajima (1988). Many firms that believe their machines are busy discover otherwise when the stoppages are recorded automatically.
4.2. A model tied to one decision
The second need is a model, and it should be chosen by the decision it supports. For a job shop the decision is usually one of a few: what delivery date to promise, which order to release next, whether a second shift or another machine is warranted, when to take a machine down for maintenance. Each can be served by a simple model fed by the recorded data: a capacity calculation, a discrete-event simulation of the main routings, a trend of a condition indicator. None requires a physics-based replica of the machine tool. Schleich et al. (2017), writing about product twins, stress that a twin should be judged by properties such as fidelity and scalability relative to its purpose. Purpose comes first, and for these decisions the fidelity required is modest.
4.3. Interfaces that keep the data the firm's own
The third need is protection against dependence. A small firm cannot afford to rebuild its data infrastructure when a supplier changes its pricing or disappears. Machine data should leave the controller through a published protocol, be stored in a form the firm can read without the supplier's software, and be exportable in full. This is less a technical demand than a contractual one, and it is the point at which the vocabulary of ISO 23247 becomes useful in a purchase specification (ISO, 2021).
4.4. Ownership inside the firm
The fourth need is a person. A model that nobody in the firm understands will drift away from the shop it describes, because routings change, machines are moved and new products arrive. Keeping model and reality in step is the defining task of a twin (Wright and Davidson, 2020), and in a small firm it falls to an individual with other duties. The system should therefore be simple enough for a production engineer or a capable supervisor to maintain, which is a further reason to prefer modest models over elaborate ones.
5. Objections
Three objections deserve an answer. The first is that cloud platforms have removed the cost barrier, so that a small firm can now rent what it could never have built. This is partly true for computing and storage. It is not true for the work that dominates the effort: connecting old machines, cleaning master data, and describing routings and resources accurately enough for a model to be believed. That work is local and cannot be rented. A rented platform also sharpens the dependence discussed above.
The second objection is that large customers will require digital twins from their suppliers, so that a firm which settles for a shadow will be excluded. Customers do increasingly ask for digital evidence about parts and processes: inspection results, traceability, process records. These are data deliverables. They are met by the record-keeping layer described here, and a firm that has that layer is well placed to meet a customer's format when one is specified. A requirement for a bidirectionally coupled model of a supplier's shop is a different matter and would raise questions of confidentiality that few suppliers would accept.
The third objection is that modest tools forgo the larger gains: optimisation in real time, autonomous rescheduling, prediction of quality before the part is cut. The gains may be real where the foundations exist. The argument here concerns sequence. Every one of those functions depends on reliable data and a maintained model, and a firm that builds those first loses nothing by adding closed-loop functions later. A firm that buys the functions first tends to find that they run on data nobody trusts. The staged view is consistent with the layered architectures in the literature (Lee et al., 2015) and with the observation that most reported twins are not yet closed-loop (Kritzinger et al., 2018).
6. Implications
For owners and managers, the practical advice is to begin with a question and not with a technology. A statement such as "we do not know why the horizontal machining centre stands idle" leads to a small, testable project. A statement such as "we need a digital twin" leads to a procurement exercise with no criterion of success. The second step is to insist on open interfaces and exportable data in every purchase, including new machine tools, whether or not a monitoring project is planned.
For vendors, the implication is that honest naming would help the market. A monitoring product is a digital shadow, and calling it that would let buyers compare like with like. Products designed for the small firm should assume a mixed machine park, no dedicated information technology staff, and an engineer with an hour a week to spare. For public programmes that subsidise digitalisation, the implication is that support for data foundations and for training a person inside the firm is likely to last longer than support for a showcase installation.
For researchers, there is an evident gap. The literature is rich in architectures and thin in accounts of what the simplest useful configuration is, what it costs a small firm to keep running, and how the benefit is to be measured (Mittal et al., 2018; Jones et al., 2020). Work that specified minimal configurations against the entities of ISO 23247, and reported the effort of maintaining them over time, would give the small manufacturer something to act on.
7. Conclusion
Small and medium manufacturers are poorly served by a term that covers everything from a status light on a screen to an autonomous factory. Measured against the definitions in the literature, what most of them need first is a digital shadow of machine states and orders, one simple model that serves a decision they already face, open interfaces, and an employee who owns the system. That is a smaller ambition than the one on offer, and a more useful one, because each part can be bought, tested and judged on its own. A true twin, with the loop closed, remains available as a later step for the firms and the processes that can justify it.
Conflict of interest
To be declared by the author(s) before publication.
Funding
To be declared by the author(s) before publication.