AR visualization of industrial equipment: where the process breaks
AR visualization of industrial equipment does not hinge on the headset or the hardware, but on the gap between documentation and the actual shop floor.
The procedure was written for the design configuration, while the site has three modifications of the assembly, some valves were replaced during the first repair, and cable routes were rerouted.
The operator opens the diagram on a tablet, sees what is no longer in the shop, and then acts from memory.
The second failure point is training. Visual instructions for operators live in slides and paper posters disconnected from a specific machine.
A new employee becomes ready for a shift in weeks, not days: each operation has to be demonstrated live and reinforced under the supervision of a mentor who is pulled from production.
The third is installation and maintenance. Assembly from memory produces errors that are not visible immediately: mixed-up tightening sequence, a skipped calibration step, the wrong assembly during replacement.
Each such error means line downtime and unscheduled repair, and the cause is discovered only after a failure.
Augmented reality in manufacturing closes exactly this gap: the model is anchored to real equipment, and process visualization shows the step on a specific assembly in its current configuration. We break down how this is addressed.
What changes after implementation: speed, errors, downtime
An operator becomes able to work independently in 3–4 shifts instead of two or three weeks of internship with a mentor: the step-by-step overlay lands on the assembly itself, not on a page of instructions, and highlights the next action at the right point.
An error is visible before the fastener is removed — the scene does not allow the step to be confirmed if the position does not match the reference geometry.
A mentor is no longer required on every shift, and clearance is issued by a formal criterion: how many operations the person completed without prompts.
In installation and maintenance, the effect is measured by the share of errors: mixed-up positions, under-tightened connections, and missed scheduled points move from regular to isolated.
The marking is anchored to the assembly geometry, so in a disputed situation the scene shows the reference point and tolerance — there is no need to check against a drawing from another revision.
In an emergency, downtime is reduced from hours to tens of minutes: the operator points the camera at the assembly, sees the failure point, and transmits the image to a remote engineer, who views the same field and guides them through the steps.
Remote commissioning covers typical startups without travel — a site visit remains where physical intervention is needed, not where an explanation was lacking.
The effect rests not on a demonstration scene, but on versioning: content is tied to the equipment revision, the session log records who, when, and according to which version performed the work, and reporting is reduced to data compatible with the requirements of ISO 55000.
When a new revision is released, the geometry and reference points are updated — all content is not re-released from scratch.
Work formats: tablet, glasses, stationary stand
The choice of format is determined by the site, not by the capabilities of the technology.
The same digital twin of an assembly can be shown on a tablet, in augmented reality glasses, or on a stationary stand — but their demonstration scenario, network requirements, and number of simultaneous viewers differ.
A mobile augmented reality application covers field scenarios, glasses free the engineer’s hands, and the stand provides controlled lighting and a stable scene for a group. Below is a comparison by site conditions and the limitations of each mode.
| Format | When it fits | Limitations |
|---|---|---|
| Mobile augmented reality application (tablet, smartphone) | Customer site visits, demonstration in the shop, one or two viewers | Requires space to walk around the assembly; in bright sunlight, recognition relies on markers |
| Augmented reality glasses | Hands-free: assembly, maintenance, step-by-step training | More expensive across the device fleet, calibration is needed for each employee, some people get tired during prolonged wear |
| Stationary demonstration stand | Exhibitions, showroom, presentation for a group | Tied to the site; a separate kit is needed for a second facility |
Offline operation is designed separately: models and markings are packaged into the application, recognition runs locally on the device, and connectivity is needed only to update the catalog and upload demonstration statistics. At a site without stable internet, the demonstration does not depend on external services.
Implementation stages: from scenario audit to handover
The work proceeds in fixed stages, and each is closed with an artifact that the customer can verify before the next weeks are invested in the project.
The order is arranged so that errors in the scenario or in the model geometry surface in the diagram and in the test build, not at the site during operation.
-
Visualization scenario audit. We analyze which tasks the scenario solves: personnel training, assembly maintenance instructions, customer demonstration. We record the list of assemblies, the order in which they are shown, and the points where the employee makes a decision. The output is an agreed list of scenarios with priorities.
-
Placement diagram and scene composition. We determine where the scenario is launched, how the employee approaches the equipment, and what enters the field of view.
The diagram shows which assemblies are displayed and which are hidden by the housing so as not to overload the image.
-
Three-dimensional equipment models. We build models from drawings and on-site measurements, bringing them to a unified scale and coordinate system. Excess geometry is removed — this noticeably reduces build weight and launch time on low-end devices.
-
Anchoring of virtual objects. Models and labels are anchored to real assemblies: by markers, by characteristic housing features, or by site coordinates. We check anchoring stability under changing lighting and partial equipment occlusion.
-
Build and internal verification of scenes. Scenarios are assembled into a single application and run on a test device fleet — the same models as those in operation. We observe behavior under low light, vibration, and route walkthroughs.
-
On-site verification. Engineers travel to the equipment, walk through the scenarios together with personnel, and correct anchors and step sequences based on actual feedback.
-
Acceptance and project handover. We hand over model source files, the anchoring diagram, the build for the required platforms, and instructions for personnel. We separately describe the procedure: how to update models and anchors when equipment is upgraded.
This order leaves the customer with control points at every step, rather than a single final demonstration of the finished application.
What the customer receives: scenes, models, procedures
We hand over not a built application “as is,” but a project that your team can develop without us: source files, anchoring diagrams, and the rules by which the content continues to live. Below is the composition of the package that we record in the acceptance act.
- Source files of three-dimensional scenes — working projects of models and environments in open exchange formats, plus texture sets at the original resolution, not only final exports.
- Coordinate and anchoring diagram — how the scene relates to real equipment: anchor points, scale, axis orientation, tolerances for marker displacement during installation.
- Content update procedure — what changes and in what order when an assembly is replaced or a unit is revised: where the model is edited, how the scene is rebuilt, and which checks are performed before release.
- Project access rights — roles and visibility scopes: who publishes the scene, who edits the model, who sees only view statistics. Keys and accounts remain with you.
- Documentation for engineers — project structure, dependencies, integration points with your equipment accounting system, and the update release procedure.
- Instructions for front-line personnel — how to attach and calibrate the marker, what to do when recognition is lost, and where to report a failure.
- Test environment and change log — the scene version used for verification and the method to roll back to the previous one if something goes wrong at the site.
Such a package removes the main risk: adding a new assembly or updating a model no longer depends on us — it is done by your team according to the described procedure.
Case study: how shift operator training time was reduced
On an industrial gearbox assembly line, an operator became able to work an independent shift after nine training shifts: instructions in paper folders, a mentor nearby, and in case of deviation from the standard scenario, a stop and a call to the supervisor.
During the first month in the role, a newcomer contacted technical support about 40 times, and the error rate in installing the sealing assembly reached 7% — each miss meant disassembly and reassembly.
What we did
We digitized three key assemblies and anchored step-by-step prompts to reference points on the housing: the instruction is overlaid on real equipment rather than existing as a separate document.
The scene marking was built on Vuforia — markers are readable under shop lighting, and the part position is monitored during movement. The content works without a network connection: the signal in the shop is unstable, and the prompt must appear within seconds.
We added step control — transition to the next operation opens only after confirmation of correct installation of the previous element. Every action is written to the log, and the supervisor sees exactly where the newcomer stopped and what they returned to.
Metrics before and after
- onboarding time: 9 shifts → 3;
- technical support requests in the first month: 40 → 11;
- error rate in sealing assembly: 7% → 1.5%;
- line downtime during changeover: 90 minutes → 35.
The longest part to agree on was not the visual part, but the verification rules: process engineers described which deviations are permissible and which require a stop. It was this part that delivered the main effect — the prompt stopped being a reminder and became control.
Augmented reality or 3D configurator: what to choose
The question is not which technology is more modern, but where the person is at that moment.
Augmented reality and a three-dimensional configurator cover different stages: the former when the equipment is already installed at the site, the latter when the layout is still being discussed at the table.
Augmented reality anchors layers to the real machine: recognized geometry provides a reference point, and on top of it are displayed the disassembly sequence, hidden assemblies, and maintenance zones.
The engineer sees the next step on the installation itself, not in the instructions. This is where the main effect comes from — fewer errors during installation and commissioning.
A three-dimensional configurator solves the opposite task. Interactive equipment diagrams are assembled into variants: a different layout, a different set of modules, checking passages and access to assemblies.
This is a conversation with the customer in a meeting room — without a site visit and without a physical sample, with the variant changed directly on the screen.
The choice of visualization format comes down to two questions. Is the configuration changing, and how many variants need to be compared — then use the configurator. Is it necessary to guide personnel at a specific piece of equipment — then use augmented reality.
Sometimes both tools are needed, and they do not duplicate work. Industrial platforms such as PTC build both interfaces on a single model: the configurator coordinates the layout, and the same data set becomes a layer for installation, adjustment, and service. A model edit reaches both scenarios.
Technical concerns: accuracy, updates, integrations
Any AR visualization implementation comes up against four questions: whether the model will align with the real hardware, what to do when the layout changes, how to work in the shop without a network, and what will remain with the customer after the project. Below is how we address each of them at the level of a solution, not promises.
How do you ensure the model aligns precisely with the real unit?
Anchoring is based on reference points on the housing and supporting structures, not “by eye” from the camera. During commissioning, we calibrate the scene for each unit: we keep contour discrepancy within several millimeters on assemblies and centimeters on overall piping.
When a unit is replaced with an equivalent of different geometry, the anchor point is rechecked — the scene does not “drift” over time.
What happens when the line layout changes or an assembly is replaced?
We assemble the scene from a description: layout, assemblies, labels, and operation sequence are stored in a separate configuration file rather than hardcoded into the application build.
An update is an edit of the description and a new version of the scene, while the previous one remains available for rollback. There is no need to rebuild and reinstall the application across the device fleet.
How does the application work at a site without internet?
Scenes, models, and reference data are preloaded onto the device when preparing for a shift, so everything works locally in the shop.
Marks about completed operations and photo documentation accumulate in a queue and are sent to the accounting system when connectivity appears — data is not lost or manually re-entered.
What remains with the customer, and how is it connected to accounting systems?
We hand over project source files, scene descriptions, build scripts, and anchoring documentation — support can be carried out by your own team.
Exchange with the accounting system goes through a service layer: the equipment card, request statuses, and operating hours are pulled into the scene, and inspection results are returned back.
Let’s discuss the task: what inputs are needed for an estimate and plan
To come back with an estimate and work plan, rather than follow-up questions a week later, we need a minimal set of inputs. Below is what actually affects the project scope and labor intensity: from the availability of three-dimensional models to acceptance criteria.
- List of equipment and models: whether three-dimensional models exist or only drawings; if there are no models, we determine which assemblies to digitize and with what level of detail.
- Scenarios: what the user does in the application — points at an assembly and sees status, follows a step-by-step repair instruction, or trains on a simulator.
- Users and device fleet: phones, tablets, or glasses, which platforms, and how the application gets onto the devices.
- Integration points: where to get actual readings from — dispatch systems, telemetry archives, accounting systems, and whether they need to be displayed over the model.
- Site conditions: lighting, dimensions, availability of supports for anchoring — this determines how the virtual layer is aligned with the real object.
- Update procedure: who is responsible for content and how new models enter the application when an assembly is replaced.
- Acceptance criteria: how many scenarios, on which equipment, and by which metrics we measure the result — setup time, error rate, training time.
Part of the data is usually incomplete, and this does not block the start: we record what is missing as a separate stage with a clear labor estimate.
Describe the task and attach what you already have — we will come back with an estimate, a stage-by-stage work plan, and project composition.