Preparing the published article.
Specify Inspection Robots by the Defect, Not the Sensor
How to build a defect list from your own records and write inspection robot requirements around detection, classification and reach.
Write the Defect List From Your Own Records
An inspection robot is bought to find specific defects, so the specification should start with a defect list, not a sensor list. Two systems can carry a similar camera and still differ in what they report, because the reporting logic, not the lens, decides whether a defect is recorded. Build the list from your last few years of inspection reports, insurance-driven surveys, repair records, and the near-misses your own crews remember.
For each defect class, write a row that answers operational questions rather than technical ones.
- Defect class: corrosion under insulation, surface crack, coating breakdown, wall thinning, refractory damage, loose fixings, seal or gasket failure, water ingress, blockage or debris.
- Where it typically appears on your asset, and whether it is hidden until a surface is cleaned or a cover is removed.
- The size, length or extent at which your team would act, expressed as an engineering judgement, not a test result.
- How the defect presents to a sensing method: visual pattern, temperature difference, geometry change, or sound.
- Which defects are legally or contractually reportable, and to whom.
Ask after every demonstration whether the defects shown came from your list or from examples the supplier selected. A demonstration that only finds its own examples proves that detection is possible somewhere, not that your defect list will be covered.
Define What Counts as a Found Defect
A sensor detects; a system decides. The question that separates suppliers is what the system calls a defect and what it calls noise. Ask for the decision logic in plain language, then test it on your own assets. Any uncertainty the system reports should itself be recorded, because an inspector needs to know when the equipment has low confidence.
Build the test around three groups. The first is defects already confirmed by a human inspection, with their exact locations. The second is marginal cases your inspectors have debated but not classified. The third is clean surfaces that resemble defect patterns: a weld, a shadow, a smear, a repair patch. Record what the system reports for each group, including the location it gives, and compare it with ground truth you established by other means.
- Per target: location, defect class, whether it was confirmed, marginal or clean, and the true size or extent.
- Per report: the location reported, the class reported, the size or extent reported, and the uncertainty or confidence statement.
- Comparison basis: how the ground truth was established, by whom, and on what date.
- Throughput: how many metres or components were covered per hour, and how much preparation time was needed.
Then draw the distinction that buyers tend to skip: detection, classification, and sizing are three different claims, and a tool that can see a dark patch may still be unable to say how deep it goes. Ask separately for each claim, and require separate evidence for each.
Build the Specification Around Reach, Preparation and Evidence
Once the defect list and the success definition exist, the commercial documents become straightforward. Write the scope as: defect classes to be detected, coverage percentage of the inspected surface or length, and the reporting fields required for each finding. Then state what the buyer will accept as a missed defect and what counts as over-reporting.
Add the practical constraints that decide whether the asset is actually reachable. For each inspection point on your assets, record what the robot needs in order to reach it: scaffolding, rope access, a hatch opening, a cleaning step, a shutdown window, or a hot-work permit. Put the field list next to the defect list.
- Reach: access route, minimum opening, maximum distance from the access point, and whether the asset must be drained or cooled.
- Preparation: surface cleaning, insulation removal, coating, and who performs each step.
- Environment: temperature, humidity, dust, explosive atmosphere, and whether entry permits are affected.
- Interfaces: power or battery runtime per shift, data transfer route, and the format the report must arrive in.
- Acceptance: repeated runs on the same target, and a written record of what was reported each time.
Finally, tie every requirement back to a defect class in your own list. A requirement that cannot be traced to a defect class is a feature request; a defect class with no requirement is an accepted blind spot. Making that mapping explicit lets the maintenance planner, the reliability engineer and the procurement officer review the same document, which is what keeps the purchase defensible after commissioning.
Photo credits: the images in this article are licensed reference photographs of the relevant robot class, credited with author and licence in each caption; they are not photographs of the specific equipment discussed. Licence and author details are recorded with each image.