AR application for industry: where the pilot stops
An AR pilot in manufacturing rarely stops because of a headset or tablet — it hits the environment. Coverage and connectivity on site are unstable, and equipment is located inside metal structures that shield the signal.
If connectivity drops in two out of five areas, the application stops being a working tool and turns into a demonstration.
The second barrier is tracking in shop-floor conditions. Metal, glare from welding, vibration from machines, and repetitive surfaces break recognition: the virtual hint drifts away from the real assembly, and the operator stops trusting it.
A separate challenge is mounting on a hard hat: the device moves with the head, and a static anchor does not hold.
The third is a scenario for a single operation. An AR application for industry is built for one workstation, one part, or one team, and in the neighboring area it no longer launches: markings and anchors are hardcoded for a specific geometry. Scaling requires rebuilding, not configuration.
Next is manual data entry. If the operator enters the inspection result by hand, and the system does not transfer it to accounting, the value boils down to a hint on the screen: data is lost or distorted, and the technical process does not change.
We break down how this is addressed: what to check before starting, how to build tracking and connectivity, and how to take the scenario beyond a single workstation.
What changes on site after implementing the AR layer
The AR layer changes not the operation itself, but the way it is supported: hints are tied to anchors on equipment and the workplace, so the instruction appears in the field of view exactly at the right step.
The operator confirms each action, and the record goes to the log with a timestamp and account — time tracking and deviation analysis stop being manual work.
On repeatable assemblies, installation, and commissioning, operation time is reduced by 15–30%: pauses for finding the right section and checking against paper disappear.
The more complex the assembly, the more noticeable the effect — the order of steps does not need to be kept in mind, the route guides through a visual sequence.
The share of rework and defects falls where an error used to be found at inspection rather than at the step itself.
Image-based verification prevents missing a fastener or a mandatory measurement, and the transition to the next operation is closed until the current one is visually confirmed.
Line downtime during an unexpected stop is shorter: the diagnostic route is brought up right at the equipment, without waiting for a paper procedure and a specialist visit.
Technically, this is anchor recognition Vuforia and offline caching of models on the device, so hints work even in areas without stable connectivity.
Onboarding new personnel speeds up the most: reaching independent work takes shifts instead of weeks, and a mentor stops being mandatory accompaniment. Then the step log shows exactly where the newcomer loses time — training is adjusted based on data, not feelings.
Three operating modes: navigation, step-by-step hints, control
The modes differ not in the set of effects, but in what input data they need and what error they catch. Navigation works from area markings, step-by-step hints — from assembly recognition and the sequence of operations, quality control — from a reference model and tolerances. Therefore, the same shop floor may require different modes for different operations.
The starting mode is chosen based on the operation where an error already costs time: rework, line downtime, a repeat specialist visit. Below are the application conditions and limitations that usually come up during a pilot.
Modes and their limitations
| Mode | When it fits | Limitations |
|---|---|---|
| Area navigation | Large areas, dozens of equipment units, newcomers and contractors | Requires area markings and anchoring to reference points; on long repetitive passages, the hint loses accuracy |
| Step-by-step hints | Assembly, commissioning, maintenance with a fixed sequence | Instructions need to be broken into steps and tied to parts; when deviating from the route, operator confirmation is required |
| Remote engineer assistance | Rare failures, complex assemblies, lack of experts on site | Requires stable connectivity and consent for broadcasting from the site; without a session procedure, time is spent on approvals |
| Assembly quality control | Acceptance of critical joints, recording the fact and parameters | Requires reference models and checklists, even lighting; disputed cases still go to expert review |
The modes are compatible: the same area markings and instruction library are reused, so the second mode is enabled on top of the first without rebuilding the application.
It makes sense to start with an operation where the result is visible within a shift — navigation and step-by-step hints deliver an effect faster than quality control.
Implementation stages: from site survey to handover
The workflow in AR differs from regular mobile development: a scenario cannot be assembled in the office and 'overlaid' on the shop floor. Anchor points, lighting, vibration, and the operator's sequence of actions determine whether the hint will match the real equipment. Therefore, we drive the project from the site, not from a mockup.
- Site survey. Engineers travel to the production site, capture the operator's route, record equipment types, lighting by zone, network availability, and PPE restrictions. The result is a map of areas where AR works reliably and a list of zones that require manual launch.
- Operation scenario design. We break the work into steps, and for each we define the hint type: assembly highlighting, order arrow, text instruction, result verification. We coordinate the design with process engineers — it becomes the contract for the entire subsequent scope.
- AR content assembly. We prepare models, anchors, and hints for recognition of real objects, including variants of worn and dirty equipment. We version content separately from the application code.
- Equipment and offline mode setup. We select devices, mounts, and operating mode for the shift duration, cache the scenario on the device so hints do not depend on network coverage in the shop floor.
- Validation on real operations. A shift runs the scenario in working mode, we calculate the share of recognized steps, time per operation, and number of references to the instruction. We make edits before acceptance, not after launch.
- Solution handover and shift training. We hand over configurations, scenario design, content update procedure, and rollback order. We train operators and the engineering service — hints can be updated without us.
The key acceptance criterion is that the step on the screen matches the actual work order for most operators, not the beauty of the model. After handover, a procedure remains by which the scenario can be extended to the next area.
Handover package: configurations, designs, procedures, and access
The project is handed over not with a presentation, but with a working package: with it, a shift goes on route without a developer, and the support engineer makes an edit to the scenario themselves.
Below is what exactly remains with the customer and which documents it is checked against during acceptance.
- Scenario configurations — step anchoring to assemblies and units, hint order, trigger thresholds. Such a file is edited and rolled out separately from the application, so a new scenario does not entail a rebuild.
- Placement and route designs — a site plan with coordinate markers and zones where recognition is reliable and where highlighting or a freeze frame is needed.
- Access policies and roles — the operator sees only their area, the supervisor receives a shift summary, the administrator manages content; rights are assigned by role, not individually.
- Shift instructions — short cards: how to start the scenario, what to do if anchoring is lost, how to hand over the shift and record a remark.
- Scenario management procedure — who approves a new scenario, in which windows it is published, and how the previous configuration is rolled back if something goes wrong on the line.
- AR content update procedure — replacement of models and hints, mandatory testing on a test bench, version numbering, so it is always visible which build is on the device.
- Change log and responsibility matrix — it shows whose edit went to the line and when.
During acceptance, we go through the list together with your operations service: the customer's engineer starts the scenario according to the instructions and makes an edit according to the procedure — the package is considered accepted when this is done without our prompting.
Case study: assembly of a unit on a line — metrics before and after
Before implementation, the unit was assembled according to a paper instruction: the operator looked away from the product, searched for the right item, manually checked the fastener type and operation order.
At three dozen positions, this gave a median of about 9 minutes per unit, and the spread between shifts reached 11–12 minutes for newcomers and 7–8 for experienced workers.
Now the assembly route is displayed directly on the product: the outline of the installation point, position number, allowed fastener, and tightening torque.
The next step opens only after the current one is confirmed, hands remain free, navigation is by voice and gestures; assembly is performed on HoloLens glasses, anchoring to the tooling is by markers.
What was measured during the pilot
The pilot was launched on one operation and one line, the second remained a control — this way the effect was not mixed with seasonality and operator experience.
Three values were measured: median cycle time across hundreds of assemblies, share of rework, and number of requests to the process engineer per shift.
Result: the median cycle decreased from 9 to 5.5 minutes, the gap between an experienced operator and a newcomer almost halved. The error class 'fastener not to specification' on the pilot line disappeared completely, rework — from 4% to tenths of a percent. A newcomer reached independent assembly in the first shift, not after a week with a mentor.
Then the AR instruction library began to be versioned together with the technical process: a change in the assembly revision automatically delivers the new version to the glasses, and discrepancies between the line and documentation are visible from the step progress log.
How does a step-by-step hint differ from remote engineer assistance?
A step-by-step hint is a pre-prepared scenario that is overlaid on a real object: the operator moves the camera, the application shows the next action, control point, and allowed deviations.
The expert does not participate in the process — their knowledge is transferred into the scenario once, during preparation.
Remote expert assistance works in real time. The engineer sees the stream from the operator's camera, places markers directly on the image, and prompts by voice while the operator performs actions.
Connectivity requirements here are fundamentally different: a stable channel with low latency is needed, otherwise the marker diverges from the picture and the hint starts to get in the way.
The difference between the modes is primarily in purpose. The hint covers routine, repeatable operations: maintenance, assembly, acceptance.
Remote assistance is needed where the scenario cannot be described in advance — an abnormal defect, a rare configuration, escalation to a narrow specialist.
The load on the expert and the cost of ownership also diverge noticeably. The scenario guides the operator without human involvement: expert time is spent once and scales to all shifts and sites.
In real-time mode, each call occupies the specialist entirely, and costs grow linearly with the number of requests.
It is more logical to start with step-by-step hints: scenarios are stored on the device and work with a weak channel in the shop floor, and the result is visible already at the first site.
Remote assistance is connected as a second stage — on top of the same object base and the same steps, when abnormal cases accumulate and it is clear whom exactly to escalate.
Engineering concerns before the pilot: addressing point by point
A pilot on site runs into not the quality of recognition, but the customer's infrastructure: an isolated network, weak signal in the shop floor, an accounting system that does not expose data externally.
Below are five questions that usually come up during technical coordination, and how we address them.
How does the application work in a closed production network?
The server side and storage are deployed inside the network perimeter, with no external requests. Recognition models and updates are delivered via a local repository that your administrators populate according to an agreed procedure.
What happens in a shop floor without stable connectivity?
The headset maintains a local operation log and accumulates telemetry, the screen and hints work without a network. When the channel appears, data goes to the server, conflicts are resolved by time and operation ID, not by 'who wrote last'.
How does integration with the accounting system work?
Exchange goes through a gateway with a fixed contract: work orders, nomenclature, execution statuses. The accounting system remains the source of truth, the application is a consumer of tasks and sender of confirmed facts, so discrepancies in reporting do not arise.
What is included in support after handover?
Source code, deployment designs, instructions for the duty shift, and the update procedure are transferred to you. Further support is provided in tiers: from engineer consultation to on-site visit in case of an incident.
How to replicate the solution to other areas?
A new area is described by configuration, not by code changes: its own route points, its own work orders, its own recognition model. The pilot scenario is transferred to the neighboring line without rebuilding the application.
Let's discuss the task: what to send for assessment and a plan
The assessment of an AR project relies not on preferences for appearance, but on the physics of the site: what the employee does, under what conditions, and what happens if the hint does not appear or appears with a delay.
Therefore, for an implementation plan we need a list of operations and data about the environment in which they are performed. You already have part of this — in instructions, designs, and labor safety procedures.
What to send for task analysis:
- List of operations step by step: what the employee does now, at which step they most often make mistakes, and how long each operation takes.
- Site designs with dimensions, equipment anchoring, and zones where working in glasses is not allowed or is restricted.
- Environmental conditions: lighting, dust, vibration, work at height, temperature fluctuations — the choice of device and mounting method depends on this.
- Network limitations: where on the route there is stable coverage, where there is no connectivity and a fully autonomous mode with later synchronization is needed.
- Shift composition and roles: how many people work simultaneously, who puts on the device, who is responsible for issuing and charging.
- Labor safety requirements and internal procedures: allowed equipment, restrictions on the auditory channel, contractor access procedure to the site.
- Existing systems at the facility that need to exchange data: accounting, dispatch, warehouse.
If some data is missing — send what you have: we will clarify the rest during the site analysis. Describe the task in a convenient form — we will come back with an assessment, implementation plan, and a list of what will be required from your side.