A photograph is an input.
For a new project, ask whether the file can be traced to an asset, whether its capture conditions support the intended assessment, and who is qualified to interpret it.
CASE 01 / EXTERNAL HISTORICAL CASE / SOURCE REVIEW 20 OCTOBER 2026
The camera finds a pattern.
The team makes a decision.
For asset owners and first-time UAV buyers: understand how an inspection becomes a useful maintenance task, what each subsystem contributes, and what a new project still needs to prove.
This is an analysis of someone else’s published work. It is not a 合機 (Hé Jī) or BYTE delivery reference. The interactive scene uses invented asset IDs and no real plant data.
The historical reference.
DJI’s manufacturer-authored report, published 5 January 2021, describes Brazil-based Drone Visual using a Matrice 210 RTK V2 with a Zenmuse XT2. Visual and thermal imagery was analysed using FLIR Tools; reports supported follow-up investigation, repair or cleaning. This is P2 evidence, not an independent audit. [S1]
The article also reports scale and productivity figures. We do not convert them into a service-level promise: the complete datasets, capture conditions, acceptance records and independent verification are not supplied here.
View the original story, field photographs and thermal examples →
Drone Visual’s own training page describes thermography, measurement parameters, anomaly location and reporting. It provides supporting evidence of advertised subject matter, not a separate audit of the historical project. [S2]
“Which asset needs attention, and why?”
An accepted work order is an output.
A crew needs an unambiguous location, supporting evidence, the proposed next action and a responsible reviewer. The record should distinguish uncertainty from a confirmed defect.
Engineering interpretation (I): design backward from the maintenance decision. A flight, an image and an AI label are different deliverables.
Walk one observation through the system.
Choose a step, then change the design question. This proposed workflow explains the handoffs a buyer should ask about. It does not replay the original operation or calculate inspection accuracy.
INTERACTIVE EXPLANATION / SYNTHETIC SCENE / NO LIVE DATA
A-10
Illustrative asset A-10 · location and colours are invented for explanation. No measured temperature or diagnosis.
STEP 1 / DEFINE
What must the owner decide?
Which modules need a technician, and what evidence will make the work order useful?
Input
Proposed input: site permission, asset map, required coverage and the person who accepts the report.
Output
A task statement and agreed acceptance criteria.
Proposed normal path: preserve evidence, review the finding and obtain acceptance before assigning an action. This is an educational sequence, not live telemetry or a completed test.
Read every step without operating the demo
- Define: What must the owner decide?
Which modules need a technician, and what evidence will make the work order useful? Proposed input: site permission, asset map, required coverage and the person who accepts the report. Output: A task statement and agreed acceptance criteria.
- Capture: What do the cameras contribute?
Visible images give scene context; thermal information supports an assessment of temperature patterns. A coloured patch alone is not a final diagnosis. Proposed input: approved capture conditions and the configured camera workflow. Output: Original files, capture settings and an association with the inspected asset.
- Transfer: Where do the originals go?
A new project must document the route from field storage to the analyst. This demo does not reconstruct the historical operator’s network. Proposed input: approved devices, accounts, storage locations and access rights. Output: A file manifest, integrity check and transfer record.
- Review: Who decides whether a finding is credible?
An analyst checks the evidence and marks observations for investigation. A model output or hotspot should not silently become a confirmed defect. Proposed input: original files, applicable measurement settings and review criteria. Output: Reviewed findings, uncertainty and a record of the reviewer.
- Report: Can a crew find the right panel?
A useful report connects the observation, original evidence and asset identity. The record must distinguish “investigate” from “confirmed defect”. Proposed input: checked asset IDs and reviewed observations. Output: A versioned report and a traceable work order.
- Act: How is the loop closed?
The asset owner assigns authorised personnel to investigate and decide the appropriate response. Record what was found and whether follow-up is needed. Proposed input: accepted work order and site procedures. Output: Closure evidence or an explicit unresolved finding.
Do not add technology the case does not establish.
The aircraft, payload and analyst workflow are the documented starting point. The five workstreams below are a framework for questions, not proof that every layer was installed.
| Layer | Technical reference | Evidence boundary |
|---|---|---|
| Drone Detection | Read the technical explanation → | Not established or required by this inspection account. |
| Mission Computer | Read the technical explanation → | An additional mission-computer model and software stack are not established. |
| C2 | Read the technical explanation → | Exact link configuration, authentication and recovery settings are not established. |
| RF | Read the technical explanation → | Frequency, approvals, range conditions and tested offline behaviour require configuration records. |
| Edge AI | Read the technical explanation → | Onboard AI is not established by the historical account. Do not relabel desktop analysis as airborne AI. |
Learn the components and control/data boundaries in the separate Technical Guide. This table retains only case-specific evidence limits.
A proposed responsibility map for a new project.
Site owner
Authorises access, defines asset IDs and data restrictions, provides reference information and accepts the final work product.
Operator and integrator
Confirm aircraft/payload configuration, lawful operating conditions, capture procedure, data transfer and operational contingencies.
Analyst or test partner
Defines review criteria, records measurement assumptions, checks sample evidence and identifies uncertainties.
Receiving maintenance team
Confirms that the asset can be located, records investigation and closes or escalates the work order.
No named company or research institution has been assigned these roles for a new pilot. A commercial agreement must identify actual owners.
Proposed acceptance checks. Not executed.
Start offline with authorised reference files before commissioning any new capture. The rows below are engineering proposals; the buyer must approve thresholds and owners.
| Test | Method and proposed pass condition | Evidence |
|---|---|---|
| Asset association | Reconcile every accepted finding in the agreed sample with the owner’s asset map. Unmatched items stay unresolved, not actionable. | asset-map.csv; findings.csv; review-log.csv |
| Original-file integrity | Compare hashes before and after an approved transfer. All transferred originals must match. | manifest-sha256.csv; transfer-log.json |
| Review traceability | Open each accepted sample finding and locate its original, reviewer, decision and report version. | review-log.csv; sample-report.pdf |
| Unavailable transfer | With synthetic files, interrupt the proposed transfer path. No silent loss; recovery produces a complete manifest with duplicates identified. | recovery-test.json; before-after-manifests |
| Export and restore | Restore the agreed sample into a clean approved workspace and demonstrate that the assigned reviewer can read it. | restore-log.json; format-and-license-register.csv |
Stage gates: desktop review → offline sample acceptance → equipment/ground validation if configuration changes → legally authorised site trial. SITL/HIL is relevant when flight-control or mission interfaces change; it does not validate thermal measurements by itself.
Write the gaps into the requirement.
Firmware, GCS and application versions; thermal calibration and processing settings; data storage and recipients; network endpoints; software/model/data licences; local support; equipment availability; current prices; operating permissions; staffing and delivery time.
For a new site, answer: who can read the files, where they are stored, who receives them, who can update software, who can control the system, whether it can work offline, and where post-processing happens. Local storage and the brand’s country alone do not establish supply-chain eligibility.
No breach, compromise, financial loss or confirmed procurement ineligibility is established by this case analysis. A proposed Taiwan/Brazil alternative must be qualified against the same deliverables; no drop-in compatibility is assumed.
Read the earlier procurement and data-risk analysis →Describe the decision you need to make.
Provide the country, site type, current equipment or “not yet determined”, required output, data restrictions and a non-confidential description of the problem.
Reference: CASE-BR-SOLAR-01. The receiving desk is BE PASSIVE. This is not a booking with Drone Visual or DJI and is not automatically forwarded to them.
Open the evidence.
- S1 — DJI Enterprise: historical Drone Visual solar inspection story. Published 5 January 2021; checked 20 October 2026. P2: manufacturer-authored case.
- S2 — Drone Visual: solar inspection training. Checked 20 October 2026. P2: provider description; current page does not independently validate the old case.
- Earlier BE PASSIVE analysis. Secondary context; its dated commercial listing is not a current quote.
Demo, role map and acceptance proposals: I (engineering interpretation). Missing configuration details: U (unknown). No independent laboratory or site test was performed for this page.