Custom Engineering · Scenario Customization

Custom Energy Inspection Systems

An energy inspection system is defined by the asset register it has to feed, not by the aircraft it flies.

1 of 10Method note

Overview

Start from the asset list and the reporting obligation that already exists, then work backwards to capture.
Multiple asset types in one system means configurable standoff and optics per type, not one average setting.
The system should hand results back into the maintenance workflow the operator already runs.
Acceptance is best defined as an auditable run of a real inspection cycle, not a demonstration flight.

What is usually standard, and what is not

Energy inspection — transmission corridors, substations, wind and solar assets, pipelines — is one of the areas where a standard configuration most often covers most of the requirement. The aircraft, the payload, the flight pattern and the data chain are all reasonably well understood, and a programme that starts from a standard configuration and adapts only where it must will usually reach operation faster and cheaper than one that starts from a blank sheet.

What tends to be standard: the platform class for the asset type, the visible-light and thermal payload pairing, the corridor or asset flight geometry, and the basic review workflow. What tends to be custom: the asset referencing scheme, the defect classification vocabulary, the output format required by the receiving asset management system, and the integration of findings into the client's work order process.

That split matters because it tells you where to spend. Money spent on customising the aircraft is usually money spent on the part of the system that was already adequate. Money spent on making findings flow into the client's existing process is usually money spent on the part that determines whether the programme produces repairs or produces archives.

Requirement discovery for energy work

The discovery conversation should establish six things before anything is proposed. Which asset classes are in scope and in what proportion. What defect or condition classes the programme is looking for, and at what smallest size. What standoff and geometry the asset requires, and what access constraints exist at the sites. What the existing asset referencing scheme is, and how it maps to coordinates captured from the air.

The sixth is the one most often skipped and most often decisive: what happens to a finding. Who reviews it, within what time, with what authority to classify severity, and what system the resulting work order enters. A technically excellent inspection programme that routes findings into an inbox produces a large archive and few repairs, and the cause is a workflow gap rather than a technical one.

We run this as a structured conversation rather than a questionnaire, because the answers interact — a smaller detectable defect size changes the standoff, which changes the platform, which changes the sortie count, which changes the cost. Our project requirement discovery process is how we do it, and it produces a written requirement before any configuration is proposed.

The adaptation work that is typically required

Payload configuration is usually the first adaptation. Energy work pairs a visible-light gimbal for identification with a thermal channel for the failure modes that precede visible ones, and the question is whether both are needed on every sortie or whether screening and confirmation should be separated. The thermal payload selection note covers the sensor decision; the custom part is deciding how the two channels are used together.

Flight geometry and the repeatability discipline come next. Energy inspection is only valuable across epochs if successive passes are comparable, which means fixed geometry, a fixed season, and a location referencing scheme that survives staff turnover. Establishing that discipline and documenting it is custom work, because it depends on the client's asset numbering and their terrain.

The third adaptation is usually the output. Asset management systems have their own schemas, their own severity vocabularies and their own tolerances, and airborne output rarely matches them without adaptation. Our data interface adaptation and work order and alerting integration work cover this, and it is frequently the highest-value part of the engagement.

Acceptance: how to know it works

Acceptance for an energy inspection configuration should be defined in terms the client can check, and it should be agreed before the pilot rather than negotiated after it. The useful acceptance criteria are concrete: the smallest defect class reliably detected at the agreed standoff; the accuracy with which a flagged item is located against the client's asset numbering; and the time from landing to a finding reaching the named reviewer.

Georeferencing and location accuracy deserve their own criterion, because they are what make epochs comparable and what allow a finding to be acted on. Verify against independent check points rather than against the system's own output. Our test and verification methods note describes how we structure that verification.

The analysis side has its own acceptance question, and it should be stated without promises we cannot keep. Where automated screening is part of the configuration, the criterion should be expressed as what the system reliably flags for human review and what it deliberately does not decide — not as an accuracy figure. Our AI performance acceptance note sets out how we write these criteria.

Starting an energy inspection engagement

The practical path is a discovery conversation, a written requirement, a feasibility assessment against it, then a pilot with agreed acceptance criteria before any volume commitment. That sequence is deliberately front-loaded, because the expensive mistakes in inspection programmes are made at the requirement stage and discovered at the delivery stage.

Where a client already operates aircraft and needs only the payload, geometry or output adaptation, the engagement is correspondingly smaller, and we scope it that way rather than proposing a full programme.

Send your asset classes, defect classes and sizes, site access constraints, existing asset referencing scheme and receiving system to our engineering team. We will tell you which parts are standard, which need adaptation, and what we would want to test before you commit.