Tube Inspection Software: Test Maps, Identity and Reports
A polished tubesheet map is useful only when each symbol remains connected to the correct tube, inspection record and reporting meaning. Test those relationships before buying or adopting a tubing software workflow.
For: U.S. NDT equipment coordinators, quality staff and inspection business owners
Define the software problem separately from the inspection technique
Start with the information task the software must support. A team may need to prepare an agreed tube list, associate acquired files with tube identities, visualize reviewed results or compare successive inspection records. Those tasks can involve different applications. Define which part of the workflow you are evaluating and which technical decisions remain with the responsible inspection personnel. Choosing a map or report tool does not select or qualify an examination technique.
Describe the intended asset representation and deliverable in the request for demonstration. Include the owner's tube numbering convention, the inspection software already used and the required report format. A generic circular tubesheet example may not exercise the naming, grouping or result relationships that matter to your organization. The purchasing exercise should use a controlled fictional example that resembles the real information structure without exposing customer data.
Name the users who need to work with the information. A planner may create the tube list, an operator may collect data, an analyst may review indications and an owner may receive the final report. Each role needs a different function. Ask whether the proposed package supports those functions directly, requires another application or depends on a manual transfer. The answer determines what must be included in the evaluation and purchase.
Understand the boundary between mapping and analysis
Eddyfi describes TubePro as software for tubesheet representation and reporting, with an active connection to Magnifi. It describes Magnifi as an acquisition and analysis platform. These manufacturer descriptions provide a concrete example of connected but distinct functions. They do not establish that every edition, version or third party combination behaves identically, so document the exact proposed workflow before testing it.
Draw a simple sequence in the acceptance record: approved tube identity, planned list, acquired data, reviewed result, map symbol and issued report. For each connection, identify which application creates it and which person reviews it. This makes gaps visible. A report tool might display a result correctly while receiving an ambiguous tube identifier, or an acquisition system might retain valid data that never reaches the map because an import rule excludes it.
Keep technical analysis responsibility explicit. A generated symbol or a suggested indication is not automatically an issued result. Ask how the proposed workflow distinguishes working analysis from the result approved for reporting. If the product provides automation or assisted analysis, evaluate that capability separately with the responsible personnel. A successful map demonstration should not be presented as validation of the underlying detection or sizing process.
Test map creation against known reference information
Use a fictional or authorized sample drawing with a known tube count and agreed identity structure. Ask the demonstrator to create the map using the proposed method, whether manual entry, drawing import, image assistance or another supported function. The buyer should then compare the output with the known reference. An automated map creation feature can save effort, but its output still needs the review appropriate to the intended use.
Check representative boundaries and irregular features rather than looking only at the middle of a regular pattern. Include section changes, omitted positions or other meaningful conditions from the approved sample. Record discrepancies and how they are corrected. The exercise should establish how the team checks a generated map, not simply how quickly a supplier can produce an attractive visualization from a favorable demonstration image.
Retain the source drawing, generated map and correction record together. If the sample changes, distinguish the revised reference from the original. Otherwise, a later reviewer may be unable to tell whether a mismatch came from software behavior or from a different input. The TubePro manual documents map and list functions for that product; use the relevant version's documentation when evaluating actual behavior.
Follow the planned list into the acquisition environment
Demonstrate the transfer of an agreed subset of tubes into the proposed acquisition workflow. Record what identifies the subset, which file or connection carries it and how the operator knows the correct list is active. A map with all tubes visible is not proof that the intended acquisition list was transferred. The acceptance record should compare the selected source identities with the identities available in the receiving environment.
Test a revised list using sample data. The project may add or remove planned work through an authorized change, so the buyer needs to understand whether an update replaces, appends or conflicts with an earlier list. Ask how the workflow communicates that change and preserves the relationship to data already collected. Do not assume that a refreshed map silently updates every connected application in the same way.
Assign ownership of the interface. If mapping and acquisition applications are supplied separately, identify who resolves transfer errors and confirms compatible versions. A supplier may support its own export while another supplier supports only a particular import structure. The purchasing decision should document the complete tested combination, including any manual crosswalk or intermediate file, rather than accepting isolated statements that both products support tube lists.
Distinguish inspection status from condition categories
Define the administrative and technical meanings that the final map must communicate. A tube not selected for the work, a tube selected but not acquired, a record awaiting review and a reviewed result are different states. The appropriate technical result categories come from the authorized reporting process. Do not allow a blank or default symbol to imply a favorable inspection result merely because no indication entry has been imported.
Use a small set of fictional records to test these distinctions. Include one planned but unacquired item, one item awaiting review and one reviewed sample result with a clearly labeled hypothetical meaning. Ask the supplier to show the map, table and exported report for each. The purpose is to expose how the software represents missing or incomplete information, not to prescribe real condition categories or acceptance thresholds.
Review legends as controlled meaning, not decoration. A color can be visually clear while its definition is ambiguous. The report should state what the symbol represents and whether it reflects acquisition status, reviewed condition or another category. If a legend is reused from a template, confirm that its definitions still match the current project's agreed reporting basis. A familiar template should not silently carry obsolete meanings into a new assignment.
Check counts and summaries against the underlying records
Ask how summary totals are calculated and what population each percentage uses. A report may refer to all tubes in the component, the planned subset, acquired records or reviewed results. Those denominators are not interchangeable. The buyer should see a worked demonstration with a small known set so that the resulting totals can be understood without relying on a large visualization that is difficult to inspect manually.
Include repeated records and multiple reported entries in the example where the workflow supports them. Determine whether the summary counts tubes, indications, files or another object. A tube with more than one reported entry should not accidentally be treated as several separate tubes unless that is the explicitly intended calculation. The technical reviewer approves the reporting logic; purchasing records whether the software can implement it transparently.
Preserve the basis of the issued summary. If the report changes after an analyst revises an entry, the organization needs a controlled distinction between the earlier issued result and the new working output. Ask which functions the software provides and which responsibilities remain external. Do not describe a dynamic report as an immutable record or an audit trail unless the actual system and process support those claims.
Evaluate repeat inspections without assuming direct comparability
A recurring inspection creates an identity problem as well as a data storage problem. Ask how the application links a current tube record to a previous record and what happens when numbering, component configuration or reporting conventions change. The relationship should be explicit enough for a reviewer to investigate a mismatch. Similar names or positions on two maps are not sufficient evidence that the underlying records represent the same physical item.
Keep inspection date, method, scope and review context attached to each dataset used in a comparison. The technical authority determines whether and how the results can be compared. A software feature that displays two datasets together does not establish that differences represent physical change. The purchasing exercise should verify preservation of the necessary context, while the interpretation of trends remains a separate qualified decision.
Demonstrate how a corrected historical record is handled. The organization may need to retain the earlier issued report while using a revised record for a current review. Ask whether the proposed workflow makes those versions distinguishable and how the comparison identifies its inputs. Do not overwrite a prior dataset merely to make the visual comparison convenient. Preserve the relationship so a later reviewer can reproduce what was actually compared.
Test the report outside the supplier's screen
Export the proposed deliverable and open it in the environment the recipient will use. Check tube identifiers, legend definitions, page breaks, symbols and the relationship between tables and map views. A correct on-screen display can become difficult to interpret when reduced to a report page or transferred to another format. The acceptance exercise should include the actual delivered representation, not only the authoring interface.
Ask whether the recipient needs an editable project, a native source package or only the issued report. These are different deliverables with different software dependencies. If a customer must revisit the map or inspect linked source data, demonstrate that task using the proposed access arrangement. A PDF that communicates reviewed results may be sufficient for one contract while being insufficient for another. Record the agreed purpose rather than assuming one format serves every future need.
Check the exported record's identity and revision information. The recipient should be able to identify the component, inspection occasion and issued version without guessing from an email subject. Keep source-to-report links in the organization's controlled record. This does not require publishing confidential raw data; it requires enough internal provenance to explain which reviewed information produced the delivered map and summary.
Capture the acceptance result and ongoing responsibilities
Use the downloadable worksheet as a starting point for a small, controlled acceptance exercise. Replace its hypothetical identifiers with an approved sample set, add the expected observations and assign a reviewer before testing. Record actual outcomes rather than marking every row complete because a supplier performed a demonstration. Keep unresolved behavior visible and decide whether it prevents the intended use or can be managed through an accepted limitation.
Document the software versions, templates, import mappings and relevant configuration used in the accepted workflow. When one changes, the owner can determine which cases need to be checked again. A routine update should not silently change the meaning of a legend or a tube identifier. The software change record guide provides an administrative approach to retaining that decision evidence.
NDT Connect's equipment tracker does not create tubesheet maps, analyze tubing data or import these worksheets. It can hold the associated instrument identity and a note pointing to the organization's software acceptance record. Keep project maps, source files and approved reports in the selected inspection record system. The optional CSV is an independent evaluation worksheet and does not represent an application feature or an inspection approval.
Work through a hypothetical map acceptance issue
A fictional provider evaluates a mapping package for an owner whose tube names include a section prefix and leading zeros. The imported drawing looks correct, but the transfer to the demonstration acquisition list retains only the local number. The reviewer identifies that two sections now contain indistinguishable names. The team records a failed identity check and asks for a supported mapping that preserves the complete relationship before approving the workflow.
In the same fictional exercise, the report summary classifies an unacquired sample item using a default symbol that the recipient could mistake for a reviewed result. The team changes the agreed reporting configuration and repeats the sample export. This example claims no defect in a named product. It shows why the buyer should test ordinary identity and incomplete-work cases rather than relying entirely on a polished vendor demonstration.
The accepted decision records the tested identity convention, result meanings, summary population, export format and remaining review responsibilities. It explains what the software contributes and what the inspection organization still controls. That evidence makes the package useful for a specific tubing workflow without suggesting that map creation, automatic linking or a colorful report independently validates the examination results.
Frequently Asked Questions
Does an automatically generated tubesheet map need review?
Yes. Compare identity, count, orientation and relevant irregular features with the approved source information before relying on the map.
Can an uninspected tube share the same symbol as a reviewed no-indication result?
The reporting convention should make these meanings distinguishable. Test how the selected software represents incomplete or absent data before issuing reports.
Does comparing two datasets prove a physical trend?
No. The responsible technical reviewer must assess identity, method, scope and other relevant differences before interpreting a change.
References & Standards Cited
- Eddyfi: TubePro heat exchanger mapping and reporting software View source ↗
- Eddyfi: TubePro 6 user manual, revision history through November 2025 View source ↗
- Eddyfi: Magnifi acquisition and analysis software 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.