> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/usecases-workflows/manufacturing/visual-daily-inspection.md).
# Visual Daily Inspection
## Overview
Daily visual inspection is the routine that keeps a plant running and, in most facilities, the routine that is least well instrumented. An operator walks a defined route with a clipboard or a tablet, looks at gauges, seals, belts, and couplings, notes anything abnormal, and files a report. The inspection happens; the evidence rarely survives in a form anyone can compare against last week.
Moving the inspection onto a private 5G network changes what the routine produces. The operator carries a 5G tablet or camera and captures images at defined inspection points. Those images upload immediately to an inference service on the Onyx Edge, which compares them against a reference and against the same point's history, and flags deviations before the operator has walked to the next point. Fixed cameras cover the points that are dangerous or awkward to reach. The output is no longer a checklist that was ticked — it is a dated, indexed visual record with automated deviation detection over it.
The network requirement is different in character from the other manufacturing workflow on this site. AGV control needs a 10 ms budget and modest bandwidth. Inspection needs a large, bursty uplink and tolerates a hundred milliseconds of latency comfortably. The two coexist on one network precisely because QoS keeps them apart.
## How It Works
### The capture loop
### What each component does
| Component | Role in this workflow |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Operator device** | Rugged 5G tablet or handheld camera, usable in gloves. Presents the capture guide so today's image is comparable to the reference and to history |
| **Fixed cameras** | At points that are hazardous, elevated, enclosed, or awkward to reach. Visual, and thermal where the failure mode is thermal |
| **Asset tags** | QR, barcode, or RFID at each point, binding a capture to the right asset unambiguously |
| **Onyx RU** | Coverage along the inspection route — plant rooms, gantries, outdoor yards. Areas Wi-Fi is rarely extended to |
| **FHM / shared cell** | An upload in progress is not interrupted as the operator walks between coverage areas |
| **Onyx Edge — 5G Core** | 5QI 4 GBR: enough guaranteed uplink for a capture burst, without the priority that would let it disturb control traffic |
| **Local breakout** | Imagery reaches on-site inference and goes no further. Usually a precondition for the project being approvable at all |
| **Inference service** | GPU host on or beside the Onyx Edge. Scores each capture against the point's reference image *and* its history |
| **CMMS / EAM** | Where a confirmed deviation becomes a work order rather than a note |
| **Onyx Portal** | Per-device throughput and failed-upload diagnostics, per inspection round |
### The capture path, hop by hop
| # | From → To | Interface | What happens |
| -- | --------------------------- | --------------------------- | -------------------------------------------------------------------------------------------------- |
| 1 | Operator → Inspection point | Asset tag scan | Position confirmed; the capture is bound to the correct asset |
| 2 | Device → *capture* | Camera + capture guide | Reference framing presented so the image is comparable to history |
| 3 | Device → Onyx RU | **5G NR Uu**, uplink | 5–20 Mbps burst on 5QI 4; 2–15 MB per image, tagged with asset ID, timestamp, operator, conditions |
| 4 | RU → FHM → Onyx Edge | eCPRI, aggregated fronthaul | Upload continues uninterrupted as the operator moves |
| 5 | UPF → Inference service | **N6 local breakout** | Image reaches the GPU host on site. It does not leave the plant |
| 6 | *Inside inference* | Model comparison | Scored against the reference image and the point's own history |
| 7 | Result → Device | Downlink | **Under five seconds** — while the operator is still at the asset |
| 8 | Operator → *decision* | Confirm or dismiss | The operator adds the context the model cannot see |
| 9 | Confirmed → CMMS | API | Work order raised with the image attached |
| 10 | Dismissed → Inference | Feedback | Dismissals are the training signal that reduces false positives |
### The constraint is burst capacity, not latency
This workflow tolerates 100 ms comfortably — it is the most latency-relaxed page in this section. What it does not tolerate is fifty operators uploading 10 MB images in the same shift-change window. Size for the **burst**, and consider staggering routes across the shift.
Hop 7 is worth stating plainly as a design rule: it is a *network* requirement expressed as a *UX* requirement. If the result does not return in seconds, hop 8 does not happen — the operator walks on, the flag queues for later review, and the system loses the cheapest and most reliable filter it has between a real deviation and a shadow.
## Network Requirements
| Parameter | Target |
| ------------------------------------------------------ | ------------------------------------------------------------------------ |
| Uplink during capture, still images | 5–15 Mbps burst |
| Uplink during capture, short video or thermal sequence | 10–20 Mbps burst |
| Per-image payload | 2–15 MB depending on sensor and format |
| Aggregate uplink, 50 capture points at peak | 50–200 Mbps |
| Fixed camera continuous uplink | 3–8 Mbps each where streaming rather than capturing |
| One-way network latency | < 100 ms |
| Inference round trip, capture to result | < 5 s |
| Packet error rate | 10-6 — image integrity matters; this is an evidentiary record |
| Availability | 99.9% |
| Primary QoS | **5QI 4** — GBR, 300 ms PDB, 10-6 PER |
| Alternative for scheduled bulk upload | **5QI 72** or non-GBR **5QI 6** |
| TDD pattern | Uplink-weighted, `DDDSU` or `DDSUU` |
| Bands | n77, n78, n48 (CBRS), n40 |
## Deploying It
{% stepper %}
{% step %}
### Define every inspection point
Asset ID, what is inspected, what normal looks like, and the capture geometry — position, angle, distance, lighting. Classify each as operator-captured or fixed-camera; hazardous, elevated, and confined-space points belong to fixed cameras.
{% endstep %}
{% step %}
### Build the reference set
Capture each point under known-good conditions. Automated comparison is only as good as its reference. Agree the deviation classes to be detected — leak, corrosion, misalignment, wear, missing fastener, abnormal gauge, thermal anomaly — with plant maintenance before model deployment.
{% endstep %}
{% step %}
### Configure the network and edge
Inspection subscriber group on 5QI 4 or 72; uplink-weighted TDD where it shares a carrier. Deploy the inference service on the Onyx Edge or a GPU host reached through local breakout.
{% endstep %}
{% step %}
### Onboard devices
SIMs for tablets, handheld cameras, and fixed cameras. Load the route onto operator devices: point sequence, capture guidance, and the previous result for each point. Configure fixed-camera schedules and any lighting triggers.
{% endstep %}
{% step %}
### Run the round
As described in the capture loop above — with the operator's confirmation happening at the asset, not at a desk afterwards.
{% endstep %}
{% step %}
### Review and trend
Triage by severity and schedule against maintenance windows. Trend each point's history to catch the slow deviations a daily comparison misses — corrosion advancing a fraction a week, a belt creeping out of alignment over a month. Review model performance against operator confirmations and dismissals.
{% endstep %}
{% step %}
### Retain as evidence
Keep the visual record with its metadata for the period the plant's regulatory or insurance regime requires, and produce completion reports — which points, when, by whom, with what result.
{% endstep %}
{% endstepper %}
## Devices & Ecosystem
* **5G rugged tablets and handheld cameras** — the operator's capture device, rated for the plant environment and usable in gloves.
* **Fixed 5G cameras** — at hazardous, elevated, or enclosed points; visual, and thermal where the failure mode is thermal.
* **Thermal imagers** — for bearings, motors, electrical connections, and steam systems, where the deviation is invisible in the visible spectrum.
* **Edge inference platform** — a GPU-equipped host running the comparison and anomaly models, on or beside the Onyx Edge.
* **CMMS / EAM integration** — so a confirmed deviation becomes a work order rather than a note.
* **Asset tags** — QR, barcode, or RFID at each point, to bind a capture to the right asset unambiguously.
## Design Considerations
{% hint style="warning" %}
**Capture consistency determines detection quality.** The largest source of false positives is not the model — it is inconsistent framing and lighting. Invest in capture guides, fixed mounting points for the operator's device, and controlled lighting at points where ambient light varies through the day. A point captured from a different angle each day cannot be compared to itself.
{% endhint %}
{% hint style="info" %}
**Latency is not the constraint; burst capacity is.** This workflow tolerates 100 ms comfortably. What it does not tolerate is an uplink that cannot absorb fifty operators uploading 10 MB images in the same shift-change window. Size for the burst, and consider staggering routes across the shift.
{% endhint %}
{% hint style="warning" %}
**Keep the imagery on site.** Inspection imagery is a detailed visual record of process equipment, tooling, and layout. Local breakout to on-site inference is frequently the reason the project is approvable at all. Confirm the retention and access policy before the first capture.
{% endhint %}
{% hint style="info" %}
**Design the human confirmation step in deliberately.** An inspection system that files flags for later review loses the operator's context — the one thing that most cheaply separates a real deviation from a shadow. Return the inference result fast enough that confirmation happens at the asset. This is a network requirement expressed as a UX requirement.
{% endhint %}
{% hint style="info" %}
**Plan for the model's first months.** Early false-positive rates will be high, and an operator who learns to dismiss everything has been trained out of the workflow. Start with a narrow set of high-confidence deviation classes, widen as the confirmation data accumulates, and show operators that their dismissals change the system's behaviour.
{% endhint %}
{% hint style="warning" %}
**Treat the record as evidentiary.** If the inspection record may be used for regulatory, insurance, or incident-investigation purposes, the integrity requirements change: 10-6 packet error rate, verified upload, immutable timestamping, and a retention policy agreed before deployment rather than after an incident.
{% endhint %}
## Validation Checklist
* [ ] Every inspection point defined with asset ID, capture geometry, and normal condition
* [ ] Points classified as operator-captured or fixed-camera; hazardous points assigned to fixed cameras
* [ ] Reference image set captured under known-good conditions for every point
* [ ] Deviation classes agreed with plant maintenance before model deployment
* [ ] Coverage validated along the entire inspection route, including plant rooms and outdoor sections
* [ ] Peak burst test — full operator complement uploading simultaneously at shift change
* [ ] Inspection traffic on its own bearer, verified not to affect control-traffic latency
* [ ] Capture-to-result round trip measured and under five seconds at the furthest point on the route
* [ ] Upload integrity verified; failed uploads retried and surfaced, never silently dropped
* [ ] Imagery confirmed to remain on site; retention and access policy documented
* [ ] Operator confirmation step tested in the field, in gloves, in plant lighting
* [ ] CMMS integration verified end to end: confirmed deviation produces a work order with image attached
* [ ] False-positive rate baselined, with a review cadence agreed
* [ ] Fixed-camera schedules and lighting triggers validated across a full day/night cycle
## Related reading
* [AGV & AMR Fleet Control on 5G](broken://pages/2aa29420dfb7652d6e4dc9b31d866e3b802d44a8)
* [Drone Site Inspection on 5G](broken://pages/eee56994ccbdeeb2979c2706f2b58cc93930f062)
* [Network Requirements at a Glance](broken://pages/d8ba02440bfd0f056f057fd9b67a87d38f1d8507)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.gxc.io/usecases-workflows/manufacturing/visual-daily-inspection.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.