Digital twin and machine safety: when simulation before construction really pays off

The decision to invest in a digital twin for safety should not be driven by a taste for visualisations or by the broad slogan of “project digitalisation”. This work only becomes worthwhile when the model makes it possible to identify in advance what would become a costly modification after construction: a conflict between machine movement and human access, an unclear restart sequence, a poorly designed intervention for a jam, or a zone layout that looks formally correct but in practice encourages people to bypass safeguards. That is why the real question is not whether simulation before construction is worthwhile, but when it actually influences design decisions and helps reduce project risk before it becomes embedded in the design, the control program, and the allocation of responsibilities between suppliers.

The most expensive mistakes happen before assembly

In machine safety, the most costly problems rarely begin at initial start-up. They are usually built in much earlier: in the functional architecture of the machine or line, in the order and interdependence of movements, in the way access to hazardous zones is arranged, in changeover logic, in the operator interventions that have been anticipated, and in the assumptions adopted for maintenance. That is why the value of a digital twin is determined not by the mere existence of a model, but by the point at which it enables a better decision to be made.

If the simulation is available before equipment is ordered, before the workstation layout is frozen, and before responsibilities are finally divided between suppliers, it becomes a tool for reducing project risk. If it appears later, it often only helps organise what has already been determined by dimensions, interfaces, ordered components, and the implementation solutions already adopted. In that case, its impact on safety is naturally limited.

From a project perspective, what matters is not whether the model “shows the machine” well, but whether it reflects decisions that are important for safety. A useful model should show movement sequences, operating modes, points where people enter the process, and the relationships between guards, presence-sensing devices, interlocks, and safety-related control functions. Only then is it possible to verify whether the risk assessment at the concept stage covers real operating situations rather than only the nominal cycle.

At this stage, the questions emerge that become most expensive after construction: will the operator bypass a guard to clear a jam, does the service technician have safe access to adjustment points, does manual mode create an unintended route for bypassing safeguards, does the line layout force entry into the working zone of a neighbouring machine. The greatest value of simulation lies not in predicting everything, but in exposing conflicts between productivity, ergonomics, and safety before they turn into a design change on the shop floor or a dispute with the supplier.

In practice, this is especially clear where guards have to be modified after assembly, sensors relocated, service access corrected, or sequence logic changed because a solution that is formally safe proves unworkable in day-to-day operation. Such a correction is not just a mechanical or programming cost. It also means further workstation design iterations, renewed coordination with production and maintenance, and sometimes a change to assumptions previously adopted in the risk assessment.

That is why the usefulness of simulation should be assessed not through general “digitalisation savings”, but through specific project indicators: the number of access points requiring analysis, the number of operating modes requiring separate assessment, and the number of workstation layout iterations before the final order is placed. These are the measures that show whether the model is really reducing uncertainty where later change is most difficult.

In this sense, a digital twin does not replace either machine conformity assessment or technical documentation. It can, however, prepare the groundwork for later decisions much earlier and bring order to areas that become only more difficult, more expensive, and more contentious after construction.

Where cost and risk really increase

The biggest costs in safety projects rarely come from selecting guards, light curtains, or interlocks alone. They increase when, only after the system has been built, it becomes clear that the actual work performed by people does not fit the assumed machine model. Most problems arise at the intersection of geometry, movement, and process behaviour: where the operator must reach a part, see the status of the cell, enter the intervention area, or perform a task during a brief transitional state.

If these situations are not checked before construction, installation reveals blind spots in visibility, motion collisions, unclear sequences, and access that formally exists but in practice forces awkward or risky work. At that point, risk assessment stops bringing order to the design and becomes a late response to problems already built into the machine.

From the design team’s perspective, the hardest cases are not nominal scenarios but off-nominal ones. These are the situations that most often diverge from the assumptions made in the functional diagram. Clearing jams, cleaning, changeovers, restart after a stop, service access, and operation in special modes rarely proceed exactly as envisaged at the concept stage. In practice, there is often a need to support a component, manually retract an axis, temporarily enter a shared zone, or confirm a restart from a location that does not provide full visibility of the hazardous area.

This is exactly where a digital twin has operational value. It makes it possible to verify whether a protective measure is not only specified, but also workable in real operation. A guard that prevents a maintenance task, a reset button located outside the logical field of view, or access that encourages bypassing safeguards are not minor ergonomic flaws. They are sources of predictable deviations from procedure, and therefore also sources of risk, delays, and later disputes over responsibility.

A good test of whether simulation is justified is a simple case from the line concept stage. Side access was provided to clear jams at the transfer point between two machines, and the reset after intervention was placed at the main control panel. On the drawing, the solution looks correct. Only when the intervention scenario is walked through in the model does it become clear that, after releasing the part, the operator does not have full visibility of the transfer zone, the second machine may already be finishing its own sequence, and reaching the reset requires leaving the location from which the safe state should be confirmed. Before construction, the change usually means adjusting the access location, sequence logic, and confirmation point. After installation, the same change may involve rebuilding guards, cable routes, the control program, and documentation, and with several suppliers it may also require deciding who is responsible for the interface and which part of the installation needs to be modified before responsibilities between suppliers are finally allocated.

That is why it is worth measuring elements that can be quantified: the number of manual interventions per shift, the number of access points, the number of jam-clearing scenarios, and the number of interfaces between machines. These are the factors that show where the lack of prior verification starts to generate cost and ambiguity.

In robotic lines and integrated systems, the value of simulation increases with the number of dependencies. In such cases, risk less and less often arises from a single machine considered in isolation, and more and more often from sequences of interactions: part transfer, release of a shared work zone, mutual readiness confirmation, behaviour after an emergency stop, and the conditions for resuming motion. Without prior verification, equipment can be accepted that appears correct individually but together creates ambiguous transitional states and gaps in responsibility.

If the model is to genuinely support decisions, it should also cover emergency and intervention situations, and its review should involve operators and maintenance personnel. They are the first to spot where the design begins to diverge from real-world practice.

When the investment makes operational sense

Investing in a digital twin makes sense when it helps resolve decisions whose error after installation would be costly mechanically, in controls, or organisationally. What matters, then, is not the sophistication of the tool itself, but whether the model answers the basic design questions: how complex the motion is, how much human-machine interaction there is, how important the special modes are, how extensive the integration of multiple devices is, and how painful a change would be after the system has been built and commissioned.

If the answers point to a large number of transitional states, frequent entry into zones, extensive changeover, cleaning, or jam-clearing tasks, and a high cost of rebuilding guards, drives, or control logic, simulation stops being a “just in case” expense. It becomes a tool for reducing design risk.

That does not mean, however, that every machine requires a full representation of the entire asset. In many cases, a model focused on selected risks is more sensible, defined by the minimum scope needed to make a decision. Sometimes it is enough to check access zones and operator visibility. In another project, the key issue will be the motion sequence during part pick-up, the arrangement of guards and interlocking devices, or the course of service activities during power isolation and restoration.

This narrowing of scope is particularly important at the quotation and concept stage, when the team should primarily eliminate incorrect assumptions rather than build an extensive model with little decision value. So the right question is not whether to build the twin “in full scope”, but what minimum model scope will allow open risks to be closed out before equipment is ordered and the conclusions incorporated into the supplier’s technical requirements.

For a simulation to be useful, decision-making responsibility must also be clearly defined. If it is not clear from the outset which questions the model is meant to answer and who approves the conclusions on the investor’s side and the supplier’s side, the model quickly turns into a presentation with no real impact on the project. Before work begins, it is therefore worth recording whether the simulation is intended to confirm that the guarding concept is acceptable, demonstrate that intervention can be carried out without bypassing safeguards, verify the logic of safe restart after a stop, or reveal points where people and automation come into conflict.

In practice, the best results come from combining the model with a workshop-based analysis of use scenarios carried out jointly by design, automation, safety, production, and maintenance. Participants then do not comment on the graphics alone, but work through normal and abnormal operating scenarios, and conclusions can be closed out in stages: at concept stage, before detailed design, and before acceptance.

• which scenarios must be verified before equipment is ordered,
• which design changes resulted from the model review,
• how many risks remain open after the agreed simulation scope has been completed.

The greatest value therefore lies not in the spatial image itself, but in structuring the design dispute before it reaches the shop floor. If the team is analysing a cell with a robot, conveyor, and manual intervention station, the model should answer very specific questions: does entry into the zone during jam clearing force operators to bypass guards, does restarting after an emergency stop unexpectedly start adjacent equipment from the operator’s perspective, and does service actually have access to adjustment points without removing safeguards.

At this stage, cost categories also become visible that are usually missing from a simplified schedule: rebuilding fences and foundations, changes to wiring and controller inputs, software revisions, additional agreements on responsibility between suppliers, and acceptance delays related to rechecking protective measures. This is also the point at which a decision must be made whether to build the model in-house or require it from the integrator as part of the agreed scope of work, and in some projects also as an acceptance requirement.

To prevent this work from dissolving into a series of meetings, the model scope must be closed out in the documentation. The conclusions from the simulation should feed back into the technical requirements, functional diagrams, assumptions for the instructions, and material supporting the conformity assessment. The digital twin itself does not replace risk assessment or the subsequent CE marking process, but it can organise the input material and reveal where the assumptions behind the control system’s safety functions, zone access, and behaviour in special modes need to be clarified.

First the design decision, then the normative reference

In practice, it is worth keeping a simple sequence: first decide what the model is for, and only then refer to formal requirements. A digital twin is not a standalone means of confirming compliance and does not replace either risk assessment or the later conformity assessment before CE marking. Its role comes earlier and is more practical: to test assumptions, reveal conflicts between technology, access, maintenance, and work organisation, and help design protective measures before they turn into costly rework.

This distinction helps keep both the project and the process in order. If the team treats the model as evidence in its own right, it is easy to collect impressive visuals without translating them into technical requirements, safety functions, operating limitations, and the machine’s technical documentation. For a manufacturer or integrator in Poland and the EU, a simulation becomes useful only when its outcome can be expressed in the language of the project.

The model should lead to specific decisions: where access to the zone is to be located, which operating modes are permitted, when motion may be enabled, which restart conditions are acceptable, and which assumptions must be explicitly transferred into the acceptance requirements. This is also the right place to divide responsibilities between suppliers. The digital model remains a design tool, risk assessment is the process of identifying hazards and selecting risk reduction measures, and conformity assessment is the formal confirmation that the applicable requirements have been met. Mixing up these layers usually results in a large amount of material with little value for acceptance.

A good example does not have to involve advanced technology. An ordinary cell with automatic part feeding and occasional operator entry to clear jams is enough. The model revealed that the originally planned service access required an unclear stop and restart sequence and, at the same time, encouraged operators to work around the intended operating assumptions in manual mode. So before the structure was built, the concept was changed: the access point was moved, the sequence of actions was simplified, and short interventions were separated from full entry into the zone. The simulation itself did not “approve” anything, but it made it possible to take a decision earlier that reduced later mechanical rework, clarified the requirements for the control system, and simplified the discussion about the responsibilities of the manufacturer and the integrator for the adopted solution.

Only at this stage does a normative reference make practical sense. The model outputs should feed into the risk assessment, the description of the protective measures adopted, the assumptions for the instructions, and the technical documentation. In practice, it is worth keeping not just the animation, but the decision trail: the model version, the scope of the simplifications adopted, operating and intervention scenarios, collisions identified in the simulation, the design decisions made on that basis, and information on who is responsible for keeping the model up to date after design changes.

In the conformity assessment process, such material does not replace verification on the real machine, but it does structure the rationale for why a given solution was adopted and where it was considered in the risk assessment. This is particularly important in multi-supplier projects, where the lack of a consistent decision trail quickly turns into a dispute over the scope and cost of changes.

The conclusion is straightforward. Simulation is worth investing in not because it has become a mandatory part of project presentations, but because some safety errors are inexpensive only while they still exist solely in the design. If the model helps make decisions on access architecture, work sequence, safety functions, and limits of use, it genuinely supports the risk assessment and preparation for conformity assessment. If it ends at visualisation, without being translated into technical requirements and the manufacturer’s or integrator’s documentation, it becomes a cost that does not shorten the path to acceptance and does not improve machine safety.