Skip to content

Drone UT Payloads: Purchase and Measurement Evidence Checklist

Adding an ultrasonic payload changes a visual inspection drone into part of a measurement workflow. The purchase review must address the measurement evidence, location relationship and qualified review as well as the platform’s ability to reach a target.

For: U.S. NDT equipment coordinators, quality staff and inspection business owners

Define the measurement task before discussing the aircraft

Begin with the approved inspection question and the evidence needed to answer it. A buyer may want thickness readings at established locations, visual documentation of a condition or both. These are separate deliverables even when one platform collects them. The responsible technical authority should define the measurement scope and suitability requirements before purchasing evaluates a drone payload. The aircraft's ability to reach a location is only one part of that decision.

Write the proposed scope without expanding it through marketing language. If the requirement is a set of spot thickness measurements, say so. Do not imply a continuous wall thickness map, complete volumetric examination or weld evaluation unless the proposed system and approved procedure actually establish those capabilities. A visually comprehensive model of an asset can provide context while containing only a limited set of ultrasonic observations.

Identify the reason for considering the platform. It may address an access constraint, reduce a particular handling burden or support a combined visual and thickness workflow. The buyer should compare that reason with the required evidence and the site's approved arrangements. This guide addresses purchasing and records; it does not provide flight instructions, measurement settings, entry authorization or a determination that a particular environment is suitable for operation.

Treat the payload as a measurement system with its own scope

Flyability describes the Elios 3 UT payload as a remote thickness measurement capability with A-scan information and location tagging. Cygnus's partnership announcement describes spot thickness measurement as the intended task. These primary manufacturer sources establish a real product category, but do not prove suitability for every material, surface, geometry or customer requirement. Evaluate the exact proposed configuration and approved application.

Keep the visual, localization and ultrasonic functions distinct in the scope record. A visual image helps show context, a localization output helps relate data to the asset, and an ultrasonic record supports the measurement review. None should silently substitute for another. A useful quotation explains which outputs are produced, how they are associated and what the recipient can do with them after the mission.

Ask whether the purchase is a complete system or an upgrade to equipment already owned. An existing aircraft may still require compatible software, accessories, support arrangements or other changes for the proposed payload workflow. The buyer should obtain configuration-specific confirmation rather than assuming every installed base unit supports every current option. Record the aircraft, payload, relevant probe and software identities in the acceptance package.

Separate access feasibility from measurement suitability

Request evidence that the proposed arrangement can reach and present the measurement system to the intended locations under an approved demonstration plan. The site and technical teams should determine what conditions the demonstration must represent. A successful flight through an opening does not establish that the payload can obtain suitable measurement evidence at the target. Conversely, a valid measurement on an easily accessible sample does not demonstrate the planned access route.

Keep the two results separate in the evaluation sheet. Access may be demonstrated while measurement suitability remains unresolved because the sample does not represent the relevant surface or geometry. A limited result is still useful if its boundary is clear. The buyer can use it to identify further evidence, narrow the intended use or consider another access arrangement without misrepresenting the original demonstration as a complete validation.

Do not derive site suitability from a general description such as industrial or confined-space drone. Ask the responsible site personnel to review the applicable manufacturer restrictions and the actual planned environment. Purchasing should retain the resulting requirements and dependencies, not attempt to approve operation from a brochure. The required permissions and operating plan belong to the qualified parties responsible for the specific project.

Identify the complete payload and support package

Build a schedule covering the aircraft configuration, payload, approved probe arrangement, required accessories, power items, software and support. Mark each line as included, optional, buyer supplied or unresolved. The technical team decides what is needed for the application. Purchasing confirms the quoted identities and quantities, including whether demonstration accessories are part of the delivered package.

Ask how replacement components are identified and reviewed. A probe or accessory replacement may affect the measurement configuration and the evidence needed before use. The equipment coordinator needs a clear part identity and the manufacturer's applicable documentation. Do not rely on a photograph or a remembered color to order a replacement, and do not assume that an accessory described for another configuration is automatically interchangeable.

Include the ground-side workflow in the package. A tablet, processing computer, application or entitlement may be necessary to review and export the measurement evidence. An aircraft and payload quotation can appear complete while leaving the data review environment unpriced. Ask the supplier to demonstrate the full chain using the equipment and software that the buyer will actually receive or maintain.

Specify the retained ultrasonic evidence

Have the technical authority define what measurement evidence must remain available after acquisition. This may include the relevant waveform record, reviewed value, configuration context and location relationship, depending on the approved requirements. The buyer should not assume that a number displayed during the mission is sufficient or that the final report automatically contains everything required for a later technical review.

Ask the supplier to save a controlled demonstration record and reopen it after the live session. The intended reviewer should identify the relevant measurement evidence and understand its relationship to the displayed value. Record which functions are available in the proposed software and which depend on additional tools or access. A successful live A-scan display is useful, but it does not independently establish the retained-data capability.

Distinguish collected data from reviewed results. The organization's technical process determines who evaluates the evidence and approves what is reported. A platform may assist collection or presentation without replacing that responsibility. The purchase record should explain how the selected workflow communicates review status and preserves the evidence supporting the issued result, including any limitations that remain external to the software.

Make location tagging understandable to the asset owner

Ask how each measurement is related to the owner's established component and location references. A point placed in a digital model may be visually useful while using a local naming scheme unfamiliar to the owner. The technical and data teams should define the required relationship before the demonstration. If a crosswalk is necessary, identify who creates, checks and retains it with the inspection record.

Test a small set of fictional locations that are deliberately similar or repeated in different parts of the sample asset. Ask the reviewer to find each point using the delivered record rather than the demonstrator's memory. The objective is to establish that the location information supports the intended follow-up or comparison. Do not turn a manufacturer localization statement into an unsupported claim of exact repeatability at every future inspection.

Keep the localization limitation visible in the report where it affects interpretation. A model can provide useful context without serving as a surveyed coordinate system or proving complete inspection coverage. The responsible technical reviewer decides what location evidence is adequate for the task. Purchasing should verify that the software retains and exports the required references and that the customer understands the delivered representation.

Plan how unsuccessful and deferred points are recorded

The scope should explain what happens when a planned point does not produce an accepted measurement. The appropriate technical response belongs to the approved procedure, but the record workflow must distinguish that point from a completed and reviewed result. Ask how the system and report identify attempted, deferred, inaccessible or otherwise unresolved locations using the organization's agreed terminology.

Use controlled sample records to test those distinctions. A visually marked point should not imply a valid thickness result if it represents only an observation or an attempted acquisition. The buyer should inspect the map, table and report to see whether the meaning remains clear after export. A complete list of points of interest can still contain an incomplete measurement scope, so the report needs an understandable reconciliation with the planned work.

Assign follow-up responsibility in the project record. Some unresolved points may require a different approved access or measurement arrangement. Others may be removed from scope through an authorized change. The purchasing evaluation should establish that these outcomes can be documented, not prescribe the technical response. A system that supports clear exception records can be more useful than a demonstration that presents only successful examples.

Confirm software compatibility across the package

Flyability's UT payload knowledge-base guidance identifies software compatibility requirements across the aircraft, control and review environment. Use the current applicable manufacturer documentation for the exact package. Do not copy an older minimum version into a permanent internal rule or assume that updating one component automatically keeps every linked component compatible.

Record the versions used for the accepted demonstration and the process for reviewing later changes. A new release may affect data handling, supported hardware or user workflow. The organization should decide which acceptance cases need to be checked when a change is proposed. Retain the prior evidence and the reason for the new decision through the software change record.

Test the receiving environment before committing to a customer deliverable. Ask whether the intended reviewer can open the retained evidence, locate a measurement and produce the agreed export using the purchased entitlement. If cloud access or another service is part of the workflow, record that dependency and the available alternatives. A shared report view and a full technical review environment may provide different functions.

Assign flight, measurement and reporting responsibilities

Define who is responsible for the platform, who is responsible for the ultrasonic examination and who approves the delivered report. These roles may be held by different people. The organization should determine the applicable competence and authorization requirements for each role through its own approved processes. A platform training course should not be described as automatically establishing ultrasonic competence, and an ultrasonic qualification does not by itself establish platform operating authorization.

Include the customer and site interfaces in the responsibility record. Someone must approve the requested scope, provide the asset references, coordinate the applicable site arrangements and accept the agreed deliverables. Purchasing can make these dependencies visible before mobilization. It should not imply that buying a particular platform removes the need for site coordination or turns every access request into an approved mission.

Review the included training and support against those roles. Ask what instruction covers platform familiarization, data review, reporting and equipment administration. Keep the scope specific enough to identify remaining organizational training needs. The equipment coordinator also needs the correct manuals, component identities and service contacts so the package can be maintained without relying entirely on one operator's informal knowledge.

Evaluate the business case using your actual workflow

Compare purchase, rental and specialist service options using the organization's expected workload and support capability. Include the complete payload package, software, training, service, data review and any necessary alternative method for unresolved locations. Do not adopt a manufacturer case study's savings percentage as a prediction for your own site. Access arrangements, component condition and deliverable requirements can change the economics substantially.

Identify the assumptions that matter most. A business case may depend on repeated use of the same asset model, availability of qualified reviewers or acceptance of the proposed data package by the customer. Give each assumption an owner and evidence status. If an assumption remains uncertain, show how it affects the decision rather than hiding it inside a precise-looking return-on-investment calculation.

Include continuity planning for both the platform and the measurement workflow. Ask how the organization will handle service downtime, unavailable software access or a payload component needing replacement. The answer may involve a spare, rental support or another approved inspection arrangement. Obtain actual supplier commitments where relevant and avoid promising automatic replacements or fixed turnaround times that are not part of the agreement.

Work through a hypothetical upgrade evaluation

A fictional U.S. inspection provider already owns a visual inspection drone and considers adding a UT payload. Its customer wants thickness evidence at a defined list of locations, plus visual context. The provider first confirms the required configuration and software dependencies. It then arranges an approved demonstration that separately addresses access, retained ultrasonic evidence and the relationship to the customer's location names.

In the hypothetical test, the platform reaches the sample targets and saves reviewable ultrasonic records, but the exported report does not clearly distinguish one unresolved point from completed points. The team records the reporting issue and revises the agreed workflow before accepting the deliverable. This example illustrates an administrative acceptance problem; it is not a claim about a named product or a prescription for how to obtain a thickness measurement.

The final decision identifies the accepted configuration, demonstrated scope, retained objects, location convention and responsible reviewers. It also states which conditions require another technical review. NDT Connect can hold the aircraft or payload's equipment identity, status, due date and notes pointing to the external evidence. It does not control the drone, store flight or A-scan data, approve measurements or automatically prevent deployment of an incomplete package.

Frequently Asked Questions

Does adding a UT payload turn a drone into a complete weld inspection system?

Do not assume that. Define the specific measurement capability and verify it for the proposed system and approved application; spot thickness measurement is a distinct scope.

Does a location-tagged point prove a valid thickness result?

No. Location context and ultrasonic validity are separate questions. The appropriate technical reviewer must evaluate the retained measurement evidence.

Can existing visual drone software be assumed sufficient for UT review?

No. Confirm the applicable aircraft, control and review software requirements and demonstrate the full retained-data workflow for the quoted configuration.

References & Standards Cited

  1. Flyability: Elios 3 UT payload capabilities and software workflow View source ↗
  2. Cygnus Instruments: historical Elios 3 UT payload partnership announcement View source ↗
  3. Flyability Knowledge Base: UT payload software and documentation requirements View source ↗

Related on NDT Connect

Join NDT Connect — free

The free marketplace for the NDT industry — connect inspectors and the companies that need them.

Free to join · Compare provider qualifications and confirm availability directly · Browse providers

By NDT Connect Editorial · Updated

Source-based editorial guidance. Read our editorial policy and disclosures.